|
|
The Answer Guy 34:
Updates: Risks and Rewards
"Linux Gazette...making Linux just a little more fun!"
 Updates: Risks and Rewards
From Frits Hoogland on 08 Oct 1998
Hi almighty answerguy!
I'm a bit confused by all the updates of various system components (like
the libc, gcc, etc, etc). Is it advisable to loop at ftp.redhat.com for
updates of my 5.0 system? Is it advisable to download a new kernel? Can
I install let say kernel 2.0.35 (which, as I noticed, nearly everyone
uses) or are there things I have to consider, things I have to check,
etc.?
 That's an excellent question. Using Red Hat's package
management system (RPM) does make it faster and easier for
most "mere mortals" (myself included) to upgrade most
packages and install most new ones.
Debian package management is allegedly at least as good
--- but it doesn't seem to be documented nearly as well
so it's harder to learn than RPM. (Hey, Debian dudes
if you write a DPKG/APT Guide for RPM users --- you might
win more converts!).
Even Slackware's pkgadd (or is that pkg_add, it's been
so long) is somewhat easier than the old "manly" way of
upgrading your software (downloading the sources,
and building them yourself).
Indeed, even that approach (building from sources) has
improved quite a bit over the years, for most packages.
The mark of a good modern package is that you can
install it, from source with the following sequence
of commands:
tar tzf /usr/local/from/foo.tar.gz
# look at contents, insure that it creates
# it's own directory tree and puts everything
# in there:
tar xzf ....
cd /usr/local/src
# extract the sources into our local source
# tree. (Might need to do a mkdir and cd into
# that if your package extracts to the "current"
# directory).
cd $package_source_top_level_dir
view README
# or 'more' or 'less' -- maybe different README's
# This should have some basica instructions
# which ideally will amount to:
./configure
# possibly with options like --prefix=/usr/local
make install
... Note that the really important parts of this are
'./configure' and 'make install' After that a good
source package should be ready to configure and run.
(Note that the "configure" command in my examples is a
script generated to perform a set of local tests and
select various definitions that are to be used by the
make file. This, in turn, tells the local system how to
"make" the program's binaries, libraries, man pages and
other files in a way that's suitable for your system ---
and (with the commonly implemented "install" option or
"target" in "makefile" terms) tells the 'make' command
where to put things. There is a difference between
"./configure"-ing the sources to be build and "configuring"
the resulting package).
In any event, with RPM's you get the package (for your
plattform: x86, Alpha, SPARC, PowerPC, etc) and type:
rpm -i foo-$VERSION.$PLATFORM.rpm
... or whatever the file's name is. To upgrade a
source package you follow mostly the same procedure for
sources (usually saving any configuration files and/or
data from the previous versions, and maybe moving or
renaming all of the old libs and bins and other files).
It would be nice if source package maintainers make
upgrades easier by detecting their prior installed version
and suggesting a "make upgrade" command --- or something
like that).
To upgrade a typical RPM you just type:
rpm -U foo.....rpm
There are similar commands for Debian, but I don't know
them off the top of my head and they aren't handy to
look up from this S.u.S.E. (RPM) system.
(I'm sure I'll get flamed for the perceived slight ---
oh well. Comes with the territory. Please include
techie info and examples with the flames).
Now, when it comes to major system upgrades (like
libc5
to glibc, and from a 1.x kernel to a 2.x kernel) it's a
different matter.
If you have a libc5 system and you just install glibc
unto it; there's no real problem. The two will co-exist.
All of your existing libc5 programs will continue to load
their shared libraries, and all your glibc2 (a.k.a. libc6)
linked programs should find the new library. Running a
mixture of "typical" programs from both libraries will
have not important effects (although you'll be using more
memory than you would if all you binaries are linked
against the same libraries.
Notice I said "typical" --- when it comes to system
utilities, like the 'login' command there are some
interactions that are significant and even incompatible.
I've heard that the format of the "utmp" and "wtmp"
records are different (these are user and "who" log
files) which are accessed by a whole suite of different
utilities (like the 'who' and 'w' commands, the 'login'
and 'xdm' commands, 'screen' and other utilities).
So, it's best to upgrade the whole system to glibc
at once. (The occasional application, one that is not
part of the base "system" and isn't "low level" that
uses a different version/set of libraries won't be a
problem).
With most recent kernels you can install the sources
under /usr/src/linux and running the following command:
make menuconfig
(go through a long list of options to customize the
kernel to your system and preferences)... or copy
in your old .config file and type:
make oldconfig
... to focus on just the differences between the
options listed/chosen for your previous kernel and
the new one.
Then you'd type something like:
make clean dep install modules modules_install
... and wait awhile.
I've done kernel upgrades that were that easy. Usually
I read the "changelog" and other text files, and the
help screens on most of the new options (I usually also
have to refresh my memory on a couple dozen old options).
These are major upgrades because they can affect the
operation of your whole system.
Recently my father (studying Mathematica) needed a better
video card. This was an old VLB (VESA Local Bus) 486
running Red Hat 4.1. So I decided to build a new system
(Pentium 166, PCI video card, new 6Gb UDMA hard disk)
and upgrade his system to Red Hat 5.1.
So, here's how I did that:
Build new hardware, boot from a customized copy of Tom
Oehser's "root/boot" diskette (http://www.toms.net/rb)
and connect to the LAN using a temporary IP address that
we have reserved for this purpose.
I then run fdisk on the new drive and issue a command
like:
for i in 1 3 5 6 7; do mk2efs -c /dev/hda$i; done
(to make filesystems all all of the partitions, root,
rescue root, /usr, /home and /usr/local). I go away
and answer e-mail and get some coffee, getting thoroughly
side tracked.
A day or so later I remember to finish work on that (he
reminds me that he has some homework to do).
Now I mount all of these filesystems they way I want
them to be later (when I reboot from the hard disk).
So I mount the new rootfs under /mnt/den (the machine's
name is Deneb --- an obscure star) and the new usr
under /mnt/den/usr and the new /usr/local under
/mnt/den/usr/local (etc).
Then I copy his old /etc/passwd and
/etc/group file
into the ram disk (see below) and issue a command
like the following:
rsh deneb "cd / && find . | cpio -o0BH crc " \
| ( cd /mnt/den && cpio -ivumd )
... this copies his entire existing system to the new
system.
When that's done (doesn't take long, but I don't time it
--- it runs unattended until I get back to it), I
edit the /mnt/den/etc/fstab, run a chroot command
(cd /mnt/den && chroot . /bin/sh) fix up the
lilo.conf
file and run /sbin/lilo, and reboot (with the root/boot
diskette removed.
Now I've replicated his whole system (and accidently
knocked his off of our LAN because I forgot to reset
the IP address of this box). So, I fix that.
I make a last check to make sure that everything *really*
did copy over like I wanted:
cd / ; rsh den " cd / && tar cf - . " | tar df -
... this copies all of his file back over the net
again (this time using 'tar' instead of cpio), but the
receiving copy just compares (diffs) the incoming file
"archive" (from it's standard input, a.k.a. the pipelined
data) rather than extracting them and writing them into
place.
This reports a few differences among some log files,
the /etc/ files that I modified, and it gives some errors
about "sockets" (Unix domain sockets show up in your
file tree as little filenames with the "s" as the
leading characters in an 'ls -l' output; there are
about five or six of these on a typical system, one for
your printer, one for you syslog and one or two for any
copies of X Windows or 'screen' you may have run. These
should not be confused with "internet domain" sockets
which only exist in memory and go through your IP interfaces).
I presume that the tar diff feature simply doesn't support
Unix domain sockets, it's probably a bug, but not a
significant one to me.
A different bug in 'cpio' is a bit irritating and I have
to report it to their maintainer. Remember how I copied over
my old passwd and group files before the transfer? There's
*supposed* to be an option to "use the numeric UID and GID"
(-n or --numeric-uid-gid) in 'cpio' (and a similar one in
newer versions of 'tar'). However, my copies (on several
machines from several distributions around the house) all
just give an error if I try to use that switch. Not a
reasonable error message like: "option not supported"
or "don't do that you moron" --- just a stubborn insistence
on printing the "usage" summary which clearly shows these
options as available!
The quickest workaround is to just copy of the passwd
and group files to the local system before attempting
the "restore" (replication). One time when I failed to
do this (using a version of 'tar' that didn't support the
feature) it squashed the ownership of every file to
'root' --- resulting in a useless system. Luckilly I was
just playing around that other time, so I learned to
watch out for that.
So, now I just slip in my Red Hat 5.1 CD (courtesy of the
IBM booth at last week's ISPCon in San Jose --- where they
were giving them out). I think IBM's booth got them from
the BALUG (Bay Area Linux Users Group) which is still trying
to scrape up a few hundred bucks to pay for the 'free' booth
they were offered. (Free means no fees to the convention
co-ordinators; we went out of pocket for "renting" tables
and chairs and paying for a power extension for the demo
computer).
From there I just let the RH 5.1 upgrade process run its
course.
What!?! All that work just to let run the upgrade?
Yep!
I spent years in technical support (MS-DOS and Windows
markets). I consider vendor and OS upgrades to be the most
dangerous thing you can do on your computer. I'm sure
they've caused more downtime and lost data than failed
hard drives, virus infections, stupid users (other than
the stupidity of blind updates), and disgruntled employees.
So, I like to make sure that I can get back to where I
started. For me, that means "start with a copy of the
system or a restore of the system's backups" I've been
known to take a hard drive out of a system, install a
new one, restore the backup to that and then to the
restore to the "new" system. (The old hard drive stays
on a shelf until the data on it is so out of date it
would be worth copying back in --- then gets rolled into
some other system, or the same one, as "extra disk space").
Now, please don't take this as a personal attack on Linux
or Red Hat. So far they haven't failed me. I have yet to
see an "upgrade" destroy one of my systems. However, my
professional experience as proven to me that this is
the right approach even for one of my home systems.
In this case the upgrade was silky smooth. I had to
fuss a little to get in a new X server (different
video card, remember) and the new system really didn't
like the PS/2 mouse that I have it (which was of
no consequence, since my father uses a serial port
trackball, so the mouse that I had in /dev/psaux was
just a temporary one anyway).
Oh, yeah, I had to compile a new kernel to support
the ethernet card I'm using (a Tulip based Netgear).
There was probably a module laying around the CD
for it somewhere --- but so what. It's a good
test for the system.
At this point the old computer sitting in the living
room, and the new one is in his room running Mathematica.
In a week or so (when we're really convinced that everything
is really O.K with the new box) I'll prep that old 486
up as a server (my colocated server is do for an upgrade
--- so this one will go in for it, and that one will become
the spare and test bed).
I can understand how most users don't want to have whole
systems around as spares. However, these days, it's
not too expensive to keep an extra 6Gb hard drive laying
around for these sorts of "major" upgrades. It's also
a good way to insure that your backups are working (if
you use the "restore" method rather than a network
"replication" trick).
Note that this whole process, as complicated as it
sounds, only takes a little more "human" time than
just slipping in the CD and doing it blindly. The
system keeps pretty busy --- but I don't wait for it,
I only issued 10 commands are so (I have a couple of
scripts for "tardiff" and "replicate" to save some
of the typing).
For the daring you can run a program called
'rpmwatch'
(or Red Hat or other RPM based systems) or "autoup.sh"
(Debian). You point these at your favorite mirror and
they will automatically update new packages.
Of course this is "daring" --- I personally wouldn't
consider it from any public mirror site. I have
recommended it to corporate customers, where they
point their client systems at an internal server and
their staff posts rpm's after testing (limited automated
deployment). This is a little easier for some sorts
of upgrades than using 'rdist' and home brewed scripts.
In terms of upgrades --- my main "gateway" (router,
server, mailhost, uucp hub, and internal web server) is
an old 386/33 --- it's about a decade old, has 32Mb
of RAM and single, full SCSI chain with a few Gig of disk
space). It runs an old copy of RH 4.2, which is an upgrade
(disk replication/swap method) from 3.03, which is an
upgrade from Slackware 1.(something), which was an upgrade
(wipe and re-install from scratch) from SLS something
(running a 0.99p10 kernel).
I used to use that machine (antares) for everything
(even X --- it has a 2mb STB Powergraph video card
that cost more than a new motherboard would have).
However, these days I mostly use 'canopus' -- a S.u.S.E.
5.1 upgraded to 5.3 (blindly --- I was feeling lazy!)
My wife mostly uses her workstation, 'betelgeuse' ---
which came from VA Research with some version of Red Hat
(read the review I wrote for Linux Journal if you're
really curious) --- and was upgraded (new installation
on new drive, copy the data) to S.u.S.E. 5.2.
So, you can see that we've used a variety of upgrade
strategies around the house over the years.
As for installing a new kernel. Do a good backup.
Now ask: Can I afford a bit of down time if I break
the system (while I restore it)? If the answer is
"Yes" than go get a 2.1.124 (or later) kernel and try
that. We're getting really close to 2.2 and only
a few thousand people have tried the new kernels. So
we want lots of people to at least try the current
releases before we finally go to 2.2.
(Linus doesn't want to have 36 "fix" releases to
the next kernel series).
The new kernel should be much faster in TCP/IP performance
(already one of the fastest on the platform) and much, much
faster in filesystem performance (using the new dcache
system).
So, try the new kernel. Be sure to get a new copy of pppd
if you use that --- the kernel does change some structure
or interface that the old version trips on.
This upgrade will not be nearly as big a deal as the
1.2 to 2.0 shift (which was the most disruptive in the
history of Linux as far as I can tell --- the formats
of entries under /proc changed, so it broke the whole
procps suite of utilities, like the 'ps' and 'top'
commands). I haven't seen any such problems from the
2.0 to 2.1 kernels (I'm running a 2.1.123 at the
moment, on canopus. antares is running on 2.0.33 or so
--- it is least frequently upgraded because it is the
server.
Looking forward to your answer.
Frits.
Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 34 November 1998
![[ Table Of Contents ]](../../gx/indexnew.gif)
![[ Front Page ]](../../gx/homenew.gif)
![[ Previous Section ]](../../gx/back2.gif)
![[ Next Section ]](../../gx/fwd.gif)
|
![[ Answer Guy Index ]](../../gx/dennis/answernew.gif)
