The Network Information System
When you're running a local area network, your
overall goal is usually to provide an environment for your users that makes the
network transparent. An important stepping stone is keeping vital data such as
user account information synchronized among all hosts. This provides users with
the freedom to move from machine to machine without the inconvenience of having
to remember different passwords and copy data from one machine to another. Data
that is centrally stored doesn't need to be replicated, so long as there is
some convenient means of accessing it from a network-connected host. By storing
important administrative information centrally, you can make ensure consistency
of that data, increase flexibility for the users by allowing them to move from
host to host in a transparent way, and make the system administrator's life much
easier by maintaining a single copy of information to maintain when required.
We previously discussed an important example of
this concept that is used on the Internet—the Domain Name System (DNS). DNS
serves a limited range of information, the most important being the mapping
between hostname and IP address. For other types of information, there is no
such specialized service. Moreover, if you manage only a small LAN with no
Internet connectivity, setting up DNS may not seem to be worth the trouble.
This is why Sun developed the Network
Information System (NIS).
generic database access facilities that can be used to distribute, for example,
information contained in the passwd
and groups files to all hosts on
your network. This makes the network appear as a single system, with the same
accounts on all hosts. Similarly, you can use NIS to distribute the hostname information
from /etc/hosts to all machines
on the network.
is based on RPC, and comprises a server, a client-side library, and several
administrative tools. Originally, NIS
was called Yellow Pages, or YP, which is still used to refer to it.
Unfortunately, the name is a trademark of British Telecom, which required Sun
to drop that name. As things go, some names stick with people, and so YP lives
on as a prefix to the names of most NIS-related commands such as ypserv
is available for virtually all Unixes, and there are even free implementations.
BSD Net-2 released one that has been derived from a public domain reference
implementation donated by Sun. The library client code from this release had
been in the Linux libc for a
long time, and the administrative programs were ported to Linux by Swen
Thümmler. An NIS server is missing from the reference
Peter Eriksson developed a new implementation
called NYS. It supports both plain NIS and Sun's much enhanced NIS+. NYS not only provides a set of NIS tools and a server,
but also adds a whole new set of library functions that need to be compiled into
your libc if you wish to use it.
This includes a new configuration scheme for hostname resolution that replaces
the current scheme using host.conf.
The GNU libc, known as libc6 in the Linux community, includes an
updated version of the traditional NIS
support developed by Thorsten Kukuk. It supports
all of the library functions that NYS provided and also uses the enhanced
configuration scheme of NYS. You still need the tools and server, but using GNU
libc saves you the trouble of
having to meddle with patching and recompiling the library.
This chapter focuses on the NIS support included in the GNU libc rather than the other two packages.
If you do want to run any of these packages, the instructions in this chapter
may or may not be enough. For additional information, refer to the NIS-HOWTO or
a book such as Managing NFS and NIS by Hal Stern (O'Reilly).
1. Getting Acquainted with NIS
keeps database information in files called maps, which contain key-value
pairs. An example of a key-value pair is a user's login name and the encrypted
form of their login password. Maps are stored on a central host running the NIS server, from which
clients may retrieve the information through various RPC calls. Quite
frequently, maps are stored in DBM files.
The maps themselves are usually generated from
master text files such as /etc/hosts
or /etc/passwd. For some files,
several maps are created, one for each search key type. For instance, you may
search the hosts file for a
hostname as well as for an IP address. Accordingly, two NIS maps are derived from it, called hosts.byname and hosts.byaddr. Table 13-1 lists common maps
and the files from which they are generated.
Some Standard NIS
Maps and Corresponding Files
Maps IP addresses to host names
Maps IP network addresses to network names
Maps encrypted passwords to user login names
Maps Group IDs to group names
Maps service descriptions to
Maps Sun RPC service numbers to RPC service
Maps protocol numbers to protocol names
Maps mail aliases to mail alias names
You may find support for other files and maps in
packages. These usually contain information for applications not discussed in
this book, such as the bootparams
map that is used by Sun's bootparamd server.
For some maps, people commonly use nicknames,
which are shorter and therefore easier to type. Note that these nicknames are
understood only by ypcat and ypmatch, two tools for checking your
configuration. To obtain a full list of nicknames understood by these tools,
run the following command:
|$ ypcat -x
Use 'passwd' for 'passwd.byname'
Use 'group' for 'group.byname'
Use 'networks' for 'networks.byaddr'
Use 'hosts' for 'hosts.byaddr'
Use 'protocols' for 'protocols.bynumber'
Use 'services' for 'services.byname'
Use 'aliases' for 'mail.aliases'
Use 'ethers' for 'ethers.byname'
server program is traditionally called ypserv. For an average network, a
single server usually suffices; large networks may choose to run several of
these on different machines and different segments of the network to relieve
the load on the server machines and routers. These servers are synchronized by
making one of them the master server, and the others slave servers.
Maps are created only on the master server's host. From there, they are
distributed to all slaves.
We have been talking very vaguely about
“networks.” There's a distinctive term in NIS
that refers to a collection of all hosts that share part of their system
configuration data through NIS: the NIS domain.
domains have absolutely nothing in common with the domains we encountered in
DNS. To avoid any ambiguity throughout this chapter, we will therefore always
specify which type of domain we mean.
domains have a purely administrative function. They are mostly invisible to
users, except for the sharing of passwords between all machines in the domain.
Therefore, the name given to an NIS
domain is relevant only to the administrators. Usually, any name will do, as
long as it is different from any other NIS
domain name on your local network. For instance, the administrator at the
Virtual Brewery may choose to create two NIS
domains, one for the Brewery itself, and one for the Winery, which she names brewery and winery
respectively. Another quite common scheme is to simply use the DNS domain name
for NIS as
To set and display the NIS domain name of your host, you can use the
domainname command. When invoked without any argument, it prints the
domain name; to set the domain name, you must become the superuser:
NIS domains determine
server an application will query. For instance, the login program on a
host at the Winery should, of course, query only the Winery's NIS server (or
one of them, if there are several) for a user's password information, while an
application on a Brewery host should stick with the Brewery's server.
One mystery now remains to be solved: how does a
client find out which server to connect to? The simplest approach would use a
configuration file that names the host on which to find the server. However,
this approach is rather inflexible because it doesn't allow clients to use
different servers (from the same domain, of course) depending on their
availability. Therefore, NIS implementations
rely on a special daemon called ypbind to detect a suitable NIS server in their NIS
domain. Before performing any NIS
queries, an application first finds out from ypbind which server to use.
ypbind probes for servers by broadcasting
to the local IP network; the first to respond is assumed to be the fastest one
and is used in all subsequent NIS
queries. After a certain interval has elapsed, or if the server becomes
unavailable, ypbind probes for active servers again.
Dynamic binding is useful only when your network
provides more than one NIS
server. Dynamic binding also introduces a security problem. ypbind
blindly believes whoever answers, whether it be a humble NIS server or a malicious intruder. Needless
to say, this becomes especially troublesome if you manage your password
databases over NIS.
To guard against this, the Linux ypbind program provides you with the
option of probing the local network to find the local NIS
server, or configuring the NIS
server hostname in a configuration file.
DBM is a simple database management library
that uses hashing techniques to speed up search operations. There's a free
DBM implementation from the GNU project called gdbm, which is part of most Linux distributions.
2. NIS Versus NIS+
NIS and NIS+ share little more
than their name and a common goal. NIS+ is
structured entirely differently from NIS.
Instead of a flat namespace with disjoint NIS
uses a hierarchical namespace similar to that of DNS. Instead of maps,
so-called tables are used that are made up of rows and columns, in which
each row represents an object in the NIS+ database and the columns cover
properties of the objects that NIS+ knows and cares about. Each table for a
domain comprises those of its parent domains. In addition, an entry in a table
may contain a link to another table. These features make it possible to
structure information in many ways.
supports secure and encrypted RPC, which helps greatly to solve the security
problems of NIS.
has an RPC Version number of 2, while NIS+
is Version 3. At the time we're writing, there isn't yet a good working
implementation of NIS+
for Linux, so it isn't covered here.
3. The Client Side
If you are familiar with writing or porting
network applications, you may notice that most of the NIS maps listed previously correspond to
library functions in the C library. For instance, to obtain passwd information, you generally use the getpwnam and getpwuid functions, which return the account information
associated with the given username or numerical user ID, respectively. Under
normal circumstances, these functions perform the requested lookup on the
standard file, such as /etc/passwd.
An NIS-aware implementation of these functions,
however, modifies this behavior and places an RPC call to the NIS server, which looks up the username or
user ID. This happens transparently to the application. The function may treat
the NIS data as though it has been appended to
the original passwd file so both
sets of information are available to the application and used, or as though it
has completely replaced it so that the information in the local passwd is ignored and only the NIS data is used.
For traditional NIS implementations, there were certain
conventions for which maps were replaced and which were appended to the
original information. Some, like the passwd
maps, required kludgy modifications of the passwd
file which, when done incorrectly, would open up security holes. To avoid these
pitfalls, NYS and the GNU libc
use a general configuration scheme that determines whether a particular set of
client functions uses the original files, NIS,
or NIS+, and in
which order. This scheme will be described later in this chapter.
4. Running an NIS Server
After so much theoretical
techno-babble, it's time to get our hands dirty with actual configuration work.
In this section, we will cover the configuration of an NIS server. If an NIS server is running on your network, you
won't have to set up your own; in this case, you may safely skip this section.
Note that if you are just going
to experiment with the server, make sure you don't set it up for an NIS domain name that is
already in use on your network. This may disrupt the entire network service and
make a lot of people very unhappy and very angry.
There are two possible NIS server configurations:
master and slave. The slave configuration provides a live backup machine,
should your master server fail. We will cover the configuration only for a
master server here. The server documentation will explain the differences,
should you wish to configure a slave server.
There are currently two NIS servers freely
available for Linux: one contained in Tobias Reber's yps package, and the other in Peter
package. It doesn't matter which one you run.
After installing the server
program (ypserv) in /usr/sbin, you should create the directory that is going to hold the
map files your server is to distribute. When setting up an NIS domain for the brewery domain, the maps
would go to /var/yp/brewery. The server determines whether it is serving a particular NIS domain by checking if
the map directory is present. If you are disabling service for some NIS domain, make sure to
remove the directory as well.
Maps are usually stored in DBM
files to speed up lookups. They are created from the master files using a
program called makedbm (for Tobias's server) or dbmload (for
Transforming a master file into a
form that dbmload can parse usually requires some awk or sed
magic, which tends to be a little tedious to type and hard to remember.
Therefore, Peter Eriksson's ypserv package contains a Makefile (called ypMakefile) that manages the
conversion of the most common master files for you. You should install it as Makefile in your map directory
and edit it to reflect the maps you want the NIS server to share. Towards the top of the
file, you'll find the all target that lists the services ypserv offers.
By default, the line looks something like this:
hosts networks protocols rpc services passwd group netid
If you don't want to produce, for
example, the ethers.byname and ethers.byaddr maps, simply remove the ethers prerequisite from this
rule. To test your setup, you can start with just one or two maps, like the services.* maps.
After editing the Makefile, while in the map
directory, type make. This will automatically generate and install the maps.
You have to make sure to update the maps whenever you change the master files,
otherwise the changes will remain invisible to the network.
The section “Setting Up an NIS
Client with GNU libc” will explain how to configure the NIS client code. If your setup doesn't work,
you should try to find out whether requests are arriving at your server. If you
specify the ––debug
command-line flag to ypserv, it prints debugging messages to the console
about all incoming NIS
queries and the results returned. These should give you a hint as to where the
problem lies. Tobias's server doesn't have this option.
5. NIS Server Security
used to have a major security flaw: it left your password file readable by
virtually anyone in the entire Internet, which made for quite a number of
possible intruders. As long as an intruder knew your NIS domain name and the address of your
server, he could simply send it a request for the passwd.byname map and instantly receive all your system's
encrypted passwords. With a fast password-cracking program like crack
and a good dictionary, guessing at least a few of your users' passwords is
rarely a problem.
This is what the securenets option is all
about. It simply restricts access to your NIS
server to certain hosts, based on their IP addresses or network numbers. The
latest version of ypserv implements this feature in two ways. The first
relies on a special configuration file called /etc/ypserv.securenets
and the second conveniently uses the /etc/hosts.allow
and /etc/hosts.deny files we
already encountered in Chapter 12. Thus, to
restrict access to hosts from within the Brewery, their network manager would
add the following line to hosts.allow :
This would let all hosts from IP network access the NIS server. To shut out all other hosts, a
corresponding entry in hosts.deny
would have to read:
IP numbers are not the only way you can specify
hosts or networks in hosts.allow
and hosts.deny. Please refer to
the hosts_access(5) manual page
on your system for details. However, be warned that you cannot use host
or domain names for the ypserv entry. If you
specify a hostname, the server tries to resolve this hostname—but the resolver
in turn calls ypserv, and you fall into an endless loop.
To configure securenets
security using the /etc/ypserv.securenets
method, you need to create its configuration file, /etc/ypserv.securenets. This configuration file is simple
in structure. Each line describes a host or network of hosts that will be
allowed access to the server. Any address not described by an entry in this
file will be refused access. A line beginning with a # will be treated as a
comment. Example 13-1 shows what a simple /etc/ypserv.securenets
would look like:
13-1. Sample ypserv.securenets File
|# allow connections from local host -- necessary
# same as 255.255.255.255 127.0.0.1
# allow connections from any host on the Virtual Brewery network
The first entry on each line is the netmask to
use for the entry, with host being treated as a
special keyword meaning “netmask 255.255.255.255.” The second entry on each
line is the IP address to which to apply the netmask.
A third option is to use the secure portmapper
instead of the securenets option
in ypserv. The secure portmapper (portmap-5.0)
uses the hosts.allow scheme as
well, but offers this for all RPC servers, not just ypserv. However, you should not use both the securenets option and the secure
portmapper at the same time, because of the overhead this authorization incurs.
To enable use of the /etc/hosts.allow method, you may have to
recompile the server. Please read the instructions in the README included in the distribution.
The secure portmapper is available via
anonymous FTP from ftp.win.tue.nl below the /pub/security/ directory.
6. Setting Up an NIS Client with GNU libc
We will now describe and discuss
the configuration of an NIS
client using the GNU libc library support.
Your first step should be to tell
the GNU libc NIS client which server to use for NIS service. We mentioned
earlier that the Linux ypbind allows you to configure the NIS server to use. The
default behavior is to query the server on the local network. If the host you
are configuring is likely to move from one domain to another, such as a laptop,
you would leave the /etc/yp.conf file empty and it would query on the local network for the
server wherever it happens to be.
A more secure configuration for
most hosts is to set the server name in the /etc/yp.conf configuration file. A very simple file for a host on the
Winery's network may look like this:
# yp.conf - YP
configuration for GNU libc library.
The ypserver statement tells your
host to use the host supplied as the NIS
server for the local domain. In this example we've specified the NIS server as vbardolino.
Of course, the IP address corresponding to vbardolino must be set in the hosts file; alternatively, you
may use the IP address itself with the server argument.
In the form shown in the example,
the ypserver command tells ypbind to use the named server
regardless of what the current NIS
domain may be. If, however, you are moving your machine between different NIS domains frequently,
you may want to keep information for several domains in the yp.conf file. You can have
information on the servers for various NIS
domains in yp.conf
by specifying the information using the domain statement. For instance, you
might change the previous sample file to look like this for a laptop:
# yp.conf - YP
configuration for GNU libc library.
This lets you bring up the laptop
in either of the two domains by simply setting the desired NIS domain at boot time using the domainname
command. The NIS
client then uses whichever server is relevant for the current domain.
There is a third option you may
want to use. It covers the case when you don't know the name or IP address of
the server to use in a particular domain, but still want the ability use a
fixed server on certain domains. Imagine we want to insist on using a specified
server while operating within the Winery domain, but want to probe for the
server to use while in the Brewery domain. We would modify our yp.conf file again to look like
# yp.conf - YP
configuration for GNU libc library.
The broadcast keyword tells ypbind
to use whichever NIS
server it finds for the domain.
After creating this basic
configuration file and making sure it is world-readable, you should run your
first test to connect to your server. Make sure to choose a map your server
distributes, like hosts.byname, and try to retrieve it by using the ypcat utility:
The output you get should
resemble that just shown. If you get an error message instead that says: Can't bind to server which serves domain, then either the NIS domain name you've set doesn't have a
matching server defined in yp.conf, or the server is unreachable for some reason. In the
latter case, make sure that a ping to the host yields a positive result,
and that it is indeed running an NIS
server. You can verify the latter by using rpcinfo, which should produce
the following output:
rpcinfo -u serverhost ypserv
version 1 ready and waiting
version 2 ready and waiting
7. Choosing the
Having made sure you can reach
the NIS server, you have to decide which
configuration files to replace or augment with NIS maps. Commonly, you will want to use NIS maps for the host and
password lookup functions. The former is especially useful if you do not have
the BIND name service. The password lookup lets all users log into their
accounts from any system in the NIS
domain; this usually goes along with sharing a central /home directory among all hosts
via NFS. The password map is explained detail in the next section.
Other maps, like services.byname, don't provide
such dramatic gains, but do save you some editing work. The services.byname map is valuable
if you install any network applications that use a service name not in the
Generally, you want to have some
choice of when a lookup function uses the local files, when it queries the NIS server, and when it
uses other servers such as DNS. GNU libc allows you to configure the order in
which a function accesses these services. This is controlled through the /etc/nsswitch.conf file, which
stands for Name Service Switch, but of course isn't limited to the name
service. For any of the data lookup functions supported by GNU libc, the file
contains a line naming the services to use.
The right order of services
depends on the type of data each service is offering. It is unlikely that the services.byname map will contain
entries differing from those in the local services file; it will only contain additional entries. So it
appears reasonable to query the local files first and check NIS only if the service name isn't found.
Hostname information, on the other hand, may change very frequently, so DNS or
the NIS server should always have the most
accurate account, while the local hosts file is only kept as a backup if DNS and NIS should fail. For hostnames, therefore,
you normally want to check the local file last.
The following example shows how
to force gethostbyname and gethostbyaddr to look in NIS and DNS
before the hosts
file and how to have the getservbyname function look in the local files before querying NIS. These resolver
functions will try each of the listed services in turn; if a lookup succeeds,
the result is returned; otherwise, they will try the next service in the list.
The file setting for these priorities is:
# small sample
services: files nis
The following is a complete list
of services and locations that may be used with an entry in the nsswitch.conf file. The actual
maps, files, servers, and objects queried depend on the entry name. The
following can appear to the right of a colon:
Use the current
server. The location of the server queried is configured in the yp.conf file, as shown in the
previous section. For the hosts entry, the hosts.byname and hosts.byaddr maps are queried.
Use the NIS+ server for this
domain. The location of the server is obtained from the /etc/nis.conf file.
Use the DNS name
server. This service type is useful only with the hosts entry. The name servers
queried are still determined by the standard resolv.conf file.
Use the local
file, such as the /etc/hosts file for the hosts entry.
with older file formats. This option can be used when either NYS or glibc 2.x
is used for NIS or NIS+ lookups. While these versions normally
can't interpret older NIS
entries in passwd
and group files, compat
option allows them to work with those formats.
Look up the
information from DBM files located in the /var/db directory. The corresponding NIS map name is used for that file.
Currently, the NIS support in GNU libc caters to the
following nsswitch.conf databases: aliases, ethers.group, hosts, netgroup,
network, passwd, protocols, publickey, rpc, services, and shadow. More entries
are likely to be added.
Example 13-2 shows a more complete example that introduces another
feature of nsswitch.conf. The [NOTFOUND=return] keyword in the hosts entry tells
the NIS client to return if the desired item
couldn't be found in the NIS
or DNS database. That is, the NIS client will
continue searching the local files only if calls to the NIS and DNS servers fail
for some other reason. The local files will then be used only at boot time and
as a backup when the NIS
server is down.
Example 13-2. Sample nsswitch.conf File
dns [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
GNU libc provides some other
actions that are described in the nsswitch manpage.
8. Using the
passwd and group Maps
One of the major applications of NIS is synchronizing user and account information on all
hosts in an NIS
domain. Consequently, you usually keep only a small local /etc/passwd file, to which
site-wide information from the NIS
maps is appended. However, simply enabling NIS lookups for this service in nsswitch.conf is not nearly
When relying on the password
information distributed by NIS, you first have
to make sure that the numeric user IDs of any users you have in your local passwd file match the NIS server's idea of user
IDs. Consistency in user IDs is important for other purposes as well, like
mounting NFS volumes from other hosts in your network.
If any of the numeric IDs in /etc/passwd or /etc/group differ from those in
the maps, you have to adjust file ownerships for all files that belong to that
user. First, you should change all uids and gids in passwd and group to the new values, then
find that all files that belong to the users just changed and change their
ownership. Assume news used to have a user ID of 9 and okir had a user ID of
103, which were changed to some other value; you could then issue the following
commands as root:
find / -uid 9 -print >/tmp/uid.9
find / -uid 103 -print >/tmp/uid.103
cat /tmp/uid.9 | xargs
cat /tmp/uid.103 | xargs chown okir
It is important that you execute
these commands with the new passwd file installed, and that you collect all filenames before
you change the ownership of any of them. To update the group ownerships of
files, use a similar method with the gid instead of the uid, and chgrp instead
Once you do this, the numerical
uids and gids on your system will agree with those on all other hosts in your NIS domain. The next step
is to add configuration lines to nsswitch.conf that enable NIS
lookups for user and group information:
/etc/nsswitch.conf - passwd and group treatment
passwd: nis files
This affects where the login
command and all its friends look for user information. When a user tries to log
in, login queries the NIS
maps first, and if this lookup fails, falls back to the local files. Usually,
you will remove almost all users from your local files, and only leave entries
for root and generic accounts like mail in it. This is because some vital
system tasks may have to map uids to usernames or vice versa. For example,
administrative cron jobs may execute the su command to temporarily become news, or the UUCP subsystem
may mail a status report. If news and uucp don't have entries in the local passwd file, these jobs will fail
miserably during an NIS
Lastly, if you are using either
the old NIS
implementation (supported by the compat mode for the passwd and group files in the NYS or glibc
implementations), you must insert the unwieldy special entries into them. These
entries represent where the NIS
derived records will be inserted into the database of information. The entries
can be added anywhere, but are usually just added to the end. The entries to
add for the /etc/passwd file are:
and for the /etc/groups file:
With both glibc 2.x and NYS you
can override parameters in a user’s record received from the NIS server by creating entries with a “+”
prepended to the login name, and exclude specified users by creating entries
with a “-” prepended to the login name. For example the entries:
would override the shell
specified for the user stuart supplied by the NIS server, and would disallow the user jedd
from logging in on this machine. Any fields left blank use the information
supplied by the NIS
There are two big caveats in
order here. First, the setup as described up to here works only for login
suites that don't use shadow passwords. The intricacies of using shadow
passwords with NIS
will be discussed in the next section. Second, the login commands are not the
only ones that access the passwd file—look at the ls command, which most people use
almost constantly. Whenever compiling a long listing, ls displays the
symbolic names for user and group owners of a file; that is, for each uid and
gid it encounters, it has to query the NIS
server. An NIS
query takes slightly longer to perform than the equivalent lookup in a local
file. You may find that sharing your passwd and group information using NIS
causes a noticable reduction in the performance of some programs that use this
Still, this is not the whole
story. Imagine what happens if a user wants to change her password. Usually,
she will invoke passwd, which reads the new password and updates the
file. This is impossible with NIS, since that
file isn't available locally anymore, but having users log into the NIS server whenever they
want to change their passwords is not an option, either. Therefore, NIS provides a drop-in replacement for passwd
called yppasswd, which handles password changes under NIS. To change the password on the server
host, it contacts the yppasswdd daemon on that host via RPC, and
provides it with the updated password information. Usually you install yppasswd
over the normal program by doing something like this:
mv passwd passwd.old
ln yppasswd passwd
At the same time, you have to
install rpc.yppasswdd on the server and start it from a network script.
This will effectively hide any of the contortions of NIS from your users.
9. Using NIS with Shadow Support
Using NIS in conjunction with shadow password files
is somewhat problematic. First we have some bad news: using NIS defeats the goals of shadow passwords.
The shadow password
scheme was designed to prevent nonroot users from having access to the
encrypted form of the login passwords. Using NIS
to share shadow
data by necessity makes the encrypted passwords available to any user who can
listen to the NIS
server replies on the network. A policy to enforce users to choose “good”
passwords is arguably better than trying to shadow passwords in an NIS environment. Let's
take a quick look at how you do it, should you decide to forge on ahead.
In libc5 there is no real
solution to sharing shadow data using NIS.
The only way to distribute password and user information by NIS is through the standard passwd.* maps. If you do have
shadow passwords installed, the easiest way to share them is to generate a
file from /etc/shadow using tools like pwuncov, and create the NIS maps from that file.
Of course, there are some hacks
necessary to use NIS and shadow passwords at the
same time, for instance, by installing an /etc/shadow file on each host in the network, while distributing user
information, through NIS.
However, this hack is really crude and defies the goal of NIS, which is to ease system administration.
The NIS support in the GNU libc library (libc6)
provides support for shadow password databases. It does not provide any real
solution to making your passwords accessible, but it does simplify password
management in environments in which you do want to use NIS with shadow passwords. To use it, you
must create a shadow.byname database and add the following line to your /etc/nsswitch.conf
# Shadow password support
If you use shadow passwords along
with NIS, you must try to maintain some security
by restricting access to your NIS
database. See Section 5” earlier in this chapter.