On Thu, 6 Oct 2011, Stephen Harris wrote: > Which, up until a few months ago, was "no client". Solaris is crap (they > recently rewrote their caching infrastructure to make it better); AIX > is crap (with it's own unique solution and persistent connections). > HPUX is crap.... ;) > Oh wait... what this really means is that _LDAP_ is crap at performance and > each and every client needs to have massive kludges and work-arounds > (that aren't necessary with NIS) in order to resume some semblence of > usability. Only I don't buy into that. Too much of NSS assumes that linear searching through the user information is the quickest route, and that's just plain dumb in complicated setups with more advanced sources of information (like LDAP). > And once you move out of normal naming services and into custom maps then > your LDAP world of pain gets even worse; I'll always be able to do a > "ypmatch" quicker than an ldapsearch. Why? GSSAPI means I don't have to provide any authentication information, and ldapsearch isn't that annoying. ypmatch is far cruder than ldapsearch, so while a simple search with ypmatch might be quicker, compound queries end up being much easier with ldapsearch. List me all of the users who work in a given department who have access to a given resource and tell me their display name and phone number. ldapsearch makes that simple. If you want to go a step further (and personally I don't) store their ssh public keys in LDAP. >> nss_getgrent_skipmembers true > > You might as well not use secondary groups at all, then! I *did* say that nss_ldap is broken! I was actually quietly surprised at how few things look to see who is a member of a group rather than query which groups a user is a member of. Even with this set, 95% of things works perfectly with secondary groups. Unfortunately chgrp and newgrp don't work without patching, which is a pain. But most things do an initgroup and don't worry about the group actually containing no members. > Dammit; why didn't UDP based LDAP ever take off? That would have helped, > a lot! Is the connection side that big a deal when you've got a daemon managing persistent connections to the servers? jh