Olaf Kirch - Linux Network Administrator Guide, Second Edition

# yp.conf - YP configuration for GNU libc library.

#

domain winery server vbardolino

domain brewery server vstout

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 this instead:

# yp.conf - YP configuration for GNU libc library.

#

domain winery server vbardolino

domain brewery broadcast

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:

# ypcat hosts.byname

172.16.2.2 vbeaujolais.vbrew.com vbeaujolais

172.16.2.3 vbardolino.vbrew.com vbardolino

172.16.1.1 vlager.vbrew.com vlager

172.16.2.1 vlager.vbrew.com vlager

172.16.1.2 vstout.vbrew.com vstout

172.16.1.3 vale.vbrew.com vale

172.16.2.4 vchianti.vbrew.com vchianti

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

program 100004 version 1 ready and waiting

program 100004 version 2 ready and waiting

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 standard services file.

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 /etc/nsswitch.conf

#

hosts: nis dns files

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:

nis

Use the current domain NIS 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.

nisplus or nis+

Use the NIS+ server for this domain. The location of the server is obtained from the /etc/nis.conf file.

dns

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.

files

Use the local file, such as the /etc/hosts file for the hosts entry.

compat

Be compatible 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.

db

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

# /etc/nsswitch.conf

#

hosts: nis dns [NOTFOUND=return] files

networks: nis [NOTFOUND=return] files

services: files nis

protocols: files nis