infrastructure November 2008

infrastructure@lists.fedoraproject.org

46 participants
71 discussions

log1 and nagios cron alerts
by Jon Stanley 08 Nov '08

08 Nov '08

This should prevent us from executing the same awstats analysis at the same time, thereby eliminating the nagios alerts for crond on log1. Since I'm not in sysadmin-web, I don't feel real comfortable deploying this without someone telling me it's OK and that it looks sane :) diff --git a/modules/awstats/templates/awstats.cron.erb b/modules/awstats/templates/awstats.cron.erb index 7e41be0..7ea507b 100755 --- a/modules/awstats/templates/awstats.cron.erb +++ b/modules/awstats/templates/awstats.cron.erb @@ -1,6 +1,12 @@ #!/bin/bash # <%= name %> + +if [ -e /var/run/<%=name>.awstats.lock ] ; do + exit 1 +fi + +touch /var/run/<%= name%>.awstats.lock mkdir -p /srv/web/awstats/<%= name %> /usr/share/awstats/tools/awstats_buildstaticpages.pl \

2 2

Failed fas upgrade
by Toshio Kuratomi 07 Nov '08

07 Nov '08

I tried to upgrade our fas instance tonight and failed. There's something wrong with fasClient in 0.8.4.6+ and groups. I've downgraded the fas-Client package to 0.8.4.5 on the servers and removed the fas-client-0.8.4.6 and 0.8.4.7 packages from the infrastructure repo (they're in my home directory in case someone wants to run diff and figure out where the problem lies). The I left the fas servers running 0.8.4.6 for the moment. -Toshio

1 0

Freeze reminder
by Mike McGrath 06 Nov '08

06 Nov '08

Just a reminder the final "full freeze" starts on November 11th. That means we've got a week to get any changes we want in and ready. -Mike

7 10

Re: ** PROBLEM alert - cvs1.fedora.phx.redhat.com/Puppet is CRITICAL **
by Jon Stanley 06 Nov '08

06 Nov '08

I silenced this in nagios, it's expected as part of the mass branching. Actually I silenced all services on cvs1. I'll re-enable when the branching is complete. On Thu, Nov 6, 2008 at 10:25 PM, Nagios Monitoring User <nagios(a)fedoraproject.org> wrote: > ***** Nagios ***** > > Notification Type: PROBLEM > > Service: Puppet > Host: cvs1.fedora.phx.redhat.com > Address: cvs1.fedora.phx.redhat.com > State: CRITICAL > > Date/Time: Fri Nov 7 03:25:45 UTC 2008 > > Additional Info: > > PROCS CRITICAL: 0 processes with args /usr/bin/ruby /usr/sbin/puppetd, UID = 0 (root) > -- Jon Stanley Fedora Bug Wrangler jstanley(a)fedoraproject.org

1 0

Meeting Log - 2008-11-06
by Ricky Zhou 06 Nov '08

06 Nov '08

21:02 * ValHolla walks in 21:02 -!- sonar_logger3 [n=Who(a)adsl-074-171-066-196.sip.aby.bellsouth.net] has joined #fedora-meeting 21:03 < dgilmore> Everyone Ready ? 21:03 * ricky is half-here 21:03 -!- Sonar_Gal [n=Andrea@fedora/SonarGal] has joined #fedora-meeting 21:03 -!- dgilmore changed the topic of #fedora-meeting to: Fedora Infrastructure Meeting 21:04 -!- Evil_Sonar_Chick [n=Andrea@fedora/SonarGal] has quit Read error: 60 (Operation timed out) 21:04 < abadger1999> hey 21:05 -!- inode0 [n=inode0@fedora/inode0] has left #fedora-meeting [] 21:05 < dgilmore> .tiny https://fedorahosted.org/fedora-infrastructure/query?status=new&status=assi… 21:05 < zodbot> dgilmore: http://tinyurl.com/2hyyz6 21:05 < dgilmore> lets start with tickets 21:06 < dgilmore> we have one .ticket 740 21:06 < dgilmore> .ticket 740 21:06 < zodbot> dgilmore: #740 (Loaning out system time to OLPC participants) - Fedora Infrastructure - Trac - https://fedorahosted.org/fedora-infrastructure/ticket/740 21:06 < dgilmore> and there really is not much to say on that right now 21:06 < dgilmore> well really nothing more to add right now 21:06 < dgilmore> I have one thing i want to go over 21:07 < dgilmore> Ive been working on koji2 21:07 < dgilmore> we have a request to have koji1 and koji2 load balanced 21:07 -!- ianweller_afk is now known as ianweller 21:07 < dgilmore> in the mean time koji2 is up 21:07 < dgilmore> and the builders are using it 21:07 < dgilmore> I created some classes in puppet 21:08 < dgilmore> kojira and some cron jobs should only be run on a single box 21:09 < ricky> So will those be run on koji2 so that koji1 can be rebuilt i686? 21:09 * ianweller rolls in 21:09 < dgilmore> ricky: right now they are on koji1 21:10 < dgilmore> there is 2 new classes kojipassivehub and kojiactivehub 21:10 < dgilmore> so its a matter of adjusting nodes to move where it gets run 21:10 < dgilmore> koji1 has 8gb ram and koji2 has 2gb 21:11 < dgilmore> I think ill swap everything to koji1 and increate the ram on koji2 to 4gb 21:11 < dgilmore> i need to check we have enough for it 21:11 < dgilmore> ricky: but ill switch them to koji2 before rebuilding koji1 21:11 < G_work> anything interesting? 21:12 < ricky> Ah, OK 21:12 < G_work> oh wait, it's just starting? 21:12 -!- cyberpear_ [n=cyberpea(a)machamp-37.dynamic.rpi.edu] has joined #fedora-meeting 21:13 < dgilmore> I need to add koiji2 to nagiso also 21:13 < abadger1999> yep 21:13 < dgilmore> but right now koji2 is up and running and serving the builders 21:14 < dgilmore> ill update the buildsys sop with info on changing the classes in puppet 21:14 < G_work> dgilmore: poke me in an hour and I'll sort out monitoring 21:14 < dgilmore> if anyone can think of a way to automate the cronjobs and kojira running moving to different hosts im all ears 21:15 < dgilmore> i guess its concievable that we could have 3 or 4 hubs/ web frontends 21:15 < dgilmore> and they just need to run on one 21:16 < dgilmore> so open floor? 21:16 < ValHolla> dgilmore: are they in active passive mode or are they "load balanced" *am confused* if they are in active/passive mode, have the cron/scripts check for node being active and exit gracefully if it is the passive one 21:16 -!- dgilmore changed the topic of #fedora-meeting to: Fedora Infrastructure Meeting - Open Floor 21:17 < dgilmore> ValHolla: they are load balanced 21:17 < dgilmore> not active passive 21:17 < ValHolla> bummer ;) 21:18 < dgilmore> anyone have anything they want to talk about? 21:18 -!- sonar_logger2 [n=Who(a)adsl-074-171-066-196.sip.aby.bellsouth.net] has quit Connection timed out 21:18 < dgilmore> price of tea in China? 21:19 < G_work> dgilmore: not really 21:19 < dgilmore> alrighty then 21:19 < G_work> except I'm now in Australia & working for Red Hat 21:19 < dgilmore> ill wrap up in 30 21:19 < abadger1999> G_work: Congratulations! 21:19 < dgilmore> G_work: :) 21:19 < dgilmore> abadger1999: he is in my old home town 21:19 < G_work> abadger1999: :) 21:19 < abadger1999> Cool 21:20 < ricky> Congrats again 21:20 < dgilmore> 20 21:20 < G_work> abadger1999: I'm actually on internal VPN because I left my USB stick behind 21:20 < dgilmore> 10 21:20 -!- rdieter is now known as rdieter_away 21:20 < dgilmore> ---Meeting ENd---

1 0

[Fwd: Account Problem]
by Ignacio Vazquez-Abrams 06 Nov '08

06 Nov '08

For your consideration. -------- Forwarded Message -------- From: Stefa Nos <stefanos4555(a)gmail.com> To: webmaster(a)fedoraproject.org Subject: Account Problem Date: Thu, 06 Nov 2008 13:48:59 +0200 Hello, I don't know if you are in charge for this type of problems but I want to inform you for a situation I have been into.While I was completing the registration form to get a Fedora account I accidentally mistype my e-mail address. These are the information I did complete to registration form: Username: stefanos4555 Full Name: Stefanos Mpourtzoudis Email: stefanos4555(a)gmai.com I am 13 years of age or older: Yes So I wonder if the wrong email address can change to the correct stefanos4555(a)gmail.com so I can proceed with my registration. Thank you in advance for your time. -- Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com>

2 1

[Fwd: [tx-devel] Roadmap thoughts]
by Toshio Kuratomi 05 Nov '08

05 Nov '08

FYI: Roadmap for Transifex's port to DJango and how long we have with the TurboGears version before we have to start thinking about making the new version work. -Toshio -------- Original Message -------- Subject: [tx-devel] Roadmap thoughts Date: Thu, 6 Nov 2008 01:26:06 +0200 From: Dimitris Glezos <dimitris(a)glezos.com> Reply-To: transifex-devel(a)googlegroups.com To: Transifex devel list <transifex-devel(a)googlegroups.com> References: <6d4237680811051433n55ef48d7x668f19b0a9dfd9b4(a)mail.gmail.com> <6d4237680811051519g7d149ba3x616957ff1ea10f55(a)mail.gmail.com> I'd like to share some thoughts on having a roadmap for the upcoming releases and next months. Get everyone is on the same page and make sure we have a consensus on our actions. Development on mainline is more or less frozen since we've been hammering the Django branch to shape, together with Diego. I'd like us to release a 0.4 major release from the TurboGears branch, based on the current tip of the mainline branch. This release can be maintained for bugfixes in the form of 0.4.x for a few months, in case there are deployments of it. I've documented the current features: http://docs.transifex.org/releases/0.4.html The Django branch, once it's mature enough release can become 0.5. This release will include at least everything the TG branch has and many more: http://docs.transifex.org/releases/0.5.html What does this mean to projects like Fedora and GNOME? I believe Fedora can install 0.4 right away, and take its time to deploy 0.5, since it's the first Django app on its Infrastructure. With GNOME we have enough time until the feature freeze to include the features we need (collections, releases, etc). With Django's pluggable architecture, it's much easier to start experimenting with these, without affecting the core functionality. One open issue is Christos' work on the submissions branch. I've ported this work on the VCS layer almost without any changes in the Django branch. It's our solid base for VCS support for all future releases. The Q is whether it's worth merging it into 0.4 as well, or if it's more efficient if we cherry-picked any bugfixes from that branch into mainline. I'm wondering whether we're better off keeping 0.4 stable and simple, given the fact that it will only exist for a few months. Roadmap to 0.5 -------------- Since we have a lot of work until reaching stability and the feature set of 0.4, we're splitting up the work in minor 0.5 releases or milestones, in the form of 0.5m1, etc. Aiming for a few of them: - 0.5-m1 (Finished): Bare minimum Code refactoring, Units, Project registration, Basic i18n, VCS layer complete, initial data there - 0.5-m2 (Finished): Announcment of the Django branch to the developers and core testers OpenID, Notifications, Deployment, non-master branches work, statistics, languages - 0.5-m3 (Half-finished): Announcement of Django branch to the general public OK: login_required for editing , use dynamic site_name, download POs Working on them: Catch most exceptions, all VCS work on tx.net - 0.5-m4: Ready for testing from projects Project Collections, User profiles, Better docs in the UI, Logging - 0.5-m5: File Submissions - 0.5-pre: Everything needing completion before 0.5 Gold Everything from TG branch works, documentation completion, wsgi deployment, admin panel refinements - 0.5 Gold Development from here will continue as usual: The goal is to have minor releases which will not break the ABI. In any way, we'll use django-evolution to allow schema evolution for model changes. A few draft ideas for minor releases: - 0.5.1: Comments, Sitemap, Invitations. Maybe: Msgmerged i18n support. - 0.5.2: More admin features, Basic CLI, AJAX. Work for better support for GNOME and Fedora. - 0.5.3: Full CLI+auth, fine-grained permissions, complex notifications, workflow, svn+https support - ... - 0.6: First release with major backwards-incompatible changes, like File monitoring, Project owners, etc. Important dates --------------- Given the fact that there are some big gaps in development time for a few of us, it's not easy to put some close hard dates on the above. But we're aiming in something like the following: - 2008-11-06: 0.4 released, branch off. - 2008-11-08: Finalize 0.5 feature set - 2008-11-15: 0.5-alpha (0.5-m3) - 2008-12-13: 0.5-beta (0.5-m5) - 2008-12-16: Feature Freeze (0.5-pre) - 2008-12-23: 0.5-rc1 - 2008-12-29: 0.5-rc2 - 2008-01-04: 0.5 final Thoughts, ideas, flames? -δ -- Dimitris Glezos Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- -- Dimitris Glezos Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) -- -- Dimitris Glezos Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B http://dimitris.glezos.com/ "He who gives up functionality for ease of use loses both and deserves neither." (Anonymous) --

1 0

Change Freeze Breakage
by Mike McGrath 04 Nov '08

04 Nov '08

The freeze doesn't technically end until tomorrow but because of the small window between this freeze and the next I'd like to get some bits done. 1) Change the smolt api to point to its new location in /var/www/smolt-wiki/ instead of /usr/share/mediawiki/ 2) fas-server update. This is a yum update with some testing. -Mike

