3. NIS, NYS or NIS+ ?

3.1. libc 4/5 with traditional NIS or NYS ?

The choice between "traditional NIS" or the NIS code in the NYS library
is a choice between laziness and maturity vs. flexibility and love of
adventure.

The "traditional NIS" code is in the standard C library and has been
around longer and sometimes suffers from its age and slight
inflexibility.

The NIS code in the NYS library requires you to recompile the libc
library to include the NYS code into it (or maybe you can
get a precompiled version of libc from someone who has already done it).

Another difference is that the traditional NIS code has some support
for NIS Netgroups, which the NYS code doesn't. On the other hand
the NYS code allows you to handle Shadow Passwords in a transparent
way. The "traditonal NIS" code doesn't support Shadow Passwords over NIS.

3.2. glibc 2 and NIS/NIS+

Forgot all this if you use the new GNU C Library 2.x (aka libc6). It
has real NSS (name switch service) support, which makes it very flexible,
and contains support for the following NIS/NIS+ maps: aliases, ethers, group,
hosts, netgroups, networks, protocols, publickey, passwd, rpc, services
and shadow. The GNU C Library has no problems with shadow passwords over NIS.

3.3. NIS or NIS+ ?

The choice between NIS and NIS+ is easy - use NIS+ only if you have
severe security needs. NIS+ is much more problematic to administer
(it's pretty easy to handle on the client side, but the server side
is horrible). Another problem is that the support for NIS+ under Linux
contains a lot of bugs and that the development has stopped.