Yesterday it was brought to my attention that my users can no longer change their passwords. This is obviously a "bad thing"(tm).
When I try to change my password on a workstation (normal user account) I get this:
mezz@daisy:~$ passwd Changing password for mezz on NIS server Old NIS password: New password: Re-enter new password: pam_chauthtok: System error mezz@daisy:~$
if I use yppasswd the output is the same except the pam line is not there.
Even though `yppasswd` isn't throwing an error, it still isn't working. I've done everything I can think of short of rebooting the server. Perhaps if the labs clear out sometime today I will try that too.
I sent a copy of this by mistake to the DB category, I am re-posting this to the SA category too. (at least it can be argued that it is a DB issue being an NIS problem :)
2. Make sure /etc/ptmp does not exist. (This is a lockfile used by rpc.yppasswdd BEFORE it will do a ypmake, if it exists already no ypmake will occur.)
Shiju: I did some google searches yesterday when this issue first came to my attention and I did get that page back as a hit.
I'm not very pam savvy. I have no real idea how it works. The error I'm getting isn't listed or even mentioned on that page (or any other pages I can find).
I wish I got something like "PAM_TRY_AGAIN" so I would at least know the error was pam.conf. Of course I get the errors that don't get any google hits. :)
hmmm, that page says that pam_chauthtok "performs a preliminary check before attempting to update passwords".
Does anyone know what these checks are? Perhaps I have some sort of system service tied down too tight so its failing a check. (but then according to the www page it would reply with try_again and not a system error)
/etc/ptmp does not exist. Real bummer too because that would be a great solution :)
You did make me think of one interesting thing. I use `make` and not `ypmake` to manually push my map changes out. If memory serves the previous sysadmin modified make so it would push out auto.direct along with auto.master. If I try `ypmake` after an auto.direct change it does not push that map (or even acknowlege it). I have no idea if this is even relevent to my problem, but the makes came up so I decided it is worth a shot to mention.
one of the checks is to make sure the login is in wtmp, thats why you can't do a passwd from remsh, because it doesn't put an entry in wtmp. You have to be able to do who and see your terminal (/dev/ttyX) for that login
I'm not sure if this is or is not an issue when the users are setting their first initial password. It won't let me change my password either so I don't think its an issue (I show up in `who`).
Shiju:
Its the standard hp-ux 11.i pam.conf file but I'll post it anyway. Its small enough that I think a direct cut/paste will work (vs attachment)
That is a cut/paste from the server. Interestingly enough the workstations seem to have a different pam.conf file from the server. Here is one from a workstation:
That is how I've been changing passwords for my users. I'm in an academic environment and I need to change passwords for around 30 people at a time (whenever a class comes in for the first time).
As you can probably guess, thats not much fun. I would love for them to do it themselves (just like the previous quarters) :)
run the tty command at the promt and make sure you get a valid tty. if you don't that could be why the who isn't working. If you can't do a who | grep TTY (tty that shows up from the tty command) then you will not be able to run the passwd command
what OS version is your master NIS server? Also on the master can you make changes to password map and do a 'make'? see if it pushs the new map out with the change(s).
It was working around a month ago (known for a fact). Lots of little things have changed and the only thing I can think of that would even semi-relate to this is that I added a slave server and I did various tie-downs of network services to our subnet only.
I decided to bite the bullet and reinstall the master/client combo via SAM on the master server. That solved all my NIS problems. I'm not sure what bit got flicked but whatever it was, it caused havoc with my NIS setup.
Thanks for the help and great ideas guys.
Now I gotta work on the other problems... ::sigh::
