NIS+ stores a wide variety of network information in tables. This section describes the structure of those tables and provides a brief overview of how they can be set up.
NIS+ tables provide several features not found in simple text files or maps, such as:
NIS+ provides preconfigured system
tables, and you can also create your own tables. The following table
lists the preconfigured NIS+ tables.
|Table||Information in the Table|
|auto_home||Location of all users' home directories in the domain|
|auto_master||Automounter map information|
|bootparams||Location of the root, swap, and dump partition of every diskless client in the domain|
|client_info||Information about NIS+ clients|
|cred||Credentials for principals who belong to the domain|
|ethers||Ethernet address of every workstation in the domain|
|group||Group name, group password, group ID, and members of every UNIX group in the domain|
|hosts||Network address and host name of every workstation in the domain|
|mail_aliases||Information about the mail aliases of users in the domain|
|netgroup||Netgroups to which workstations and users in the domain may belong|
|netmasks||Networks in the domain and their associated netmasks|
|networks||Networks in the domain and their canonical names|
|passwd||Password information about every user in the domain.|
|protocols||List of IP protocols used in the domain|
|rpc||RPC program numbers for RPC services available in the domain|
|services||Names of IP services used in the domain and their port numbers|
|timezone||Time zone of every workstation in the domain|
These tables store a wide variety of information, ranging from user names to Internet services. Most of this information is generated during a setup or configuration procedure. For instance, an entry in the passwd table is created when a user account is set up. An entry in the hosts table is created when a workstation is added to the network.
Because this information is generated from such a wide field of operations, much of it is beyond the scope of this book. The appendix summarizes the type of information contained in each column of the tables, but for thorough explanations about the actual information that is stored, see the AIX 5L Version 5.1 System Management Guide: Communications and Networks.
The cred table, because it contains only information related to NIS+ security, is described in Administering NIS+ Credentials.
Although NIS+ tables store different types of information, they all have the same underlying structure; they are each made up of rows (called entries or entry objects) and columns.
A client can access information by a key, or by any column that is searchable. For example, to find the network address of a workstation named baseball, a client could look through the hostname column until it found baseball. It then would move along the baseball row to find its network address, as shown in the following figure.
Figure 4-10. Example of NIS+ Table Structure. This illustration shows a simple matrix of five rows and four columns. The fourth row is labeled Baseball Row. The first column is labeled Address Column. The second column is labeled Hostname Column. The Hostname Column cells contain text - from top row: nose, grass, violin, baseball. The cell at which the Baseball row and Address column intersect is shaded and contains an IP address.
Because a client can access table information at any level, NIS+ provides security mechanisms for all three levels. For instance, an administrator could assign read rights to everyone for a table at the object level, modify rights to the owner at the column level, and modify rights to the group at the entry level. Details about table security are provided in Administering NIS+ Access Rights.
A table contains information only about its local domain. For instance, tables in the wiz.com. domain contain information only about the users, clients, and services of the wiz.com. domain. The tables in the sales.wiz.com. domain store information only about the users, clients, and services of the sales.wiz.com. domain, and so on.
If a client in one domain tries to find information that is stored in another domain, the client must provide a fully qualified name. As described in NIS+ Name Expansion, if the NIS_PATH environment variable is set up properly, the NIS+ service does this automatically.
Every NIS+ table can also specify a search path that a server will follow when looking for information. The search path is an ordered list of NIS+ tables, separated by colons. For example:
The table names in the search path do not have to be fully qualified; they can be expanded just like names entered at the command line. When a server cannot find information in its local table, it returns the table's search path to the client. The client uses that path to look for the information in every table named in the search path, in order, until it finds the information or runs out of names.
For an example that demonstrates the benefit of search paths, assume a domain hierarchy as shown in the following figure.
Figure 4-11. Example NIS+ Namespace. This illustration shows an example NIS+ namespace showing the wiz.com. domain and subdomains called sales.wiz.com, test.wiz.com., and eng.wiz.com.
The hosts tables of the lower three domains have contents similar to that
described in the following example. Assume now that a user logged onto
a client in the sales.wiz.com. domain wants to
log in remotely to another client. If that user does not provide a
fully qualified name, it can only remotely log on to five workstations:
vermont, maine, cherry, apple, and
|127.0.0.1 localhost||127.0.0.1 localhost||127.0.0.1 localhost|
|18.104.22.168 vermont||22.214.171.124 nebraska||126.96.36.199 georgia|
|188.8.131.52 maine||184.108.40.206 oklahoma||220.127.116.11 florida|
|18.104.22.168 cherry||22.214.171.124 corn||126.96.36.199 orange|
|188.8.131.52 apple||184.108.40.206 wheat||220.127.116.11 potato|
|18.104.22.168 mailhost||22.214.171.124 mailhost||126.96.36.199 mailhost|
Now assume that the search path of the hosts table in the sales.wiz.com. domain listed the hosts tables from the test.wiz.com. and eng.wiz.com. domains:
A user in the sales.wiz.com. domain can enter something like rlogin oklahoma, and the NIS+ server will find it. It first looks for oklahoma in the local domain, but when it does not find a match, it looks in the test.wiz.com. domain. How does the client know how to find the test.wiz.com. domain? The information is stored in its directory cache. If it is not stored in its directory cache, the client obtains the information by following the process described in this chapter.
Specifying a search path does have drawbacks. If the user enters an incorrect name, such as rlogin potatoe for example, the server looks through three tables--instead of just one--before returning an error message. If you set up search paths throughout the namespace, an operation could search through the tables in 10 domains instead of just 2 or 3. Another drawback is a performance loss from having many clients contact more than one set of servers when they need to access NIS+ tables.
Note that because "mailhost" is often used as an alias, when trying to find information about a specific mailhost, you should use its fully qualified name (for example, mailhost.sales.wiz.com.), or NIS+ will return all the mailhosts it finds in all the domains it searches through.
You can specify a table search path by using the -p option to the nistbladm command.
Setting up NIS+ tables involves the following steps:
NIS+ system tables are stored under an org_dir directory. Before you can create any tables, you must do the following:
The nisserver script and the nissetup and nismkdir utilities are described in their reference descriptions.
A benefit of the nissetup utility is its capability to assign the proper access rights to the tables of a domain whose servers are running in NIS-compatibility mode. When entered with the -Y flag, it assigns read permissions to the nobody class of the objects it creates, allowing NIS clients, who are unauthenticated, to get information from the domain's NIS+ tables.
The NIS+ system tables and the type of information they store are described in the appendix. The easiest way to create them is to use the nisserver script. To create a nonstandard table--that is, a table that has not been preconfigured by NIS+--use the nistbladm command.
You can populate NIS+ tables in three ways:
When a domain is set up, its servers receive their first versions of the domain's NIS+ tables. These versions are stored on disk, but when a server begins operating, it loads them into memory. When a server receives an update to a table, it immediately updates its memory-based version of the table. When it receives a request for information, it uses the memory-based copy for its reply.
The server also needs to store its updates on disk. Since updating disk-based tables takes time, all NIS+ servers keep log files for their tables. The log files are designed to temporarily store changes made to the table, until they can be updated on disk. They use the table name as the prefix and append .log. For example:
hosts.org_dir.log bootparams.org_dir.log password.org_dir.log
It is recommended that you update disk-based copies of a table on a daily basis so that the log files do not grow too large and take up too much disk space. This process is called checkpointing. To do this, use the nisping -C command.