test

Solaris Naming Administration Guide

Chapter 17 Network Information Service (NIS)

This chapter describes NIS, the Network Information Service.

See Solaris Naming Setup and Configuration Guide for information on how to initially setup and configure NIS.

NIS Introduction

NIS is a distributed name service. It is a mechanism for identifying and locating network objects and resources. It provides a uniform storage and retrieval method for network-wide information in a transport-protocol and media-independent fashion.

By running the service, the system administrator can distribute administrative databases, called maps, among a variety of servers (master and slaves), and update those databases from a centralized location in an automatic and reliable fashion to ensure that all clients share the same name service information in a consistent manner throughout the network. For additional overview and background information on NIS, see "NIS".

NIS was developed independently of DNS and has a slightly different focus. Whereas DNS focuses on making communication simpler by using machine names instead of numerical IP addresses, NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information not only about machine names and addresses, but also about users, the network itself, and network services. This collection of network information is referred to as the NIS namespace.

Note -

In some contexts machine names are referred to has host names or workstation names. This discussion uses machine, but some screen messages or NIS map names may use host or workstation.

NIS Architecture

NIS uses a client-server arrangement. NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, they have backup, or slave servers. Both master and slave servers use the NIS information retrieval software and both store NIS maps.

NIS uses domains to arrange the machines, users, and networks in its namespace. However, it does not use a domain hierarchy; an NIS namespace is flat. Thus, this physical network:

Graphic

would be arranged into one NIS domain:

Graphic

A NIS domain cannot be connected directly to the Internet using just NIS. However, organizations that want to use NIS and also be connected to the Internet can combine NIS with DNS. You can use NIS to manage all local information and use DNS for Internet host lookup. NIS provides a forwarding service that forwards host lookups to DNS if the information cannot be found in a NIS map. The Solaris operating system also allows you to set up the nsswitch.conf file so that hosts lookup requests go only to DNS, or to DNS and then NIS if not found by DNS, or to NIS and then DNS if not found by NIS. (See Chapter 2, The Name Service Switch, for details.)

NIS and NIS+

Both NIS and NIS+ perform some of the same tasks. NIS+, however, allows for hierarchical domains, namespace security, and other features that NIS does not provide. For a more detailed comparison between NIS and NIS+, see "How NIS+ Differs From NIS".

You can use NIS in conjunction with NIS+ under the following principles and conditions:

Which service a machine uses for various name services is controlled by the machine's nsswitch.conf file. This file is called the switch file. See Chapter 2, The Name Service Switch for further information.

NIS and FNS

Under certain conditions, FNS commands can be used by NIS clients to update naming information that pertains to them such as file systems and printers. (See "NIS Clients Can Update Contexts With FNS if SKI is Running" for details.)

NIS Machine Types

There are three types of NIS machines:

Any machine can be an NIS client, but only machines with disks should be NIS servers, either master or slave. Servers are also clients, typically of themselves.

NIS Servers

By definition, an NIS server is a machine storing a set of maps that are available to network machines and applications. The NIS server does not have to be the same machine as the NFS file server.

NIS servers come in two varieties, master and slave. The machine designated as master server contains the set of maps that you, the NIS administrator, create and update as necessary. Each NIS domain must have one, and only one, master server. This should be a machine that can propagate NIS updates with the least performance degradation.

You can designate additional NIS servers in the domain as slave servers. A slave server has a complete copy of the master set of NIS maps. Whenever the master server maps are updated, the updates are propagated among the slave servers. The existence of slave servers allows the system administrator to evenly distribute the load resulting from answering NIS requests. It also minimizes the impact of a server becoming unavailable.

Normal practice is to designate one master server for all NIS maps. However, because each individual NIS map has the machine name of the master server encoded within it, you could designate different servers to act as master and slave servers for different maps. Note, however, that randomly designating a server as master of one map and another server as master of another map can cause a great deal of administrative confusion. For that reason it is best to have a single server be the master for all the maps you create within a single domain. The examples in this chapter assume that one server is the master for all maps in the domain.

NIS Clients

NIS clients run processes that request data from maps on the servers. Clients do not make a distinction between master and slave servers, since all NIS servers should have the same information.

