• Choose a category
• All
• Classic-Fiction

Run ypinit:

newclient# /usr/sbin/ypinit -c

You will be prompted for a list of NIS servers. Enter the servers in order of proximity to the client.

Kill (if necessary) ypbind, and restart it:

newclient# ps -ef | grep ypbind

newclient# /usr/lib/netsvc/yp/ypstop

newclient# /usr/lib/netsvc/yp/ypstart

Once NIS is running, references to the basic administrative files are handled in two fundamentally different ways, depending on how nsswitch.conf is configured:

The NIS database replaces some files. Local copies of replaced files (ethers, hosts, netmasks, netgroups,[3]networks, protocols, rpc, and services) are ignored as soon as the ypbind daemon is started (to enable NIS).

Some files are augmented, or appended to, by NIS. Files that are appended, or augmented, by NIS are consulted before the NIS maps are queried. The default /etc/nsswitch.conf file for NIS has these appended files: aliases, auto_*, group, passwd, services, and shadow. These files are read first, and if an appropriate entry isn't found in the local file, the corresponding NIS map is consulted. For example, when a user logs in, an NIS client will first look up the user's login name in the local passwd file; if it does not find anything that matches, it will refer to the NIS passwd map.

Although the replaced files aren't consulted once NIS is running, they shouldn't be deleted. In particular, the /etc/hosts file is used by an NIS client during the boot process, before it starts NIS, but is ignored as soon as NIS is running. The NIS client needs a "runt" hosts file during the boot process so that it can configure itself and get NIS running. Administrators usually truncate hosts to the absolute minimum: entries for the host itself and the "loopback" address. Diskless nodes need additional entries for the node's boot server and the server for the diskless node's /usr filesystem. Trimming the hosts file to these minimal entries is a good idea because, for historical reasons, many systems have extremely long host tables. Other files, like rpc, services, and protocols, could probably be eliminated, but it's safest to leave the files distributed with your system untouched; these will certainly have enough information to get your system booted safely, particularly if NIS stops running for some reason. However, you should make any local additions to these files on the master server alone. You don't need to bother keeping the slaves and clients up to date.

We'll take a much closer look at the files managed by NIS and the mechanisms used to manage appended files in Section 3.3. Meanwhile, we'll assume that you have modified these files correctly and proceed with NIS setup.

* * *

[2] The multiple-domain case is really no different than this; you just have to remember which systems belong to which domain.

[3] The netgroups file is a special case. Netgroups are only meaningful when NIS is running, in which case the netgroups map (rather than the file) is consulted. The netgroups file is therefore only used to build the netgroups map; it is never "consulted" in its own right.

Files managed under NIS

Now that we've walked through the setup procedure, we will discuss how the NIS maps relate to the files that they replace. In particular, we'll discuss how to modify the files that are appended by NIS so they can take advantage of NIS features. We will also pay special attention to the netgroups NIS map, a confusing but nevertheless important part of the overall picture.

Table 3-2 lists the most common files managed by NIS. Not all vendors use NIS for all of these files, so it is best to check your documentation for a list of NIS-supported files.

Table 3-2. Summary of NIS maps

Map Name

Nickname

Access By

Contains

Default Integration

auto.*

Map key

/etc/auto_*

Append

bootparams

Hostname

/etc/bootparams

Append

ethers.byname

ethers

Hostname

/etc/ethers

Replace

ethers.byaddr

MAC address

/etc/ethers

Replace

group.byname

group

Group name

/etc/group

Append

group.bygid

Group ID