Re: after upgrade, cannot su or sudo

[Rob Owens <rowens@ptd.net>]

On Wed, May 08, 2013 at 11:30:25AM -0600, Bob Proulx wrote:
> Rob Owens wrote:
> > Currently my system seems to be working fine except that I can't su or
> > sudo from my regular user.  I can log in as root.  My users are all LDAP
> > authenticated.  
> 
> First, I don't know.  But it does seem like there might be an LDAP
> interaction with sudo.  Are you using "sudo-ldap" package for sudoers
> in ldap too?  Or just sudo?
> 
I'm just using sudo, as I have been for Lenny and Squeeze.  But I'll
give sudo-ldap a try if I can't get this working.

> > So maybe I just talked myself out of believing this is a a pam
> > problem...
> 
> Check 'getent passwd USERNAME' and 'getent group GROUPNAME' to verify
> that your accounts are getting looked up okay.  (Just brainstorming
> ideas.)
> 
Yeah, I tried that.  It works.  LDAP lookups seem to be working
properly.

> > Back to LDAP.  I saw some reference to unscd as a possible replacement
> > for nscd.  I doubt LDAP is my real problem here, because local logins
> > and ssh password logins work find. 
> 
> I have had problems with nscd before.  It tends to reorder entries in
> a non-traditional way.  The file order is not preserved.  It can
> therefore produce different results than when not using it.  I
> consider that a serious bug but others disagree.  I therefore always
> remove nscd whenever I encounter it.
> 
Hmm, I thought nscd was required when I installed libnss-ldapd.  Seems
it's not (anymore).  But removing it hasn't fixed anything.  Neither has
installing unscd.

> > Any suggestions where to look next?
> 
> Check /var/log/auth.log for any message there?
> 
I'm getting sudo messages like "auth could not identify password for
[rob]"

And "authentication failure" for su.

I'm going to have to check my pam files against the current
documentation.  They used to work, but maybe something has changed.

> Check 'sudo -l' to list the user's sudo status dump?
> 
User rob may run the following commands on this host:
    (ALL) ALL

> Sorry, no answers, just hopeful brainstorming.
> 
Thanks, it at least got me to look at auth.log again.  I swear that
stuff wasn't in there before...

-Rob