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

[Joachim Kupke]

On 10 Dec 1998, Luke Kenneth Casson Leighton wrote:

> On Wed, 9 Dec 1998, Greg Dickie wrote:
> 
> > 
> > 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? I have been using the head cvs version of Samba
for about half a year in an educational environment now (irregularly
having updated the server) after having got used to it in my private
environment before. User data is exported from some postgres database
to /etc/passwd, /etc/shadow, /etc/group and ...samba/private/smbpasswd.

I am noticing that with an increasing number of accounts (about 350 by
now) logon performance drops rapidly. Since we are planning to include an
even greater number of users into the database (1227, in order to speak
exactly), I seriously consider using LDAP or some other form of data
source for Samba, just in order to improve logon velocity.

In fact, using an AMD K6 266 Mhz server running Linux 2.0.36 without even
touching any swap memory, logon of bottom-listed persons in smbpasswd may
take almost a minute. The environment is likely to have all possible
18 workstations logon simultaneously, resulting in logon completion after
more than 10 minutes only.

Considering an order n squared, I fear that with 1200 users, all logins
taken together will last more than an hour then, what would be completely
inacceptable then. Could perhaps at least someone point out where in the
code user validation, etc. could be modified? (Even a Samba with a hard
coded user database would be acceptable if only it was faster.)

Before "simply" trying it, I would like to discuss another issue: Deploying
NT by disk duplication. Classically, this is a no-no, since obviously
computer names should be different and less obviously, some internal SIDs
must be different among workstations communicating with each other. Now
if I put all workstations into different logical subnets (and thus
preventing them to find their own names in different computers) and quite
concludingly if I ran as many different Sambas as there are workstations,
all listening in those different subnets on the same aliased net interface
(having to cope a little with mostly redundant password files -- only the
trust account should be separate, of course), wouldn't it then be possible
to use the "same" NT a couple of times simultaneously? Any comments?


Sincerely
Joachim Kupke