foundation, let's look at how
to set the machinery in motion. Basic NIS management involves setting
up NIS servers and enabling NIS on client hosts. Server management
includes three tasks:
In this section, we'll review the procedures required to
initialize NIS, set up slave servers, and configure NIS clients.
3.2.2. Installing the NIS master server
We'll assume that you've already done your
planning
and decided that you need a single NIS domain, which will
be
called
bedrock.
[5] Before going any further, make sure you've set the
NIS domain name on the master server
using
domainname. We'll install a server
for an NIS domain named
bedrock:
newmaster# domainname bedrock
A line like this will usually appear in the
/etc/rc2.d/S69inet file for every host (server
and client) in the domain. Setting the domain name if you
aren't using NIS is harmless. Reminder: you are setting the NIS
domain name here, not the DNS domain. See
Section 3.3.8.1, "Internet domains versus NIS domains" later in this chapter.
Note that on Solaris, the domain name setting will not survive a
server reboot unless it is stored in the
/etc/defaultdomain file. So, you need to do:
newmaster# domainname > /etc/defaultdomain
After establishing the domain's name, you should
go over
all the system's administrative files with a fine-toothed comb:
make sure they contain only the entries you want, no more, and no
less. It is important for your network to start with correct map
information. Which administrative files NIS cares about varies, but
generally includes the information shown in
Table 3-1.
Table 3-1. Files managed by NIS
File |
Contains |
/etc/auto_* |
Automounter maps |
/etc/bootparams |
Information about diskless nodes |
/etc/ethers |
Ethernet numbers (MAC addresses) |
/etc/group |
User groups |
/etc/hosts |
Hostnames and IP addresses |
/etc/inet/ipnodes |
Hostnames, IPv4, and IPv6 addresses |
/etc/mail/aliases |
Aliases and mailing lists for the mail system |
/etc/netgroup |
Netgroup definitions (used by NIS) |
/etc/netid |
Netname database for RPC/dh (RPC/dh is discussed in Section 12.5.4, "AUTH_DH: Diffie-Hellman authentication") |
/etc/netmasks |
Network "masks" |
/etc/networks |
Network addresses |
/etc/passwd |
Usernames and user IDs |
/etc/protocols |
Network protocol names and numbers |
/etc/publickey |
Public key database for RPC/dh |
/etc/rpc |
Remote procedure call program numbers |
/etc/services |
Network port numbers and service names |
/etc/shadow |
User passwords |
With the exception of netgroup, these are all
standard Solaris administrative files. Once NIS is running, it will
replace or supplement all of these files, depending on how
/etc/nsswitch.conf is configured.
/etc/netgroup is an administrative file that is
only consulted via the NIS database. Before creating it, see Section 3.3.2, "Netgroups" later in this chapter.
Make sure that your
/etc/passwd file on the
master server does
not include the entry:
+::0:0::
This entry is used by NIS client hosts to indicate that they want to
include NIS map information in their password files. On the NIS
master server, all entries
in the
/etc/passwd file get put into the
passwd NIS map. If you leave this NIS
"marker" in the master server's
/etc/passwd file, your NIS password file map
will contain an entry for a user named
+. If you
do leave the entry in the password file, be sure to put an asterisk
(
*) in the password field so that this
"user" will not have a valid password:
+:*:0:0::
Note that this will not work under all operating systems; in
particular you must not use an asterisk in SunOS 4.0 or later. If you
cannot fill the password field of the NIS "marker" entry,
make sure you remove this entry if you decide not to run NIS at some
future point. Also, in Solaris, the plus sign entry has been
deprecated in favor of the use of the Name Service Switch, via the
nsswitch.conf file.
If you are using NIS to manage
any local files
(company phone lists, etc.), you must also make sure that your local
source files are up-to-date. Once you have established the
domain's name and "purified" the master
server's source files, you're ready to initialize a
master server. To do so, you will use the
ypinit
utility.
You will first need to ensure that
ypinit gets
its naming information from files:
newmaster# cp /etc/nsswitch.files /etc/nsswitch.conf
At this point, you are quite close to creating the NIS maps via the
ypinit utility. However, there is one security
issue you need to be aware of. The
ypinit
utility will generate
maps from
the set of files listed in
Table 3-1. One of these
files is
/etc/shadow, which
contains a one-way hash of the password for every account name listed
in
/etc/passwd. If you look at
/etc/shadow, you should see something like:
root:eOUqsdfpdIaiA:6445::::::
daemon:NP:6445::::::
bin:NP:6445::::::
sys:NP:6445::::::
adm:NP:6445::::::
lp:NP:6445::::::
uucp:NP:6445::::::
nuucp:NP:6445::::::
listen:*LK*:::::::
nobody:NP:6445::::::
noaccess:NP:6445::::::
nobody4:NP:6445::::::
stern:aSuxcvmyerjDM:6445::::::
mre:96wqktpdmrkjsE:6445::::::
The fields are separated by
colons (:). The first field is the name
of the account or login. The second field is the one-way hash. Note
that the "system" accounts,
except for
root,
have a password hash of NP or *LK*. These are not valid hashes, so
the accounts are effectively locked. The nonprivileged accounts, such
as
stern and
mre, have a
valid password hash. It is safe to put the locked accounts in the NIS
passwd map, because the password hash is of no
use to an attacker. It is safe to put the nonprivileged accounts in
the map because they don't have privileges. However, it is not
safe for
the root account to be put into NIS.
The reason is that if an attacker obtains the hash for root, he can
perform an off-line brute force attack to determine the root password
of the master NIS server. With that password, the attacker could
render havoc on your network.
Thus, you must take steps to ensure that the
passwd map does
not
have a root entry. The ypinit utility will invoke the make utility on
/var/yp/Makefile. Then
Makefile will
by default get the
passwd map contents from
/etc/passwd and
/etc/shadow, but by setting the
PWDIR Makefile variable to
something else, you can ensure that
ypinit will
create the passwd map without root in it. So do the following:
newmaster# mkdir /etc/nispw
newmaster# chmod 0700 /etc/nispw
newmaster# grep -v '^root:' /etc/passwd > /etc/nispw/passwd
newmaster# grep -v '^root:' /etc/shadow > /etc/nispw/shadow
newmaster# vi /etc/passwd /etc/shadow # delete the nonprivileged entries,
# e.g., stern and mre
newmaster# cp /var/yp/Makefile /var/yp/Makefile.save
newmaster# vi /var/yp/Makefile # change the PWDIR variable to /etc/nispw
Before you create the new master server, you must decide how many
slave servers you will have. For availability, it is a good idea to
have at minimum one slave. Once NIS is installed, if it ever becomes
unavailable, your network will become unusable. The first time your
master server becomes unavailable, your
users
and
you will appreciate being able to use the network. If you need
additional server horsepower, then set up more than one NIS slave
server. Once you know what the names of the slaves are, make sure
that the master's
/etc/hosts file has
entries for each slave.
To create a new master server, become
the superuser on the host and invoke
ypinit with the
-m flag:
Edit /etc/hosts to add entries for each slave
newmaster# /usr/sbin/ypinit -m
ypinit builds the domain subdirectory of
/var/yp for the current default domain. Note
that the
ypinit utility lives in
/usr/sbin, so you should use its full pathname
if you don't have this directory in your search path. In this
example,
ypinit creates
/var/yp/bedrock.
After building the domain subdirectory,
ypinit
builds a complete set of administrative maps for your system and
places them in this directory. The first map created by
ypinit -m is the
ypservers
map.
ypinit will ask
you
for a list of hosts that will be running NIS. The hosts named in the
ypservers map do not have to be running NIS at
that time, but they should become NIS servers before the first
modifications are made to NIS maps.
You must have one and only one
master
server per NIS domain. There is nothing in
ypinit that checks for the existence of another
master server, so it's
possible to create two masters accidentally in the same domain.
Having more than one master may lead to NIS map corruption; at best
it confuses procedures that contact the NIS master, such as map
transfers and NIS password file updates.
Now enable NIS in
nsswitch.conf so that
processes on your NIS master host can use NIS for all of its name
service accesses:
newmaster# cp /etc/nsswitch.nis /etc/nsswitch.conf
If you are running Solaris 8 and if you think you will ever use the
sec=dh option with NFS, then it would be an
excellent idea to change the entry for publickey in
nsswitch.conf to:
publickey: nis
The reason for this step is that the Solaris 8 utilities that
manipulate
the
publickey map get
confused if there are multiple database sources in the publickey
entry of
nsswitch.conf. You should do this on
NIS slaves and NIS clients as well.
Once
ypinit finishes and
nsswitch.conf is set up to use NIS, you should
start the NIS service manually via the
ypstart
script or by rebooting the server host. In Solaris, the
relevant part of the boot script
/etc/rc2.d//S71rpc
normally looks like this:
# Start NIS (YP) services. The ypstart script handles both client
# and server startup, whichever is appropriate.
if [ -x /usr/lib/netsvc/yp/ypstart ]; then
/usr/lib/netsvc/yp/ypstart rpcstart
fi
Assuming you opt to start the NIS service manually, you would do:
newmaster# /usr/lib/netsvc/yp/ypstart
As the comment in
S71rpc says, the
ypstart script handles the case when the host is
an NIS server or NIS client or both. Both
S71rpc
and
ypstart came with the system when it was
installed, and normally won't need modifications. The logic in
ypstart may require modifications if a server is
a client of one domain but serves another; this situation sometimes
occurs when a host is on multiple networks. Issues surrounding
multiple domains are left for the next chapter.
Test that your NIS server is
working:
newmaster# ypcat passwd
noaccess:NP:60002:60002:No Access User:/:
nobody4:NP:65534:65534:SunOS 4.x Nobody:/:
nobody:NP:60001:60001:Nobody:/:
listen:*LK*:37:4:Network Admin:/usr/net/nls:
daemon:NP:1:1::/:
nuucp:NP:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
uucp:NP:5:5:uucp Admin:/usr/lib/uucp:
sys:NP:3:3::/:
bin:NP:2:2::/usr/bin:
adm:NP:4:4:Admin:/var/adm:
lp:NP:71:8:Line Printer Admin:/usr/spool/lp:
stern:aSuxcvmyerjDM:6445::::::
mre:96wqktpdmrkjsE:6445::::::
You are now ready to add new
slave servers or to set up NIS clients.
Note that NIS
must be running on a master server
before you
can proceed.
3.2.3. Installing NIS slave servers
As with a master server, you must
establish the domain name and the
/etc/hosts file with the IP addresses of all the slaves and the
master:
newslave# domainname bedrock
newslave# domainname > /etc/defaultdomain
Edit /etc/hosts to add master and slaves
When you initialize a new slave server, it transfers
the
data from the master server's map files and builds its own
copies of the maps. No ASCII source files are
used to build the NIS maps on a
slave server -- only the information already in the master
server's maps. If the slave has information in ASCII
configuration files that belongs in the NIS maps, make sure the
master NIS server has a copy of this data before beginning the NIS
installation. For example, having password file entries only on an
NIS slave server will not add them to the NIS
passwd map. The map source files on the master
server must contain
all map information, since
it is the only host that constructs map files from their sources.
The slave will need to act as an NIS client in order get initial
copies of the maps from the server. Thus you must first set up the
slave as a client:
newslave# /usr/sbin/ypinit -c
You will be prompted for a list of NIS servers. You
should
start with the name of the local host (in this example,
newslave), followed by the name of the master
(in this example,
newmaster), followed by the
remaining slave servers, in order of physical proximity.
Now check to see if your slave was already acting as an NIS
client already. If
so, use
ypstop to terminate it:
newslave# ps -ef | grep ypbind
newslave# /usr/lib/netsvc/yp/ypstop
Now start
ypbind:
newslave# /usr/lib/netsvc/yp/ypstart
Slave servers are also initialized using
ypinit.
Instead
of
specifying the
-m option, use
-s and the
name of the NIS master server:
newslave# /usr/sbin/ypinit -s newmaster
Now you need to start
the
ypserv daemon:
newslave# /usr/lib/netsvc/yp/ypstop
newslave# /usr/lib/netsvc/yp/ypstart
Finally, set up
nsswitch.conf to use NIS:
newslave# cp /etc/nsswitch.nis /etc/nsswitch.conf
3.2.3.1. Adding slave servers later
In general, it is a good idea to initialize
your
NIS slave servers as soon as possible after building the master
server, so that there are no inconsistencies between the
ypservers map and the hosts that are really
running NIS. Once the initial installation is complete, though, you
can add slave servers at any time. If you add an NIS slave server
that was not listed in the
ypservers map, you
must add its hostname to this map so that it receives NIS map
updates.
To edit
ypservers, dump out its old contents
with
ypcat, add the new slave server name, and
rebuild the map using
makedbm. This procedure
must be done on the NIS master server:
master# ypcat -k ypservers > /tmp/ypservers
Edit /tmp/ypservers to add new server name
master# cd /var/yp
master# cat /tmp/ypservers | makedbm - /var/yp/`domainname`/ypservers
Once you've changed the master
ypservers
map on the new slave, you must follow the steps described in
Section 3.2.3, "Installing NIS slave servers"
in this
chapter.
3.2.4. Enabling NIS on client hosts
Once you have one or more NIS servers
running
ypserv, you can set up NIS clients that
query them. Make sure you do not enable NIS on any clients until you
have at least one NIS server up and running. If no servers are
available, the host that attempts to run as an NIS client will hang.
To enable NIS on a client host, first set up
the
nsswitch.conf
file:
newclient# cp /etc/nsswitch.nis /etc/nsswitch.conf
Set up the domain name:
newclient# domainname bedrock
newclient# domainname > /etc/defaultdomain
Run
ypinit:
newclient# /usr/sbin/ypinit -c
You will be prompted for a list of NIS servers. Enter the servers in
order of proximity to the client.
Kill (if necessary) ypbind, and restart it:
newclient# ps -ef | grep ypbind
newclient# /usr/lib/netsvc/yp/ypstop
newclient# /usr/lib/netsvc/yp/ypstart
Once NIS is running, references to the basic
administrative
files are handled in two fundamentally different ways, depending on
how
nsswitch.conf is configured:
- The NIS database replaces some files. Local
copies of replaced
files (ethers, hosts,
netmasks,
netgroups,[6] networks,
protocols, rpc, and
services) are ignored as soon as the
ypbind daemon is started (to enable NIS).
- Some files are augmented, or
appended to, by NIS. Files
that
are appended, or augmented, by NIS are consulted before the NIS maps
are queried. The default /etc/nsswitch.conf file
for NIS has these appended files: aliases,
auto_*, group,
passwd, services, and
shadow. These files are read first, and if an
appropriate entry isn't found in the local file, the
corresponding NIS map is consulted. For example, when a user logs in,
an NIS client will first look up the user's login name in the
local passwd file; if it does not find anything
that matches, it will refer to the NIS passwd
map.
Although the replaced files aren't consulted once NIS is
running,
they
shouldn't be deleted. In particular, the
/etc/hosts file is used by an NIS client during
the boot process, before it starts NIS, but is ignored as soon as NIS
is running. The NIS client needs a "runt"
hosts file during the boot process so that it
can configure itself and get NIS running. Administrators usually
truncate
hosts to the absolute minimum: entries
for the host itself and the "loopback" address. Diskless
nodes need additional entries for the node's boot server and
the server for the diskless node's
/usr
filesystem. Trimming the
hosts file to these
minimal entries is a good idea because, for historical reasons, many
systems have extremely long host tables. Other files, like
rpc,
services, and
protocols, could probably be eliminated, but
it's safest to leave the files distributed with your system
untouched; these will certainly have enough information to get your
system booted safely, particularly if NIS stops running for some
reason. However, you should make any local additions to these files
on the master server alone. You don't need to bother keeping
the slaves and clients up to date.
We'll take a much closer look at the files managed by NIS and
the mechanisms used to manage appended files in
Section 3.3, "Files managed under NIS". Meanwhile, we'll assume that you
have modified these files correctly
and
proceed with NIS setup.