On Monday, April 09, 2007 06:51:33 PM -0400 Marcus Watts <[EMAIL PROTECTED]> wrote:
Max user id is 851087 and max group id is -19786.
It's always fun to watch you demonstrate to someone that they're not really as big as they think they are. It helps the rest of us keep a sense of perspective. :-)
Older versions of ptserver had an option called "CROSS_CELL", which had some sort of split 16-bit assumption about viceIDs. We never ran with this at umich.edu, and the code seems to be gone in modern versions of openafs.
Actually, you're running that code now. The ptserver had some notion of foreign users as far back as the end of 1988, but it wasn't fully developed then; in fact, that code wouldn't let anyone create an entry with an '@' in its name, ever, though you could apparently create entries with PRFOREIGN set and no '@' in the name, even if you were an ordinary user!
The modern form of cross-cell authentication first appeared in AFS 3.2, along with the CROSS_CELL macro which enabled it. Starting in AFS 3.5, that functionality was turned on by default, and references to the CROSS_CELL macro went away.
Foreign users are identified by the presence of an '@' in their name, and can only be created if the corresponding system:[EMAIL PROTECTED] group exists. The group quota on that entry is used to control the number of users that can be created from that cell; when it runs out someone needs to add more in order to allow more users to be created.
ID's for foreign users are based on the ID of the corresponding system:[EMAIL PROTECTED] group. The low-order 16 bits of a foreign user ID are the same as those of the group; the high-order bits start at 1 and increment for each new user. If you have two foreign-cell groups whose ID's are the same in the low-order 16 bits, then users from those cells will have ID's drawn from the same namespace. In AFS 3.2, the allocation method was primitive; each foreign-cell group has a counter which records the next available ID for that cell; if that ID was not available, then no new users could be created in that cell until an admin created one with an explicit ID (drawn from the correct range). Today, the counter is still used, but only as an optimization; the ptserver starts from there and searches for the next available value, similar to what is done for user and group ID's.
So, there is a limit of 2^15-1 foreign users per cell, and a nominal limit of 2^31-1 users in total. However, before you reach 2^31-1 users, your PRDB will grow too large for Ubik to handle -- the DISK protocol can't handle file sizes or offsets larger than 2^31-1, and PTS entries are 192 bytes, which means you'll max out at around 11 million entries (including the extension blocks used when a user or group has more than 10 memberships). Of course, that's assuming you don't start having problems with recovery first.
Older unix systems had a 16-bit uid limit
Except Ultrix, which had a limit of exactly 32000, above which setuid() would fail :-)
-- Jeff _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
