I am out of the office until 08/15/2011.
I will be on vacation starting on Friday and returning on August 15.
Unix System Administrator
Note: This is an automated response to your message "infrastructure
Digest, Vol 63, Issue 6" sent on 8/6/11 6:00:21.
This is the only notification you will receive while this person is away.
Greetings all, Infrastructure is in the process of getting all of our
machines switched from RHEL5 to RHEL6. Right now we're looking at one of
the more publically visible services that we host -- mediawiki for
fedoraproject.org/wiki. Mediawiki installs and runs for us but it is too
slow. So slow, in fact, that our proxy server decides that the instance is
down and takes it out of rotation.
If someone has some mediawiki configuration or mediawiki/php programming
experience and would like to take a look, we'd be happy to get you
permissions to poke around our RHEL6 app server test instance and try out
fixes. You can contact nirik (Kevin Fenzi) or me (abadger1999) on
irc.freenode.net #fedora-admin to help get you started. You can also take
a look at the ticket for any details I've left out here:
The infrastructure team will be having it's weekly meeting tomorrow
2011-08-04 at 1900 UTC in #fedora-meeting on the freenode network.
Suggested topics (suggested by whom):
* New folks introductions and Apprentice tasks.
* F16 Alpha Freeze reminder and tickets.
* Upcoming Tasks/Items (nirik)
2011-08-02 - 16: Alpha change freeze
2011-08-16: Fedora 16 alpha
2011-09-06 - 20: Beta change freeze
2011-09-20: Fedora 16 Beta
2011-10-11 - 25: Final change freeze
2011-10-25: Fedora 16 release.
* Meeting tagged tickets:
Submit your agenda items, as tickets in the trac instance and send a
note replying to this thread.
More info here:
Following up on the action item for the infra-docs/SOP migration from
the wiki to git I was wondering what opinions folks had on these two
1. having each page be plain text and have the following format:
Summary: blah blah blah
Body goes here
Then having a commit hook for the git repo generate a simple index of
the above for browsing on a web site.
2. Just put the txt files in a dir and let you browse based on filename
and be done with it. - since a lot of us are going to just use git grep
ANYWAY, just roll with it.
I'm inclined toward simple and add complexity as we go.
Just FYI, there was an unplanned outage in phx2 today.
There was some cabling work being done and a switch in one of our racks
didn't properly failover to it's second power supply when power was
moved from it's primary. This resulted in a approx 10min outage to
servers in that rack.
Additionally, one machine had a network cable that wasn't reseated
properly, so it couldn't reach anything after the switch came back.
Investigation of how to fix the switch is ongoing.
The old I2 mirror machines (2 of them) handled 50 syncs at a time.
We have 3 machines, but they are set currently to 25/ea, meaning a
total of 75 could be hitting the backend storage.
I'd like to lower this down to 15/ea and see if it helps with the
slowdown/issues as seen in
diff --git a/modules/rsync/files/rsyncd.conf.download-rdu b/modules/rsync/files/rsyncd.conf.download-rdu
index de816a0..027b90e 100644
@@ -1,7 +1,7 @@
pid file = /var/run/rsyncd.pid
syslog facility = daemon
-max connections = 25
+max connections = 15
timeout = 600
use chroot = yes
uid = nobody
Hey, folks. Just wanted to take another shot at one of my oldest
So, we talked about calendaring for a long time. Then we picked Zarafa.
Then we kind of implemented it. Then no-one used it, and we took it out
That wasn't what you might call a 'success', I know. I think there's
maybe a couple of reasons for that. One, I'm still not really sure why
we'd pick Zarafa. It's explicitly designed to be a Microsoft Exchange
replacement, and I don't think Fedora is a project with a lot of people
who really need to use ActiveSync or Outlook, so...huh? It just doesn't
seem like it was ever a great fit. By the Zarafa page on the wiki -
https://fedoraproject.org/wiki/Zarafa - we couldn't even ship Z-Push
because ActiveSync is patented, so apparently our only ever official
calendaring system never had a working sync mechanism at all, and I
don't think Zarafa's web interface is any great shakes.
Two, there was never any particular driver towards using it.
So, I think another try with a more appropriate calendaring system - if
we can find one - and a 'seed' use of it might be a good idea.
I've been using eGroupware, personally, for quite a while, and I think
it's a good system. I'm not aware of any major barriers to including it
in Fedora. It has internal copies of a few Pear modules, but that's
pretty small beer and it should be trivial to use the system-wide copies
or get an exception (some of them are extensively modified). It has a
nice web UI and decent sync capabilities via CalDAV: I've used it
synchronized with Evolution on two systems and never had major problems.
It seems at least a better fit than Zarafa. Citadel would be another one
to look at.
As for a 'seed' use, I think an ideal fit here would be the release
schedules. Currently, these are dumb HTML tables with ICS files living
in the current release manager's personal fedoraproject space:
which sucks for any number of reasons, not least of which you need to
know who the hell the release manager is at the moment in order to find
the schedule. =) Using a proper calendaring system would seem to be a
far better way to handle the release calendars, and would be a great
kickstarter for a project calendaring system. Since the calendars are
maintained by one person, we only need to get one person (hi, Robyn!) to
buy in, in order to kick off this seed use.
To restrict the liability issues mentioned in Smooge's blog post, we
could not enable the email function of the system we choose (this is
possible with both EGW and Citadel). We could also not have individual
accounts for all Fedora project members, at least at first: we could
have just a few individual accounts with commit access, mainly for the
release manager to maintain the calendars, and then have a single
read-only guest account which people could use to view the calendars and
sync them read-only to their phones and desktop clients. It may even be
possible to set things up so people can view and read-only sync without
any authentication required.
What do people think of this idea? If it seems like an approach that's
simpler to maintain and more likely to produce actual useful results,
that'd be great. I'm willing to work on packaging eGroupware and
resolving the private-copies-of-pear-modules issue - I already maintain
eGW for Mandriva, so it wouldn't be too much work to convert the spec to
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora