[TriLUG] tested solution to openssh / full update issues

Lisa Lorenzin lorenzin at 1000plus.com
Sat Dec 22 02:08:44 EST 2001


hi kevin,

i have a spare system at home running red hat 7.0 which i had installed
from cd and then never gotten around to the project i was going to use it
for (and therefore never patched, since it's not internet-exposed), so i
decided to do a little experimentation to see what it would take to get
from where you are to a fully updated box. the following process worked
for me - the only difference is that i started out running 7.0 rather than
7.1, but that just means my starting glibc was even further from the
latest rpm than yours is. :)  the whole thing took about 2 hours.

basically, what i did was download all the 7.0 updates from redhat's site
and update them individually by hand, in small groups.  i updated all the
ones with non-glibc dependencies first, then updated glibc, then updated
the ones that depended on the new glibc.  proof that it works is that i'm
opensshed from that box to this box to send this email. :)  (and i did get
the same glibc dependency error when i tried to update openssh by itself,
before doing the full update, since my 7.0 system started in the same
state of neglect that yours is in.)

my exact process follows.  you can probably simplify it somewhat (by using
-Fvh on all the update packages, rather than identifying which packages
are already installed and doing -Uvh on those) if you're not as
anal-retentive about package archiving as i am...

in my download directory, i created 3 subdirs - installed, glibc, and
kernel.  first thing i did was move glibc*rpm into the glibc subdir and
kernel*rpm into the kernel subdir.  then i started the manual updates:

list the update RPMs beginning with a:
ls -al a*

start with the first one, see if it's already installed:
rpm -qa | grep apache

if not, skip it.  if it is, update its suite of packages:
rpm -Uvh apache*
if it updates, great.  if not...

if it lists glibc as one of its dependencies, move it into the glibc 
subdir.

if not, see what dependencies it needs.  usually they're pretty easy to
figure out from context.  if it specifies a library rather than an rpm,
use rpmfind to figure out which update has that library.  you may also
have to go back to the standard RPM if you did a custom install and
skipped a package which an update newly depends on.  once you find the
dependencies, update them all at once. 

rpm -Uvh apache* mm*.rpm expat*.rpm mod_throttle*.rpm mod_bandwidth*.rpm
mod_somethingelse*.rpm

if that also throws dependency errors, you may have to branch out and
install all the dependencies of a package it depends on, but i only had
to do that maybe 3 times in this whole process.

(and if it's being a real pain, skip it - you can always come back to it.  
i had an issue with openldap not updating because of sendmail dependencies
- i updated sendmail, but openldap still complained, so i just ended up
skipping the openldap rpms.  i tried updating them one last time after i
updated everything else, and THAT time, it worked.  maybe the moon wasn't
high enough on the first try... *wry grin*)

move on to the next one.  when you're through with the a's, move on to the
b's, c's, etc.  yes, it's tedious, but you only have to go through this
once and then you can use up2date forever after. :)

once you work all the way through the alphabet, you will have updated
everything except the kernel (which i didn't touch - that's a whole
'nother story), glibc, and the updates which depend on glibc.

at this point, you can then cd into your glibc subdir, take a deep breath, 
and update glibc.
rpm -Uvh glibc-2* glibc-common* glibc-devel*
(i didn't have glibc-profile installed, so i didn't update it.  if you 
did, tack it on there.)

then you can update everything else in the glibc directory - openssh, gdb,
and diffutils were the only packages i had that required the new glibc.

once you've done that, you will be current on everything except the 
kernel, and there's a really good kernel-upgrade howto to cover that... :)

(at this point, you should be able to delete out any other update rpms
left in your download directory, since you know that a) they weren't
installed in the original, and b) nothing new depends on them.)

if you try this and have any difficulty, feel free to let me know.  i'd be
happy to offer any advice i can, based on what i encountered...

hope all this helps.  happy holidays!

						lisa

-- 
lisa lorenzin   |   lorenzin at 1000plus.com   |   http://www.1000plus.com/lisa/
# find / -user your -name base -print0 | xargs -0 chown us




More information about the TriLUG mailing list