[TriLUG] Re: up2date

[Steve Thorpe]

> I'm not sure how many of you run RedHat's up2date, but are there any
> alternate servers to pull the updates from (while still using up2date)?
> I've been trying to update a fresh 7.2 install for over 2 hours now,
> getting about 20-25k/sec (from RedHat) which is pretty bad considering I
> have a 100Mb pipe.
>
> Jeff

Dear Jeff an other TriLUGgers,

Noticed the posting about up2date and thought I would add
my $.02 worth... personally I prefer to put the new rpms
on at my own discretion (using "rpm -Fvh" or "rpm -ivh")
so I control exactly which rpms go on there, and when.
However it was a continual drag to have to wait a LOOOONG
time to download the RPMs from the Red Hat site.  My 
solution was a home grown alternative to up2date. I wrote
a simple script which I run as a cron job prior to each 
work day, with the following cron tab entry:

01 22 * * sun,mon,tue,wed,thu /home/thorpe/bin/getLatestRPMs

For me, the nice parts about this script are:

1. Since it uses wget's --timestamping option, the rpms
   copied to my local disk have the same timestamp as
   they do on the RedHat ftp site... so I can do "ls -alt"
   to see them sorted in reverse date order

2. It only grabs NEW rpms that show up on the site, as
   long as I keep the local directory in place with any
   already downloaded rpms.  Thus it is *much* faster than 
   just doing a "wget *" (provided its run on a regular
   basis)

3. Since its automated by a cron job, I never think about
   it but just get an email every morning telling me if
   I might have some newly available rpms to consider 
   upgrading to.  If so, it gives me the command I need to 
   run to do the upgrade.  I can just copy/paste the 
   command from the email message to a shell, and perform 
   the upgrade(s).  (However if there are new kernel RPMs 
   you'd probably want to do them differently)

4. In a nutshell, I am happy because I control which rpms
   are upgraded, and when, but the script makes it so easy
   that I am almost never more than 1 business day out of
   date.  All with maybe 2-30 seconds per day of effort on
   my part.

FWIW I offer my getLatestRPMs script to anyone who is
interested.  Enjoy!

Steve Thorpe
steve_thorpe at acm.org
  
-----------------------------------------------------------------
#!/bin/tcsh -f
#
#    File: getLatestRPMs
# Purpose: updates ./updates.redhat.com/$RELEASE/en/os/i386/ with
#          latest RPMs from RedHat, mailing results to $USER
#
setenv RELEASE 7.2
setenv BASEDIR /scratch/$USER/errata
setenv SUBDIR  updates.redhat.com/$RELEASE/en/os/i386
setenv TMPFILE /tmp/getLatestRPMs.out
umask 77
mkdir -p $BASEDIR
cd $BASEDIR
rm -rf $TMPFILE                                              >& /dev/null
wget ftp://$SUBDIR -r -nv --timestamping                     >& $TMPFILE
echo " "                                                     >> $TMPFILE
echo "--------------------------------------------"          >> $TMPFILE
echo "NOTE: Any RPMs listed here are corrupted:   "          >> $TMPFILE
echo "--------------------------------------------"          >> $TMPFILE
rpm -K --nogpg $BASEDIR/$SUBDIR/*.rpm | /bin/grep -v " OK"   >> $TMPFILE
echo " "                                                     >> $TMPFILE
echo "--------------------------------------------"          >> $TMPFILE
echo "To freshen all of the RPMs from this release:"         >> $TMPFILE
echo "--------------------------------------------"          >> $TMPFILE
echo "cd $BASEDIR/$SUBDIR; rpm -Fvh *.rpm"                   >> $TMPFILE
echo " "                                                     >> $TMPFILE
echo "BUT DO NOT FORGET TO TREAT KERNEL UPGRADES WITH CARE!" >> $TMPFILE
Mail -s "getLatestRPMs `grep Downloaded $TMPFILE`" $USER     <  $TMPFILE
rm -rf $TMPFILE                                              >& /dev/null
-----------------------------------------------------------------