UNIX System Administration Handbook - Evi Nemeth [311]
passwd: files nis
hosts: files dns
group: files
...
Each line configures one type of information (usually, one flat-file equivalent). The potential sources are nis, nisplus, files, dns, and compat; they refer to NIS, NIS+, vanilla flat files (ignoring tokens such as “+”), DNS, and NISified flat files (honoring “+”), respectively. DNS is only a valid data source for host information.
Sources are tried from left to right until one of them produces an answer for the query. In the example above, the gethostbyname routine would first check the /etc/hosts file, and if the host was not listed there, would then check DNS. Queries about UNIX groups, on the other hand, would check only the /etc/group file.
If necessary, you may define the “failure” of a source more specifically by putting bracketed expressions after it. For example, the line
hosts: dns [NOTFOUND=return] nisplus
causes DNS to be used exclusively if it is available; a negative response from the name server makes queries return immediately (with a failure code) without checking NIS+. However, NIS+ will be used if no name server is available. The various types of failures are shown in Table 18.3; each may be set to return or continue, indicating whether the query should be aborted or forwarded to the next source.
Table 18.3 Failure modes recognized in /etc/nsswitch.conf
Several suggested nsswitch.conf configurations are often provided in the /etc directory. Check to see if one of these is appropriate for your site (ls /etc/nss*) before rolling your own.
FreeBSD does not yet support a centralized switch file. The priority of data sources for host lookups can be set in the /etc/host.conf file, which is self-documenting. NIS tokens must appear in the passwd and group files to import remote maps; see the section 5 man pages for passwd and group for more information.
Advantages and disadvantages of NIS
One nice feature of NIS is that it can be understood by mere mortals. NIS is analogous to copying files around; in most cases, it’s unnecessary for administrators to be aware of NIS’s internal data formats. Administration is performed with the same old flat files, and only one or two new procedures need to be learned.
Since there is no way to link NIS domains, NIS is not suitable for managing a large network of machines unless a single configuration is to be applied to every machine. You can divide a large network into several NIS domains, but each domain must be administered separately.
See Chapter 9 for more information about cron.
If a slave server is down or inaccessible when a map is changed, the slave’s copy will not be updated. Slaves must periodically poll the master to be sure that they have the most recent version of every map. Although basic tools for polling are provided with NIS, you must implement the polling scheme you want by using cron. Even so, there is the possibility that two different versions of a map will be served simultaneously for a while, with clients randomly seeing one or the other.
NIS is not secure. Any host on a network can claim to serve a particular domain, thus feeding bogus administrative data to NIS clients. And anyone can read your NIS maps, perhaps feeding the encrypted passwords to a cracking program to look for poorly protected accounts.
Some NIS servers attempt to increase password security by denying access to the shadow password map from unprivileged ports. While well-intentioned, this is a very weak form of protection. If you are concerned about security, you should not use NIS.
How NIS works
NIS’s data files (and often some of its commands) are stored in one directory, usually /var/yp. Hereafter, we refer to this as “the NIS directory.” Each NIS map is stored in a hashed format in a subdirectory of the NIS directory named for the NIS domain. The exact name and number of the map files depends on the hashing library being used. For example, in the domain “cssuns”, the ndbm files for the /etc/passwd maps