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.


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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).
>
> http://www.redhat.com/spacewalk/


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.



--
During times of universal deceit, telling the truth becomes a revolutionary act.
George Orwell
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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



_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

----- 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?



--

Kind Regards
Rudi Ahlers


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos

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.

_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos