Tux Knows It's Nice to Share, Part 3
Welcome back, everyone, to another episode of the SysAdmin's Corner, where we discuss all things Linux, dig deep below the surface of our systems and really get to know the soul of the machine itself. <insert appropriate mood music here> When last we met on this very corner, we were mucking about with file sharing, specifically NFS. As you all noticed, NFS has some rather annoying problems when it comes to permissions. The most annoying thing about NFS is it assumes a user's name and UID on one machine matches exactly the user's name and UID on another machine, which means you either have to have matching password and group files on all your servers or, somehow, anonymous access is sufficient for all your needs.
The answer to this problem is NIS (well, one answer, anyhow). NIS allows us to share databases of critical system information across our network, information like users, groups, e-mail aliases and other things, without having to maintain that information on every server. Like NFS, NIS is a child of Sun Microsystems and, also like NFS, goes back to the 1980s. At that time, it was called Yellow Pages, but since Yellow Pages happens to be a registered trademark, the name was changed to avoid legal troubles. Nevertheless, the echoes of those YP days is still with us when we deal with NIS. As you will soon discover during this section, the letters "yp" show up in configuration files and commands alike.
Disclaimer v 1.0 : This is a big topic with both the server and client side to cover. Consequently, I am going to break this up into two sections. Next week, we will discuss client configuration. To make it up to you, I'll also give you the tools to completely automate the whole mounting and unmounting of remote systems routine.
NIS (and more recently, NIS+) does far more than allow these two files to be consistent across a network. Other files can be maintained as well. We can use the ypcat -x command to get a list of the databases already known or managed by your system. You need to have the portmapper running (as we discussed in part 1 of this series www.linuxjournal.com/article/4710). Try this command on your system:
[root@testsys /root]# ypcat -x Use "ethers" for map "ethers.byname" Use "aliases" for map "mail.aliases" Use "services" for map "services.byname" Use "protocols" for map "protocols.bynumber" Use "hosts" for map "hosts.byname" Use "networks" for map "networks.byaddr" Use "group" for map "group.byname" Use "passwd" for map "passwd.byname"
Now, you have an idea of just what kind of information you can use NIS to distribute, and there is even more, as you will see. Of particular interest to our discussion of permissions on NFS are the "group" and "password" databases. Remember, NFS expects a user on one machine will have the same UID on another. Short of always updating each and every server to reflect user and group name changes, NIS is the answer.
The first thing we need to get NIS rolling is a NIS domain name which bears no resemblance whatsoever to your internet domain name (although it could be the same if you so choose). Let's create a NIS domain name called mydomain.nis. On my Red Hat system, this is done by setting the NIS_DOMAIN variable in /etc/sysconfig/network, like this:
On a Debian system, the domain name is pulled from /etc/defaultdomain. In that case, add a single line with the NIS domain name and nothing else.
There's more to do, but before we can get there, we need to start the ypserver process. If you are running Red Hat, try this command:
Debian users need to edit their /etc/init.d/nis file first. Near the top of the file, you will find a line that reads NISSERVER=false. Change the "false" to "master". Now, start the ypserver with this command:
With NIS, you can set up backup servers as well. For now, we'll concentrate on the primary or the master. We've defined the domain name, so now we'll move on to defining what databases will be shared. This is done by modifying a file called /var/yp/Makefile. (It's starting to look an awful lot like we are compiling a program, isn't it?) Open the file in your favorite editor, and you'll see something like this:
GROUP = $(YPPWDDIR)/group PASSWD = $(YPPWDDIR)/passwd SHADOW = $(YPPWDDIR)/shadow GSHADOW = $(YPPWDDIR)/gshadow ADJUNCT = $(YPPWDDIR)/passwd.adjunct #ALIASES = $(YPSRCDIR)/aliases # aliases could be in /etc or /etc/mail ALIASES = /etc/aliases ETHERS = $(YPSRCDIR)/ethers # ethernet addresses (for rarpd) BOOTPARAMS = $(YPSRCDIR)/bootparams # for booting Sun boxes (bootparamd) HOSTS = $(YPSRCDIR)/hosts NETWORKS = $(YPSRCDIR)/networks PRINTCAP = $(YPSRCDIR)/printcap PROTOCOLS = $(YPSRCDIR)/protocols PUBLICKEYS = $(YPSRCDIR)/publickey
The list is fairly long, and it is possible to add others. Comment out what you don't need or want. What actually gets built is decided a little later in the file. Notice the YPPWDDIR variable. It is set earlier in the file and, by default, is /etc where most of these files live. Pay attention because this isn't always true. For instance, later incarnations of Sendmail put the aliases file in /etc/mail instead of /etc. Once you have the databases you want defined, look for this:
Since we are setting up a single master NIS server in this example, we set this to true. If we had secondary or "slave" servers, we would set this to false. Notice as well these two settings:
This is the default UID and GID information being served. As you might guess, there are security reasons for this. We don't want to advertise administrative IDs across our network. If you want to change this, do it here. If you are setting this up on a Debian system, you may find that these are already set to 100 instead of Red Hat's default of 500.
All right. Two more, very important settings before we get ready to wrap up our server configuration. Look for these two in the file.
In all likelihood, you are using a shadow password file; if you are not, go back and implement shadow passwords now. <Well, that was quick>. NIS will merge the information from your /etc/shadow file into its shared copy of /etc/passwd. This is normally set to true, but you can override this. The MERGE_GROUP setting defaults to false on some systems (my Debian test system is one), so you might wind up changing the setting of this one. Look for a /etc/gshadow file. If your system is using it, set this one to true as well.
Now, we are almost ready to build the new databases. The last thing we do is confirm what we want (or don't want) built. This is where you really decide what gets out the NIS door. Look for this text in the Makefile.
# If you don't want some of these maps built, feel free to comment # them out from this list. all: passwd group hosts rpc services netid protocols netgrp mail # shadow publickey # networks ethers bootparams printcap # amd.home auto.master auto.home passwd.adjunct
Once again, the settings as they exist are probably what you want, but you can set things like automount files (auto.master, etc.) which we'll talk about in greater detail next time around. But for now...
Ready? No, you don't type make.
The command that initializes all these databases is called ypinit.
[root@testsys /root]# /usr/lib/yp/ypinit -m The local host's domain name hasn't been set. Please set it.
What the heck is this all about? If you get this message, it isn't because your system hates you. It is likely that the domain name is in your boot time scripts. Next time the system comes up, you won't have to worry about this, as it will already be set. Since we don't want to reboot right now, let's manually set the domain name with this command.
Now, we run the ypinit command again.
[root@scigate /root]# /usr/lib/yp/ypinit -m At this point, we have to construct a list of the hosts which will run NIS servers. testsys.mydomain.nis is in the list of NIS server hosts. Please continue to add the names for the other hosts, one per line. When you are done with the list, type a <control D>. next host to add: testsys.domain.nis next host to add:
Unless you want to set up secondary servers at this point, just press Ctrl+D, and you are done. If you want to add servers, it's easy to do so after the fact. These get added into a file called /var/yp/ypservers. If you change to this directory, you'll see that this is a simple text file. When you are finished, the ypinit process will do a make for you and create the databases. You should see output like the following.
The current list of NIS servers looks like this: testsys.mydomain.nis Is this correct? [y/n: y] We need some minutes to build the databases... Building /var/yp/mydomain.nis/ypservers... Running /var/yp/Makefile... gmake: Entering directory `/var/yp/mydomain.nis' Updating passwd.byname... Updating passwd.byuid... Updating group.byname... Updating group.bygid... Updating hosts.byname... Updating hosts.byaddr... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating netid.byname... Updating protocols.bynumber... Updating protocols.byname... Updating mail.aliases... gmake: Leaving directory `/var/yp/mydomain.nis'
It is possible that when you run this the first time, it won't work quite so cleanly. The most likely scenario for a failure here is because you told Makefile to create databases that don't exist on your system. Pay attention to the messages, and edit the Makefile accordingly. Then, simply rerun the ypinit command. At this point, you can also just type make. (If you really, really want to.)
Yes, there is more, but I have filled my alloted space yet again. There is a lot to this whole process of sharing files and information, but in Linux networking, it's what we do. Like all good things in the Linux world, though, the hard work is up front. Once everything is done, you can pretty much book that trip to Europe, the Dominican Republic, or <insert your favorite holiday destination here>. So, it is here that I leave you. Until next time, remember what your Momma said, "It's nice to share."
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Nice article, thanks for the
5 hours 30 min ago
- I once had a better way I
11 hours 16 min ago
- Not only you I too assumed
11 hours 34 min ago
- another very interesting
13 hours 27 min ago
- Reply to comment | Linux Journal
15 hours 20 min ago
- Reply to comment | Linux Journal
22 hours 14 min ago
- Reply to comment | Linux Journal
22 hours 30 min ago
- Favorite (and easily brute-forced) pw's
1 day 22 min ago
- Have you tried Boxen? It's a
1 day 6 hours ago
- seo services in india
1 day 10 hours ago