log1 and nagios cron alerts
by Jon Stanley
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 \
14 years, 10 months
Failed fas upgrade
by Toshio Kuratomi
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
14 years, 10 months
Freeze reminder
by Mike McGrath
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
14 years, 10 months
Re: ** PROBLEM alert - cvs1.fedora.phx.redhat.com/Puppet is CRITICAL **
by Jon Stanley
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
14 years, 10 months
Meeting Log - 2008-11-06
by Ricky Zhou
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=as...
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---
14 years, 10 months
[Fwd: Account Problem]
by Ignacio Vazquez-Abrams
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>
14 years, 10 months
[Fwd: [tx-devel] Roadmap thoughts]
by Toshio Kuratomi
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)
--
14 years, 10 months
Change Freeze Breakage
by Mike McGrath
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
14 years, 10 months
space for more storage?
by Matt Domsch
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
14 years, 11 months
Re: Cron <root@proxy3> /usr/local/bin/syncFiles.sh mirrors /srv/web/mirrors/
by Matt Domsch
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
14 years, 11 months