[7431] in Release_7.7_team
ideas for en-masse dev cell project locker move to athena cell
daemon@ATHENA.MIT.EDU (andrew m. boardman)
Mon Mar 28 15:39:29 2011
Date: Mon, 28 Mar 2011 15:39:21 -0400
Message-Id: <201103281939.p2SJdL0E029271@pothole.mit.edu>
From: "andrew m. boardman" <amb@MIT.EDU>
To: rel-eng@MIT.EDU, release-team@MIT.EDU
Looking at what's in /afs/dev/project, I suspect its *almost* completely
dead storage, but there's enough stuff of lingering interest that it's
probably worth keeping. (Also, the entire collective usage adds up to
peanuts by today's storage standards.)
There are no collisions with athena cell project locker names, so my
initial thought it to just move them all to the athena cell mostly as-is.
There are some issues with acls, but I don't think any of them are
particularly critical; these don't exist in the athena cell at all:
read:staff
system:libdevo
system:rel-eng
system:winafstest
write:sipb
write:staff
...but could either be recreated as is or perhaps just regularized to use
a couple of new (or maybe existing) moira groups for write access and any
restricted read access. (Maybe something like source-access for any
restrictive read acls and athena-committers/release-team/rel-eng/etc. for
rlidwka.)
PTS groups which actually exist in both cells but which are different
between them are are system:administrators, which I don't think we need
to worry about, and system:aui-acl, which should probably have the -c dev
users added to the relevant moira group.
Am I missing anything? Lots of what's here is crufty even by my
standards, and I may be missing some subtle and still-relevant
machinery.
