Quoting Craig White <craigwhite at azapple.com>: > On Wed, 2008-08-27 at 17:35 -0400, Mark Hennessy wrote: >> Quoting Craig White <craigwhite at azapple.com>: >> >> > On Wed, 2008-08-27 at 17:07 -0400, Mark Hennessy wrote: >> >> Quoting Craig White <craigwhite at azapple.com>: >> >> >> >> > On Wed, 2008-08-27 at 14:53 -0400, Mark Hennessy wrote: >> >> >> Quoting Craig White <craigwhite at 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 >