Yeah, I've been talking to Ryan and Jeremy on this too, but perhaps they
can chime in.  What we're talking about should be within the realm of
possibility on the OSU hosted server, I think. They've got it fairly
isolated from the rest of the OSU stuff, I think.

Ryan Ordway, as part of his job at OSU,  is already the the basic
fundamental OS-level sysadmin for the box. But he doesn't necessarily
have the time to be app-level admin for the apps we run, at least not
putting in as much time as we might want for really good services.  It's
enough that OSU is donating the server, bandwidth, and basic OS-level
sysadmining, I think!

So what I'm still leaning toward is having 2-3 people as the main group
of admins for the box (under the authority of Ryan and OSU, doing
app-level admin).  They might or might not have sudo wheel access, if
needed, it can be negotiated with Ryan. (Ryan said this was possible, if
there was a good reason for it, I think).  Taking into account Joe's
warning that 2-3 doesn't work you need JUST ONE--I still think 2-3 can
work, but maybe one of those 2-3 is the "head" or something. But then
there'd be other volunteers under _their_ authority----you want to admin
the planet, you talk to those 2-3 people and express your interest, if
they are convinced you know what you're doing enough to not mess stuff
up, they give you access (or ask Ryan to give you access; but they're
the gatekeepers).  These extra volunteers would never have sudo wheel
access, I'd think.

So that sounds good to me as a way to go. But it requires that 2-3 (or
even 1) person volunteering to be that, um, what I'm calling 'junta'.
Anyone interested?   One of the reasons I think 2-3 is better than 1, is
I think it's going to be even harder to get someone to volunteer to do
it by themselves.

Jonathan





Joe Hourcle wrote:
On Fri, 21 Mar 2008, Jonathan Rochkind wrote:

I think that by allowing a  larger group of people in, we get more done
and have _better_ services. But there's definitely a balancing act,
between stability and more hands.  I don't want to see it balanced too
much toward stability 'guarantees' though. Letting in people we trust to
know what they know and what they dont' know and only touch the stuff
they are volunteering to be responsible for I think can do that.

For instance, I'm happy to be responsible for the planet. And not much
else.  Just being responsible for the planet, I'd be 'wasting' a 'slot'
if we only allowed 2-3 people in---plus I'm not really an experienced
sysadmin!  But I'm willing to manage the planet, and if I weren't doing
it, someone else would have to. I suppose if we can really find 2-3
experienced sysadmin willing to spend a lot of time on code4lib for
free...  but isnt' spreading out the work more a better idea?

Depending on the apps being maintained, it's sometimes useful to have an
admin for each individual app, plus basic sysadmin (and possibly
webserver admin) for the box.

Personally, I'm getting kinda rusty in my sysadmin duties, and I've never
dealt with CentOS (or RedHat -- my linux experience in general is rather
lacking ... most of my experience is in Solaris / FreeBSD / MacOSX )

But on the issue with having lots of sysadmins -- it's ideal that you
have
a backup for various roles, in case someone's on vacation, etc, but you
can run into the problem where everyone waits for someone else to step up
and do something.  (eg, one of my co-workers has been maintaining the
DC-SAGE webserver for years ... people keep requesting new features, but
aren't stepping up to implement them ... and the sad thing, it's a group
of sysadmins.)

I personally might be able to help with things on an ad-hoc basis, but
I've already got a few 'volunteer' systems that I'm behind schedule on
implementing.


As far as the 'formalization' idea---if what you want is a small group
of people deciding who gets shell access, you can have that without
bylaws and a board. Just create the small group of people. Two seperate
questions. If a junta in charge of code4lib sysadmining is a good idea,
create one.

I'd be afraid of someone letting the power go to their head.  It's also
possible that OSU has policies on people with root/administrator
access on
their network, which might override anything decided in this forum.


So maybe that's the answer right there. We find 2-3 people to take
_primary_ app-level responsibility for code4lib.org (ryan ordway still
has primary OS-level responsibility), and they are the junta. If someone
else (like me) wants access to do some smaller part, the junta approves
him or her (and the junta can revoke them).  That makes sense to me.

You can't have 2-3 people take primary responsibility unless they're each
primary for a different component.  (see earlier comment regarding the
bystander effect)


Anyone volunteering to be that junta?   :)

Not it!


-Joe


--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

Reply via email to