Patch Management

[Joel Merrick]

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'

[R.I.Pienaar]

----- "Joel Merrick" <joel.m...@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.

[luke.bigum]

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.

[Joel Merrick]

On Tue, Nov 2, 2010 at 2:50 PM, luke.bigum <luke....@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

[donavan]

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.

[Joe McDonagh]

++ 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.

--
--
Joe McDonagh
Operations Engineer
AIM: YoosingYoonickz
IRC: joe-mac on freenode
"When the going gets weird, the weird turn pro."

[pinto...@gmail.com]

Fwiw, at @rpm5.org probably there is Some interest in This. Regards

Hi Joel,

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.