Overview of NIS+

NIS+ allows you to maintain configuration information for many hosts in a set of distributed databases. You can read or modify these databases from any host in the network, if you have the proper credentials and access permissions. Common configuration information, which would have to be maintained separately on each host in a network without NIS+, can be stored and maintained in a single location and propagated to all of the hosts in the network.

Advantages of NIS+ over NIS

NIS+ has the following advantages over NIS:

NIS+ supports a hierarchical domain structure called the NIS+ namespace. You can create a separate domain for each workgroup or department in your organization. Each domain can be managed independently of the others. Hosts in any domain may have access to information in all the other domains in the namespace.
The NIS+ namespace can grow with your organization. Because information may be distributed over multiple domains, each with its own servers, the size of the NIS+ namespace is not limited by the capacity of any single server.
NIS+ is not limited by subnet boundaries. NIS+ clients do not broadcast requests, so you do not need a server on every subnet.
NIS+ is secure. It uses a private key/public key authentication scheme with DES encryption. Every user and host in the namespace has its own unique credentials, and you can decide which users and hosts will be allowed to read or modify the information in each NIS+ domain.
You can modify the information in an NIS+ table from any host in the namespace. Modifications are made directly to the NIS+ table, so you do not have to rebuild the table from a file.
Replica servers in NIS+ domains receive each table update as it is made. You do not have to push whole tables to the replica servers.
An NIS+ table may contain many columns, and you can search for entries based on the information in any column.

Disadvantages of NIS+

NIS+ has the following disadvantages:

NIS+ is difficult to administer. It requires dedicated system administrators trained in NIS+ administration. NIS+ administration is very different from NIS administration.
The NIS+ databases are not automatically backed up to flat files. The system administrator must create and maintain a backup strategy for NIS+ databases, which includes dumping them to flat files and backing up the files.

Structure of the NIS+ Namespace

An NIS+ namespace may be “flat,” consisting of a single domain, or it may be hierarchical, like the DNS domain structure. Every namespace has exactly one root domain. All other domains are subdomains of the root domain. Figure 5-1 “Sample NIS+ Namespace” shows a sample hierarchical NIS+ namespace.

The master server of the root domain is the root master server. Master servers of subdomains are called non-root master servers. NIS+ backup servers are called replica servers. Replica servers are the NIS+ equivalent of slave servers in an NIS domain. The replica servers of the root domain are called root replica servers, and the replica servers of the non-root domains are called non-root replica servers. A server may serve more than one domain, but it is not recommended.

All NIS+ servers must also be NIS+ clients. The root master and root replica servers are clients of the root domain. However, a non-root server serves a subdomain of the domain in which it is a client. The domain in which it is a client is the parent domain of the domain it serves.

Figure 5-1 Sample NIS+ Namespace

Structure of an NIS+ Domain

An NIS+ domain is an NIS+ directory whose name is the domain name. An NIS+ directory is not an HP-UX directory. You must use the nisls(1) command to see the directory structure of an NIS+ domain. Figure 5-2 “NIS+ Directory Structure of the “Wiz.Com.” and “Eng.Wiz.Com.” Domains” shows the NIS+ directory structure of the Wiz.Com.and Eng.Wiz.Com. domains.

Each NIS+ domain contains two NIS+ subdirectories, called groups_dir and org_dir. The groups_dir subdirectory contains NIS+ groups, which are like HP-UX groups except they are used only to determine access to NIS+ objects. The org_dir subdirectory contains all the standard NIS+ tables. Any other NIS+ directories are subdomains. In the example in Figure 5-2 “NIS+ Directory Structure of the “Wiz.Com.” and “Eng.Wiz.Com.” Domains”, Eng.Wiz.Com. is a subdomain.

Figure 5-2 NIS+ Directory Structure of the “Wiz.Com.” and “Eng.Wiz.Com.” Domains

The full name of an NIS+ object includes the names of all the NIS+ directories in its directory path. For example, the full name of the hosts table in the Wiz.Com. domain is hosts.org_dir.Wiz.Com. To specify an entry in this table, you need to specify enough column values to uniquely identify it. For example, to identify a host whose canonical name in the cname column is romney, you would specify [cname=romney],hosts.org_dir.Wiz.Com. If the default domain on the local host is Wiz.Com., you can leave off the domain name and type just hosts.org_dir or [cname=romney],hosts.org_dir. Domain names always end in a period, except when you are setting the default domain with the domainname command.

