Last time around, we went through the process of setting up a NIS server. Although it's great that we've done the job of setting up the NIS server, it isn't much good without clients. Luckily, clients are fairly simple, so feel free to set up lots of them. On the client system, start by opening the file

/etc/yp.conf

in your favorite editor (go ahead, I dare you). There are three possible ways of setting up the client to look for NIS servers.

     domain NISDOMAIN server HOSTNAME
     #       Use server HOSTNAME for the domain NISDOMAIN.

If you choose this method, then specify the NISDOMAIN and the HOSTNAME to which you would like the client to connect. You can have more than one such entry. Using my example of domain.nis, my

yp.conf

entry would look like this.

     domain mydomain.nis server testsys.mydomain.dom

You can also set up your client to listen for NIS servers via a broadcast. The only catch here is the servers must be on the same subnet. You can not listen for NIS servers outside your network.

     domain NISDOMAIN broadcast
     #       Use  broadcast  on  the local net for domain NISDOMAIN

Once again, you replace NISDOMAIN with the NIS domain name. The advantage of this method is you only need to configure one entry, and you are done. The final option is perhaps the easiest of the bunch, in terms of flexibility.

     ypserver HOSTNAME
     #       Use server HOSTNAME for the  local  domain.

Type the hostname of the NIS server, and that's it. If you are going to use this approach, however, you had better make sure the HOSTNAME is listed in

/etc/hosts

file. For my test, I used the final example with this entry.

     ypserver testsys

One last file needs editing, and we are finished. This one is called /etc/nsswitch.conf and while there is a lot more stuff here than in yp.conf, the format is no more difficult. Basically, you have a list of file names and one or more service options associated with each one. Here's a sample from my file which is basically the stock configuration from a Red Hat system.

     passwd:     files nisplus nis
     shadow:     files nisplus nis
     group:      files nisplus nis

     #hosts:     db files nisplus nis dns
     hosts:      files nisplus nis dns

The service options are files, nis (or yp - both are the same), nisplus, dns and [NOTFOUND=return]. Okay, here's a bit more detail. The files options means we should use the local files to look up information. On the other hand, nis (or yp) tells the system to use NIS for the information. Then, we have nisplus (use NIS+), dns (use the DNS to find the information : note that this only applies to the hosts file) and, finally, [NOTFOUND=return] which means “if you haven't found the information, stop searching”.

Of course, each file has several options listed which can only mean the order is somehow important. This is the search order for information retrieval: you almost always want to search your local host first, so files is usually the first option. It is only when you don't find the information locally that you want to look elsewhere, but even that can be changed.

Let's test things, shall we? First things first. As with the server, you need to have the NIS domain name set. You still want the information hard-coded in the appropriate configuration files, but a quick way to set it (if you haven't already) is with the domainname command. Now, remember, we are working on the client this time.

     domainname mydomain.nis

Cool! Now, we need to start yppasswdd (to allow for password changes on the NIS server) and the NIS listener, ypbind. With Debian, this is the /etc/init.d/nis start script. With Red Hat, you'll need to start /etc/rc.d/init.d/yppasswdd and /etc/rc.d/init.d/ypbind as well.

You can just feel the tension, can't you? To see the contents of the NIS server's password file, try this command.

     ypcat passwd

I won't bore you with the contents of my central password file <insert appropriate evil grin here>. Suffice to say that if you did everything right, you should see the contents of the password file. Notice, however, only the entries after the MINUID you set last time around (see the last column on setting up the NIS server www.linuxjournal.com/article/5299) are actually visible.

Let's try another. To get the host information, do this.

     ypcat hosts

The format is simple. You are simply specifying the name of the file served by NIS services.

I am going to leave NIS for now. There are still a couple more things on this topic I want to talk about, but for now, we'll do something else. In order to address that something else, I need to ask you all a few questions.

Are you feeling tired? Listless? Has the constant flow of life-giving caffeine stopped having the desired effect? Do you find yourself absendmindedly saying “sure, I'll mount that file system for you” whenever someone walks into your office? Are you constantly trying to remember whether you've set up shares to this directory or that one? Is your network getting bogged down by hundreds of unnecessary NFS (or SAMBA) mounts that you only use occasionally, but can't bear the thought of mounting and unmounting every time you need them? If you've answered “yes” to any of these questions, then I may have something to help you.

If you start using NFS in a big way, you may find this whole business of mounting and unmounting file systems gets to be a bit tedious. You could just put the various mounts in your /etc/fstab (as we talked about in the first part of this series www.linuxjournal.com/article/4710) and have them come up automatically, but that has its problems as well. What if that system is not always available? It may also be that you only need this file system from time to time. If this is the case, you don't want to have it permanently mounted. Then again, when somebody does need it, do you really want them to disturb you?

The Linux command autofs can make your life a lot easier. The idea is you define file systems for mounting in a file called a map file. This map describes the file system types, where they are and what permissions may be required to mount them. The beauty is you don't have to manually mount these file systems or even have them mounted at all. As soon as a user requests something in the map path, that file system is automatically mounted. Does it sound too good to be true? Fear not. It's all real.

To use this tool, you will need to have the autofs package loaded on your system. You will find it is probably already on your distribution CD. Alternatively, you can go to the ftp.kernel.org web site and look in the /pub/linux/daemons/autofs directory for the latest and greatest.

Setup is easy. Start by setting up your /etc/auto.master file. The format is as follows. You define a top level directory where your automatic mounts occur. This points back to another file (your map) which takes care of individually defining these mounts and their file system types. Here's my auto.master file now.

     /automnt\t\t/etc/auto.automnt

You can have many such definitions. For instance, you might have mount points defined under /misc, /home or the perennial /mnt. The convention is to use a /etc/auto.map file where "map" is the same name as the mount point. You can use pretty much any name you like, however, and it will still work. Now, let's have a look at the map I have defined.

     # automount locations
     # This is an automounter map and it has the following format
     # key [ -mount-options-separated-by-comma ] location

     # nfs servers
     testsysdata        -fstype=nfs,rsize=8192,wsize=8192          testsys:/data1
     testsysroot        -fstype=nfs,rsize=8192,wsize=8192          testsys:/

     # samba servers
     testsysdos\t\t-fstype=smb,username=marcel,password=secret\t://testsys/dosdir
     winsoft\t\t-fstype=smb\t\t://nexus/win95

     # Windows PCs
     natika_c\t\t-fstype=smb,username=natika,password=secret         ://speedy/natika_c

Notice I have listed Samba file systems (which I haven't talked about yet) and a Windows PC as well. The Linux autofs can handle many different systems; it's not just for NFS. Before we can start using things, though, we need to start (or restart) the autofs process. On my test system running Red Hat, I start it from a script

     /etc/rc.d/init.d/autofs start

On a Debian system, the script will likely be in /etc/init.d instead, but it will use the same keyword to start the automounter. By the way, the program that actually does the work is called automount so if you look for the program in a “ps ax”, you'll see that program name instead of autofs, which is just the package name.

To access information on any of these systems, I only need to change the directory or reference a file there. The autofs system will do the rest for me.

     cd /automnt/natika_c
     ls

Voila! Miraculously, I can see the entire contents of Natika's C drive!

Well, that wraps up another week for your humble geek and narrator. Until next we meet on this most sunny of corners, remember what your Momma said, “It's nice to share”.