How to let NIS client to find the NIS server on other subnet via broadcast?

[Jiang Li_1]

As NIS is widely used in unix infrastructure, it is bit common to have both NIS client and NIS server on different subnets.

For HPUX, we can use 'ypset' to specify the NIS server on NIS client because it can not find the NIS server via broadcast. This method has shortcoming, once the client lost network connection with NIS server, it will not automatically bind to NIS even the connection recovered.

To address this, I want to forward the NIS broadcast message to NIS server with the help of network team, but not sure if it is workable. Does anyone here have similar situtation? Do you know how to do that configuration on router? Can you share some better solution ?

By the way, we have some difficulties to setup another NIS slave server on one subnet.

Appreicate your inputs!
-Jiang

[Steven E. Protter]

Shalom,

ypmake on the server should push configuration to all slaves.

SEP

[Chandan Kumar_1]

Hi Jiang,

Check whether it helps..

http://docs.hp.com/en/5991-1153/ch04s05.html#bjadgbjd

Chandan K.

[A. Clay Stephenson]

Ypset is one method. The better way and what you should be doing is have two slave NIS servers (two for redundancy) on each subnet. Broadcasts then work exactly as they should and you will be bound to an NIS server "near" you. Your other option is to allow your routers to forward broadcast packets.

NIS is very useful but is considered to be far too insecure these days for most environments. The fundamental problem is that the password hashes are visible to all users and thus the network is vulnerable to a password guessing attack.

[Jiang Li_1]

Hi All,

Thanks very much for your quick reply on my question!

I'm sorry I forgot to mention that I'm talking HPUX10.20 systems which are NIS clients. I can not use 'ypinit -c' to set multiple NIS servers so that the client can query the other one if the primary NIS master server not available.

Setting up a NIS slave server on each subnet will be good solution for my case. But I can not find a stable system which can take NIS salve role on one subnet.

Thanks so much for your inputs!
-Jiang

[Steven E. Protter]

Well Jiang,

Linux systems work perfectly well as NIS clients of HP-UX masters.

I'd suggest just in case you have problems with that 10.20 box that you install HP-UX 11.11 on it first, if the hardware supports it.

Linux NIS slaves will work nicely for your subnet and can be throwaway pc's if they are still reliable.

Note that HP-UX standard installs can not be NIS clients of Linux because they can't handle the shadow password configuration of Linux.

SEP

[A. Clay Stephenson]

In that case, configure your router or gateway to forward broadcast packets. Exactly how that is done depends upon the router. I used NIS for many years on 10.20 without problems but that release is far out of date and out of support. There is no reason why you can't configure some Linux boxes or HP-UX workstations to be slave servers on any subnet.

[Jiang Li_1]

Hi Stephenson,

We tried to route the boradcast traffic (sunrpc 111 port) to NIS servers, but it still doesnot work. Do you have experience on how to configure router?

We are using 3-layer switch in our environment.

Thanks!
-Jiang

[rick jones]

IIRC, apart from "all ones" (255.255.255.255) what is a broadcast IP address in one subnet is _not_ going to be the broadcast address of another subnet (well, if they were nested netmasks I suppose...) so, if you have a machine on subnet A, and you want it to have something broadcast on subnet B, the machine in A has to send to subnet B's broadcast address and have that fowarded by the router.

And at this point, an obligatory bit about 10.20 - it is _well_ past its End Of Life date. Even 11.0 is past EOL now. While there is something to be said for "if it ain't broke, don't fix it" it might be a very good time to consider upgrading to something like 11iv2 (11.23) or even 11iV3 if your hardware supports it, or perhaps add-in upgrading to some newer hardware which does support the current OS revs.