Package: nslcd Version: 0.7.9 Severity: important Hi,
I've a ldap client that is not my dns server and that get its IP (and gateway and DNS server) with DHCP. When nslcd is started and a first request to nslcd is done before /etc/resolv.conf is correctly filled, then this request fails (normal) but also any futur requests done (even after /etc/resolv.conf is correct). Step to reproduce on my system: ifdown eth0 ; sleep 2 ; (sleep 10 ; ifup eth0 ) & (sleep 5 ; id vdanjean ) & nslcd -d In this case, command "id vdanjean" gives: aya:~# id vdanjean id: vdanjean : utilisateur inexistant aya:~# id vdanjean uid=2001 gid=2001(vdanjean) groupes=4294967295,4(adm),20(dialout),24(cdrom),25(floppy),29(audio),44(video),46(plugdev),100(users),122(kvm),116(libvirt),125(freevo),10000(photos),3000 aya:~# [when I got the correct answer, it is after several seconds] Getting the good answer or the bad one depends on which thread/process (I do not know precisely how nslcd works) handles the request. If this is a thread launch before /etc/resolv.conf is correct, I got in the log: ========= nslcd: [1bd7b7] DEBUG: ldap_initialize(ldap://ldap.danjean.fr/) nslcd: [1bd7b7] DEBUG: ldap_set_rebind_proc() nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_PROTOCOL_VERSION,3) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_DEREF,0) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_TIMELIMIT,0) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_TIMEOUT,0) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT,0) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_REFERRALS,LDAP_OPT_ON) nslcd: [1bd7b7] DEBUG: ldap_set_option(LDAP_OPT_RESTART,LDAP_OPT_ON) nslcd: [1bd7b7] DEBUG: ldap_simple_bind_s(NULL,NULL) (uri="ldap://ldap.danjean.fr/";) nslcd: [1bd7b7] failed to bind to LDAP server ldap://ldap.danjean.fr/: Can't contact LDAP server: No such file or directory nslcd: [1bd7b7] no available LDAP server found ========= This is repeated several times. When I got an answer, I have the same kind of log, but I also have other threadsloging sucessful ldap requests such as: ========== nslcd: [8c895d] DEBUG: connection from pid=7998 uid=0 gid=0 nslcd: [8c895d] DEBUG: nslcd_group_bygid(2001) nslcd: [8c895d] DEBUG: myldap_search(base="dc=danjean,dc=fr", filter="(&(objectClass=posixGroup)(gidNumber=2001))") nslcd: [8c895d] DEBUG: ldap_result(): end of results ========== My guess is that, when a thread fails to resolve a name with the DNS due to a bad /etc/resolv.conf file, something is cached and latter ldap_simple_bind_s still fail. The correct fix for this bug would be to find where the info is cached and discard it in case of a failed connection. However, this is perhaps to intrusive for squeeze. For squeeze, you should be able to, at least, put a script in /etc/resolvconf/update-libc.d to restart nslcd when dns changes. Something as simple as: if [ -x /etc/init.d/nslcd ]; then /etc/init.d/nslcd restart fi Regards, Vincent -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages nslcd depends on: ii adduser 3.112 add and remove users and groups ii debconf [debconf-2.0] 1.5.35 Debian configuration management sy ii libc6 2.11.2-4 Embedded GNU C Library: Shared lib ii libgssapi-krb5-2 1.8.3+dfsg~beta1-1 MIT Kerberos runtime libraries - k ii libldap-2.4-2 2.4.23-4 OpenLDAP libraries Versions of packages nslcd recommends: pn libnss-ldapd <none> (no description available) pn libpam-ldapd <none> (no description available) pn nscd <none> (no description available) nslcd suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
