Portable Home Directories without Open Directory, part 3

HomeSyncContinued from part 2….

LDAP mapping changes

Now we had login/logout syncing working. Unfortunately, I found it stopped working the next day. A look at the output of niutil -read . /users/gneagle showed that the original_home_loc field was missing once again. I guessed that this was because this field was not defined in the LDAPv3 mapping I was using (RFC 2307 (Unix)). Periodically, the loginwindow must query the directory server and update the values for the cached password and network home info. This is probably the meaning of this field:


preserved_attributes: dsAttrTypeStandard:AuthenticationAuthority dsAttrTypeStandard:Password dsAttrTypeStandard:NFSHomeDirectory dsAttrTypeStandard:HomeDirectory dsAttrTypeStandard:Picture

So I altered the LDAP mappings, adding a custom mapping pointing the HomeDirectory attribute (which corresponds to the “home_loc” field in NetInfo) to homeDirectory, the same field NFSHomeDirectoy points to. (NFSHomeDirectory corresponds to the “home” field in NetInfo.)

LDAPv3 configuration

Now DirectoryServices supported what Portable Home Directories was looking for, and login/logout syncing started working again.

HomeSync Preferences

An interesting side effect of adding the original_home_loc mapping was that the “Configure” button was no longer grayed out in the Accounts System Preference for Mobile accounts. But clicking on it caused System Preferences to crash.

A look at the crash log ferretted out the reason:


Application Specific Information:
Accounts v.1.7 (com.apple.preferences.users)
 
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000006
 
Thread 0 Crashed:
0 com.apple.CoreFoundation 0x9073fba4 CFRetain + 60
1 com.apple.CoreFoundation 0x90750fa4 CFDictionarySetValue + 448
2 com.apple.preferences.users 0x017c71d0 LWNotifyMountServerWithCurrentAuthentication + 156

That call to “LWNotifyMountServerWithCurrentAuthentication” looked to me like the Accounts pref was trying to mount the network home dir using the original_home_loc field, but since this wasn’t an AFP or SMB homeDir URL, it failed and crashed. I reformatted this field to look more like an AFP URL:


<home_dir><url>nfs://fashome-n1.tld/home</url><path>gneagle</path></home_dir>

And now the Accounts prefs didn’t crash when bringing up HomeSync preferences. But this caused other odd things to happen – like the NFS server mounting under /Volumes and refusing to unmount until a restart, so I reverted to a regular path for the home_loc/original_home_loc field. Ultimately this probably won’t matter for us, as when the user can access the HomeSync Preferences, any change they make completely blows away the ~/Library/Preferences/com.apple.homeSync.plist file, replacing it with something based on /System/Library/CoreServices/mcxd.app/Contents/Resources/CinchDefaults.plist and adding the user’s selections in the HomeSync prefs. This removes any customizations you have done. So not being able to access HomeSync Preferences might be a good thing for us.

That said, on my Open Directory test box, I set up NFS Home Directories for an OD test user, and found that I _could_ access HomeSync Preferences, even when original_home_loc was populated with a path instead of XML. So there’s more to this story, and I hope to puzzle more of it out in the future.

Conclusion and future directions

The original goal was to get Portable Home Directories working in my environment without having to make modifications to our LDAP or NFS servers. That has been accomplished. There are issues yet to be resolved.

NFS Home dir quotas
Our NFS home dirs are subject to disk quotas. Once a user hits their quota, they can no longer write to their NFS home dir. What happens if the user adds lots of material to their PHD which makes it larger than the available space under quota on the NFS server? How does the sync behave? Is there data loss? Is there any warning?

FileVault
How do Portable Home Directories work with FileVault-encrypted home directories? I haven’t yet tested this combination.

User control
How can we give the user some control over what syncs without overriding our preferred configuration? For example, by default I would not want to sync the Music, Movies, or Pictures folders – generally these are either empty, or filled with *personal* Music, Movies, or Pictures, things we as an organization don’t need to be backing up. But there will be users for whom it does make business sense to sync Music, Movies, or Pictures folders. Do we need to have an admin configure this? If so, should they just edit ~/Library/Preferences/com.apple.homeSync.plist, or can we provide a GUI? If we can get Apple’s HomeSync Preferences working, what can we do to prevent our “managed” list from being competely ignored?

Network change notification/Dynamic NFS mounts
With our current NFS automounts, which mount NFS shares based on automount maps, we have a custom startup item that calls automount to do the actual NFS automounts, and a periodic script that queries a server for newer versions of the automount maps.