NIS servers are also clients, typically though not necessarily, of themselves. For information on how to create NIS clients, refer to the ypbind man page.

NIS Elements

The NIS service is composed of the following elements:

The NIS Domain

An NIS domain is a collection of machines that share a common set of NIS maps. Each domain has a domain name and each machine sharing the common set of maps belongs to that domain. Domain names are case-sensitive.

Any machine can belong to a given domain, as long as there is a server for that domain's maps in the same network. Solaris Release 2 machines do not require the server to be on the same subnet, but earlier implementations of NIS historically have required that a server exist on every subnet using NIS. A NIS client machine obtains its domain name and binds to a NIS server as part of its boot process.

NIS Daemons

NIS service is provided by five daemons as shown in Table 17-1.

Table 17-1 NIS Daemons

Daemon 

Function 

ypserv

Server process 

ypbind

Binding process 

ypxfr

High speed map transfer 

rpc.yppasswdd

NIS password update daemon 

rpc.ypupdated

Modifies other maps such as publickey

NIS Utilities

NIS service is supported by nine utilities as shown in Table 17-2.

Table 17-2 NIS Utilities

Utility 

Function 

makedbm

Creates dbm file for an NIS map

ypcat

Lists data in a map 

ypinit

Builds and installs an NIS database and initializes NIS client's ypservers list.

yppmatch

Finds a specific entry in a map 

yppoll

Gets a map order number from a server 

yppush

Propagates data from NIS master to NIS slave server 

ypset

Sets binding to a particular server 

ypwhich

Lists name of the NIS server and nickname translation table 

ypxfr

Transfers data from master to slave NIS server 

NIS Maps

NIS stores information in a set of files called maps.

NIS maps were designed to replace UNIX /etc files, as well as other configuration files, so they store much more than names and addresses. On a network running NIS, the NIS master server for each NIS domain maintains a set of NIS maps for other machines in the domain to query. NIS slave servers also maintain duplicates of the master server's maps. NIS client machines can obtain name space information from either master or slave servers.

NIS maps are one type of implementation of Solaris databases. (Other types, not necessarily overlapping, are the files generally found in the /etc directory, the DNS resource records (RRs), and NIS+ tables.)

NIS Maps Overview

NIS maps are essentially two-column tables. One column is the key and the other column is information value related to the key. NIS finds information for a client by searching through the keys. Some information is stored in several maps because each map uses a different key. For example, the names and addresses of machines are stored in two maps: hosts.byname and hosts.byaddr. When a server has a machine's name and needs to find its address, it looks in the hosts.byname map. When it has the address and needs to find the name, it looks in the hosts.byaddr map.

Maps for a domain are located in each server's /var/yp/domainname directory. For example, the maps that belong to the domain test.com are located in each server's /var/yp/test.com directory.

An NIS Makefile is stored in the /var/yp directory of machines designated as a NIS server at installation time. Running make in that directory causes makedbm to create or modify the default NIS maps from the input files. (See Solaris Naming Setup and Configuration Guide for a description of using this process to initially set up your NIS name space.)

Note -

Never make the maps on a slave server. Always run make on the master server.

The information in NIS maps is stored in ndbm format. The ypfiles and ndbm man pages explain the format of the map file.

Default NIS Maps

A default set of NIS maps are provided for you. You may want to use all these maps or only some of them. NIS can also use whatever maps you create or add when you install other software products.

Table 17-3 describes the default NIS maps, information they contain, and whether the operating system consults the corresponding administrative files when NIS is running.

Table 17-3 NIS Map Descriptions

Map Name 

Corresponding NIS Admin File 

Description 

bootparams

bootparams

Contains path names of files clients need during boot: root, swap, possibly others. 

ethers.byaddr

ethers

Contains machine names and Ethernet addresses. The Ethernet address is the key in the map. 

ethers.byname

ethers

Same as ethers.byaddr, except the key is machine name instead of the Ethernet address.

group.bygid

group

Contains group security information with group ID as key. 

group.byname

group

Contains group security information with group name as key. 

hosts.byaddr

hosts

Contains machine name, and IP address, with IP address as key. 

