[log in to unmask] wrote:
> Dear all,
> 
> I support dCache a HEP storage management product and on our wiki pages
> we recommend that people use your repositories for yum updates.
> 
> I also have deployment testing scripts, which also break often with
> this error and since I don't change the settings I know the error is at
> least on many occasions server side. Today I one of my customers
> reported.
> 
> yum update
>         Repository sl-errata is listed more than once in the
> configuration Repository sl-base is listed more than once in the
> configuration Loading "kernel-module" plugin
>         Setting up Update Process
>         Setting up repositories
>         glite31                   100% |=========================|  951
> B    00:00
> ftp://ftp.scientificlinux.org/linux/scientific/44/SL/RPMS/repodata/repomd.xml:
> [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror.
> Cannot open/read repomd.xml file for repository: sl-base failure:
> repodata/repomd.xml from sl-base: [Errno 256] No more mirrors to try.
> Error: failure: repodata/repomd.xml from sl-base: [Errno 256] No more
> mirrors to try.
> 
> The problem I suspect is caused by the SL repository indexes being
> updated on line.
> 
> For the dCache yum repository I do this off line then rsync the
> information to my distribution servers. With this setup I have been
> unable to replicate this issue and non of my clients have ever
> complained of my repositories since we started with this policy. Glite
> and sl4 repositories get almost equal complaints but I suspect they
> deploy more updates per day and this maybe why I don't get them.
> 
> I don't know how you manage the master SL repositories (maybe you also
> use rsync too) but some way to remove the occasional.
> 
> IOError: HTTP Error 404
> 
> Would make life better for me.
> 
> Regards
> 
> Owen

Hi Owen,
I have three questions, and a couple suggestions

First - Why do you use the main ftp.scientificlinux.org repository?  I know 
that desy has their own repository, and that it's updated several times a day. 
  I would think that connecting to a mirror that is much closer would give you 
better response times, and possibly cut down on these errors.

Seond - It shows that both sl-base and sl-errata are listed more than once.  Do 
you have both yum-conf and yum-conf-4x installed?  Or what is the deal with that?

Third - What do you suggest?

As for ways to fix the http errors, I do have a couple of suggestions, but they 
all involve some effort on your part, and some on mine.

First - Put another line in your repo's.  At the very least, if you want to 
connect the the main repo, put in a line to http://ftp.scientificlinux.org/ and 
then ftp://ftp.scientificlinux.org/.
http works better with yum, and is the reason that all the recent yum-conf's 
originally point to http.  We found out that yum (actually python's geturl) 
does some odd stuff with ftp protocols.

Second - Next time you get this error, let me know.  Tell me when (down to the 
second if possible, we get several hundred hits a second usually) and from what 
IP address.  I'll look through the server logs, and maybe something will show up.

Thanks
Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________