My original question
---- 'afternoon all...When users try to log onto one of our IPCs they get the following message:
clntudp_create: RPC: program not registered Login incorrect
The IPC runs NIS and SunOS 4.1.1b. The YP server is a Sun 4/280 running SunOS 4.0.3
The IPC was set up as a client according to the manuals and this included making some new maps on the server (timezone and calling the server timehost).
This problem does not occur if the user has an entry in the passwd file (ie root can log in OK).
The problem occurs when logging into the host from the console or when using telnet. It does not occur when using rlogin.
Any Ideas? I'll summarise if interest warrants. ----
Well, here 'tis. The summary.
The problem was that rpc.pwdauthd was not running. It wasn't started in rc.local. Thanks to everyone who replied. Quite a few suggestions follow - I've listed them all below
From: mikem@juliet.ll.mit.edu
I remember seeing this message while trying to use a password adjunct file without the rpc.pwdauthd daemon running. The message was coming from the login process (which is bypassed in an rlogin) as it tried to validate a password via an rpc to the pwdauthd server.
If you're using an adjunct password file -- running ypbind 'secure', (with the '-s' option) make sure the code that starts rpc.pwdauthd is uncommented in /etc/rc.local - the startup code looks like this:
------------------------------------------ # # start up authentication daemon if present and if adjunct file exists # if [ -f /usr/etc/rpc.pwdauthd -a -f /etc/security/passwd.adjunct ]; then rpc.pwdauthd & (echo -n ' pwdauthd') >/dev/console fi ------------------------------------------
Hope this helps!
From: trr@lpi.liant.com (Terry Rasmussen)
One cheap way to find out what is going on is to use etherfind to watch the network traffic between the IPC and the yellowpages (oops I forgot, NIS) server when the telnet session or the attempted login is attempted, this will tell you if you have a networking problem. I doubt you have a networking problem.
When you login as root does ypwhich indicate that the correct ypserver is serving the client machine?
No doubt ftp works just fine, since rlogin works OK, but telnet does not work? This gets me to wondering what would happen if you were to re-install the OS from your existing on site OS media distribution. We are experiencing no problems with any of the 8 IPC's we have on site, purchased over the last 9 month (so they all most likely came from different production runs.) I will bet that there is something wrong with the installed OS and the installed libraries and a re-installation (yes I know how painfull that can be) from a known working set of media could remedy the situation. A good test would be to set up the machine as a diskless client and then see if the problem still persists.
From: Mike Raffety <oconnor!miker@oddjob.uchicago.edu>
Maybe your keyserv daemon isn't running?
From: bparent@calvin.UCSD.EDU (Brian Parent)
I've seen the same problem on my IPC's. My solution may not apply to your situation, but it might shed some light. I'm using shadowed passwords, and NIS, the NIS server being a Solbourne (a sun act alike in case you haven't heard of them, running something akin to SunOS 4.0.3 with bug fixes). If the server goes down, when it comes back up, I have the same problem that you described. (i.e. trying to login to an IPC yields an error message: clntudp_create: RPC: program not registered Login incorrect)
>From what I could tell, it was the rpc.pwdauthd daemon that wasn't cooperating. So, I've included in my /etc/rc.local on the NIS server a line that logs into each of the IPC's (20 of them), and kills off and restarts the rpc.pwdauthd. After that, all is well. Before I installed this rather klugy patch, I noticed that after some time, and a certain number of attempts, things would begin to work again, without any intervention. However, unlike your situation, we had the problem regardless of whether the login was through rlogin or telnet or direct.
From: mmikulska@UCSD.EDU (Margaret Mikulska)
Perhaps, just perhaps, your portmap on the server dies. This was a problem in 4.0.3. There is a Sun patch for this - a new, improved portmap. Just check on ps guax if portmap is running on the server when you have this problem.
From: vanandel@keel.atd.ucar.EDU
I've seen a problem like this when the password file contains entries like vanandel:##vanandel:1114:10:Joe VanAndel:/rsg/users/vanandel:/localbin/tcsh
The ##vanandel indicates use of the "shadow" password file stuff. If you haven't configured this on the offending machine, login is frustrated that it can't contact the "security' password RPC service.
From: stern@sunne.East.Sun.COM (Hal Stern - Consultant)
looks like an NIS problem. looks like your client is trying to contact the server but can't because the server's NIS daemon isn't running --OR-- because the ypbind daemon on the client was running and exited.
-- _ Name : Mark Ferraretto Title: Computing Officer \ \ Place : Department of Physics and Mathematical Physics || \ \ University of Adelaide ==========>==>==-- Aarnet: mferrare@physics.adelaide.edu.au || / / Phone : +61 8 228 5428 /_ / Phax : +61 8 224 0464
-- _ Name : Mark Ferraretto Title: Computing Officer \ \ Place : Department of Physics and Mathematical Physics || \ \ University of Adelaide ==========>==>==-- Aarnet: mferrare@physics.adelaide.edu.au || / / Phone : +61 8 228 5428 /_ / Phax : +61 8 224 0464
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:14 CDT