Centralized management with Unix workstations and servers is hard to accomplish. At least, it was. Using NIS is a step closer towards some ordering in the chaos that can emerge from a crowded LAN.

NIS

NIS? What is that? NIS is a product developed by Sun Microsystems, and the acronym stands for Network Information Service. Well, it is the new name Sun gave it as it was formerly know as Yellow Pages (YP), but YP is trademarked but British Telecom, so the name had to be changed.

What can NIS do?

NIS allows a networked environment of Unix boxen to share common authentication files, such as /etc/group, the password file on your version of Unix (in the case of FreeBSD: /etc/passwd) and a lot of other files.

NIS is an extremely handy solution in a large networked environment in which a lot of users need to be able to log in on every available station without having to worry about whether or not the user has an account on that workstation.

The above example works even better in conjunction with the Network File System, since this allows the user to be able to use his home directory wherever he logs in.

Requisites for NIS

NIS, as may be obvious from the name, at least needs to have a working network environment (which could also be the Internet) to make effective use of it.

Furthermore, since you, the reader, obviously read this because you are curious about how to set it up on your own systems I will assume that I should not have to dwell too long on the subjects of basic IP networking rules.

I cannot stress it enough, but I will say it again, define a policy on what rights certain type of users get. This is one of the most underestimated things in administration. Whatever damage done to your system(s) by individuals able to acquire root privilege will always be the responsibility of the administrators. Therefore, know what you are dealing with by playing with it in a test environment before implementing it at large since NIS was/is known for having security flaws (which has been compensated a lot for by NIS+).

The security policy settled, we need to know something very important; which server will be the master server? Make sure this server can handle the requests send against it.

Another important thing to think about is name giving of the servers and the domain. The easiest way to do this is using the same names as those in use by DNS (provided one uses DNS of course). The NIS domain name should be identical to the DNS domain name, but isn't required to (but will surely save you a lot of administrative headaches in the future).

Setting up the Master Server

Obviously, since NIS is a centralized approach towards administration we need start our configuration on the master server. I will assume that you have installed a very normal FreeBSD box, nothing fancy.

On that server, verify that we have not yet set a NIS domain name by simply typing:

	$ domainname
  

If the server has no domain name it will echo a blank line and then the command prompt again.

If we want to set a domain name we would su to root and type something like this:

	# domainname foo
  

Typing domainname again on a new line will now echo the domain name back to us:

	$ domainname
	foo
  

