The Network Information Service (NIS) is a distributed database service that uses one set of configuration files for multiple computers on a LAN.
All Linux computers come with the same basic configuration files. An NIS database of configuration files may be easier to maintain instead of different versions of the same file on different computers.
For example, you may want your users to be able to enter the same username and password at each of your computers. One approach is to copy the /etc/passwd and /etc/ group files to every computer on your LAN. Alternatively, you can configure a central database on an NIS server. In NIS, these databases are also known as maps .
You may have a larger LAN and don t want to go to the trouble of creating a DNS server. While you could copy the /etc/ hosts file to every computer on your LAN, this becomes more difficult as you add more computers to your LAN. Storing /etc/hosts on a central NIS server map is an excellent option.
While creating a DNS server is not difficult, it does mean running another service. Many administrators try to keep their services to a minimum. One way to do this is by avoiding the use of DNS on a local network, relying on /etc/hosts shared via NIS and on the DNS servers of an ISP for the Internet.
Red Hat Linux 9 comes with the packages needed to support a regular NIS version 2.2 server. In this chapter, you ll notice a couple of references to nisplus , which is based on the NIS version 3. x server (reportedly troubled by bugs ).
In the following sections, we ll examine the required RPM packages, define the domain, define what we re going to share, start the NIS services, and generate the database maps that we ll need.
The drawback to NIS is security. If you have an NIS server, it should be on a LAN behind a firewall. You should not have a firewall between NIS servers and clients . While there are a number of things you can do with firewalls to help secure NIS on a LAN, it may be more trouble than it s worth. A simple web search for the terms NIS and security reveals many thousands of websites and messages detailing various security issues.
Four basic RPM packages are associated with NIS, as shown in Table 28.7. Notice that the portmap-* RPM used by NFS is included here as well. As described in Chapter 10 , you can run the rpm -qi packagename command to learn more about each package.
Supports secure NIS remote procedure call (RPC) connections.
The NIS client package; it binds a client to a server.
The NIS server package.
Includes basic NIS commands.
NIS clients and servers are organized in domains. Unfortunately, NIS domains are unrelated to the domains associated with computer names such as linux.mommabears.com , or even the domains associated with Microsoft networks.
First, your computer may already have an NIS domain name . To find out, run the domainname command. If it returns "(none)", your computer does not have an assigned NIS domain.
Assigning an NIS domain name is easy. For example, the following command defines a domain name of nistest for the local computer:
# domainname nistest
You ll also want to add a corresponding entry in /etc/sysconfig/network so it is known the next time you boot Linux. In this case, here s the line you need to add:
Once you ve installed the required RPMs and set the NIS domain name, the next step is to configure the NIS server. This starts with the Makefile in the /var/yp directory. It is an extensive file; essentially , you get to set parameters, and the script at the bottom processes the files that you select into NIS database maps to be shared on the NIS domain. The variables we ll describe in this section are based on the default Makefile and are limited to that file.
You can configure NIS to look for computers that aren t in the NIS database. If you enable this command (by removing the #), it looks to your DNS servers for more information:
On larger LANs, you may have a backup NIS server. If you do, you ll want to change true to false . NIS then looks for the names of slave servers in /var/yp/ypservers :
By default, regular users have user IDs and group IDs of 500 and above. Lower ID numbers include administrative users. The following commands exclude lower ID numbers from the appropriate NIS map database:
If you want to keep some local-only users, you can set higher ID numbers. For example, if you set MINUID and MINGID to 505, the first five users on all computers on the NIS domain will be local.
If you try to connect to an NFS server on an NIS domain as a root user, the following commands map the root user ID to a special user known as nobody, which has few privileges:
As you might remember from Chapter 09 , passwords are normally kept in /etc/shadow and /etc/gshadow . If your Linux system is configured this way, these commands incorporate passwords into the NIS map database:
The following source directories should be standard. Unless you ve changed the location of basic files such as /etc/passwd , you should not have to change any of these settings:
YPSRCDIR = /etc YPPWDDIR = /etc YPBINDDIR = /usr/lib/yp YPSBINDDIR = /usr/sbin YPDIR = /var/yp YPMAPDIR = $(YPDIR)/$(DOMAIN)
Many of the following settings are standard. For example, GROUP is associated with YPPWDDIR , which is the /etc directory. From the first line in this list, the group configuration file is /etc/group , which is the standard location. If you ve changed the location of any of these configuration files, revise these lines accordingly :
GROUP = $(YPPWDDIR)/group PASSWD = $(YPPWDDIR)/passwd SHADOW = $(YPPWDDIR)/shadow GSHADOW = $(YPPWDDIR)/gshadow ADJUNCT = $(YPPWDDIR)/passwd.adjunct #ALIASES = $(YPSRCDIR)/aliases # could be in /etc/mail ALIASES = /etc/aliases ETHERS = $(YPSRCDIR)/ethers BOOTPARAMS = $(YPSRCDIR)/bootparams HOSTS = $(YPSRCDIR)/hosts NETWORKS = $(YPSRCDIR)/networks PRINTCAP = $(YPSRCDIR)/printcap PROTOCOLS = $(YPSRCDIR)/protocols PUBLICKEYS = $(YPSRCDIR)/publickey RPC = $(YPSRCDIR)/rpc SERVICES = $(YPSRCDIR)/services NETGROUP = $(YPSRCDIR)/netgroup NETID = $(YPSRCDIR)/netid AMD_HOME = $(YPSRCDIR)/amd.home AUTO_MASTER= $(YPSRCDIR)/auto.master AUTO_HOME = $(YPSRCDIR)/auto.home AUTO_LOCAL = $(YPSRCDIR)/auto.local TIMEZONE = $(YPSRCDIR)/timezone LOCALE = $(YPSRCDIR)/locale NETMASKS = $(YPSRCDIR)/netmasks YPSERVERS = $(YPDIR)/ypservers
Next, you can select the files to share through your NIS server. The following list is from the default configuration file; you can add or subtract from the list by placing it in or removing it from the comment area (with the #):
all: passwd group hosts rpc services netid protocols mail \ # netgrp shadow publickey networks ethers bootparams \ # printcap amd.home auto.master auto.home auto.local \ # passwd.adjunct timezone locale netmasks
The rest of the Makefile processes these settings. Because this is not a programming book, I won t cover any further configuration; the default script in the rest of this file is sufficient for most users.
Once you ve configured the /var/yp/Makefile , the next step is to start the NIS server. Since it s a standard Linux service, simply issue the following command:
# service ypserv start
The ypserv daemon won t work if you haven t defined an NIS domain name. As described earlier, you can do this with the domainname yourNISdomain command.
Now you can process the Makefile into a database map. The /usr/lib/yp/ypinit -m command processes the Makefile to a /var/yp/ dommainname subdirectory, where domainname is the name of the NIS domain. You might realize that the /usr/lib/yp directory is not a part of the PATH (see Chapter 08 ), so you ll need to run the ypinit command using the full directory path.
Don t forget to make sure that the NIS service starts the next time you boot Linux. The chkconfig --level 345 ypserv on command ensures that the NIS server starts automatically at runlevels 3, 4, and 5.
When you run this command, you ll be prompted to enter the names of the computers that you want to add to your NIS domain. In the case shown, RHL9 is the name of the NIS server computer; you may have a computer with a name like linux.example.com . The computers that you add are included in /var/yp/ypservers , which means you can configure them as NIS slave servers.
# /usr/lib/yp/ypinit -m At this point, we have to construct a list of the hosts which will run NIS servers. RHL9 is in the 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 <control D> next host to add: RHL9 next host to add:
When you ve finished adding computers to your NIS domain, you re asked to confirm your list. If you type n , you re prompted to start your list again. Otherwise, the ypinit command should start processing your Makefile with messages similar to those shown in Figure 28.7.
If you see an error starting with failed to send ˜clear to local ypserv , you probably forgot to start the NIS server, the ypserv daemon.
If you need to update the NIS database, navigate to the /var/yp directory, and then run the make command. As you may remember from Chapter 12 , a Linux Makefile can be typically processed in this fashion, for a kernel, for many packages, and yes, for the NIS database.
In larger networks, it s useful to have backups . The NIS slave server includes the information that the other computers on your network may need to keep going. To set up an NIS slave server, there are things you need to do on both the NIS master and the NIS slave computers.
On the master, make sure that you ve added both computers to the list of NIS computers on the NIS domain, in /var/yp/ypservers . You should have already done this when you ran the /usr/lib/yp/ ypinit -m command.
You also need to revise one line in the master NIS server s /var/yp/Makefile to show NOPUSH=false . This allows your NIS master server to copy its database to the NIS slave with the yppush command.
You ll also need to start the NIS map transfer server daemon, ypxfrd . Naturally, you can do this while Linux is running by using the service ypxfrd start command; to make sure it starts the next time you boot Linux, run the following command:
# chkconfig --level 345 ypxfrd on
Once the NIS master server is ready, there are just a few things that you need to check on the NIS slave. First, NIS slave servers should also be clients of both servers. For more information, read about NIS clients in the next section .
Make sure that your NIS slave computer is bound to the NIS master server. As long as you ve assigned the NIS domain name on the slave computer, the ypbind command should do this automatically. The ypserv daemon should be running; you can check this with the service ypserv status command. Start these daemons as required. When you re ready, try the following command (substitute the hostname of your NIS master server for RHL9):
# /usr/lib/yp/ypinit -s RHL9
If the command is successful, you ll see a long series of messages, each of which transfers a configuration file from the NIS master to the NIS slave. One example is:
Transferring passwd.byname Trying ypxfrd success
If you need to troubleshoot, you should see some messages here (and from a ypbind -debug command). Besides checking the network, recheck the NIS master server configuration process. Also, check that you ve set NOPUSH=false on the NIS master to accommodate the NIS slave server. Make sure the appropriate services are started on the local NIS slave computer.
By default, NIS does not use DNS servers, so it s important to have at least the NIS master server information in the NIS slave computer s /etc/hosts file.