Bug 4293 - ftp.redhat.com oscillating between 2 different versions of rawhide
ftp.redhat.com oscillating between 2 different versions of rawhide
Status: CLOSED WONTFIX
Product: Red Hat Raw Hide
Classification: Retired
Component: ncftp (Show other bugs)
1.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-31 18:15 EDT by dunwoody
Modified: 2014-03-16 22:09 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-08-02 11:17:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description dunwoody 1999-07-31 18:15:19 EDT
I don't believe this is a problem with ncftp itself (I'm
running ncftp-3.0beta9-1), but rather with the
ftp.redhat.com site.

I have a script that uses ncftpls and ncftpget to grab the
latest files
from ftp.redhat.com/rawhide/i386/RedHat/RPMS.  I have
been using this script successfully for quite a while, but
it failed today.  I ran the
script several times this morning, using two different ISPs
(TCI@Home and SGI).  With each ISP, my first run of the
script accessed what appeared to be an up-to-date version of
ftp.redhat.com/rawhide/i386/RedHat/RPMS, but when the script
attempted to retrieve some of the files, ncftpget returned
error 3 (transfer failed) on about half of the files  The
other half of the files were retrieved successfully.  The
transfer failures occurred in an alternating pattern -- if
one transfer succeeded, the next one would fail, and the
next one would succeed, etc.

With each ISP that I tried, subsequent runs of my script
after the first accessed what appeared to be an out-of-date
version of ftp.redhat.com/rawhide/i386/RPMS.  Most of the
packages appeared in older versions; e.g. on the first run
ncftpget picked up kernel-2.2.10-3, but on subsequent runs
ncftpget picked up kernel-2.2.5-25.  When I tried ncftp in
interactive mode and did an ls, I saw the older versions.

Perhaps there is some sort of route-flapping going on
between multiple ftp.redhat.com servers, or a load
balancing mechanism that is selecting between multiple
servers that aren't in sync with each other?

For completeness, here is the script:

#!/bin/bash
buildtime() {
    rpm -q --queryformat '%{BUILDTIME}' $*
}
rpmget() {
    echo -n "opening ftp://$1/: "
    files=$(ncftpls ftp://$1/); ret=$?
    if [ $ret -ne 0 ]; then
        echo ERROR ncftpls returned $ret
        return
    fi
    echo ok
    for file in $files; do
        echo -n "$file: "
        pkg=${file%-*-*}
        pkgver=${file%.*.rpm}
        if [ ${file##*.} != rpm ]; then
            echo skipping
        elif ! eval rpm -q $pkg &> /dev/null; then
            echo pkg not installed
        elif eval rpm -q $pkgver &> /dev/null; then
            echo pkg already installed
        elif [ -f ./$file -o -f ../krpm/$file -o -f
../orpm/$file ]; then
            echo already downloaded
        else
            oldfile=
            for f in ./$pkg-[0-9]* ../krpm/$pkg-[0-9]*; do
                fp=${f##*/};fp=${fp%-*-*}
                if [ -f $f -a $fp = $pkg ]; then
                    oldfile=$f
                    break
                fi
            done
            ncftpget ftp://$1/$file &> /dev/null; ret=$?
            if [ $ret -ne 0 ]; then
                echo ERROR ncftpget returned $ret
            elif ! eval rpm -K --nopgp $file &> /dev/null;
then
                echo ERROR checksig failed
                rm -f $file
            elif [ $(buildtime -p $file) -lt $(buildtime
$pkg) ]; then
                echo older version
mv $file ../orpm
            else
                echo NEW
                if [ ${pkg%%-*} = kernel ]; then
                    mv $file ../krpm
                fi
                if [ -f ./$oldfile ]; then mv $oldfile
../orpm; fi
            fi
        fi
    done
}
cd /1/pkg/rpm
{
    rpmget ftp.falsehope.com/pub/Mesa/rh6.0
    rpmget ftp.falsehope.com/pub/socks5
    rpmget ftp.redhat.com/rawhide/i386/RedHat/RPMS
    rpmget ftp.redhat.com/rawhide/powertools/i386
    rpmget ftp.redhat.com/redhat/updates/6.0/i386
} 2>&1 | tee /1/pkg/getrpm.log
Comment 1 Jeff Johnson 1999-07-31 19:10:59 EDT
There have been recent rearrangements of ftp.redhat.com. These
problems should be fixed now.
Comment 2 dunwoody 1999-07-31 20:19:59 EDT
This problem appears to me to be still unresolved.  I am continuing
to see the same behavior.  I'm seeing two seemingly separate problems:

- two competing versions of ftp.redhat.com/rawhide/i386/RedHat/RPMS.
  One version (call it A) seems to have the latest versions of
  everything except wmmon, which is at 1.0b2-3.  The other version
  (call it B) seems to have out-of-date versions of most things,
  except wmmon which is at 1.0b2-4.  I've been running my script
  repeatedly, and sometimes I get A; sometimes I get B.

- My script invokes ncftpget repeatedly.  Odd-numbered invocations
  (1, 3, 5...) fail with error 3 (transfer failed), and
  even-numbered invocations (2, 4, 6) succeed.  I added a workaround
  to my script -- if ncftpget fails, the script just tries again.
  This works, but the underlying problem remains.  This is a new
  problem; the last time I ran my script (about 2 weeks ago),
  using the same system configuration (including ncftp-3.0beta19-1)
  everything was fine.  I tried fiddling with the ncftpget timeout and
  redial options, but didn't find a way to eliminate the failures.

-Craig Dunwoody dunwoody@sgi.com
Comment 3 dunwoody 1999-08-02 07:34:59 EDT
I'm not seeing this problem now, so I'll be optimistic and assume it's
gone for good.  I'd like to re-close this bug myself to save you the
trouble, but if there's a way for me to do that I don't know what it
is (possible bugzilla RFE?).  Thanks very much for the quick response
on these bug reports -- impressive!
Comment 4 Bill Nottingham 1999-08-02 11:17:59 EDT
ftp.redhat.com is aliased to two separate machines. Hence, if
one has the updated files and one doesn't (this could happen
if you're trying to download while the machines are syncing,
for example), weird things can happen. I'm not sure there's much
we can do about this, though.

Note You need to log in before you can comment on or make changes to this bug.