campbell@dataco.UUCP (Duncan Campbell) (06/28/91)
Howdy, can anyone tell me how many user accounts SCO SystemV 3.2.2 can support? 100? 1000? more? less? Just accounts, not simultaneous use. Thanks, Duncan ***--------------------------------------------------------------*** * DISCLAIMER: * * ==========: * * The opinions expressed are solely of the author and do not * * necessarily reflect the opinions of Canadian Marconi Company. * ***--------------------------------------------------------------***
sef@kithrup.COM (Sean Eric Fagan) (06/28/91)
In article <665@fudd.dataco.UUCP> campbell@bung.UUCP (Duncan Campbell, VOR) writes: >Howdy, can anyone tell me how many user accounts SCO SystemV 3.2.2 >can support? 100? 1000? more? less? Just accounts, not simultaneous >use. Assuming infinite disk space, it should be somewhere around a) 65435: 2**16 (65536) - 1 - 100 (you shouldn't use a UID of less than 100; they're "reserved" by AT&T) b) Infinite, it you choose to share UID's. Actually, not infinite, as the passwd file (etc.) has a limit of less than 4Gigabytes (maximum filesize determined by the hardware [32-bit ints and longs], kernel, compiler, and filesystem). I have heard of, through various customers I communicated with (back when I was at sco, that is) of people having upwards of a thousand accounts on the system (although only a few would be in use at any one time). -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.
rbraun@spdcc.COM (Rich Braun) (06/29/91)
campbell@bung.UUCP (Duncan Campbell, VOR) writes: >>Howdy, can anyone tell me how many user accounts SCO SystemV 3.2.2 >>can support? 100? 1000? more? less? Just accounts, not simultaneous... sef@kithrup.COM (Sean Eric Fagan) writes: >Assuming infinite disk space, it should be somewhere around > a) 65435: 2**16 (65536) - 1 - 100 (you shouldn't use a UID > of less than 100; they're "reserved" by AT&T) A number of years ago, I maintained a DEC-10 system at the University of Delaware with over 9,000 user accounts. The limitation isn't the size of the integers used to identify users, but rather the speed with which the password and/or other accounting files can be scanned. The DEC-10 O/S was shipped with source code, so I modified the LOGIN program to do a binary-tree search of the password file. Most Unix systems, including SCO I'm sure, do a linear search of /etc/passwd (in addition, SCO keeps user records in the /tcb/files/auth tree) before asking for the user's password. This can become painfully slow if the file gets large and the system isn't fast. Therefore you need to correspond with someone who is now using SCO Unix to manage a large number of users, rather than to simply be told that the physical maximum is 64K or thereabouts. A 100-entry password file, by the way, would definitely not be considered "large", and I suspect a 1000-entry file wouldn't make things too slow--but I don't speak from personal experience with large password files on a 386. The 'grep' program has no problem with multi-thousand-line files, though. -rich
ti@bazooka.Altos.COM (Ti Kan) (06/30/91)
In article <665@fudd.dataco.UUCP> campbell@bung.UUCP (Duncan Campbell, VOR) writes: >Howdy, can anyone tell me how many user accounts SCO SystemV 3.2.2 >can support? 100? 1000? more? less? Just accounts, not simultaneous >use. That depends upon the length of the account names. SCO UNIX's sysadmsh has a braindead behavior where it adds all accounts you create into the /etc/group file under "group" by default. As a result, the group line can get quite long after you add a hundred accounts or so. So long that you can't vi it. Sysadmsh shell has internal buffer limits that if the group line exceeds it, it will either core dump or otherwise misbehave. The typical limit is about 100 to 150 accounts before this happens (the group line exceeds 1024 bytes long). I don't recommend removing entries from the group file however, since with all that security magic, even in relaxed mode, you might mess something up. -Ti -- /// Ti Kan /// Internet: ti@bazooka.altos.com ///// UUCP: ...!{uunet|sun|sco|apple|amdahl|pyramid}!altos!bazooka!ti /// vorsprung durch technik!