Discover the Power of Open Directory (Part 2)by Noah Gift
In the first part of this three part series on Open Directory we set up Open Directory, created an Open Directory User Account called oduser, gave the oduser a local home directory attribute, and authenticated a Mac against Open Directory. In this article, we will set up a Mac with an NFS home directory using Open Directory, integrate an existing Linux NFS file server for a cross-platform home directory, and authenticate a Linux client into Open Directory.
Making OS X work with an existing NFS infrastructure is quite easy, although not mentioned in any documentation I have found, including the official Mac systems administration training books. Apple pushes AFP, but if you are already running a Unix shop, then using NFS is a much better choice. There are a few gotchas and design decisions to be aware of that I figured out through trial and error, and I am happy to share those findings here.
Getting Linux NFS Server to Authenticate to Open Directory
If you remember, for the last article we set up a local home directory for our Mac client. This is an acceptable setup, but not nearly as fun or useful as a common NFS home directory that Linux and OS X clients can share.
To get started, let's first integrate an existing Linux file server. My home file server is a CentOS 4.4 client that has a 1 TB volume consisting of three 350 GB SATA II drives striped in a RAID 0 configuration. I mirror my file server every night to another slow file server, so I don't care that much if the main file server dies and all of the data is lost. I use this strategy to get the fastest possible disk I/O on my network. I think using this type of strategy is a quite reasonable approach as the overhead (loss of performance and space) and complexity of managing a redundant RAID is a bit of a hassle for me. I have finally settled on synchronized RAID 0 as my file server strategy. This configuration may not be appropriate for you if you can't afford the downtime of resynchronizing the data while you rebuild the main file server again. In that situation, a simple RAID 1 Mirror could be appropriate, although it would be much slower.
For a CentOS 4.4 machine there is a handy tool available that makes authenticating to Open Directory a snap. It is called
authconfig. This wizard only works on Red Hat-based systems, so you will need to configure LDAP authentication by editing the proper configuration files on other Unix variants.
Using authconfig to Authenticate CentOS to Open Directory
Before we get started, let's make sure that our Linux box knows how to find the Open Directory (OD) server by editing its local host files. Note that in the final article in this series we will switch everything over to a DNS server, but for now we will just edit /etc/hosts so that we have an entry for mini.pretendco.com or whatever your Open Directories FQDN is. Refer to the first article in this series for instructions on how to edit your /etc/hosts file if you don't know how to perform this action.
Next, just type in
authconfig at the command line and you will see the dialog box in Figure 1. Make sure that you select the boxes shown in the example. Note that Kerberos also works just great, but requires a centralized time server that the OD master and clients talk to. We won't cover it in this article, but you can try playing with it on your own. Remember that Kerberos just works on Open Directory right out of the box.
Figure 1. authconfig example (Click to enlarge.)
In Figure 2, you will need to enter the server IP address and the base DN of the Open Directory Server you set up. If you forgot your base DN, just open Server Admin and look at the Open Directory service box again.
Figure 2. authconfig OD entry example (Click to enlarge.)
Testing authentication with getent passwd
Now that you have authenticated against Open Directory (that took, what, all of 20 seconds?), it is time to do some thorough testing. Let's use
getent passwd, shown in Figure 3, to get a dump of the all user accounts our Linux machine can find. This is a great way to see if we can find the oduser account we created in the first article.
Figure 3. getent password example
You will get a large dump of accounts to your terminal, but the one you care about is the last account as shown in Figure 4. Alternatively, if there is a specific account you would like to verify you could type in:
getent passwd | grep oduser.
Figure 4. getent password output example
Since it appears we can see our oduser account, let's log in and see what happens. If you are root, it is easy to change into another account and do a few simple tests as shown in Figure 5. Look carefully at the several commands there. First I
su - oduser, which allows me to switch into the user's environment, and I instantly get an error saying "cannot change to /Users/oduser: No such file or directory." This is because Unix keeps home directories in /home/ and Mac OS X keeps directories in /Users. This isn't a big deal, and we can fix this later. I also typed in
whoami. This command tells you which account you are currently using. It says I am oduser, which is what I expect. Finally, in looking at the output of
env we can tell that the user's HOME value is /Users/oduser. This confirms the dialog we saw earlier about not being able to change to /Users/oduser.
Figure 5. authconfig OD entry example (Click to enlarge.)