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
On Wed, Jul 16, 2008 at 9:24 AM, Ray Van Dolson rayvd@bludgeon.org wrote:
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).
Spacewalk handles both distros just fine, it just can't have them both in the same organization. This is because both distros provide the same versions of the same packages, with different signatures. The oracle bit isn't a huge deal, because it can use the free/development version just fine.
On Wed, Jul 16, 2008 at 8:28 AM, Robert Moskowitz rgm@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.
On Jul 16, 2008, at 9:36 AM, Terry wrote:
Our issue isn't bandwidth. Our issue is controlling which patches are to be deployed and at what time.
ok, then you want option a) from my previous response. if you're the gatekeeper of all packages that go into your private repository, and if your systems aren't pulling packages from any other repos, then i would think that would give you the necessary degree of control.
you may find Dag's mrepo tool (http://dag.wieers.com/home-made/mrepo/) useful for building this infrastructure.
-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@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).
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 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
----- Message from rainer@ultra-secure.de --------- Date: Wed, 16 Jul 2008 16:08:06 +0200 From: Rainer Duffner rainer@ultra-secure.de Reply-To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] centralized patch management To: CentOS mailing list centos@centos.org
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 _______________________________________________
Ok, so what would you suggest is a good practice for a hosting environment with a few different RH based (CentOS & Fedora Core) servers, all doing different stuff?
Rudi Ahlers wrote:
Ok, so what would you suggest is a good practice for a hosting environment with a few different RH based (CentOS & Fedora Core) servers, all doing different stuff?
do you have test/staging servers for each of these production environments?
without such, there's really not much you can do, short of manually patching and praying.
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
-
Jim Perrin -
John R Pierce -
Rainer Duffner -
Ray Van Dolson -
Robert Moskowitz -
Rudi Ahlers -
Steve Huff -
Terry -
Tom Brown