| We stated earlier that the slaves should be built as clients first. The reason for this is that during the slave configuration process, ypinit needs to copy the NIS maps from the master back to the slave, which it does using NIS itself. This means that before we can run ypinit, the client side of NIS should already be runningin other words, ypbind should be running. For our slave builds, we'll assume that they are already configured correctly following the steps just described in the section "Build the Clients" on page 295. This means that the domainname is set, the NIS services have started, and the server map contains the complete list of servers (including the slaves). Let's use fluorine for this example and start by checking that the domainname is correct: fluorine# domainname nis.solarisbootcamp.com flourine# Just to make sure everything is correct, we'll stop and restart NIS to make sure ypbind is running: fluorine# /usr/lib/netsvc/yp/ypstop fluorine# /usr/lib/netsvc/yp/ypstart starting NIS (YP server) services: ypbind done flourine# Good. Now the machine is acting as a NIS client, so we can start to initialize it as a slave: [View full width] fluorine# ypinit -s tin 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? [y/n: 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. The yp domain directory is /var/yp/nis.solarisbootcamp.com There will be no further questions. The remainder of the procedure should take a few minutes, to copy the data bases from tin. Transferring auto.home... Transferring auto.master... Transferring netmasks.byaddr... Transferring netid.byname... Transferring publickey.byname... Transferring mail.byaddr... Transferring mail.aliases... Transferring protocols.byname... Transferring services.byservicename... Transferring services.byname... Transferring rpc.bynumber... Transferring networks.byaddr... Transferring networks.byname... Transferring hosts.byaddr... Transferring hosts.byname... Transferring group.bygid... Transferring group.byname... Transferring passwd.byuid... Transferring protocols.bynumber... Transferring ypservers... Transferring passwd.byname... fluorine's nis data base has been set up without any errors. flourine#
This output shows that the maps have been transferred from tin. If we check the slave we can see that the directory /var/yp/nis.solarisbootcamp.com has been created and that it contains copies of the NIS maps, just as we saw on the master. NIS is only running in client mode on the server at present, so now we need to stop and restart it again to bring up both the client and server processes: fluorine# /usr/lib/netsvc/yp/ypstop fluorine# /usr/lib/netsvc/yp/ypstart starting NIS (YP server) services: ypserv ypbind done flourine# Again, we can see the daemons that have been started, and this time both ypserv (the server side) and ypbind (the client side) are running. Running some NIS commands will show that it appears to be working OK, and that we have bound to ourselves, rather than the master: fluorine# ypwhich fluorine flourine# fluorine# ypwhich -m auto.home tin hosts.byaddr tin hosts.byname tin <lines removed for clarity> ypservers tin flourine# Good. We're happy that the machine is working as a slave, so let's alter the switch file and make NIS our default naming service as we did for the master and clients: fluorine# cp /etc/nsswitch.nis /etc/nsswitch.conf flourine# | 
