Friday, October 11, 2013

NIS slave

Installing and configuring a NIS slave isn't a mysterious task either. But unfortunately, sometimes (or why not often) the procedure isn't clearly presented (perhaps due to some sort of presenter's self-evidence or triviality), turning something easy into something tricky.

In addition, at least for Solaris 11.1, due to its enhanced security by default or a simply a bug on its ypinit script, the rpc/bind SMF service isn't adjusted properly. As a side effect, the NIS master can't contact the NIS slave to push maps, although the NIS slave can still contact the NIS master to pull maps.

Start by installing (or verifying) the required NIS package (service/network/nis) which normally aren't installed by default:

nis-3# pkg install service/network/nis
...

Another pre-requisite for setting up a host as a NIS slave (beyond having an already running NIS master, of course) is setting it up as a NIS client in the first place. But before following the procedure to configure a NIS client be aware to take into consideration the following specifics:

Add all existing NIS servers to its /etc/host:
  • The NIS master (nis-1)
  • All other already active NIS slaves (nis-2)
 
nis-3# cat /etc/hosts
...
192.168.0.10  nis-1.business.corp  nis-1  # The NIS master 
192.168.0.11  nis-2.business.corp  nis-2  # Another NIS slave
192.168.0.12  nis-3.business.corp  nis-3  # This new NIS slave
...

After defining the (RPC) domain name as in NIS client configuration, when it's time to run the ypinit -c script, supply the new slave first, then the master, and finally all other already active slaves in order of proximity. It's required that all of them are properly declared in /etc/host before attempting the NIS client configuration.

nis-3# ypinit -c
...

At this point, restart both the nis/domain SMF service (so that its ypservers property gets properly updated) and the nis/client SMF service (most probably to catch the previous nis/domain SMF service updates as well).

nis-3# svcadm restart nis/domain
nis-3# svcadm restart nis/client

Make sure the NIS master is running and up to date and install the new slave, by running the ypinit -s <master> script, which among other things, will pull (ypxfr) all the existing maps from the master.

nis-3# ypinit -s nis-1

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] <ENTER>
  
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/business.corp
There will be no further questions. 
The remainder of the procedure should take a few minutes, 
to copy the data bases from nis-1.
Transferring mail.aliases...
Transferring netgroup...
Transferring netmasks.byaddr...
Transferring ypservers...
Transferring rpc.bynumber...
Transferring exec_attr...
Transferring networks.byname...
Transferring netid.byname...
Transferring protocols.byname...
Transferring auto.home...
Transferring ipnodes.byaddr...
Transferring group.byname...
Transferring ipnodes.byname...
Transferring publickey.byname...
Transferring prof_attr...
Transferring netgroup.byuser...
Transferring networks.byaddr...
Transferring services.byname...
Transferring netgroup.byhost...
Transferring ethers.byaddr...
Transferring ageing.byname...
Transferring hosts.byaddr...
Transferring passwd.byname...
Transferring mail.byaddr...
Transferring passwd.byuid...
Transferring auth_attr...
Transferring auto.master...
Transferring project.byname...
Transferring project.byprojid...
Transferring user_attr...
Transferring group.bygid...
Transferring protocols.bynumber...
Transferring ethers.byname...
Transferring services.byservicename...
Transferring hosts.byname...

nis-3's nis data base has been set up without any errors.

# svcs '*nis*'
STATE          STIME    FMRI
disabled       11:53:42 svc:/network/nis/update:default
disabled       11:53:43 svc:/network/nis/xfr:default
disabled       11:53:48 svc:/network/nis/passwd:default
online         11:47:25 svc:/network/nis/domain:default
online         11:48:10 svc:/network/nis/client:default
online         12:01:57 svc:/network/nis/server:default

Now restart the NIS client so that it'll bind to the local NIS slave:

nis-3# svcadm restart nis/client

Unfortunately, probably due to a bug in the ypinit script provoked by the out-of-the-box Solaris 11.1 security enhancements, the rpcbind remains secured to only operate locally. This impacts the ability of the NIS master to initiate map transfers (yppush) to the newly configured NIS slave.
The symptoms, now as perceived from the NIS master, are:

nis-1# /usr/lib/netsvc/yp/yppush <map>
Error talking to <slave>: rpcbind failure (how is down?)


nis-1# rpcinfo -s nis-3
rpcinfo: can't contact rpcbind: : RPC: Authentication error; why = Failed (unspecified error)


The fix is made on the new NIS slave server:

nis-3# svccfg -s rpc/bind

...>
listprop config/local_only
config/local_only          boolean     true

...>
setprop config/local_only = boolean: false

...>
listprop config/local_only
config/local_only          boolean     false


...>
select default

...>
refresh

...>
exit

If this host, nis-3, the new NIS slave being configured, haven't yet been configured during the NIS master (nis-1) setup, a routine occurrence, it's necessary to go back to NIS master and add the new NIS slave to its ypservers map, otherwise the NIS master won't know about the new NIS slave in case it's necessary to push updated maps:
Update the NIS master's /etc/hosts.
Include this new NIS slave (nis-3).

Verify that the new NIS slave (nis-3) isn't yet declared on the NIS master (nis-1):

nis-1# cd /var/yp/business.corp
nis-1# makedbm -u ypservers
YP_LAST_MODIFIED 1381844115

YP_MASTER_NAME nis-1

nis-2

nis-1
While still on /var/yp/business.corp, update ypservers:
nis-1# makedbm -u ypservers > /tmp/ypservers
nis-1# vim /tmp/ypservers
nis-1 # cat /tmp/ypservers

YP_LAST_MODIFIED 1381846000
YP_MASTER_NAME nis-1

nis-1

nis-2

nis-3

nis-1# makedbm /tmp/ypservers ypservers
Verify the update:
nis-1# makedbm -u ypservers
YP_LAST_MODIFIED 1381851334

YP_MASTER_NAME nis-1

nis-3
nis-2

nis-1
As a complementary measure it may be good to update the NIS master nis/domain SMF service accordingly:

nis-1# svccfg -s nis/domain listprop config/*
...
config/domainname   hostname    business.corp
config/ypservers    host        nis-1 nis-2
config/securenets   astring     "255.255.255.0  192.168.0.0"

...

nis-1# svccfg -s nis/domain
...> setprop config/ypservers = host: (nis-1 nis-2 nis-3)
...> select default
...> refresh
...> exit

nis-1# svcadm restart nis/domain
nis-1# svcadm restart nis/client
 
Verify what's done so far:
 
nis-1# ypcat -k ypservers
nis-3
nis-2
nis-1

Now go to each previously active NIS slaves (just nis-2 on these series of examples) and reference the new NIS slave (nis-3) as following:
Update the /etc/hosts.
Include this new NIS slave (nis-3).

Rerun the ypinit -c and rebuild the list specifying nis-3 accordingly. Remember, first the local NIS slave, then the NIS master, then all other NIS slaves (including nis-3) according to proximity.

Restart the nis/domain SMF service.

Pull the updated ypservers map with:

other-nis-slave# /usr/lib/netsvc/yp/ypxfr ypservers
other-nis-slave# ypcat -k ypservers
nis-3
nis-2
nis-1
Tough?
;-)
  
I also recommend implementing pam_list.
This will provide a finer access control to NIS servers and clients.