Chris's Wiki :: blog/sysadmin/PatchesAndPackaging

Patch management is part of package management

January 9, 2010

There's two approaches to distributing updates; you can distribute entire new versions of packages, or you can use some sort of 'patches'. For essentially historical reasons, commercial Unix vendors generally use the latter approach.

Here is something important about this: if you have patches, patch management needs to be part of the packaging infrastructure, even if it is not done with the package management system and commands. It cannot and should not be something that is just slapped on over top.

Here's why:

From a sysadmin perspective, the purpose of package management is to keep track of what is on your system; what is there, where it comes from, what it should look like, and so on. (This applies whether or not the packaging system is used for extra software or is only for the base operating system.)

The purpose of patching is to change what's on your system. This is exactly what package management is supposed to keep track of, so that it can give you correct answers to your questions about what should be there and where it should have come from. Ergo, patching needs to be part of package management so that package management can continue to give you these answers, instead of out of date lies.

(Patching is not the only such thing, mind you. As a general rule, current package management systems are utterly lacking in ways for sysadmins to tell them about changes. If it's not a new version of a package, they don't know about it and they don't want to hear from you. I maintain that this is a mistake, but that's another entry.)

Comments on this page:

From 65.172.155.228 at 2010-01-11 00:25:35:

As a general rule, current package management systems are utterly lacking in ways for sysadmins to tell them about changes. If it's not a new version of a package, they don't know about it and they don't want to hear from you. I maintain that this is a mistake

Well you already said you'd answer it, so feel free to think of this as "things I should cover, in that post" :)

So here are my assumptions: At time N sysadmin A installs pkgA. and it is working. That at time N+M sysadmin B does one of the following things:

Changes the config. for pkgA.

Installs pkgB that overrides pkgA.

Changes the config. for pkgZ which screws up pkgA.

Uses something like alternatives to override pkgA with previously installed pkgC (this is slightly different than the previous one, IMO).

Changes the config. for code YY which isn't a package.

Now in case 1, "rpm -V"/"yum verify" will tell you something changed and it should be spotted easily ... you just won't know what it was without going to backups. This gets a little harder if the config. was changed at time N (so "is it different" from default isn't enough), but timestamps will also have changed (and "yum verify" will nicely tell you what the new timestamp is). So while everything can be improved, I think current packaging systems are pretty good here.

Case 2 is hard to spot by just looking at pkgA, because nothing has changed there. But tools like "yum history" and "yum version" will point to this directly/easily. IMNSHO current packaging tools are awesome here, although this is not what you are complaining about :)

Case 3 is hard, you really need "yum history" but for the configurations of all packages ... I guess this is the main problem you are thinking about, and I agree this is a useful feature. We could maybe do something like "yum version" which includes all the files of all the packages, but I'm not sure it'd be stable enough to do anything useful with (you certainly couldn't compare it across machines as you do with the version, without a lot of exceptions). My main opposition is that I see little benefit in integrating this into "package management". Due to...

Case 4 is like case 3, except as far as "package management" is concerned nothing has changed /etc/alternatives/mta isn't owned by anything, although /usr/sbin/sendmail is "owned" by everything that can be an alternative ... so you can kind of argue that the packaging system can find it's way to the problem.

Case 5 is the degenerate case of case 3-4, something changed somewhere that the packaging system knows nothing about but it broke a package. An example here would be /etc/sysconfig/network-scripts/ifcfg-* ... any sane packaging system can't know about those files, but changing them can sure screw up packages :).

So solving cases 3-5 easily basically requires having a history of what changed, but as cases 4-5 show you can't limit to "what changed that is owned by a package" ... thus. my argument that putting this in with "package management" isn't the right thing to do.

Written on 09 January 2010.

«	A brief and jaundiced history of Unix packaging systems

Why the Solaris packaging system is bad