Hi Puppeteers! I''ve just been speaking to Ohad on #theforeman about package management, specifically about generating lists of packages : version numbers across the estate for things like patch management. DISCLAIMER: I''m new to puppet! What I was initially thinking was extended facter to produce a dpkg/rpm etc.. output but I''ve been told that facter doesn''t produce hashes and the size of the list would probably exceed the available HTTP GET? Ohad showed me some code that would generate this list, but it obviously doesn''t tie straight into puppet. Is there any way this could be accomplished? I suppose the nirvana for me would be to be able to instantly see if a package needs updating, based upon a CVE/DSA/RSA etc similar to the way pakiti does it [1].. (although I suppose a sources.list with just security sources would do) and then use something like mcollective to slowly, but safely upgrade the package. Has this been thought of as an approach at all, or do people here use their own repo''s and just finely control what goes into it and use some other mechanism to push the updates? Any thoughts on this matter greatly appreciated, Cheers Joel [1] http://pakiti.sourceforge.net/ -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge'' -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
----- "Joel Merrick" <joel.merrick@gmail.com> wrote:> Is there any way this could be accomplished? I suppose the nirvana > for me would be to be able to instantly see if a package needs updating, > based upon a CVE/DSA/RSA etc similar to the way pakiti does it [1].. > (although I suppose a sources.list with just security sources would > do) and then use something like mcollective to slowly, but safely > upgrade the package.not sure if this will solve all your needs but it should be trivial to write something for mcollective to parse ''yum check-update'' output and aggregate that over your entire estate. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Nov 2, 2:26 pm, Joel Merrick <joel.merr...@gmail.com> wrote:> Hi Puppeteers! > > I''ve just been speaking to Ohad on #theforeman about package > management, specifically about generating lists of packages : version > numbers across the estate for things like patch management. > > DISCLAIMER: I''m new to puppet! > > What I was initially thinking was extended facter to produce a > dpkg/rpm etc.. output but I''ve been told that facter doesn''t produce > hashes and the size of the list would probably exceed the available > HTTP GET? Ohad showed me some code that would generate this list, but > it obviously doesn''t tie straight into puppet. > > Is there any way this could be accomplished? I suppose the nirvana for > me would be to be able to instantly see if a package needs updating, > based upon a CVE/DSA/RSA etc similar to the way pakiti does it [1].. > (although I suppose a sources.list with just security sources would > do) and then use something like mcollective to slowly, but safely > upgrade the package.Not 100% on what you''re trying to achieve, even after looking at Pakiti. A few questions... Do you know the packages that need updating or do you have a list of ones that need to be kept up to date? Do you just want to keep everything up to date? Do you want to be TOLD what needs updating across your site and then click/run something that will automatically do it? For the first one, you can use Puppet to ensure the latest version of a set list of packages is the latest version. This of course assumes you''re running on an OS where the Puppet provider allows such an action: $package_list = [ "glibc", "kernel" ] package { $package_list: ensure => latest, } For the second, you could use Puppet to execute a global update of packages every night either with an ''exec'' resource or ''cron'' resource. For the third you won''t be able to easily achieve that with stock Puppet. One idea might be to write a custom fact to print a comma separated list of packages and version numbers that you could then do "something" with. The facter output might look like: $facter ... upgradeable_packages => lm_sensors-2.10.7-9.el5,glibc- common-2.5-49.el5_5.7,nscd-2.5-49.el5_5.7 But you might run into some string size limit somewhere. What do you mean by "slowly, but safely upgrade the package"? Are you afraid of compatibility issues between upgrades and want a great deal of control? If you are gearing towards option 3, I''m not sure Puppet''s the best tool the job. I use CentOS and so I''d look into the free version of Red Hat''s Satellite, Spacewalk for fine tuned software update control and deployment if I wanted to achieve the same thing.> Has this been thought of as an approach at all, or do people here use > their own repo''s and just finely control what goes into it and use > some other mechanism to push the updates?> Any thoughts on this matter greatly appreciated, > > Cheers > Joel > > [1]http://pakiti.sourceforge.net/ > > -- > $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge''-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Tue, Nov 2, 2010 at 2:50 PM, luke.bigum <luke.bigum@fasthosts.co.uk> wrote: Do you want to be TOLD what> needs updating across your site and then click/run something that will > automatically do it?Yep, this is the one. Apologies if it wasn''t clear> > For the third you won''t be able to easily achieve that with stock > Puppet. One idea might be to write a custom fact to print a comma > separated list of packages and version numbers that you could then do > "something" with. The facter output might look like: > > $facter > ... > upgradeable_packages => lm_sensors-2.10.7-9.el5,glibc- > common-2.5-49.el5_5.7,nscd-2.5-49.el5_5.7 > > But you might run into some string size limit somewhere.Yes, most likely!> > What do you mean by "slowly, but safely upgrade the package"? Are you > afraid of compatibility issues between upgrades and want a great deal > of control?For example if I wanted to keep a certain package up to date on a load balanced service, I wouldn''t want the particular service to be restarted at once, this is where mcollective could help. Ideally it would have been great to have facter generate the list of packages, without the need for another intermediary sending data back to a central point. If this needs to happen outside of the scope of puppet itself then no big deal.> > If you are gearing towards option 3, I''m not sure Puppet''s the best > tool the job. I use CentOS and so I''d look into the free version of > Red Hat''s Satellite, Spacewalk for fine tuned software update control > and deployment if I wanted to achieve the same thing.Debian shop (un)fortunately :) Thanks for the mail though, gives food for thought Joel -- $ echo "kpfmAdpoofdufevq/dp/vl" | perl -pe ''s/(.)/chr(ord($1)-1)/ge'' -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Nov 2, 7:26 am, Joel Merrick <joel.merr...@gmail.com> wrote:> Hi Puppeteers! > > I''ve just been speaking to Ohad on #theforeman about package > management, specifically about generating lists of packages : version > numbers across the estate for things like patch management.Hi Joel, It''s not really an answer but there was related talk at puppetcamp. One of the ideas from puppetlabs was integration between package management databases and puppets resource modeling. I don''t think there were any detailed plans, but I imagine it would make your query requirements pretty easy. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
++ RIP, I''ve piloted mcollective but have not yet deployed as a standard C&C tool. It is the future IMO, so if you''re starting from scratch, it''s probably what you want to go with, as I sort of view puppet as not being the tool for this job For this stuff now, I use a combo of Nagios and capistrano. Nagios can tell me when nodes are out of date via the check_cluster plugin (info generated dynamically from puppet) as a cluster of the check_apt plugin. Capistrano can easily pull my nodes from puppet stored configs, dynamically stuff them into roles based on hostname (mcollective does not have the limitation of relying on hostnames), and I can update to various groups of hosts based on OS, DC/location, or type of service such as webservers, smtp servers, etc. I suppose some logic could be coded into my capfile to get this info more gracefully than simple hostname parsing, but at that point I would just deploy mcollective. I have some really simple code I can share if you need to, but I am warning you right now, capistrano is not a scalable tool. It barfs, last time I checked, on more than 30 or so simultaneous ssh connections. This could be a limitation of the ssh-agent, but I''ve worked around it and haven''t done any stress testing in months. Security stuff like CVE''s would be a little more involved. The company I work for scans for this stuff, but we don''t really have an automated fix integration process. We generate remediation reports, but that just tells a human what to do. Like I said, mcollective is the future for this kind of stuff, but cap is sort of easier to get going with since it''s plain ssh connections. I guess it depends on a few factors like, size of your infrastructure, how quick you need it, etc. If you have time, go with mcollective. On 11/02/2010 10:38 AM, R.I.Pienaar wrote:> ----- "Joel Merrick"<joel.merrick@gmail.com> wrote: > > >> Is there any way this could be accomplished? I suppose the nirvana >> for me would be to be able to instantly see if a package needs updating, >> based upon a CVE/DSA/RSA etc similar to the way pakiti does it [1].. >> (although I suppose a sources.list with just security sources would >> do) and then use something like mcollective to slowly, but safely >> upgrade the package. >> > not sure if this will solve all your needs but it should be trivial to > write something for mcollective to parse ''yum check-update'' output and > aggregate that over your entire estate. > >-- -- Joe McDonagh Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode "When the going gets weird, the weird turn pro." -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Fwiw, at @rpm5.org probably there is Some interest in This. Regards -----Original Message----- From: donavan Sent: 06/11/2010, 04:03 To: Puppet Users Subject: [Puppet Users] Re: Patch Management On Nov 2, 7:26 am, Joel Merrick <joel.merr...@gmail.com> wrote:> Hi Puppeteers! > > I''ve just been speaking to Ohad on #theforeman about package > management, specifically about generating lists of packages : version > numbers across the estate for things like patch management.Hi Joel, It''s not really an answer but there was related talk at puppetcamp. One of the ideas from puppetlabs was integration between package management databases and puppets resource modeling. I don''t think there were any detailed plans, but I imagine it would make your query requirements pretty easy. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.