Network Information Service (NIS) software lets you administer both UNIX and NetWare from a single point, namely eDirectory.
NIS is a yellow pages service widely implemented in UNIX environments. NIS contains common information about users, groups, and hosts and other information that any client might require. This information could include a list of network hosts, protocol information, and even non-standard information that is likely to benefit from a centralized administration such as phone list.
NIS maintains its information in eDirectory and integrates the user/group information so that the eDirectory User/Group object also represents the NIS user/group. In the eDirectory enabled NIS, all NIS-related information is stored as eDirectory objects. The NetWare NIS can be set up to work in the various NIS configurations available.
NetWare Implementation of NIS: In the NetWare implementation of NIS, individual NIS Records, NIS Maps, NIS Domains, and NIS Servers are eDirectory objects with additional custom attributes defined to accommodate the NIS-specific information.
A typical UNIX system stores user account information in the /etc/passwd file and group information in the /etc/group file. The migration utility lets you migrate the user/group information to eDirectory. For more information on the migration utility, see Section 7.13, Migrating NIS Maps.
NetWare NIS is installed as part of the Native File Access for UNIX installation, and the NIS Server eDirectory object is created with the name NISSERV_ ServerName in the default (first) bindery context of the server or in the Server’s eDirectory context.
This NISSERV_ ServerName is the main NIS Server eDirectory object. It maintains a list of all the NIS Domains it is serving. To view and edit the list:
Right-click the NISSERV_ servername object > Click .
Click the Memberships tab to display the list of NIS Domains served by this NIS Server object.
Click the Others tab to view the IP address associated to NISSERV_servername object.
The NIS services organizes nodes into administrative segments called domains. The NIS domain exists only in the local environment and usually covers a single network. A NIS domain is a hierarchical structure, so it is stored as a container in eDirectory. NIS does not impose any strict rules on domain naming; however, each domain must have a unique name.
An administrative NIS domain could be a company or a division of a company. Many administrators who use DNS prefer relating the NIS domain name to their DNS domain name, but this is not necessary.
NIS stores all the common information pertaining to a domain as a set of NIS maps. Users can access the information in these NIS maps. In the eDirectory-enabled NIS, these maps are stored as containers under the NIS domain container. The migration utility lets you create the NIS maps under a specified domain.
The NIS Server supports both standard and custom maps.
Standard NIS Maps: Standard maps are created from the standard NIS text files.
The following standard maps are supported. They are classified according to the type of records that they contain.
Ethers Map: A source of information about the Ethernet addresses (48-bit) of hosts on the Internet. The Ether objects (ieee802Device) store information about the Ethernet address and hostname.
Bootparams Map: A source of information for various boot parameters. The Boot objects store information about the boot parameters of the various devices that are running. To migrate the Bootparams text filename from the ConsoleOne, name the text file to bootp.
Hosts Map: Contains one entry for each IP address of each host. If a host has more than one IP address, it has an entry for each IP address. The Hosts objects store the IP address and hostname as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Netgroup Map: A source of information about Net Group parameters. It provides the abstraction of net groups.
Networks Map: Contains a single object for each network. The Network objects store network names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Protocols Map: Contains one object for each protocol. The Protocols objects store protocol names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
RPC Map: Contains one object for each Remote Procedure Call (RPC) program name. The RPC objects store RPC program names as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Services Map: Contains an object for each service. The Services objects store service names, ports, and protocols as distinguished values of CN, and aliases and nicknames are stored as other values of CN attributes.
Passwd Map: Maintains the details of the users such as UID, Username, and home directory.
Group Map: Maintains the details of the groups present such as GID, Group name, and Group members.
Ypservers Map: Maintains a list of NIS slave servers which can serve the NIS domain.
Custom NIS Maps: You can use NIS to store any common configuration information that is valuable to NIS clients. Maps you create in addition to the standard NIS maps are called custom maps. For example, you can create an NIS map that provides an employee phone list.
You can create custom maps by creating a text file that contains the relevant configuration information. After creating the text file, you convert it into an NIS map through migration.
To create a phone list map, begin by creating a text file containing each employee’s name and phone number.
An NIS map text file must conform to the following rules:
Each data line begins a new entry key.
The backslash character (\) at the end of a line appends the next line to the current line.
The pound sign (#) at the beginning of a line tells the converter to ignore the line.
Blanks separate the key and the value. Therefore, you must use underscores (_) to replace all other blanks within the key, such as the space between an employee’s first and last names. Blanks are acceptable within the key values such as the phone list.
The following is an example of the phone list text file:
# This is the text file for the phone list map.
Janice_SmithMS 881-1456
Bob_RodriguezMS 235-6777
Eric_Mueller MS 769-8909
NIS can be configured in the following ways:
The master server is the true single owner of map data. It is responsible for all map maintenance and distribution to slave servers. After an NIS map is built on the master, the new map file is distributed to all slave servers for that domain, through the client-server relationship. You must, therefore, make all the modifications only on the master. The master maintains a list of slave servers within its domain in the form of a map named Ypservers.
You can set up read-only copies of the NIS database on secondary servers. The secondary servers are referred to as slaves. When the server is set up as an NIS slave, it contacts the master NIS server and requests a complete copy of the NIS maps on that server.
After the slave server is set up, you do not need to manage the update process manually. The slave servers periodically query the master and request an update when the slave detects a more recent time stamp on the master. You can get an immediate update of the slave servers through ConsoleOne. A slave server can be added to the Ypservers map in the master.
We recommend that you set up at least one slave server for each NIS domain. The slave server can then function as a standby if the master server goes down, although it might not be necessary in all networks. Slave servers can be used for load distribution in the network. A master NIS server for one domain can function as a slave NIS server for another domain.
The NIS client enables users to query NIS map information from NIS servers.
For more information on setting up and managing NIS, see Section 7.15, Managing NIS Server.
With the implementation of NIS over eDirectory, a single user or group in the network contains both eDirectory and UNIX information. This brings the user management to single point, namely eDirectory.
For this purpose, the eDirectory schema has been extended and the relevant user information is placed in the eDirectory Library. The User object now stores UNIX information such as UID, GID, password, home directory, and shell in eDirectory.
By default, UNIX users or groups are looked for within the containers specified by the search_root parameter in the nfs.cfg configuration file. The search is recursive within the containers specified by this parameter. If the parameter does not contain any value, then the search is done under the default (first) bindery or servers context.
When a set of users or groups are migrated to eDirectory from a UNIX server, corresponding User/Group objects are created or updated in eDirectory. During migration, if the UNIX user or group does not exist, a new eDirectory User or Group object is created with default NetWare rights. If the User or Group object exists, the user or group’s UNIX-related information is updated by default during the migration.