RPM has some issues handling configuration files. I'm sure this has
happened to many people: Upgrade RedHat, reboot, system boots but some
configuration is hosed, curse, poke about, find broken configuration file,
fix, boot.
IRIX provides the 'versions changed' mechanism to deal with this; a snippet
from the manpage is appended. I've found that the following is a simple
approximation:
for i in `rpm -qac`; do if [ -f $i.rpmsave ]; then rpm -qf $i;\
ls -l $i $i.rpmsave; echo; fi done
ypbind-3.3-20
-rwxr-xr-x 1 root root 1457 Apr 15 1999 /etc/rc.d/init.d/ypbind*
-rwxr-xr-x 1 root root 926 Oct 12 1998 /etc/rc.d/init.d/ypbind.rpmsave*
knfsd-1.4-2
-rwxr-xr-x 1 root root 2455 Jun 18 14:35 /etc/rc.d/init.d/nfs*
-rwxr-xr-x 1 root root 1775 Nov 30 1998 /etc/rc.d/init.d/nfs.rpmsave*
autofs-3.1.3-2
-rw-r--r-- 1 root root 494 Apr 9 1999 /etc/auto.misc
lrwxrwxrwx 1 root root 9 Nov 14 1998 /etc/auto.misc.rpmsave ->
auto_misc
but I didn't figure this out until after I had a hosed system and was in
panic mode. Since the RPM manpage doesn't make any mention of 'rpmsave'
files, panic mode led quickly to 'freak out' mode. The above helps but
notice that unlike what IRIX does, the above can't tell you if you had made
local changes to the old version (and thus need to be careful about
merging) because the data for it has already been lost.
Has anyone thought about integrating this kind of thing better? IRIX will
warn you at boot time if you have unmerged configuration changes; perhaps
RedHat should do the same. The installer should probably give you the
opportunity to merge configuration changes before it reboots the machine.
The RPM documentation should be clearer about exactly what it will do with
configuration files that have been locally modified.
--
Jason L Tibbitts III - [EMAIL PROTECTED] - 713/743-3486 - 660PGH - 94 PC800
System Manager: University of Houston Department of Mathematics
"You'll see the blood as we roll in it together..."
Excerpt from the IRIX 'versions' manpage:
[...]
Because configuration files often contain modifications, inst treats them
specially during the installation process. If they have not been
modified, inst removes the old file and installs the new version during
software updates. For configuration files that have been modified, one
of three things occurs:
- The new version is not installed at all.
- The new version is installed and the old version is renamed by adding
the suffix .O (for older) to the name.
- The new version is put in a file whose name is created by adding .N
(for newer) to the original name.
[...]
Updating Configuration Files
As discussed in the Definitions section, some files in a product are
called configuration files and are handled specially during installation
because they contain system or site-specific information. As a result of
this, .O (older) and .N (newer) versions of configuration files may be
left on your system after an installation.
When you reboot your system, a check for .O and .N files is done. If any
are present, a message is displayed suggesting that you merge
configuration files in cases where there are two versions. To do this,
first enter the command:
versions changed
[...]
After you have examined the .O and .N configuration files and made any
changes you want, you can delete the .O and .N versions of the
configuration files. If you want to keep them, you should rename them
because they might be removed automatically during the next software
installation. If you remove all of the .O and .N configuration files,
then no message about configuration files appears when you boot your
system. The message also stops appearing even if .O or .N files continue
to exist after some number of reboots.
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
