This chapter presents background information on NIS, suggests guidelines for planning an NIS configuration, and explains configuration and administration procedures. Novice and experienced network administrators alike should read the entire chapter; although you may be familiar with NIS functionality, the section ``How NIS works'' includes details on features unique to the SCO implementation.
The term ``Network Information Service'' now refers to the service formerly known as Sun ``Yellow Pages'' or ``YP.'' The functionality remains the same; only the name has changed. Nonetheless, many NIS utilities retain the ``yp-'' prefix, for example, ypmake and ypserv.
See also:
When NIS is initialized on the master server, information from these files is compiled into a series of databases called maps. The maps are then propagated to other servers (slave and copy-only servers) on the network, where they are translated back into ASCII files. When it is necessary to update information in these files, the ASCII files are edited on the master server and the maps are modified and repropagated using NIS commands.
In the SCO implementation of NIS, master and slave
servers perform all lookups of NIS-managed information
locally on servers.
Copy-only servers and NIS clients use remote servers.
SCO clients can request NIS maps from servers
to satisfy lookup requests for password and group information.
This is only supported for commands that have
been built using the libsocket library.
All SCO-supplied commands, such as
ls(C),
can read NIS password and group maps when run on a
client.
When a new map is received on a slave or copy-only server, it is
converted to the corresponding ASCII file(s) that is
then available locally to requesting processes.
SCO NIS servers
can also satisfy lookup requests from clients running
other than SCO systems.
See also:
While an NIS domain may consist of a list of hosts identical to those contained in an Internet, MMDF, or sendmail domain, an NIS domain is distinct from these others in purpose.
All NIS servers and clients within an NIS domain
store a common domain name.
This name is established during NIS initialization of the server
or client.
The domain name can also be set or displayed using the
domainname(NC)
command.
This domain name is used for authentication within NIS
and is used to name the directory within which each host
stores the NIS maps for that domain.
For example, maps for the literature domain are in the
/etc/yp/literature directory.
NIS maps
The configuration information managed with NIS is typically
stored in ASCII files when NIS is not in use.
NIS master servers convert the information into NIS
maps for storage and transfer by NIS programs.
Each NIS map is an ndbm database. An ndbm database consists of a pair of files that are created by calls to the ndbm(NS) library package. One file contains a directory (that is, a bitmap of indices accessed by a hash table); the other file contains data. Because of the non-ASCII file structure imposed by ndbm, you must use NIS tools (such as ypxfr and yppush) to transfer maps from one machine to another.
The use of maps to manage data permits NIS to add a timestamp and the identity of the source (that is, the name of the host serving as the master). A host uses the timestamp to determine if the contents of the map it is receiving are newer than data it already has. The identity of the master allows a nonmaster server to request an immediate update.
NIS maps are created when an NIS master server is initialized
or as needed using NIS commands.
When an NIS master server
is being initialized, the initialization process creates the
maps listed in the file /etc/yp/YP_MAP_X_LATE.
These maps are propagated to nonmaster servers when these
servers enter multiuser mode for the first time after
being initialized as NIS servers.
Additional maps can be created on the master server at any
time using the procedures described in
``Creating NIS maps''.
Understanding YP_MAP_X_LATE
The /etc/yp/YP_MAP_X_LATE file contains
a complete listing of active NIS maps.
The most common entries are hosts, group,
passwd, and ypservers, although all standard
and nonstandard maps (that is, created by you) must be listed
here if you wish NIS to serve them.
The format of this file is described on the
ypmapxlate(NF)
manual page.
The maps listed in YP_MAP_X_LATE get created when NIS is initialized by executing ypinit(NADM) or mkdev nis. You must list all the maps you need in YP_MAP_X_LATE before your system is initialized. If you add new maps after initialization, they need not be listed in YP_MAP_X_LATE to be made functional; however, because NIS consults YP_MAP_X_LATE when propagating maps, new maps must be listed here for them to be propagated using yppush(NADM), ypxfr(NADM), or other NIS utilities. For this reason, we recommend that you keep YP_MAP_X_LATE up-to-date on your master server.
Although slave and copy-only servers do not propagate maps and hence do not consult YP_MAP_X_LATE, we recommend that you keep this file current on nonmaster servers to simplify NIS administration.
YP_MAP_X_LATE also contains NIS
aliases for NIS maps;
aliases may be used by all NIS servers.
If you have a system on your network that cannot handle long
map names (that is, longer than 14 characters),
you can add an alias to YP_MAP_X_LATE,
showing a shortened alias for the map. If you have additional aliases
to include in YP_MAP_X_LATE, add them before
configuring NIS.
Propagating an NIS map
Propagating a map means moving it from place to place,
generally from the NIS master server to an NIS
slave or copy-only server. Initially, the map is moved at system startup.
Maps are not propagated to clients because clients request map information
from servers rather than storing the maps themselves.
After you initialize an NIS nonmaster server, ypxfr(NADM) transfers updated maps from the master server. The ypxfr command can be run in the following ways:
You can capture ypxfr's transfer attempts and results in the logfile /usr/adm/nislog. If this file exists, results are appended to it. You are responsible for limiting the size of this file. To turn off logging, remove or rename this file. Refer to the ypxfr(NADM) manual page for more information about the logfile.
Methods for transferring updated maps are described in the
following sections.
Using cron to propagate maps
Maps have differing rates of change; for instance, protocols.byname
might not change for a long time, but passwd.byname
might change several times a day in a large organization.
You can set up root's
crontab(C)
entries to run ypxfr
periodically at a rate appropriate for any map in an NIS database.
The ypxfr program contacts the master server
and transfers the map only if the master's
copy is more recent than the local copy.
To avoid a crontab entry for each map, group several maps into a shell script that can be run from a single crontab script file. Each shell script should contain maps with approximately the same characteristics. The following suggested groupings, mnemonically named, can be found in /etc/yp: ypxfr1phr (hourly), ypxfr1pdy (once daily), and ypxfr2pdy (twice daily). If the rates of change are inappropriate for a particular environment, you can easily modify or replace these shell scripts. The following crontab entries will call the scripts:
0 * * * * /etc/yp/ypxfr1phr 0 0 * * * /etc/yp/ypxfr1pdy 0 0,12 * * * /etc/yp/ypxfr2pdy
Run the same shell scripts at each NIS slave and copy-only server in the domain; do not run them from the master server. Alter the time of execution from one server to another to prevent the checking from impeding the master server. To transfer the map from a particular server, rather than the master server, use the -h option to ypxfr from within the shell script. You can check and transfer maps having unique change characteristics by explicit invocations of ypxfr within crontab.
See also:
See also:
The master server updates the databases of slave and copy-only servers.
Copy-only servers, slave servers, and clients differ in the following ways:
Database changes in an NIS domain are propagated from the master
server to other servers.
If you create or change NIS databases on slave or copy-only
servers instead of on the master server,
all modifications you make are temporary
and are overwritten when the master server updates them.
Therefore, make all database creations and modifications
on the master server machine only.
NIS binding
The action of associating a server with a particular host is called
binding that host in the NIS domain.
Hosts must be
bound for NIS services to be provided.
Binding is accomplished at system startup when the ypbind
daemon broadcasts for a server to satisfy a process request.
The ypbind daemon remembers information that lets clients' processes on a single node communicate with the ypserv daemon, the NIS database lookup server. Requests are usually to transfer a map, display its contents, or to display information about the NIS domain. Its primary function is to look up information in its local database of NIS maps. Unless the host system crashes or the network administrator intervenes, bindings remain constant in an NIS domain.
NIS services are implemented by the following daemons:
yppasswdd must be run only on the master server.
See also:
NIS password information is maintained by the following files in the /etc directory:
Entries in passwd.local take precedence over entries in passwd.yp. That is, if the two files include a user with the same name, the information in passwd.local is incorporated into passwd and the corresponding information in passwd.yp (and the passwd map) is overridden.
On clients, you can use NIS maps to augment local password information in the /etc/passwd file. See ``Using NIS maps in the password file'' for more details.
Entries in group.local take precedence over entries in group.yp. That is, if the two files include a group with the same name, the information in group.local is incorporated into group and the corresponding information in group.yp (and the group map) is overridden.
On clients, you can use NIS maps to augment local group information in the /etc/group file. See ``Using NIS maps in the group file'' for more details.
You can manipulate NIS account files directly from the
command line or scripts using the
useradd(ADM),
userdel(ADM),
and
usermod(ADM)
commands.
About netgroups
The /etc/netgroup file
defines network-wide groups used for permission
checking when fielding requests for remote mounts, remote logins, and remote
shells. For remote mounts, the information in netgroup is
used to classify machines; for remote logins and remote
shells, it is used to classify users.
NIS clients can use netgroups to include the map
entries for the members of a netgroup in the password file,
/etc/passwd.
See
``Using NIS maps in the password file''
for more details.
Each line of the netgroup
file defines a group and has the format
groupname member_1 member_2
where member is either another group name or a triple (in the
following format, parenthesis included):
(hostname,username,domainname)
Any of these three fields can be empty, in which case it signifies a wildcard. Thus the entry
universal (,,)defines a group to which everyone belongs.
The domainname field must either be the local domain name or empty for the netgroup entry to be used. This field does not limit the netgroup or provide security. The domainname field refers to the domain in which the triple is valid, not the domain containing the trusted host.
A gateway machine should be listed under all possible host names by which it may be recognized:
wan (volga,,) (volga-cities,,)Field names that begin with something other than a letter, digit, or dash (such as `-') work in precisely the opposite way:
justmachines (amazon,-,sun) justpeople(-,babbage,sun)The machine amazon belongs to the group justmachines in the domain sun, but no users belong to it. Similarly, the user babbage belongs to the group justpeople in the domain sun, but no machines belong to it. The triple
(,,domain)allows all users and machines trusted access and has the same effect as the triple
(,,)To correctly restrict access to a specific set of members, use the hostname and username fields of the triple.
Network groups are contained in the Network Information Service
and are accessed through these files:
/etc/yp/domainname/netgroup.dir
/etc/yp/domainname/netgroup.pag
/etc/yp/domainname/netgrp.usr.dir
/etc/yp/domainname/netgrp.usr.pag
/etc/yp/domainname/netgrp.hst.dir
/etc/yp/domainname/netgrp.hst.pag
These files can be created from /etc/netgroup using
makedbm(NADM).
See also:
The fields have the same meaning as for ordinary passwd(F) file entries except that there are no entries for the user or group IDs. That is, the UID and GID from the NIS entry are always used; they cannot be defined locally. Entries in the password, comment, directory, or program field override the corresponding value obtained from the NIS server.
The following entry inserts the entire NIS password file:
+:Netgroup entries are added by specifying them as:
+@netgroup:
Any host information about a netgroup is ignored.
You can prevent users and members of netgroups from logging in by
starting their passwd entries with ``-'' instead
of ``+'':
-username:
-@netgroup:
The following example passwd file is used in conjunction with the shadow(F) file to include and exclude certain users and netgroups:
root:x:0:10:super user:/:/bin/sh fran:x:121:100:Fran Sisco:/u/fran/:/bin/ksh -renee: -@marketing: +diego:::::: +:::::/u/guest:/bin/rksh +@developers:This example, though simple, implies several things:
+:::::/u/guest:/bin/rksh that precedes the entry
defining their inclusion.
See also:
The fields have the same meaning as for ordinary group(F) file entries except that there are no entries for the group ID. The group ID from the NIS entry is always used. An entry in the password field is ignored as group passwords are not supported. If specified, a comma-separated list of users is added to the list obtained from the NIS server.
The following entry inserts the entire NIS group file:
+:::You can exclude groups by starting their group entries with ``-'' instead of ``+'':
The following example group file defines a group local, adds members to the group giant, and includes all NIS groups except transport:
local::100:fran,stan +giant:::bill,tina,alan,hetty -transport: +:::
See also:
See also:
Only copy-only NIS servers and clients can be initialized in Secure Mode settings on SCO systems. These servers may receive maps, but they cannot propagate them. In addition, if a copy-only server in Secure Mode receives a password or group map, it cannot translate these maps into /etc/passwd or /etc/group ASCII files.
Clients that include NIS maps in their /etc/passwd or /etc/group files circumvent TCB and are not C2 Secure.
Table 9-1, ``Security configurations for SCO NIS servers and clients'', lists the security configurations permitted for each type of SCO NIS server and client.
Table 9-1 Security configurations for SCO NIS servers and clients
------------------------------------------------------------------- SCO NIS server or client type Permitted security settings ------------------------------------------------------------------- master or Unsecure Mode only (Traditional or Low) slave copy-only or Secure Mode (High or Improved) or client Unsecure Mode (Traditional or Low)These security precautions help prevent unauthorized NIS password and group information from reaching SCO hosts. However, the same security precautions may not be available for client implementations running on systems other than SCO. Consult your documentation for NIS client implementations if you are concerned with security.
See also:
Special NIS password change
When you change a password using the
passwd(C)
command when NIS is not enabled on your system,
the entry given in the system password database
file is changed.
When NIS is enabled, you also use
passwd to change your password.
The passwd command is then a link to the
yppasswd(NC)
command.
(The original
/bin/passwd file is stored at /usr/lib/nisrt/bin/passwd
and a link to /bin/yppasswd is made.)
To enable NIS password service,
you must start up the server daemon,
yppasswdd(NADM),
on the machine serving as the master
for the NIS password file.
If the file /etc/ptmp exists, you will receive the following message when you try to change a password:
yppasswd: password file busy - try againThe file /etc/ptmp is a lock file that indicates a previous invocation of yppasswd still exists. This file can be removed to unlock the password file.
See the
yppasswd(NC)
manual page for a list of error codes.
NIS logfiles
The Account Manager,
yppasswdd(NADM),
yppasswd(NC),
ypxfrd(NADM),
and
ypxfr(NADM)
all use the file
/usr/adm/nislog as a logfile.
If the logfile /usr/adm/nislog exists when
ypxfr is executed, results are appended to this logfile.
If the same logfile exists when the daemon ypserv starts up,
log information will be written to this file when ypserv error
conditions arise.
The user is responsible for limiting the logfile.
To turn off logging, remove the logfile.
Enabling an NIS server
Many of the tasks associated with
ypinit(NADM)
can also be performed after initialization during routine
maintenance and troubleshooting.
Refer to:
See also:
For most NIS installations, a single domain is sufficient to satisfy users' needs. However, if your site has multiple networks, you must create separate domains for each network because NIS domains cannot cross network boundaries. A possible network division might be into accounting, marketing, and manufacturing domains.
In such an environment, it is recommended that there be one master and at least one slave server for each domain.
Two factors are important in selecting master and slave servers: uptime and synchronization. The master server should be a host that is stable and available for NIS requests. This suggests that a machine be dedicated as a master server and that there be at least one slave server for each master in a domain should the master become unavailable.
The master and slave servers should have CPUs of comparable power to those of the machines to which they will propagate maps. This is particularly important in heterogeneous environments where a number of NIS clients running on other operating systems may seek to bind with the most available server. Because it is essential that current map information be uniformly available across the network, availability and equivalent speed of servers ensure that the propagation of map information is synchronized.
In an NIS environment comprised of SCO machines exclusively, slave servers can be used as a backup to the master server and to improve the ability to service map update requests from copy-only servers. In a heterogeneous environment, slave servers should be added as needed to keep up with requests from clients running on other operating systems.
The physical structure of the network may influence the distribution of slave servers. For example, if you have a network that includes a bridge, you will probably want at least two slave servers on either side. This is because NIS requests are delayed when crossing bridges. The result is that a server on the same side of a bridge as the requesting host will satisfy a request sooner than one on the far side, even if the closer server is heavily loaded. Having two slave servers on the requesting side of the bridge removes a virtual reliance on one server that may be heavily loaded.
Although NIS is designed to administer password and group authorization files, such administration is incompatible with C2 security. SCO NIS maintains C2 security in an NIS environment by enforcing the following restrictions:
In a heterogeneous environment, SCO copy-only servers under C2 protection continue to refuse password and group maps from master or slave servers running on other operating systems. However, an SCO master or slave server (by definition in Unsecure Mode) may be able to propagate maps to C2-protected clients on other operating systems. Consult your client's documentation to address your security concerns. Refer also to ``NIS interaction with security modes''.
See also:
missouri.sco.com.
Usually, the network domain name and hostname
are set up by the system startup script.
Verify the following:
See also:
The file /etc/yp/YP_MAP_X_LATE supports a facility for mapping map names that are longer than operating system length limits into alias names; the maps are then allowed to reside on the system under the alias name but still be known to NIS programs by a universal map name. You must assign an NIS alias to a map if a map name exceeds the filename length limit allowed by your operating system (often 14 characters; however, DTFS, EAFS, and HTFS filesystems have a filename limit of 255 characters). For more information on aliasing map names see ypmapxlate(NF).
Verify that the files listed in /etc/yp/YP_MAP_X_LATE are complete and current on your master server. All files listed in /etc/yp/YP_MAP_X_LATE must be available to the master server.
See also:
NULL
by entering domainname at your prompt.
If the screen returns anything other than NULL,
enter domainname "".
ypinit and mkdev nis do not enter the appropriate
command in the NIS startup script unless your domain
name is set to NULL.
domainname(NC)
sets or displays the name of the current NIS domain.
See also:
/etc/yp
Initializing a master server
The following steps explain how to initialize a master NIS server:
You see messages as the system services stop.
Press <Enter> at the Safe to Power Off message.
Type <Ctrl>D to proceed with normal startup, (or give root password for system maintenance)
or
/etc/yp/ypinit
The functionality and the options for ypinit and mkdev nis are identical.
You must specify whether this host is to be a master, slave server, copy-only server or NIS client. Please enter the server type:[mscCq]
Enter m to indicate that the local host is to be the
NIS master server.
If you want to stop the initialization, enter q.
ypinit: ERROR: Invalid configuration.The security settings of this system are incompatible with the NIS configuration requested. Please refer to your Release and Installation Notes for further details. Initialization Aborted.
Refer to ``NIS interaction with security modes'' for security restrictions.
NIS has been initialized previously on this machine Please verify that you would like to re-initialize NIS Do you wish to re-initialize NIS? (y/n/q)Enter y to continue.
The local host's domain name hasn't been set. Please set it. Please enter the domain name or q to quit:Enter the NIS domain name; you need an NIS domain name to retrieve data from an NIS database.
You will be asked:
Is "domainname" correct? [y/n/q]Enter y if correct. If you enter n, you will be asked to reenter the domain name. If you enter q, NIS initialization aborts.
You see this prompt:
Installing the NIS database will require that you answer a few questions. Questions will all be asked at the beginning of the procedure.
Can we destroy the existing /etc/yp/<domainname> and its contents? [y/n/q: n]
If you see this message, enter y to continue, which tells NIS to rebuild the previous NIS database with current information.
If you enter the default n or q, NIS
initialization aborts, and you must
manually remove the old NIS databases.
NIS stores local logins in /etc/passwd.local, which currently doesn't exist on this machine. The /etc/passwd.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/passwd to /etc/passwd.local? [y/n/q: n]
If you enter the default n, you must manually create the /etc/passwd.local file, then start the initialization procedure again.
NIS stores local groups in /etc/group.local, which currently doesn't exist on this machine. The /etc/group.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/group to /etc/group.local? [y/n/q: n]
If you enter the default n, you must manually create the /etc/group.local file, then start the initialization procedure again.
The YP_MAP_X_LATE file contains the following: list of mapnamesIf the list is not correct, enter the default n. Edit YP_MAP_X_LATE to contain the correct entries, and start the initialization procedure again. Refer to the ypmapxlate(NF) manual page for more information.Is this correct? [y/n/q: n]
If the list is correct, enter y to continue.
The NIS network password file resides in /etc/passwd.yp on master servers only. Since this node is being set up as a master server, /etc/passwd.yp must be created.Enter y to continue.Is it okay to create /etc/passwd.yp? [y/n/q: n]
If you enter n, you must manually
create the /etc/passwd.yp file, then start the initialization
procedure again.
The NIS network password file resides in /etc/group.yp on master servers only. Since this node is being set up as a master server, /etc/group.yp must be created.Enter y to continue.Is it okay to copy /etc/group to /etc/group.yp? [y/n/q: n]
If you enter n, you must manually
create the /etc/group.yp file, then start the initialization
procedure again.
You must specify whether ypbind is to be run with the secure option (-s), the ypset option (-ypset), allowing anyone to change your binding, or the ypsetme option (-ypsetme) which only allows requests with host-name's IP address to change host-name's binding, or with no options. Please see ypserv(NADM) for more information 1) ypbind -s 2) ypbind -ypset 3) ypbind -ypsetme 4) ypbind Please enter your choice (1-4,q):Enter the response appropriate to your security concerns:
For further information, consult the ypserv(NADM) manual page, which includes information about ypbind. See also ypset(NADM).
At this point, we have to construct a list of the hosts that will be running NIS (NIS server hosts). The local host is in this list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a <Ctrl>D.Enter all of the master and slave server names, including all server machines running other operating systems. The machine name and the Internet Protocol (IP) domain name are acceptable host names; the NIS domain name is not. Press <Enter> after each host name. After entering the last host name, press <Ctrl>D to continue, and enter y to verify that the host names are correct. NIS then creates and updates the maps.
Should administration accounts such as "root" be distributed? [y/n/q: n]Enter n to prevent administration accounts from being distributed, unless there is strong reason to do so. See ``Administering NIS users and groups'' for more information.
When the initialization procedure is complete, you see a series of messages resembling the following display:
There will be no further questions. The remainder of the procedure should take 5 to 10 minutes.
The backup directory /usr/lib/nisrt already existsEnter y to continue; NIS then backs up system passwd files. If you enter n or q, NIS installation aborts.Do you wish to continue with the SCO NIS Runtime System Initialization?
You then see a series of messages similar to:
Backing up system passwd files . . .This display of updated maps should correspond to the maps listed in /etc/yp/YP_MAP_X_LATE.Building /etc/yp/domain_name/ypservers . . .
Running /etc/yp/ypmake . . .
<list of updated files>
host_name has been set up as a NIS master server without any errors.
Your master server is now initialized.
If there are running slave servers, run yppush now for any data bases that have been changed. If there are no running slaves, run ypinit on those hosts that are to be slave servers.See the reference manual pages for yppush(NADM) and ypinit(NADM) if you have questions about these procedures.
The first time an NIS slave server enters multiuser mode after NIS has been initialized on the slave server, its startup script calls ypxfr to transfer maps from the master server. Subsequent system startups do not transfer maps automatically.
You see messages as the system services stop.
Press <Enter> at the Safe to Power Off message.
Type <Ctrl>D to proceed with normal startup, (or give root password for system maintenance)
or
/etc/yp/ypinit
The functionality and the options for ypinit and mkdev nis are identical.
You must specify whether this host is to be a master, slave server, copy-only server or NIS client. Please enter the server type:[mscCq]
Enter s to indicate that you are setting up a slave server.
If you want to stop the initialization, enter q.
ypinit: ERROR: Invalid configuration.The security settings of this system are incompatible with the NIS configuration requested. Please refer to your Release and Installation Notes for further details. Initialization Aborted.
Refer to ``NIS interaction with security modes'' for security restrictions.
NIS has been initialized previously on this machine Please verify that you would like to re-initialize NIS Do you wish to re-initialize NIS? (y/n/q)Enter y to continue.
The local host's domain name hasn't been set. Please set it. Please enter the domain name or q to quit:Enter the NIS domain name; you need an NIS domain name to retrieve data from an NIS database.
You will be asked:
Is "domainname" correct? [y/n/q]Enter y if correct. If you enter n, you will be asked to reenter the domain name. If you enter q, NIS initialization aborts.
You must specify a host name to act as the NIS master during map transfer [q to quit]:Enter the name of a master server with an up-to-date and stable database.
You see this prompt:
Installing the NIS database will require that you answer a few questions. Questions will all be asked at the beginning of the procedure.
Can we destroy the existing /etc/yp/<domainname> and its contents? [y/n/q: n]If you see this message, enter y to continue, which tells NIS to rebuild the previous NIS database with current information.
If you enter the default n or q, NIS initialization aborts, and you must manually remove the old NIS databases.
NIS stores local logins in /etc/passwd.local, which currently doesn't exist on this machine. The /etc/passwd.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/passwd to /etc/passwd.local? [y/n/q: n]
If you enter the default n, you must
manually create the /etc/passwd.local file,
then start the initialization procedure again.
NIS stores local groups in /etc/group.local, which currently doesn't exist on this machine. The /etc/group.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/group to /etc/group.local? [y/n/q: n]
If you enter the default n, you must manually create the
/etc/group.local file,
then start the initialization procedure again.
The YP_MAP_X_LATE file contains the following: list of mapnamesIf the list is not correct, enter the default n. Edit YP_MAP_X_LATE to contain the correct entries, and start the initialization procedure again. Refer to the ypmapxlate(NF) manual page for more information.Is this correct? [y/n/q: n]
If the list is correct, enter y to continue.
You must specify whether ypbind is to be run with the secure option (-s), the ypset option (-ypset), allowing anyone to change your binding, or the ypsetme option (-ypsetme) which only allows requests with host-name's IP address to change host-name's binding, or with no options. Please see ypserv(NADM) for more information 1) ypbind -s 2) ypbind -ypset 3) ypbind -ypsetme 4) ypbind Please enter your choice (1-4,q):Enter the response appropriate to your security concerns.
There will be no further questions. The remainder of the procedure should take a few minutes to set up the NIS server.The NIS maps will be transferred from master_server when server_name goes to run level 2.
The backup directory /usr/lib/nisrt already existsEnter y to continue; NIS then backs up system passwd files. If you enter n or q, NIS installation aborts.Do you wish to continue with the SCO NIS Runtime System Initialization?
You then see:
Backing up system passwd files . . .Your slave server is now initialized.server_name's NIS data base has been set up without any errors.
The first time an NIS slave or copy-only server enters multiuser mode, its startup script calls ypxfr to transfer maps from the master server. Subsequent system startups do not transfer maps automatically.
You see messages as the system services stop.
Press <Enter> at the Safe to Power Off message.
Type <Ctrl>D to proceed with normal startup, (or give root password for system maintenance)
or
/etc/yp/ypinit
The functionality and the options for ypinit
and mkdev nis are identical.
You must specify whether this host is to be a master, slave server, copy-only server or NIS client. Please enter the server type:[mscCq]
Enter c to indicate that you are setting up a copy-only server.
If you want to stop the initialization, enter q.
Due to the restrictions of running NIS under the current security setting of this system, this server will accept, but not integrate sensitive maps received through NIS. Please refer to your Release and Installation Notes for further details.Hit return to continue.
NIS has been initialized previously on this machine Please verify that you would like to re-initialize NIS Do you wish to re-initialize NIS? (y/n/q)Enter y to continue.
The local host's domain name hasn't been set. Please set it. Please enter the domain name or q to quit:Enter the NIS domain name; you need an NIS domain name to retrieve data from an NIS database.
You will be asked:
Is "domainname" correct? [y/n/q]Enter y if correct. If you enter n, you will be asked to reenter the domain name. If you enter q, NIS initialization aborts.
You must specify a host name to act as the NIS master during map transfer [q to quit]:Enter the name of a master server with an up-to-date and stable database.
You see this prompt:
Installing the NIS database will require that you answer a few questions. Questions will all be asked at the beginning of the procedure.
Can we destroy the existing /etc/yp/<domainname> and its contents? [y/n/q: n]If you see this message, enter y to continue, which tells NIS to rebuild the previous NIS database with current information.
If you enter the default n or q, NIS
initialization aborts, and you must
manually remove the old NIS databases.
If the /etc/passwd.local file does not exist on the machine, you see the following message:
NIS stores local logins in /etc/passwd.local, which currently doesn't exist on this machine. The /etc/passwd.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/passwd to /etc/passwd.local? [y/n/q: n]
If you enter the default n, you must manually create the /etc/passwd.local file, then start the initialization procedure again.
If the /etc/group.local file does not exist on your machine, you see:
NIS stores local groups in /etc/group.local, which currently doesn't exist on this machine. The /etc/group.local file must be created before continuing.Enter y to continue. See ``About managing users'' for details on these files.Is it okay to copy /etc/group to /etc/group.local? [y/n/q: n]
If you enter the default n, you must manually create the /etc/group.local file, then start the initialization procedure again.
The YP_MAP_X_LATE file contains the following: list of mapnamesIf the list is not correct, enter the default n. Edit YP_MAP_X_LATE to contain the correct entries, and start the initialization procedure again. Refer to the ypmapxlate(NF) manual page for more information.Is this correct? [y/n/q: n]
If the list is correct, enter y to continue.
You must specify whether ypbind is to be run with the secure option (-s), the ypset option (-ypset), allowing anyone to change your binding, or the ypsetme option (-ypsetme) which only allows requests with host-name's IP address to change host-name's binding, or with no options. Please see ypserv(NADM) for more information 1) ypbind -s 2) ypbind -ypset 3) ypbind -ypsetme 4) ypbind Please enter your choice (1-4,q):Enter the response appropriate to your security concerns.
There will be no further questions. The remainder of the procedure should take a few minutes to set up the NIS server.The NIS maps will be transferred from master_server when server_name goes to run level 2.
The backup directory /usr/lib/nisrt already existsEnter y to continue; NIS then backs up system passwd files. If you enter n or q, NIS installation aborts.Do you wish to continue with the SCO NIS Runtime System Initialization?
You then see:
Backing up system passwd files . . .Your copy-only server is now initialized.server_name's NIS data base has been set up without any errors.
The first time an NIS slave or copy-only server enters multiuser mode, its startup script calls ypxfr to transfer maps from the master server. Subsequent system startups do not transfer maps automatically.
You see messages as the system services stop.
Press <Enter> at the Safe to Power Off message.
Type <Ctrl>D to proceed with normal startup, (or give root password for system maintenance)
or
/etc/yp/ypinit
The functionality and the options for ypinit and mkdev nis are identical.
You must specify whether this host is to be a master, slave server, copy-only server or NIS client. Please enter the server type:[mscCq]
Enter C to indicate that you are setting up an NIS client.
If you want to stop the initialization, enter q.
NIS has been initialized previously on this machine Please verify that you would like to re-initialize NIS Do you wish to re-initialize NIS? (y/n/q)Enter y to continue.
The local host's domain name hasn't been set. Please set it. Please enter the domain name or q to quit:Enter the NIS domain name; you need an NIS domain name to retrieve data from an NIS database.
You will be asked:
Is "domainname" correct? [y/n/q]Enter y if correct. If you enter n, you will be asked to reenter the domain name. If you enter q, NIS initialization aborts.
You must specify whether ypbind is to be run with the secure option (-s), the ypset option (-ypset), allowing anyone to change your binding, or the ypsetme option (-ypsetme) which only allows requests with host-name's IP address to change host-name's binding, or with no options. Please see ypserv(NADM) for more information 1) ypbind -s 2) ypbind -ypset 3) ypbind -ypsetme 4) ypbind Please enter your choice (1-4,q):Enter the response appropriate to your security concerns.
For further information, consult the
ypserv(NADM)
manual page, which includes information about ypbind.
See also
ypset(NADM).
server_name's NIS data base has been set up without any errors.Your NIS client is now initialized.
Reinitializing a server
If it becomes necessary to reinitialize a server, reexecute the
ypinit command on that server.
Situations under which it might be necessary to reinitialize a
server include a bad configuration wherein a slave or copy-only
server or a client was initialized before the master server.
See also:
You can also start NIS from the command line
by logging in as root and entering:
/etc/nis start
The first time you start a copy-only server, it will display messages similar to the following as it transfers maps from the NIS master:
Transferring proto.nam . . . map2ascii conversion for proto.nam map succeededSome map conversions, specifically for the passwd and group maps, will fail in Secure Mode.
To stop NIS on a machine, log in as root and enter:
/etc/nis stop
When you stop NIS on a server, clients bound to the server will hang if this was the only server serving the domain. NIS is shut down automatically when the system is taken to run level 0, 1, or 6.
See also:
See also:
See also:
To create an NIS map on the master server and to push this map to all the servers in an NIS domain, follow these steps:
ypmake mapname
yppush mapname
See also:
ypbind -ypsetexecuted on the local machine says that a ypset(NADM) command issued from any machine may change the binding on the local machine. This option poses serious security risks and should only be used for debugging the network from a remote machine.
See also:
ypbind -ypsetmeexecuted on the local machine says that a ypset(NADM) command may be used to set the binding of the local machine only if the ypset command is issued from the local machine.
See also:
domainname new_domainon each machine in that domain. Note that the new domain name is in effect only until the next machine boot.
To permanently change an NIS domain name, edit the file /etc/nis on each machine in the new domain and set the variable YPDOMAIN to the new domain name. The new domain takes effect when you reboot the system.
See also:
For example, if you need to remove from the network a machine that was an NIS server, you must remove the machine from NIS service before removing it from the network.
If the machine removed was a slave server, you would probably want to add a slave server to replace it.
Circumstances may also require removing from the network the machine serving as the NIS master server. In this case, you would need to change the NIS master server.
See also:
When SCO NIS is removed from a system, the /etc/passwd.local file is removed. The /etc/passwd file, which under NIS included both distributed and local accounts, becomes the authoritative password file. This means that distributed NIS accounts become regular user accounts when NIS is removed. If you want to restrict users with distributed NIS accounts from using the old server, you must remove their accounts before returning the old server to multiuser mode.
Follow these steps to remove a server:
The old master server must be running NIS to complete this procedure. This is because nonmaster servers consult their own copies of maps, which include the name of the old master server, when they receive a map transfer request originating from yppush on the master. New maps with the new master server listing must come from the old master server for the maps to be incorporated on slave and copy-only servers. Therefore, if the old master is not available when you change master servers, you must rebuild your entire NIS system from scratch.
The procedures described here assume that the new master is running SCO NIS. Other implementations of NIS configure servers in a different way; consult the documentation for your version of NIS before changing master servers.
To change NIS master servers, follow these steps:
By removing the timestamp files, you force the maps to be rebuilt regardless of prior modifications. The NOPUSH option to ypmake prevents maps from being pushed to other servers until you have completed this entire procedure.
This command must be run on the old master for every current NIS map. The -h option forces ypxfr to transfer the map from the new master; the -f option forces the transfer even if the contents of the old and new maps are the same.
This command must be run on the old master for every current NIS map. When this is completed, all nonmaster servers will have received maps that include the new master listing.
\:
MAPS=`oawk '{print $1 ; }' /etc/yp/YP_MAP_X_LATE`
for map in $MAPS; do
echo moving $map
ypxfr -h new_master -f $map
yppush $map
done
Make sure your /etc/yp/YP_MAP_X_LATE file is current
before running this command; for more information, refer to
``NIS maps''.
See also:
See also:
If the ASCII source file becomes unavailable, you can remake it
from the NIS map by entering the following:
cd /etc/yp
./makedbm -u mapname > /etc/mapname
Following is an example for modifying the hosts map from its ASCII source file /etc/hosts.
See also:
The result is a map called /etc/yp/domain_name/mymap.
See also:
Propagation of NIS maps depends on the following:
See also:
To edit the file /etc/yp/YP_MAP_X_LATE, you must have root permissions. Map names in this file appear in the form:
long_map_name short_map_nameFor example:
passwd.byname passwd.nam
See also:
See also:
This timestamp is used by NIS programs such as ypxfr on a copy-only server to compare its map versions with those on a master. If the master version has a newer timestamp, the newer version is retrieved.
It may be useful to view this timestamp to ensure synchronization of maps. This timestamp is readable as a string whose value is the standard UNIX system timestamp (seconds since 1970). If this value on a map on a copy-only server is less than that on the map on the master server, the master is newer and hasn't been transferred. If the value on the copy-only server is larger than the master, it may reveal that a bogus master exists somewhere that is updating nonmaster servers.
To view the timestamp, enter:
ypmatch YP_LAST_MODIFIED mapnameThe date is displayed as:
YP_LAST_MODIFIED : 0736625147
See also:
If you must change the name of an existing map, follow this procedure:
If you are going to use the old name for a different NIS map, remove the old map from the master server; create and propagate the new map, using the old name. You will not need to add the name to the YP_MAP_X_LATE files on all NIS servers because it is already there.
See also:
If the frequency of updates to a map changes, change the frequency with which the map is updated by the crontab file. The example files provided are set up to group updates in the same time frequency. To change the frequency with which a map is updated, move its ypxfr entry to a crontab file with a frequency closer to that needed or create a new crontab file if an existing one does not fit.
For example, the following crontab entry will update a map once a day:
0 0 * * * /etc/yp/ypxfr1pdyTo have cron update the map twice a day instead of once a day, change the map's crontab entry to read as follows:
0 0,12 * * * /etc/yp/ypxfr2pdy
See also:
See also:
Use yppush at the master to distribute maps to slave servers.
A master cannot push a map to a copy-only server. Copy-only servers poll the master at set intervals for map updates and acquire those maps that have changed since the copy-only server last polled.
See also:
To enable NIS logging, create the file /usr/adm/nislog.
To disable NIS logging, remove the file /usr/adm/nislog or move it to another location (that is, change its name).
To display NIS logfiles, use a text editor, such as vi(C), or use the more(C) command to view the contents of the logfile /usr/adm/nislog.
To clear the NIS logfile:
cat /dev/null > /usr/adm/nislog
Administering NIS users and groups
Once you have initialized an NIS domain,
most user account administration within the domain can be
performed using the Account Manager.
You can:
You must be in multiuser mode (init state 2) with NIS daemons running before creating or modifying user accounts.
By default, only non-administrative accounts will become distributed NIS accounts when NIS is initialized by either ypinit or mkdev nis.
ypinit will ask the user whether administrative accounts should be distributed. If the user chooses to do so, the ADMACCTS variable in /etc/yp/Makefile and /etc/yp/ypmake will be set to -a.
See also:
To distribute a user account using NIS or to change a local account to a distributed account:
Distributed user accounts can be removed or deactivated using the same procedure as conventional accounts.
Modifying group attributes on servers
Use the Account Manager to create new group accounts on the
NIS master server; refer to
``Managing groups'' in the System Administration Guide
for more information on the Account Manager.
To distribute a group account using NIS or to change a local account to a distributed account:
Distributed group accounts can be removed or deactivated using the
same procedure as for conventional accounts.
Creating netgroups
To create a netgroup, follow these steps:
This will create the new netgroup and push the changes out to the other NIS servers in the domain.
See also:
The following utilities are available for troubleshooting NIS. See their reference manual pages for complete information.
-----------------------------------------------------------------
Utility Function
-----------------------------------------------------------------
ypcat(NC) displays the contents of an NIS map.
ypmatch(NC) prints the value for one or more specified keys
in an NIS map.
yppoll(NADM) asks any NIS server for information about a map
that it holds internally.
ypwhich(NADM) tells you which NIS server an NIS client is
currently using for NIS, or which NIS server is
master of a named map.
rpcinfo(NADM) displays RPC information from a specified RPC
server. Use rpcinfo to check whether portmapper,
ypbind, and (for NIS servers) ypserv are running.
If exporting filesystems, the mountd service
should be registered.
ping(ADMN) reports roundtrip time and packet loss
statistics. Use ping to ensure a network
connection can be made between hosts.
The
Account Manager
is used to administer distributed and local NIS
accounts.
yp: server not responding for name "domainname"; still trying.To check whether the server is up and running, enter from the client:
It should display a list of programs, versions, protocols, and port numbers similar to:
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100002 1 udp 1027 rusersd 100002 2 udp 1027 rusersd 100008 1 udp 1028 walld 100007 2 tcp 1025 ypbind 100007 2 udp 1031 ypbind 100007 1 tcp 1025 ypbind 100007 1 udp 1031 ypbind 100005 1 udp 1127 mountd 100005 1 tcp 1049 mountd 100003 2 udp 2049 nfs 100024 1 udp 1128 status 100024 1 tcp 1050 status 100021 2 tcp 1051 nlockmgr 100021 1 udp 621 nlockmgr 100021 3 udp 621 nlockmgr 100021 1 tcp 621 nlockmgr 100021 3 tcp 621 nlockmgr 100004 2 udp 778 ypserv 100004 2 tcp 779 ypserv 100004 1 udp 778 ypserv 100004 1 tcp 779 ypservThe portmapper, ypbind, and ypserv programs must be running on the server, or NIS cannot work correctly.
You can also use rpcinfo to check whether a specific server
program such as ypserv is running:
rpcinfo -u server_name ypserv
This should return something similar to:
program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting
If these steps fail, run rpcinfo -p on the server's console to verify that the required programs are registered. If they are not running, restart NIS on the server. Check /etc/yp/nislog and /usr/adm/syslog for error messages.
When the required programs are up and running, check whether a network connection can be made between the client and server. See ``Network problems'' for this procedure.
If the NIS server is responding, but the problem is not solved,
check to make sure the local domain is set properly. See
``Domain name problems''.
Domain name problems
If the domain name is not set properly, network utilities
will hang waiting for ypbind to bind to an invalid domain.
To check if the NIS domain name is set, use the
domainname command:
domainname
This should display the NIS domain name. If the domain name is missing or incorrect, check the YPDOMAIN variable in /etc/nis to make sure it is set to the correct domain.
To check if NIS is bound to the correct server, use
the ypwhich command:
ypwhich
This should return the name of the NIS server. If
this hangs or fails, the local machine is unable
to bind to the remote NIS server. Use the rpcinfo
command to check whether the ypbind program is running
on the local machine:
rpcinfo -u server_name ypbind
Network problems
Use the ping command to check that the network is
up and functional:
ping -c 1 server_name
It should display something similar to:
PING server_name (server_address): 56 data bytes 64 bytes from server_name (server_address): icmp_seq=0 ttl=255 time=10 ms--- server_name ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0/5/10 ms
If the ping command hangs, fails, or returns a
message similar to 0 packets transmitted, the network is down.
See
Chapter 13, ``Troubleshooting system-level problems'' in the SCO OpenServer Handbook
and
``Troubleshooting TCP/IP''.
See also:
---------------------------------------------------------------------- Manual page Information provided ---------------------------------------------------------------------- makedbm(NADM) make NIS ndbm file utility map2ascii(NADM) NIS database conversion routines ypinit(NADM) initialize NIS servers and clients ypmake(NADM) make NIS databases yppasswdd(NADM) server for modifying NIS password file yppoll(NADM) query NIS server for NIS map version yppush(NADM) propagate NIS map from master server to slaves ypserv(NADM) NIS server, binder, and transfer processes ypset(NADM) point ypbind at a particular server ypshad2pwd(NADM) install and update the /etc/passwd.yp passwd file ypwhich(NADM) which host is NIS server or map master ypxfr(NADM) transfer NIS map from server to here netgroup(NF) list of network groups ypfiles(NF) description of NIS database and directory structure ypmapxlate(NF) translation table for NIS map names domainname(NC) set or display current NIS domain ypcat(NC) print values of an NIS database ypmatch(NC) print values of one or more keys of NIS database yppasswd(NC) change login password in NISAdditional information on NIS may be found in the following book: Managing NFS and NIS; Stern, Hal (1991); O'Reilly & Associates, Inc., Sebastopol CA. ISBN: 0-937175-75-7.