JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Administration: Naming and Directory Services     Oracle Solaris 11 Information Library
search filter icon
search icon

Document Information


Part I About Naming and Directory Services

1.  Naming and Directory Services (Overview)

2.  Name Service Switch (Overview)

3.  Managing DNS (Tasks)

4.  Setting Up Oracle Solaris Active Directory Clients (Tasks)

Part II NIS Setup and Administration

5.  Network Information Service (Overview)

6.  Setting Up and Configuring NIS (Tasks)

7.  Administering NIS (Tasks)

Password Files and Namespace Security

Administering NIS Users

How to Add a New NIS User to an NIS Domain

Setting User Passwords

NIS Netgroups

Working With NIS Maps

Obtaining Map Information

Changing a Map's Master Server

How to Change a Map's Master Server

Modifying Configuration Files

How to Modify Configuration Files

Modifying and Using /var/yp/Makefile

Working With the Makefile

Changing Makefile Macros/Variables

Modifying Makefile Entries

How to Modify /var/yp/Makefile to Use Specific Databases

How to Modify the Makefile to Delete Databases

Updating and Modifying Existing Maps

How to Update Maps Supplied With the Default Set

Maintaining Updated Maps

Propagating an NIS Map

Using the cron Command for Map Transfers

Using Shell Scripts With cron and ypxfr

Directly Invoking the ypxfr Command

Logging ypxfr Activity

Modifying Non-Default Maps

Using the makedbm Command to Modify a Non-Default Map

Creating New Maps From Text Files

Adding Entries to a File-Based Map

Creating Maps From Standard Input

Modifying Maps Made From Standard Input

Adding a Slave Server

How to Add a New Slave Server

Using NIS With C2 Security

Binding to a Specific NIS Server

Setting a Machine's NIS Domain

How to Set a Machine's NIS Domain Name

Using NIS in Conjunction With DNS

How to Configure Machine Host Name and Address Lookup Through NIS and DNS

Turning Off NIS Services

8.  NIS Troubleshooting

Part III LDAP Naming Services

9.  Introduction to LDAP Naming Services (Overview)

10.  Planning Requirements for LDAP Naming Services (Tasks)

11.  Setting Up Oracle Directory Server Enterprise Edition With LDAP Clients (Tasks)

12.  Setting Up LDAP Clients (Tasks)

13.  LDAP Troubleshooting (Reference)

14.  LDAP Naming Service (Reference)

15.  Transitioning From NIS to LDAP (Tasks)



Updating and Modifying Existing Maps

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.

The following sections explain how to use various updating tools. In practice, you might decide to only use them if you add non-default maps or change the set of NIS servers after the system is already up and running.

How to Update Maps Supplied With the Default Set

Use the following procedure to update maps that are supplied with the default set.

  1. Become an administrator on the NIS master server.

    For more information, see How to Obtain Administrative Rights in Oracle Solaris Administration: Security Services.

  2. Edit the source file for the map that you want to change.

    The file could reside in /etc or in some other directory of your choice.

  3. Run the make command.
    # cd /var/yp
    # make mapname

    The 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.

Maintaining Updated Maps

The following sections describe additional procedures after you have completed updating maps that are supplied with the default set.

Propagating an NIS Map

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.

Note - The 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.

Using the cron Command for Map Transfers

Maps have different rates of change. For instance, some maps might not change for months at a time, such as protocols.byname among the default maps and auto_master among the non-default maps. However passwd.byname can change several times a day. Scheduling map transfer by using the crontab command enables 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.

Note - If 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.

Using Shell Scripts With cron and ypxfr

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 accomodate your site requirements. The following example shows the default ypxfr_1perday shell script.

Example 7-1 ypxfr_1perday Shell Script

#! /bin/sh
# - Do daily yp map check/updates
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. However, be aware of the performance degradation that is implied in frequently propagating the maps. For more information, see the crontab(1) man page.

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 ] mapname

Where 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 must be the same across domains. For example, two domains might share the same services.byname and services.byaddr maps. Alternatively, for more control you can use rcp or rsync to transfer files across domains.

Directly Invoking the ypxfr Command

The second method of invoking the ypxfr command 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.

Logging ypxfr Activity

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.log

You can have crontab execute these commands once a week. To turn off logging, remove the log file.

Modifying Non-Default Maps

To update a non-default map, you must do the following:

  1. Create or edit its corresponding text file.

  2. Build (or rebuild) the new or updated map. There are two ways to build a map.

    • Use 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 /var/yp/Makefile.

    • Use the /usr/sbin/makedbm program. The makedbm(1M) man page fully describes this command.

Using the makedbm Command to Modify a Non-Default Map

There are two different methods for using makedbm to modify maps if you do not have an input file:

Creating New Maps From Text 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 home-domain subdirectory. To do this, type the following on the master server.

# cd /var/yp
# makedbm mymap.asc home-domain/mymap

The mymap map now exists on the master server in the directory home-domain. To distribute the new map to slave servers run ypxfr.

Adding Entries to a File-Based Map

Adding 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.

Creating Maps From Standard Input

When 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 home-domain/mymap key1 value1 key2 value2 key3 value3

Modifying Maps Made From Standard Input

If 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.temp

The 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.temp

Then propagate the map to the slave servers, by becoming root and typing the following.

# yppush mymap

The preceding paragraphs explained how to use makedbm to create maps. However, almost everything you actually have to do can be done by theypinit command and by using /var/yp/Makefile unless you add non-default maps to the database or change the set of NIS servers after the system is already up and running.

Whether you use the Makefile in /var/yp or some other procedure the goal is the same. A new pair of well-formed dbm files must end up in the maps directory on the master server.