Bug#566844: failure in NIS setup
I tried sending this two weeks ago, but it bounced back with a CNAME
lookup failure. This will be my third attempt to send it (now with a
qmail patch applied -- I hope it's the right one...).
However, I learned a thing or two after the original message was sent,
which also need to be mentioned.
The original message:
> I ran into this bug on a standard NIS setup. Googling the error
> message led me to this, from 2003:
> Specifically, this part:
> The 'compat' option no longer works, you need
> passwd: files nis
> group: files nis
> shadow: files nis
> In your nsswitch.conf instead.
> Making that change fixed it for me. Or at least, I no longer get the
> (ignored) error message when I su from root down to the user's account.
> The user's out to lunch, so she can't test it directly on the console
> at the moment (which was the original situation I was trying to fix).
> In the interest of full disclosure, this lenny box is quite a bit behind
> on its security updates. I tried updating libc6, but that didn't help.
As it turns out, making the "passwd: files nis" change to nsswitch.conf
broke the ability to use "+username::::::/other/shell" in the local
passwd file to override the NIS-defined shell.
So, I had to change nsswitch back to "passwd: compat" and then find a
different workaround for the "can't login at all" problem.
It turns out, Debian is much more sensitive to the "+::::::" line that
goes at the end of passwd than Unix systems are (or at least, it is
when it's using "compat" instead of "nis"). On our Unix systems, we
have things like "+::-24:-24:::" at the end of /etc/passwd, and it's
always worked fine (I don't have a clue where the -24 came from).
On the Debian system, something changed the line to "+::0:0:::". I'm
not 100% sure, but I think it might have been an adduser command (there
is a whole group of people who have the root password, not just me --
I know that one of them attempted to add a user locally, and then
removed it later, but I don't know if that was what caused the change).
Long story short, "+::0:0:::" doesn't allow people to login (PAM refuses
to consult the NIS maps, it appears), but "+::::::" works. Similarly,
on the shell-override lines, "+username::0:0:::/shell" does not work,
while "+username::::::/shell" does.
Meanwhile, *something* was putting "+::0:0:::" in the file, though I
don't know whether that was a Debian program, or a direct human edit.
I hope someone finds this information useful.