You can learn how to make customized NIS maps by using the /usr/ccs/bin/make command and the /var/yp/Makefile file. The make utility and the Makefile file:
- Are used by programmers to build programs
- Are used by administrators to build NIS maps
- Can be generalized to build customized NIS maps
Building Targets
The make utility receives its instructions from the Makefile file. The Makefile file uses variable definitions (called macros), targets, and dependencies.
You can use macros as variables, similar to those used in a shell script. You must define a macro at the beginning of the Makefile file. Prefix the name of the macro with a dollar sign ($) when using it throughout the Makefile file.
The make utility builds targets. Targets need dependencies. Dependencies can represent other targets that must be completely built before the original target is considered “made.” This structure enables you to nest the target and dependency pairs to an arbitrary depth, letting you build complex hierarchical code structures.
When making NIS maps, you should keep the target and dependency relationship very basic.
The NIS Makefile file is located in the /var/yp directory and is composed of four main sections:
- The first section contains macro definitions.
- The second section contains the first target, all.
- The third section defines the final target and dependencies.
- The fourth section contains entries for each of the dependencies.
Configuring the Sections of Makefile
The first section of the Makefile file contains the following macro definitions:
#B=-b B= DIR =/etc INETDIR=/etc/inet RBACDIR=/etc/security PWDIR =/etc DOM = `domainname` NOPUSH = “” ALIASES = /etc/mail/aliases YPDIR=/usr/lib/netsvc/yp SBINDIR=/usr/sbin YPDBDIR=/var/yp YPPUSH=$(YPDIR)/yppush MAKEDBM=$(SBINDIR)/makedbm MULTI=$(YPDIR)/multi REVNETGROUP=$(SBINDIR)/revnetgroup STDETHERS=$(YPDIR)/stdethers STDHOSTS=$(YPDIR)/stdhosts MKNETID=$(SBINDIR)/mknetid MKALIAS=$(YPDIR)/mkalias
The second section of the Makefile file contains the first target, all.
all: passwd group hosts ipnodes ethers networks rpc services protocols
netgroup bootparams aliases publickey netid netmasks c2secure
timezone auto.master auto.home
auth.attr exec.attr prof.attr user.attr audit.user
The all target has several dependencies, each of which represents one of the NIS maps to be built. This feature enables the entire set of NIS maps to be built by typing:
# cd /var/yp; /usr/ccs/bin/make
The all target is not considered to be built until each of its targets is first built. Each of the targets for all depends on another target.
When adding custom maps to NIS, the name of the new map to be built should be added to the all target list (auto.direct in the following example).
all: passwd group hosts ipnodes ethers networks rpc services protocols
netgroup bootparams aliases publickey netid netmasks c2secure
timezone auto.master auto.home auto.direct
auth.attr exec.attr prof.attr user.attr audit.user
| Note: The fourth section of the Makefile file is covered before the third section, because the fourth section continues the dependency thread introduced by the all target. |
The entry in the fourth section of the Makefile file for each of the dependencies in the all target is:
passwd: passwd.time group: group.time project: project.time hosts: hosts.time ipnodes: ipnodes.time ethers: ethers.time networks: networks.time rpc: rpc.time services: services.time protocols: protocols.time netgroup: netgroup.time bootparams: bootparams.time aliases: aliases.time publickey: publickey.time netid: netid.time passwd.adjunct: passwd.adjunct.time group.adjunct: group.adjunct.time netmasks: netmasks.time timezone: timezone.time auto.master: auto.master.time auto.home: auto.home.time auth.attr:auth.attr.time exec.attr:exec.attr.time prof.attr:prof.attr.time user.attr:user.attr.time audit.user:audit.user.time $(DIR)/netid: $(DIR)/timezone: $(DIR)/auto_master: $(DIR)/auto_home: $(PWDIR)/shadow: $(DIR)/auth_attr: $(DIR)/exec_attr: $(DIR)/prof_attr: $(DIR)/user_attr: $(DIR)/audit_user: ageing: ageing.time
These entries are used by the make process to establish relationships between the time stamp controls and their respective maps in addition to identifying the location of the source files for the maps.
Using the previous example of an auto.direct map, add a new map to the NIS domain by appending the appropriate entries to the end of this “second level” target and dependency pair.
… auto.direct: auto.direct.time … $(DIR)/auto_direct:
After you modify the auto.direct map, the final lines from the fourth section of the Makefile file would look like:
… auto.master: auto.master.time auto.home: auto.home.time auto.direct: auto.direct.time auth.attr:auth.attr.time exec.attr:exec.attr.time prof.attr:prof.attr.time user.attr:user.attr.time audit.user:audit.user.time $(DIR)/netid: $(DIR)/timezone: $(DIR)/auto_master: $(DIR)/auto_home: $(DIR)/auto_direct: $(PWDIR)/shadow: …
The target is the auto.direct map, which depends on the auto.direct.time target.
The third section of the Makefile file defines the final target and dependencies, as well as instructions on how to build each map in the domain.
Edit the Makefile file by adding the following lines to build a new auto_direct map:
auto.direct.time: $(DIR)/auto_direct
-@if [ -f $(DIR)/auto_direct ]; then \
sed -e “/^#/d” -e s/#.*$$// $(DIR)/auto_direct \
| $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto.direct; \
touch auto.direct.time; \
echo “updated auto.direct”; \
if [ ! $(NOPUSH) ]; then \
$(YPPUSH) auto.direct; \
echo “pushed auto.direct”; \
else \
: ; \
fi \
else \
echo “couldn’t find $(DIR)/auto_direct”; \
fi
| Caution: You can copy and paste lines from a section to another map; however, the proper use of tabs and spaces in the Makefile file is critical. Look up the make command in the online manual pages for the correct usage of tabs and spaces. |
Some points to consider are:
- You must indent subsequent lines of make instructions by using tabs.
- You can use make macros in the instructions.
- Instructions that begin with the at (@) sign are not echoed to the terminal screen. Removing the @ sign is useful for debugging new instructions.
- Instructions that begin with a leading dash (-) before the @ sign do not echo error messages to the terminal screen.
If only one or two clients are experiencing symptoms that indicate NIS binding difficulty, the problems are probably on those clients. If many NIS clients are failing to bind properly, the problem probably exists on one or more of the NIS servers.
This section addresses some common errors associated with NIS server configuration.
No Server Available
If your domain name is set correctly, the ypbind daemon is running, and you get messages indicating that the client cannot communicate with a server, it can indicate a number of different problems:
- Does the client have a /var/yp/binding/domainname/ypservers file containing a list of servers to which it can bind? If not, enter the ypinit -c command, and specify the servers that this client should bind to, in the order of preference.
- If the client has a /var/yp/binding/domainname/ypservers file, does it have enough servers listed in it if a couple of servers should become unavailable? If not, add additional servers to the list by using the ypinit -c command.
| Note: For reasons of security and administrative control, specify the servers that a client should bind to in the client’s ypservers file rather than have the client search for servers through broadcasting. Broadcasting slows down the network, as well as the client, and prevents you from balancing the server load by listing different servers for different clients. |
- If none of the servers listed in the client’s ypservers file are available, the client searches for an operating server by using broadcast mode. If there is a functioning server on the client’s subnet, the client will find it. If there are no functioning servers on the client’s subnet, you can solve the problem in several ways:
- If the client does not have a server on the subnet or have a route to one, install a new slave server on that subnet.
- Make sure that your routers are configured to pass broadcast packets so that the client can use broadcast to find a server on another subnet. Use the netstat -rn command to verify the route.
- If there should be a working route to a server on another network, check to see if the route exists with ping and netstat -nr on both servers. If neither daemon is running, start them with SMF.
- Do the servers listed in a clients ypservers file have entries in the /etc/inet/hosts file? If not, add the servers to the NIS maps hosts input file, and rebuild your maps by using the ypinit -c or ypinit -s commands.
- Is the /etc/nsswitch.conf file set up to consult the client’s local hosts file in addition to NIS?
The ypwhich Command Displays Are Inconsistent
When you use the ypwhich command several times on the same client, the resulting output varies because the NIS server changes, which is normal. The binding of the NIS client to the NIS server changes over time when the network or the NIS servers are busy. Whenever possible, the network becomes stable at a point where all clients get an acceptable response time from the NIS servers. As long as your client machine gets NIS service, it does not matter where the service comes from. For example, an NIS server machine can get its own NIS services from another NIS server on the network.
Network or Servers Are Overloaded
NIS can hang if the network or NIS servers are so overloaded that the ypserv daemon cannot get a response back to the client ypbind process within the time-out period.
Under these circumstances, every client on the network experiences the same or similar problems. In most cases, the condition is temporary. The messages usually go away when the NIS server reboots and restarts the ypserv daemon, or when the load on the NIS servers or network itself decreases.
Server Malfunction
Make sure the servers are up and running. If you are not physically near the servers, use the ping NIS_server command.
NIS Daemons Not Running
If the servers are up and running and you can find a client machine behaving normally, perform the ypwhich command on the client, as follows:
# ypwhich
If the ypwhich command does not respond, kill the ypwhich command.
# pkill ypwhich
Log in as the root user on the NIS server, and check if the NIS daemons are running by performing the command:
# pgrep -fl yp
| Note: Do not use the -f option with the ps command, because this option attempts to translate user IDs into names, which causes more name service lookup requests that might not succeed. |
If either the ypbind or ypserv daemons are not running, stop and then restart the NIS services by performing the commands:
# svcadm disable network/nis/server:default # svcadm enable network/nis/server:default
If both the ypserv and ypbind processes are running on the NIS server, and the ypwhich command does not respond, the ypserv process has probably hung. You must restart the process. Log in as root on the server, and kill the ypserv process.
# pkill ypserv
Start the ypserv process by restarting the NIS services. Perform the commands:
This section addresses some common errors associated with NIS client configuration.
Missing or Incorrect Domain Name
One client has problems, the other clients are operating normally, but ypbind is running on the problem client. The client might not be set to the correct domain.
On the client, perform the domainname command to see which domain name is set.
# domainname suned.Sun.COM
Compare the output with the actual domain name in the /var/yp directory on the NIS master server. The actual NIS domain is shown as a subdirectory in the /var/yp directory and reported with the domainname command on the master server.
# domainname suned.sun.com
If the domain name returned by running the domainname command on a client is not the same as the server domain name listed as a directory in the /var/yp directory, the domain name specified in the client’s /etc/defaultdomain file is incorrect. Log in as superuser, and correct the client’s domain name in the client’s /etc/defaultdomain file to ensure that the domain name is correct every time the machine boots. Then reboot the machine.
| Note: The domain name is case sensitive. |
Client Not Bound to Server
If your domain name is set correctly, the ypbind daemon is running, and commands still hang, then make sure that the client is bound to a server by running the ypwhich command.
# ypwhich NIS_server
The server to which this client is currently bound can be the NIS master server or any NIS slave server that answers the ypbind broadcast.
If you have just started the ypbind daemon, then enter the ypwhich command several times (typically, the first ypwhich command entry reports that the domain is not bound and the second command entry succeeds).
