'Production' improvements to pdb_ldap

Stefan (metze) Metzmacher metze at metzemix.de
Sun Oct 13 13:20:00 GMT 2002


At 14:02 12.10.2002 +1000, Andrew Bartlett wrote:
>Samba 3.0 is starting to be used in a lot of places, and I'm starting to
>look into how we can best ensure we don't get bottlenecks in our
>performance.
>
>Metze has raised a number of issues with pdb_ldap:
>
>  - We do a Get_Pwnam() on every user - even in enums.
>
>  - We hit the LDAP server for a new connection each time
>
>Both of these we have known about for a while - but it turns out that
>usrmgr asks for a list of all users (enum), then asks for each user by
>RID.  In his (quite large) setup, this can take so long that usrmgr
>times out!
>
>For the first problem, I am proposing that we use the uidNumber
>gidNumber etc in the user's ldap record directly - rather than going a
>Get_Pwnam() for that information.  Naturally, if that information is not
>present, we can do a Get_Pwnam anyway.
>
>However, the question is:  Should we make this the default?  It's fine
>for sites running nss_ldap, but it does change behavior.  Or should we
>add 'yet another smb.conf option', that admins would have to turn on if
>they are running such large domains?
>
>I would propose 'ldap trust uids' as the name, unless somebody comes up
>with a better one :-).

I would preferr 'ldap trust ids', because we later inlude gids also.


>For the second issue, we will just have to start caching connections -
>it doesn't look too hard, just a wrapper around the actual calls, but
>I've not had a chance to implement it.

We have to find a way to disconnect idle ldap connection and don't cache 
forever!

We basicly need pdb_* calls (ldap calls) in the auth and rpc_server stuff 
in smbd.

Maybe we can call a pdb_close function to do such stuff if the calling 
system won't use pdb_* calls for now( If the authentification is successful 
done, or the rpc pipe was closes...)



metze
-----------------------------------------------------------------------------
Stefan "metze" Metzmacher <metze at metzemix.de>




More information about the samba-technical mailing list