11.1. Creating new NIS maps

The initial NIS maps will be created by running

    % /usr/lib/yp/ypinit -m

This is done when setting up the NIS master server for the first time. For more information about this, read Section 9. If you wish to add new maps to your server or remove old one, you need to edit the /var/yp/Makefile and change the all: rule. Add or remove the name of the rule, which generates the map.

If you delete a map, you also have to remove the corresponding files.

After this change, you only need to run

    % make -C /var/yp

and the maps should be created.

11.2. Updating NIS maps

If you modify the sources for the NIS maps (for example if you create a new user by adding the account to the passwd file), you need to regenerate the NIS maps. This is done by a simple

    % make -C /var/yp

This command will check which sources have changed, creates the maps new and tell ypserv that the maps have changed.

11.3. Length of Map entries

The length of one entry is limited by the NIS protocol to 1024 characters. You can't just increase this value and recompile the system. Every system that uses NIS v2 expects key and data values to be no more than 1024 bytes in size; if you suddenly make YPMAXRECORD larger on your client and server, you will break interoperability with all other systems on your network that use NIS. To make it work right, you'd have to go to every vendor that supports NIS and get them to all make the change at the same time. Chances are you won't be able to do this.

With glibc 2.1 and newer this limit was removed from the glibc NIS implementation. So it is possible under Linux to use longer entries, but only if you have no other NIS clients or servers in your network.

To allow the creation of NIS maps with a longer entry, you need to add the --no-limit-check option to the makedbm call in /var/yp/Makefile.

The result should look like:

DBLOAD = $(YPBINDIR)/makedbm -c -m `$(YPBINDIR)/yphelper --hostname` --no-limit-check

WARNING: This breaks the NIS protocol and even if Linux supports it, not all Applictions running under Linux works with this change!

There is another way of solving this problem for /etc/group entries. This idea is from Ken Cameron:

1. Break the entry into more than one line and name each group
   slightly differnet.

2. keep the GID the same for all.

3. have the first entry with the right group name and the GID.
   I don't put any user names in this one.

What happens is that going by user name you pick up the GID when the code
reads it. Then going the other way it stops after the first match of GID
and takes that name. It's ugly but works!