denon.domain.com's NIS database has been set up.

If there were warnings, please figure out what went wrong, and fix it.



At this point, make sure that /etc/passwd and /etc/group have

been edited so that when the NIS is activated, the databases you

have just created will be used, instead of the /etc ASCII files.

Don't worry about the Trying ypxfrd...not running message. This happens because you haven't set the NIS master server to run the YP map transfer daemon rpc.ypxfrd. In fact, you never set it up to do so—instead use a server push method where the NIS master server pushes the maps to all the NIS slaves whenever there is an update.

In order to set the NIS master to do the actual push, you need to change its Makefile a little. On the master server, edit the Makefile so that the line NOPUSH="True" is changed to read #NOPUSH="True" and the line that reads DOMAIN = `basename \'pwd\'' is changed to DOMAIN= '/bin/domainname'.

Now for the big test. On the NIS master server, run cd /var/yp;make all to force all the maps to be rebuilt and pushed. The output should look something like the following:

Updating passwd.byname....

Pushed passwd.byname map.

Updating passwd.byuid...

Pushed passwd.byuid map.

Updating hosts.byname...

Pushed hosts.byname.

Updating hosts.byaddr...

Pushed hosts.byaddr.

[etc...]

On the NIS slave server, change the /etc/yp.conf file so that the ypserver is set to point to the slave server. Try running the command ypcat passwd and see if your NIS password file is displayed. If so, you're set! The NIS slave server is configured.

If you're having problems, go back and trace through your steps. Also, be sure to reboot the machine and see if your NIS slave server still works correctly. If it doesn't come back up, be sure that the changes you made to the boot sequence when installing ypserv were correct.

Using NIS-isms in Your /etc/passwd File

The most popular use of NIS is to keep a global user database so that it is possible to grant access to any machine at your site to any user. Under Red Hat Linux, this behavior is implicit for all NIS clients.

There are times, however, when you do not want everyone accessing certain systems, such as those used by personnel. This can be fixed by using the special token + in your /etc/passwd file. By default, NIS clients have the line +:::::: at the end of their /etc/passwd file, thereby allowing everyone in NIS to log in to the system. In order to change this so that the host remains an NIS client but does not grant everyone permission, the line +::::::/bin/false should be explicitly added to the end of your /etc/passwd file. This will allow only people with actual entries in the /etc/passwd file for that host (for example, root) to log in.

In order to allow a specific person to log in to a host, you can add a line to the /etc/passwd file granting this access. The format of the line is +username:::::: where username is the login of the user you want to grant access to. NIS will automatically grab the user's passwd entry from the NIS server and use the correct information for determining the user information (for example, UID, GID, GECOS, and so on). You can override particular fields by inserting the new value in the +username:::::: entry. For example, if the user sshah uses /usr/local/bin/tcsh as his shell, but the host he needs to log in to keeps it in /bin/tcsh, his /etc/passwd entry can be set to +sshah::::::/bin/tcsh.

Using Netgroups

Netgroups are a great way to group people and machines into nice neat names for access control. A good example of this is for a site where users are not allowed to log in to server machines. A netgroup for the system administrators can be created and those in the group let in through a special entry in the /etc/passwd file.

Netgroup information is kept in the /etc/netgroup file and shared via NIS.

The format of a netgroups file is

groupname member-list

where groupname is the name of the group being defined and the member-list is comprised of other group names or tuples of specific data. Each entry in the member-list is separated by a whitespace.

A tuple containing specific data comes in the form

(hostname, username, domain name)

where hostname is the name of the machine for which that entry is valid, username is the login of the person being referenced, and domain name is the NIS domain name. Any entry left blank is considered a wildcard; for example, (technics,,,) implies everybody on the host technics. An entry with a dash in it (-) means that there are no valid values for that entry. For example, (-,sshah,) implies the user sshah and nothing else. This is useful for generating a list of users or machine names for use in other netgroups.

In files where netgroups are supported (such as /etc/passwd), they are referenced by placing an @ sign in front of them. So if you wanted to allow the netgroup sysadmins consisting of (-,sshah,) (-,heidis,) permission to log in to a server, you would add the line

+@sysadmins

to your /etc/passwd file.

An example of a full netgroups file is as follows:

sysadmins        (-,sshah,) (-,heidis)

servers        (numark,-,) (vestax,-,)

clients        (denon,-,) (technics,-,) (mtx,-,)

research-1        (-,boson,) (-,jyom,) (-,weals,) (-,dave,)

research-2        (-,scora,) (-,dan,) (-,david,) (-,barth,)

consultants        (-,arturo,)

allusers        sysadmins research-1 research-2 consultants

allhosts        servers clients

The Network File System

The Network File System, or NFS, is the means by which UNIX systems share their disk resources with one another. By abstracting the details of the filesystem to this level, it is possible for other systems (both UNIX and non-UNIX alike) to follow the NFS protocol and share disks across one another.

The success of NFS is due to a number of its key features, the first and foremost being that its specifications have been made publicly available from Sun Microsystems from its initial development onward. At the same time, Sun began shipping all of its workstations with this capability. During the '80s and early '90s, the Sun UNIX (SunOS and later Solaris) made heavy use of the protocol and many other UNIX vendors followed suit. Linux supported NFS before even version 1.0 was released.

Another key feature is NFS's robust nature. It is a stateless protocol meaning that each request made between the client and server is complete in itself and does not require knowledge of prior transactions. Because of this, NFS cannot tell the difference between a very slow host and a host that has failed altogether. This allows for servers to go down and come back up without having to reboot the clients.