This chapter describes how to administer NIS. The following topics are covered.Password Files and Namespace Security Administering NIS Users Working With NIS Maps Updating and Modifying Existing Maps Adding a Slave Server Using NIS With C2 Security Changing a Machine's NIS Domain Using NIS in Conjunction With DNS Turning Off NIS Services The NIS service is managed by the Service Management Facility. Administrative actions on this service, such as enabling, disabling, or restarting, can be performed by using the svcadm command. See NIS and the Service Management Facility for more information about using SMF with NIS. For an overview of SMF, refer to Chapter 16, Managing Services (Overview), in System Administration Guide: Basic Administration. Also refer to thesvcadm1M and svcs1 man pages for more details.NIS services can also be started and stopped by using the ypstart and ypstop commands. See the ypstart1M and ypstop1M man pages for more information. NISsecurity securityNIS, and password dataNIS, and For security reasons, follow these guidelines.It is best to limit access to the NIS maps on the master server. NISroot entrysecurityroot in NIS mapspassword dataroot in NIS mapsThe files used to build the NIS password maps should not contain an entry for root to protect against unauthorized access. To accomplish this, the password files used to build the password maps should have the root entry removed from them and be located in a directory other than the master server's /etc directory. This directory should be secured against unauthorized access. /var/yp directoriesNIS securityMakefile fileNIS securityFor example, the master server password input files could be stored in a directory such as /var/yp, or any directory of your choice, as long as the file itself is not a link to another file and is specified in the Makefile. When you use either the Service Management Facility or the ypstart script to start the NIS service, the correct directory option is set according to the configuration specified in your Makefile.passwd fileSolaris 1.x formatsshadow fileSolaris 1.x formatsIn addition to the older Solaris 1 version passwd file format, this implementation of NIS accepts the Solaris 2 passwd and shadow file formats as input for building the NIS password maps. NISusers, administering usersNIS This section includes information about setting user passwords, adding new users to an NIS domain, and assigning users to netgroups.On the master NIS server, become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. useraddNISuseraddusersuseraddCreate the new user's login ID with the useradd command.# useradd userIDuserID is the login ID of the new user. This command creates entries in the /etc/passwd and /etc/shadow files on the master NIS server. Create the new user's initial password.To create an initial password that the new user can use to log in, run the passwd command.# passwd userIDWhere userID is the login ID of the new user. You will be prompted for the password to assign to this user.useraddpassword is lockedNISuser password lockedThis step is necessary because the password entry created by the useradd command is locked, which means that the new user cannot log in. By specifying an initial password, you unlock the entry. passwd mapsusers, addingIf necessary, copy the new entry into the server's passwd map input files.The map source files on your master server should be in a directory other than /etc. Copy and paste the new lines from the /etc/passwd and /etc/shadow files into the passwd map input files on the server. See Password Files and Namespace Security for additional information.For example, if you added the new user brown, the line from /etc/passwd that you would copy to your passwd input file would look like the following.brown:x:123:10:User brown:/home/brown:/bin/csh:The line for brown that you would copy from /etc/shadow would look like:brown:W12345GkHic:6445:::::: Make sure that the Makefile correctly specifies the directory where the password input file resides. If appropriate, delete the new user's entries from /etc/passwd and /etc/shadow input files.userdelNISuserdelusersuserdel (NIS)For security reasons, do not keep user entries in the NIS master server /etc/passwd and /etc/shadow files. After copying the entries for the new user to the NIS map source files that are stored in some other directory, use the userdel command on the master server to delete the new user.For example, to delete the new user brown from the master server's /etc files, you would enter the following.# userdel brownuserdelFor more information about userdel, see the userdel man page. NISupdating passwd mapsusersupdating passwd mapsUpdate the NIS passwd maps.After you have updated the passwd input file on the master server, update the passwd maps by running make in the directory containing the source file.# userdel brown # cd /var/yp # /usr/ccs/bin/make passwd Tell the new user the initial password you have assigned to his or her login ID.After logging in, the new user can run passwd at any time to establish a different password. NISpasswords, user userspasswords (NIS) passwordsNIS, and passwdUsers run passwd to change their passwords.% passwd usernamepasswordsrpc.yppasswdd (NIS)NISrpc.yppasswddrpc.yppasswddBefore users can change their passwords, you must start the rpc.yppasswdd daemon on the master server to update the password file.The rpc.yppasswdd daemon starts automatically on the master server. Notice that when the m option is given to rpc.yppasswdd, a make is forced in /var/yp immediately following a modification of the file. If you want to avoid having this make take place each time the passwd file is changed, remove the m option from the rpc.yppasswd command in the ypstart script and control the pushing of the passwd maps through the crontab file.ypstart scriptpasswd.adjunct filerpc.yppasswddNo arguments should follow the rpc.yppasswd m command. Although you can edit the ypstart script file to achieve a different action, it is not recommended that you modify this file other than optionally removing the m option. All commands and daemons invoked by this file with the proper set of command line parameters. If you choose to edit this file, be especially careful when editing the rpc.yppasswdd command. If you add an explicit call to the passwd.adjunct file, the exact $PWDIR/security/passwd.adjunct path must be used; otherwise, incorrect processing results. NISnetgroups usersnetgroups groupsnetgroups (NIS) NIS netgroups are groups (sets) of users or machines that you define for your administrative purposes. For example, you can create netgroups that do the following.Define a set of users who can access a specific machine Define a set of NFS client machines to be given some specific file system access Define a set of users who are to have administrator privileges on all the machines in a particular NIS domain Each netgroup is given a netgroup name. Netgroups do not directly set permissions or access rights. Instead, the netgroup names are used by other NIS maps in places where a user name or machine name would normally be used. For example, suppose you created a netgroup of network administrators called netadmins. To grant all members of the netadmins group access to a given machine, you need only add a netadmin entry to that machine's /etc/passwd file. Netgroup names can also be added to the /etc/netgroup file and propagated to the NIS netgroup map. See netgroup4 for more detailed information on using netgroups.netgroup filenetgroup.byuser filenetgroup.byhost fileOn a network using NIS, the netgroup input file on the master NIS server is used for generating three maps: netgroup, netgroup.byuser, and netgroup.byhost. The netgroup map contains the basic information in the netgroup input file. The two other NIS maps contain information in a format that speeds lookups of netgroup information, given the machine or user.Entries in the netgroup input file are in the format: name ID, where name is the name you give to a netgroup, and ID identifies a machine or user who belongs to the netgroup. You can specify as many IDs (members) to a netgroup as you want, separated by commas. For example, to create a netgroup with three members, the netgroup input file entry would be in the format: name ID, ID, ID. The member IDs in a netgroup input file entry are in the following format.([-|machine], [-|user], [domain])Where machine is a machine name, user is a user ID, and domain is the machine or user's NIS domain. The domain element is optional and should only be used to identify machines or users in some other NIS domain. The machine and user element of each member's entry are required, but a dash (-) is used to denote a null. There is no necessary relationship between the machine and user elements in an entry.netgroup fileentries, exampleThe following are two sample netgroup input file entries, each of which create a netgroup named admins composed of the users hauri and juanita who is in the remote domain sales and the machines altair and sirius.admins (altair, hauri), (sirius,juanita,sales)admins (altair,-), (sirius,-), (-,hauri), (-,juanita,sales)NISnetgroupsusersnetgroupsgroupsnetgroups (NIS)Various programs use the netgroup NIS maps for permission checking during login, remote mount, remote login, and remote shell creation. These programs include mountd, login, rlogin, and rsh . The login command consults the netgroup maps for user classifications if it encounters netgroup names in the passwd database. The mountd daemon consults the netgroup maps for machine classifications if it encounters netgroup names in the /etc/dfs/dfstab file. rlogin and rsh In fact, any program that uses the ruserok interface consults the netgroup maps for both machine and user classifications if they encounter netgroup names in the /etc/hosts.equiv or .rhosts files.If you add a new NIS user or machine to your network, be sure to add them to appropriate netgroups in the netgroup input file. Then use the make and yppush commands to create the netgroup maps and push them to all of your NIS servers. See netgroup4 for detailed information on using netgroups and netgroup input file syntax. NIS mapsadministering This section contains the following information:Obtaining Map Information Changing a Map's Master Server Modifying Configuration Files Modifying and Using the Makefile NIS mapsdisplaying contents Users can obtain information from and about the maps at any time by using the ypcat, ypwhich, and ypmatch commands. In the examples that follow, mapname refers both to the official name of a map and to its nickname, if any.To list all the values in a map, type the following.% ypcat mapnameTo list both the keys and the values (if any) in a map, type the following.% ypcat k mapnameTo list all the map nicknames, type any of the following commands.% ypcat x % ypmatch x % ypwhich xTo list all the available maps and their master(s), type the following.% ypwhich mTo list the master server for a particular map, type the following.% ypwhich m mapnameTo match a key with an entry in a map, type the following.% ypmatch key mapnameIf the item you are looking for is not a key in a map, type the following.% ypcat mapname | grep itemwhere item is the information for which you are searching. To obtain information about other domains, use the d domainname options of these commands.If the machine requesting information for a domain other than its default does not have a binding for the requested domain, ypbindconsults the /var/yp/binding/domainname/ypservers file for a list of servers for that domain. If this file does not exist it issues an RPC broadcast for a server. In this case, there must be a server for the requested domain on the same subnet as the requesting machine. NIS mapschanging server makedbmchanging map serverypxfr command changing map serverTo change the master server for a selected map, you first have to build the map on the new NIS master. Since the old master server name occurs as a key-value pair in the existing map (this pair is inserted automatically by makedbm), copying the map to the new master or transferring a copy to the new master with ypxfr is insufficient. You have to reassociate the key with the new master server name. If the map has an ASCII source file, you should copy this file to the new master.On the new master, become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Change directories.newmaster# cd /var/yp Makefile filechanging a map's master serverThe Makefile must have an entry for the new map before you specify the map to make. If this is not the case, edit the Makefile now, using a map called sites.byname. To update or remake the map, type the following.newmaster# make sites.byname If the old master remains an NIS server, remote log in (rlogin) to the old master and edit Makefile. Make sure you comment out the section of the Makefile that made sites.byname so that it is no longer made there. sites.byname filechanging map serverndbm filechanging map servermakedbmchanging map serverIf sites.byname only exists as an ndbm file, remake it on the new master by disassembling a copy from any NIS server, then running the disassembled version through makedbm.newmaster# cd /var/yp newmaster# ypcat sites.byname | makedbm domain/sites.bynameyppush commandchanging map serverAfter making the map on the new master, you must send a copy of the new map to the other slave servers. Do not use yppush, because the other slaves will try to get new copies from the old master, rather than the new one. A typical method for circumventing this is to transfer a copy of the map from the new master back to the old master. To do this, become superuser, or assume an equivalent role, on the old master server and type the following.oldmaster# /usr/lib/netsvc/yp/ypxfr h newmaster sites.bynameNow it is safe to run yppush. Any remaining slave servers still believe that the old master is the current master and will attempt to get the current version of the map from the old master. When clients do so, they will get the new map, which names the new master as the current master.ypxfr commandchanging map serverIf this method fails, you can log in as root on each NIS server and execute the ypxfr command shown above. NISmodifying configuration files NIS mapsmodifying configuration files NIS intelligently parses the setup files. Although this makes NIS administration easier, it does make the behavior of NIS more sensitive to changes in the setup and configuration files.Use the procedures in this section when modifying any of the following./var/yp/Makefilemapssupported listMakefile filemapssupported list/var/yp/Makefile to add or delete supported maps Adding or deleting /etc/resolv.conf to allow or deny DNS forwarding $PWDIR/security/passwd.adjunctpasswd.adjunct fileAdding or deleting $PWDIR/security/passwd.adjunct to allow or deny C2 security ($PWDIR is defined in /var/yp/Makefile) You do not have to stop and start NIS when changing NIS maps or the map source files.Keep the following in mind.Deleting a map or source file from an NIS master server does not automatically result in corresponding deletions from slave servers. You must delete maps and source files from slave servers by hand. New maps do not automatically get pushed to existing slave servers. You must run ypxfr from the slaves. Become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Stop the NIS server.# svcadm disable network/nis/server Make the necessary changes to your files. Start the NIS server.# svcadm enable network/nis/server NIS mapsMakefile and You can modify the Makefile provided by default in /var/yp to suit your needs. You can add or delete maps, and you can change the names of some of the directories.Keep an unmodified copy of the original Makefile for future reference. To add a new NIS map, you must get copies of the ndbm files for the map into the /var/yp/domainname directory on each of the NIS servers in the domain. This is normally done for you by the Makefile. After deciding which NIS server is the master of the map, modify the Makefile on the master server so that you can conveniently rebuild the map. Different servers can be masters of different maps, but in most cases this leads to administrative confusion. Try to set only one server as the master of all maps.NISMakefile filteringNIS mapsMakefile filteringTypically a human-readable text file is filtered through awk, sed, or grep to make it suitable for input to makedbm. Refer to the default Makefile for examples. See the make1S for general information about the make command.makeMakefile syntaxUse the mechanisms already in place in the Makefile when deciding how to create dependencies that make will recognize. Be aware that make is very sensitive to the presence or absence of tabs at the beginning of lines within the dependency rules. A missing tab can invalidate an entry that is otherwise well formed.Adding an entry to the Makefile involves the following.Adding the name of the database to the all rule Writing the time rule Adding the rule for the database Makefile fileautomounter maps andauto_direct.time mapsauto_home.time mapsFor example, in order for the Makefile to work on automounter input files, you would have to add the auto_direct.time and auto_home.time maps to the NIS database.To add these maps to the NIS database you need to modify the Makefile. NIS mapsMakefile variables, changing NIS mapsMakefile macros, changing You can change the settings of the variables defined at the top of the Makefile by changing the value to the right of the equal sign (=). For instance, if you do not want to use the files located in /etc as input for the maps, but you would rather use files located in another directory, such as /var/etc/domainname, you should change DIR from DIR=/etc to DIR=/var/etc/domainname. You should also change PWDIR from PWDIR=/etc to PWDIR=/var/etc/domainname.The variables are the following.NIS mapsMakefile, DIR variableDIR= The directory containing all of the NIS input files except passwd and shadow. The default value is /etc. Since it is not good practice to use the files in the master server's /etc directory as NIS input files, you should change this value. NIS mapsMakefile, PWDIR variablePWDIR= The directory containing the passwd and shadow NIS input files. Since it is not good practice to use the files in the master server's /etc directory as NIS input files, you should change this value. NIS mapsMakefile, DOM variableDOM= The NIS domain name. The default value of DOM is set using the domainname command. However, most NIS commands use the current machine's domain which is set in the machine's /etc/defaultdomain file. The following procedure describes how to add and delete databases from the Makefile.Become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Modify the line that starts with the word all by adding the name(s) of the database you want to add:all: passwd group hosts ethers networks rpc services protocols \ netgroup bootparams aliases netid netmasks \ audit_user auth_attr exec_attr prof_attr \ auto_direct auto_home auto_direct.time auto_home.timeThe order of the entries is not relevant, but the blank space at the beginning of the continuation lines must be a Tab, not spaces. Add the following lines at the end of the Makefile:auto_direct: auto_direct.time auto_home: auto_home.time Add an entry for auto_direct.time in the middle of the file.auto_direct.time: $(DIR)/auto_direct @(while read L; do echo $$L; done < $(DIR)/auto_direct $(CHKPIPE)) | \ (sed -e "/^#/d" -e "s/#.*$$//" -e "/^ *$$/d" $(CHKPIPE)) | \ $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto_direct; @touch auto_direct.time; @echo "updated auto_direct"; @if [ ! $(NOPUSH) ]; then $(YPPUSH) auto_direct; fi @if [ ! $(NOPUSH) ]; then echo "pushed auto_direct"; fiwhereNIS mapsCHKPIPE in MakefileCHKPIPECHKPIPE makes certain that the operations to the left of the pipe (|) are successfully completed before piping the results to next commands. If the operations to the left of the pipe do not successfully complete, the process is terminated with a NIS make terminated message. yppush commandMakefile andNOPUSH in MakefileNIS mapsNOPUSH in MakefileNIS mapsyppush in MakefileNOPUSH prevents the makefile from calling yppush to transfer the new map to the slave servers. If NOPUSH is not set, the push is done automatically. makedbmThe while loop at the beginning is designed to eliminate any backslash-extended lines in the input file. The sed script eliminates comment and empty lines.The same procedure should be followed for all other automounter maps, such as auto_home, or any other nondefault maps. Run make.# make mapnameWhere mapname is the name of the map you want to make. If you do not want the Makefile to produce maps for a specific database, edit the Makefile as follows. Delete the name of the database from the all rule. Delete or comment out the database rule for the database you want to delete.hosts databaseFor example, to delete the hosts database, the hosts.time entry should be removed. Remove the time rule.For example, to delete the hosts database, the hosts: hosts.time entry should be removed. Remove the map from the master and slave servers. After you have installed NIS, you might discover that some maps require frequent updating while others never need to change. For example, the passwd.byname map can change frequently on a large company's network, while the auto_master map changes little, if at all.As mentioned in Default NIS Maps, the default location of the default NIS maps is on the master server in /var/yp/domainname, where domainname is the name of the NIS domain. When you need to update a map, you can use one of two updating procedures, depending on whether or not it is a default map.ypinit commanddefault mapsA default map is a map in the default set created by ypinit from the network databases. NIS mapsnondefaultNondefault maps can be any of the following.Maps included with an application purchased from a vendor Maps created specifically for your site Maps created from a nontext file The following sections explain how to use various updating tools. In practice, you might decide to only use them if you add nondefault maps or change the set of NIS servers after the system is already up and running.Use the following procedure for updating maps supplied with the default set. Become a superuser on the master server.Always modify NIS maps only on the master server. Edit the source file for the map you want to change, whether that file resides in /etc or in some other directory of your choice. Type the following.# cd /var/yp # make mapnamemakeafter updating mapsThe make command then updates your map according to the changes you made in its corresponding file. It also propagates the changes among the other servers. The following sections describe additional procedures after you have completed updating maps that are supplied with the default set.After a map is changed, the Makefile uses yppush to propagate a new map to the slave servers (unless NOPUSH is set in the Makefile). It does this by informing the ypserv daemon and sending a map transfer request. The ypserv daemon on the slave then starts a ypxfr process, which in turn contacts the ypxfrd daemon on the master server. Some basic checks are made (for example did the map really change?) and then the map is transferred. ypxfr on the slave then sends a response to the yppush process indicating whether the transfer succeeded.crontab fileThe above procedure will not work for newly created maps that do not yet exist on the slave servers. New maps must be sent to the slave servers by running ypxfr on the slaves. Occasionally, maps fail to propagate and you must to use ypxfr manually to send new map information. You can choose to use ypxfr in two different ways: periodically through the root crontab file, or interactively on the command line. These approaches are discussed in the following sections. Maps have different rates of change. For instance, some might not change for months at a time, such as protocols.byname among the default maps and auto_master among the nondefault maps; but passwd.byname can change several times a day. Scheduling map transfer using the crontab command allows you to set specific propagation times for individual maps.To periodically run ypxfr at a rate appropriate for the map, the root crontab file on each slave server should contain the appropriate ypxfr entries. ypxfr contacts the master server and transfers the map only if the copy on the master server is more recent than the local copy.NISpasswd maps auto updaterpc.yppasswddpasswd updates mapspasswdNIS map auto updatedIf your master server runs rpc.yppasswdd with the default m option, then each time someone changes their yp password, the passwd daemon runs make, which rebuilds the passwd maps. As an alternative to creating separate crontab entries for each map, you might prefer to have the root crontab command run a shell script that periodically updates all maps. Sample map-updating shell scripts are n the /usr/lib/netsvc/yp directory. The script names are ypxfr_1perday, ypxfr_1perhour, and ypxfr_2perday. You can modify or replace these shell scripts to fit your site requirements. Example 6–1 shows the default ypxfr_1perday shell script.#! /bin/sh # # ypxfr_1perday.sh - Do daily yp 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 This shell script updates the maps once per day, if the root crontab is executed daily. You can also have scripts that update maps once a week, once a month, once every hour, and so forth, but be aware of the performance degradation implied in frequently propagating the maps.Run the same shell scripts as root on each slave server configured for the NIS domain. Alter the exact time of execution from one server to another to avoid bogging down the master.If you want to transfer the map from a particular slave server, use the h machine option of ypxfr within the shell script. Here is the syntax of the commands you put in the script.# /usr/lib/netsvc/yp/ypxfr h machine [ c ] mapnameWhere machine is the name of the server with the maps you want to transfer, and mapname is the name of the requested map. If you use the h option without specifying a machine, ypxfr tries to get the map from the master server. If ypserv is not running locally at the time ypxfr is executed, you must use the c flag so that ypxfr does not send a clear current map request to the local ypserver.You can use the s domain option to transfer maps from another domain to your local domain. These maps should be the same across domains. For example, two domains might share the same services.byname and services.byaddr maps. Alternatively, you can use rcp, or rdist for more control, to transfer files across domains. The second method of invoking ypxfr is to run it as a command. Typically, you do this only in exceptional situations – for example, when setting up a temporary NIS server to create a test environment or when trying to quickly get an NIS server that has been out of service consistent with the other servers. The transfer attempts and results of ypxfr can be captured in a log file. If a file called /var/yp/ypxfr.log exists, results are appended to it. No attempt to limit the size of the log file is made. To prevent it from growing indefinitely, empty it from time to time by typing the following.# cd /var/yp # cp ypxfr.log ypxfr.log.old # cat /dev/null > /var/yp/ypxfr.logYou can have crontab execute these commands once a week. To turn off logging, remove the log file. To update a nondefault map, you must do the following.Create or edit its corresponding text file. Build (or rebuild) the new or updated map. There are two ways to build a map.Makefile filenon-default mapsmodifyingUse the Makefile. Using the Makefile is the preferred method of building a non-default map. If the map has an entry in the Makefile, run make name where name is the name of map you want to build. If the map does not have a Makefile entry, try to create one following the instructions in Modifying and Using the Makefile. Use the /usr/sbin/makedbm program. makedbm1M fully describes this command. /usr/sbin/makedbmnon-default maps, modifying makedbmThere are two different methods for using makedbm to modify maps if you do not have an input file:Redirect the makedbm u output to a temporary file, modify the file, then use the modified file as input to makedbm. sedawkHave the output of makedbm u operated on within a pipeline that feeds into makedbm. This is appropriate if you can update the disassembled map with either awk, sed, or a cat append. NIS mapsnew maps, creating from files Assume that a text file /var/yp/mymap.asc was created with an editor or a shell script on the master. You want to create an NIS map from this file and locate it in the homedomain subdirectory. To do this, type the following on the master server.# cd /var/yp # makedbm mymap.asc homedomain/mymapypxfr commanddistributing new maps to slave serversThe mymap map now exists on the master server in the directory homedomain. To distribute the new map to slave servers run ypxfr. /var/yp/.ascdbmAdding entries to mymap is simple. First, you must modify the text file /var/yp/mymap.asc. If you modify the actual dbm files without modifying the corresponding text file, the modifications are lost. Then run makedbm as shown above. NIS mapsnew maps, creating from keyboard makedbmWhen no original text file exists, create the NIS map from the keyboard by typing input to makedbm, as shown below (end with Control-D).ypmaster# cd /var/yp ypmaster# makedbm homedomain/mymapkey1 value1 key2 value2 key3 value3 makedbmIf you later need to modify the map, you can use makedbm to disassemble the map and create a temporary text intermediate file. To disassemble the map and create a temporary file, type the following.% cd /var/yp % makedbm u homedomain/mymap > mymap.tempThe resulting temporary file mymap.temp has one entry per line. You can edit this file as needed, using any text editor.To update the map, give the name of the modified temporary file to makedbm by typing the following.% makedbm mymap.temp homedomain/mymap % rm mymap.tempThen propagate the map to the slave servers, by becoming root and typing the following.# yppush mymapThe preceding paragraphs explained how to use makedbm to create maps; however, almost everything you actually have to do can be done by ypinit and Makefile unless you add nondefault maps to the database or change the set of NIS servers after the system is already up and running.dbmWhether you use the Makefile in /var/yp or some other procedure the goal is the same. Anew pair of well-formed dbm files must end up in the maps directory on the master server. NIS slave serversadding After NIS is running, you might need to create an NIS slave server that you did not include in the initial list given to ypinit.To add an NIS slave server:On the master server, become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Change to the NIS domain directory.# cd /var/yp/domainname ypservers fileadding slave serverNISypservers fileserversypservers fileDisassemble the ypservers file.# makedbm u ypservers >/tmp/temp_filemakedbm commandadding slave serversThe makedbm command converts ypservers from ndbm format to a temporary ASCII file /tmp/temp_file. Edit the /tmp/temp_file file using a text editor. Add the name of the new slave server to the list of servers. Then save and close the file. ypservers filecreatingRun the makedbm command with temp_file as the input file and ypservers as the output file.# makedbm /tmp/temp_file ypserversmakedbm then converts ypservers back into ndbm format. Verify that the ypservers map is correct (since there is no ASCII file for ypservers) by typing the following on the slave.slave3# makedbm u ypserversThe makedbm command displays each entry in ypservers on your screen.If a machine name is not in ypservers, it will not receive updates to the map files because yppush consults this map for the list of slave servers. On the new NIS slave, become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Set up the new slave server's NIS domain directory.ypinit commandadding slave serversypbind daemonadding slave serversCopy the NIS map set from the master server, then start the NIS client. When running the ypinit command, follow the prompts and list the NIS servers in order of preference.slave3# cd /var/yp slave3# ypinit c slave3# svcadm enable network/nis/client NIS slave serversinitializingInitialize this machine as a slave.slave3# /usr/sbin/ypinit s ypmasterwhere ypmaster is the machine name of the existing NIS master server. svcadmwith NISStop the machine running as an NIS client.# svcadm disable network/nis/client Start NIS slave service.# svcadm enable network/nis/server NISC2 security securityC2 securityNIS and PWDIR/security/passwd.adjunct filepasswd.adjunct fileIf the $PWDIR/security/passwd.adjunct file is present, C2 security is started automatically. ($PWDIR is defined in /var/yp/Makefile.) The C2 security mode uses the passwd.adjunct file to create the passwd.adjunct NIS map. In this implementation, NIS allows you to use both the passwd.adjunct file and shadow file to manage security. The passwd.adjunct file is processed only when you type the following.# make passwd.adjunctmakeC2 security andThe make passwd command processes the passwd map only, not the passwd.adjunct map when you run make manually in the C2 security mode. NISbinding manually Use the following steps to bind to an NIS server that you specify. For more information, see the ypinit1M, ypstart1M, and svcadm1M man pages.Add the hostname of the NIS server and its IP address to the /etc/hosts file. Run the domainname command to populate the /etc/defaultdomain file.# /usr/bin/domainname name-of-NIS-domain Prompt for the NIS server host name.# /usr/sbin/ypinit -c Server name: Type the NIS server hostname Restart the NIS services by performing one of the following steps.For the services to persist across reboots, run the svcadm command:# svcadm enable -r svc:/network/nis/client For the services to persist until reboot only, run the ypstop and ypstart commands:# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart NIS domains changing NIS hosts changing domain of hosts (machines)NIS domains, changing To change the NIS domain name of a machine, do the following.Become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. Edit the machine's /etc/defaultdomain file, exchanging its present contents with the new domain name for the machine.For example, if the current domain name is sales.doc.com, you might change it to research.doc.com. Run domainname `cat /etc/defaultdomain' Set the machine up as an NIS client, slave, or master server.See for Chapter 5, Setting Up and Configuring NIS Service for details. NISDNS and DNSNIS and Typically, NIS clients are configured with the nsswitch.conf file to use only NIS for machine name and address lookups. If this type of lookup fails, an NIS server can forward these lookups to DNS.Become superuser or assume an equivalent role.Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services. The two map files, hosts.byname and hosts.byaddr must include the YP_INTERDOMAIN key. To test this key, edit the Makefile and modify the following lines.#B=b B=toB=b #B=makedbm will now start with the b flag when it makes the maps, and the YP_INTERDOMAIN key will be inserted into the ndbm files. Run the make command to rebuild maps.# /usr/ccs/bin/make hosts Check that all the NIS server's /etc/resolv.conf files point to valid nameservers.If you have NIS servers that are not running Solaris, Release 2, make sure YP_INTERDOMAIN exists in the hosts maps. To enable DNS forwarding, restart each server.# svcadm restart network/nis/server:<instance>In this implementation of NIS, ypserv automatically starts with the d option to forward requests to DNS. If the master and slave servers are not both running Solaris 2, refer to the following table for how to avoid potential problems. The notation “4.0.3+” refers to that and later releases of SunOS. makedm b is a reference to the “B” variable in the Makefile.Slave Master 4.0.3+ Solaris NIS 4.0.3+ Master: makedbm bSlave: ypxfr Master: makedbm bSlave: ypxfr b Master: ypserv dSlave: ypxfr b Solaris NIS Master: makedbm bSlave: ypxfr Master: makedbm bSlave: ypxfr Master: ypserv dSlave:ypxfr with resolv.conf or ypxfr b NIShalting NISstopping If ypserv on the NIS master is disabled, you can no longer update any of the NIS maps.To disable NIS on a client, type the following.# svcadm disable network/nis/client To disable NIS on a specific slave or master server, type the following on the server.# svcadm disable network/nis/server