RE: Vote for the (probable) name of Fedora 7!
Is there an explanation of the names somewhere? What they stand for, why they are being suggested, how they compare to the previous names... -- Toivo Voll University of South Florida Academic Computing Data Network Management -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Nottingham Sent: Tuesday, May 22, 2007 21:09 To: fedora-infrastructure-list@redhat.com Subject: Vote for the (probable) name of Fedora 7! The board has sent a list of suggested names for Fedora 7 to our legal department, and they have responded with the names that have passed preliminary legal approval. Please vote for your favorite choice at: https://admin.fedoraproject.org/voting/vote.cgi The choices are 'Lee', 'Sherman', 'Nothing', 'Cylon', 'Moonshine', 'Siegfried'. You will need to log in with your Fedora account system user/password. Voting will be open until 2007-05-25 00:00:00 UTC. Thanks to Toshio Kuratomi for getting this set up. We apologize for the short voting timeframe - final legal approval can take up to five days, and we'd really like to avoid slipping solely for the name of the release. If there end up being legal issues with the name selected, the Board will decide on the name. (Who knows, could end up being Zod 2: Electric Zod-a-loo). Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Vote for the (probable) name of Fedora 7!
On Wed, 2007-05-23 at 10:41 +0300, Nicu Buculei wrote: Bill Nottingham wrote: Please vote for your favorite choice at: https://admin.fedoraproject.org/voting/vote.cgi The choices are 'Lee', 'Sherman', 'Nothing', 'Cylon', 'Moonshine', 'Siegfried'. If the voter is supposed to select no more than one name, why check boxes are used instead of radio buttons? Because we're reusing the voting application for electing people to FESCo and the other Steering Committees for this. This is one of several things that should be enhanced when we get around to rewriting the application. If anyone would like to work on that, we'd love to reimplement voting as a turbogears application with a turbogears widget that can be embedded in other web apps, historical voting records, support for multi-issue ballots, radio buttons when voting for a single choice, etc. Currently, no work has been done on this so you have a lot of freedom in choosing how to architect things. -Toshio signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Vote for the (probable) name of Fedora 7!
On Wed, 2007-05-23 at 11:10 -0500, Mike McGrath wrote: Christopher Blizzard wrote: On Wed, 2007-05-23 at 11:07 -0400, Voll, Toivo wrote: Is there an explanation of the names somewhere? What they stand for, why they are being suggested, how they compare to the previous names... It's Nothing you have to worry about. It's Moonshine I worry about :) Nothing like a drink of Moonshine. --Chris ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: report_mirror traceback
On Wed, May 23, 2007 at 11:37:22AM -0500, Matt Domsch wrote: On Wed, May 23, 2007 at 11:29:32AM -0400, Chuck Anderson wrote: I'm getting a traceback running report_mirror on my FC6 mirror system: $ ./report_mirror -o mirror-report.txt -c report_mirror.conf Traceback (most recent call last): xmlrpclib.Fault: Fault 1: 'NoneType' object has no attribute 'keys' Thanks for the report. This was a caching bug on the server side. It had updated the database, but hadn't synced that data into the DB before trying to read it in another function a moment later. I think I know how to fix it. Should be OK in a few hours. I was able to rerun the script successfully at 11:54 EDT. When should I expect the mirror cgi to start returning my mirror for my netblock? Thanks. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: report_mirror traceback
On Wed, May 23, 2007 at 11:49:51AM -0500, Matt Domsch wrote: I was able to rerun the script successfully at 11:54 EDT. When should I expect the mirror cgi to start returning my mirror for my netblock? It takes up to 2 hours to refresh all the web servers with this data. Thanks, it's working now. One other question. What is the output file used for? I noticed it is in some binary format. Do I need to keep this somewhere? Thanks. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Vote for the (probable) name of Fedora 7!
On 5/23/07, Voll, Toivo [EMAIL PROTECTED] wrote: Is there an explanation of the names somewhere? What they stand for, why they are being suggested, how they compare to the previous names... -- Zod --- All kneel to Zod Lee -- General Sherman -- General Nothing -- because nothing can follow Zod! Cylon -- Moonshine -- because moonshine can solve any problem? Siegfried -- -- Stephen J Smoogen. -- CSIRT/Linux System Administrator How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. The Merchant of Venice ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Vote for the (probable) name of Fedora 7!
Is there an explanation of the names somewhere? What they stand for, why they are being suggested, how they compare to the previous names... -- Zod --- All kneel to Zod Lee -- General Sherman -- General Nothing -- because nothing can follow Zod! Cylon -- Moonshine -- because moonshine can solve any problem? Siegfried -- Was't FC6 Zod? -- Matthew Galgoci GIS Production Operations Red Hat, Inc 919.754.3700 x44155 ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Security concerns with mirrormanager
On Tue, 2007-05-22 at 22:45 -0500, Matt Domsch wrote: On Tue, May 22, 2007 at 05:58:03PM -0600, Dax Kelson wrote: I mentioned on the list a few months back a technique for having YUM automatically use a local mirror without any configuration changes on the clients. A few people sent me emails asking for more details, so I was goaded/spurred into implementing it and have now documented the procedure in a new GURU GUIDE. Dax, very cool. Thanks for posting this. One thing I added to mirrormanager[1] was the ability for a mirror host to specify the set of IP netblocks that should use the local mirror. When a yum client hits the mirrorlist CGI, such as: http://mirrors.fedoraproject.org/mirrorlist?repo=core-6arch=i386 it looks up the client IP address in mirrormanager's database. If one or more of the hosts in that database claim that IP address as local to them, the CGI returns just those hosts. In mirrormanager, you can have private mirror sites and private mirror hosts, so they never appear on the public list of servers, but the mirrorlist CGI can still handle them. The drawback is that mirrormanager can't crawl private mirror sites (generally). So, you have to use mirrormanager's report_mirror script[2], which runs on your private mirror, to tell the mirrormanager database what content you have. With this little bit of setup, you can get much the same benefit as your setup provides. Matt, mirrormanager is very cool! For YUM to automatically find a mirror I believe the cleanest and best solution is have it be done within Yum itself. Possibly with a WPAD-like or DNS SRV technique. It should be on default. The idea of the main mirrorlist CGI having a database of local IPs and mirrors is actually a solution that I ran through mentally awhile back and came to the conclusion that security concerns and technical limitations made it unworkable. When you attach your computer to a network there is some level of implicit trust in the local network (and whoever manages it). But this is a two party relationship and doesn't involve a third party who is a random stranger on the internet. The main security concern I have with the DB of local IPs, is what is to prevent someone from listing my IP network as local to their mirror? This could be accidental via a netmask typo, or with a more sinister intent (cross your fingers that your users pay attention to gpg messages from yum). IMHO, this should not be possible. If mirrormanager intends to maintain a DB of local IPs for a mirror, then the ownership/control of the IP range *must* be strongly authenticated. It should be done securely, or not at all. Different people have different security requirements, but I believe that some people will be in for a shock and react poorly/predictably when they find out that their IP netblocks (or any portion thereof) could be redirected. The technical limitation of the DB of local IPs is that it doesn't work for organizations who run their mirrors on a RFC1918 IP and use NAT to get out to the internet. This scenario is very common. Dax Kelson Guru Labs ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: releasing torrents
On Wednesday 23 May 2007 19:27:06 seth vidal wrote: A couple of questions: 1. where should I link that page from? 2. is there a better page for docs for infrastructure in general? That's kind of ReleaseEngineering stuff. I wanted to start gathering a list of Processes that ReleaseEngineering goes though, this feels like one of them (: -- Jesse Keating Release Engineer: Fedora pgp5dD5LzLkB2.pgp Description: PGP signature ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
http://fedoraproject.org/PackageReviewStatus
I've made some changes to the scripts behind PackageReviewStatus that should make it a bit more robust in the face of errors. Feel free to ping me if any problems crop up. -Toshio signature.asc Description: This is a digitally signed message part ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
the mechanics of pushing updates
Mmm, plumbing. bodhi is heading for production soon. To push updates, what bodhi currently does is, for any update: - sign the package - copy the package to a 'staging' tree of the entirety of updates - read a static list of packages that should be multilib, act on that - run createrepo - check deps on the repo - rsync the whole repo out Older updates are cleaned by a cron script later. Advantages of this approach: - it's simple - it's easy to clean upthings that Go Wrong (just manually remove them from the repo and re-sync) Disadvantages: - multilib. In a world where we continually add new packages, this *will not scale*. So, we need at least *some* sort of better workflow. One alternative - using mash (what we're using to build rawhide.) It would go something like this: - sign the package - tag the package (for updates-testing, or updates) - run mash to create a repo of updates/updates-testing, solve it for multilib - rsync it out Advantages: - solves multilib - doesn't require continually keeping a staging tree around - depcheck is built in when solving multilib - builds on koji tags to let anyone easily query what updates are released Disadvantages: - by rebuilding the repo each time, it's going to be slow once the repo gets large - harder to clear out other strangeness - will only have one version of each updated package The last of these isn't as *big* of a concern now, as all builds will be available through the koji web site, space permitting. Other ideas for better workflow? What do the extras push scripts do? Do we want to add a modified version of mash's multilib solver into bodhi? (This is ignoring the process of rsyncing to the mirror master, which will be gross.) Bill ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: the mechanics of pushing updates
Once upon a time Thursday 24 May 2007, Bill Nottingham wrote: Mmm, plumbing. bodhi is heading for production soon. To push updates, what bodhi currently does is, for any update: - sign the package - copy the package to a 'staging' tree of the entirety of updates - read a static list of packages that should be multilib, act on that - run createrepo - check deps on the repo - rsync the whole repo out Older updates are cleaned by a cron script later. We plan on adding auto clean up to bodhi, Other ideas for better workflow? What do the extras push scripts do? Do we want to add a modified version of mash's multilib solver into bodhi? Extras keeps the last two versions for releases and last for devel. Extras multilib is all -devel packages and requires with some manual blacklisting/whitelisting we need bodhi to do update announcements etc. So i think that we need to make bodhi's multilib better. probably best to use mash for that. so we have one tool for the job Dennis ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
