Re: Open sysadmin-requests mailing-list?



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


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]