Large number of users (was: Cannot add machine with latest CVS)

[Luke Kenneth Casson Leighton]

> > > Hmm setgrent appears in 3 files (aliasunix.c,groupunix.c,builtinunix.c) are all
> > > these mutually exclusive?
> > 
> > possibly not.  imagine a situation in which a group enumeration occurs, it
> > gets group info (members of the group).  the group enumeration could call
> > getgrent, and the enumeration of the group members could do likewise.
> > 
> > what about getting the primary user's group and the users' group members?
> > etc.
> > 
> > so it's all riddled with awkward horrible stuff and i'm giving serious
> > consideration to cacheing the unix group -> nt rid data using
> > groupdb/aliasfile.c,groupfile.c and builtinfile.c.
> > 
> > the enumeration algorithms for *unix.c are probably order n squared at
> > least, and for them to be fixed properly then need to be order n cubed,
> > which is horrible.
> 
> Is this still an issue?

yes.  it has been marginally improved with a unix-passwd "cache" which is
known to crash (circumstances unknown) with pass->pw_name = NULL from
somewhere (reported recently).

the code was proof-of-concept and written 6 months ago or so.

the ideal solution is to have an off-line unix-to-nt conversion tool that
starts you off by creating private/aliasfile, private/groupfile and
private/builtinfile. thereafter, it can be managed by USRMGR.EXE and
rpcclient, doing any order-n-squared algorithm checks at user interface
speeds.

and yes, the speed would be greatly increased by using ldap _if_ the ldap
schemas have room for rid+gid [in alias, group and builtin lookups] and
rid+uid [in user lookups] because the conversion / verification from nt
names to unix names (and uids to rids) is what takes such a horrible
amount of time.

luke