On Thu, 6 Oct 2011, Stephen Harris wrote:
> On Thu, Oct 06, 2011 at 11:17:42PM +0100, John Hodrien wrote:
>> On Thu, 6 Oct 2011, Stephen Harris wrote:
>>> 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
>
> ldapsearch requires a new TCP connection; slow.
Right, so how often do you want to do a single query where performance is that
critical? SSSD maintains connections, so it's not one connection per query.
And slow is a very vague term:
time ldapsearch 'cn=someuser' >& /dev/null
real 0m0.017s
So with all the GSSAPI authentication and the TCP connection and finding the
right entry it takes how long? I know you were talking about more WAN type
connections, but persistent connections with SSSD should deal with that
performance hit shouldn't it?
>> 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
>
> Compound queries belong in a database.
Probably you're right, but as a user of LDAP is sometimes find need to do
them, and I'm not going to store the information twice.
> I wouldn't do that in NIS. Why would my OS care about it?. But I would
> do "tell me the path to the latest version of application X" 100s of times
> per minute.
Which should all be cached at the client side.
> ldapsearch adds massive overhead (2 orders of magnitude) to the return. The
> right tools for the job; fast lightweight efficient protocols for the OS
> where we get millions of calls; slower heavier weight calls for applications
> that make calls once a minute or slower.
If there are millions of calls you can't afford to be asking the network,
especially on things like this where odds are you're only talking about the
value changing relatively rarely.
>> 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
>
> getgrnam("foo") to see who is in a group is nice and efficient for
> a connection that's already open. initgroups (which _has_ to do
> a while(getrgrent()) loop) is slow. Logins and su and similar do
> initgroups.
Yes, but relatively few things do the former. You specify AllowGroups blah in
sshd_config, and ssh doesn't check who is a member of that group, it does an
initgroups instead.
>>> 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?
>
> ldapsearch doesn't use the connection manager. Unless you're now replacing
> tonnes of tools (and the perl Net::LDAP module and the python module and
> the apache LDAP module and...)
No, but for a lot of these things querying through nss is an option.
jh
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
