Tux Knows It's Nice to Share, Part 3

Let me look that up for you. 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.
Let me look that up for you.

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:


   NIS_DOMAIN=mydomain.nis

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:


   /etc/rc.d/init.d/ypserv start

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:


   /etc/init.d/nis start

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:


   NOPUSH=true

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:


   MINUID=500
   MINGID=500

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.


   MERGE_PASSWD=true
   MERGE_GROUP=true

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.


   domainname mydomain.nis

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 &lt;control D&gt;.

            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[1]: 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[1]: 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."

______________________

Comments

Comment viewing options

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

Part 3

jack's picture

Where is the rest of this article?

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