Portable Home Directories without Open Directory, part 2


In my last post, I wrote about getting Portable Home Directories working in my environment. I do not have an Open Directory server or AFP home directories, or Active Directory with SMB home directories – each an enviroment that Apple designed PHDs for. Instead, I have a third-party LDAP server that is used for many things in our organization, OS X login authentication among them. And home directories are handled the same way as all our Unix boxes – NFS automounts. We’ve been using this environment for many years, and successfully integrated OS X into it. It works well for our desktop users, who are always connected to the network with at least 100Mbps full-duplex connections. Users can go to any Mac in the building, log on as themselves, and get full access to their home dir. Their Desktop and Dock look the same. Their home dirs, since they are on the server, are backed up regularly. If their machine dies, we can swap in a new one, and they can be up and running very fast.

But our laptop users have been treated differently. They can’t use their UNIX home dir as their actual home dir on their laptops, because they are not always on the network. And they couldn’t use their LDAP credentials for logon, again because they are not always on our network. So they use local accounts. They are responsible for manually copying anything important to a server if they want it backed up, and if they also use a desktop machine on occasion, the environments are not the same. If they change their LDAP password (used also for mail, file server access, and other services), they have to remember to also change their local password on their laptop, or deal with two different passwords.

Tiger to the rescue?

When Tiger was announced with support for Portable Home Directories, it looked like a possible solution to some of these issues. Unfortunately, it did not work “out of the box” with our environment, and in early releases of 10.4, it was missing important sync functionality (~/Library syncing). So I set it aside to wait for an opportunity to look at it again and get it working here.

Finally I made some time recently to do just that. I’ve made a lot of progress. There are still issues to solve, but I am confident it could be a workable solution here. Longer-term, I’m even thinking about using PHDs on some of our desktop Macs – this has the potential to solve some issues with Adobe apps, which seem to dislike network home directories, and to speed up machines a bit (local disk access should be faster than network access).

Getting Login/Logout Synchronization working

When I left off last time, I had background and manual syncing working, but login/logout syncs did not work.

To aid in my investigation, I set up a more “standard” Apple environment for comparison. I installed OS X Server on a partition of one of the Macs at my disposal and configured it as an Open Directory Master. I then added some users, created some AFP home directories, and set Mobility preferences for the domain.

I configured a client machine to connect to the Open Directory Master and logged on as a user defined on the ODM, and configured a Mobile account. Login/logout syncs and background syncs behaved as expected.

Logging info for the synchronizations is written to ~/Library/Logs/MirrorAgent.log. By ssh’ing into the client from another machine, I could monitor this log while logging in as either client, looking for differences. I noticed that two different types of processes seem to be happening. The first type is the normal background or manual sync. These syncs appear to be handled by a single process that launches right after login and terminates at logout:

****** MirrorAgent-99.8 (8G1454) (pid 1515) starting Wed Mar 15 17:43:36 2006
Wed Mar 15 17:44:50.711 2006 *** Syncing "HomeSync_Mirror"
0 OKAY ADDED --> .bash_history
Wed Mar 15 17:44:51.712 2006 *** Done syncing "HomeSync_Mirror"
Elapsed time: 00:01.002
****** MirrorAgent terminating Wed Mar 15 17:50:09 2006
Shutting down sync engine.

But during login and logout, the log entries look a bit different:

MHD: ====================================================================================================
MHD: ****** MirrorAgent-99.8 (8G1454) (pid 668) starting Wed Mar 15 17:55:49 2006
****** MirrorAgent-99.8 (8G1454) (pid 683) starting Wed Mar 15 17:55:54 2006
Wed Mar 15 17:57:07.204 2006 *** Syncing "HomeSync_Mirror"
0 OKAY MODIFIED --> .bash_history
Wed Mar 15 17:57:08.193 2006 *** Done syncing "HomeSync_Mirror"
Elapsed time: 00:00.989
Wed Mar 15 17:57:22.554 2006 *** Syncing "HomeSync_Mirror"
Wed Mar 15 17:57:23.555 2006 *** Done syncing "HomeSync_Mirror"
Elapsed time: 00:01.001

Note the “MHD” tags, which is an abbrievation for “Mobile Home Directories”, an alternate name for Portable Home Directories. Since it is a slightly different mechanism that is doing the login/logout sync, I looked around for differences between the Mobile accounts, thinking there might be something there the login/out sync is triggering off of.

I got extremely lucky. I compared two Mobile accounts – one from OD where login/out syncs worked, and one from LDAP where they did not. Here’s mine (which wasn’t working):

niutil -read . /users/gneagle
name: gneagle
_writers_picture: gneagle
authentication_authority: ;LocalCachedUser;/LDAPv3/faldap:gneagle:
original_node_name: /LDAPv3/faldap
gid: 663
original_home: /home/fahome/gneagle
uid: 4389
comment: FA - Southside
shell: /bin/tcsh
original_passwd: NoneOfYerBzNz
change: 13182
realname: Greg Neagle
sharedDir: Public
passwd: ********
preserved_attributes: dsAttrTypeStandard:AuthenticationAuthority dsAttrTypeStandard:Password dsAttrTypeStandard:NFSHomeDirectory dsAttrTypeStandard:HomeDirectory dsAttrTypeStandard:Picture
home: /Users/gneagle
copy_timestamp: 2006-03-15T19:00:51Z

A field that was missing, compared to a “working” account, was original_home_loc. On the working account, this was a bit of XML containing an AFP URL and path. This doesn’t really have an equivilent with NFS mounts, so I just added this:

original_home_loc: /home/fahome/gneagle

…and login/logout syncing started working, after a dialog warning me that my home direcotry location had changed, and prompting me to choose where my most recent files were (network or local).

I surmise that this has something to do with the way AFP and SMB home dirs are implemented on OS X. At login, the loginwindow actually uses the home_loc (AKA dsAttrTypeStandard:HomeDirectory) field to mount the AFP or SMB home dir. Once logged in, the home dir is available at the path provided by “home” (AKA dsAttrTypeStandard:NFSHomeDirectory). So the login/logout sync process relies on “original_home_loc” (the preserved value of the network home dir location) to mount the network home dir. Without this value, it doesn’t know what to do, so it does nothing.

Continued in part 3….

Portable Home Directories without Open Directory, part 2

3 thoughts on “Portable Home Directories without Open Directory, part 2

  1. Maybe you can help with this issue?

    I am trying to find fellow sufferers obsessed with OS X Server (10.6) + Xserve + AFS (+XSan).

    Xserve1 hosts (AFP) user accounts on an external XSan.
    Portable Home Directories sync those to client laptops.
    The XSan folder is also permanently mounted to XServe2 (‘>mount’ on Xserve2 shows it correctly mounted).

    When I log into Xserve2, the users folder is mounted AGAIN (causing grief with file perms etc.). There was no problem pre-SnowLeopard (10.5).

    I KNOW I could just stop using PHD,.. but I don’t want to give that up.
    I also KNOW that could just not mount permanently,.. but I need it for a bunch of other reasons.
    I COULD just move the files physically from Xserve1 to Xserve2 but that just shifts the problem elsewhere (I’ll have double-mounts on Xserve1).

    1. How do *you* local-mount users, permanent-mount on another server, and PHD to mobile laptops syncing their home dirs.
    2. How might I prevent the automount from happening while preserving the use of PHD? (woud making a hardlink work?.. configuring fstab in an exotic way? digging into the hidden prefs on OS X Server? Latching on to some sort of apple event linked to the the system log file?

    Your help is appreciated and will win you a privileged place in heaven (and a free beer if you come by Lausanne, Switzerland).


Comments are closed.