UNIX System Administration Handbook - Evi Nemeth [309]
This script assumes that no errors can happen after a successful login; in the real world, you’d probably want to add more embellishments. In this example, the same error handling is applied to several exchanges through the use of a while loop. There are some special versions of the expect command that are designed to solve this problem in a less kludgey way.
The send command places a string on the subprocess’s standard input. You must explicitly include a carriage return (entered as “\r”) if you want one. A string without spaces or special characters need not be quoted. The send_user command is similar to the send command, except that the text is sent to the script’s standard output rather than to the slave process.
The expect command accepts a series of pattern/action pairs. If the pairs span multiple lines, as in the example above, they should be enclosed in curly braces. Actions should generally be enclosed in curly braces as well.
Each pattern is something to watch for in the command’s output; when a string is seen, its corresponding action is triggered. Patterns are normally matched using unanchored shell-style globbing, but regular expressions are also available. Actions for the special strings timeout and eof are triggered after a (settable) period of inactivity and at the end of the input stream, respectively.
The source code for expect can be downloaded from the web at expect.nist.gov.
18.3 NIS: THE NETWORK INFORMATION SERVICE
NIS, released by Sun in the 1980s, was the first “prime time” administrative database. It was originally called the Sun Yellow Pages, but eventually had to be renamed for legal reasons. NIS commands still begin with the letters yp, so it’s hard to forget the original name. Many vendors have licensed Sun’s code, making NIS the most widely supported file sharing system.
Sun released a new administrative database system called NIS+ in the early 90s. Despite their similar names, NIS and NIS+ do not really have much to do with each other. NIS+ is considerably more complex than NIS, and it has not enjoyed the same degree of popular support. More information about NIS+ is given on page 530; Table 18.2 shows the current state of support for NIS and NIS+ on our example systems.
Table 18.2 Support for NIS and NIS+
The unit of sharing in NIS is the record, not the file. A record usually corresponds to one line in a config file. A master server maintains the authoritative copies of system files, which are kept in their original locations and formats and are edited with a text editor just as before. A server process makes the contents of the files available over the network. A server and its clients constitute an NIS “domain”.3
Data files are preprocessed into database files by a hashing library (usually ndbm or the GNU equivalent, gdbm); this procedure improves the efficiency of lookups. After editing files on the master server, you tell NIS to convert them to their hashed format, using either make or a script called ypmake, depending on your system.
The common hashing libraries allow only one key to be associated with each entry, so a system file may have to be translated into several NIS “maps.” For example, the /etc/passwd file is translated into two different maps called passwd.byname and passwd.byuid. One is used to look up entries by username, and the other to look up entries by UID. Either map can be used to enumerate the entries in the passwd file. However, since hashing libraries do not preserve the order of records, there is no way to reconstruct an exact duplicate of the original file (unless it was sorted).
NIS allows you to replicate the network maps on a set of slave servers.