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.
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.
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.)
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.)
Assuming you're using a Unix or Linux file server, it is extremely straightforward to share out a home directory over NFS. Most Linux distributions install NFS by default and all that is necessary to start NFS is to configure /etc/exports and run something like:
There are a few Mac NFS oddities to be aware of that threw me for a loop when I first encountered them. One is that Mac-specific Linux NFS servers must use the insecure option when they export a file system. This is because OS X uses a weird port for NFS, and if you don't enable it you won't be able to mount NFS volumes and you'll wonder why. See Figure 6 for a CentOS /etc/exports configuration that works for Mac and Linux.
Figure 6. /etc/export example
Keep in mind, you can also quite easily share out a directory on your Open Directory server and use that to host common NFS home directories for Mac and Linux clients. This works just fine as well. Sharing out NFS volumes on OS X client or server is almost identical. Many people aren't aware that a regular, nonserver OS X machine can work well as an NFS file server. If you have one laying around, put it to use as an NFS file server. You'll find that SMB works just fine as well. I personally prefer to use Linux as an infrastructure file server because it is very cheap. An alternate corporate configuration could be a massive XSAN file server shared out over NFS that Open Directory uses for common NFS home directories. There are many ways to configure Open Directory and NFS; you just need to pick the right way for your situation.
This section is the most complex section you will encounter in this three-part series, but I have included quite a few figures to try to make it clear. If you have any problems setting this up, don't feel bad, because it is very involved, and you can refer to the Open Directory online documentation, which is quite good.
Remember how I said that OS X has a few odd NFS implementations? Well, here is another oddity. The OS X implementation of NFS does not have something like
autofs, which is an extremely handy tool to automount file servers. For example, on Linux if you enable
autofs, you would just need to edit /etc/auto.master and uncomment the /net section as shown in Figure 7.
Figure 7. auto.master example
What is brilliant about using
autofs is that you will automatically get access to any NFS volume on the network by typing
ls -l /net/hostname of the file server you would like to mount. This means that you can make drastic changes to the NFS infrastructure and client-side configurations will not be needed, such as editing /etc/fstab.
On OS X there is a way to get around this by using Open Directory as an automount server. There is a Mounts container in Open Directory, which serves as a way to automount NFS volumes to bound Open Directory clients. This is extremely handy as it means you can explicitly define NFS file servers for all clients to mount.
Before you get too excited, there are a few gotchas. According to Apple, you should only mount between three to five file servers using this method. Additionally, you should modify the number of NFS daemons on your Open Directory Server so that it is above the default of six. I personally set this value to around 32 daemons, but you can go as high as 64 daemons if you have, say, 250 clients getting their NFS mounts this way. See Figure 8 for an example of changing NFS daemons default value.
Figure 8. Setting NFS daemons example
Now we can modify Open Directory to add NFS Mount records so that all Open Directory clients will mount the file servers we define. To do this we first need to go into export mode and Show "All Records." Go to the Workgroup Manager Preferences and enable Show "All Records" tab and inspector. Refer to Figure 9 for an example.
Figure 9. Check the Show "All Records"... preference
This enables us to actually edit the LDAP database by hand. Next we need to add a mount record. You will need to select the Mount container by navigating to the bullseye type button. From there you will see a drop-down list right under the search field. Select Mounts from this big list of LDAP containers. See Figure 10 for an example of this.
Figure 10. selecting mounts
Since a picture is worth a thousand words, I am including an image of the proper attributes that are necessary to enable an NFS file server Mount record. I created a new Mount record by selecting New Record. I then created new Attributes for this Mount record by selecting New Attribute. If you look at the Open Directory documentation, it refers to the proper attribute values that I am using on pages 224 and 225. To my knowledge, this is the only documentation ever published on how to get NFS home directories and Mount records to work (other than this article). Refer to Figure 11 for the exact values.
Figure 11. Example complete NFS Mount record
Now that we have set up a Mount record, all Open Directory clients will automatically mount cent:/mnt/raid. In order to test this, you will need to reboot your machine. Usually, just a logout will be enough to tell the automount daemon to reload, but the first time a Mount record is added to Open Directory you will need to reboot your machine for the setting to take effect. See Figure 12 for an example of the automounted volume.
Figure 12. Automounted NFS volume
Now that we have verified that we have an automounted NFS volume, you might be wondering, "how are a Linux machine and a Mac going to get the same home directory, because the way they mount things is so different?" All we need to do is create a symbolic link on both the Linux client and Mac client so that we can add one NFS Home Directory value to Open Directory. Remember, we have a local home directory for our oduser now. On the Mac we'll do this by:
sudo ln -s /Network/Servers/cent/mnt/raid/home /odhome
This will allow the home directory to appear to be: /odhome/oduser on a Mac. Now, on our Linux client we'll create a symbolic link that will create the same uniform path by:
sudo ln -s /mnt/raid/home/ /odhome
On Linux we have a network home directory path of /odhome/oduser. If you haven't already created a placeholder directory for oduser go ahead and do so now by using the following commands on the Linux file server:
mkdir /odhome/oduser chown -R oduser:staff /odhome/oduser/
This will ensure that the oduser account will have the proper permissions when OS X creates the account for the first time. If you ever experience problems with common NFS home directories, make sure that you check your permissions for the user using the preceding example.
All that's left to do to get an NFS home directory working is to add this record to Open Directory. Open up the Workgroup manager and select the oduser. Delete the current home directory attribute, shown in Figure 13.
Figure 13. Delete Local Home value
Next create a NFSHomeDirectory value of /odhome/oduser as shown in Figure 14.
Figure 14. Create NFSHomeDirectory value
Let's test this out and we're finished. If you do a fast user switch to oduser, and open up a shell and type in
pwd, you will see that you are in /odhome/oduser. If you type
ls -l, you will notice that you have a Library and Desktop folder that are automatically created by OS X when a new account is logged in. Now let's really test this baby out by shelling into our Linux box and seeing if we get the home directory. If you
su - oduser you will notice that if you do a
ls -l that you have the same data, Library and Desktop! Let's send a message to our Mac alter-ego. We'll change into the Desktop and tell the Mac "hi." See Figure 15 for a picture of the commands.
Figure 15. Hi from Linux
Figure 16. oduser sees Hi from Linux
One final thing to keep in mind, if you use OS X with NFS in a group environment you should probably edit this file:
Use the Property List Editor to add the value NSUmask = 2. This binary value will set the umask to 002, which will allow other members of your NFS group to read, write, and execute. The default behavior of the finder is to create files with umask 022, which means group users only have read and execute privileges.
You should probably also set the umask in /etc/profile by adding the line:
Note that a reboot is required for the Finder and the bash shell to get their new respective umask values.
As shown in this article, Open Directory can play with the Unix big boys and integrate quite nicely into an existing NFS infrastructure. NFS is a great alternate choice for OS X Home Directories, as it lets you share a common environment with your Linux and Unix machines. If you work frequently from the shell, you will appreciate the fact that your .bashrc works flawlessly wherever you go.
Noah Gift is the co-author of Python For Unix and Linux by O'Reilly. He is an author, speaker, consultant, and community leader, writing for publications such as IBM Developerworks, Red Hat Magazine, O'Reilly, and MacTech, and Manning.
Return to Mac DevCenter.
Copyright © 2009 O'Reilly Media, Inc.