We help IT Professionals succeed at work.

NIS problems on Tru64 Unix

peltw
peltw asked
on
Our company has two development departments, one in town A and one in town B.
Both sites own a Digital Alphaserver 1200 machine running Tru64 Unix 5.1, patch 3.
The server in town A is NIS master, the one in town B is NIS slave.

Three months ago we relocated the server room in town A to a different building. As a result of this, the IP address changed, but the DNS name didn't. The change of IP address has caused a couple of interesting problems, but we have been able to solve them all.
One problem remains, although I'm not sure whether it has to do with the IP address change at all. The fact remains that the problem started the moment we switched on the server at his new location.

The problem has to do with NIS. When a user tries to change his password using yppasswd, the program waits for about a minute after the passwords have been entered and then the following output is generated:

    Changing NIS password for peltw
    Old NIS password:
    New password:
    Retype new password:
    RPC: Timed out

    Your NIS passwd may or may not be changed

I just love these descriptive messages ;-)

When I look in /var/adm/syslog.dated/current/auth.log, I see the following entries:

    Oct 17 10:13:43 server-a yppasswdd[230599]: yppasswdd: no change for peltw
    Oct 17 10:13:43 server-a yppasswdd[230599]: yppasswdd: no change for peltw

The funny thing is that the password HAS changed correctly. The change has even been distributed to the slave server.

As a probable side effect, the DiskAccess NFS client on our Windows NT machines fails to log on to the server (logs in with UID/GID -1/-2).

Together with the Compaq helpdesk I have been working on this problem for three months, but even the experts at Compaq are completely lost about this situation. Any help on this issue is greatly appreciated! (Too bad EE does not allow me to reward the question with more than 300 points. The first one who can help me, will get another 300 points one way or another!)
Comment
Watch Question

CERTIFIED EXPERT

Commented:
let's start at the basics:
what does this tell you on host A and host B?
    ypwhich
    domainname
    nslookup <DNS name of NIS master>

Author

Commented:

root@server-a# ypwhich
server-a.product.company.com

root@server-b# ypwhich
server-b.sub.product.company.com


root@server-a# ypwhich -m
auto.tools server-a.product.company.com
auto.master server-a.product.company.com
auto.home server-a.product.company.com
mail.aliases server-a.product.company.com
netgroup.byhost server-a.product.company.com
netgroup server-a.product.company.com
netgroup.byuser server-a.product.company.com
protocols.byname server-a.product.company.com
protocols.bynumber server-a.product.company.com
services.byname server-a.product.company.com
rpc.bynumber server-a.product.company.com
networks.byaddr server-a.product.company.com
networks.byname server-a.product.company.com
hosts.byaddr server-a.product.company.com
hosts.byname server-a.product.company.com
group.bygid server-a.product.company.com
group.byname server-a.product.company.com
passwd.byuid server-a.product.company.com
ypservers server-a.product.company.com
passwd.byname server-a.product.company.com

root@server-b# ypwhich -m
auto.tools server-a.product.company.com
auto.master server-a.product.company.com
auto.home server-a.product.company.com
ypservers server-a.product.company.com
services.byname server-a.product.company.com
protocols.bynumber server-a.product.company.com
protocols.byname server-a.product.company.com
passwd.byuid server-a.product.company.com
passwd.byname server-a.product.company.com
networks.byname server-a.product.company.com
networks.byaddr server-a.product.company.com
netgroup.byhost server-a.product.company.com
netgroup server-a.product.company.com
mail.aliases server-a.product.company.com
hosts.byname server-a.product.company.com
hosts.byaddr server-a.product.company.com
group.byname server-a.product.company.com
group.bygid server-a.product.company.com
netgroup.byuser server-a.product.company.com



root@server-a# domainname
swdev

root@server-b# domainname
swdev


root@server-a# nslookup server-a.product.company.com
Server:  dns06.campus.company.com
Address:  172.16.129.20

Non-authoritative answer:
Name:    server-a.building.company.com
Address:  172.16.213.247
Aliases:  server-a.product.company.com


root@server-b# nslookup server-a.product.company.com
Server:  dns.sub.product.company.com
Address:  172.17.238.8

Non-authoritative answer:
Name:    server-a.building.company.com
Address:  172.16.213.247
Aliases:  server-a.product.company.com

CERTIFIED EXPERT

Commented:
if you look at the nslookup results, you'll see that they do not match for server-a and server-b
Probably you should fix this first, then check again.

Author

Commented:
The only thing I see in the nslookup results is that server-a and server-b use a different DNS server, since there's no use in sending DNS requests all over the country when there is a local caching DNS server. Or am I missing something?
CERTIFIED EXPERT

Commented:
oops, DNS is ok. Checked the wrong IPs, sorry.
The only difference I can see is that server-a and server-b use a different NIS master (see ypwhich in you posting).
Usually the master does not change frequently, so it also might not change between the yppasswd call and the following login.

Looking at your question again, I see that there is just a warning in you NIS server's log file, and that login only fails from NT workstations and not the UNIX workstations.
This might be 'cause the NFS client caches some information, probably user/password. Could you please check your docs. Which NFS client are you using?

Author

Commented:
On our Windows NT machines we use DiskAccess NFS, on the servers we use the NFS that is built into the OS.

I don't think it's an NFS problem, though. When changing a password using the yppasswd utility, NFS should not be used at all. In an attempt to pin-point the source of the problem, I have just reconfigured NIS on both servers to define server-a as the NIS master and server-b as a simple NIS client (so there are no NIS slave servers in the domain). This does not change the behaviour of NIS, so I'm still getting the RPC timeouts and the error message "Your NIS passwd may or may not be changed" (when using yppasswd on server-a). It's the RPC timeouts that bother me most.
CERTIFIED EXPERT

Commented:
I'm out of ideas, sorry. Think you need someone who has access to a True64 to track down the problem.
Check the default route use :- netstat -ra
Commented:
We had the same problem (yppasswd RPC Timed out) after updating the server (4.0d -> Tru64 V5.1).
I've tried to start the NIS-Master without /var/yp/securenets - yppasswd works fine! But we need for security reasons the file securenets. I've added a new line in securenets for localhost (255.255.255.255 127.0.0.1) - yppasswd still works fine.

It seems to be a feature of Tru64 ( but it's nowhere documented).

Author

Commented:
That's the answer I have been waiting for. Thanks!

Explore More ContentExplore courses, solutions, and other research materials related to this topic.