Hello, I have been asked to come up with a strategy for centralized patch management of our linux servers. Today, this is only centos and rhel. What is everyone else doing in this arena? Thanks!
On Wed, Jul 16, 2008 at 08:08:31AM -0500, Terry wrote:> Hello, > > I have been asked to come up with a strategy for centralized patch > management of our linux servers. Today, this is only centos and rhel. > What is everyone else doing in this arena?For RHEL, at work we use RHN Satellite. For CentOS we don't currently deploy enough to warrant anything although you might look at CFengine or puppet. In addition, Spacewalk is the recently "opened" version of RHN Satellite and it should be able to run with CentOS. I don't think it's a perfect solution yet however as it still requires Oracle on the back-end and I don't believe you can run it with RHEL and CentOS machines simultaneously (someone correct me if I'm wrong). http://www.redhat.com/spacewalk/ Ray
Terry wrote:> Hello, > > I have been asked to come up with a strategy for centralized patch > management of our linux servers. Today, this is only centos and rhel. > What is everyone else doing in this arena?Set up a local repo and point all your systems to it.
On Jul 16, 2008, at 9:08 AM, Terry wrote:> I have been asked to come up with a strategy for centralized patch > management of our linux servers. Today, this is only centos and rhel. > What is everyone else doing in this arena?here's a reasonably straightforward scheme: 1) make sure yum is installed on all your systems (if you have RHEL4 boxes) 2) host your own yum repository 3) install an appropriate myrepo.conf in /etc/yum.repos.d on all your hosts at this point you have a few options: a) mirror the upstream base and updates repos for your architectures into your local repo and remove all the other contents of /etc/ yum.repos.d on all your hosts. this gives you the maximum control over when patches go out to your machines; unfortunately, capturing updates from RH is a bit arduous (one way to do is is to run one machine per architecture that has an RHN subscription, capture all the packages it downloads, and copy them into your local repository) and, especially if you're manually approving each package that gets copied over, it can introduce delay in the deployment of patches. b) let your systems pull updates from RHN or from CentOS mirrors as normal, and add any additional packages via your custom repo. this scheme requires less effort, but may not be as "centralized" as you desire. both of these schemes scale to accommodate other third-party repositories, though you have to think about whether you want other repositories to clobber packages from your distribution. these should also scale to accommodate other RPM-based distributions. -steve -- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
Terry wrote:> On Wed, Jul 16, 2008 at 8:28 AM, Robert Moskowitz <rgm at htt-consult.com> wrote: > >> Terry wrote: >> >>> Hello, >>> >>> I have been asked to come up with a strategy for centralized patch >>> management of our linux servers. Today, this is only centos and rhel. >>> What is everyone else doing in this arena? >>> >> Set up a local repo and point all your systems to it. >> >> > > Our issue isn't bandwidth. Our issue is controlling which patches are > to be deployed and at what time.Unless your systems are scattered all over the Internet, you probably should still run a centralized repo server for the Centos systems. You can also put all your 'special' rpms there. Then whatever you use to schedule what patches when, would get them without relying on how the mirrors are working. Plus what you pull down would be input into what you need to distrubute (rather than plowing through the update announce messages).
Terry schrieb:> Hello, > > I have been asked to come up with a strategy for centralized patch > management of our linux servers. Today, this is only centos and rhel. > What is everyone else doing in this arena? > >I investigated this earlier. The only thing that seems halfway usable is pakiti: http://pakiti.sourceforge.net/ People who think that running "yum update" every night is a solution should go back and do some research. This is how it might work at home (mostly), but not the way you deploy patches to a large number of systems who serve different purposes and thus have different package-selections, user-requirements, patch-policies and downtime-schemas etc.pp. I hope to be able to test pakiti soon. cheers, Rainer
> > I have been asked to come up with a strategy for centralized patch > management of our linux servers. Today, this is only centos and rhel. > What is everyone else doing in this arena? > >i would say Pulp fits the bill from what you have said https://fedorahosted.org/pulp