Very Computer

At my last job (the University of Colorado), we used an in-house package
which worked in tandem with a centralized UID database. (Yes, Jeff, I wish
I had DURM/Uniquid here. :)

Here at Western, we have a relatively new Internet domain with only a few
UNIX machines (as yet) and I've been charged with developing a system
to manage accounts and keep the UID's straight.  We will probably develop
our own system, but I'd like to see other ideas if you want to share them.

At a minimum, our platforms will include (old) SunOS, Solaris, DEC Ultrix,
Unixware, SCO ODT, Linux, and HP-UX.  Other possible platforms are IBM AIX,
and Dell SVR4.

If you know of any interesting packages (this doesn't really fit an
archie search :), public domain or otherwise, I'd appreciate it if you
would let me know about it.

I will summarize and repost if there is interest.

Thanks,

Scott
--
J. Scott Farrow                              UNIX/VAX Technical Support
Martin Marietta - DOE/Western Area Power Administration, Golden, CO USA

Quote:>I'm interested in finding out what other UNIX admins are doing to manage
>and keep consistent UID's and GID's across multiple platforms in the same
>domain.

Is there universal agreement on what id numbers are reserved for local
use?  What is the upper limit?  our sys/types.h defines uid_t as
unsigned long, but I remember a thread a while back where an attempt to
use employee numbers caused an overflow.
--

--Pierre Asselin, Magnetoresistive Head Engineering, Applied Magnetics.

--

At least in our version of ls (sequent symmetry running dynix
3.0.17.9), there was a table with 4000 slots that was used to cache
names for uids between 0 and 3999.  The code looked something like:

    if (uid >= 0 && uid < 4000) {
        if (Name_cache[uid] == NULL)
            look_up_uid_in_password_file_and_put_name_in_cache();
        Name = Name_cache[uid];
    } else {
         Name = look_up_uid_in_password_file_and_return_name();
    }

For uids < 4000, the name was cached, but for uids >= 4000, the
password file was being repeatedly scanned.

When we started creating users with uids in the 4000-6000 range, ls -l
got really slow, particularly on directories with lots of files owned
by users with uids >= 4000.  I checked the source for ls and
discovered the 4000 entry name cache.  After increasing the size of
the cache to 8000 things sped up again.

-stuart
--

Trandes Corporation                             +1 301 459 0200
On-Contract-To: David Taylor Research Center    +1 301 227 1428