Tux Knows It's Nice to Share, Part 4
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.confin 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.confentry 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/hostsfile. For my test, I used the final example with this entry.
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.
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.
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.
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.
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
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”.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide