Set the Slave Server

If there are running slave yp servers, run yppush now for any data bases which have been changed. If there are no running slaves, run ypinit on those hosts which are to be slave servers. The first created map is ypservers, which includes the names of all NIS servers for this NIS domain, based on the host names entered by the administrator during the master server creation. This map is crucial for an update of the NIS databases on the slave servers, because it contains a list of the registered slave servers. It is assumed that at this moment the specified slave servers are not yet running NIS; if they are, it is a good idea to recreate them as the slave servers. Also, ypinit does not check for other possible master servers in the same NIS domain, it is up to the administrator to ensure that multiple master servers are not created. Once ypinit −m finishes, the NIS service should be started manually by issuing the ypserv command; the rc startup script can also be used, everything needed for the proper script execution should be there.

17.2.2.3 Set the Slave Server

Execute the command: full−pathnameypinit −s NISmaster where NISmaster is the name of the master server. Here is an example the host is named NISslave and the implemented platform is again Solaris 2.x; the entered responses are presented in bold−italic: usrsbinypinit −s NISmaster 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? [yn: n] n OK, please remember to go back and redo manually whatever fails. If you dont, some part of the system perhaps the yp itself wont work. The yp domain directory is varypNISdomain Can we destroy the existing varypNISdomain and its contents? [yn: n] y There will be no further questions. The remainder of the procedure should take a few minutes, to copy the data bases from NISmaster. Transferring locale.byname… 407 The newly created slave server will pull NIS data from the master server and store its own copies of the maps; the slave server must be included in the ypservers map, otherwise the master server will reject the transfer of maps. If a new slave server is not included in the map it is realistic situation, because the new slave server could be added later, the ypservers map on the master server must be re−edited. How can an NIS map be re−edited? The ypservers map cannot be re−edited literally. NIS maps are not ASCII files and their contents are odd and noncomprehensive; they are in the ndbm format that is not readable at all, but is very convenient for fast machine searching. Each NIS map is built for better understanding, we can say compiled from a corresponding source ASCII file. Re−editing an NIS map means to re−edit its source file and then recompile the map itself. For the most part, the source files are usually configuration etc files on the master server. However, in the case of the NIS map ypservers, there is no corresponding source file at all; this map has been built based on the supplied data during the master server creation. Consequently to re−edit this map is a tricky business. One possible approach is: First, the old contents of the ypservers map must be dumped into an arbitrary temporary file: ypcat −k ypservers tmpypservers Keep in mind that the ypcat command dispalys the map contents in a comprehensive ASCII format. Then, edit the ASCII file tmpypservers and add a new slave server: vi tmpypservers 408 cat tmpypservers | usrsbinmakedbm − varyp domainname ypservers The new slave server is now included into the ypservers map, and the master server will treat it correspondingly. The master server uses the ypservers map to identify registered slave servers for NIS databases pushing. NIS clients do not base their binding to the slave servers on this map; clients do not check servers for eligibility, they simply trust servers. This means that even if this map is not propagated after an update, it will not affect overall NIS behavior. But this also means, that a not−registered slave server could be accepted by clients as the eligible one, which is a security risk. The ypcat command is used to read the contents of the NIS maps; its −k option which prints each value with the preceding associated key is required in the case of the ypservers map. 17.2.2.4 Start NIS Service Finally, when ypinit −s finishes, the NIS service should be started manually by initiating the ypserv daemon simply by issuing the ypserv command, or ypstart command, or even the corresponding rc start script for NIS.

17.2.3 To Create an NIS Client