Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:35 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:07 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 14:53 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
> On Wed, 2008-08-27 at 12:34 -0400, Mark Hennessy wrote: >> I'm using CentOS 5.0,5.1, and 5.2 on several systems where
I'm seeing
>> this problem. >> >> Hello, I'm seeing a weird problem that perhaps someone has run into >> with groups. >> >> First, a little background. >> I was made aware of a problem with CentOS 5 where if the
nscd password
>> cache is clear and >> someone tries to log in if there is no network connection
with an LDAP
>> account that it >> just hangs. Even worse, if the machine is rebooted and it
continues
>> to have no network >> connection, even root login doesn't work. I messed around with >> nsswitch.conf to fix this >> problem. >> >> I altered these lines as so: >> passwd: files [!NOTFOUND=return] ldap >> shadow: files [!NOTFOUND=return] ldap >> group: files [!NOTFOUND=return] ldap >> >> and the problem seemed to go away. >> >> But now, here's the weird stuff: >> I have defined in my local /etc/groups file this line: >> group1:x:100:apache >> group2:x:101:apache >> >> 'getent group groupname' shows the right info: >> # getent group group1 >> group1:x:100:apache >> >> # sudo -u apache bash >> $ groups >> apache >> >> I revert back to my old config: >> # sudo -u apache bash >> $ groups >> apache group1 group2 >> >> Also, something else that's interesting. If I do this: >> passwd: files [!NOTFOUND=return] ldap >> shadow: files [!NOTFOUND=return] ldap >> group: ldap [NOTFOUND=continue] files >> >> and reboot, udev segfaults and the system freezes up after a few >> more seconds. >> Starting udev: /sbin/start_udev: line 43: 519 Segmentation fault >> "$@" $ARGS >> /sbin/start_udev: line 201: 523 Segmentation fault
/sbin/udevd -d
>> Wait timeout. Will continue in the background.[FAILED] >> >> Any advice? > ---- > Try putting this at the bottom of /etc/ldap.conf > > timelimit 30 > bind_timelimit 30 > bind_policy soft > nss_initgroups_ignoreusers root,ldap > > I wouldn't recommend the changes that you have in nsswitch.conf
Unfortunately, that doesn't work either. I made the changes, shut down the machine and started it without networking, and here's what happens:
login: root Password:
login:
login pukes and init starts it again.
you shouldn't need to restart but if you can't login as root, you probably still have something messed up in /etc/nsswitch.conf or may have messed up /etc/passwd | /etc/shadow
can you login as a user and su - to root?
if not, it probably would be best to boot to runlevel 1 and edit /etc/nsswitch.conf so it has this...
passwd: files ldap shadow: files ldap group: files ldap
and remove the NOTFOUND entries
Yes, done. Without networking, still the login failure trouble.
With networking, no trouble at all, but with those timeouts of 30 seconds and without those changes to nsswitch.conf, it takes a while for the first root login to succeed even though it is using local auth.
do you have this line in /etc/pam.d/system-auth
account sufficient pam_localuser.so
???
What does your /etc/pam.d/system-auth look like?
my /etc/pam.d/system-auth: #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pass debug auth required pam_deny.so
account required pam_unix.so broken_shadow account sufficient pam_succeed_if.so uid < 500 quiet account [default=bad success=ok user_unknown=ignore] pam_ldap.so account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok debug password required pam_deny.so
session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_ldap.so debug session required pam_mkhomedir.so skel=/etc/skel umask=0022
=== I added
account sufficient pam_localuser.so
right before pam_ldap in the account section and tried again with the same procedure (turn off networking (chkconfig --levels 2345 network off), reboot).
Same result, login dies and gets restarted.
login: root Password:
login:
well, it hardly makes any sense to use ldap for user accounts and start up with networking off but I would recommend that you adhere to the advice at the top of the file and run 'authconfig' or 'system-config-authentication', make sure the settings are correct (including checking the box for local authentication is sufficient) so that it configures not only /etc/pam.d/system-auth and nsswitch.conf
Yes, I agree, it makes no sense to operate a machine with ldap accounts if it has no network connection, but at least one should be able to log in as root. To clarify, here's the problem: I have a machine. In normal operation, the network connection is non-functional and LDAP accounts are usable and everyone does their thing over ssh. If the network connection craps out, I can get into the machine via serial console and try to find out what's going on, perhaps switch to a different network connection, whatever. If I can't log in as root, my only recourse is to powercycle the machine and go into single-user mode. Now, multiply that by 100. This is why I need to get this working.
Craig