|
|
| Author |
Message |
| 25 new of 44 responses total. |
steve
|
|
response 13 of 44:
| 
Dec 9 18:43 UTC 1998 |
I'm not sure I understand your question, Dave. Can you ask it again?
|
davel
|
|
response 14 of 44:
|
Dec 10 04:07 UTC 1998 |
Just being picky, as usual, I'm afraid. Someone had suggested that
we decide whether limiting # of users or migrating (or other technological
fix, I think) is the policy we want to follow - and *then* discuss how to
implement the policy chosen. (Maybe I have it wrong; I'm not going back
to find the posting.) What I meant to say was this: we can't fully
judge those two policies without considering how to implement them, as
the implementations will have costs to Grex. If we decide to limit
the number of users, the question of what we'll have to do (shut off
newuser? reap accounts *very* frequently & quickly?) and how fast such
drastic measures might be needed (if they are) has a lot to do with
whether it's an attractive alternative. How easy a technical fix to UID
numbers would be, ditto for *that* alternative.
Probably still not very clear. Sorry.
|
steve
|
|
response 15 of 44:
|
Dec 10 05:51 UTC 1998 |
Well, hopefully we'll look at the possibilities and talk about
them in coop. We need to start talking of this in general now,
working towards what we'd like to do, and then see how feasible
that is. We might need a couple iterations of this.
Right now, the number of newusers has dropped a little, and
we're slowly growing. We've been at the 24K - 25K mark for a
while now. We will run out of UIDs eventually, but I think we
have a little time to think about the best approach for the
future.
|
remmers
|
|
response 16 of 44:
|
Dec 10 12:13 UTC 1998 |
Re resp:14 - I think I was the person who said something resembling
that. Didn't mean to imply that technical issues wouldn't play a role in
the discussions leading to a decision. My point was that there are
larger issues that everybody would need to be involved with, not *just*
the staff.
|
jep
|
|
response 17 of 44:
|
Dec 10 14:36 UTC 1998 |
Grex could probably free up a lot of UIDs by using a little more
aggressive reaping strategy. You can have one UID back right now;
'uohriman', my UUCP account, hasn't been used in at least 3 years, and
will never be used again. I glanced at /etc/passwd today, and noticed
that loginid kep has never been used, ldiot last logged in on September
3, 1997, and denise last logged in on January 14, 1998. Maybe all of
these accounts are being kept by request -- they're all very early users
and supporters of the system. But of the 25,000 current lines in
/etc/passwd, how many haven't logged in for a month? A third? Half?
More?
|
remmers
|
|
response 18 of 44:
|
Dec 10 18:03 UTC 1998 |
There would be tricky technical problems with simply re-using UID's
of canceled accounts, because programs use UID's to keep track of
who did what. For example, Picospan uses the UID to determine who
posted a response. If user 'foo' posts a response, then has his
account reaped, and user 'bar' runs newuser and happens to be
assigned the same UID, then bar would be able to expurgate foo's
response.
So we'll have problems when we hit the maximum UID *number*,
which will probably happen long before we're anywhere close
to the maximum volume of users.
The max UID number on our platform is 65535. The last account
created has UID 64011. Hmmm...
|
albaugh
|
|
response 19 of 44:
|
Dec 10 19:04 UTC 1998 |
I don't see any way around reusing UIDs. I would be ideal to reuse the least
recently reaped UIDs for new accounts, so that the delta t between reuse of
a UID would be greatest. But I don't know if that timing information is
available. As far as a new user of a UID going through picospan looking for
items that he could scribble, based on reuse of the UID, that is so bizarre
and unlikely that I don't think it's worth worrying about!
|
steve
|
|
response 20 of 44:
|
Dec 10 19:12 UTC 1998 |
Yes, we do reuse UID's, and have for quite some time, now. We're on our
third "pass" through the passwd file. What we've done when its time to
"rewind" the uid's is to create a new group for people in that next pass.
Originally, everyone was in group "people". Then we created "people" and
then "beings". We'll have to create another one soon, like next week and
then we're off on our forth pass through the passwd file. When newuser is
run, it looks for uid "n" (whatever that is), and sees if it exists already
under an older group. If it does, then it increments the number and tries
again. Once a free number is found, that newuser gets that uid.
What will happen, assuming continual growth, is that after we've gond
through the passwd file like 8 times or something, the "holes" in available
UID space will become smaller and smaller. At that point, once we have 0
free uids (but in many different groups) we'll have to ration new user
accounts in some manner.
|
steve
|
|
response 21 of 44:
|
Dec 10 19:28 UTC 1998 |
John asked about how many people have logged in since when.
Here is some data I have, that I created as I was doing some
other things. Note that the totals aren't exactly 100%, and
that some things like system accounts which aren't logged into
(bin, sys, etc) are here as well. But this should give a good
approximation of how used we are.
24,260 accounts total
Last Login num % cumulative %
Today 2021 8.3 8.3
1 - 7 days ago 4472 18.4 26.7
8 - 15 days ago 2995 12.3 39.0
16 - 30 days ago 3605 14.8 53.8
31 - 60 days ago 5994 24.7 78.5
61 - 90 days ago 5025 20.7 99.2
On the day I did this (middle of November?) just over half
of the accounts we had had been logged into in the last 30
days.
I once did a study (like in late '94) of the accounts that
hadn't been logged into in the 3-60 and 60-90 day range, to
see if the idea that "if they haven't logged in since then,
it doesn't matter if we kill them or not" was true.
That was basically true for the 60-90 group, but a surprising
number (like 25%) of the 30-60 group did login again (or, I
should say after 6 months of looking for those accounts,
they wern't in the reap files.)
|
jep
|
|
response 22 of 44:
|
Dec 10 20:17 UTC 1998 |
I didn't log in for around a year, but my loginid was preserved when I
came back. I had to ask the staff for my password. I'm grateful that
my account was kept. Nevertheless, if there's a conflict between
inactive people like I was, and new people coming in, I think it'd be a
bad mistake to give preference to the inactive ones. If a better
solution doesn't become implemented, I see at least a 5,000 UID reapable
buffer, and maybe 11,000 (room for 20-45% more additional growth).
|
rcurl
|
|
response 23 of 44:
|
Dec 10 20:38 UTC 1998 |
What is the specific feature that limits the number of uids?
|
steve
|
|
response 24 of 44:
|
Dec 10 21:21 UTC 1998 |
The design of the operating system. On SunOS (and nearly all other
UNIX's from that era) use a 16 bit unsigned integer, hence the limit
of 65535.
Some of the really old logins have been kept in the hopes that their
owners would come back. ;-)
|
rcurl
|
|
response 25 of 44:
|
Dec 11 05:06 UTC 1998 |
I guess I don't know enough about OS's - so I'll ask why there can't be
an A series and a B series....
|
krj
|
|
response 26 of 44:
|
Dec 11 05:24 UTC 1998 |
That UID number is used to associate things in the system, such as
files, with a specific user.
|
steve
|
|
response 27 of 44:
|
Dec 11 12:08 UTC 1998 |
Right. A uid (user id) is the essential identifier in the unix
operating system to differenciate each user.
And the B series of SunOS is called Solaris, which has long
integer uid's, capable of handling either two or four billion
users.
|
davel
|
|
response 28 of 44:
|
Dec 11 12:25 UTC 1998 |
And eventually there'll be a system that has to worry about using all *those*
up. I kind of hope it'll be Grex. 8-{)]
As far as STeve's statistics go: do those include as having logged in people
who post to conferences via Backtalk, even if they don't actually log in?
|
steve
|
|
response 29 of 44:
|
Dec 11 12:59 UTC 1998 |
Ah... do people who log in get updated in the lastlog file? Thats
what I base my stats on. Hmm. I should know the answer to that, but
I don't.
|
remmers
|
|
response 30 of 44:
|
Dec 11 13:16 UTC 1998 |
Hm, not quite sure what I was thinking when I posted #18, as I knew
about the new groups and the UID recycling. Memory must be getting
faulty in my advancing middle age. (Grex must be one of the only Unix
systems in the world that has to resort to that kind of stuff.)
|
aruba
|
|
response 31 of 44:
|
Dec 11 15:42 UTC 1998 |
Rane: The reason UIDs can't be bigger than 65535 = 2^16-1 is because that is
the largest number that can be stored in 16 bits = 2 bytes. The system, and
a lot of programs that run on it, only reserve two bytes for UIDs, so if the
UIDS got bigger than that (or if we tried to append a letter, and distinguish
between 23456A and 23456B) they wouldn't fit. Does that make sense?
|
remmers
|
|
response 32 of 44:
|
Dec 11 18:39 UTC 1998 |
(It's kinda like the Y2K problem...)
|
robh
|
|
response 33 of 44:
|
Dec 11 18:50 UTC 1998 |
Except that we know exactly when that problem is gonna hit us. >8)
|
richard
|
|
response 34 of 44:
|
Dec 11 22:51 UTC 1998 |
would it be feasible to change the reaping prog. so inactive accounts
are reaped after two months instead of three?
this would solve this right?
|
steve
|
|
response 35 of 44:
|
Dec 11 23:03 UTC 1998 |
No, it wouldn't.
It would free up a chunk of users upfront, thats true. but over time
we'd see the passwd file grow again.
If there are more new people than reaped ones, we grow in size. The
frequency of reaping would change things at the beginning, but if people
are going to look at the system and decide they don't like it, then it
doesn't matter if we reap them at 60 or 90 days. They're still going to
go. At the very end when we had like 63,000 users faster reaping would
matter a little, but only for a small portion of uid space.
I think we should keep the 90 day rule; it's saved many accounts in
the past, when people have become busy in their lives and haven't been
able to get here for a while.
|
rcurl
|
|
response 36 of 44:
|
Dec 12 00:25 UTC 1998 |
I was thinking that one could program a larger user database, but I
can see it getting very slow, with all the lookups that occur. Isn't
the limit really in being able to do it in the CPU? Could id's be
swapped in and out of the OS, since a lot of people aren't on much?
|
scott
|
|
response 37 of 44:
|
Dec 12 00:33 UTC 1998 |
It would be like swapping engines in your car on a more-than-daily basis.
|