On 11/10/2011 02:36 AM, Jean-Michel Barbet wrote:
> Hello all,
>
> One of our colleagues is performing network installs of SL.
> He frequently observes that the install fails on downloading always the
> same package (depending on the SL version and arch) with a message
> saying that the package is not found or damaged.
>
> He has tried different mirrors with the same result. Removing the
> package from the list of packages to install result in the install
> process failing on another package. The protocol is FTP.
>
> => Anybody has similar experiences ? Solutions ?
>
> Thank you.
>
> JM
>
>
I can say from our side that, excluding the announced outages, we've 
been up.

$ ssh ftp.scientificlinux.org
$ uptime
  08:43:33 up 25 days, 18:40,  1 user,  load average: 0.49, 0.33, 0.29
$^D
$ ssh ftp1.scientificlinux.org
$ uptime
  08:44:25 up 25 days, 16:32,  1 user,  load average: 0.22, 0.17, 0.19
$^D
$ ssh ftp2.scientificlinux.org
$ uptime
  08:45:17 up 25 days, 16:33,  1 user,  load average: 0.00, 0.01, 0.00
$^D
$ ssh rsync.scientificlinux.org
$ uptime
  08:45:42 up 25 days, 18:42,  1 user,  load average: 1.21, 1.09, 0.82
$^D

As an aside, our experience internally has been that FTP is a bit more 
chatty than HTTP for installs.  It seems that Anaconda sometimes likes 
to traverse each piece of the install path (ie open 
ftp.scientificlinux.org ; cd /linux ; cd scientific ; cd 6x ; cd i386 ; 
cd os ; cd Packages ; get foo.rpm; close ; open ftp.scientificlinux.org 
; cd /linux ..... and so on).  If you have some sort of caching proxy, 
perhaps it doesn't like this behavior.  Is HTTP an option for your 
installs?  Do you have the space for a local, private, mirror?[1]  As of 
5 minutes ago SL6x is just shy of 41G (a hefty download to say the 
least), but that includes all archive, source, and iso files.

Pat

[1] http://www.scientificlinux.org/download/mirroring/

-- 
Pat Riehecky
Scientific Linux Developer