Configuring the Network Infomation Service (NIS)II
Configuring the Network Infomation Service (NIS)IIYou should have at least one NIS slave
server
to provide backup if the NIS master server becomes unavailable. To configure an NIS slave server, complete the following steps on the
system
that you want to designate as the slave server:
Edit the /etc/inet/hosts file to ensure that the NIS master and all NIS slave servers have been defined.
Execute the domainname command to set the local NIS domain. # domainname domainname
For example:# domainname classroom.Central.Sun.COM
Create or populate the /etc/defaultdomain file with the
domain name
.
Initialize the system as an NIS client by performing the command: # ypinit -c
When the system prompts for a list of NIS servers, enter the NIS master host followed by the name of the local host and all other NIS slave servers on the local network.
Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file. If necessary, modify the file.
On the NIS master, ensure that the ypserv process is running by performing the command: # pgrep -fl ypserv
If it is not running, refer to the previous section on how to start NIS daemons on the master.
Return to the proposed NIS slave system, and enter the ypstart command to start the ypbind daemon. # svcadm enable svc:/network/nis/client:default
Initialize the system as an NIS slave by performing the command: # ypinit -s master
where master is the name of the NIS master.
Note: If you did not add the name of the NIS slave server when you initially configured the NIS master server using the ypinit command, enter the ypinit -m command once more on the NIS master server. In the process of updating the NIS master, the script prompts you for confirmation when it is about to destroy the existing domain database. Confirm by entering y.
Before starting the ypserv daemon on the slave server, stop the client with the command: # svcadm disable svc:/network/nis/client:default
When the NIS server is started, it also starts the ypbind client daemon. # svcadm enable svc:/network/nis/server:default
To test NIS client functionality on the newly configured NIS slave server, perform the command: # ypwhich -m
The output shows a list of maps together with the NIS master server for each map.
Because database files change with time, you must update your NIS maps. To update the NIS maps (on the master server), complete the following steps:
Update the text files in your source directory (typically, /etc, unless it was changed in the Makefile file).
Change to the /var/yp directory. # cd /var/yp
Refresh the NIS database maps using the make utility. # /usr/ccs/bin/make
If the NIS master is running the rpc.yppasswdd daemon, any client system can update the NIS password map by using the yppasswd or passwd commands, as shown in the image.
http://blogimg.chinaunix.net/blog/upfile2/080119154411.gif
To update the password map complete the following steps:
Run the rpc.yppasswdd daemon on the NIS master server # /usr/lib/netsvc/yp/rpc.yppasswdd /$PWDIR/passwd -m passwd
When users change their NIS passwords, the rpc.yppasswdd daemon updates the NIS master’s /$PWDIR/passwd file and passwd map. The passwd map is then pushed to all slave servers.
Enter the passwd command on any NIS client. $ passwd
Changing NIS password for user1 on server1.
Old password:
New password:
Retype new password:
NIS entry changed on server1
The following steps manually update the NIS timezone map on the master server and propagate all maps to the slave servers:
Edit the source file on the NIS master. # vi /etc/timezone
Remake and push the NIS maps to the slave servers. # cd /var/yp; /usr/ccs/bin/make
If the push from the master server fails, the following command runs on the slave server and manually “pulls” only the timezone map from the master server. # /usr/lib/netsvc/yp/ypxfr timezone.byname
To pull all of the maps from the master server at once, perform the command:
# ypinit -s nis_master
Sometimes maps fail to propagate, and you must manually use the ypxfr command to retrieve new map information. To automate the updating and propagating of NIS maps on slave servers, you can install shell scripts to run as cron jobs. Because maps have different rates of change, scheduling a map transfer by using the crontab command enables you to set specific propagation intervals for individual maps.
The Solaris OS provides several template scripts in the /usr/lib/netsvc/yp directory that you can use and modify to meet your local site requirements. These scripts are useful when slave servers are down during NIS map propagations.
The image shows you how to update passwd maps using slave servers with scripts. When slave servers are down, they might not receive the update unless you run a “safety valve” script.
http://blogimg.chinaunix.net/blog/upfile2/080119154501.gif
Using the ypxfr_1perhour Script
The following text lists the contents of the ypxfr_1perhour script that, if run hourly using the cron daemon, ensures that the NIS slave server’s passwd map is never more than one hour out of date.#! /bin/sh
#
# Copyr 1990 Sun Microsystems, Inc.
#ident“@(#)ypxfr_1perhour.sh1.2 00/05/01 SMI”
#
# ypxfr_1perhour.sh - Do hourly NIS map check/updates
#
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr passwd.byname
ypxfr passwd.byuid
Using the ypxfr_1perday Script
The following output details the contents of the ypxfr_1perday script. If run daily using the cron daemon, the script ensures that the NIS slave server’s NIS maps for the group, protocols, networks, services, and ypservers keys are never more than one day out of date.#! /bin/sh
#
# Copyr 1990 Sun Microsystems, Inc.
#ident“@(#)ypxfr_1perday.sh 1.2 00/05/01 SMI”
#
# ypxfr_1perday.sh - Do daily NIS map check/updates
#
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr group.byname
ypxfr group.bygid
ypxfr protocols.byname
ypxfr protocols.bynumber
ypxfr networks.byname
ypxfr networks.byaddr
ypxfr services.byname
ypxfr ypservers
Using the ypxfr_2perday Script
The following output details the contents of the ypxfr_2perday script. If run twice daily using the cron daemon, the script ensures that the NIS slave server’s NIS maps for the hosts, ethers, netgroups keys, and mail aliases are never more than 12 hours out of date.#! /bin/sh
#
# Copyr 1990 Sun Microsystems, Inc.
#ident“@(#)ypxfr_2perday.sh 1.2 00/05/01 SMI”
#
# ypxfr_2perday.sh - Do twice-daily NIS map check/updates
#
PATH=/bin:/usr/bin:/usr/lib/netsvc/yp:$PATH
export PATH
# set -xv
ypxfr hosts.byname
ypxfr hosts.byaddr
ypxfr ethers.byaddr
ypxfr ethers.byname
ypxfr netgroup
ypxfr netgroup.byuser
ypxfr netgroup.byhost
ypxfr mail.aliases
As system requirements or configurations change, you must keep the name service configuration the same as the system configuration.
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:
# svcadm disable network/nis/server:default
# svcadm enable network/nis/server:default
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).
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/36549/showart_467890.html
页:
[1]