hosts.byname

hosts

Contains machine name and IP address, with machine (host) name as key. 

mail.aliases

aliases

Contains aliases and mail addresses, with aliases as key. 

mail.byaddr

aliases

Contains mail address and alias, with mail address as key. 

netgroup.byhost

netgroup

Contains group name, user name and machine name. 

netgroup.byuser

netgroup

Same as netgroup.byhost, except that key is user name.

netgroup

netgroup

Same as netgroup.byhost, except that key is group name.

netid.byname

passwd, hosts

group

Used for UNIX-style authentication. Contains machine name and mail address (including domain name). If there is a netid file available it is consulted in addition to the data available through the other files.

netmasks.byaddr

netmasks

Contains network mask to be used with IP submitting, with the address as the key. 

networks.byaddr

networks

Contains names of networks known to your system and their IP addresses, with the address as the key. 

networks.byname

networks

Same as networks.byaddr, except key is name of network.

passwd.adjunct. byname

passwd and shadow

Contains auditing information and the hidden password information for C2 clients. 

passwd.byname

passwd and shadow

Contains password information with user name as key. 

passwd.byuid

passwd and shadow

Same as passwd.byname, except that key is user ID.

protocols.byname

protocols

Contains network protocols known to your network. 

protocols.bynumber

protocols

Same as protocols.byname, except that key is protocol number.

rpc.bynumber

rpc

Contains program number and name of RPCs known to your system. Key is RPC program number. 

services.byname

services

Lists Internet services known to your network. Key is port or protocol. 

services.byservice

services

Lists Internet services known to your network. Key is service name. 

ypservers

N/A 

Lists NIS servers known to your network. 

Using NIS Maps

NIS makes updating network databases much simpler than with the /etc files system. You no longer have to change the administrative /etc files on every machine each time you modify the network environment.

For example, when you add a new machine to a network running NIS, you only have to update the input file in the master server and run make. This automatically updates the hosts.byname and hosts.byaddr maps. These maps are then transferred to any slave servers and are made available to all of the domain's client machines and their programs. When a client machine or application requests a machine name or address, the NIS server refers to the hosts.byname or hosts.byaddr map as appropriate and sends the requested information to the client.

You can use the ypcat command to display the values in a map. The ypcat basic format is: 


% ypcat mapname

Where mapname is the name of the map you want to examine or its nickname. If a map is composed only of keys, as in the case of ypservers, use ypcat -k; otherwise, ypcat prints blank lines. The ypcat man page describes more options for ypcat.

You can use the ypwhich command to determine which server is the master of a particular map. Type the following: 


% ypwhich -m mapname

Where mapname is the name or the nickname of the map whose master you want to find. ypwhich responds by displaying the name of the master server. For complete information, refer to the ypwhich man page.

NIS Map Nicknames

Nicknames are aliases for full map names. To obtain a list of available map nicknames, such as passwd for passwd.byname, type ypcat -x or ypwhich -x.

Nicknames are stored in the /var/yp/nicknames file, which contains a map nickname followed by the fully specified name for the map, separated by a space. This list may be added to or modified. Currently, there is a limit of 500 nicknames.

Summary of NIS-Related Commands

The NIS service includes specialized daemons, system programs, and commands, which are summarized in Table 17-4. Refer to their man pages for details about how to use them.

Table 17-4 NIS Command Summary

Command 

Description 

ypserv

Services NIS clients' requests for information from a NIS map. ypserv is a daemon that runs on NIS servers with a complete set of maps. At least one ypserv daemon must be present on the network for NIS service to function.

ypbind

Provides NIS server binding information to clients. It provides binding by finding a ypserv process that serves maps within the domain of the requesting client. ypbind must run on all servers and clients.

ypinit

Automatically creates maps for an NIS server from the input files. It is also used to construct the initial /var/yp/binding/domain/ypservers file on the clients. Use ypinit to set up the master NIS server and the slave NIS servers for the first time.

make

Updates NIS maps by reading the Makefile (when run in the /var/yp directory). You can use make to update all maps based on the input files or to update individual maps. The ypmake(1M) man page describes the functionality of make for NIS.

