Bring on the Clones: Cloning your NetInfo Database 
6 March 2003
Now that you know a bit more about NetInfo you may be worried about what happens when your parent NetInfo server goes down—a valid concern. Luckily, NetInfo has the capacity to clone itself. Not only does this allow your clients to continue authenticating correctly, but you can also load-share the database for greater efficiency. This is especially helpful across subnets connected by low-speed connections.
Before we get started I need to mention a couple of things. Most of this information comes from various places. Apple has a good PDF on how NetInfo works. Also: Google is your friend here. Additionally, Apple’s Mac OS X Server mailing list has a lot of good information. The information in this article has been taken from all of these sources, in addition to personal experience. If you have any additional info, or find any errors here, please let us know. Also: many thanks to Aaron LaBeau for giving me some ideas on this and working through it in 10.2.
A bit of background on NetInfo. Traditionally, the top level of a NetInfo domain has been called “network.” In a standard setup this is referenced in Workgroup Manager as “/netinfo/root” since it is the “root” or base of the NetInfo hierarchy. We’re going to give our examples using this same setup.
Now some info on clones. A master, the original NetInfo database, can have multiple clones. A master and its clone cannot be hosted on the same machine. However, a machine can host its own master and a clone for another database at the same time. A master pushes changes onto the clones only when changes are made, keeping network traffic low. Clones are only able to be written to by the master, so when the master goes down a clone can handle authentication and other services but users will not be able to change their passwords or other information.
A properly configured network will allow the master and clone to load share. For example, your file server can be a clone of your authentication server. Incoming connection requests to the file server will first be authenticated out of the cloned database, saving the master for network logins or other uses. Also client machines can be configured to automatically connect to a clone if the master cannot be found or is slow to respond. For this to work the clone has to have the same “tag” or database name as the master. In our case this name is “network."
You can clone a master and give the clone a different tag from the master. This will create a backup-only copy of the database. Clients will not fall back on it if the master goes down.
Clients can bind, or connect, to a NetInfo parent in numerous ways—all of which are setup using the Directory Access application. If more than one option is chosen the client will bind from most specific to least specific. So a static bind is attempted first, then dynamic then broadcast.
Broadcast binding is similar to how DHCP works but specific to NetInfo. The client will send out a broadcast request looking for a NetInfo domain with the name “network.” The client will then bind to the first machine, master or clone, to respond to the request. When the parent server goes down the client will attempt to find another server by sending out another broadcast. For a parent to respond to a broadcast request there must be an entry in /machines of the parent database for the child machine that contains the child’s hostname and IP address.
Dynamic binding occurs when the client is given a NetInfo parent from a DHCP server. While this is a built-in function of Mac OS X Server, you should be able to add this info to most any modern DHCP server. You can specify multiple servers here, but only one tag. The clients will then automatically attempt to bind to the next server in the list after the first one fails.
Static binding allows you to specify a specific IP address and NetInfo domain name to bind to. In Directory Access you can only specify one server. However, if you edit /var/db/SystemConfiguration/preferences.xml you can specify more than one server, each with a different tag. In this case the client will attempt to bind to the second machine if the first fails.
A fourth way to bind is using LDAP. While this is not the “native” way for Mac OS X machines to share directory information, it will certainly work. LDAP servers can either be manually entered into Directory Access or given out via DHCP. Unlike NetInfo, you can have multiple separate LDAP servers specified for a static bind in Directory Access.
Now on to setting up a clone server. For this example we’ll use two servers. The master database will be held on DrEvil at 10.0.1.10 and the clone on MiniMe at 10.0.1.20. The machines are named using the “hostname” property in /etc/hostconfig. These names are important, so make sure they are right. To greatly facilitate this process you should set up DNS records for each machine where their DNS host name matches the machine name. Additionally, you will want to enable the search domain in the Network Preferences. Otherwise you will have trouble with your binding since the child or clone won’t be able to find the master.
Configure DrEvil
You’ll need to set this server up as you normally would to host network users using the Open Directory Assistant. Please see our article on this for more information.
Edit the master database
On DrEvil, we need to edit the machine record for MiniMe; that will tell the master database that a clone is available. So from the command line, execute these commands:
sudo niutil -create / /machines/MiniMe sudo niutil -createprop / /machines/MiniMe serves MiniMe/local ./network sudo niutil -createprop / /machines/MiniMe ip_address 10.0.1.20 sudo niutil -createprop / /machines/MiniMe suffix dc=evilcorp,dc=com
This is where all of the magic happens. We first create an entry for MiniMe to let the network domain know that MiniMe is out there. Next we add an entry to MiniMe’s machine record that states it serves itself, MiniMe/local, and the network, ./network, databases. Since MiniMe serves the same network database that DrEvil is the master for, MiniMe must be a clone.
Next we add an IP address for MiniMe so that DrEvil knows where to find it.
Finally, we enter in the domain, evilcorp.com, that MiniMe’s IP address resolves too. This is strictly for LDAP connections and is not necessary if you are not using LDAP.
Edit the clone database
While there are a number of ways to do this, the easiest by far is to set MiniMe up as a master NetInfo server first. This means going through the whole Open Directory Assistant procedure. After you have rebooted you will be serving out a network database that is not a clone. Now from the command line of MiniMe we can change this into a clone:
sudo nidomain -d MiniMe/network MiniMe sudo nidomain -c network DrEvil/network
The first command deletes the existing network domain on your machine. The second command fires up a clone database on your machine.
If you have problems at this point it is most likely because MiniMe cannot find DrEvil—how sad. Here is where good DNS comes into play. However you can get around this issue by creating a machines record in the local domain of MiniMe. For instance, do this on MiniMe:
sudo niutil -create . /machines/DrEvil sudo niutil -createprop . /machines/DrEvil ip_address 10.0.1.10
Now try the previous step again.
If you are using Mac OS X client and don’t have Open Directory Assistant you can accomplish the same thing by setting up Directory Access to statically bind to the network tag at 127.0.0.1 and then doing the following from the command line.
sudo nidomain -m network
Now you’ll have a working network database on the local machine. You are now where you would have been had you used the Open Directory Assistant.
Test the setup
First you want to make sure that everything took on MiniMe.
ps -aux | grep netinfod
This should return three lines that look similar to this
root 244 0.0 0.1 1832 516 ?? Ss 11:21AM 0:06.01 netinfod local (master) root 245 0.0 0.1 2432 532 ?? Ss 11:21AM 0:00.30 netinfod network (clone) root 2761 0.0 0.0 1116 4 std R+ 10:46AM 0:00.00 grep netinfod
Now you know that you have a local master and a cloned copy of the network database. So far, so good.
Open up NetInfo Manager on MiniMe—which should bring up the local domain. Click on the blue globe at the top of the window to open up the parent database. This should open up a new window titled “network @ 10.0.1.10” or whatever the parent’s IP address is. Change something in this database. Nothing important, mind you, but something. For instance, add /contacts in preparation for creating an LDAP contact server.
Wait a few moments. The clone should update in a matter of a few seconds. Now, in NetInfo Manager, go to Domain>Open By Tag and enter in 127.0.0.1 for the host and “network” for the tag. This will open up a new window that is a connection to the locally cloned database. Amazingly, it will look and act exactly like the parent.
Now for the problem
The hitch in all of this is the Password Server. While NetInfo databases can be cloned, Password Servers cannot. A workaround for this was recently discussed on Apple’s Mac OS X Server list: you can copy the pertinent information about the Password Server to another machine. Switch the backup machine’s IP address to that of the original Password Server, and then add a line to the watchdog.conf file that relaunches the Password Server. Now you have a fully functional Password Server back in operation.
For example, let’s set up a network with a centralized authentication server, password server and file server all with directory service redundancy.
DrEvil is our main authentication server, in addition to other network duties like DHCP and DNS. All client machines will bind to DrEvil and authenticate. DrEvil will pass off all password requests to NoTwo, which will house the password server. MiniMe is the main file server in this operation and maintains a clone of DrEvil’s network database. With me so far?
Now, when everything is working correctly you set up your clients to first attempt to bind to DrEvil and then to NoTwo and then fall back to broadcast discovery. When users connect to MiniMe they will be authenticated from MiniMe’s clone of the network database and thus reduce the activity on DrEvil.
We have three machines so three possible points of failure:
- If DrEvil goes off-line. Absolutely everything still works. Clients can bind to NoTwo, which will still serve out passwords just as before. MiniMe will continue to use it’s local clone of the network database. The NetInfo information will not be able to be updated, but that should be the least of your worries when your main authentication server goes down.
- If NoTwo goes off-line your IP failover scheme kicks into place. DrEvil sees NoTwo go down, assumes NoTwo’s IP address, restarts NetInfo and edits /etc/watchdog.conf to fire off the Password Server. DrEvil now thinks its hosting a clone network database because its IP address matches the machine record for NoTwo. Clients will bind to DrEvil, thinking they are binding to NoTwo because of the IP change. Essentially the end result is the same as in scenario 1.
- If MiniMe goes off-line directory services are completely unaffected. Users will not be able to reach the files stored on MiniMe, but that doesn’t affect logging into the machines. Hopefully you have contingency plan in place for a file storage backup, but that’s another article.