NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | BUGS | SEE ALSO
yp
The YP subsystem allows network management of passwd, group, netgroup, hosts, services, rpc and ethers file entries through the functions getpwent(3STDC), getgrent(3STDC), getnetgrent(3POSIX), gethostent(3STDC), getnetent(3POSIX), getrpcent(3RPC), and ethers(3STDC). NIS support for the hosts, services and rpc databases is enabled by uncommenting the nis line in /etc/host.conf. NIS support for the remaining services is activated by adding a special '+' entry to the appropriate file.
NIS is an RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location.
The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In the ChorusOS operating system, these maps are stored in /var/yp/[domainname] where [domainname] is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps.
In the ChorusOS operating system, the NIS maps are Berkeley DB hashed database files (the same format used for the passwd(4CC) database files). The Berkeley DB hash method uses a single file for both pieces of information. This means that while you may have passwd.byname.dir and passwd.byname.pag files on other operating systems (both of which are really parts of the same map), the ChorusOS operating system only has one file called passwd.byname. The difference in format is not significant: only the NIS server and related tools need to know the database format of the NIS maps. Client NIS systems receive all NIS data in ASCII form.
There are three main types of NIS systems:
NIS clients, which query NIS servers for information.
NIS master servers, which maintain the canonical copies of all NIS maps.
NIS slave servers, which maintain backup copies of NIS maps that are periodically updated by the master.
An NIS client establishes what is called a binding to a particular NIS server using the ypbind(1M) daemon. The ypbind(1M) daemon checks the system's default domain (as set by the domainname(1CC) command) and begins broadcasting RPC requests on the local network. These requests specify the name of the domain for which ypbind(1M) is attempting to establish a binding. If a server that has been configured to serve the requested domain receives one of the broadcasts, it will respond to ypbind(1M), which will record the server's address. If there are several servers available (a master and several slaves, for example), ypbind(1M) will use the address of the first one to respond. From that point on, the client system will direct all of its NIS requests to that server. The ypbind(1M) daemon will occasionally ``ping'' the server to make sure it's still up and running. If it fails to receive a reply to one of its pings within a reasonable amount of time, ypbind(1M) will mark the domain as unbound and begin broadcasting again in the hopes of locating another server.
On networks with a large number of hosts, it is often a good idea to use a master server and several slaves rather than just a single master server. Maintaining slave servers helps improve NIS performance on large networks by:
Providing backup services in the event that the NIS master crashes or becomes unreachable
Spreading the client load out over several machines instead of causing the master to become overloaded
Allowing a single NIS domain to extend beyond a local network (the ypbind(1M) daemon might not be able to locate a server automatically if it resides on a network outside the reach of its broadcasts. It is possible to force ypbind(1M) to bind to a particular server. This problem can be avoided simply by placing a slave server on the local network.)
The ChorusOS password database system includes support for shadow passwords. The standard password database does not contain users' encrypted passwords: these are instead stored (along with other information) in a separate database which is accessible only by the superuser. If the encrypted password database were made available as an NIS map, this security feature would be totally disabled, since any user is allowed to retrieve NIS data.
To help prevent this,the NIS server handles the shadow password maps (master.passwd.byname and master.passwd.byuid) in a special way: the server will only provide access to these maps in response to requests that originate on privileged ports. Since only the superuser is allowed to bind to a privileged port, the server assumes that all such requests come from privileged users. All other requests are denied: requests from non-privileged ports will receive only an error code from the server.
On the client side, getpwent(3STDC) functions will automatically search for the master.passwd maps and use them if they exist. If they do, they will be used, and all fields in these special maps (class, password age and account expiration) will be decoded. If they aren't found, the standard passwd maps will be used instead.
See attributes(5) for descriptions of the following attributes:
ATTRIBUTE TYPE | ATTRIBUTE VALUE |
---|---|
Interface Stability | Evolving |
The getservent(3POSIX) and getprotoent(3POSIX) functions do not yet have NIS support. Fortunately, these files don't need to be updated that often.
NAME | SYNOPSIS | DESCRIPTION | ATTRIBUTES | BUGS | SEE ALSO