makedbm

makedbm takes an input file and converts it into dbm.dir and dbm.pag files--valid dbm files that NIS can use as maps. You can also use makedbm -u to disassemble a map, so that you can see the key-value pairs that comprise it.

ypxfr

Pulls an NIS map from a remote server to the local /var/yp/domain directory, using NIS itself as the transport medium. You can run ypxfr interactively, or periodically from a crontab file. It is also called by ypserv to initiate a transfer.

ypxfrd

Provides map transfers service for ypxfr requests (generally slave servers). It is run only on the master server.

yppush

Copies a new version of an NIS map from the NIS master server to its slaves. You run it on the master NIS server. 

ypset

Tells a ypbind process to bind to a named NIS server. This is not for casual use and its use is discouraged because of security implications. See the ypset(1M) and ypbind(1M) man pages for information about the ypset and ypsetme options to the ypbind process.

yppoll

Tells which version of an NIS map is running on a server that you specify. It also lists the master server for the map. 

ypcat

Displays the contents of an NIS map. 

ypmatch

Prints the value for one or more specified keys in an NIS map. You cannot specify which version of the NIS server map you are seeing. 

ypwhich

Shows which NIS server a client is using at the moment for NIS services, or, if invoked with the -m mapname option, which NIS server is master of each of the maps. If only -m is used, it displays the names of all the maps available and their respective master servers.

NIS Binding

NIS clients get information from a NIS server through the binding process, which can work in one of two modes: server-list or broadcast.

Server-List Mode

The binding process in server-list mode works as follows:

  1. Any program, running on the NIS client machine that needs information provided by an NIS map, asks ypbind for the name of a server.

  2. ypbind looks in the /var/yp/binding/domainname/ypservers file for a list of NIS servers for the domain.

  3. ypbind initiates binding to the first server in the list. If the server does not respond, ypbind tries the second, and so on, until it finds a server or exhausts the list.

  4. ypbind tells the client process which server to talk to. The client then sends the request directly to the server.

  5. The ypserv daemon on the NIS server handles the request by consulting the appropriate map.

  6. ypserv sends the requested information back to the client.

Broadcast Mode

The broadcast mode binding process works as follows:

  1. ypbind must be started with the broadcast option set (broadcast).

  2. ypbind issues an RPC broadcast in search of an NIS server.

Note -

In order to support such clients, it is necessary to have an NIS server on each subnet requiring NIS service.

  1. ypbind initiates binding to the first server that responds to the broadcast.

  2. ypbind tells the client process which server to talk to. The client then sends the request directly to the server.

  3. The ypserv daemon on the NIS server handles the request by consulting the appropriate map.

  4. ypserv sends the requested information back to the client.

Normally, once a client is bound to a server it stays bound to that server until something causes it to change. For example, if a server goes out of service, the clients it served will then bind to new servers.

To find out which NIS server is currently providing service to a specific client, use the following command:


% ypwhich machinename

Where machinename is the name of the client. If no machine name is mentioned, ypwhich defaults to the local machine (that is, the machine on which the command is run).

Differences Between This and Earlier NIS Versions

The following features are new or different in Solaris Release 2.6 NIS.

NSKit Discontinued

The most recent Solaris releases have not included NIS service. Up to now, NIS service had to be installed from the unbundled NSKit. NIS has now been included in the Solaris Release 2.6 and there is no 2.6 Release NSKit.

Because NIS service is now part of the Solaris 2.6 Release, the SUNWnsktu and SUNWnsktr packages no longer exist. Instead, NIS is now installed via the NIS Server cluster (containing the SUNWypu and SUNWypr packages).

NIS service is no longer started with the /etc/init.d/yp script which no longer exists. With the Solaris 2.6 Release, you first configure your master server NIS maps with the ypinit script, and then start NIS with ypstart. NIS service is stopped with the ypstop command.

The ypupdated Daemon

The most recent versions of NSKit did not include the ypupdated daemon. The ypupdated daemon is now included in this Solaris release.

/var/yp/securenets

As with the previous NSKit release, the /var/yp/securenets file is now used to limit access to NIS services. If such a file exists on an NIS server, the server only answers queries or supplies maps to machines and networks listed in the file. For the file format, see the securenets man page.

