InformIT: Mac OS X Unleashed > Multiple Users and Multiple Machines: Creating Clusters

Table of Contents

Multiple Users and Multiple Machines: Creating Clusters

Since almost the dawn of computing, the Unix operating system has supported the notion of a cooperating group of machines that share user information between them. The concept of clustering includes the idea that the machines should share not only information, but also sufficient resources so that any user with an account on the cluster can use any machine in the cluster, and the experience will be indistinguishable from using any other machine.

The user information traditionally is shared among the machines in the cluster by using a technology known as NIS (the Network Information System, originally known as the Yellow Pages) that was developed by Sun Microsystems. File systems (containing user accounts and software) are shared to members of the cluster using NFS (the Network File System). NFS is still the preferred way of sharing file systems under OS X, but Apple has provided a slightly more complex, and considerably more powerful, method of sharing user information: the NetInfo system. Not only is the information in NetInfo databases used for configuration of your own machine, but if you choose, this information can be shared to other machines.

As you might guess from what you know of Unix abstraction by now, a machine shouldn't really care whether its NetInfo configuration information comes from its local NetInfo server, or from another NetInfo server that it's talking to over the network. As a matter of fact, a hierarchy of NetInfo servers can be linked together to provide a significant level of sophistication in the distribution of user information.

Creating and managing many-level NetInfo hierarchies is a topic best left for Mac OS X Server, but the creation of a two-level hierarchy is something that can be reasonably done with OS X.

