Wiki save slowness
by Mike McGrath
Does anyone want to take some time to find out exactly whats causing out
wiki to save slow and what we can do about it? #moin has been helpful
for me but I've got other issues I need to deal with right now. The old
wiki is still up for those that want to test with it, you can view the
old content (and save it) by typing:
ssh -L 8080:fpserv.fedoraproject.org:80 localhost
(Assuming you're running ssh on your local box) then just go to
http://localhost:8080/wiki/
It seems to take 30 to 50 seconds to save a page which is just
horrible. From what I understand its because saving causes moin to
iterate over all the user accounts (currently many thousand) to see
which users are watching that page. I've heard there are options but
I'm not sure what those options are.
If someone is interested in helping just reply and let us know.
-Mike
17 years, 1 month
xen 1 and 2 - yum update
by Mike McGrath
I'm going to update the xen boxes, they're out of sync and its
preventing some tests I need to do.
-Mike
17 years, 1 month
FYI: SMART Noticies on xen2
by Mike McGrath
Mar 7 14:28:53 xen2 smartd[4441]: Device: /dev/sda, SMART Failure:
LOGICAL UNIT FAILURE PREDICTION THRESHOLD EXCEEDED
Repeated many times, looking into it.
-Mike
17 years, 1 month
proxy 1, 2
by Mike McGrath
Some nfs shares on the proxy servers have gone a little stale and
they're not cleanly unmounting. I'm taking a closer look but may have
to reboot the boxes. I'll do them one at a time so we shouldn't have
any actual downtime.
-Mike
17 years, 1 month
OTRS upgrade
by Mike McGrath
I've done an OTRS upgrade to the latest version. The db scheme upgrade
wasn't as clean as I would like so if anyone sees anything strange, let
me know. I've been working with spam stuff since SMTP is on hold. It
seems to be helping.
-Mike
17 years, 1 month
[Fwd: [Fedora Project Wiki] Update of "Infrastructure/RFR/SELinux" by DanielWalsh]
by Mike McGrath
Dan is requesting a xen instance for use for this project.
Questions I have:
There's no way to integrate this into our current environment? All
information we get from the internet is random data :-)
Can you give us a better idea of how this works on the back end? What
would we need as far as backups go, space, etc?
-Mike
17 years, 1 month
Getting rid of fedora.redhat.com
by Rahul Sundaram
Hi
Is there any major roadblocks to redirecting fedora.redhat.com to
fedoraproject.org? There is a lot of outdated misleading content there
that searches point out to. Could we do this before the Fedora 7 release
please?
Rahul
17 years, 1 month
PackageDB 0.1.92 and Roadmap
by Toshio Kuratomi
Hey guys,
I've put together 0.1.92 of the PackageDB. 0.2 is just around the
corner. Look at the present work here:
https://admin.fedoraproject.org/pkgdb/
The front page details the tasks that need to be accomplished before the
Go Live date. If you want to help out with any of this, I'd be happy to
hear from you as I've started doing some consulting which took up way
too much of my time this week :-(.
* Within the web app
* Ability to add or subtract cvsextras access to your
package: This will be a general group feature later. For
now we just need cvsextras +/- to match the present ACL
system. (*) This is the last feature before 0.2
* Notification that people have requested acls: package
owner and people on approveacls
* Notification of owner changes: cvsadmin group? FESCo?
* Hide checkout and build perms
* External scripts
* How to add a new package: Must be done pre-cvs-import so
we should tie this into dgilmore's scripts on cvs-int.
* Current sync of owners.list/owners.epel.list: Have to
update slightly to account for the new owners.list
format
* Sync to Package ACLs
* Output ACLs to the system
* Output entries to bugzilla
The plan is to get 0.2 done over the weekend. Hiding the build and
checkout perms should be pretty to accomplish in the pkgpage.js init()
function. Then the GUI through the database layers will be done enough
to release.
Notification is probably best done using TurboMail in the web app but
that's an area that can be explored.
Adding the new package: someone needs to coordinate with dgilmore about
adding things to the branch script.
Syncing of owners.list has a lot of work done since I had to import the
data in the first place. Some changes have occurred since the script
was written, though. So we need to update. notting has a similar
script that we might be able to use.
notting already has code that deals with ACLs (both in and out) as he
currently has to parse the individual acl files from cvs and push them
into the cvs acl file. I haven't looked at it but he thinks most of it
will be applicable to the packagedb.
Output to bugzilla is currently handled via cron using a script that
sopwith wrote. I believe the code lives in fedora-accounts but I'm not
sure where the live script is. It would be nice to move away from cron
and make changes to bugzilla as they occur in the packagedb but we
probably want a "sync everything in packagedb to bugzilla" as a way of
ensuring packagedb and bugzilla agree so moving away from cron might be
a project for later.
Note that the front page lists a lot of additional work that could be
done to make the package db better. Some of those will make a huge
difference usability wise but for me to get to them requires making it
through the things that have to be there for us to replace owners.list.
If someone else wants to dig into those now let me know.
-Toshio
17 years, 1 month
people,developers.fedoraproject.org
by Mike McGrath
So now that fpserv no longer hosts the wiki... We may be able to
re-evaluate the people.fedoraproject.org and
developers.fedoraproject.org setup. This machine is at Duke and Seth is
on board (he suggested it). I'd still like to send a copy of the CVS
off site to this box for safe keeping but it would allow us for plenty
of leg room. This is probably going to be a long discussion (as it
should be) but I'll get started.
people.fedoraproject.org:
For Fedora contributors[1] only, no exceptions.
50M quota, strictly enforced.
Static content only
sftp access
http access
Fedora related content only. (We will passively police)
No expectation of privacy
Won't take much to get banned from p.fp.o
username.people.fedoraproject.org (should be trivial to setup)
developers.fedoraproject.org
For the more high-level people, will require full approval of the
infrastructure team.
For those that don't make it I'll send them a note telling them no and
explaining why if there is a reason.
(This if for the jkatz, thl's, abadger1999 and dgilmore's of our group)
200M quota, manually enforced (email notifications)
Static content and basic scripting, TurboGears, python, php, perl, etc.
cronjobs (this may be a bad idea)
sftp
http/https
shell / ssh
no expectations of privacy
Local apps (like running their own mysql db's and such, as long as it's
within the quota)
username.dev.fedoraproject.org (should be trivial to setup)
We will help meet these peoples needs but won't go too far out of the
way (like installing multiple versions of python)
** Not for critical apps **
The idea here is that this should be a very hands off process for our
team. We'll help the developers with things but if we don't meet their
needs, they'll have to go somewhere else, this is a convenience thing.
The people.fp.o site will be completely hands off, we have to find a
scriptable way to determine who belongs in people. Anyway, what do you
think?
-Mike
[1] Contributor. Here are a few possible definitions of contributor:
CLA: Users who have signed the CLA (I consider this to be the general
public)
Sponsored: Users who have been sponsored by someone for their team.
Committers: People who actually have commit access to the CVS (Doc's
team, Extras, etc)
I vote for "sponsored"
17 years, 1 month
