We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message: student1@linux:~> yppasswd yppasswd is deprecated, use /usr/bin/passwd instead Changing password for student1. Old Password: New password: Re-enter new password: yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error rpc.yppasswdd is running on the master server (rhserver). There are no slave servers. Using /usr/bin/passwd produces the same results. What is different about SuSE's NIS compared to RedHat? What are we missing? Mike -- Michael Williams Computer Information Systems The University of Akron
On Friday 03 September 2004 19:54, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
yppasswd is deprecated, use /usr/bin/passwd instead Changing password for student1. Old Password: New password: Re-enter new password: yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error
rpc.yppasswdd is running on the master server (rhserver). There are no slave servers. Using /usr/bin/passwd produces the same results.
What is different about SuSE's NIS compared to RedHat? What are we missing?
Mike
We asked the same question a few months ago. The only way we can change passwords on a homogenous 9.1 lan is for root to do it on the server and then rebuild the nis maps.
On Friday 03 September 2004 19:54, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
As this happens with both a rh9 and a SuSE9.1 NIS server then can we narrow the problem down to the SuSE NIS clients? (sorry, should have included this in my last posting) Steve.
No. The RedHat client-server installation worked perfectly. The SuSE client-server installation does not allow users to change passwords. I guess the next step is to setup a RH NIS server with SuSE clients to see if the problem is the server or client. The sad part is we may have to return to RedHat and hundreds of students will get the message that RH is superior to SuSE (which it is not). Fri, 2004-09-03 at 18:31, steve-ss wrote:
On Friday 03 September 2004 19:54, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
As this happens with both a rh9 and a SuSE9.1 NIS server then can we narrow the problem down to the SuSE NIS clients?
(sorry, should have included this in my last posting) Steve. -- Michael Williams, Ed.D. Professor, Computer Information Systems The University of Akron (330) 972-7385
On Saturday 04 September 2004 13:34, you wrote:
No. The RedHat client-server installation worked perfectly. The SuSE client-server installation does not allow users to change passwords.
I guess the next step is to setup a RH NIS server with SuSE clients to see if the problem is the server or client.
The sad part is we may have to return to RedHat and hundreds of students will get the message that RH is superior to SuSE (which it is not).
Fri, 2004-09-03 at 18:31, steve-ss wrote:
On Friday 03 September 2004 19:54, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
As this happens with both a rh9 and a SuSE9.1 NIS server then can we narrow the problem down to the SuSE NIS clients?
(sorry, should have included this in my last posting) Steve.
If we can set this up and it works with a rh nis server and a suse client then we have good grounds to file a bug report. I haven't done so as when we had it working (under the good old bulletproof 8.2) all hell let loose with students changing passwords and forgetting them before the next lesson. But we are dealing with secondary age kids here so we are happy it doesn't work in one sense but frustrated in that we'd like more responsible lan users to be able to avail themselves of the facility. I have a madrake free cd from a magazine. If I get time I'll set that up with a suse client except I think I'd have to setup the nis by hand. Meanwhile someone could save us a hell of a lot of time by letting us in on the secret ;) Cheers from Steve.
On Fri, Sep 03, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
yppasswd is deprecated, use /usr/bin/passwd instead Changing password for student1. Old Password: New password: Re-enter new password: yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error
rpc.yppasswdd is running on the master server (rhserver). There are no slave servers. Using /usr/bin/passwd produces the same results.
What is different about SuSE's NIS compared to RedHat? What are we missing?
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server? Not to say: it works fine for me. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Sunday 05 September 2004 07:14, Thorsten Kukuk wrote:
On Fri, Sep 03, Michael Williams wrote:
We recently switched from RH9 to SuSE for student use. We setup a NIS for student use using SuSE Linux I386 9.1 Professional. We set it up with YAST2 and added the appropriate auto.master and auto.home files. Everything works fine except students cannot change their passwords. When they try, they get the following message:
student1@linux:~> yppasswd
yppasswd is deprecated, use /usr/bin/passwd instead Changing password for student1. Old Password: New password: Re-enter new password: yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error
rpc.yppasswdd is running on the master server (rhserver). There are no slave servers. Using /usr/bin/passwd produces the same results.
What is different about SuSE's NIS compared to RedHat? What are we missing?
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server?
Not to say: it works fine for me.
Yes. I have a firewall. What port needs to be open?
On Sun, Sep 05, steve-ss wrote:
On Sunday 05 September 2004 07:14, Thorsten Kukuk wrote:
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server?
Not to say: it works fine for me.
Yes. I have a firewall. What port needs to be open?
The RPC one and the ones used by rpc.yppasswdd and ypserv. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Monday 06 September 2004 10:28, Thorsten Kukuk wrote:
On Sun, Sep 05, steve-ss wrote:
On Sunday 05 September 2004 07:14, Thorsten Kukuk wrote:
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server?
Not to say: it works fine for me.
Yes. I have a firewall. What port needs to be open?
The RPC one and the ones used by rpc.yppasswdd and ypserv.
Thorsten
Hi Thorsten. Hi Everyone. here is a snip from rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100004 2 udp 829 ypserv 100004 1 udp 829 ypserv 100004 2 tcp 832 ypserv 100004 1 tcp 832 ypserv 100009 1 udp 849 yppasswdd So from this I can guess that these ports need to be open. Is this correct? What confuses me is this: 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 3 udp 2049 nfs_acl 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl nfs works fine without any mention of 2049 on our firewall (SuSEfirewall2) Thanks, Steve.
On Mon, Sep 06, steve-ss wrote:
On Monday 06 September 2004 10:28, Thorsten Kukuk wrote:
On Sun, Sep 05, steve-ss wrote:
On Sunday 05 September 2004 07:14, Thorsten Kukuk wrote:
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server?
Not to say: it works fine for me.
Yes. I have a firewall. What port needs to be open?
The RPC one and the ones used by rpc.yppasswdd and ypserv.
Thorsten
Hi Thorsten. Hi Everyone.
here is a snip from rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100004 2 udp 829 ypserv 100004 1 udp 829 ypserv 100004 2 tcp 832 ypserv 100004 1 tcp 832 ypserv 100009 1 udp 849 yppasswdd
So from this I can guess that these ports need to be open. Is this correct?
Yes. But be aware: If you restart the services, this ports will change.
What confuses me is this: 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100227 3 udp 2049 nfs_acl 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100227 3 tcp 2049 nfs_acl
nfs works fine without any mention of 2049 on our firewall (SuSEfirewall2)
Could be that there is a special rule for NFS in the code or this is because nfs uses ports above 1024. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Monday 06 September 2004 20:15, Thorsten Kukuk wrote:
On Mon, Sep 06, steve-ss wrote:
On Monday 06 September 2004 10:28, Thorsten Kukuk wrote:
On Sun, Sep 05, steve-ss wrote:
On Sunday 05 September 2004 07:14, Thorsten Kukuk wrote:
The question is, why is the SuSE box not allowed to contact the rpc.yppasswdd daemon on the NIS master server? Are you really sure it is running? Are there any firewalls, /etc/hosts.{allow,deny} rules or similar? What can you find in the log files on the master server?
Not to say: it works fine for me.
Yes. I have a firewall. What port needs to be open?
The RPC one and the ones used by rpc.yppasswdd and ypserv.
Thorsten
Hi Thorsten. Hi Everyone.
here is a snip from rpcinfo -p program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100004 2 udp 829 ypserv 100004 1 udp 829 ypserv 100004 2 tcp 832 ypserv 100004 1 tcp 832 ypserv 100009 1 udp 849 yppasswdd
So from this I can guess that these ports need to be open. Is this correct?
Yes. But be aware: If you restart the services, this ports will change.
But surely there must be some way of making this permanent. Maybe a range of addresses? How do you overcome this on your firewall? TIA Steve.
Thorsten, steve-ss and others, I solved the NIS yppasswd problem. The error messages was: yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error The problem was with the clients not the server. The error message would lead you to think it was the server, but the server was never queried. The server was not known to DNS so an entry was needed in the /etc/hosts file. Perhaps the error message should be changed since it does not reflect the real error. Now everything works. Mike -- Michael Williams Professor, Computer Information Systems The University of Akron
Hi, On Mon, Sep 06, Michael Williams wrote:
Thorsten, steve-ss and others,
I solved the NIS yppasswd problem. The error messages was:
yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error
The problem was with the clients not the server. The error message would lead you to think it was the server, but the server was never queried. The server was not known to DNS so an entry was needed in the /etc/hosts file. Perhaps the error message should be changed since it does not reflect the real error.
I have no chance to print another error message: The RPC function only returns an error, not which error happens. But if you wish to use a more secure/reliable methode to change passwords: Look at rpasswd/rpasswdd. This does not transmit passwords in clear text over the network like yppasswdd is doing. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Mon, Sep 06, steve-ss wrote:
On Monday 06 September 2004 20:15, Thorsten Kukuk wrote:
On Mon, Sep 06, steve-ss wrote:
Yes. But be aware: If you restart the services, this ports will change.
But surely there must be some way of making this permanent. Maybe a range of addresses? How do you overcome this on your firewall?
We don't need a firewall on our NIS servers. They are behind our firewall and only have this ports open, which are needed. Doesn't make any sense to block unused ports with a firewall. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE Linux AG Maxfeldstr. 5 D-90409 Nuernberg -------------------------------------------------------------------- Key fingerprint = A368 676B 5E1B 3E46 CFCE 2D97 F8FD 4E23 56C6 FB4B
On Tuesday 07 September 2004 01:15, Michael Williams wrote:
Thorsten, steve-ss and others,
I solved the NIS yppasswd problem. The error messages was:
yppasswdd not running on NIS master rhserver.bustech.uakron.edu Error: Password NOT changed passwd: Authentication token manipulation error
The problem was with the clients not the server. The error message would lead you to think it was the server, but the server was never queried. The server was not known to DNS so an entry was needed in the /etc/hosts file. Perhaps the error message should be changed since it does not reflect the real error.
Now everything works.
Mike
Brilliant. Thanks, I would never have thought of that. It works fine. Cheers, Steve.
On Tuesday 07 September 2004 14:42, Thorsten Kukuk wrote:
On Mon, Sep 06, steve-ss wrote:
On Monday 06 September 2004 20:15, Thorsten Kukuk wrote:
On Mon, Sep 06, steve-ss wrote:
Yes. But be aware: If you restart the services, this ports will change.
But surely there must be some way of making this permanent. Maybe a range of addresses? How do you overcome this on your firewall?
We don't need a firewall on our NIS servers. They are behind our firewall and only have this ports open, which are needed. Doesn't make any sense to block unused ports with a firewall.
Thorsten
So is our NIS server. I think I've just understood something. Thanks, Steve.
participants (3)
-
Michael Williams -
steve-ss -
Thorsten Kukuk