Here are a few thoughts on the F8 release, from the mirror manager perspective. :-)
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.
Thanks, Matt Fedora Mirror Wrangler
Matt Domsch wrote:
Here are a few thoughts on the F8 release, from the mirror manager perspective. :-)
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?
Additionally, we need to flip the bit before we release it on the website.
-Mike
On Nov 8, 2007 11:31 AM, Matt Domsch Matt_Domsch@dell.com wrote:
Here are a few thoughts on the F8 release, from the mirror manager perspective. :-)
As a very very former mirror manager, I wanted to say that Fedora has done a heck of a job on getting this working and this was very painless compared to a long time ago.
I want to say that the BIGGEST WIN is that by using a community model of getting software together, hardware requirements, and various tracking software Fedora was able to get a trust model working between the masters and tier 1/tier2 etc mirrors that was hard if not impossible a long time ago.
Thanks.
Matt Domsch wrote:
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.
I disagree. This is typically a server setup issue, not a permission issue. If vsftpd serves such files, it means it has the right to access the directory (so it is run with the same UID than rsync or it is in the same group). If the files are group readable, then technically, vsftpd has the right to read them just like it has the right to access the directories path. Doing 0640 on files will block vsftpd access if and only if the admin has enabled anon_world_readable_only.
I would advocate for a release root-only bitfliped to get updates as simple as possible. As admins are usually asked to schedule a atjob to run a rsync/chmod at release date/time, KISS... ;-)
If you really want to avoid leaks, then perhaps you should test mirrors with a special directory to reproduce usual release rights and check from time to time if this directory contents are unreadable.
François
infrastructure@lists.fedoraproject.org
-
Francois Petillon -
Matt Domsch -
Mike McGrath -
Stephen John Smoogen