> 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. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba