HP-UX 11.11 NIS ypbind behaviour with ypset

[Peter Brook_1]

Hi,

I would like to use the ypset feature of ypbind to force NIS clients to particular NIS servers. I just wondered if anyone can confirm the behaviour of ypbind in the event of...

a) The preferred NIS server is unavailable when the NIS client starts,
b) If the peeferred NIS server becomes unavailable.

I assume that in both cases, ypbind will broadcast after the rpc timeout (40 secs?), and hopefully pick up another local NIS server. I'm afraid that I am unable to test this and cannot see any manuals, knowledgebase, forum hits which specify the behaviour in the event of a preferred NIS server problem.

Kit...
HP rp3440's running HP-UX 11.11

thanks in advance

[Steven E. Protter]

Shalom,

Ideal:
a) The Master for the whole organization answers and all is well.
b) The Master for the organization answers and al is well.

In practice this depends on how you configured the entire organizaation. I have found my recent NIS experience is that when the preferred server is unavailable, users can't log in.

This makes it important that you test this scenario.

SEP

[Victor Fridyev]

Hi,

If you define ypbind with ypset option and the pointed server failed, all its clients have problems with connections and commands responce time for all users grows till minutes.
AFAIK, broadcast is impossible in this case.
May be, you have a good reason for such a configuration, but my preference is NIS-slaves in each subnet, which permits broadcast connections for all clients.

HTH

[Dave Olker]

Hi Peter,

Your understanding of the ypbind -ypset behavior is correct. When you use the ypset syntax it forces the client to bind to a specific server, whether that server is on the local subnet or not.

If that server becomes non-responsive, the client will give up that binding and revert back to sending UDP broadcast packets. These can only be answered by an NIS server on the same subnet.

There is another preferred method of designating NIS servers that are not on the same subnet. You can use the "ypinit -c" command to specify a list of NIS servers to bind to. This allows you to configure multiple servers, even servers on different subnets, for the client to bind to. If the current server it is bound to fails it can contact one of the other servers in the list.

According to the ypinit man page:

-c Configures the local host as a NIS client, so
that the NIS client will attempt to bind to a
particular NIS server. Invocation of ypinit
with a -c option prompts the user to
construct a list of NIS servers, in the order
of preference, to which the client will try
to bind. This list of NIS servers is stored
in the file
/var/yp/binding//ypservers. In
order for ypbind to use this list of NIS
servers, ypbind should not be invoked with -
broadcast option. (see ypbind(1M) in
ypserv(1M)). If it is so desired that it is
not necessary for a NIS client to bind to a
NIS server in a particular list, the ypinit
-c installation mechanism could be ignored.


In my experience this is a much better way of controlling which NIS servers the clients will bind to, and what they will do in the event of a failure.

I hope this helps,

Dave

[Peter Brook_1]

Thanks to all of you for your comments.

Hopefully I will now be able to set the order in which NIS clients bind to NIS servers and they will still be able to re-bind using the broadcast method.

cheers!