[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 __________________________________________________