I've been working on getting jigdo usable for Fedora Unity. In the
process, I needed a way to have a single url to access rpms on public
mirrors. Assume the requested file is foo.rpm What I have done so far is
setup a rewrite map that does the following:
* Pull the mirrorlist while preserving the requesting IP as
X-Fowarded-For (for geoIP)
* Parse the mirrorlist
* Random loop the mirrorlist and request the HEAD for foo.rpm from a
given mirror, if not 404 continue
* Redirect the request for foo.rpm to a public mirror (using 302)
that has verified it has the file
Things I plan on doing:
* Cache results (assuming no DB backend, do RAM caching based on
session; IP, remote mirror, etc)
* Maybe rate public mirrors based on:
o Number of missing files (404)
o Latency (granted this is from the rewrite server)
o Bitrate test (ran every hour or something, also from the
* Setup a database that can be prepopulated with this data,
potentially using data from mirrormanager
If needed, round robin would help keep things going.. or even just use
pound (or something else) between two machines.
Any thoughts? I'd like to have Fedora Project to provide this feature.
If not, I will be setting it up anyways.
I spent a little bit of time today getting gitweb going for
git.fedoraproject.org since if people are using git, they almost
certainly want to have gitweb available. In doing so, I needed to
update git on the server to 126.96.36.199 instead of the 1.3.3 that was
present before. If anyone hears of any problems, shout.
I've also updated the instructions on setting up a git repository to
include the step for adding the repo to gitweb. Should be pretty
straightforward (add a line to /var/www/html/gitweb/index)
On Sat, 2007-01-13 at 19:42 +0200, Ahmed Kamal wrote:
> not sure I understand your question, but they way things should go is,
> the client downloads the drpm, client side code combines client side
> files from older rpm + the drpm into a new rpm. Then that new rpm is
> installed. The required bandwidth should drop to 20%, the numbers need
> some testing ofcourse, but I can imagine such savings.
SuSE did a lot of work on distributing the files as less than a whole
rpm. Their original tool works as you say, with an "rpm patch file"
that combines with an rpm on the client's system which is then
installed. The newer tool that they were pushing a couple years ago was
also able to upgrade files on the filesystem rather than going through
the intermediate step of creating an rpm. I consider this method to be
less desirable from a security standpoint than the first.
To better enable co-maintainership, the format of owners.list is going
to change slightly on Monday, February 18th, at 3PM EST (2000 UTC), give
or take a few minutes.
The change is that the 'initialowner' field will now be a comma-separated
list of maintainers. The first e-mail address listed will be the 'primary'
maintainer listed as the owner in bugzilla; all other address will be
Hence, if you currently have co-maintainers listed in initialcclist,
you'll want them moved to the owner field. Feel free to notify
cvsadmin-members(a)fedoraproject.org, or set the review bug to fedora-cvs?
in bugzilla, and we'll get this taken care of.
So the puppet prototype is up and working with proxy1 and proxy2. I'm
currently getting more configs on those boxes (like global configs, ntp,
smtp, etc) I'd encourage all that have access to login to lockbox and
poke around. Adding files is pretty easy and we have total control over
it. Editing and deploying files is easier than ever. Basically edit
your config file and restart puppet on the remote server or just wait
for the next check. We're moving to a service centric management model
instead of host centric. In the old system it wasn't obvious what files
were related to what other files, the fedora accounts system is a good
example. In the new system there will be one manifest file for the
Fedora Account System. This manifest will define the proxy configs,
application configs, client configs (nsswitch, cronjobs, etc) and the db
configs. This way it will be very easy to see exactly what the Fedora
Account System consists of. We can also define "requires" for the
config files so that nagios config files require nagios to be installed
on that box. Here's the wiki link:
When we announced the FC6 statistics milestone of a million users, it
was described as the amount of downloads in many places. This widespread
confusion even internally in Red Hat is probably many software projects
like say Firefox usually advertise their download rates. One way to
avoid this is provide both download and user estimates except that we
dont really have download numbers.
We could ask each of the mirrors to send us the data but that is a bit
tedious and mirrors might not participate. A better way might be a
mirror list designed to allow us to keep tab of the downloads. sf.net
for example has a web page that is not a static list of mirrors but a
web page with a round robin system. We could do something like that or
geo ip based page which suggests the mirrors near to them. I dont think
we would be able to know partial downloads with this but it allows us a
more accurate estimate of much of these downloads actually translate
into users. Comments?