Package: libnss-ldapd
Version: 0.6
Severity: important
When using an LDAP server with a lot of groups in the LDAP three, it
might take a while to get it to start returning the result of the LDAP
search done by the setgrent()/getgrent()/endgrent() API.
When running commands like 'id username', it will return after a few
seconds, without any group information. I traced the problem, and was
able to see that nslcd received the reply from the server after the
client disconnected. This was with an Active Directory LDAP server,
and lots of lines like
nslcd: alias entry
CN=NOR-ANSATTE,OU=GrupperStandard,OU=NOR,OU=GS,OU=Skoler,DC=SKOLEN,DC=LOCAL
does not contain gidNumber v...
would show up. A workaround that solved this problem was to increase
the timeout used on the client part of nss-ldapd using this patch:
--- nss-ldapd-0.6.orig/nss/common.c
+++ nss-ldapd-0.6/nss/common.c
@@ -62,10 +62,10 @@
return NULL;
}
/* set the timeouts */
- readtimeout.tv_sec=2; /* looking up stuff may take some time */
+ readtimeout.tv_sec=20; /* looking up stuff may take some time */
readtimeout.tv_usec=0;
- writetimeout.tv_sec=1; /* nslcd could be loaded with requests */
- writetimeout.tv_usec=500000;
+ writetimeout.tv_sec=10; /* nslcd could be loaded with requests */
+ writetimeout.tv_usec=0;
/* create a stream object */
if ((fp=tio_fdopen(sock,&readtimeout,&writetimeout))==NULL)
{
Why are these timeouts so short?
This had the unfortunate side effect of increasing the time used by
the client program by several times this timeout. It seem to be that
the server fail to tell the client that the request has been handled,
and the client will then time out and try again. The client (id
username in this case) would also ask for the same result several
times, thus adding to the load of the LDAP server. This might be
related to the problem with servers returning only part of the search
result set. Perhaps this is the reason why the nslcd server to not
tell 'id' that it can not expect any more data?
Happy hacking,
--
Petter Reinholdtsen
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
