Managing NFS and NIS, 2nd Edition - Mike Eisler [35]
NIS is built on the RPC protocol, and uses the UDP transport to move requests from the client host to the server. NIS services are integrated into the standard Unix library calls so that they remain transparent to processes that reference NIS-managed files. If you have a process that reads /etc/passwd, most of the queries about that file will be handled by NIS RPC calls to an NIS server. The library calling interface used by the application does not change at all, but the implementations of library routines such as getpwuid( ) that read the /etc/passwd file are modified to refer to NIS or to NIS and local files. The application using getpwuid( ) is oblivious to the change in its implementation.
Therefore, when you enable NIS, you don't have to change any existing software. A vendor that supports NIS has already modified all of the relevant library calls to have them make NIS RPC calls in addition to looking at local files where relevant. Any process that used to do lookups in the host table still works; it just does something different in the depths of the library calls.
Map files
Configuration files managed by NIS are converted into keyword and value pair tables called maps. We've been using the term "map" all along, as if a map were equivalent to the ASCII files that it replaces or augments. For example, we have said that the passwd NIS map is appended to the NIS client's /etc/passwd file. Now it's time to understand what a map file really is.
NIS maps are constructed from DBM database files. DBM is the database system that is built into BSD Unix implementations; if it is not normally shipped as part of your Unix system, your vendor will supply it as part of the NIS implementation. Under DBM, a database consists of a set of keys and associated values organized in a table with fast lookup capabilities. Every key and value pair may be located using at most two filesystem accesses, making DBM an efficient storage mechanism for NIS maps. A common way to use the password file, for example, is to locate an entry by user ID number, or UID. Using the flat /etc/passwd file, a linear search is required, while the same value can be retrieved from a DBM file with a single lookup. This performance improvement in data location offsets the overhead of performing a remote procedure call over the network.
Each DBM database, and therefore each NIS map, comprises two files: a hash-table accessed bitmap of indices and a data file. The index file has the .dir extension and the data file uses .pag. A database called addresses would be stored in:
addresses.dir index file
addresses.pag data file
A complete map contains both files.
Consecutive records are not packed in the data file; they are arranged in hashed order and may have empty blocks between them. As a result, the DBM data file may appear to be up to four times as large as the data that it contains. The Unix operating system allows a file to have holes in it that are created when the file's write pointer is advanced beyond the end of the file using lseek( ). Filesystem data blocks are allocated only for those parts of the file containing data. The empty blocks are not allocated, and the file is only as large as the total number of used filesystem blocks and fragments.
The holes in DBM files make them difficult to manipulate using standard Unix utilities. If you try to copy an NIS map using cp, or move it across a filesystem boundary with mv, the new file will have the holes expanded into zero-filled disk blocks. When cp reads the file, it doesn't expect to find holes, so it reads sequentially from the first byte until the end-of-file is found. Blocks that are not allocated are read back as zeros, and written to the new file as all zeros as well. This has the unfortunate side effect of making the copied DBM files consume much more disk space than the hole-filled files. Furthermore, NIS maps will not