For laptops, there are some additional challenges – if the laptop is off the company network when it boots, the custom startup script does nothing. A later connection to the network does not bring up the automounts; the user is (currently) required to reboot the machine to get the NFS automounts working.

What is needed is a way to receive notifications when the network changes, and then run a script that checks if the company network is available. If it is, it should check to see if the custom automounter is running. If so, send a kill -HUP signal, if not, start it. Perhaps it would be good to kill the custom automounter if we disconnect from the network, but that might be unneeded, instead relying on automount timeouts.

Additionally, a laptop is more likely to be off the comapny network (or off or asleep) when the periodic job runs that updates the automount maps. So even after the reboot, it’s possible the automounter will be started with obsolete automount maps. The same script that starts the automounter when we connect to the company network might also check the age of the automount maps and request new ones if they are more than, say, 24 hours old.

I’ve done some work on how to determine when the network changes, but have not yet found a 100% reliable way that’s accessible from a script. The SystemConfiguration Kicker bundle seems the most appropriate route, but I haven’t yet been able to get it to do what I want. Hints and tips appreciated!

Portable Home Directories without Open Directory, part 3

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

  1. Thanks – it appears that the main step you took was to import the Apple schema into your LDAP server. My approach also works and avoids making changes to the LDAP schema. There are plusses an minuses to each approach, but you can certainly get more OD-like functionality if you extend the LDAP schema to more closely resemble OD.

    Are you not seeing the Apple-supplied HomeSync prefs dialog crash in your configuration? I find that it does – if my Directory Services is OD, it opens and functions fine, but if my Directory Services is LDAP, it crashes. I expect it’s looking for an attribute I don’t have defined, but I haven’t figured it out.

    -Greg

  2. Its been working OK for us. No complains so far. Because I was able to migrate the schema, I am also able to use the Workgroup Manager from my laptop, point it to the LDAP server and manage user/group objects. My laptop user accounts are same as LDAP (no local accounts), and their we discovered during testing that ldap password changes get replicated to connected laptops fairly quickly and they do not have to remember multiple passwords. We have 1 account for all Unises..

    So far, we have not had the HomeSync Prefs crash. That probably because individual users do not have the ability to control what gets “synced”. They *do* get the Configure button but all options except “Sync Now” are greyed out. We do that deliberately using the Workgroup manager and manage that from the server side.

    Have you tried capturing the LDAP requests and see where/how it is failing ? Must be a plist that is missing ? (just a guess)

  3. I just worry that Apple will make major schema changes like they did from 10.3. to 10.4, and I’m not the LDAP admin here, so I like to figure out how to manage things with the minimum impact on our LDAP server.

    I suspect the crashing HomeSync Prefs is due to the fact that we mount the home directory under /home, the same as our Linux boxes, and not using the ‘net’ option to mount it under /Network/Servers. You mention that you could not get Portable Home Directories to work unless you mounted it under /Network/Servers. What problems did you see? It’s working for me, and my home dir is at /home/fahome/gneagle, and there’s nothing mounted under /Network/Servers.

  4. One more comment – it doesn’t really matter that much that the HomeSync Prefs dialog crashes, as I don’t want users to use that to modify their HomeSync prefs, anyway. It’s just bad user experience. I wrote a standalone app that lets users modify some of the HomeSync prefs while maintaining those parts I want to manage for all machines.

  5. Shan Sinha says:

    Greg-

    I am new to Mac in a networked environment and have run into a very strange problem with my macbooks. I know systems really well, but I’m just unfamiliar with how to debug mac systems.

    Here’s what’s happening:

    1) I’ve created an LDAP server based on OpenLDAP server on Linux
    2) I’ve connected my Mac to the LDAP domain (server=absolut) I’ve created so that I can log in to network accts
    3) I’ve set up the network logins to automount their home folders (on mac laptops) using Appletalk to our fileserver (johnny)
    4) I can turn my network account into a mobile account just fine (by modifying the system preferences). I can log in and out at will.
    5) As soon as I turn on Portable Home Directories and my home folder syncs down to the /Users folder, when I log out, I am unable to log back in. The user/password dialog box just shakes whenever I type in my password.
    6) As soon as I go in and delete the mobile account, and try to log back into the network account, things work fine.

    I’ve noticed that you’ve set up a similar network infrastructure.

    Can you help me with some debugging tips?

    In much pain!
    Shan

  6. So I’m confused about what you’re doing between steps 4 and 5 above – when you create the mobile account there should be a local home in /Users. What then are you doing in step 5 when you say you are turning on Portable Home Directories?

    When you get in the state when you can’t log in: what happens if you disconnect from the network?
    What does the output of
    dscl . read /Users/yourshortname
    Look like?

  7. Zach C says:

    Greg-

    This is a fairly old article, so I don’t know if you’re still monitoring it for comments. It remains one of the few resources available on Portable Home Directories.

    I have PHD working with my Linux OpenLDAP/NFS server, except that FileSyncAgent seems to sync every thing every time–even things that haven’t (shouldn’t have) changed. Have you experienced this or have any idea what could be causing it? I’m wondering if there’s something about how timestamps or perms are represented by the NFS server that’s causing the OS X client ot see modifications when there aren’t any. I’ve cranked up logging:
    defaults write com.apple.FileSyncAgent debugOutput 3.
    There’s a lot more output but nothing indicating what the actual change was.

    Any tips would be appreciated.

    Thanks

    1. I haven’t seen this, though I have seen FileSync insist on always syncing a few files here and there, and occasionally sync files that I know haven’t changed in a long time.
      I’d try resetting the FileSync database on the network home:
      rm -rf /path/to/network/home/.FileSync

  8. Dave R says:

    Hey Greg,

    Excellent breakdown!

    I too have run into a PHD syncing issue.

    CONFIGURATION:
    Here is a bit of background on our config. We have an eDir/OD triangle setup that is functioning well. Home folders are hosted on a Novell file server. The OD Master xServe is running 10.5.5 and the Mac Client is running 10.4.11. The client is bound to both eDir (ldap) and OD. Both Login/Logout and Background Sync is active (syncing only ~Documents and Safari/Firefox ~Library folders) via WGM.

    We did not extend the schema on our eDir ldap server, but rather LUM enabled the users and groups via a Novell Linux server and ran a script to auto-populate the AFP home directory path in the Novell user accounts. (possixAccount / possix Groups)

    NOTE: Similar to your situation, we had to modify our ldap mappings, adding a custom mapping pointing the HomeDirectory attribute to homeDirectory.

    PROBLEM:
    The problems don’t start until I introduce mobile homes in to the mix. When a user logs in with a mobile home account, the initial sync completes as expected, but the logout sync does not take place. (Note: Background sync does take place and correctly syncs files — manual sycs work too.)

    Then at the next login MirrorAgent complains of changes since last sync and wants me to pick either local or network as the location of the newest files. It doesn’t matter which I choose as this cycle will repeat at each subsequent login.

    I verified the MCX settings for sync preferences and it is set to sync at login, logout, and once every 20 minutes. Interestingly enough, once you choose a location for the latest copy of the files (either network or local) all subsequent syncs will complete successfully without complaint until the user logs out.

    I reviewed the Mirror Agent.log but the only thing of interest I could see was the following error message.

    MHD: ==========================================================
    MHD: ****** MirrorAgent-99.9.7 (8S165) (pid 339) starting Thu Feb 19 15:38:48 2009
    MHD: Thu Feb 19 15:38:50 2009: /SourceCache/FileSync/FileSync-99.9.7/Agent/Engine/home.m,298 pair->there->home.mhdMountPath is NULL (AcquireHomesForMirrorPair)

    The above error message is recorded when the gui is telling me that there were file changes from last sync when trying to login.

    As for logout all I get is this: (no logout sync activity)

    MirrorAgent terminating Fri Feb 20 01:09:57 2009
    Shutting down sync engine.

    So it doesn’t even seem to be attempting to sync at logout at all.

    My best guess is the “home.mhdMountPath is NULL” statement listed above is our clue, but that confuses me since the background sync and manual sync work fine.

    Based on your experiences, can you make sense of this issue? Any help in pointing me in the right direction to solve this issue wold be greatly appreciated.

    Thanks for your time and insight.

  9. Dave R says:

    Greg,
    I am not exactly sure where to find the output for the OriginalHomeDirectory attribute. I have included the niutil output below from one of our mobile accounts (didn’t see it there either). Hopefully the niutil output helps…if not, let me know. Thanks -DR

    niutil -read . /users/cichbevname: cichbev
    CichBev_writers_picture: cichbev
    authentication_authority: ;LocalCachedUser;/LDAPv3/www.domain.here:cichbev:
    original_node_name: /LDAPv3/www.domain.here
    original_home: /var/tmp/novell/cichbev
    gid: 5001
    uid: 5016
    original_home_loc: afp://tj_login.domain.here/TJ_LOGIN.VOL1Teachers/CichBev
    shell: /bin/bash
    realname: CichBev
    passwd: ********
    sharedDir: Public
    picture:
    preserved_attributes:
    dsAttrTypeStandard:AuthenticationAuthority
    dsAttrTypeStandard:Password
    dsAttrTypeStandard:NFSHomeDirectory
    dsAttrTypeStandard:HomeDirectory
    dsAttrTypeStandard:Picture
    home: /Users/cichbev

  10. Dave R says:

    Greg,
    The above original_home_loc output should read:

    original_home_loc: afp://tj_login.domain.here/TJ_LOGIN.VOL1Teachers/CichBev

  11. If you’d used dscl . read /Users/cichbev you’d see the OriginalHomeDirectory attribute. In the niutil output, it is listed as original_home_loc.

    It looks OK to me. Can you think of any reason you wouldn’t be able to mount the network home share on logout?

  12. Dave R says:

    I thought it might be a DNS issue, but I verified that to be working. I also tried connecting with the IP address instead of the domain name and received the same results.

    Strange how the network home share is being mounted for a manual and background sync, but can’t with login/log out. DNS must be working for the manual and background syncs.

    I’ll do some more digging. Let me know whether you have any other thoughts.

    Thanks!

  13. Dave R says:

    Greg,
    I did find another interesting output in the mirror agent.log. Notice the “err -1 (syncThreadStart)” listed after the home.mhdMountPath is NULL return. Not sure whether that is being posted due to the offending “home.mhdMountPath is NULL error” or whether it is a clue to something else. Funny thing is that I don’t always see that statement in the MHD output. I’ll continue to dig on my end. Thanks!

    MHD: =================================================
    MHD: ****** MirrorAgent-99.9.7 (8S165) (pid 989) starting Tue Feb 24 12:45:10 2009
    MHD: =================================================
    MHD: ****** MirrorAgent-99.9.7 (8S165) (pid 1023) starting Tue Feb 24 14:15:36 2009
    MHD: Tue Feb 24 14:15:37.051 2009 *** Syncing “HomeSync_Mirror”
    MHD: Tue Feb 24 14:15:37 2009: /SourceCache/FileSync/FileSync-99.9.7/Agent/Engine/home.m,298 pair->there->home.mhdMountPath is NULL (AcquireHomesForMirrorPair)
    MHD: Tue Feb 24 14:15:37 2009: /SourceCache/FileSync/FileSync-99.9.7/Agent/Engine/SyncThread.m,217 err -1 (syncThreadStart)
    MHD: Tue Feb 24 14:15:38.097 2009 *** Done syncing “HomeSync_Mirror”
    MHD: Elapsed time: 00:01.047

  14. Dave R says:

    Greg,
    Do you have an idea what “home.mhdMountPath” is referring to in the aforementioned error? (OriginalHomeDirectory???) Obviously, what home.mhdMountPath is looking for must be empty or nonexistent.

    Then the questions that need to be answered are “why” is it empty and what does it need to be populated with? -or- If it is nonexistent, “where” does it need to be created and what does it need to be populated with?

  15. I haven’t used a Tiger machine for a long time; home.mhdMountPath has to refer to either the mount URL or where it mounts on the local filesystem.

  16. Dave R says:

    Looks like the mount URL is where this is stemming from. I got a hold of a Mac with 10.5.5 installed on it, and I set it up for PHD. Console gave me the following error…

    EXCEPTION: Unable to mount remote home volume (Carbon error -5002)
    [2009/02/26 15:11:27.813] Peer “network” is unable to sync. Not enough peers will be available to continue syncing.

    I guess I still don’t understand why background and manual syncs work (which means it must be mounting the remote home volume) and Login/Logout sync is unable to mount the remote home. I wonder whether it is trying to authenticate differently in Login/Logout syncs?

  17. Dave R says:

    Hi Greg,
    Sorry for the long delayed response, but I was able to find a remedy for the mobile homes synching issue noted in the above details.

    In Workgroup Manger we were only synching the Documents Folder, Safari Library Folder, and FireFox Application Support folder. For some reason, in 10.4.11, we could not get all Syncs (Login, Logout, and Background) to work when logged in as a mobile user.

    After playing around for quite a while, we discovered that the three Synching functions would not work unless we created (in the Mobile User’s Network home folder) a Preferences folder with the com.apple.homeSync.plist inside. The com.apple.homeSync.plist was copied from the user’s local Library/Preferences. Once we did this, all Synching functions worked. Not sure whether this is a hidden bug in the process, but we are now working fine.

    10.5.x computers did not have this issue.

    Special thanks to Ben Gollmer from TC Networks for assisting us in solving this issue.

Comments are closed.