[6205] in Release_7.7_team
Re: Low UIDs and GIDs
daemon@ATHENA.MIT.EDU (Michael R. Gettes)
Wed Feb 11 11:48:23 2009
Cc: release-team@mit.edu
Message-Id: <118D8A13-B13C-4A0F-BCBE-C38972856470@mit.edu>
From: "Michael R. Gettes" <gettes@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
In-Reply-To: <81556AB8-F55A-4869-AB3E-6301DE1CA380@mit.edu>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Wed, 11 Feb 2009 11:47:40 -0500
X-Spam-Flag: NO
X-Spam-Score: 0.00
ok, so a proper response to this analysis (from me) would be "oh crap".
This is quite a significant problem from a user support perspective.
Do we think there is some "easy-ish" mechanism we could put in place
to migrate users to different UIDs and hopefully deal with the problems
as they come thru such a mechanism? Maybe a web page to "heal my UID"
and it does all the right magic behind the scenes if the user is logged
out of all unix instances? Maybe same thing for the GIDs?
/mrg
On Feb 11, 2009, at 11:38, Jonathan Reed wrote:
> Sorry, for the confusion. "DOOMED" refers to users who have been
> deactivated, but not yet purged. However, some of these users do
> end up returning to the Institute in one capacity or another, so we
> can't immediately assume that we can ignore those accounts.
>
> "SYSTEM" and "PROJECT" refer to accounts that are something other
> than a real live person - way way back in the distant past, there
> were shared accounts for certain things. Someone with more history
> than me can elaborate on that.
>
> -Jon
>
> On Feb 11, 2009, at 11:28 AM, Michael R. Gettes wrote:
>
>> To verify my understanding... the user counts noted as "DOOMED"
>> are users who we need to move ASAP??? The others might be problems
>> in the future and could be dealt with then? If so, then we have
>> 43 users to immediately worry about?
>>
>> /mrg
>>
>> On Feb 11, 2009, at 11:14, Jonathan Reed wrote:
>>
>>> I have compiled the list of UID and GIDs less than or equal to 2000.
>>>
>>> Short answer:
>>> We lose as far as UIDs go, we lose slightly less as far as GIDs
>>> go. That's not to say we shouldn't do something, since this
>>> problem isn't going to go away, but...
>>>
>>> Raw data is in /mit/jdreed/release-team, acl'd to release-team and
>>> debathena-dev
>>> - users-affected contains uid, username, real name, and class
>>> - groups-affected contains gid, group name, "NFS" or "AFS", and a
>>> truncated description of the group.
>>> - The output is sorted numerically in the users-by-id and groups-
>>> by-id files
>>>
>>> Details below:
>>>
>>> ---------UIDs----------
>>> There are 1917 entries in moira with UIDs less than or equal to
>>> 2000, so the space is pretty full.
>>>
>>> Less than or equal to 100:
>>> - 6 users
>>> - 28 SYSTEM
>>> - 2 PROJECT
>>>
>>> 101 through 200:
>>> - 89 users (8 DOOMED)
>>> - 5 SYSTEM
>>> - 2 PROJECT
>>>
>>> 201 through 500:
>>> - 295 users (11 DOOMED)
>>> - 1 PROJECT
>>> - 2 SYSTEM
>>>
>>> 501 through 1000:
>>> - 487 users (24 DOOMED)
>>> - 7 SYSTEM
>>> - 4 PROJECT
>>>
>>> 1001 through 2000:
>>> - 983 users (65 DOOMED)
>>> - 5 SYSTEM
>>> - 1 PROJECT
>>>
>>> ---------GIDs----------
>>> There are 850 groups in moira with GIDs less than or equal to 2000.
>>> 469 of them are "user groups" (according to the description, anyway)
>>>
>>> NOTE: I included groups which are not currently NFS (Hesiod)
>>> groups. The raw data indicates whether or not they're NFS or AFS.
>>>
>>> Less than or equal to 100:
>>> 14 (5 user groups)
>>>
>>> 101 through 200:
>>> 25 (15 user groups)
>>>
>>> 201 through 500:
>>> 124 (45 user groups)
>>>
>>> 501 through 1000:
>>> 240 (92 user groups)
>>>
>>> 1001 through 2000:
>>> 447 (312 user groups)
>>>
>>
>
