• Choose a category
• All
• Classic-Fiction

Configuring NIS servers

ypinit initializes both the master and slave servers for a domain. On the master, you use the following commands:4

# cd /var/yp /* The NIS directory, wherever it is */

# domainname foo /* Name the new domain. */

# ypinit -m /* Initialize as master server. */

# ypserv /* Start the NIS server. */

The -m flag tells ypinit that it’s configuring a master server; it will prompt you to enter a list of slave servers. Once the master is up and running, you should prime each slave server by running ypinit with the -s (slave) flag:

# cd /var/yp

# ypinit -s master /* Argument is master's hostname. */

# ypserv

ypinit-s makes a local copy of the master’s current data; the presence of the domain’s data files is enough to let ypserv know that it should serve the domain.

See Chapter 9 for more information about cron.

On each slave, you should set up crontab entries to pull fresh copies of all maps from the master. The command ypxfr map, where map is a name such as passwd.byuid, will transfer the specified map from the master server. You must run the command once for each map. Maps tend to change at different rates, and if network bandwidth is precious, you may want to transfer some maps more often than others. In most circumstances, transferring all the maps once or twice a day (perhaps late at night) is good enough. The following script transfers every map:

#!/bin/csh -f

set mydomain = `/usr/bin/domainname`

cd /var/yp/$mydomain # the NIS directory

foreach map (`/bin/ls`)

/usr/lib/yp/ypxfr $map

end

Some systems provide prefabricated scripts called ypxfr_1perday, ypxfr_2perday, and ypxfr_1perhour that transfer NIS maps at various frequencies.

Many systems that support NIS check at boot time to see if the current host is an NIS server, and if so, they automatically start the ypserv daemon. On others, you must turn on ypserv explicitly. See the vendor specifics section for details.

If you want users to be able to change their passwords with yppasswd, you must run the yppasswdd daemon on the master NIS server.

Configuring NIS clients

After setting up servers, you must inform each client machine that it is a member of the new domain. The servers of a domain are generally clients as well.

See Chapter 2 for more information about the system startup scripts.

The domainname command sets a machine’s NIS domain. It’s usually run at boot time from one of the startup scripts. The exact contortions necessary to configure this vary by system; system-specific details are given below.

Each client must have at least a minimal private version of the passwd, group, and hosts files. passwd and group are needed to allow root to log in when no NIS server is available. They should contain the standard system accounts and groups: root, bin, daemon, wheel, etc. The hosts file must be present to answer boot-time queries that occur before NIS is up and running.

Vendor specifics

Under Solaris, the NIS domain name should be put in the file /etc/defaultdomain. The /etc/init.d/inetinit script checks this file at startup, and if it exists, calls the domainname command with its contents as the only argument. Later in the startup process, the ypstart script notices that the domain name has been set and starts ypbind and ypserv as appropriate. yppasswd and ypxfrd are also started automatically on the master server.

To prevent ypbind from broadcasting to find NIS servers, run ypinit -c on each NIS client machine and enter the names of the servers you would like that client to use. You must kill and restart ypbind on the client without the -broadcast option (or reboot) to make the change take effect. The server names must appear in /etc/hosts so that they can be resolved before NIS is running.

NIS configuration information is kept in /etc/rc.config.d/namesvrs on HP-UX systems. On clients, set the NIS_DOMAIN variable to the NIS domain name and set NIS_CLIENT to 1. On servers, you should also set either NIS_MASTER_SERVER or NIS_SLAVE_SERVER to 1, but not