Comment 35 for bug 155947

From my point of view the problem is not located in the nss_ldap but in nss_compat/nss_files.

I have 2 servers. Both have a local openldap server running.

I have following lines in nsswitch.conf

passwd: compat ldap
group: compat ldap
shadow: compat ldap

And I have configured following lines in ldap.conf on the affected server

host 127.0.0.1 172.17.7.15

And I have following lines in /etc/passwd

syslog:x:101:102::/home/syslog:/bin/false
klog:x:102:103::/home/klog:/bin/false

I should never see any ldap queries on server 172.17.7.15 during the boot process of the affected server, because all needed information should be in /etc/passwd.

But when I enabled logging on the ldap server 172.17.7.15(which is already up and running) I can see following lines:
conn=16 fd=21 ACCEPT from IP=172.17.7.201:52540 (IP=0.0.0.0:389)
conn=17 fd=22 ACCEPT from IP=172.17.7.201:52542 (IP=0.0.0.0:389)
conn=16 op=0 BIND dn="" method=128
conn=16 op=0 RESULT tag=97 err=0 text=
conn=17 op=0 BIND dn="" method=128
conn=17 op=0 RESULT tag=97 err=0 text=
conn=16 op=1 SRCH base="dc=schule,dc=loc" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=syslog))"
conn=17 op=1 SRCH base="dc=schule,dc=loc" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=klog))"
conn=17 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
conn=17 op=2 SRCH base="dc=schule,dc=loc" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=klog))"
conn=17 op=2 SRCH attr=gidNumber
conn=17 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
conn=17 fd=22 closed (connection lost)
conn=16 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
conn=16 op=2 SRCH base="dc=schule,dc=loc" scope=2 deref=0 filter="(&(objectClass=posixGroup)(memberUid=syslog))"
conn=16 op=2 SRCH attr=gidNumber

As you can see, the affected server is trying to look up the uid's of the accounts syslog and klog from the ldap directory. This should never happen, as these information are stored in /etc/passwd and nss_compat/nss_files should be able to lookup these informations already. nss_ldap should never get a request for these accounts.