6 12

space for more storage?
by Matt Domsch 02 Nov '08

02 Nov '08

Given the discussion on FAB: If we had more storage, where (physically) could we put it? Is there space in PHX? If so, how much? There's no particular reason why space for hosting a boatload of remixes would need to be in PHX. For bandwidth purposes, it would be good if it were elsewhere. I can try to drum up more sponsors, but want a coordinated plan for what we're asking for, and where it's going to go... -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux

2 1

Re: Cron <root@proxy3> /usr/local/bin/syncFiles.sh mirrors /srv/web/mirrors/
by Matt Domsch 02 Nov '08

02 Nov '08

On Sun, Nov 02, 2008 at 03:13:10AM -0500, Ricky Zhou wrote: > On 2008-11-02 08:00:02 AM, Cron Daemon wrote: > > rsync: read error: Connection reset by peer (104) > > rsync error: error in rsync protocol data stream (code 12) at io.c(614) [receiver=2.6.8] > Could these be due to the recent rsync rate limiting changes? Should we > make them only affect secondary1, perhaps? perhaps... though there aren't so many proxy* servers (are there) that they'd be seen as being >10, or >2 from a single IP? in fact, yes, >2 per IP. My guess is it's multiple syncFiles.sh running in parallel cronjobs simultaneously. I'll drop that bit for now. -- Matt Domscht Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

infrastructure November 2008