Portable Home Directories — Part 1

Available since version 10.4, Portable Home Directories have become one of the most elegant and well-implemented features of a full Mac OS X Server deployment. Functioning much like Windows' roaming profiles (or earlier Solaris NFS/NIS environments), they allow a user to log in from any computer on your network while retaining their personal data and settings. Unlike entirely network-based systems, however, they do so by synchronizing user data to the server (so that a full copy of the home directory exists in both locations), eliminating the need for constant connectivity.

Portable Home Directories make for simpler backup of user data, both by copying off the server rather than each client machine, and by allowing remote users to synchronize via VPN. They also free users from being tied to a single machine, allowing for greater flexibility and less service down-time. It's because this functionality is so powerful that it's often assumed to be difficult to put into practice. Instead, with the proper infrastructure already in place, deploying Portable Home Directories is practically the reward for having done everything else right.

Planning For Portable Home Directories:

Before you actually implement any kind of server-based account storage, you'll want to make sure you have sufficient storage and bandwidth on an available OS X server. This may seem obvious to some, but for reasonable performance, fifty users with a 40GB quota requires at least 2TB of relatively high-speed (and hopefully redundant) disk attached to a gigabit network switch. This isn't an exotic setup by any means, but it may be more than you just have lying around.

You'll also need clients bound to a functioning Open Directory environment, complete with internal DNS. If you don't yet have this set up, refer to our earlier series on how to master Open Directory. Once Directory Service users and groups are in place, Portable Home Directories are nothing more than cleverly deployed managed account preferences. There's a lot to keep track of, but very little you wouldn't already know how to do.

Configuring Portable Home Directory Preferences:

In Workgroup Manager, browse to the "LDAPv3" directory (as opposed to the local user directory), then choose the multi-headed "Groups" button on the left and the "Preferences" icon from the toolbar. Select the group (or groups) you're offering Portable Home Directories, then click the "Mobility" icon in the center of the window to configure that group's settings. If you're deploying this feature to all your users, you're better off creating an all-encompassing "Employees" group to do so.

Beginning in the "Account Creation" tab with the "Creation" pane, choose to manage these Preferences "Always", the check "Create mobile account when user logs in to network account". Uncheck the box which requires confirmation, as this allows the user to skip the Portable Home Directory set up for their individual account. Below that, choose to "Create home" directories "with default sync settings".

