Tux Knows It's Nice to Share, Part 4

NIS II: The Client Demands its Due — What do you think? Will a title like that get them through the doors at your local mega-theatre-plex if we flash it on a big marquee? How about Harried Admin meets Savvy Automount? Probably not (in either case), but it's my way of introducing another installment of the SysAdmin's Corner

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”.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

this article

Jason's picture

ok, how long until this gets done? I could really use the info here.

Found it!

Tom B's picture

how to startup vcdj

Anonymous's picture

i hope to get the answer from your article as it is promised in an other on.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState