yp troubles

I've tried several times to get NIS to allow me to update passwords
from any of my machines and I still haven't gotten it to work.

I have 5 machines running FC3, one contains /home and the password
file. It runs ypserv and correctly distributes passwords and home
directories to the rest of the system.

On a client machine (running ypbind), I can run yppasswd and update
a password. This correctly changes the password on the server and
runs the Makefile in /var/yp to re-build the database. However, it
does not restart ypserv so the new database is not visible to the
rest of the system. That's problem one.

Problem two occurs on the server. I've tried running yppasswd to
update passwords both with and without yppasswdd running and with and
without ypbind running. In all cases, I get an error that looks like

yppasswd: unknown user (uid=***)

Where *** is either my user id if I'm running it as me or "0" if
I'm running it as root.

I've found a bit of conflicting information about which daemons
should be running on which machines so I'll ask that as well. My
current setup has
yppasswdd - only on server
ypbind - on all machines (though it appears unnecessary on server)
ypserv - only on server

I sure would appreciate a pointer to some help on how to get yppasswd
running correctly.

Thanks,
Brian McMinn
(and yes, mcminnspam@earthlink.net is a real e-mail address but
it doesn't get read unless I'm expecting e-mail.)

hi brian!

some time i did something with nis ... but i'll give it a try:

Brian McMinn wrote:
> On a client machine (running ypbind), I can run yppasswd and update
> a password. This correctly changes the password on the server and
> runs the Makefile in /var/yp to re-build the database. However, it
> does not restart ypserv so the new database is not visible to the
> rest of the system. That's problem one.

i'd say you can change the /var/yp/Makefile to kill -1 the ypserv process?

> Problem two occurs on the server. I've tried running yppasswd to
> update passwords both with and without yppasswdd running and with and
> without ypbind running. In all cases, I get an error that looks like
>
> yppasswd: unknown user (uid=***)

how do the /etc/passwd files look like on server/client?

> I've found a bit of conflicting information about which daemons
> should be running on which machines so I'll ask that as well. My
> current setup has
> yppasswdd - only on server
> ypbind - on all machines (though it appears unnecessary on server)
> ypserv - only on server

looks fine to me!

greetz d

On 2005-01-10, dominikschopper <dominik@taka-tuka.net> wrote:
> hi brian!
>
> some time i did something with nis ... but i'll give it a try:
>
> Brian McMinn wrote:
>> On a client machine (running ypbind), I can run yppasswd and update
>> a password. This correctly changes the password on the server and
>> runs the Makefile in /var/yp to re-build the database. However, it
>> does not restart ypserv so the new database is not visible to the
>> rest of the system. That's problem one.
>
> i'd say you can change the /var/yp/Makefile to kill -1 the ypserv process?

I tried manually HUPing the ypserv process and that doesn't cause it to
re-read the database. The docs say "kill -1" will cause ypserv to re-read
the config file and I expected it to re-read the database as well but
apparently it doesn't.

>
>> Problem two occurs on the server. I've tried running yppasswd to
>> update passwords both with and without yppasswdd running and with and
>> without ypbind running. In all cases, I get an error that looks like
>>
>> yppasswd: unknown user (uid=***)
>
> how do the /etc/passwd files look like on server/client?

The client passwd file contains ONLY the system ID's (UID's below 500).
The server passwd file contains exactly the same system ID's plus it
has the user ID's appended to it.

/etc/yp.conf contains only a single line defining the domain name.

/etc/ypserv.conf is something I've not edited.

The one thing I've discovered over the last few days is that I may have
/etc/nsswitch.conf wrong. Based on the Linux Network Admin Guide, it looks
like I want
passwd: nis files
group: nis files
My server has simply "files" here and my clients have "files nis" rather
than "nis files". I can't see why that would make a difference.

Thanks for the reply!

Brian

>
>> I've found a bit of conflicting information about which daemons
>> should be running on which machines so I'll ask that as well. My
>> current setup has
>> yppasswdd - only on server
>> ypbind - on all machines (though it appears unnecessary on server)
>> ypserv - only on server
>
> looks fine to me!
>
> greetz d

hi brian!

> I tried manually HUPing the ypserv process and that doesn't cause it to
> re-read the database. The docs say "kill -1" will cause ypserv to re-read
> the config file and I expected it to re-read the database as well but
> apparently it doesn't.

normally it should reread tha database anyway (as far as i rem. even
without HUP)

> The client passwd file contains ONLY the system ID's (UID's below 500).
> The server passwd file contains exactly the same system ID's plus it
> has the user ID's appended to it.

absolutely right. if i rem. correctly, there should be a line with
+:::
something like it as last file in the client-passwds?

> /etc/yp.conf contains only a single line defining the domain name.
>
> /etc/ypserv.conf is something I've not edited.
>
> The one thing I've discovered over the last few days is that I may have
> /etc/nsswitch.conf wrong. Based on the Linux Network Admin Guide, it looks
> like I want
> passwd: nis files
> group: nis files
> My server has simply "files" here and my clients have "files nis" rather
> than "nis files". I can't see why that would make a difference.

this defines where to look first:

passwd: files nis
means if a uid is requested, look into your files and then ask
nis-server

passwd: nis files
means first ask your nis-server and if it doesn't know, look into
your files.
normally you look into your files first.

which distrib. do you have? did you compile the nis yourself?
which nis-packages are installed? what do the system-logs say, when
the thing goes wrong?
if you want to ... i can dig for some example-files for you to check
(about 3yrs old!)

greetz

d

On 2005-01-11, dominikschopper <dominik@taka-tuka.net> wrote:
>> The client passwd file contains ONLY the system ID's (UID's below 500).
>> The server passwd file contains exactly the same system ID's plus it
>> has the user ID's appended to it.
>
> absolutely right. if i rem. correctly, there should be a line with
> +:::
> something like it as last file in the client-passwds?

This appears to be an old convention and it doesn't have any effect.
(I had to stop working on the home system for a few days and do some
"real" work so it's been a few days since you suggested this).

> which distrib. do you have? did you compile the nis yourself?
> which nis-packages are installed? what do the system-logs say, when
> the thing goes wrong?

I'm running FC3, pretty much stock.

The system logs were a great idea. Here's what I learned from them...
When I change my password from a client machine, the server machine's
/var/log/messages shows two lines:

Jan 14 23:21:11 server rpc.yppasswdd[28631]: update dumbuser (uid=500) from host 192.168.1.12 successful.
Jan 14 23:21:11 server ypserv[2022]: refused connect from 127.0.0.1:955 to procedure ypproc_clear (,;0)

This indicates to me that the remote password update actually occurs (and
the timestamps in the /var/yp files would agree) but that something bad
happens when the local ypserv process attempts to update itself after that.

I dug into the docs for ypserv and sure enough, I've got my /var/yp/securenets
file mis-configured (many other Linux'es use /etc/ypserv.securenets instead).
I added the line
host 127.0.0.1
to securenets and then everything started working the way I expected it to.
Now I can update any user password from any machine and the update is
immediately visible to every other machine!

Thanks for the pointer that got me close enough to the answer to figure it
out!

Brian

nice helping you, sorry that i didnt find the example files must be
somewhere on the hundreds of cds ...

d