Next comes the Account Expiry tab, new to 10.5. By allowing you to set a time limit after which the client-side copy of a home directory expires, it helps clean up the occasional "orphaned" set of user data (a full home directory left, for instance, on a machine only used once by that user during maintenance on their own machine. This feature can reduce the chance of accidentally filling client machines with multiple unused accounts, but does so at the risk of letting the computer determine when data should be disposed of. If you enable it, do so with caution.

Finally, the "Rules" tab lets you set what data will synchronize and when. Start with the "Login & Logout Sync" pane and once again click the button to "Always" manage, then check the box to "Sync at login and logout". The first list above allows you to set which directories you'll sync, and unless you feel you can fully predict your users' behavior the best approach is usually to select the entire home directory (as represented by the tilde symbol). You can then choose what not to sync in the second list below, including full paths, partial names, and even regular expressions. Be careful if you delete any of Apple's pre-configured items to skip, especially ~/Library/Application Support/SyncServices, which can result in synchronization issues and potentially data loss. The "Merge with user's settings" box allows you to decide if individuals can add or subtract to the list of data being synchronized.

The Background Sync pane, functions identically, and in most cases makes sense to configure identically as well. The only exceptions would be huge local files which change often, or live databases which won't sync properly. The Entourage database, for instance, sits both criteria and should be excluded from background synchronization. The "Options" pane also allows you to choose how often background sync takes place. With your configuration decided, click the "Apply Now" button to save your settings.

Next week, in part two, we'll set up the AFP share where your new Portable Home Directories reside and configure your Open Directory accounts to store user data there.

Recommended Reading: While I might not recommend implementing it in a production environment, Greg Neagle's multi-part article on Portable Home Directory Without Open Directory provides fantastic under-the-hood information on exactly how Portable Home Directories function at his "Managing OS X" blog.

Configure Launchd Graphically

We've written about launchd (the daemon which governs OS X system processes) before. We've detailed its xml-based syntax, even as we've struggled to remember every tag and attribute. We could have saved ourselves the trouble and pointed to Peter Borg's Lingon, the free graphical editor for launchd plist files.

Inexplicably named for a swedish berry, with an icon like the giant red ball from Alias, Lingon's odd presentation quickly gives way to its powerful and convenient functionality. Its main panel allows you to create and edit launchd jobs with just their names, the Terminal command or script they run, and their scheduling options.

An advanced mode offers syntax-colored construction of the full range of launchd options (such as inetd compatibility, hard resource limits, and listening sockets). For power-users, Lingon is a tremendous time-saver, eliminating a great deal of referencing and proofreading for what amounts to an occasional task. For the novice, it's like Dreamweaver for dangerous system modifications.

Lingon has one major annoyance: The inability to save files anywhere other than live system directories. This isn't so bad if you're composing your plist files on a system that's meant to run them. If you're composing a launchd job for another machine (or many others), you must save it first without enabling it, then fish it out of the directory Lingon squirreled it away in. A "Save As" feature would go a long way here, and the absense of one could cause serious trouble for a careless user.

Despite its eccentricities, Lingon is an impressive tool, simple when it needs to be and complex where it has to. It's also a generous open-sourced contribution to the Macintosh administration community.

Lingon is available free of charge.

Restart Kerberos Manually

The Kerberos authentication protocol is an encrypted ticketing system at the heart of Apple's Open Directory. It is the basis for Mac OS X's "Single Sign On" features, and a required component for integration with Windows Active Directory domains. Unfortunately, it's possible for the Kerberos service to stop functioning properly, and when it dies, a good number of your network services die with it.

Ideally, you can simply click the "Kerberize" button in the "General" pane of Server Admin's Open Directory settings. That should restart the service. This article for when you find yourself in less than ideal circumstances.

Why Kerberos Can Stop On OS X Server:

When the Kerberos service fails, the likely culprit is a DNS issue. This isn't the only reason Kerberos can break, but it's most common and the easiest to test for. The Kerberos KDC service (or Key Distribution Center), requires matching forward and reverse DNS lookups, and changing a server's hostname or IP manually (or losing connection to your DNS servers) can require the machine to be re-Kerberized. Since Tiger, Mac OS X has also been designed to dynamically set a machine's hostname on boot using a reverse lookup, meaning that external changes to a server's DNS listings can cause it to change names and break its original Kerberos realm.

Before you try to restart Kerberos, you'll want to know which (if any) of these things went wrong. If you aren't sure how to go about this, check with whomever in your organization controls Domain Name Service, or use the procedure from the beginning of our article on setting up Open Directory.

How To Start Kerberos From The Command Line:

Once your server is properly registered in DNS, you can begin reconstructing your Kerberos realm. The first step is to create a new edu.mit.Kerberos file, which Mac OS X can fortunately do (somewhat) automatically. Open the Terminal and type:

sudo kerberosautoconfig -r REALM -m HOSTNAME

For this command, HOSTNAME is the fully qualified domain name of your server, such as server.example.com. REALM is the server's DNS name again, but this time in all capital letters, like SERVER.EXAMPLE.COM. Next you'll create a KDC database for the new Kerberos realm:

kdcsetup -f /LDAPv3/127.0.0.1 -w -a DIRADMIN -p PASSWORD REALM

Here DIRADMIN is the name of any user with directory administration privileges, and PASSWORD is their actual login password. Once that's done, you can Kerberize the server's Open Directory domain with the following:

sudo slapconfig -kerberize -f DIRADMIN REALM

Finally, configure the Single Sign On mechanism to utilize Kerberos authentication for all applicable OS X services.

sudo sso_util configure -r REALM -a DIRADMIN -p PASSWORD all

This should once again leave you with a fully-functioning Kerberos installation on your Open Directory server, all without ever having had to reboot the machine.

If you're following this procedure, keep one additional things in mind: Because the kdcsetup and sso_util commands unfortunately requires that you provide a password on the command line (and therefore store that password in your command history), it's good security practice to change that user's password immediately after this process.

Recommended Reading: For an illustrated overview of the Kerberos authentication Process, there's the handy Kerberos Chart [PDF - 72KB] at Computer World. For more depth into how Kerberos works on OS X, there's an excellent three-part article at AFP548.com.

Mount SFTP Volumes Locally

For years, systems administrators have used SFTP (the SSH File Transfer Protocol) to provide secure access to remote file systems. Based not on FTP, but on the Unix Secure Shell, SFTP allows the encrypted transfer of files over any network. While SFTP's command options and version compatibility can make it a complicated tool, Magnetk's ExpanDrive makes it easy to appreciate, offering Macintosh users a near-flawless way to mount and access remote servers as local disks.

The heart of ExpanDrive is the Drive Manager window, opened from its magnet-shaped icon in the OS X menu bar. From this window, you can add, subtract, and manage any remote volume on a server offering SSH. Fill in the server address, your login name and password, and (optionally) the remote server path you're logging in to and name you'd like for the local version of the volume.

The beauty of ExpanDrive is that once it's up and running, you can forget it's there entirely. It handles network difficulties gracefully, faster and more stably than the Macintosh Finder itself, and reconnects seamlessly when disconnected.

ExpanDrive keeps improving as well, with four significant updates this month alone. The coming version, promised by Magnetk in the next few weeks, includes Applescript integration and command line utilities for mounting SFTP shares from the Terminal.

ExpanDrive isn't without its issues. It handles Unix symlinks (file pointers like Windows shortcuts) poorly, can't transfer the resource fork on legacy Macintosh files (and fonts), and lacks a standardized interface or dock icon. If these issues apply in your environment, they may very well be deal breakers. For web development, image libraries, or management tasks, on the other hand, ExpanDrive outshines any other available tools for secure file system access.

ExpanDrive retails for $29.

Acrobat 8 Crashes On Launch

Although Mac OS X has excellent built-in PDF support, there are some jobs that only Adobe's Acrobat can do. The ability to combine existing documents, create editable forms, and encrypt sensitive data all make Acrobat an indispensable tool. It's too bad, then, that the application has such a checkered history when it comes to stability. Acrobat 8 Professional, for instance, often crashes right out of the box. If it's doing so in your environment, there are several ways to get things running smoothly again.

There's a known issue in Acrobat 8 where corrupt or improperly-permissioned support files can cause the application to quit without warning. The problem centers around Adobe's Updater plugin, which by default checks for software patches when Acrobat first starts and causes the program to crash. Armed with this knowledge, it's easy to choose a solution appropriate for your environment.

The simplest method of dealing with this is to disable the plugin by selecting Acrobat in the Finder, choosing "Get Info" from the "File" menu, and unchecking the "Updater.acroplugin" box in the "Plugins" section of the Info pane. This method will prevent Acrobat from quitting unexpectedly, and is simple enough to walk users through over the phone or email. Unfortunately, it doesn't address the underlying issue.

The next approach is to replace the Updater plugin entirely. Adobe offers a fix for the Updater Plugin [963 KB]. To install the new plugin, right-click Acrobat 8 and choose "Show Package Contents", then open the "Contents" folder and place the new file in the "Plugins" directory. Though the publisher notes this doesn't work in every case, it allows Acrobat to run properly in most environments with the auto-update mechanism.

Finally, in most large environments, the best solution is to remove the offending plugin entirely. To do this, once again right-click Acrobat 8 and choose "Show Package Contents", this time going into the Plugins folder and removing the file named "Updater.acroplugin". This not only returns Acrobat 8 to full functionality, but prevents future issues that might be caused by unscheduled or user-initiated updates.

Recommended Reading: If you're looking for greater control of the update process, Adobe offers patches for manual download, testing, and installation at its Acrobat for Macintosh support page. If you're looking for more information on this issue, take a look at the Adobe Product Forums or the Acrobat for Macintosh list at Google Groups.