[mdlug] Centralized package management tools

[Wojtak, Greg]

Ah, the holy grail for CentOS/RHEL systems (aside from paying Red Hat
$13,000 a year for a satellite server!).

I am looking for the same thing (and I'm sure any other Linux Sysadmin
is) for years.  I'm still using the strategy of "install updates on dev
server, keep the rpm's that were downloaded, move them to test, then
production, and pray to God that the same packages are in sync across
all environments."  

Not very efficient.  I've been looking into building a yum server and
configuring the yum-updatesd to download the packages that I roll out.
A little better than using cron, but not by much.

I'd be interested to hear if you find anything.

Greg Wojtak

-----Original Message-----
From: mdlug-bounces at mdlug.org [mailto:mdlug-bounces at mdlug.org] On Behalf
Of Michael ORourke
Sent: Monday, December 01, 2008 9:29 AM
To: MDLUG's main mailing list
Subject: [mdlug] Centralized package management tools

Lug nuts,

I'm looking for some recommendations, specifically for the CentOS 5.2 
distribution, for a centralized package management system or tools.
I've 
spent some time doing vaious Google searches, but haven't found what I
was 
looking for aside from basic tools such as 'yum' and 'up2date', which
are 
designed to run on a single host.  I was hoping that I would stumble
upon 
some existing tools that could be leveraged in an existing environment.
What I would really like is:
* Gui tools (browser based).
* Internal centralized server (package repository).
* Centralized management (for development, QA, & production).
* Ability to schedule updates and manually push updates.
* Auditing capabilities (which servers have what packages installed).
* Ability to manage servers by group (e.g. Dev App servers).

Running 'yum -update' from cron on each server isn't a good strategy, 
especially when it comes to production systems.  I would like to have
the 
capability to pull down patches to a centralized server, then push the 
patches/updates to the development/QA environment, and finally out to
the 
production systems after testing is completed.
Is that too much to ask for.  :-)
Any suggestions/recommendations/ideas?

Thanks,
Mike 

_______________________________________________
mdlug mailing list
mdlug at mdlug.org
http://mdlug.org/mailman/listinfo/mdlug