How NIS+ Information is Stored and Propagated

NIS+ information is stored in the /var/nis directory. On a server, the /var/nis/data subdirectory, or the /var/nis/hostname subdirectory (where hostname is the name of the local host), contains the NIS+ directories and tables that make up the domain.

You can make changes to the NIS+ objects from any NIS+ client in the namespace, if you are authenticated and have the proper access permissions. Whenever anyone makes a change to an NIS+ object, the change is sent to all the replica servers. NIS+ sends only the changes to replica servers, not whole tables. A transaction log in the /var/nis directory on each server keeps track of all the changes that have been made. To keep the transaction log from growing too large, you must checkpoint the domain regularly. When you checkpoint the domain (with the nisping[1M] command), the changes in the transaction log on all the servers are incorporated into the tables on disk, and the transaction log is cleared.

An NIS+ client may get information from any domain in the namespace, if it is authenticated and has the proper access permissions. Each NIS+ client has a file called NIS_COLD_START in the /var/nis directory, which contains the internet addresses of servers the client can contact for NIS+ information. Because all servers are also clients, every server has a cold start file, too. An NIS+ client does not “bind” to a server the way an NIS client does. It contacts a server directly to request information. If a client requests information about a domain from a server that does not serve the domain, the server tells the client how to find a server that serves the domain. As the client learns about other servers, it adds the information to a cache file called NIS_SHARED_DIRCACHE in the /var/nis directory, and it uses the information to find servers later.

NIS+ Tables

By default, an NIS+ domain that you set up with the standard scripts contains the NIS+ tables listed in Table 5-1 “Standard NIS+ Tables”. Table 5-1 “Standard NIS+ Tables” also gives the configuration files and the NIS maps that are equivalent to the NIS+ tables.

Table 5-1 Standard NIS+ Tables

NIS+ Table

Equivalent File

Equivalent NIS maps

Purpose

auto_home

/etc/auto_home

auto.home

Location of users’ home directories.

auto_master

/etc/auto_master

auto.master

Mapping of AutoFS mount points to AutoFS maps.

bootparams

none on HP-UX

bootparams

Not used on HP-UX. Provided for Sun interoperability.

cred

/etc/publickey

publickey.byname

Secure RPC keys and netnames for authenticating users and hosts.

ethers

none on HP-UX

ethers.byname
ethers.byaddr

Not used on HP-UX. Provided for Sun interoperability.

group

/etc/group

group.bygid
group.byname

List of HP-UX groups, their group IDs and members.

hosts

/etc/hosts

hosts.byaddr
hosts.byname

Mapping of host names to internet addresses.

mail_aliases

/etc/mail/aliases

mail.aliases
mail.byaddr

sendmail aliases and their corresponding mailing lists.

netgroup

/etc/netgroup

netgroup
netgroup.byhost
netgroup.byuser

List of netgroups (used only with NFS services) and their members.

netmasks

If needed, the /etc/netmasks file must be created manually.

netmasks.byaddr

This file is used by AutoFS for the replicated servers configuration.

networks

/etc/networks

networks.byaddr
networks.byname

Mapping of network names to network addresses.

passwd

/etc/passwd

passwd.byname
passwd.byuid

List of user names and IDs with associated user information.

protocols

/etc/protocols

protocols.byname
protocols.bynumber

Mapping of networking protocols to protocol numbers.

rpc

/etc/rpc

rpc.bynumber
rpc.byname

Mapping of RPC programs to program numbers.

sendmailvars

none on HP-UX

none

Not used on HP-UX. Provided for Sun interoperability.

services

/etc/services

services.byname
servi.bynp

Mapping of networking services to port numbers and protocols.

timezone

/etc/TIMEZONE

none

Timezone of the local host.

trusted

/tcb/files/auth

NIS+ Authentication and Authorization

Authentication is the process by which NIS+ determines who you are. To be an authenticated NIS+ user, you must have an entry in the cred table, and your password must decrypt your secure RPC key, which is stored in the cred table.

