[KLUG Members] Re: slow ldap authentication

agencies_ad1 at sancharnet.in agencies_ad1 at sancharnet.in
Fri Jan 13 02:32:15 EST 2006


Quoting Joe Baker <joebaker at dcresearch.com>:


> Komal, might I suggest that the name resolution isn't setup properly on the
> machine with the 15 second delays.  Typically daemons on the system like to
> log the hostname that is making the connection, so the hosts file is
> consulted, then other services such as NIS, WINS, DNS and maybe even
> additional LDAP queries.  /etc/nsswitch.conf is typically the file that is
> used for configuring the order of presidence for these name resolver
> services.  Add on top of this that many LANS don't have a local DNS zone
> setup and you can begin to see that there is much room for improvement in the
> name resolution arena.
> 
> Try creating a client host name in /etc/hosts on the slow server like this
> 
> 192.168.0.35	testhostname.nelfc.com
> 
> And then initiate a SSH, FTP, SMB connection from .35 and see if that helps. 
> If not, then I'm likely wrong in my guess.
> 
> Good Luck Komal,
>
Hello,

When I am on the ldap client (.35) and nss uses ldap components to query a
remote a ldap server (10.1.1.202 or 10.1.1.203), it uses the ip address as
shown in my /etc/ldap.conf file I provided. So, from the client side, name
resoltion does not come into play, thus nsswitch for hosts would not matter
here, right? When I am on the client and I su as some ldap user, they delay is
experienced. I have not even considered ssh/ftp/smb into this ldap client from
let's say another machine just yet. I want to start with the basics. If su is
slow, then everything should be slow as su uses nss which uses files aand then
ldap. nss using files for passwd has been fast. If su can be fixed then
ssh/ftp/smb access into this ldap client will fall into place. I am focusing on
the ldap client's relationship with an LDAP server. BTW - The delay grows
longer if the user is further down the ldap tree of users. On RHEL 3 AS and
RHEL 2 AS with (or without nscd) this has not been an issue. It has always been
pretty fast. It is just with RHEL 4 AS (U1 or U2) where the ldap client
experiences the delay. Again, to sum up...the first query is slow as nscd
caches it. The subsequent query is instantaneous. And on RHEL2 and RHEL3 this
has not been an issue with or w/o ncsd. It is fast all the time.


Thanks

Regards,

Komal

----------------------------------------------------------------
This message was sent using NWebmail, BSNL's Webmail Program



More information about the Members mailing list