Patch bundles for RedHat Enterprise Linux

[Simon Hargrave]

I'm after some advice on patching Enterprise Linux (AS3).

On HPUX we create 3-monthly patch bundles which we swinstall - simple.

In RHEL we'd like to be able to do a similar thing, ie have a bunch of "all" patches from a point in time, and apply that over our Linux servers as required.

I know the RedHat philosophy is to keep your server up to date using up2date, but as this is a constantly changing channel we can't maintain servers in the same patch state.

Now, RedHat Satellite Server aside (which I believe only runs on AS2.1 anyway???) the best option I see is to have one central server download the whole channel periodically. Then install YUM on all the other servers and update from this static repository.

Question from this are: -

- Does anyone else do this, is it a good idea?
- What are the support implications?
- Are there any other options for "static" patch bundles?

Cheers,


Sy

[xyko_1]

Hi Simon,

I guess RHN Proxy Server may solve your problem.
http://www.redhat.com/docs/manuals/RHNetwork/proxy/3.6/intro-proxy.html

See also the full collection of RHN manuals at
http://www.redhat.com/docs/manuals/RHNetwork/

regards,
Xyko

[Andrius]

HI,

check the open source RHN's version at http://current.tigris.org/
It has some issues, but are on heavy development.

Andrius

[Simon Hargrave]

Thanks for the replies. I've developed a solution that works as I'd like though. If anyone's interested here's what I do: -

On the "master" server, download all RPMs in the AS3 channel with: -

up2date --showall | xargs up2date --get

This downloads all the RPMs to a local directory.

I then NFS share this directory to any server that is to be patched and mount it.

On the servers to patch, add a line: -

patch-bundle /mnt/tmp/patches

to the file

/etc/sysconfig/rhn/sources

Then I can use up2date, untick the RHN channel and leave the "Local" channel. It then updates from this static repository, without trying to get later untested version from the network.

[Simon Hargrave]

Sorry the line added to the file must be prefixed with "dir" as in: -

dir patch-bundle /mnt/tmp/patches

[Steven E. Protter]

I would suggest using the rpmbuild utility to create.

Red Hat doesn't create big bundles. The rpm system is a pain that I've had to enhance with several helper scripts to make it useful.

SEP

[TJ_16]

We are also having this exact same problem with patching RH 2.1/3.0 servers...

Any idea if this works on 2.1?

Thanks,

[TJ_16]

Just checked this out and it is nice on RH 3.0 servers, but 2.1 servers seem to not be able to use this...
2.1 also doesn't have the rpm --aid option.

How do you all handle your 2.1 patching?

Thanks,

[Vitaly Karasik_1]

there are few more ways:

1) using OnStage from Aduva, Patchlink and similar products

2) using just "rpm -F *.rpm" for upgrading

[Simon Hargrave]

Sorry I don't know about 2.1, we don't have any of that release.

rpm -Fvh * is not a reliable solution. If you are upgrading a package that has "new" dependancies, for (a daft) example you upgrade to the latest version of xterm and it needs lib3d when before it didn't, rpm will NOT install lib3d and therefore will now work since the F option won't install anything that doesn't exist.

It's poor, but it's the way it works. In an ideal world it'd upgrade only packages that are installed, but would also allow any selected "new" dependencies to install.

You may think that this is a rare occurence, but think back to the first time you ran up2date on a clean AS3 installation. It adds various packages to solve dependencies required by the patches, including:

aspellconfig
bind-libs
compat-db

to name but a few. These would not be applied in the case of Fvh *.

[Vitaly Karasik_1]

yes, I know about this problem, but I resolve it by just adding several

rpm -Uv some-package.rpm

commands before

rpm -Fv *rpm

Yes, it's not so elegant :-(

[Paul Tibbitts]

I was wondering if anybody had gone the yum route since the orignal posting, as we are also looking at alternatives.

A comment on the rpm -F issue. What we're looking at doing, because we have an identically configured (software/hardware) test environment, is doing the up2date (from RH) on the test envrionment, and save the resulting rpms in an exportable directory. Once testing is complete, the directory (containing only those rpms, and probably named according to the date of the original up2date) can be exported to production servers and the following done:

1. rpm -U on all but the kernel rpms (assuming you want to mimic up2date behavior in saving the old kernels)

2. rpm -i on the kernel rpms

This creates a problem of course if any of the non-kernel rpms depend up the new kernel rpm (haven't run into that yet - is it a practical problem?) If it is, I guess just using U the whole bunch would work.

The final problem is dealing with obsoletes. Again, I'm not sure if this is a practical problem, but if something is obsoleted and not replaced by something newer, it would be deleted (I assume) by up2date but not by this process. I'm haven't looked into how to fix that yet.

Paul

[Simon Hargrave]

Regardless I found yum just not as useful as up2date in terms of resolving dependancies.