I'm using RedHat 8 on my network and I'm having problems that all seem to relate to changing/creating a password for a user.

1- We have scripts using mkpasswd, and sometimes it works, sometimes it doesn't. Sometimes it'll show you what the password is, but it doesn't work (password is shown as "!!" in the shadow file); other times it'll just hang, and sometimes it gives an error saying RPC: can't encode arguments.

2- on our NIS server, performing the "passwd" command as root on a user produces the "RPC: can't encode arguments" error 9 time sout of 10.

3- on an NIS client, using the yppasswd command as root on a user sometimes produces a command that says "password not changed on [NIS servername]", and sometimes it works even with that message, and sometimes it doesn't work when it says the password was changed.

Off-hand, I don't recall what happens when a user tries to change their own password; I haven't heard any complaints so I'm under the assumption a user can change their own password using yppasswd. This has been quite a thorn in our side and no one has really had any luck or even ideas as far as what to do. I'm just about the least experienced out of everyone, and people are lookin @ me to try and get it done, so hopefully I can take care of it. Like the subject line says; my theory is that it's PAM, simply b/c all our errors are linked to changing/creating a password. Any ideas as to if it's PAM or not, and suggestions as to what to try and fix? The system was just recently updated w/ the RedHat network, but that didn't solve anything.


Thanks!!
jasonp

Tried running the procedure through strace? See exactly where it pops up?

i ran the strace utility on the passwd command. ie:
%strace -o filename passwd tempUser

i did this until i had one time when it worked and one time when it did not work. I made sure in both cases that i ran passwd the exact same (ie: i didn't mess up and have to retype the password a 2nd time. in both cases i enterred a password correctly on the first attemp. once it worked, once it didn't). I then looked through both files to see what happened and if it told me anything useful. While i really don't know squat about most of what was in there, i found the following details of interest.

after retyping the new password, the working case does a "recvfrom" that returns a 32. the failing case does a "recvfrom" which returns a 112. From there....


in the working case, after passwd prompted to retype the new password, it then went on to open /etc/passwd, and then apparently copy lines from /etc/shadow and /etc/nshadow. after that it renamed /etc/nshadow to /etc/shadow and then the passwd program wrote "all tokens updated successfully"

in the failing case, /var/yp/binding/(domainname).2 is opened, a bind to address 0.0.0.0 returned 0, a send returned 68, and a recvfrom returned 56. open /etc/resolv.conf was opended, a connect returned -1. open /etc/host.conf, open etc/hosts, then a bind returned 0, a sendto returned 56, and a recvfrom returned 28. a connect then returned a -1, /etc/hosts was opened, /etc/protocols was opened, bind returned 0, sendto returned 56, and recvfrom returned 28. a bind once again returned 0, and then after that passwd said "can't encode arguments".

So from what I can gather, when the passwd command doesn't work, it attempts to connect and send/recv to somewhere but it can't establish the proper connection. hopefully this means sometihng to someone, b/c i don't get it tho i realize it seems to be important...


thanks,
jasonp

I see it this way (not looking at the strace result, so MMMV)
In the failing case a connection is set up (socket, bind) by the NIS client (not passwd), then the client tries determine which NIS server to use (like ypwhich) using std libc procedure: look if we have means to resolve the name, if we can't read host.conf and check hosts. Then follows the client's session w/t server, which turns out ok, connection torn down and then passwd says "can't encode arguments".

I'd suggest running ypserv/passwdd in debug mode, just to be sure that end of the line is functioning w/o probs, and run your pam_unix passwd entry on the client side with the "audit" param: it'll put out logging at a higher level compared to "debug".

Now I ain't no NIS help, but IMHO if you really want to tackle this methodically you'll have to realize the "stacking" that makes up for NIS auth, like for instance RPC running over IP, so you have to make sure all the requirements for resolving etc etc are there, connections OK, (incl wrappers/fw access), then NIS itself with resolving the master, domain, (securenets etc etc), then NIS serv with the "+" passwd entries and the yp/makefile including MINUID's etc etc. And I haven't even thought of PAM issues.

Then somehow your problem seems related to a passwd locking problem, but I thought that was resolved in 2002.

Sorry, ain't not a big help in this.
//mod note: If you'd like I'll move it over to networking, maybe it gets the attention there it deserves...

edit: seems SuSE feature a pam_unix2 module that *migh* be better compared to the "old pam_unix", maybe an idea to try that.

if you think moving it to networking would provide more insight, by all means go for it! i'm going to look in to some of the stuff you mentioned and hopefully something will come out of it!

thanks,
jasonp