When you log in and supply your password, NIS+ identifies you as an NIS+ principal. If you are a non-root user, your NIS+ principal name is loginname.domainname. For example, if you log in as user ming in domain Wiz.Com., your NIS+ principal name is ming.Wiz.Com. If you are a root user, NIS+ identifies you by the host name where you logged in, and your NIS+ principal name is hostname.domainname. For example, if you logged in as root to host garlic in the Eng.Wiz.Com. domain, your NIS+ principal name is garlic.Eng.Wiz.Com.

The cred table stores two types of credentials: Local and DES. A Local credential associates an NIS+ principal name with a user ID. Only non-root users have Local credentials. A DES credential contains the secure RPC keys for authenticating an NIS+ user. Both root and non-root users may have DES credentials. Each NIS+ principal has only one DES credential, in his or her home domain, but he or she may have Local credentials in many domains.

Authorization is the process by which NIS+ determines what you are allowed to do with NIS+ objects. Every NIS+ object has a permissions string that determines who can read, modify, create, or destroy it. This permissions string is similar to the HP-UX file permissions string that grants read, write, and execute permissions to HP-UX users.

NIS+ grants 4 types of permissions: (r)ead, (m)odify, (c)reate, and (d)estroy. It grants permissions to 4 types of users: nobody, owner, group, and world. Figure 5-3 “Format of the NIS+ Permissions String” shows the format of an NIS+ permissions string:

Figure 5-3 Format of the NIS+ Permissions String

User nobody is the group of all unauthenticated users. If you have no entry in the cred table, NIS+ identifies you as user nobody and assigns you a user ID of -2.

The owner of an NIS+ object is typically the NIS+ principal who created it. However, you can change the owner of an NIS+ object with the nischown(1) command.

The group is the NIS+ group that owns the object. NIS+ groups are stored in the groups_dir subdirectory under each domain directory. An NIS+ domain typically has an admin group consisting of the NIS+ principals who administer the domain. Not every NIS+ object has a group owner. For more information on NIS+ groups, type man 1 nisgrpadm at the HP-UX prompt.

The world is the group of all authenticated NIS+ principals. If you are an authenticated NIS+ principal, but you are not the owner of an object, and you are not a member of the NIS+ group that owns the object, then you will have whatever access permissions are granted to the world.

Every NIS+ directory has an owner and permissions associated with it. Every table has an owner and permissions. Entries and columns in a table have all the permissions the table has, but you can assign more permissions to an entry or column than the table has. An entry’s owner and group owner may be different from the owner and group owner of the table to which the entry belongs.

When an NIS+ object is created, it inherits a default owner and permissions. Most NIS+ commands have an option for overriding these defaults. You can also change these defaults. Type man 1 nisdefaults at the HP-UX prompt for more information. After an NIS+ object has been created, you can change its owner with the nischown(1) command, its group owner with the nischgrp(1) command, and its permissions with the nischmod(1) command.

NIS Compatibility Mode

An NIS+ server may serve NIS clients, by running in NIS compatibility mode. NIS compatibility mode is intended as a migration tool, to allow you to migrate your servers from NIS to NIS+ without having to migrate all your clients to NIS+ at the same time.

NIS compatibility mode has the following disadvantages:

NIS compatibility mode is less secure than regular mode. NIS clients cannot be authenticated by NIS+, so NIS compatibility mode allows unauthenticated clients to read the passwd table.
If you have links or concatenation paths in NIS+ tables, NIS clients will not be able to follow them.
NIS clients may read information only in their default domain. They cannot read information in other domains in the namespace.
Every NIS client must have a server on its local subnet, unless its server name has been set with the ypset command.

If any server in an NIS+ domain is running in NIS compatibility mode, all servers for that domain must run in NIS compatibility mode.

All servers in an NIS+ domain must be NIS+ servers. You cannot mix NIS servers and NIS+ servers in the same domain.

Overview of NIS+

Technical documentation

» Table of Contents

» Index

Advantages of NIS+ over NIS

Disadvantages of NIS+

Structure of the NIS+ Namespace

Structure of an NIS+ Domain

How NIS+ Information is Stored and Propagated

NIS+ Tables

NIS+ Authentication and Authorization

NIS Compatibility Mode