Large number of users (was: Cannot add machine with latest
Luke Kenneth Casson Leighton
lkcl at switchboard.net
Mon May 31 03:34:03 GMT 1999
> > > 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
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.
More information about the samba-ntdom