[Samba] Re: ldap machine suffix fixed?

[Adam Tauno Williams]

> OK, so what I am hearing is that:
> 1. It is still a problem.
> 2. But it isn't a Samba problem, it is an nss_ldap problem.
> 3. There might be some work arounds.
> Possible workarounds:
> A. Burry the Two OU's one deeper and do a subtree search on the parent
> OU. Works but not scaleable.

I disagree on the "not scaleable" claim.  NSS *MUST* see all valid posix
accounts,  so you're going to perform one sub search or *TWO* one-level
searches?  I'll put my money on the former as a better (and faster)
solution.  If your nss search is slow -

1. Fix your indexes
2. Tune your DSA
3. Run nscd (you can also increase the nscd cache size if you have lots
of active users, x > ~200)

All three should be standard practice anyway.

> B. Add "filter" keyword to uh... Is it /etc/ldap.conf or
> nss_switch.conf? Syntax?

nss performs all searches with an objectclass filter and searches for
uid and uidNumber are equality searches; any properly configured DSA is
going to be able to chunk through thousands of such searches per minute;
and if your caching it won't even have to.

And set your various bases in NSS -
nss_base_passwd        ou=Entities,ou=SAM,dc=whitemice,dc=org
nss_base_shadow        ou=Entities,ou=SAM,dc=whitemice,dc=org
nss_base_group         ou=Groups,ou=SAM,dc=whitemice,dc=org

Still to slow?  (You must have tens of thousands of users).  You can
either run a local replicant just for the local Samba & NSS that you can
communicate with via the UNIX domain socket (way faster than TCP/IP) or
run a local proxy cache backend (also using the UNIX domain socket).
Most of our user apps like address books and what are aimed through a
proxy, because those are the kind of searches that slow things down, and
it performs wonderfully.

> Am I in the right ballpark here? :-)

There is no problem.  The 'problem' results from a failure to properly
conceptualize the situation.