All,

We're in the process of evaluating candidates for a new Linux OS and patch management system for our corporate environment. Up until now, we were unable to do this due to internal opposition by developers. Our previous solution was Gentoo, which has become nearly impossible to administer. Our environment necessitates high availability and thorough testing. We have several application environments; each consists of at least 1 dev, 1 staging, and 1 production environment. Staged rollouts are the norm. Admin resources are spread thin.


We've identified the following requirements:

Centralized Patch Management
-tracking of applied/unapplied patches
-phased rollout to a large # of server groups (business, dev, staging, production, etc.)
-patch success auditing/reporting
-central console for managing patches
-ability to provision a server and bring it to a group's current patch level

Versioned Releases
-Specific versioned releases
-Long-term support of releases for security fixes (3+ years)

Strong User-Base/Industry Support

Remote Management



We've been looking at RHEL 5.1, CentOS 5.1, and Debian 4.0 so far. We think that SLES 10 and Ubuntu Server may also be viable options, but haven't had time to look at them yet. We've looked at both vendor- and third party-based solutions for patch management. CentOS doesn't appear to have any support for centralized patch management. We're wondering if we'll run into this problem with Ubuntu as well...

What solutions are out there to accomplish this?

What do you use in your environments for a Linux OS? Patch Management?

UNIX isn't an option, since we already have a lot of code developed specifically for Linux that can't be easily ported.

I think it's generally fair to say that any distribution can be managed en mass as long as there's some form of atomic package management. with ubuntu or other debian derivatives you could really very easily set up your own apt repositories and craft sources.list files for different types of machine and distribute and report on patch levels really quite easily. I'm not aware of anything preexisting to do thism but the level of nix know-how to rig up a framework for this really isn't going to be too great, depending on what you want to do. I'd assume the same would be true for gentoo, although i will acknowledge that the portage world does really live online to quite some extent. it'd be doable with a better understanding though, without a doubt.

Redhat's Satellite product does (appear) to be approaching something resembling the dogs proverbials with the patch management side being well supplemented by Xen management and a really attractive support licensing model with Xen if that's a route that interests you. You don't need the satellite itself, but it does make things easier. without it you can still do patch management through the online rhn interfaces...

What we used (Stuck in a Windows place at the moment grrr.) was apt.

Rather than patching libs and binaries, we created packages of one lib, one binary etc.. and used apt to handle dependancies. We could handle partial upgrades etc. without breaking things, and knew if we updated a program that required a particular version of a library things would be handled smoothly.

Also we had one server in each section ( Development, Testing, Live ) be the keeper for that enviroment, and all the other machines update from the one in their stage.

It worked well, we had a nice tool that was developed as well so it would check the build enviroment and create the packages for us. Wish I was still using it

Two things come to mind,
At my work we have a volume redhat license which may or may not make sense in you case. The advantage is that the Redhat Network (RHN) gives you the ability to have configuration channels so that machines can be managed in groups.
There is also cfengine which I have not used but I hear good things

Thanks for the info everyone. We're going to try to pursue using Debian with an in-house apt repository, maybe more than one (we're going to need separate patch sets for separate environments) , depending on how exactly it works. cfengine definitely looks like something to look into for configuration.

Thanks Again,
John