UNIX System Administration Handbook - Evi Nemeth [314]
Under Red Hat, you set the NIS domain name in /etc/sysconfig/network by setting the variable NISDOMAIN. ypbind, ypserv, and yppasswdd are enabled and disabled with chkconfig; for example,
# chkconfig ypbind on
You can force Red Hat’s ypbind to use a particular NIS server (rather than letting it forage via broadcasting) by putting the following line in /etc/yp.conf:
ypserver hostname
This should be the only line in the /etc/yp.conf file. The specified hostname must be listed in /etc/hosts.
On FreeBSD systems, you specify the NIS domain name in /etc/rc.conf by setting the nisdomainname variable. For example:
nisdomainname="cssuns"
The ypbind, ypserv, and yppasswdd daemons are started by setting the variables nis_client_enable, nis_server_enable, and nis_yppasswdd_enable to YES.
/etc/passwd and /etc/group must contain the magic cookie “+” if they are to use NIS as an information source; see page 523.
18.4 NIS+: SON OF NIS
NIS+, aka “NIS on steroids whose face nobody is Ever Going to Kick Sand in Again,” was designed to correct the deficiencies of NIS and introduce deficiencies of its own. It handles large networks of machines. It has security features built in. It permits multiple domains to be administered from anywhere on a network. It transfers updates efficiently. It’s a distributed database and a dessert topping; it sings, it dances, it leaps capital T in a single bound.
Although NIS+ servers can serve data to NIS clients (at some security expense), NIS+ is a different system that shares no code with NIS. It is supported by some big-ticket OS vendors (such as HP), but its complexity has prevented it from diffusing onto any of the free versions of UNIX.
NIS+ is a good example of what Frederick P. Brooks, Jr. calls “the second system effect” in his classic book on software engineering, The Mythical Man-Month. It attempts to build on the success of its progenitor while avoiding all of the mistakes and pitfalls of the previous design. It devotes substantial effort to the system’s formal architecture. In theory it should be perfect. In practice it’s somewhat clunky, overengineered, and adrift from everyday reality. We’ve been told that even Sun does not use NIS+ internally.
There are several significant differences between NIS and NIS+:
• NIS+ domains are arranged in a site-wide hierarchy patterned after the one used by DNS. As with NIS, each domain includes various kinds of administrative information. You can subdivide domains to delegate administrative authority. Each machine belongs to a single domain, but domains can refer to each other’s contents, allowing individual machines to obtain information from several domains.
• NIS+ is more database-like than NIS and allows maps (now called “tables”) to be searched by any field. This feature removes the need to maintain several maps for each system file; NIS+ equates each file with a single table.
• NIS+ doesn’t use flat files as NIS does. Although you can transfer data from a UNIX file (or an NIS map) into NIS+, NIS+ is then considered the authoritative source for the information. NIS+ won’t automatically refresh itself if you later change the file. To make changes, you use a command that directly edits the information in NIS+’s tables.
• NIS+ is much better than NIS at maintaining slave servers (called “replicas” in NIS+). Only incremental changes are transferred, and a nifty logging scheme accommodates replicas that come in and out of contact with the master server. The master is also able to transfer its entire NIS+ database to a replica if it decides that the replica is too far out of date to be updated incrementally.
• NIS+ is built on top of Sun’s Secure RPC system, which allows authentication based on public key encryption as well as the traditional “I claim to be Fred” style of nonauthentication. NIS+ servers can be configured to require encrypted credentials or, for the more convenience-minded, to obey the usual UNIX conventions.
Like