The following is an example of a securenets file.


255.255.255.0	13.13.13.255
host	  13.13.14.1
host  	13.13.14.2

Multihomed Machine Support

As with the previous NSKit release, the ypserv process provides support for machines which have more than one network address. When the machine maps are created, the Makefile creates a YP_MULTI_HOSTNAME entry in the map for any machine that has more than one address. This entry lists all the addresses for that machine. When the machine address is needed, an attempt is made to use the closest address on the list. See the ypserv man page for more details.

The determination of closest address is an arithmetic one and as such there is no check for address validity. For example, suppose that a multihomed machine has six IP addresses and only five of the interfaces on the machine are operating normally. Machines on a network that is not directly connected to this multihomed machine can receive the IP address for the down interface from ypserv. Thus, this hypothetical client can not reach the multihomed machine.

Note -

All addresses for a multihomed machine should normally be active. If a particular address or machine is going to be out of service, remove it from the NIS maps.

Sun Operating System 4.X Compatibility Mode

Solaris 2.6 release NIS supports password configuration files in both the Sun Operating System 4.x (Solaris release 1) password format and the Solaris Release 2 password and shadow file formats.

The mode of operation is determined by the existence of the file $PWDIR/shadow, where $PWDIR is the Makefile macro set in the /var/yp/Makefile file. If the shadow file exists, NIS operates in the Solaris Release 2 mode. If this file does not exist, NIS operates in the SunOS 4.x mode.

In the SunOS 4.x mode, all password information is kept in the passwd file. In the Solaris Release 2 mode, password information is kept in the shadow file and the user account information is kept in the passwd file.

If the make macro PWDIR is set to the /etc directory, NIS can operate only in the Solaris Release 2 mode because of the Solaris Release 2 passwd processing requirements. However, if PWDIR points to any directory other than /etc, the user has the option of keeping passwd configuration files in either the SunOS 4.x format or in the Solaris Release 2 format. The rpc.yppasswdd daemon understands both password formats. The Solaris Release 2 format is recommended.

Using the Name Service Switch

The name service switch is designed to simplify name service administration. Client machines and applications use this switch to select a name service. The switch mechanism is implemented using the /etc/nsswitch.conf file, which specifies the source(s) used to resolve references for each information type.

This section discusses only those elements that are needed to properly configure the name service switch for NIS operation. For a more detailed description of the nsswitch.conf file, see Chapter 2, The Name Service Switch.

An nsswitch.conf file is automatically loaded into every machine's /etc directory by the Solaris 2.6 release software, along with three alternate (template) versions:

These alternate template files contain the default switch configurations used by the NIS+ service, NIS, and local files. (See "The nsswitch.conf Template Files".) No default file is provided for DNS, but you can edit any of these files to use DNS (see"DNS Forwarding for NIS Clients").

Note that this switch functionality does not exist under SunOS 4.x. Thus, DNS forwarding for 4.x clients must be done on the NIS server. In this situation, if a 4.x client requests information for a host that is not listed in the NIS server's NIS map, the NIS server forwards the client's host request to a DNS server on the client's behalf.

When Solaris 2.6 release software is first installed on a machine, the installer selects the machine's default name service: NIS+, NIS, or local files. During installation, the corresponding template file is copied to /etc/nsswitch.conf. For a machine client using NIS, the installation process copies nsswitch.nis to nsswitch.conf. Unless you have an unusual NIS database setup, the default /etc/nsswitch.nis template file as copied to nsswitch.conf should be sufficient for NIS operation.

When changing a machine client from naming system (/etc, NIS or NIS+) to another, you copy the corresponding template file to nsswitch.conf. You can also change the sources of particular types of network information used by the client by editing the appropriate lines of the /etc/nsswitch.conf file. See Solaris Naming Setup and Configuration Guide, and Chapter 2, The Name Service Switch.

Caution - Caution -

If the /etc/nsswitch.conf file is set to files and not nis for host information, and the server is not included in the /etc/hosts file, then the ypcat command generates the following error message: RPC failure: "RPC failure on yp operation"