Thank you to the several people who have put their data into
mirrormanager https://admin.fedoraproject.org/mirrormanager/ already.
I've made a few tweaks in the past week to speed up the queries, and
it seems to be working pretty well.
I ask everyone to please enter their data into mirrormanager now, so
we can shake out any additional bugs before F7 Test 4 is ready to go
In particular, please create:
* an account in the Fedora Account System if you haven't already
* a new Site
* a new Host in your Site
* a new ACL IP for your Host (DNS name preferred, IP ok too)
* two new Category entries, one for Fedora Core, and one for Fedora
* For each of FC and FE, one or more URLs by which end users can get
at your data (HTTP, FTP, and rsync).
With that in place, the http/ftp crawler will come by every 6 hours or
so looking at what you're carrying. Each Category page in the web UI
will show the list of directories you have it thinks are up-to-date.
displays all the active mirrors. This page (and its children - the
per-version, per-arch subselect pages) will get exported static soon
which is what we'll publicize end users to view. Likewise the yum
mirrorlist redirectors are available for playing with with a URL of
e.g. the same as the normal mirrorlist syntax, just a change in the
host. The lists are being exported as static files every few hours
also, so the standard mirrorlist CGI can use it unchanged, but as
Infrastructure is moving that particular CGI this week, I haven't
As always, thank you for your generous support of Fedora. With your
help, this will be the smoothest Fedora release ever.
 occasionally we have authentication problems with the Fedora
Account System, but it's much rarer that it had been. If you hit it,
please just reload a few times and it'll clear.
 per-country lookups on the mirrorlist aren't quite working yet,
appending &country=XX. It will soon though...
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
As do/done people of the FedoraProject, I need to choose another tool
(more efficient than rdist ....) to manage my configurations at work.
I've read the Fedora admin ML and see that finally, you choosed the
puppet tool for config. management.
I must have missed a thread of the ML, but I don't find the major points
that made you choose puppet and not bcfg2.
Can someone give me more details on the pro/cons for instance between
these 2 projects, or the missing feature of bcfg2 from the FC
perspective ? It will be a really valuable information for me.
Thanks in advance,
A short question: Is it possible to CC: all alpha related bugs to a
mailinglist? AlphaCore team would be happy to receive notifications
about alpha-related bugs.
If this cannot be easily done. I think I can provide a (perl-)script
that queries the database and sends out a mail...
Let me know...
I don't know if the cleaning has begun but I seem to have lost my wiki
account (JohnBaer). :(
My home page is still there and everything else ....
Is the process to create a new wiki account with the same credentials as
So this thread kind of got forgotten about without any action. Here's
where it left off.
User signs up and gets account(a)fp.o and firstname.lastname(a)fp.o
accounts are unique but firstname.lastname is not. This causes
Firstname.Lastname may (and currently does) contain characters that
postfix and sendmail freak out about.
People think firstname.lastname sounds professional while
accountname(a)fp.o may not.
I'd like to move forward with removing the firstname.lastname addresses
after sending out a notification. Secondary issues aside, our current
model can't work forever and already causes some issues.
Are there any major detractors?
I've rewritten the owners.list => bugzilla script to sync from the
packagedb => bugzilla. This script relies on a new version of the
python-fedora module which has a fas email => bugzilla email mapping.
I'm attaching the old version that's in cvs so people who don't have the
module checked out from cvs can more easily take a look at the
One way we could see immediate performance gain on the wiki is to delete
old users. I would like permission from both teams to do delete all
A) aren't in the edit group
B) aren't watching any pages
Presently there's 9,900 accounts on there. Only 600 of which are
actually in the edit group. Since having an account, without edit or
watching abilities is basically useless I'd like to just get rid of
those accounts. Nothing would prevent those people from signing up
again if they chose to do so.
This is kind of a drastic measure, I realize, but I think its needed.