infrastructure June 2007

infrastructure@lists.fedoraproject.org

66 participants
78 discussions

proxy server acting up
by Karsten Wade 02 Jun '07

02 Jun '07

One (or more) of the proxies, perhaps proxy1, is acting up. It is serving incorrect, old, or misplaced content to various requests. Most commonly, it seems to be serving rhold.fp.o in place of fp.o, fp.o/wiki, and docs.fp.o. Seems to have started around 1700 UTC or earlier, today 02 Jun. - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

1 0

click-through CLA for the Wiki
by Karsten Wade 02 Jun '07

02 Jun '07

Can someone help implement $SUBJECT with me? As per the layers set here: http://fedoraproject.org/wiki/KarstenWade/Drafts/CLAAcceptanceHierarchies A pure Wiki-contributor no longer needs to do the signed-GPG CLA. We can find a canonical location for that page now. Instead what is needed is for the user, when creating a new Wiki-account, read through and agree to the CLA as a click-through form. Then we can drop the ACL restriction and use of EditGroup. Hallelujah! I see two generic ways to implement: 1. Wiki-only -- no attempt is made to tie the NewAccount to an associated FAS account; we rely upon Moin Moin authentication to affirm that FooPerson has read and approved the CLA; we continue with the WikiLicense as a reminder of the obligation agreed to. 2. Tie into FAS -- the new FooPerson would get an associated FAS account and a be part of a new group 'cla_wiki'; the advantage is if we get additional Web tools that would require the click-through, we can grant access to people who have already run the gauntlet instead of making them click through again. Anyway, those are just my ideas. And you'll note that, looking at the above, there is almost nothing that I know how or have access to do, so I'm turning to y'all for a volunteer. :) - Karsten -- Karsten Wade, 108 Editor ^ Fedora Documentation Project Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProject quaid.108.redhat.com | gpg key: AD0E0C41 ////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

1 0

Docs site
by Rahul Sundaram 02 Jun '07

02 Jun '07

Hi http://docs.fedoraproject.org/release-notes which is linked from the release announcement doesn't work properly. Rahul

3 9

Wiki test
by Paulo Santos 01 Jun '07

01 Jun '07

Mike, Im getting some IOerrors in the apache logs and as such I would like to propose a set of tests in starting next week or the week afterwards. [Fri Jun 01 12:29:04 2007] [error] [client 10.8.32.56] PythonHandler MoinMoin.request::RequestModPy.run: IOError: Write failed, client closed connection. Also lots of mod_python errors in the error_log Setup the wiki in a 1 (or 2) to 1 like it was in the old days. proxy1 -> app1 proxy2 -> app1 No load balancers or anything other thing out of a normal ProxyPass. I would like to try this, so make sure that its not anything regarding the new LoadBalancer functionalities that you've added in the past weeks. It should be enough to run this test for half a day... Any comments ? Thanks, Paulo

2 1

Wiki upgraded
by Mike McGrath 01 Jun '07

01 Jun '07

I've upgraded the wiki from 1.5.7 to 1.5.8 (should fix unicode error) we do strange things with our wiki so if stuff isn't working now or doesn't look right please let me know. -Mike

2 2

Wrong mirrorlists for ppc
by Torsten Rausche 01 Jun '07

01 Jun '07

Hello! Is it intended that all mirrorlists for ppc point to ppc64 directories? The ppc64 directories only contain ppc64 and noarch packages, while the ppc directories contain ppc, noarch and also ppc64 packages. So shouldn't the mirrorlists point to the ppc directories? In the current state mirrorlists are useless for my iBook and I have to point yum to a mirror manually :( Torsten

2 3

looking to contribute to fedora
by justin randell 01 Jun '07

01 Jun '07

hi, http://fedoraproject.org/wiki/JustinRandell <-- my details i'm looking to help out with the fedora infrastructure team. a suggestion that came out of #fedora-admin was working on improving the efficiency of moinmoin (especially page save operations). i'm happy to start there, but i'm open to other suggestions. cheers justin

3 2

Fedora 7 Release (Post release day)
by Mike McGrath 01 Jun '07

01 Jun '07

Well this release went so much better then the last release. Matt has created the following page: http://fedoraproject.org/wiki/Infrastructure/F7LessonsLearned For those that don't remember last year.... It didn't go so well. Here's some issues we had this year: * Spikey load + iptables implementation broght the static pages down for a few minutes at a time at the beginning of the release (first couple of hours) This also caused some mirrors.fp.o outages - Minor issue * Wiki Load - The wiki, as always causes issues. All in all I think the wiki did ok, we never created any static pages for it (as we did last year) but we did lose app1 three times (needed to be rebooted) This also brought docs.fp.o down (see below) - Medium issue * Nagios - Just ended up creating a lot of noise. This was a known issue and is already being worked on :) This stuff will get better as we implement better service dependencies. - Known issue * Docs - This one lies on me, it went much better than last year (docs was down for close to 4 days). Unfortunately, unlike most of our apps, docs didn't get setup to load balance properly. As such all traffic was going to app1, and when moin combined with docs took app1 down, docs just died. We put a temporary site in place but it was untested and we had some display issues. We'll have this one totally corrected in no time. * Ram - This was an identified issue but not one that we had much time to fix. Seems most of the problems we had were ram related (technically swap related) There's a great deal of performance we can gain in every area by adding ram. Additionally some of our boxes are close to being out of warranty and can be replaced with 64 bit boxes. * Accounts - The accounts stuff died a bit, same issue as the wiki. Accounts is working to be replaced anyway and in the meantime the account system can be installed on more app servers (presently its only on two) Stuff that went right: * Mirrors.fp.o and smolt - Mirrors worked like a champ, so has smolt. Spread acrsoss two boxes they only required minor tweaking from matt and really just worked. This is quite an impressive feat since neither one of these apps has been under this sort of load before and we really didn't know exactly how they would work (though our initial load tests on both proved they would work fine). The public list was CRITICAL in getting users to the mirrors and it just worked. My hats off to everyone with this stuff, both of these apps are written in TurboGears. * The static pages - Boy what a difference these made. It was very nice to know we also had them on the mirrors. though never needed to use them. * #fedora-admin - For the most part stayed on topic, everyone was helpful and it was great to get all of the smart people together to test, discover what went wrong and work to fix it. * Torrent - Didn't here a word about it and AFAIK it 'just worked' amazing. * Dynamic allocation of systems. We were able to take down and add additional ram to some of our app servers as well as create a new proxy server at the temporary cost of test and build servers. now that release day is done we can just put everything back as it was. We could have done even more to help the wiki if we had more ram. App1 had 3G RAM App2 had 4G. App1 still crashed. (those are our wiki servers) * Fedora 7 Release - We had a few bumps but I'd easily call this a success. We got people to the mirrors on release day. Much better than last year, and even better still we did better then Ubuntu did on their last release :) For next time: Aside from the wiki upgrade and trying to find more efficiencies there, the big thing we need is more RAM. I'd say 95% of our issues could have been non-issues just with more RAM. Fortunately thats the easy part :) Nagios should be in good shape by next time. Thanks everyone for your hard work we've done a really good job this time out. Anyone have other comments? -Mike

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure June 2007