Re: Open sysadmin-requests mailing-list?
- From: Owen Taylor <otaylor redhat com>
- To: Murray Cumming Comneon com
- Cc: gnome-hackers gnome org
- Subject: Re: Open sysadmin-requests mailing-list?
- Date: 27 Jun 2003 11:52:12 -0400
On Fri, 2003-06-27 at 03:49, Murray Cumming Comneon com wrote:
> The administration of our various servers is failing, because the select few
> people listening to gnome-sysadmin gnome org just don't have enough time,
> and we naturally can't give the root password and responsibilities to yet
> more people. We are all very grateful for the work that the sysadmins do
> manage to do.
>
> One solution is to employ a full-time system administrator, but that isn't
> likely to happen any time soon.
>
> I think we should at least have an open sysadmin-requests mailing list so
> - everyone can see what needs to be done. This would also build a case for
> employing a sysadmin.
> - everyone can see how best to request something.
> - the undocumented workings of our servers would be a bit more documented.
> - people without the root password can investigate problems and suggest
> solutions that the syadmins can try quickly.
>
> I'd like to think that we can put _all_ sysadmin discussion on an open
> mailing list instead of having security-via-obscurity, but it doesn't look
> like people will agree to that.
>
> So, any thoughts? Any objections to creating an open sysadmin-requests
> mailing list and advertising this as the place to ask for sysadmin stuff?
> Alternatively, we might make gnome-sysadmin public and move secret
> discussion onto a new private list. Or would a syadmin bugzilla product be
> better?
Unfortunately, I don't think advertising a lot of details about system
adminstration is a good a good idea... at a minimum we'd need to have
three separate things:
- Non-security sensitive requests
- Security sensitive requests
- Discussion
And that strikes me as just too confusing. (Actually, a great deal
of the requests are already going to the request tracker, so seeing
what goes to gnome-sysadmin doesn't help you there.)
And in the end you seem to want is accountability, but I don't see how
accountability is going to do any good. If we had the assumption that
we *were* handling all the sysadmin stuff in a timely and good fashion,
then accountability would be useful to verify that. But I don't
think we have that assumption.
I'm quite willing to say:
"The current system adminstratration system is quite
unresponsive and a long ways from ideal"
But I also would really like to emphasize:
"It could be far, far, far worse. It has been far, far, far
worse. Let's not blindly make changes without having some
idea that they will really improve the situation."
The current situation, from my perspective is:
- We are doing very well at handling reliability of the standard
services cvs/mail/bugzilla/etc. We have been going months
between outages recently.
This *may* just be coincidence.
- We are doing OK-ish on requests for new accounts, and
similar stuff.
- We are doing quite badly at upgrades and new facilities
The basic problem is that we have only wanted to delegate adminstrative
access to people that we know and trust, which, pretty much by
definition is people without any time. So, we have a dozen or more
people with full adminstrative access on gnome.org, but still
the current situation where requests are very slow at getting
filled.
For example, Murray, I'd be quite willing to give you the necessary
access to create new mailing lists on mail.gnome.org, but I don't
think it would do much good ... your interest and where your time
goes is always going to go to gtkmm.
There is also other problems that:
- The few people with physical access to the machines (those of
us here at Red Hat) are probably even more time constrained
than the overloaded hackers.
- The hardware we are using is getting quite antique, and we
often don't want to add stuff just because we don't have
the capability.
The 4th anniversary of the current cvs.gnome.org going into
service is tomorrow.
I think the broad outline of where we want to be is clear.
- There should be a formal gnome system adminstration led
by someone who is willing to commit significant amounts
of time to it on a long-term (say 1-year) basis.
- We should have a small group of time-zone distributed
trusted minions.
- We should figure out how to reduce the physical access needs
as much as possible (hardware solutions such as console
servers and remote power management could definitely help,
and perhaps we should solicit donations in this area.)
- My time that is freed up by the above should be used be
used for unavoidable phyical tasks.
How to get from here to there is the hard question, and I'd
appreciate any suggestions that people have.
> By the way, here are some of the current problems that I know of personally:
> - libxslt crashes while building Docbook documentation, on widget.
> - A new cvs server is apparently on the way, or has maybe arrived already,
> is maybe in limbo. A mystery.
That particular machine is not coming. We are investigating other
options.
> - We need to use cvs via ssh. [1]
This has sort of been blocking on the new machine that turned out
not to arrive. It's not really that hard to get going, but needs someone
to drive the process.
> - It's very difficult to add new mailing lists. I generally have to ask 3 or
> 4 times.
To some extent, I have to say I think that's a good thing, mailing list
explosion can easily get out of hand. ;-) But no, it's not a good
thing. Generally, I think your best bet is to find people on IRC
personally and harass them.
> - widget is running an old distro that lacks something needed by Jeff's
> auto-upload-of-developer-documentation, so
> we have currently uploaded arbitrary old documentation versions to
> developer.gnome.org. Jeff gave specifics in an email somewhere.
Never seen that email. I gave Matthias Clasen access, and he's fixed
the autobuild up to, I think ORBit. Beyond that, apparently there
are obscure auto* problems or something.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]