SEUL-Leaders: cvs config

[Luka@pop3.aracnet.com (Peter) <luka@mit.edu>]

talked to omega last night about cvs, and worked out a much
simpler config.  simplicity has much value, as long as it works,
so tell me if you see something i've forgotten:

there's a seul-admin user and seul-admin group (we could call them
seul or seul-admin, but _both are administrative_ is the important thing).
each developer has his own uid (just being explicit here), which doesn't
have much importance beyond authentication.
and each major group has its own gid.  eg, seul-dev-ui, seul-dev-foo,
seul-web, etc.....

here's the cvs setup

/seul/cvsroot  : rwxr-xr-x : seul-admin, seul-admin
 |
 +--seul-group1  : rwxrwsr-x : seul-admin, seul-group1
 |
 +--seul-group2  : rwxrwsr-x : seul-admin, seul-group2
 |
 ... (etc)

the effects of this setup:
 creation of a module/group has to be authorized by seul-admin; this
prevents cvsroot from blowing up.  (also, only seul-admin should have
access to the CVSROOT module.)
 seul-admin permission will not be needed often - only when a new
group has to be created, since the point of seul-admin is that only
he has permission to modify the cvs root structure.
 under normal operation, each developer will be in appropriate
groups for projects he is working on.  he can then work freely
on anything within his scope (this may well be seul-dev-*, but not
seul-marketing-fubar, for example).  whenever he operates on a module,
sgid on the directory ensures that the files will have grp perms, so
everything in a module belongs to that group.
 there is no reason to use a uid which is not your own.  the group
determines perm's and work because of mod dir sgid.  the uid then
identifies who touched stuff, but shouldn't have other real implications.
(so the inability of a random user to chown a file does not matter.)

 when administration is needed, there should be a small set of admin
scripts available to just a few of us (presently, the people on this
list), which let us do things like create new groups upon request.
joe random user should not have access to these because he should
be set up to have permissions in groups we know he's working on at
least semi-regularly, and can stash stuff related to those groups
in the respective modules.  if he wants to store something unrelated
to anything he has permissions on then either:
 1. it is not related to seul - it does not belong on cran.
 2. it belongs in a group that he doesn't have access to - he sends
mail notifying us that he is working on foo, or has foo to checkin.
if this is a one-time thing, he can just ask someone with permission
to check it in.  if not, then within a day he gets a new group perm
from root, or any seul-admin if we use the admin scripts. (not much
required here!)
 3. it belongs in a new group - he sends mail to seul-admin and gets
a new group created if it is the right thing to do (else advice on
what should really be done).

(oh - note that i sort of use seul-admin loosely to refer to cvs-gods.
the repository _is_ dedicated to seul, so the seul repository gods are
seul admins.)

and as far as coverage, we should be able to get 24/7 pretty easily
just among us.  if nothing else, i live 3 feet under cran, even on
holidays, and should soon have ssh access set up from the places i 
travel most frequently (work, etc).
not to mention, even a 1 day seul-admin response time is quite good,
since that access (suid/sgid seul scripts or direct login) should 
only be needed for relatively major changes (changing the project layout,
or moving people around in groups).  the grouping thing will
be pretty intense during times when accounts are being set up en masse,
but should be low-maintenance outside of that. (and the project layout
*better* not change more than once a day!)

so, that's it.  i just scribbled this out quickly, and probably
missed details, so tell me what i overlooked (i don't think i
missed anything earth-shattering though...).
i'll be on irc tonight, as promised, around 8-9 and again around midnight.
(i have a meeting 10-11).

-luka
----------------------------------------------------------------------------
Simple End User Linux Leader Mailing list
----------------------------------------------------------------------------