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?
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
Craig
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.
Craig
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
Craig
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.
Craig
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?
Craig
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:
Craig
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
Craig
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
On Wed, Aug 27, 2008 at 2:56 PM, Mark Hennessy mark@hennessy.cx wrote:
Quoting Craig White craigwhite@azapple.com:
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.
Since you have now restated the problem, could you possibly edit your replies so as not to repeat the entire thread every time?
Thanks.
mhr
On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
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.
---- sounds like you're trying to fix a symptom, not the problem.
anyway, did you run authconfig/system-config-authentication ?
Craig
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
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.
sounds like you're trying to fix a symptom, not the problem.
anyway, did you run authconfig/system-config-authentication ?
Yes, I did in fact run it. here are the results: authconfig --enableldap --enableldapauth --ldapserver=ldap.example.com --enableldaptls --ldaploadcacert=file:///etc/openldap/cacerts/cacert.pem --test
caching is enabled nss_files is always enabled nss_compat is enabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is enabled LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap uid = "blah-blah" SMB idmap gid = "blah-blah" nss_wins is disabled pam_unix is always enabled shadow passwords are enabled md5 passwords are enabled pam_krb5 is disabled krb5 realm = "EXAMPLE.COM" krb5 realm via dns is disabled krb5 kdc = "kerberos.example.com:88" krb5 kdc via dns is disabled krb5 admin server = "kerberos.example.com:749" pam_ldap is enabled
LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" pam_pkcs11 is disabled
use only smartcard for login is disabled smartcard module = "coolkey" smartcard removal action = "Ignore" pam_smb_auth is disabled SMB workgroup = "WORKGROUP" SMB servers = "" pam_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_cracklib is enabled (try_first_pass retry=3 debug) pam_passwdqc is disabled () Always authorize local users is disabled () Authenticate system accounts against network services is disabled ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These last two lines look interesting.
Craig
On Wed, 2008-08-27 at 20:41 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
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.
sounds like you're trying to fix a symptom, not the problem.
anyway, did you run authconfig/system-config-authentication ?
Yes, I did in fact run it. here are the results: authconfig --enableldap --enableldapauth --ldapserver=ldap.example.com --enableldaptls --ldaploadcacert=file:///etc/openldap/cacerts/cacert.pem --test
caching is enabled nss_files is always enabled nss_compat is enabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is enabled LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap uid = "blah-blah" SMB idmap gid = "blah-blah" nss_wins is disabled pam_unix is always enabled shadow passwords are enabled md5 passwords are enabled pam_krb5 is disabled krb5 realm = "EXAMPLE.COM" krb5 realm via dns is disabled krb5 kdc = "kerberos.example.com:88" krb5 kdc via dns is disabled krb5 admin server = "kerberos.example.com:749" pam_ldap is enabled
LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" pam_pkcs11 is disabled
use only smartcard for login is disabled smartcard module = "coolkey" smartcard removal action = "Ignore" pam_smb_auth is disabled SMB workgroup = "WORKGROUP" SMB servers = "" pam_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_cracklib is enabled (try_first_pass retry=3 debug) pam_passwdqc is disabled () Always authorize local users is disabled () Authenticate system accounts against network services is disabled ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These last two lines look interesting.
---- I would think that authenticate system accounts against network services is disabled would be the setting that you want but the other...
always authorize local users should be enabled.
Also, I'm assuming that you've swapped out dc=example,dc=com for the real entries and will put in the real entries when you actually run the command.
Craig
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 20:41 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
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.
sounds like you're trying to fix a symptom, not the problem.
anyway, did you run authconfig/system-config-authentication ?
Yes, I did in fact run it. here are the results: authconfig --enableldap --enableldapauth --ldapserver=ldap.example.com --enableldaptls --ldaploadcacert=file:///etc/openldap/cacerts/cacert.pem --test
caching is enabled nss_files is always enabled nss_compat is enabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is enabled LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap uid = "blah-blah" SMB idmap gid = "blah-blah" nss_wins is disabled pam_unix is always enabled shadow passwords are enabled md5 passwords are enabled pam_krb5 is disabled krb5 realm = "EXAMPLE.COM" krb5 realm via dns is disabled krb5 kdc = "kerberos.example.com:88" krb5 kdc via dns is disabled krb5 admin server = "kerberos.example.com:749" pam_ldap is enabled
LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" pam_pkcs11 is disabled
use only smartcard for login is disabled smartcard module = "coolkey" smartcard removal action = "Ignore" pam_smb_auth is disabled SMB workgroup = "WORKGROUP" SMB servers = "" pam_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_cracklib is enabled (try_first_pass retry=3 debug) pam_passwdqc is disabled () Always authorize local users is disabled () Authenticate system accounts against network services is disabled ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These last two lines look interesting.
I would think that authenticate system accounts against network services is disabled would be the setting that you want but the other...
always authorize local users should be enabled.
Also, I'm assuming that you've swapped out dc=example,dc=com for the real entries and will put in the real entries when you actually run the command.
Your assumption is valid, and, in this case, correct.
After running that, I ran authconfig-tui and followed the prompts, including making local login sufficient, and then performed the test. It failed with the same issue, password accepted without claim of failure, no shell, new login prompt.
Craig
Mark,
Probe with this line:
authconfig --enablelocauthorize --updateall
Regards,
Alejandro www.linuxiso.com.ar Argentina
2008/8/27 Mark Hennessy mark@hennessy.cx
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 20:41 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
On Wed, 2008-08-27 at 17:56 -0400, Mark Hennessy wrote:
Quoting Craig White craigwhite@azapple.com:
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.
sounds like you're trying to fix a symptom, not the problem.
anyway, did you run authconfig/system-config-authentication ?
Yes, I did in fact run it. here are the results: authconfig --enableldap --enableldapauth --ldapserver=ldap.example.com --enableldaptls --ldaploadcacert=file:///etc/openldap/cacerts/cacert.pem --test
caching is enabled nss_files is always enabled nss_compat is enabled nss_db is disabled nss_hesiod is disabled hesiod LHS = "" hesiod RHS = "" nss_ldap is enabled LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" nss_nis is disabled NIS server = "" NIS domain = "" nss_nisplus is disabled nss_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" Winbind template shell = "/bin/false" SMB idmap uid = "blah-blah" SMB idmap gid = "blah-blah" nss_wins is disabled pam_unix is always enabled shadow passwords are enabled md5 passwords are enabled pam_krb5 is disabled krb5 realm = "EXAMPLE.COM" krb5 realm via dns is disabled krb5 kdc = "kerberos.example.com:88" krb5 kdc via dns is disabled krb5 admin server = "kerberos.example.com:749" pam_ldap is enabled
LDAP+TLS is enabled LDAP server = "ldap.example.com" LDAP base DN = "dc=example,dc=com" pam_pkcs11 is disabled
use only smartcard for login is disabled smartcard module = "coolkey" smartcard removal action = "Ignore" pam_smb_auth is disabled SMB workgroup = "WORKGROUP" SMB servers = "" pam_winbind is disabled SMB workgroup = "WORKGROUP" SMB servers = "" SMB security = "user" SMB realm = "" pam_cracklib is enabled (try_first_pass retry=3 debug) pam_passwdqc is disabled () Always authorize local users is disabled () Authenticate system accounts against network services is disabled ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ These last two lines look interesting.
I would think that authenticate system accounts against network services is disabled would be the setting that you want but the other...
always authorize local users should be enabled.
Also, I'm assuming that you've swapped out dc=example,dc=com for the real entries and will put in the real entries when you actually run the command.
Your assumption is valid, and, in this case, correct.
After running that, I ran authconfig-tui and followed the prompts, including making local login sufficient, and then performed the test. It failed with the same issue, password accepted without claim of failure, no shell, new login prompt.
Craig
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Mark Hennessy wrote:
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.
Phew, seems like people don't know how to trim posts around here!
Anyways, I suggest you install SSH keys on your systems, I've found I can authenticate with a system using an SSH key no problem even if LDAP is down.
I finally migrated off of LDAP this past weekend for my home network, files are so much simpler :)
(even for my work network with 300 systems)
nate
On Wed, Aug 27, 2008 at 05:07:26PM -0400, Mark Hennessy wrote:
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.
If you have ldap groups and the ldap server isn't reachable then logins _can_ take a long time (depending on why the ldap server isn't reachable; if a "telnet ldapserver ldap" returns immediately then it shouldn't) because a login has to go through _every_ group to determine if you're in the group or not.
It doesn't do a "getent group blah" it does the equivalent of while (getgrent()) { } which means it tries to parse the whole local _and_ ldap group entries.
It needs to do this to get your secondary group list.
Even root would need to do this.
On Wed, 2008-08-27 at 18:19 -0400, Stephen Harris wrote:
On Wed, Aug 27, 2008 at 05:07:26PM -0400, Mark Hennessy wrote:
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.
If you have ldap groups and the ldap server isn't reachable then logins _can_ take a long time (depending on why the ldap server isn't reachable; if a "telnet ldapserver ldap" returns immediately then it shouldn't) because a login has to go through _every_ group to determine if you're in the group or not.
It doesn't do a "getent group blah" it does the equivalent of while (getgrent()) { } which means it tries to parse the whole local _and_ ldap group entries.
It needs to do this to get your secondary group list.
Even root would need to do this.
---- that's why I suggested the changes to /etc/ldap.conf to time limit and to tell it not to bother with certain users
Craig
-
Alejandro -
Craig White -
Mark Hennessy -
MHR -
nate -
Stephen Harris