Configuring the Network Infomation Service (NIS)I
Configuring the Network Infomation Service (NIS)INIS facilitates the creation of server systems that act as central repositories for several of the administrative files found on UNIX systems. The benefits of NIS include:
[*]Centralized administration of configuration files
[*]Better scaling of configuration file administration as networks grow
The image shows that NIS is organized into named administrative domains. Conceptually, within each domain there is one NIS master server, zero or more slave servers, and one or more clients.
http://blogimg.chinaunix.net/blog/upfile2/080119153204.gif
NIS makes network administration more manageable by providing centralized control over a variety of network information. NIS stores information about host names and their IP addresses, users, groups, and others. This collection of network information is called the NIS namespace.
NIS maps can replace or be used with the configuration files that exist on each UNIX system.
NIS maps are located in the /var/yp/domainname directory (where domainname is the name of the NIS domain). There are two files (.pag and .dir files) for each map in this directory.
Map Contents and Sort Keys
Each map contains a key and value pair. The key represents data used to perform the lookup in the map, while the value represents data returned after a successful lookup. The maps are the results of sorting the data based on different keys.
For example, the /var/yp/domainname/hosts.byaddr.pag map contains the data for the hosts map indexed by host IP addresses. Similarly, the /var/yp/domainname/hosts.byname.pag map contains the same host data using the host name as the lookup key. For the domain name training, the NIS map files list for the hosts map are:
[*]The /var/yp/training/hosts.byname.pag file
[*]The /var/yp/training/hosts.byname.dir file
[*]The /var/yp/training/hosts.byaddr.pag file
[*]The /var/yp/training/hosts.byaddr.dir file
The syntax for the NIS maps is:
map.key.pag and map.key.dir
where:
Syntax for the NIS Maps
Field
Description
map
The base name of the map (hosts, passwd, and so on).
key
The map’s sort key (byname, byaddr, and so on).
pag
The map’s data.
dir
An index to the *.pag file. If the *.pag file is small, the *.dir
file might be empty.
Sometimes searches are made using names. At other times, searches may be performed using an ID number. It is worth noting that searches can be forced to occur on the appropriate NIS map file. For example:# ypmatch -k chris passwd.byname
chris: chris:MWnTvQ5PGuiYo:100:1::/export/home/chris:/usr/bin/ksh
# ypmatch -k chris passwd.byuid
Can’t match key chris in map passwd.byuid.Reason: no such key in map.
# ypmatch -k 100 passwd.byuid
100: chris:MWnTvQ5PGuiYo:100:1::/export/home/chris:/usr/bin/ksh
Commands to Read Maps
You can use two commands to read maps:
[*]ypcat [ -k ] mname - The ypcat command prints out values in the NIS name service map specified by the mname argument, which can be either a map name or a map nickname. # ypcat hosts
192.168.30.30 instructor instructor. loghost
192.168.30.30 instructor instructor. loghost
127.0.0.1 localhost
192.168.30.30 instructor instructor. loghost
192.168.30.41 sys41
192.168.30.34 sys34
[*]ypmatch [ -k ] value mname - The ypmatch command prints the values associated with one or more keys from the NIS name services map specified by the mname argument, which can be either a map name or a map nickname. # ypmatch sys44 hosts
sys44: 192.168.30.44 sys44 loghost
# ypmatch usera passwd
usera: usera:LojyTdiQev5i2:3001:10::/export/home/usera:/bin/ksh
An NIS domain is a collection of hosts and interconnecting networks that are organized into a single administrative authority. NIS uses domains to arrange the hosts, users, and networks in its namespace. An NIS namespace does not use a domain hierarchy. Each NIS domain contains:
[*]One NIS master server
[*]NIS slave servers (optional)
[*]NIS clients
The NIS Master Server
Within each domain, the NIS master server:
[*]Contains the original source ASCII files used to build the NIS maps
[*]Contains the NIS maps generated from the ASCII files
[*]Provides a single point-of-control for the entire NIS domain
NIS Slave Servers
Within each domain, the NIS slave servers:
[*]Do not contain the original source ASCII files used to build the NIS maps
[*]Contain copies of the NIS maps copied from the NIS master server
[*]Provide a backup for NIS map information
[*]Provide redundancy in case of server failures
[*]Provide load sharing on large networks
NIS Clients
Within each domain, the NIS clients:
[*]Do not contain the original source ASCII files used to build the NIS maps
[*]Do not contain any NIS maps
[*]Bind to the master server or to a slave server to obtain access to the administrative file information contained in that server’s NIS maps
[*]Dynamically rebind to another server in case of server failure
[*]Make all appropriate system calls aware of NIS
Note: All hosts in the NIS environment are clients. All NIS clients that are configured as NIS master server and NIS slave servers contain copies of the NIS maps to support the server function.
The main daemons involved in the running of an NIS domain are:
[*]The ypserv daemon
[*]The ypbind daemon
[*]The rpc.yppasswdd daemon
[*]The ypxfrd daemon
[*]The rpc.ypupdated daemon
The image shows a domain and its NIS daemons.
http://blogimg.chinaunix.net/blog/upfile2/080119153401.gif
The ypserv Daemon
The ypserv daemon:
[*]Runs on master and slave servers
[*]Answers ypbind requests from clients
[*]Responds to client information requests
The ypbind Daemon
The ypbind daemon:
[*]Runs on all NIS client systems
[*]Makes initial client-to-server binding requests
[*]Stores binding information in the /var/yp/binding/domainname directory
[*]Rebinds to another server if the connection is lost with the initial server
[*]Requests NIS map information at the library-call level
The rpc.yppasswdd Daemon
The rpc.yppasswdd daemon:
[*]Allows users to change their passwords
[*]Updates the passwd and shadow files on the master server
[*]Updates the NIS password map
[*]Provides or “pushes” the NIS password map to all slave servers
The ypxfrd Daemon
The ypxfrd daemon:
[*]Runs on the NIS master server only
[*]Responds to requests, generated in the slave servers by using the ypxfr command to pull the maps from the master
[*]Transfers NIS maps
The rpc.ypupdated Daemon
The rpc.ypupdated daemon:
[*]Runs on the NIS master server only
[*]Updates NIS maps using the configuration stored in the /var/yp/updaters file
Note: The rpc.ypupdated daemon and the /var/yp/updaters file relate to systems running secure Remote Procedure Call (RPC) services. By default, the updating master’s Makefile is not used to authenticate changing any conventional NIS maps.
The name service switch is a file named /etc/nsswitch.conf. This file controls how a client host or application obtains network information. A template file is provided for each of the Solaris OS name services to assist you in configuring the respective name services. When you select NIS as the name service, the /etc/nsswitch.nis configuration file loads into the default /etc/nsswitch.conf file.
The name service switch file is a database list. Each entry is followed by ordered lists of information that help locate specific information from the respective databases. Although you can customize the nsswitch.conf file to specify any search order, the most common search orders are:
[*]Search files and then NIS
[*]Search NIS and then files
[*]Search files, then NIS, then DNS
http://www.learning-solaris.com/content-img/view-example.gif
A default /etc/nsswitch.nis file is provided with the Solaris 10 OS. This file helps specific databases send lookup requests to local files and then to NIS maps: passwd: files nis
group: files nis
automount:files nis
aliases: files nis
services: files nis
auth_attr:files nis
prof_attr:files nis
project: files nis
Using the passwd database as an example, the entry states that user information lookup is performed first by using the /etc/passwd and /etc/shadow files. If the information does not exist in these local files, then the password lookup requests search the NIS maps on the NIS server.
The default /etc/nsswitch.nis file, provided with the Solaris 10 OS, is also configured so that specific databases can send lookup requests first to the NIS maps and then to the local files. The databases that follow this procedure are: hosts: nis files
networks: nis files
protocols:nis files
rpc: nis files
ethers: nis files
netmasks: nis files
bootparams: nis files
publickey:nis files
Using the hosts database as an example, the entry states that hosts lookup requests first search the NIS maps on the NIS server. If these maps do not contain the information, then the hosts lookup requests search the /etc/inet/hosts file on the client system.
To further define this search, use a status message and a name service switch action option. The condition works as follows:
[*]If the NIS maps source does not respond or is unavailable, it indicates that the map cannot be accessed. You must continue to search the local file for the map.
[*]If you get a “no such entry” response from the NIS maps, it indicates that the NOTFOUND condition is configured with the return action, which causes the system to stop looking for the information. Therefore, when the entry is not found in the NIS map file, stop the search.
The NIS client requests information from the NIS server as usual. If the information is not found, the NIS client requests the information from the DNS server directly. The NIS client is configured as a DNS client so that it can request the information directly from the DNS server. Therefore, you do not need to configure the Makefile file. Using this method, you can configure the hosts database information source in the /etc/nsswitch.conf file to recognize both NIS and DNS.
The following line requests information first from the NIS namespace and then, if the information is not found, it searches the DNS namespace.hosts: nis dns
The Demo shows the process of searching NIS and DNS namespaces. If the information is not located in the NIS namespace, the NIS server returns a status of NOTFOUND. In the name service switch, the default action for the NOTFOUND status is to continue the search with the next listed information source. In this case, the next information source is DNS; therefore, the client requests the information from the DNS namespace.
Just as NIS makes the network information more manageable, it can also create inadvertent security holes. Two methods of closing these security holes are using the securenets file to restrict access to a single host or to a subnetwork, and using the passwd.adjunct file to limit access to the password information across the
network
.
The /var/yp/securenets file limits access to NIS services. If the /var/yp/securenets file exists on an NIS
server
, the server only answers queries or supplies maps to hosts and networks whose IP addresses exist in the file.
The server must be able to access itself. To access itself, the server can be a part of the subnet that is allowed to access the server, or you can add the following entry:host 127.0.0.1
The following example describes a securenets file
where:
[*]The server is configured to access itself.
[*]A class C network is configured for access.
[*]Two specific hosts, 13.13.14.1 and 13.13.14.2, are configured to access the NIS information. # Each line contains two fields separated by
white space
.
(output omitted for brevity)
#
host 127.0.0.1
255.255.255.0 150.10.1.0
host 13.13.14.1
host 13.13.14.2
If you modify entries in the /var/yp/securenets file, you must stop and restart the ypserv and ypxfrd daemons. To restart the daemons, stop and restart the NIS services with:# svcadm disable svc:/network/nis/server:default
# svcadm enable svc:/network/nis/server:default
Caution: Stopping and starting NIS services results in a short period of name services being unavailable.
Note: Refer to “Using NIS with C2 Security” in the “
System Administration
Guide: Naming and Directory Services (DNS, NIS, and LDAP)” book on docs.sun.com for more information about the password.adjunct file.
The passwd.adjunct file prevents unauthorized users from seeing the encrypted passwords that normally form part of the output when viewing the NIS passwd maps.
Encrypted passwords are normally hidden from the user in the /etc/shadow file. With the default NIS configuration, however, the encrypted password string is shown as part of the passwd maps.
The following example shows that the user passwd is hidden from view when viewing the /etc/passwd file:# grep usera /etc/passwd
usera:x:3001:10::/export/home/usera:/bin/ksh
When the ypmatch command runs against the usera account value in the passwd map, the following output appears:# ypmatch -k usera passwd
usera: usera:LojyTdiQev5i2:3001:10::/export/home/usera:/bin/ksh
The encrypted user password is included as part of the NIS passwd maps. To maintain the same security, the
system
configures the passwd.adjunct file. The passwd.adjunct file contains the account name preceded by ## in the password field. Subsequent attempts to gain account information, using the ypcat or ypmatch commands, returns the password entry from the passwd.adjunct file, as follows:# ypmatch -k usera passwd
usera: usera:##usera:3001:10::/export/home/usera:/bin/ksh
One method to enable the passwd.adjunct file is to follow the procedures to configure C2 security features. These procedures are located on the Sun Product Documentation
Web site
at
http://docs.sun.com
.
To generate NIS maps, you need the source files. You can find source files in the /etc directory on the master server. Do not to keep the source files in /etc directory, because the contents of the maps are then the same as the contents of the local files that control access to the master server. This is a special problem for the /etc/passwd and /etc/shadow files, because all users would have access to the master server’s root password that would be available to all NIS clients through the passwd map.
To locate the source files in another directory, modify the /var/yp/Makefile file:
[*]Change the INETDIR line to DIR=/your-choice
[*]Change the DIR=/etc line to DIR=/your-choice
[*]Change the PWDIR=/etc line to PWDIR=/your-choice
[*]
Copy files
from /etc, /etc/inet, and /etc/services to DIR=/your-choice
where your-choice is the name of the directory that you are using to store the source files. This process enables you to keep the local files on the server separate from those files used for NIS.
Caution: Before you make any modifications to the /var/yp/Makefile file, save a copy of the original Makefile file.
The NIS configuration script, /usr/sbin/ypinit, and the make utility generate NIS maps. The ypinit command reads the /var/yp/Makefile file for source file locations, and converts ASCII source files into NIS maps.
Note: For security reasons and to prevent unauthorized
root access
, the files that build the NIS password maps should not contain an entry for the root user. To make sure of this, copy the files to another directory, and modify the PWDIR entry in the Makefile file.
Locating Source Files
The source files are located in the /etc directory on the master server, but the files can be copied into some other directory (such as /etc/yp_dir in the the image).
http://blogimg.chinaunix.net/blog/upfile2/080119153832.gif
The image also shows the location of the defaultdomain file that resides in the /etc directory. The /etc/defaultdomain file sets the NIS
domain name
during system boot.
The ypinit script calls the program make, which uses the Makefile file located in the /var/yp directory. The image shows a default Makefile in the /var/yp directory, which contains the commands needed to transform the source files into the NIS maps.
http://blogimg.chinaunix.net/blog/upfile2/080119153858.gif
The /var/yp directory contains a subdirectory named after the NIS domain name. This
domainname
directory is the repository for the NIS maps created by the ypinit script. The /var/yp/binding/domainname directory contains the ypservers file where the names of the NIS master server and NIS slave servers are stored.
The image shows that the /usr/lib/netsvc/yp directory contains the ypstop and ypstart commands that stop and start NIS services, respectively.
http://blogimg.chinaunix.net/blog/upfile2/080119153927.gif
Dependencies of the NIS Makefile File
The NIS Makefile works by using a set of dependencies. When the make command is executed, it is effectively a make all command. The second section of the Makefile contains the target line all, which determines which maps are built. The all target entries are matched with dependency entries in the fourth section of the Makefile to match them with the final dependencies that define which code segments in the section three of the Makefile are executed to construct the specified NIS maps. Section one of the Makefile contains macros that are called out in section three. These macros redirect the make utility to the alternate locations of source files when you choose to use a source file directory other than the /etc directory.
Note: These sections of the Makefile are described in detail later in this module.
Converting ASCII Source Files Into NIS Maps
To build new maps on the master server, perform the command:
# /usr/sbin/ypinit -m
The ypinit command prompts for a list of other machines to become NIS slave servers. Type the name of the server on which you are working, along with the names of your NIS slave servers. The ypinit command asks whether you want the procedure to terminate at the first nonfatal error or to continue despite nonfatal errors.
The ypinit command asks whether the existing files in the /var/yp/domainname directory can be destroyed. This message is displayed only if NIS has been previously installed. You must answer yes to install a new version of NIS maps. After the ypinit command has constructed the list of servers, it invokes the make command.
This program uses the instructions contained in the Makefile file (either the default one or the one you modified) located in the /var/yp directory. The make command strips any remaining comment lines from the source files and runs the makedbm function on them, creating the appropriate maps and establishing the name of the master server in each map.
To set up the NIS name service master
server
, perform the following steps:
Determine which machines on your network domain will be NIS servers. There should be one NIS master server, and there can be as many NIS slave servers as needed. All
systems
within the domain are NIS clients.
Choose an NIS domain name. This is usually less than 32 characters in length. (The maximum length is 256 characters, and it is case sensitive.)
Enter the
domainname
command to set the local NIS domain. # domainname domainname
For example:
# domainname classroom.Central.Sun.COM
Create an /etc/defaultdomain file with the
domain name
. You must maintain the format established by the original files and update the text files in the /etc directory (all of the files that are used for NIS maps) on the master server with information about the
domain
.
If the files do not already exist, use the touch command to create zero-length files with the following names: /etc/ethers, /etc/bootparams, /etc/locale, /etc/timezone, /etc/netgroup, and /etc/netmasks. These files are necessary for the creation of the complete set of NIS maps as directed in the Makefile file. When you initialize NIS, you receive
error messages
for each of these files if they do not exist.
Install an updated Makefile file in the /var/yp directory if you intend to use NIS on the system that functions as your JumpStartTM server. Performing this installation provides entries that create a map for the /etc/locale file, so that the locale information does not have to be provided by the sysidcfg file.
Note: The lab at the end of this module shows you how to create the updated Makefile file.
Create or populate the /etc/locale file, and make an entry for each domain on your
network
using the following format: domainname locale
For example:
classroom.Central.Sun.COM en_US
Initialize the master server by using the local /etc files. Enter the ypinit -m command. # ypinit -m
When the program prompts you for a list of slave servers and after you complete your list, press Control-D. You can make entries for all slaves now, or you can rerun the ypinit -m command after you determine whether you need more or less slave servers.
The program asks if you want to terminate it on the first
fatal error
. If you answer n, the procedure reports any error and attempts to complete the creation of the NIS
database files
. If you answer y, the process aborts with the first error. You can correct the error and restart the ypinit program.
Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file. If necessary, modify the file.
The following example shows the text feedback displayed as the program begins:
# ypinit -m
In order for NIS to operate successfully, we have to construct a list of the NIS servers. Please continue to add the names for YP servers in order of preference, one per line. When you are done with the list, type aor a return on a line by itself.
next host to add: server1
next host to add:
The current list of yp servers looks like this:
server1
Is this correct? y
Installing the YP
database
will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? n
OK, please remember to go back and redo manually whatever fails. If you don’t, some part of the system (perhaps the yp itself) won’t work.
Note: If you have to restart the ypinit program, you are prompted to destroy the /var/yp/domainname directory. Answer y.
Start the NIS daemons on the master server with the following command: # svcadm enable svc:/network/nis/server:default
If you want to stop the NIS service running on the NIS master, perform the command: # svcadm disable svc:/network/nis/server:default
There are a number of commands that you can use to obtain information from and about the NIS database. You can also use these commands to test the functionality of the NIS service. You do not have to be the superuser to use these commands.
The most commonly used NIS commands are:
Common NIS Commands
Command
Description
ypcat
Prints values from an NIS map
ypmatch
Prints the value of one or more keys from an NIS map
ypwhich
Returns the name of the NIS server that supplies the NIS map services to an NIS client
Using the ypcat CommandThe following example prints the information from the hosts database.
$ ypcat hosts
192.168.30.30 instructor instructor1
127.0.0.1 localhost loghost
192.168.30.45 sys45
192.168.30.44 sys44
192.168.30.43 sys43
192.168.30.42 sys42
192.168.30.41 sys41
…
…
Using the ypmatch Command
The following example matches individual host entries.
# ypmatch sys41 localhost hosts
192.168.30.41 sys41
127.0.0.1 localhost loghost
The following example matches a specific user in the
password database
.
# ypmatch user5 passwd
user5:.dJJ.oofIqCLs:4005:10::/export/home/user5:/bin/ksh
Using the ypwhich Command
Perform the ypwhich command to identify the NIS server the client is bound to:
$ ypwhich
sys44
When used with the -m option, the ypwhich command provides a list of all databases and the name of the master server for each map.
$ ypwhich -m
…
…
timezone.byname sys44
netmasks.byaddr sys44
netid.byname sys44
bootparams sys44
netgroup.byhost sys44
netgroup.byuser sys44
netgroup sys44
…
…
All systems within an NIS domain that are not configured as servers are configured as clients. To configure the NIS client, complete the following steps:
Edit the /etc/inet/hosts file to ensure that the NIS master server and all slave servers have been defined.
Execute the domainname 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.
To initialize the system as an NIS client, perform the command: # ypinit -c
When the system prompts you for a list of NIS servers, enter the names of the NIS master and all slave servers.
Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file. If necessary, modify the file. To exit the ypinit command without building a specific list of NIS servers, press Control-D. The client then broadcasts to bind the first available server during subsequent ypbind operations. When not operating in broadcast mode, clients can only bind to servers that are listed in their /var/yp/binding/domainname/ypservers file.
[*]Start NIS with the following command: # svcadm enable svc:/network/nis/client:default
[*]On the newly configured NIS client, test the NIS functionality by performing the command: # ypwhich -m
The output shows a list of maps together with the NIS master server for each map.
All systems within an NIS domain that are not configured as servers are configured as clients. To configure the NIS client, complete the following steps:
[*]Edit the /etc/inet/hosts file to ensure that the NIS master server and all slave servers have been defined.
[*]Execute the domainname 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.
[*]To initialize the system as an NIS client, perform the command: # ypinit -c
[*]When the system prompts you for a list of NIS servers, enter the names of the NIS master and all slave servers.
[*]Copy the /etc/nsswitch.nis file to the /etc/nsswitch.conf file. If necessary, modify the file. To exit the ypinit command without building a specific list of NIS servers, press Control-D. The client then broadcasts to bind the first available server during subsequent ypbind operations. When not operating in broadcast mode, clients can only bind to servers that are listed in their /var/yp/binding/domainname/ypservers file.
[*]Start NIS with the following command: # svcadm enable svc:/network/nis/client:default
[*]On the newly configured NIS client, test the NIS functionality by performing the command: # ypwhich -m
The output shows a list of maps together with the NIS master server for each map.
本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u1/36549/showart_467888.html
页:
[1]