This little article will try to make sense of the jungle that is NFS and NIS. For our example we will use NFS for keeping /home on a server, allowing us to work on the same files in our homedir from any computer in the network.
NIS (Network Information Service) is a directory system which is used to centralise configuration files like /etc/hosts and /etc/passwd. By using NIS for passwd, you can have the same users on each host in the network without the hassle of keeping the passwd file of all hosts synchronised.
We will need NIS (or another directory service) to make sure the NFS user ids/group ids are the same on the server as on all clients. Otherwise, bad things will happen, as you can probably imagine (especially in our example of mounting /home over NFS). Note that using NIS with NFS is not mandatory, you can also keep the server and client's passwd in synch.
NIS used to be called the "Yellow Pages", or YP for short. Because of trademarks it had to be renamed, but the programs are all still prefixed with `yp`.
# Kernel options
Before doing anything with NFS, ensure that your kernel has support for NFS sharing. This means your clients and servers must have NFS kernel support enabled. This is the case for GENERIC Kernels. For custom Kernels, the following lines must be in the kernel file:
file-system NFS # Network File System client
Your server also must have the following option:
options NFSSERVER # Network File System server
If you want to get funky and boot from NFS (not discussed in this article), your clients need these options as well:
# Creating a NIS setup
The first thing we should do is decide on a NIS domain name. This has nothing to do with your machine's Internet domain name. It is just a unique name that is used to identify machines in the same NIS block.
The domainname is set (as root) using the [[!template id=man name="domainname" section="1"]] program, or can be set in the /etc/mydomain file.
Alternatively, in most BSD systems, it can be set in /etc/rc.conf under the variable `domainname`.
root@earth# domainname planets
After this, we must initialise all files needed for the server to do its work. For this, we use the ypinit utility.
root@earth# ypinit -m
The -m means we are creating a master server. On more complex networks, you can even want slave servers. The tool will ask you for a list of YP servers to bind to.
Since we're only using one server, just press RETURN (make sure your own server's internal address is in the list).
Before we run `make` in /var/yp, as the tool says, we must enable the NIS daemons: rpcbind, ypserv and ypbind (in that order). After that, we can run `make` in /var/yp.
To test if your setup is working, try yptest. It should spew out the passwd file among others, so don't panic ;)
To get stuff working on your client, you need to enable the yppasswdd, rpcbind and ypbind daemons as well. In order to do that, edit the /etc/rc.conf file and add there following:
Then just run
# /etc/rc.d/rpcbind start
# /etc/rc.d/ypserv start
# /etc/rc.d/ypbind start
# /etc/rc.d/yppasswdd start
[[!template id=man name="rpc.yppasswdd" section="8"]] must be running on the NIS master server to allow users to change information in the password file.
[[!template id=man name="ypserv" section="8"]] provides information from NIS maps to the NIS clients on the network.
[[!template id=man name="ypbind" section="8"]] finds the server for a particular NIS domain and stores information about it in a "binding file".
After that, you can use ypinit:
root@mars# ypinit -c
Then, add your NIS server's address to the list. To test if everything is working, use yptest on the client as well. **Note that ypbind will HANG if it can't find the server!**
If everything is working, you are ready to go! Just edit /etc/nsswitch.conf and put in some `nis` keywords. For example:
passwd: files nis
would first look up usernames/passwords/uids in /etc/passwd, and if it can't find it, it would look it up using NIS. Right after changing this file, you should be able to log in on your system using a username which is only in /etc/passwd on the server. That's all there is to it.
# The daemons
What are all those daemons for? Well, here's a quick rundown:
Portmap/rpcbind is the program which maps RPC (Remote Procedure Call) program numbers to port numbers (hence, portmapper). Any program which wishes to know on what port a certain RPC program is listening can ask this from the portmapper daemon (rpcbind). Each RPC service has its own number, which can be looked up in /etc/rpc. These numbers are how rpcbind can match the running RPC services to the ports. In short: If rpcbind is not running, not a single RPC program will work.
Ypserv is an authentication daemon for the RPC services, I believe. Ypbind is the daemon which can find the YP server for the specified domain.
Setting up NFS is a piece of cake. Just enter all directories you wish to export in /etc/exports and start the NFS daemon. In our example we would have:
/home -network 192.168.0.0 -mask 255.255.0.0 -maproot=root
This exports /home only on the LAN 192.168.x.x. The maproot line is needed, because otherwise the client's root will not have superuser access. Now, start the mount daemon and the NFS daemons (mountd and nfsd) as root on your server, in that order. For that type:
root@mars# /etc/rc.d/rpcbind onestart
root@mars# /etc/rc.d/mountd onestart
root@mars# /etc/rc.d/nfsd onestart
root@mars# /etc/rc.d/nfslocking onestart
If you wish to start the NFS server on boot, add following lines to your /etc/rc.conf
Now, try to mount from the client and type:
root@mars # mount -t nfs earth:/home /home
Voila, you're done. Just add all NFS volumes you want to mount to your /etc/fstab like this
earth:/home /home nfs rw
and have them mounted at system startup.
NOTE: I had much trouble with NFS which was caused by UDP packet fragmentation. This made all writes extremely slow (and other outgoing network traffic as well!) while reads were at an acceptable speed. To solve this, I added the (undocumented?) `tcp` option to fstab to mount NFS over TCP. You'll probably also need to add
to rc.conf so the NFS server serves up TCP exports.
If you just want to run NFS, you need to run the following daemons on your server: rpcbind, mountd, nfsd (in that order)
# Concerning NFS
If you find NFS is not suitable for you, you could try Coda. The Coda filesystem tries to overcome some of the drawbacks of NFS:
* Handling of (sudden) disconnections
* Its own authentication system
And some others. The latest NFS versions are of course trying to integrate some of Coda's features as well.
# Concerning NIS
A disadvantage of NIS is that it is not very secure. If security is a big concern, have a look at LDAP and NIS+, which are more complex directory services. For networks where security isn't that important (like most home networks), NIS will do. It is also much easier to set up than NIS+ or LDAP.
On NetBSD (probably on other systems as well), the NIS server consults /etc/hosts.allow and /etc/hosts.deny (from Wietse Venema's tcpwrappers package) to determine if the requesting host is allowed to access the NIS directory. This can help you in securing NIS a little.
My /etc/hosts.deny looks like this:
In my /etc/hosts.allow I have my LAN hosts.
* O'Reilly's Managing NFS and NIS, 2nd Edition
* [Linux NFS howto](http://nfs.sourceforge.net/nfs-howto)
* [The CODA project](http://www.coda.cs.cmu.edu/)
* [The good old NetBSD Guide](http://www.netbsd.org/Documentation/#Guide)
* [Replacing NIS with Kerberos and LDAP howto](http://www.ofb.net/~jheiss/krbldap/howto.html)
# See also
* [[!template id=man name="mount_nfs" section="8"]] manpage
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb