[Yum] modified date of header.info

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


 



[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux