One of the takeaway items from the meeting on thursday was the need to rebuild
all boxes that are currently running FC-6 before FC-6 is EOL'd
Right now we know we need to rebuild the buildsystem. which includes all
builders and the koji hub. Some of the app servers need rebuilding.
We need to test the applications running on FC-6 on their new platform wether
it is RHEL5 or F-8
right now i would like to do the buildsystem on the weekend of Dec 1-2.
Volunteers to help would be appreciated as well as identifying what else
needs migration and testing
Once again, the checksums match up when they hit /mnt/koji/mash/updates,
but from there they get synced out to our mirrors corrupted.
We may be experiencing some corruption on the master mirror, but I don't
believe I have the access to verify.
Just a quick thought after tonight's outage.
If *everything* is down, the most important thing to have up is the
mirrormanager since all of our users depend on it on a regular basis.
It might be a relatively easy thing to periodically replicate the entire
mirrormanager database over to an external box (like @ serverbeach) so
we can repoint DNS and bring it back online at moment's notice.
Just a thought.
>From the "d'oh!" category: I tend to go reflexively to
torrents.fedoraproject.org rather than torrent.fp.o, always resulting
in a momentary twinge of panic when I get the "server not found"
Any chance we can setup a "torrents" subdomain and just have it
redirect (dns alias, apache, whatever) to torrent?
My brain would appreciate it :)
Ex astris, scientia
Here are a few thoughts on the F8 release, from the mirror manager
Handoff from rel-eng to IS to put on masters worked great, all the
bits were landed by Monday morning.
Content on the masters wasn't hardlinked at first, which caused some
churn and unnecessary downloading. A tree that was hardlinked from rawhide,
carrying only i386 and x86_64, would have downloaded only 12GB instead
of 109GB for the full unhardlinked tree. Let's be sure the tree is hardlinked.
Permissions on dirs/files on the mirror should be revisited.
All directories should be 0750 and files should be 0640 before the
bitflip, to prevent leaks. vsftpd will serve a file with a known name
and perms 0644 even if the directory or one above it is 0750. Apache
won't. Let's be sure to use these permissions.
Release day bitflip was 30 minutes later than expected, which caused
churn for our mirroradmins. Can this be a scheduled cronjob?
I'd like a way to be notified automatically when changes, such as the
bitflip or content landing, has actually been snapmirrored
everywhere. After this message is received, I'd then like to be able to
send email to the mirror admins. Is this possible?
all in all it's been smooth, just a few hiccups.
Fedora Mirror Wrangler
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux
As most are probably aware, we are hitting a bug in the yum depsolver
when trying to mash dist-f7-updates-testing. Tim Lauridsen wrote a
patch that seems to fix the problem and allows us to compose
updates-testing again (WOOOOOOOO!).
Tim sent the patch to yum-devel for review, but in the mean time I'd be
happy to apply this to the yum on releng1 so we can get these repos
back under testing. What do you guys think?
We've got a bad drive on app4, this box is scheduled to be removed soon
but hasn't been yet and, is not under warranty. I consider this to be
of emergency in importance, and I will be finding a different location
to build app4 immediately. Getting the new app server up is of medium
risk but not having it up for tomorrow is of HIGH risk as it would cause
all mirror traffic to go through app3, and only app3.
I had to make a last-minute change to syncStatic.sh - the counter image
said "1 days" instead of "1 day." Since I had frozen it to a single
commit, it'll just wget the updated image from fedorapeople.org-
of course, I'll remove this before pushing the F8 site.
Next time, I'll branch fedora-web instead of locking to a commit to make
these sorts of changes much easier.