On Thu, 2004-02-26 at 01:13 -0500, seth vidal wrote: > I think the reposed.xml file will help this somewhat b/c it will include > an internal datestamp of the files inside of it and it's really quite > small, so transferring it shouldn't put much load on things. > > Essentially we need to have a way of making sure mirrors get the > repodata dir LAST to the other actual packages. The only true fix is to make yum rugged enough realize that it is working with an out of date mirror. Ya, a timestamp within repomd.xml would help--but isn't that a pretty big file-- hence the user would have to download a pretty big chunk to realize that the mirror they are pointing yo was rolled in Oct of 1962 Maybe a one line timestamp file could be generated by the metadata create stuff. I the short term it would be a simple reliable method to determine the upToDateness of a mirror. In the medium to long term it could provide an handle for the flags Michael was talking about yesterday. GenerateMd.py (or what ever it is called) would actually need to generate two identical timestamp files; timestamp and timestamp.built. Yum would always refer to timestamp. Rsync and other maintenance operations could but would not be required to be wrapped in a simple scrip #!/bin/bash echo "go away i am busy" > timestamp rsync ... cp timestamp.built timestamp Not much complexity, yet can help solve a bunch of problems. A little more invasive would be the addition of an optional primaryurl = http://some/where to each repo section. In the sort term, primaryurl could be used to serve the latest timestamp and a mirrors.list. Maybe timestamp should be a few lines long so there is the possibility that yum could be made aware of the of the last several repobuils. Primaryurl would not server any package, rather it would be a central location for repo house keeping stuff. Thus the primaryurl server would seldom be busy. This server could also provide a handle for future security related things. A server blacklist--maybe a mirror has been serving corrupt stuff all day. It could be pulled from usage. A mirror has been maliciously serving bad packages. It also could be pulled. A securityUpDateList--This could be used to convey information to both mirror admins and the yum end users. This could be a big marketing point as well as good engineering, how often does that happen? For example if a particularly nasty security flaw has been found and fixed, That fix could be added to a securityUpDateList via a flag in generateMd. Mirrors that usually rsync every 24 hour could have a script that called securityUpDateList every 30 min and do an "emergency rsync" if necessary. Thus a normal three tier update taking 36 hours could be reduced to a few hours so when end users do their nightly updates the fixes will be ready for download. I'm not suggesting implementing these features right away;)--just that thought should go into designing the interfaces. Dave Farning
