When a system has been configured using pam_ldap nss_ldap an ldap server and nsswitch.conf has the passwd and group fields set to "ldap files" as opposed to "files ldap", halt.sh quits after unmounting filesystem where INIT then quits claiming that there are no other processes left in this runlevel. the restart or shutoff function then no longer works and you are forced to perform a reset. Reproducible: Always Steps to Reproduce: 1. install pam_ldap nss_ldap and an ldap server (Openldap in my case) 2. configure nsswitch.conf passwd and group fields to "ldap files" (in that order) 3. make sure pam is set up to authenticate over ldap 4. verify that the system is using ldap for its user information 5. try to restart the machine, Actual Results: after a series of messages you finaly get "Unmounting Filesystems" which does not produce an OK or a failure then you get INIT there are no more processes in this runlevel (I'm doing this from memory I hope it right) Expected Results: Reboot normally note if you change the fields from "ldap files" to "files ldap" the system will reboot fine. This can cause dataloss as the filesystem are not unmounted cleanly, I can see that the system reports dirty filesystems when it is rebooting. I haven't lost any data yet but it is very possible that it can happen.
Robin, any idea why this is happening?
if you use 'ldap files' you should be using 'ldap [UNAVAIL=continue] files' networking and any local ldap should have gone down by that point, so 'ldap files' can cause a system lockup (which something in halt.sh could timeout from and just die because of). 'files ldap' avoids the issue as there shouldn't be any lookups of something that isn't in the files database.
Although it doesn't specifically state it in the manpages it seems like UNAVAIL=continue would be the default setting. I have tried ls -l on a directory that has both local users and ldap based users and using "ldap files" and "ldap [UNAVAIL=continue] files" and have noticed no difference in responce times while shutting off and turning on the ldap server. Oddly enough if I simply pull the network plug and try the same thing it freezes. Even if I change the setting back to "files ldap" it freezes. It is as though as long as the server machine can say ldap is not here it fails over to the other lookup system, but if the network is gone it will sit there looking for the service so far indefinetly. If I have it set to "files ldap" and look at a directory that only has local users and groups then it goes though without a hitch even though the network is gone. I'll have to try a restart on my home machine as the server here can't be rebooted right now.
do you have nscd running?
No but what a cool program :-)
You SHOULD be using nscd with nss_ldap! if you can reproduce this with nscd running then come back on reopen the bug.
Ok starting nscd will screw up winbind, I just noticed that, I seem to remember reading about nscd causing problems with winbind now that I had the name resolution problem after starting it again, Our network has SAMBA and Windows Domains trusting each other so shutting of winbind is not an option, that is the reason for the tight ldap integration. I may have to keep "files" first but there is an annoying side effect, when there is a local wheel group it takes presidence over the ldap based one. If I delete the local wheel (which luckly does not seem to have any other side effects) I can again use "su" to be root on the servers and clients.
why not use winbind in nsswitch then, instead of ldap directly.
Winbind has some limited ability and several of our services do not have pam capability nscd does conflict with winbind (plus it is not a very fast protocol). I think there are more problems with the all of these working together as even with "files ldap winbind" I have trouble getting our LDAP server to start. I don't know if this is considered or a configuration issue an I'm just trying to do too much at once. I even noticed our postfix server claiming it started but not running after a recent reboot. I think it tried to start before ldap did so that may have caused to to quit. Unfortunatly I can't reboot this server again for a while is there a way to influence the start sequence without modifying the scripts in init.d?
No, modifying the scripts in init.d is the only way to affect the start sequence, AFAIK