The normal two-level hierarchy includes a local NetInfo domain, and a parent NetInfo domain that is delivered via the network. Each machine that participates in the cluster subscribes to the parent NetInfo domain. (This includes the machine that runs the parent server as well; it subscribes via the network to a domain that it serves via the network. Don't worry, these things will make sense eventually.) Any users defined in the parent domain can use any of the machines that subscribe to the domain. Users that are defined in the local domain on any machine can use the machine on which they are defined, but do not have access to any other machines in the cluster.

Subscribing to a NetInfo Parent Domain

If you would like your machine to participate in a cluster, there are two options for participation: Your machine can either subscribe to a parent NetInfo domain or it can be the provider of the domain. Because subscribing to a domain is necessary in both cases, we'll cover subscription to a domain supplied by another machine first.

For a technique that provides such a powerful method of integrating machines and user accounts, joining a cluster implemented through the NetInfo service is surprisingly easy. There are essentially only two things that you need to do. First, you need to mount the file systems from the remote machine so that users' home directories appear on your machine in the same places that they are defined to be in the NetInfo domain to which you will be subscribing.

Second, subscribe to a parent NetInfo domain using the Directory Setup utility.

The first of these tasks you've already learned how to do in the previous chapter. For this example, we will assume that users who are intended to be cluster users, with the ability to log in on any of the machines in the cluster, have home directories defined to exist in the directory /netusers. Therefore, if we want to be able to log in on our machine as one of the users defined in the parent NetInfo database, we need to mount the remote directory on the server (192.168.1.16 in this case) named /netusers as a local directory /netusers. This will allow logins to user accounts listed in the localhost/local NetInfo database, as well as to accounts listed in the remote 192.168.1.16/network database. The following listing shows the mounts entry for the machine that is subscribing to the NetInfo cluster:

[kimagure:~/] ray% nidump -r /mounts -t localhost/local

     {
       "name" = ( "mounts" );
       CHILDREN = (
         {
           "vfstype" = ( "nfs" );
           "dir" = ( "/mnt" );
           "name" = ( "venice.iwaynet.net:/home" );
           "opts" = ( "-i", "net", "-P", "-b", "ro" );
         } ,
         {
           "vfstype" = ( "nfs" );
           "dir" = ( "/netusers" );
           "name" = ( "192.168.1.16:/netusers" );
           "opts" = ( "-b", "-s", "-P" );
         }
       )
     }

Note that it is mounting the /netusers directory to participate in the cluster, as well as another directory from an entirely different machine. NFS can be used to create arbitrarily complex networks of interconnected file systems.

Satisfying the second requirement involves only opening the Directory Setup utility, and entering the machine name or IP address and the NetInfo directory to which to subscribe. For a machine subscribing to the network database, served by 192.168.1.16, this is shown in Figures 24.1 and 24.2.

Figure 24.1 To subscribe to a parent NetInfo domain, open the Directory Setup utility, enable changes, and check the NetInfo box. Then click the Configure button.

Figure 24.2 Subscribing to the parent network NetInfo database, served from a machine at IP address 192.168.1.16. This dialog is reached by clicking Configure as shown in the previous figure.

The network NetInfo database, to which our machine's NetInfo database is now parented in this example contains the following users;

[kimagure:~] ray% niutil -list -t 192.168.1.16/network /users
     3        root
     4        skel
     5        bellchan

Figures 24.3 and 24.4 show the same user, bellchan, logged in to 192.168.1.16 and 192.168.1.105. 192.168.1.16 is the server of the NetInfo network domain, and 192.168.1.105 is subscribed to this as a child of the network domain. If you look closely at the figures, you won't see much of a difference—and that is exactly the point. The bellchan user has its home directory in the /netusers directory on 192.168.1.16, and this directory is mounted in the same location on 192.168.1.105. All of bellchan's user information is served via NetInfo and subscribed to by 192.168.1.105. So, due to Unix abstraction and the power of clustering, there is no difference to the user (other than possible network performance issues) between sitting down in front of either of these machines.

Figure 24.3 The user bellchan logged into 192.168.1.16 (locally named racer-x) at the console. bellchan's account physically resides on this machine, as does the network NetInfo database.

Figure 24.4 The user bellchan logged into 192.168.1.105 (locally named kimagure) at the console. bellchan's account physically resides on another machine, and is coming to this machine via the power of NetInfo, NFS, and the notion of Unix clustering.

Parenting a NetInfo Domain to Other Machines

If you would like to set up your machine to be the server of a NetInfo parent domain to which other machines can subscribe, the process is also straightforward. There are three requirements. First, as you should realize from the previous example, for users who exist in the parent domain to be useable on machines that are clients to the domain, their home directories (or, more usefully, the directory containing all their home directories) must be made available to the client machines.

Next, your machine must be set up to serve a NetInfo directory to the network, and users must exist in it.

Finally, your machine must be subscribed to the network NetInfo server that it serves, so that your local NetInfo database is a child of the network NetInfo database.

After these requirements are met, others can subscribe as children of your network-served network NetInfo database by following the directions given in the section "Subscribing to a NetInfo Parent Domain" earlier in this chapter.

Caution

It isn't particularly useful to parent a domain with a machine that switches "locations" frequently. It is difficult to configure the machine to properly parent and not parent the domain when desired. Also, if you're providing domain parenting information to other machines, it's rude to yank their parent domain away when you take the machine down to move it. For this reason, we recommend parenting NetInfo domains only from machines with fixed IP addresses and that are generally intended to be always on.

To configure the server similarly to the one on 192.168.1.16 that was used in the previous example, the following steps need to be taken:

The directory /netusers needs to be created, owner set to root, and group set to wheel, just as the /Users directory is set.

The directory /netusers needs to be exported via NFS. The following listing shows the NetInfo exports entry used:

[localhost:~/Documents] ray% nidump -r /exports -t localhost/local
{
  "name" = ( "exports" );
  CHILDREN = (
    {
      "clients" = ( );
      "name" = ( "/netusers" );
      "opts" = ( "maproot=root", "network=192.168.1.0", "mask=255.255.255.0" );
    }
  )
}

A new master NetInfo server needs to be created on your server machine (ours was 192.168.1.16). To do this, simply go to the NetInfo Manager, enable modifications to the localhost/local domain, select Manage Domains from the Domain menu, and Hierarchy under that. In the dialog box that appears, choose Create a new master server on this host. A new master server serving a domain named network will be created by default.
Choose the newly created NetInfo network domain as a parent domain. To do this, follow the instructions in the prior example for selecting a parent domain. You will use the Directory Setup utility to enable parenting to a NetInfo domain, and provide your IP address and network as the domain to use as a parent.
Rebooting the machine at this point is probably a wise choice. If the network domain was not correctly created, or your NetInfo service doesn't want to connect to it as a parent domain, you'll need to delete the domain and try again. Unfortunately, this step seems a little hit or miss at the moment. What appears to be a bug or three in the NetInfo server occasionally results in it dying, instead of accepting the changes. The symptom is that the colorful spinning wait cursor appears for the NetInfo Manager, and never returns to a pointer cursor. In this case, Force-Quit the NetInfo Manager, restore your NetInfo database from a backup (as discussed in Chapter 23), and reboot your machine).
If everything goes well, your machine will reboot cleanly, and you will be able to log in. Verify that your local NetInfo domain is now a child of the network domain by opening the local domain on localhost from the NetInfo Ma n ager, and then clicking the Open Parent Domain button (world with up-pointing arrow). The network domain you created earlier should open.
Create some users in the network domain by duplicating the root user and changing the user's information as appropriate. For the example given earlier, we created the skel skeleton account so that we could use it to create other customized users, and then used it as shown in previous examples in this chapter to create the bellchan account. If you're going to create the account using the nidump, niutil, and niload command-line tools, remember that you're not inserting users into localhost/local, but instead into <yourip> /network.
Log out, and try to log in at your console as one of your users from the network domain. If you're successful, you've completed the basic configuration of your machine as a NetInfo and NFS server to provide cluster information to other machines. Other machines can now mount your exported directories, and subscribe to your NetInfo network domain, as shown in the previous example.

If you aren't successful, check the user information that you've created in the network domain carefully to make certain that you haven't overlapped any UIDs or usernames with users that exist in your local domain. Also, check that things you've specified, such as the home directories, really exist. If your NetInfo Manager shows that your local domain is a child of the ne t work domain (by being able to open the network domain as its parent), you're 99% of the way there, and the problem must be in the user account information itself.

Command-Line Administration Tools | Next Section

Previous Section