The Network Information Service (NIS) has the following features:
The NIS system serves information stored in NIS "maps." Each map contains a set of keys and associated values. For example, in a map called hosts, all the host names within a network are the keys, and the Internet addresses of these host names are the values. Each NIS map has a map name used by programs to access it. Programs must know the format of the data in the map. Many of the current maps are derived from ASCII files traditionally found in /etc; examples include hosts, group, passwd, shadow, and a few others. The format of the data within the NIS map is identical, in most cases, to the format within the ASCII file. Maps are implemented as files located in subdirectories of the directory /var/yp on NIS server machines.
An NIS domain is a named set of NIS maps. Users can determine and set their NIS domains with the domainname(1) command. NIS domains differ from both Internet domains and sendmail domains. An NIS domain is simply a directory in /var/yp where an NIS server holds all of the NIS maps. The name of the subdirectory is the name of the domain. For example, maps for the literature domain would be in /var/yp/literature.
A domain name is required for retrieving data from an NIS data base. Each machine on the network belongs to a default domain set at boot time in the system start-up script, such as /etc/rc2.d/S31rpc, with the domainname(1) command. A domain name must be set on all machines, both servers and clients. Further, a single name should be used on all machines on a network.
In the network information service environment, only a few machines have a set of NIS data bases. The NIS service makes the data base set available over the network. An NIS client machine runs NIS processes and requests data from data bases on other machines. Two kinds of machines have data bases: an NIS slave server and an NIS master server. The master server updates the data bases of the slave servers. Changes should be made only to data bases on the NIS master server. The changes propagate from the master server to the NIS slave servers. If NIS data bases are created or changed on slave server machines instead of master server machines, the NIS update algorithm is broken. All data base creation and modification should be done on the master server machine.
A server can be a master with regard to one map and a slave with regard to another. Random map assignment to server machines can cause a great deal of confusion. Administrators are strongly urged to make a single server the master for all the maps created by ypinit(1M) within a single domain. This document assumes that one server is the master for all maps in the data base.
| Home |
|---|
The network information service can serve any number of data bases. Typically, these include some files that were found in /etc; for example, programs used to read the /etc/hosts file to find an Internet address. When a new machine is added to the network, a new entry has to be added to every machine's /etc/hosts file. With the network information service, programs that need to look at the /etc/hosts file do a remote procedure call (RPC) to the servers to get the information.
Most of the information describing the structure of the NIS system and the commands available for that system is contained in manual pages and is not repeated here. For quick reference, the manual pages and an brief description of their contents are given below.
ypinit(1M) does all such construction automatically. It also constructs initial versions of maps required by the system but not built from files in /etc; an example is the map "ypservers." This tool should be used to set up the master NIS server and the slave NIS servers for the first time. It should not be used as a general administrative tool for running systems.
| Home |
|---|
Installation and administration of NIS are covered in this section.
The NIS daemons are executed in /etc/rc2.d/S31rpc. The following are the NIS descriptions. The variables YP_DOMAIN, YPSERV, YPBIND and YPPASSWDD are defined in /etc/default/rccustom. These variables are "OFF" at release.
if [ "$YP_DOMAIN" != "OFF" ]
then
domainname $YP_DOMAIN >/dev/console 2>&1
fi
if [ "$YPSERV" = "ON" ]
then
# enable if you want to be NIS server.
if [ -f /usr/lib/netsvc/yp/ypserv -a -d /var/yp/`domainname` ]; then
echo " ypserv:\c" >/dev/console
/usr/lib/netsvc/yp/ypserv >/dev/console 2>&1
fi
fi
if [ "$YPBIND" = "ON" ]
then
# enable if you want to be NIS Client & Server.
echo " ypbind:\c" >/dev/console
/usr/lib/netsvc/yp/ypbind >/dev/console 2>&1
fi
if [ "$YPPASSWDD" = "ON" ]
then
# enable if you are NIS server, and master of passwd maps
echo " yppasswdd:\c" >/dev/console
/usr/lib/netsvc/yp/yppasswdd /etc/passwd /etc/shadow -m passwd \
>/dev/console 2>&1
fi
| Home |
|---|
A master server is created from superuser as follows:
For security, access to the master NIS system can be restricted to a smaller set of users than that defined by the complete /etc/passwd and /etc/shadow. The complete file must be copied somewhere other than /etc/passwd and /etc/shadow, and the unauthorized users must be deleted from the remaining /etc/passwd. For system security, do not include this smaller file in the NIS escape entry discussed in the next section.
To provide network information service, /usr/lib/netsvc/yp/ypserv should be invoked. It starts up automatically from the system start-up script on subsequent reboots.
If you execute "ypinit -c", it is possible to establish the binding to the server on the specified host. Otherwise, ypbind sends a broadcast message and establishes the binding to the first server to respond.
| Home |
|---|
When adding clients to NIS, it is recommended that all nodes in the network have access to the updated versions of the NIS files, rather than the potentially out-of-date local files. That policy is acknowledged by running a ypbind process on the client node (including nodes that might be running NIS servers) and by abbreviating or eliminating files that normally implement the data base. The files in question are /etc/passwd, /etc/shadow, /etc/hosts, etc/group, and others. The treatment of each file is discussed in this section. The NIS file in respect to passwd is formed from /etc/passwd and /etc/shadow.
/etc/hosts must contain entries for the local host's name and the local loopback name. These are accessed at boot time when the NIS service is not yet available. After the system is running, and after the ypbind process is up, the /etc/hosts file is not accessed at all. The /etc/hosts can be controlled by hosts.conf(4). An example of the hosts file for NIS client zippy is:
127.0.0.1 localhost
192.9.1.87 zippy # John Q. Random
/etc/passwd must contain entries for root, the primary users of the machine, and an escape entry to force the use of the NIS service. Several additional entries are recommended:
The following is a sample NIS client's /etc/passwd file:
root:x:0:10:God:/:/bin/csh
jrandom:x:1429:10:J Random:/usr2/jrandom:/bin/csh
operator:x:333:20:sys op:/usr2/operator:/bin/csh
daemon:x:1:1::/:
sync:x:1:1::/:/bin/sync
+:x:0:0:::
The following is a sample NIS client's /etc/shadow file:
root:wAmOY41Enf6wc:7690::::::
jrandom:uHP1gQ2VyZxv9:6445::::::
operator:UqpqEPm4cvtU1:7445::::::
daemon:Nppqep3q100Af:8917::::::
sync::7590::::::
+::::::::
The last line signals the library routines to use the NIS service rather than give up the search. Entries in /etc/passwd mask analogous entries in the NIS maps. Earlier entries in the file mask later ones with the same user name or user id. The order of the entries for daemon and for sync (which have the same uid) must be noted and duplicated in user files. /etc/group may be reduced to a single line:
+:::
This forces all translation of group names and group ids to be made via the NIS service. This is the recommended procedure.
The six ":" must exist in passwd entry, the eight ":" must exist in shadow entry, and the three ":" must exist in group entry.
| Home |
|---|
The network must be working to set up a slave NIS server.
To create a new slave server, the superuser should cd to /var/yp. From there, ypinit(1M) with the -s switch should be run, and a host already set up as an NIS server should be named as the master. Ideally, the named host is the master server, but it can be any host that has its NIS data base set up. The host must be reachable. The default domain name on the machine intended to be the NIS slave server must be set up, and must be set to the same domain name as the default domain name on the machine named as the master.
After running ypinit, copies should be made of /etc/passwd, /etc/shadow, /etc/hosts, /etc/group, and others. For instance, on a machine named ypslave:
To ensure that processes on the slave server actually makes use of the NIS services, rather than the local ASCII files, the original files should be edited in accordance with the above section on altering the client's data base. This ensures that the NIS slave server is also an NIS client. Backup copies of the edited files should be made. For instance:
After the NIS data base is set up by ypinit, the user must enter /usr/lib/netsvc/yp/ypserv to start NIS services. On subsequent reboots, it starts automatically from /etc/rc2.d/S31rpc.
If you execute "ypinit -c", it is possible to establish the binding to the server on the specified host. Otherwise, ypbind sends a broadcast message and establishes the binding to the first server to respond.
To set up an NIS client, the local files should be edited as described earlier. If /usr/lib/netsvc/yp/ypbind is not running already, it should be started. With the ASCII data bases of /etc abbreviated and /usr/lib/netsvc/yp/ypbind running, the processes on the machine are clients of the NIS services. An NIS server must be available; many processes hang if no NIS server is available while ypbind is running. The possible alterations to the client's /etc data base (discussed above in the section on altering the client) should be noted. Because some files may not exist or may be specially altered, the ways in which the ASCII data bases are used are not always obvious.
The escape conventions used within those files to force inclusion and exclusion of data from the NIS data bases are found in the following manual pages: passwd(4), shadow(4), hosts(4) and group(4). In particular, note that changing passwords in /etc/passwd (by editing the file, or by running passwd(1)) affect only the local client's environment. The NIS password data base should be changed by running yppasswd(1).
If you execute "ypinit -c", it is possible to establish the binding to the server on the specified host. Otherwise, ypbind sends a broadcast message and establishes the binding to the first server to respond.
| Home |
|---|
Data bases served by the NIS must be changed on the master server. The data bases expected to change most frequently, such as /etc/group, may be changed by first editing the ASCII file and then running the command make(1) on /var/yp/Makefile.
Data bases that rarely change, or data bases for which no ASCII form exists (for example, data bases that did not exist before the NIS) can be modified manually. makedbm(1M) with the -u switch is used to disassemble them into a form that can be modified using standard tools (such as awk, sed, or vi). A new version must be built with makedbm(1M). This can be done manually in two ways:
To create a nonstandard NIS map, called mymap, note that the map consists of key-value pairs in which the keys are strings such as al, bl, cl, etc. and the values are ar, br, cr, etc.
Two procedures can be used when creating new maps.
To include another 2-tuple, (dl,dr) to the map, the modifications can be made by first editing the ASCII file. Modifications made to the map, rather than in the ASCII file, are lost. The modification should be made as follows:
When there is no original ASCII file, the NIS map can be created from the keyboard as follows. In the following example, the system name is ypmaster, and the default domain is home_domain:
To modify the map, makedbm can be used to create a temporary ASCII intermediate file that can be edited using standard tools. For example:
The file mymap.temp can be edited to contain the correct information. A new version of the data base is created by the commands
The preceding paragraphs explain how to use some tools, but almost everything can be done automatically by ypinit(1M) and /var/yp/Makefile, unless nonstandard maps have been added to the data base or the set of NIS servers has been changed after the system is running. Whether the Makefile in /var/yp or some other procedure is used, the goal is the same: a new pair of dbm files must end up in the domain directory on the master NIS server.
| Home |
|---|
Propagating a map means moving it from place to place; in general, moving it from the master NIS server to a slave NIS server. Initially, the map is moved by ypinit(1M) as described above. After a slave NIS server has been initialized, updated maps are transferred from the master server by ypxfr(1M). ypxfr may be run in three different ways: periodically by cron(1M); by ypserv(1M), and interactively by a user.
Maps have differing rates of change; for instance, protocols.byname may not change for long periods of time, but passwd.byname may change several times a day in a large organization. crontab(1) entries can be set up to periodically run ypxfr at a rate appropriate for any map in an NIS data base. ypxfr contacts the master server and transfers the map only if the master copy is more recent than the local copy.
To avoid a crontab entry for each map, several maps with approximately the same change characteristics can be grouped in a shell script, and the shell script can be run from a single crontab script file. Suggested groupings, mnemonically named, can be found in /var/yp: ypxfr 1perhour, ypxfr 1perday, and ypxfr 2perday. If the rate of change is inappropriate for a particular environment, these shell scripts can be easily modified or replaced.
The same shell scripts should be run from each NIS slave server in the domain. The time of execution from one server to another should be altered to prevent the checking from bogging down the master. To transfer the map from a particular server, rather than master, specify the ypxfr's -h option within the shell script. Finally, maps having unique change characteristics can be checked and transferred by explicit invocations of ypxfr within crontab.
ypxfr is also invoked by ypserv when responding to a Transfer Map request. Such a request is made as an RPC call from yppush(1M). yppush is run on the master NIS server. It enumerates the NIS map ypserver to generate a list of NIS servers in the domain. To each of the named NIS servers, it sends a Transfer Map request. ypserv spawns a copy of ypxfr, invoking it with the -C flag, and passes it the information needed to identify the map and to call back the initiating yppush process with a summary status.
In the cases mentioned, ypxfr transfer attempts and results are captured in a log file. When /var/yp/ypxfr.log exists, results are appended to it. No attempt to limit the log file is made. The administrator is responsible for log file limits. The log file is removed to turn off logging.
ypxfr can also be run as a command. This is done only in isolated situations, such as setting up a temporary NIS server to create a test environment, or when quickly updating an NIS server that is out of service.
| Home |
|---|
Making a new NIS map entails getting copies of the map's dbm files into the domain directory on each of the NIS servers in the domain. The actual mechanism was described previously. This section only describes the work required to get the proper mechanisms in place so that the propagation works correctly.
After deciding which NIS server is the master of the map, /var/yp/Makefile should be modified on the master server so that the map can be conveniently rebuilt. Typically, a readable ASCII file is filtered through awk, sed, and/or grep to make it suitable for input to makedbm(1M). The existing Makefile may be consulted as a source for programming examples. Use of the mechanisms already in place in /var/yp/Makefile is recommended when deciding how to create dependencies that make(1) recognizes. Specifically, the use of .time files allows users to see when the Makefile was last run for the map.
Support by the NIS slave servers to propagate new maps consists of appropriate entries either in /usr/lib/crontab or in one of the ypxfr shell scripts. To get an initial copy of the map, ypxfr can be run mechanically on each slave server. The map must be globally available before clients can gain access. When the map is not available to all NIS servers, client programs operate erratically.
To add a new NIS slave server, some maps on the master NIS server must be modified. If the new server is a host that has not been an NIS server before, the host's name must be added to the map ypservers in the default domain. The procedure for adding a server named ypslave to domain home_domain follows:
Some commands are displayed on two lines, but can be entered as one command, even if the line wraps on the screen. The return and newline may be escaped with a backslash, as shown.
The host address is registered in hosts; otherwise, /etc/hosts is edited and make is executed. The command is as follows:
The new slave NIS server's data bases should be set up by copying the data bases from NIS master server ypmaster. Following a remote login to the new NIS slave, ypinit(1M) must be used as follows:
The steps described previously must be completed to add a new server.
| Home |
|---|
To change a map's master, the map at the new master must be built. The existing NIS master's name is a key-value pair in the existing map. It does not suffice to use an existing copy at the new master or to send a copy there with ypxfr. The key must be reassociated with the new master's name. If the map has an ASCII source file, it should be in its current version at the new master. The NIS map (example.map) must be remade locally with the sequence:
/var/yp/Makefile must be properly configured for this to work. When the old master remains an NIS server, the /var/yp/Makefile must be edited so that example.map is not made there. This is done by commenting out the section of oldmaster:/var/yp/Makefile that made example.map.
If the map only exists as a dbm data base, it can be remade on the new master by disassembling an existing copy from any NIS server and rerunning the disassembled version. For example:
After making the map on the new master, a new copy of the map must be sent to the other (slave) NIS servers. However, yppush cannot be used because it causes the other slaves to attempt new copies from the old master, rather than the new one.
A typical solution is to become superuser on the old master server and type:
This places a copy on the old master and lets yppush be run. The remaining slave servers still recognize the old master as the current master and attempt to get the current version of the map from the old master. This accesses the new map that names the new master as the current master.
When this fails, an alternative must be used. On each NIS server, the superuser must execute the command sequence shown above. This is the worst-case scenario.
| Home |
|---|
This section addresses two types of NIS problems: those encountered on an NIS client, and those seen on an NIS server.
The most common problem at an NIS client node is for a command to hang and generate console messages:
Occasionally, a command sequence hangs even though the system appears to be working properly and new commands can be run.
The preceding message indicates that ypbind on the local node cannot communicate with ypserv in the domain wigwam. This often happens when machines running ypserv crash. This can also happen when the net or NIS server node is overloaded and ypserv cannot get a response to the local node's ypbind within the time-out period. Under these circumstances, all the other NIS client nodes on the network show the same or similar problems. The condition is usually temporary. The messages stop when the NIS server reboots and ypserv returns or when the load on the NIS server nodes or the Ethernet decreases.
The situation does not always improve, as described next.
The NIS client has not set, or has incorrectly set, domainname on the machine. Clients must use a domain name that the NIS servers recognize. domainname(1) must be used to see the client domain name that must be compared with the domain name set on the NIS servers. The domain name must be set in /etc/rc2.d/S31rpc. When /etc/rc2.d/S31rpc fails to set or sets the domain name improperly, take the following corrective actions:
When the domain name is correct, the local network must be checked to ensure that it has at least one NIS server machine. Users can only bind to a ypserv process on the local network, not on another accessible network. At least one NIS server for each machine's domain must be running on the local network. Two or more NIS servers improve availability and response characteristics for NIS services.
If the local network has an NIS server, it should be checked to ensure operation. Other nodes on the local network must be checked. If several client nodes have problems simultaneously, the server must be checked. The ypwhich command must be tested on a client node that is running. When ypwhich does not respond, terminate it. On the NIS server machine, enter the following:
to discover ypserv and ypbind processes. If the server's ypbind daemon is not operating, start it by entering:
When a ypserv process is running, a ypwhich must be executed on the NIS server machine. When ypwhich returns no answer, ypserv probably stalled and must be restarted. The superuser must terminate (kill -9) the existing ypserv process and start /usr/lib/netsvc/yp/ypserv:
If ps shows no ypserv process running, one must be started.
| Home |
|---|
When NIS services are unavailable on only one node, several different symptoms might be displayed, including:
For example, messages like the following might be displayed:
mymachine$ ypcat myfile
ypcat: can't bind to nis server for domain <wigwam> .
Reason: can't communicate with ypbind.
mymachine$ /usr/sbin/yppoll myfile
Sorry, I can't make use of the network information service. I give up.
In such cases, run the following directory containing files owned by many users, including users not in the local node's /etc/passwd file.
When ls -l indicates that file owners are in the local machine's /etc/passwd file as numbers rather than names, it is a symptom that NIS service is not operating.
These symptoms usually indicate that the ypbind process is not running. ps -ef can be used to check for the ypbind process. When not found, enter the following to start the process:
| Home |
|---|
If ypbind crashes each time it is started, there are problems in other parts of the system. Check the portmap daemon by typing:
If it is not operating, reboot the node. When portmap does not stay up or operates erratically, the problem is probably basic, and the state of the network must be checked.
Communication with portmap is possible from a local node that is operating properly. From the local node, enter the following:
If portmap is functioning correctly, the output is:
Program vers proto port
100005 1 udp 32770 mountd
100003 2 udp 2049 nfs
100007 2 tcp 32775 ypbind
100007 2 udp 32776 ypbind
100007 1 tcp 32775 ypbind
100007 1 udp 32776 ypbind
Port numbers are unique to each node. The four entries that represent the ypbind process are:
100007 2 tcp port_#
100007 2 udp port_#
100007 1 tcp port_#
100007 1 udp port_#
When these entries are missing, ypbind is unable to register its services. The node must be rebooted. When the entries are there and they change with each start attempt (/usr/lib/netsvc/yp/ypbind), the system must be rebooted even if portmap is operating.
When ypwhich is used several times from a client node, the system response varies. The NIS server changes, which is normal. The binding of NIS client to NIS server changes over time on a busy network or when NIS servers are busy. Whenever possible, the system stabilizes when all clients gain acceptable response times from the NIS servers. When a client machine receives NIS service, where the service originates is not a consideration. Often an NIS server node gets its own NIS services from an NIS server on the network.
NIS operates by propagating maps among servers. Different versions of a map can be found at servers on the network. This version skew is normal when transient.
Normal updating is prevented when an NIS server or a gateway node between NIS servers is offline during a map transfer attempt. When all NIS servers and gateways are running, ypxfr succeeds.
When a particular slave server has problems updating, ypxfr must be run interactively on that server. If ypxfr fails, a reason is issued that helps in isolating and correcting the problem. When ypxfr fails intermittently, a log file must be created to enable message logging. The following program saves all output from ypxfr.
The output resembles the output generated when ypxfr is run interactively, but each line in the log file is time stamped. The time stamp shows when ypxfr started. When copies of ypxfr run simultaneously but for different lengths of time, they can write their summary status line to the log files in a different order from when they were invoked. Any pattern of intermittent failure shows in the log. When the problem is resolved, logging must be turned off by removing the log file; otherwise, the log file builds without limit.
On the problem NIS slave server, the /usr/lib/crontab file and the ypxfr shell scripts that it invokes must be inspected. Typing mistakes in these files create propagation problems, as does failure to refer to a shell script within crontab. Failing to refer to a map within any shell script also causes propagation problems.A check must be done to ensure the NIS slave server is in the map ypservers within the domain. If not, the slave functions properly as a server but is not notified by yppush when a new copy of a map exists.
| Home |
|---|
When ypserv crashes and does not operate with repeated activations, the method for debugging is identical to that described for ypbind crashes. The portmap daemon must be checked:
When not found, the server must be rebooted. When in place, type the following:
Output similar to the following is generated.
program version protocol port
100005 1 udp 32770 mountd
100003 2 udp 2049 nfs
100004 2 tcp 32777 ypserv
100004 2 udp 32779 ypserv
100004 1 tcp 32777 ypserv
100004 1 udp 32779 ypserv
100007 2 tcp 32775 ypbind
100007 2 udp 32776 ypbind
100007 1 tcp 32775 ypbind
100007 1 udp 32776 ypbind
The four entries representing the ypserv process are:
100004 2 tcp port_#
100004 2 udp port_#
100004 1 tcp port_#
100004 1 udp port_#
When entries are missing, ypserv is unable to register its services. The node must be rebooted. When the entries are in place and they change on restart attempts (/usr/lib/netsvc/yp/ypserv), the node must be rebooted.
This section describes the policies set by the C library routines when they access the following files on a system running the Network Information Service.
| Home |
|---|
A site can add data base files of its own. The network information service is divided into local and global file types. A local file is searched first on the local node, then in the network information service. A global file is searched only in the network information service. /etc/passwd, /etc/shadow, and /etc/group are the local files in the network information service data base. The other network information service files are global. The /etc/hosts can be controlled by hosts.conf(4)
For example, a program calling /etc/passwd (a local file) first looks in the password file on the local node. The network information service password file is only consulted when the local node's password file contains plus (+) entries. The /etc/passwd file is local to provide local control of passwords. The other local files are /etc/shadow and /etc/group.
The remaining network information service file (networks etc.) is a global file. The information in this file is network-wide data and is accessed only from the network information service. When booting, each machine needs an entry in /etc/networks etc. When network information service is operating, global files are only checked in the network information service; a file on a local machine is not searched.
The library function that handles /etc/ethers file does not support network information services. The sendmail refers to network information service, if /usr/lib/aliases is not found key.
An /etc/passwd file, /etc/shadow file, and /etc/group file can also have plus (+) entries. A line in an /etc/passwd file such as
pulls in an entry for nb from the network information service that gets the uid and gid from the network information service, and the gecos, home directory, and default shell from the plus (+) entry. An /etc/passwd entry such as
gets all information from the network information service.
The following two examples differ.
nb::1189:10:Napoleon Bonaparte:/usr2/nb:/bin/sh
In the first example, the password field is obtained from the network information service; in the second, the user nb has no password. If there is no entry for nb in the network information service, the effect of the first example is as if no entry for nb is present.
The six ":" must exist in passwd entry and the eight ":" must exist in shadow entry and three ":" must exist in group entry.
| Home |
|---|
When a password is changed with the passwd(1) command, the entry given in the local /etc/passwd file is changed. When the password is not given explicitly but is pulled from the network information service with a + entry, the passwd command prints the following error message:
To change a password in the network information service, use the yppasswd(1) command. To enable this service, the system administrator must start up the daemon yppasswdd(1M) server on the node serving as the master of the network information service password file.
More security information is provided on the following manual pages: yppasswd(1), export(4), passwd(4), hosts.conf(4), group(4), netgroup(4), and yppasswdd(1M).
When the Network Information Service is not needed, the user can bypass it.
/etc/default/rccustom is the file that defines whether NIS daemons are activated or not. The shell procedures that start network functions read this file, which determines if NIS daemons are activated by the variables defined in /etc/default/rccustom. When the variables YP_DOMAIN, YPSERV, YPBIND, and YPPASSWDD are "OFF", NIS is not activated.
Adding a user involves editing the password file and creating a home directory on the new user's node as described in the following section.
With a new user, a password file entry must be added to every node on the local network. This is done from a superuser account, starting on the master NIS server node. The master NIS server must edit to the merged passwd. The merged passwd is made from both the /var/passwd and /etc/shadow. The merged_passwd is created by /var/yp/Makefile. If the user doesn't use yppasswdd(1M), then the user can edit /etc/passwd and /etc/shadow. If you specify both passwd and shadow for yppasswdd(1M), edit the specified passwd and shadow. Later, the password and shadow file entry for the user is copied to the /etc/passwd and /etc/shadow file on the new client's partition. Without an entry in this file, the person administering the new client machine cannot log in should the network information service fail.
| Home |
|---|
On the master NIS server, a new line must be added to the merged passwd file. /etc/passwd and /etc/shadow is a readable ASCII file with a one-line entry for each valid user on the system. Each entry is separated into fields by colons (:). There are seven fields on each line and some fields can be blank by placing two colons back-to-back. Certain characters in the merged passwd file must be avoided. These include: single and double quotes (` "), backslashes (\), and parentheses (( )). passwd(4) and shadow(4) gives more information about the file format.
With the new user name of NEC and the account name pubs, a line similar to that shown below must be added to the merged passwd file:
The second field, blank in the example, normally contains an encrypted version of the user's password. When the field is blank, anyone can log in by typing the user name; no password is required. A password cannot be created by making an entry in the /etc/shadow file. The passwd(1) command must be used by someone logged in as the user or as superuser. Since anyone can log in when a user has no password, it is better to provide a password for the new user allowing them to log in and change the password. yppasswd(1) is used to change passwords in the NIS data base.
When pubs has a password, the entry for NEC in the merged passwd file resembles the following:
Following are field descriptions for the merged password file:
When the password file is updated and a password created for the new user, the network information service data base must be updated by running /var/yp/Makefile for /etc/passwd:
| Home |
|---|
After adding a new entry to the password file, a home directory must be created for the new user. The home directory is the directory given in the sixth field of the password file entry. From /usr2, a directory can be made for the new user. Ownership must be changed to the user's login name, and group must be changed to the user's group. For example:
When the NIS data bases for the password file are not updated on the node's network information service server, the following error message is displayed when chown is tried:
In this case, the following commands can be used:
The user's ID number from the password file entry is implemented instead of the login name to change the ownership of the home directory.
The login point for a new user can be specified in several ways. For example, specify a copy of the file .profile if the Bourne shell is used. See the sh(1) for information on .profile.
The new user as a member of a group on the site must be added to /etc/group as necessary. See group(4). The changes must be made to the /etc/group file on the master NIS server.
Following is a restriction on the Network Information Service.
| Home |
|---|
| Contents | Previous Chapter | Next Chapter | Index |