Hi Sean! On Thu, 11 Feb 2010, Sean Carolan wrote: > > But if --enableldap is changed to --disableldap, then the local users > > can log on and run sudo commands fine. This of course is all while > > the LDAP server is down. > > I may have narrowed down the problem a bit. Inside /etc/nsswitch.conf > there is a line that looks like this: > > group: files ldap > > It's as if the local system is searching for some group data on the > ldap server, but is never able to reach it so it just sits there and > hangs. If I remove the 'ldap' part from the end, logins work fine > with no issues even when the ldap server is down. > > So my questions are: > > 1. Why is this group line gumming up the entire authentication process? > 2. Do I need "ldap" on the group line? If I take it out how will it > affect my running systems? Answer to the "Why?" question: You may have groups in LDAP that you don't have locally. The server has no way to know. Those groups may include the person who just tried to log in. The only way to know if those groups exist is to look in LDAP and run through those groups to see if the person logging in is a member of any of them, so it *is* going to try if you've told it to check LDAP for group info. Your basic problem seems to be that that lookup is taking far too long to time out when the LDAP server is down. There are a lot of reasons this might happen, but with the setup we use here (which is very near identical to yours) the connection failure happens really fast, and PAM just moves on. That, of course, assumes the LDAP server is not running at all and not listening on port 389, which may or may not fit the definition of "down" as you're using it here. I should also probably note that this has probably not been an issue for me with the same setup partially because, here, LDAP's critical, and we make sure it's never down by using redundant systems, and it's really unlikely here that LDAP will ever be completely unavailable... and since we store login information there, I'd fully expect logins to fail if LDAP was totally unavailable... I'd actually *want* them to fail, since that's the one authoritative source of authentication we use. In the same way, if we used local files, I'd expect logins to fail if someone deleted /etc/shadow. By the way, you don't *need* the ldap in the group spec in nsswitch.conf... unless, of course, you want to access group information from LDAP, in which case you do. -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
