RedHat linux package management

[John Guster]

We have test and production systems. we want have a controlled way to install any packages: test system first, 2 weeks late the same packages are installed on production system if there is no any issue on test system. How to make the packages on test system avaliable to production system? The packages include application s/w and any patches/fixes. We use redhat network for each system. Any suggestions are welcome. Thanks

[Steven E. Protter]

Shalom,

Set up a full set of application tests to insure the integrity of your test system prior to doing an installation on production.

Set up test criteria and expected results.

Do not go production until you are certain and get good results.

SEP

[Brem Belguebli]

If you use RHN with a sattelite connexion, you can create your own baseline with selected patches/fixes, install it on your test systems, and a few weeks later deploy it on your prod systems

[dirk dierickx]

even if you only use RH's packages from their site (without your own satelite server), you can still set up your own repository for packages.

pre RH5 you will need to install yum yourself and point to your internal repository only. RH5 has yum included and you can just add your own repository to the list.

[Steven McCoy]

This may be helpful:

http://kbase.redhat.com/faq/docs/DOC-7228

[Jared Middleton]

Like John, we have 6 servers (Play, Dev/Test, and 4 Live Production), fully Hosted, no Proxy or Satellite.

It appears to be common practice that updates are installed first on the Play or Dev/Test instance and if everything checks out, then schedule each Production server to be likewise updated (directly from RHN?).

While one can use a simple "up2date -uf" (w/possible reboot after) on the initial Test server, this is generally not appropriate for making the Production boxes match the Test installation.

SOX/Auditors do not like the idea of running "up2date -u" directly on Production.

If one waits very long between "patch-up" cycles or otherwise accumulates a bunch of pending updates to test & apply, the more likely Red Hat is to: 1) add more new Errata packages 2) (re)revise packages already being tested... after a Test has started but before all Production servers have been updated to match.

We don't have GUI-oriented packages installed, only ChUI command line tools (via ssh) and Webmin... So there's no mouse-click selection available (in our environment) to create a bundle of packages to install on Production (which would exactly match what just passed Test).

We do have the RHN Management Module entitlement on all 6 systems, in which the RHN website provides a "Package profile comparison" tool to compare two systems directly against each other to visually see the differences. Unfortunately, AFAIK, you cannot actually do anything to "sync" the differences... unless you also have the RHN Provisioning Module.

QUESTION: Is there a common industry practice for updating Production systems to match Test under the above type of scenario?

If adding "Provisioning" to all systems is THE answer, then can-do. Adding "Satellite" would be more problematic.

[Jared Middleton]

I forgot to mention, solution should work for both RHEL 4 and RHEL 5, ideally the same way.

Also, does one have to setup a local repository (RPM archive) in order to guarantee version matching?

Example: All systems are running version 3.1.0 of a package. RHN Errata 3.1.1 comes out and start Test. Before all Production systems are updated, RHN Errata 3.1.2 comes out.

Do you: 1) restart Test with 3.1.2 or 2) proceed with 3.1.1 through to Production first?

Restarting might be okay once, but in theory this could happen again. If Proceed, is the(outdated) package 3.1.1 still available from RHN and/or on the Test server (by default)?

I recall seeing recent packages, but not all. Are downloaded RPMs rotated out (purged over time) by default?

[Heironimus]

You probably won't like this answer. The best way I've found is to run up2date or yum on one server, copy the RPMs out, and just use rpm to install them on other servers.

When I pushed to move our environment to a similar patch schedule I don't think we found any tools to facilitate it in RHN. I suppose it's because they really want to sell you an expensive satellite server to go with the expensive RHN subscriptions. There are other tools like cobbler that can create custom repositories, if you have the time to dedicate to it.

[Steven E. Protter]

Shalom,

You can install Centos yum into RHEL 4 and then use yum repositories to update all your systems.

The packages will not be the same, but the update method can be simple and not depend on the red hat network.

I updated rhel4/5 systems as follows.

I had a single system, 32 bit and 64 bit for each RHEL 4 and 5 registered on RHEL.

Those systems gathered patches nightly by script, copied them to NFS share and ran other scripts to build repositories.

I can provide you the scripting for this which varies due to RHEL 5 having yum built in, if you wish.

SEP