peltw
asked on
NIS problems on Tru64 Unix
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/curr
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!)
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/curr
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!)
ASKER
root@server-a# ypwhich
server-a.product.company.c
root@server-b# ypwhich
server-b.sub.product.compa
root@server-a# ypwhich -m
auto.tools server-a.product.company.c
auto.master server-a.product.company.c
auto.home server-a.product.company.c
mail.aliases server-a.product.company.c
netgroup.byhost server-a.product.company.c
netgroup server-a.product.company.c
netgroup.byuser server-a.product.company.c
protocols.byname server-a.product.company.c
protocols.bynumber server-a.product.company.c
services.byname server-a.product.company.c
rpc.bynumber server-a.product.company.c
networks.byaddr server-a.product.company.c
networks.byname server-a.product.company.c
hosts.byaddr server-a.product.company.c
hosts.byname server-a.product.company.c
group.bygid server-a.product.company.c
group.byname server-a.product.company.c
passwd.byuid server-a.product.company.c
ypservers server-a.product.company.c
passwd.byname server-a.product.company.c
root@server-b# ypwhich -m
auto.tools server-a.product.company.c
auto.master server-a.product.company.c
auto.home server-a.product.company.c
ypservers server-a.product.company.c
services.byname server-a.product.company.c
protocols.bynumber server-a.product.company.c
protocols.byname server-a.product.company.c
passwd.byuid server-a.product.company.c
passwd.byname server-a.product.company.c
networks.byname server-a.product.company.c
networks.byaddr server-a.product.company.c
netgroup.byhost server-a.product.company.c
netgroup server-a.product.company.c
mail.aliases server-a.product.company.c
hosts.byname server-a.product.company.c
hosts.byaddr server-a.product.company.c
group.byname server-a.product.company.c
group.bygid server-a.product.company.c
netgroup.byuser server-a.product.company.c
root@server-a# domainname
swdev
root@server-b# domainname
swdev
root@server-a# nslookup server-a.product.company.c
Server: dns06.campus.company.com
Address: 172.16.129.20
Non-authoritative answer:
Name: server-a.building.company.
Address: 172.16.213.247
Aliases: server-a.product.company.c
root@server-b# nslookup server-a.product.company.c
Server: dns.sub.product.company.co
Address: 172.17.238.8
Non-authoritative answer:
Name: server-a.building.company.
Address: 172.16.213.247
Aliases: server-a.product.company.c
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.
Probably you should fix this first, then check again.
ASKER
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?
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?
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?
ASKER
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.
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.
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That's the answer I have been waiting for. Thanks!
what does this tell you on host A and host B?
ypwhich
domainname
nslookup <DNS name of NIS master>