NIS oddity when changing servers

I've a machine running Fedora Core 3 (2.6.11-1.14_FC3). It was previously
an NIS+ client of a Solaris machine. I changed /etc/nsswitch.conf to use
nis, and I changed /etc/yp.conf to use a new Linux NIS server.

I've gone so far as a full reboot. All *appears* right: 'ypwhich' and
'ypwhich -m' report the new NIS server and 'ypcat passwd' shows the proper
data.

Yet when I log in, I'm required to use the password from the NIS+ machine.

I've several machines that are running the same OS and (largely) the same
everything else. Yet only one this one machine have I found this odd
symptom.

My login doesn't have a presence in /etc/passwd or /etc/shadow on the
machine in question. The "passwd" line in /etc/nsswitch.conf is:

passwd: files nis

No nscd is running.

I'm at a loss on this. I'm guessing that the password is cached somewhere,
but how/where?

Any suggestions would be quite welcome.

- Andrew

Andrew Gideon wrote:
> I've a machine running Fedora Core 3 (2.6.11-1.14_FC3). It was previously
> an NIS+ client of a Solaris machine. I changed /etc/nsswitch.conf to use
> nis, and I changed /etc/yp.conf to use a new Linux NIS server.
>
> I've gone so far as a full reboot. All *appears* right: 'ypwhich' and
> 'ypwhich -m' report the new NIS server and 'ypcat passwd' shows the proper
> data.
>
> Yet when I log in, I'm required to use the password from the NIS+ machine.
>
> I've several machines that are running the same OS and (largely) the same
> everything else. Yet only one this one machine have I found this odd
> symptom.
>
> My login doesn't have a presence in /etc/passwd or /etc/shadow on the
> machine in question. The "passwd" line in /etc/nsswitch.conf is:
>
> passwd: files nis
>
> No nscd is running.
>
> I'm at a loss on this. I'm guessing that the password is cached somewhere,
> but how/where?
>
> Any suggestions would be quite welcome.
>
> - Andrew
>

Hello,

Is the new NIS(+) server the only NIS(+) server in your network?
Is it right that you changed not only the server but even from NIS+ to NIS?

NIS is a connection less communication. If you have more than one NIS
server in your network your client takes the information from the server
which is the first giving the answer.

I have seen in one of my installations that the passwd needs an entry
+:::: (dont know how many ::: to extend the search. Actually I dont
need it in my network. Never thought about it because everything works.
But maybe this is a point to start.

Or you have a look on your network with tcpdump to see if you are
getting NIS packets from a machine you dont expect.

BR
Hans-Juergen Lange

Hans-Juergen Lange wrote:

> Andrew Gideon wrote:
>> I've a machine running Fedora Core 3 (2.6.11-1.14_FC3). It was
>> previously
>> an NIS+ client of a Solaris machine. I changed /etc/nsswitch.conf to use
>> nis, and I changed /etc/yp.conf to use a new Linux NIS server.
>>
>> I've gone so far as a full reboot. All *appears* right: 'ypwhich' and
>> 'ypwhich -m' report the new NIS server and 'ypcat passwd' shows the
>> proper data.
>>
>> Yet when I log in, I'm required to use the password from the NIS+
>> machine.
>>
>> I've several machines that are running the same OS and (largely) the same
>> everything else. Yet only one this one machine have I found this odd
>> symptom.
>>
>> My login doesn't have a presence in /etc/passwd or /etc/shadow on the
>> machine in question. The "passwd" line in /etc/nsswitch.conf is:
>>
>> passwd: files nis
>>
>> No nscd is running.
>>
>> I'm at a loss on this. I'm guessing that the password is cached
>> somewhere, but how/where?
>>
>> Any suggestions would be quite welcome.
>>
>> - Andrew
>>
>
> Hello,
>
> Is the new NIS(+) server the only NIS(+) server in your network?

The new NIS server is just NIS; not NIS+. The old server is NIS+. Both are
currently running on the network (with the intention of removing the NIS+
server eventually).

Both are serving the same domain, so I have the yp.conf file specifying the
server name (as opposed to broadcasting a request for service).

[...]
> NIS is a connection less communication. If you have more than one NIS
> server in your network your client takes the information from the server
> which is the first giving the answer.

I don't think that that is true except at startup, and that only if ypbind
is told to broadcast a request. But I'm not sure, as I've not played with
slave-servers so I've never had two servers with which to experiment with
this.

Certainly: in this case, there's only the old NIS+ server and the new NIS
server.

>
> I have seen in one of my installations that the passwd needs an entry
> +:::: (dont know how many ::: to extend the search. Actually I dont
> need it in my network. Never thought about it because everything works.
> But maybe this is a point to start.

That's not something I'm needing on the other NIS clients I've successfully
switched.

> Or you have a look on your network with tcpdump to see if you are
> getting NIS packets from a machine you dont expect.

That I can check. More easily, I can shut down the NIS+ server and see what
happens. My guess is that this won't change anything, and that it'll turn
out that the client is caching. But it's just a guess, so I should check.

Andrew

Andrew Gideon wrote:

>> Or you have a look on your network with tcpdump to see if you are
>> getting NIS packets from a machine you dont expect.
>
> That I can check. More easily, I can shut down the NIS+ server and see
> what
> happens.

With the [old] NIS+ server completely down, the client still requires the
NIS+ server's password to log in.

I expected that. What I didn't expect is that the client fails to permit a
login if the [new] NIS server is down. This despite still requiring the
password that's in use on the NIS+ server.

Weird. Any suggestions?

- Andrew