| NIS maps
|List the critical configuration files NIS uses as the basis for its standard maps.
NIS maps represent the data shared by the members of an NIS domain. The original copies of NIS maps are stored as files on the
NIS master server. These files are kept in the DBM database format. This format is not directly readable by humans. In principle, an NIS master server can distribute NIS maps containing absolutely anything to the members of its domain. In most cases, however, NIS is used to distribute a standard set of maps derived from versions of critical configuration files. These files and their significance for the NIS domain, are described below.
Files for the NIS Domain
passwd is identical in purpose to the /etc/passwd file (though without shadow passwords). The
passwd map stores network account information.
group is identical to the /etc/group file; it stores network group membership information.
hosts is identical to /etc/hosts; it stores IP-to-hostname mappings. Since DNS usually is used for this purpose, most sites do not use NIS hosts maps.
services is a copy of the services file. This file rarely changes, so distributing it by NIS is not crucial.
aliases creates mail aliases; it can be used to share this information across the network. This file is part of email configuration.
ethers is used for RARP to assign IP addresses to machines based on their Ethernet address. Modern systems use DHCP or BOOTP servers for this task, so
ethers is rarelyused.
bootparams is used to pass parameters to the kernel for booting. This map enables a common set of boot parameters to be shared across an NIS domain.
networks replaces /etc/networks; it can be used to configure routing.
protocols replaces /etc/protocols which defines protocol numbers and names for network protocols. This file is usually identical on every machine, and it changes very rarely, so distributing it through NIS is not crucial.
In addition, NIS sometimes distributes Secure RPC
public keys and automounter
We will discuss Secure RPC and automounter maps later in this course when we cover NFS.
Which components need to be configured for NIS Maps
In order to configure NIS Maps, several components need to be set up and configured properly:
- NIS master server: The master server is the central repository for all of the NIS maps. It stores the NIS maps and is responsible for updating them and propagating changes to the slave servers.
- NIS slave servers: The slave servers are used to replicate the NIS maps from the master server. They are typically used to provide redundancy and to improve performance by reducing the load on the master server.
- NIS maps: NIS maps are the actual databases that store the user and system information. They can include information such as user accounts, group accounts, host names, and network addresses.
- NIS clients: NIS clients are the systems that query the NIS servers for information. They are typically configured to use the IP address or hostname of the nearest NIS server.
- ypbind daemon: The ypbind daemon is responsible for binding the NIS client to a NIS server. It communicates with the NIS servers to find the nearest available server and to detect if a server is down and to switch to another one.
- ypwhich command: It is command that is used to check the NIS maps and NIS servers on the client
- Domain name: NIS server and clients must be in the same domain. It is required to be configured and consistent across all systems that are participating in the NIS network.
All of these components must be properly configured and working together in order for NIS to function correctly. In addition, the NIS maps should be properly populated with accurate and up-to-date information.
Creating NIS maps
To create NIS maps, text copies of the data files, in their standard format, are run through a program called
makedbm. As we will see, usually this process is automated, so the details of doing it are not important. However, if you want to use NIS for a new kind of map, you must learn to use
makedbm, which is outside the scope of this course.
The Secure RPC protocol is an attempt to add a level of strong authentication to requests for NFS resources. It is based on a combined public-key/private-key encryption system.
The automounter daemon provides a system for centralizing filesystem administration so the administrator can make any changes in the filesystem configuration from a central location.