NOTE: this will only set up the domain name for as long as the server is up. If you want to make the domain name a permanent addition to the server start-up do the following as root:

	# vi /etc/rc.conf
    
	[ Look for the `nisdomain' line in that file, it's probably
	set to NO, then change it to the domain name for your NIS
	domain ]
    
	nisdomainname="foo"     # Set to NIS domain if using NIS (or NO).
  

Then save the file.

The above steps took care of the NIS domain name, but of course there's more to do to the server before it's truly a master. We are currently settling on only one NIS server, so we won't need to enable pushing (of the server data to slave servers). But regardless of the servers involved, we are required to create a file called ypservers in /var/yp to let the system know which hosts are NIS servers. This file needs to know about the servers, so we simply create a file in /var/yp called ypservers in which we place the hostnames of the servers involved. We now need to initialize some files for the domain. We need to copy the master.passwd to /var/yp and then get rid of any administrator accounts such as root and toor or any other UID 0 users. Then we run a make in /var/yp:

	# cd /var/yp
	# vi ypservers

	[ add server(s) and save ]

	# cp -p /etc/master.passwd .

	# ls -alsoF
	total 20
	1 drwxr-xr-x   2 root  wheel  -   512 Feb 15 02:29 ./
	1 drwxr-xr-x  19 root  wheel  -   512 Dec 30 23:18 ../
	18 -r--r--r--   1 root  wheel  - 18126 Feb 15 02:29 Makefile.dist
	2 -rw-------   1 root  wheel  -  1237 Feb 16 21:38 master.passwd
	0 -rw-r--r--   1 root  wheel  -     0 Feb 16 20:41 ypservers

	# cp -p Makefile.dist Makefile
	# make

	[ this will make the current domain, if you need to make
	another domain, use make target domainname ]

  NOTE: it will generate some errors with regard to ypserv not being
  active.  This can be solved by running ypserv as root before starting
  the make.
  

If we would look at the directory structure right now we would see that the make process has created a passwd file and a directory with the domain name.

So now that we got the maps set up in /var/yp we need to enable lookups to work in the domain. This is done by editing /etc/host.conf and removing the # which precedes the nis entry.

Now for the clients and the slave servers to be able to be looked up we would need entries for them in either DNS or /etc/hosts. Basically in my opinion if one uses DNS why bother with /etc/hosts, it will only mean double administration.

To be sure that NIS is started every time we have to reboot the machine for whatever reason we have to edit /etc/rc.conf a final time. In rc.conf there is a special section titled Network Information Services (NIS), we need to edit this section.

This is the line that primarily concerns us (since we have already set the NIS domain earlier on):

	nis_server_enable="NO"  # We're an NIS server (or NO).
  

We need to change this to:

	nis_server_enable="YES" # We're an NIS server (or NO).
  

Since we have copied and edited master.passwd in /var/yp we also want to enable yppasswdd and set the flag to point to the /var/yp/master.passwd file instead of the original master.passwd file. In our case:

	nis_yppasswdd_enable="NO"       # Run rpc.yppasswdd at boot time (or NO).
	nis_yppasswdd_flags=""          # Flags to rpc.yppasswdd (if enabled).
  

We are going to change this to:

	nis_yppasswdd_enable="YES"      # Run rpc.yppasswdd at boot time (or NO). 
	nis_yppasswdd_flags="-t /var/yp/master.passwd"  # Flags to rpc.yppasswdd (if enabled).

	[ NOTE: for more verbose logging put -v in the yppasswdd flags ]
  

The reason I use /var/yp/master.passwd and not the /etc/master.passwd is because I have deleted all the UID 0 and other important accounts that could be used for compromises.

Another thing to address, since we are a single master server we have no need to fill in the ypxfrd lines since these are only used for transferring maps to the slave servers.

At this point we might want to reboot to see if all has been well. Please be patient at boot-up as my P166-MMX took 2.5 minutes before it was done.

Client Side Installation of NIS

So we made it through the server part, now we want to be able to use the master as well as a client and we want a host to use the NIS domain as well.

Most of the client-side configuration takes place in /etc/rc.conf.

The first is the obvious one, namely nisdomainname, this must be set to the domain which it will primarily use.

	nisdomainname="foo"	# Set to NIS domain if using NIS (or NO).
  

Next we need to enable the ypbind daemon to make sure the host will be a NIS client.

	nis_client_enable="YES" # We're an NIS client (or NO).
	nis_client_flags=""     # Flags to ypbind (if enabled).
  

If we don't provide client flags the client will use the nisdomainname and will send out a broadcast for a server that serves that domain. This might be considered a security hole since anyone can configure a server to respond to the NIS domain being broadcast. If this is deemed insecure by you then I suggest you take a look at man ypbind and especially it's -S flag. If we would apply it here we would get something like this:

	nis_client_flags="-S foo,server1,server2" # Flags to ypbind (if enabled).

	[ NOTE: the server names have to be able to resolve to IP 
	addresses, either by /etc/hosts or else DNS ]
  

Next thing to do on the client would be to edit master.passwd, group and some other file to enable NIS to use them.

/etc/group

Delete groups which are not system critical like games and append +::: at the end of the file (this will signify to use NIS).

/etc/master.passwd and passwd

Use vipw to delete all users not needed for system operation, such as UIDs starting at 1000 and onwards, user games, etc. Append a +::::::::: to the end of the file to enable NIS. If one combines NIS with NFS this will mean that whatever the host on which the user logs in, he always has his home directory.

/etc/host.conf

The order of the lookups, I myself use bind, then nis, then hosts on the clients. Some people prefer to swap hosts and bind. This is something that reflects your own personal choices. I just know my DNS servers work =)

	[ NOTE: with bind at the top, ypwhich should return the
	complete DNS host and domain name ]
  

/etc/hosts

Add the necessary entries such as the NIS servers, and append a +:: to enable NIS.

You can now either reboot or just do a domainname followed by ypbind as root to enable NIS. Now try to login on that client host with a user name not present locally, but which you know exists on the NIS server.

Another test would be to use ypmatch like this:

	ypmatch user master.passwd
  

This will search the NIS password file for the user and print the relevant information.

You now have a working NIS domain structure. If you find any errors in the text above please do not hesitate to mail me, but be sure to have tested it thoroughly first and have read the text and understood it.

Thanks go to John Kenagy for his NIS document and help on freebsd-questions as well as Ted Wisniewski's document from which I learned a lot to set up NIS.

Jeroen

Return to Issue #3