Managing NFS and NIS, 2nd Edition - Mike Eisler [51]
#! /bin/sh
/usr/lib/netsvc/yp/ypxfr -h mahimahi -s nesales hosts.byname
/usr/lib/netsvc/yp/ypxfr -h mahimahi -s nesales hosts.byaddr
/usr/lib/netsvc/yp/yppush -d `domainname` hosts.byname
/usr/lib/netsvc/yp/yppush -d `domainname` hosts.byaddr
The ypxfr commands get the maps from the primary master server, and then the yppush commands distribute them in the local, secondary NIS domain. The -h option to ypxfr specifies the hostname from which to initiate the transfer, and overrides the map's master record. The -s option indicates the domain from which the map is to be taken. Note that in this approach, the hosts map points to mahimahi as the master in both domains. If the rcp-based transfer is used, then the hosts map in each domain points to the master server in that domain. The master server record in the map always indicates the host containing a source file from which the map can be rebuilt.
Chapter 5. Living with Multiple Directory Servers
Domain name servers
The hostname management provided by NIS can be integrated with an Internet Domain Name Service (DNS), or the DNS facilities can be used to replace the NIS host map in its entirety. We'll avoid a full-length discussion of setting up a name server. That process depends on the type of name server supported by your vendor, and it is best described by your vendor's documentation. Instead, this section concentrates on differences between the scope of the two hostname services, and support for DNS with and without NIS. Note that the implementation of Domain name services provided by your vendor may not be called DNS. If the Berkeley Internet Name Domain name service or one of its derivatives is used, the service is often called BIND.
DNS versus NIS
DNS provides a hierarchical hostname management system that spans the entire Internet. Each level in the hierarchy designates authoritative name servers that contain maps of hostnames and IP addresses, similar to the NIS hosts map but on a larger scale. The DNS server for a large name service domain would have host information merged from dozens of NIS domains. First among the advantages of DNS is its ability to decentralize responsibility for the maintenance of hostname-to-IP address mappings and the resulting domain name qualification that is used to differentiate identically named hosts.
Decentralized name management means that each organization running a name service domain — whether it is a subdivision of a corporation or an entire company — can maintain its own host information without having to notify some central authority of changes in its local configuration. Host information is published through the authoritative name server for that domain, and hosts in other name service domains retrieve information from the name server when needed. Every domain knows how to reach the next highest level in the name space hierarchy, and it can generally find most of its peer name servers within the same organization. If a name server does not know how to reach the name server for another domain, it can ask the next higher level domain name server for assistance.
For example, Princeton University is part of the educational, or .edu, domain. The domain name for the entire university is princeton.edu, and it is further divided by department:
cs.princeton.edu
politics.princeton.edu
history.princeton.edu
and so on. Each of the name servers for the departmental name service domains knows how to reach most of the others; therefore each department can run its own systems without having to notify a campus-wide network manager of any changes to host information. There is also a name server for the entire princeton.edu domain that points to lower-level name servers for incoming queries and locates other domains in .edu, .com, or .gov for outbound requests.
In a world in which every machine name must be unique, all of the good names are taken very quickly. DNS allows each domain to have