7.3. User Home Folders

In a standard desktop computing environment, in order for a user to be able to do anything useful and have the merits of their work persist, they must have a non-volatile place to store that work. Most modern day multi-user operating systems provision a specific directory, typically called a home folder, on the file system for this purpose.

In OS X, there are two different types of home directory storage. A Local home folder is the most common type, and simply means that a user's home folder resides on a local disk of the machine that they are using. A Network home folder, on the other hand, resides directly on remote storage accessed via a network file system while data appears to reside on local disk. In actuality, all activity results in file system activity on a remote server.

The following sections will explain the differences between these different storage types, provide explanation on how to determine which scheme is right for your users, and provide you with the necessary information to implement an efficient, effective home directory strategy.

7.3.1. Local Home Folders

In OS X the default store location for user's home directories is on the root volume at the path /Users. Every user created using the Accounts Preference Pane of System Preferences will be automatically provisioned a folder inside this directory, named after the user's short name. For instance, if you were to create a user and specify a shortname of "bob," that user would be provisioned a local home folder at path /Users/bob. If you were to inspect this folder, you would see a default OS X user directory containing the following folders:

• Desktop: This folder serves as the user's desktop folder. Any item residing in this folder will be displayed on the user's desktop.

• Documents: This folder is used primarily for user-generated documents. Occasionally, applications will store support files in this folder, but this is considered poor form. One infamous offender here is Microsoft Office, which stores numerous files, including the entire Entourage email database, inside of this directory in the folder Microsoft User Data.

• Downloads: This folder is used for content downloaded via Safari, iChat, or other supporting Cocoa-based apps. This folder typically only contains transitional or low priority items. Users should be encouraged to properly organize items in this folder into more appropriate folders in their home directory.

• Library: The user Library folder is a user-specific version of the main library folder at /Library. This is where the behind-the-scenes data resides that can be edited by applications. Data in this folder is typically not fit for direct user interaction or presentation. Its uses include, but are not limited to, application databases, preferences, plug-ins, fonts, and cache files.

• Movies: This folder is pretty self-explanatory, and is intended for the storage of videos. This folder in an average user's home directory is typically pretty barren. This folder isn't heavily utilized by applications. The most notable app to make use of this folder is iMovie.

• Music: Like Movies, this folder doesn't leave much ambiguity. The most notable app to make heavy use of this directory is iTunes, which stores all of its music, movies, podcasts, and iPhone/iTouch applications. It is not uncommon for users to sneak in 10-15 gigabytes of data into this folder.

• Pictures: This folder is utilized for picture storage. iPhoto maintains its database in this folder, as do other third-party photo organizers.

• Public: This folder serves as a public store for other users. This folder is readable by all users on the machine, and serves as a place for a user to save work and allow other user's access to it. This folder also contains a Drop Box, where other users can leave work, only to be viewed by the home folder's owner.

• Sites: This is a per-user web folder utilized by the OS X's web server. Users can implement their own html sites here and access them at http://servername/~username.

A user's home folder is their own private repository, meaning there are access restrictions in place to prevent other users from violating this privacy. However, there are a few limitations to these restrictions that are important to know about, both as a user and as an administrator. The most notable characteristic is that the root of the user's home directory is world-readable. That is, every user on the computer can read and open any item placed in this directory. This is primarily notable in that many users have absolutely no qualms saving items in the top level of their home directory, unwillingly exposing these items to any user on the system. You do not want your users to fall into this habit, especially if you are dealing with sensitive data. It is important that you train your users to properly utilize the folder structure in place. If you have a user base that is particularly unwilling to learn, in some cases it may be desirable to simply restrict users from saving directly into this folder, forcing them to save to an existing subdirectory. Read on to the "User Templates" section to learn how to do this.

Another notable characteristic of the default restrictions in a user's home folder is the use of ACL's to maintain the in-place folder structure. Specifically, all of the default folders contain an 'everyone deny delete' ACL to prevent their removal.

[helyx:/Users/hunterbj] hunterbj% ls -el
total 0
drwx------+  9 hunterbj  staff   306 Jan  9 12:37 Desktop
 0: group:everyone deny delete
drwx------+  4 hunterbj  staff   136 Jan  9 00:46 Documents
 0: group:everyone deny delete
drwx------+  4 hunterbj  staff   136 Jan  9 01:24 Downloads
 0: group:everyone deny delete
drwx------+ 30 hunterbj  staff  1020 Jan  9 12:18 Library
 0: group:everyone deny delete
drwx------+  3 hunterbj  staff   102 Jan  9 00:46 Movies
 0: group:everyone deny delete
drwx------+  3 hunterbj  staff   102 Jan  9 00:46 Music
 0: group:everyone deny delete
drwx------+  4 hunterbj  staff   136 Jan  9 00:46 Pictures
 0: group:everyone deny delete
drwxr-xr-x+  6 hunterbj  staff   204 Jan  9 01:23 Public
 0: group:everyone deny delete
drwxr-xr-x+  5 hunterbj  staff   170 Jan  9 00:46 Sites
0: group:everyone deny delete

These ACLs ensure that a default baseline is maintained across all user directories on the system.

The standard home folder also provides a means for users to privately exchange files with other users. This is implemented through the 'Public' and 'Sites' directories. As can be seen the previous output, these folders are the only folders inside a default home folder that are world-readable. The Public folder is meant for file exchange. A user can place an item inside of their public folder and it will be then accessible to all users, but only with read access. They will not be able to make changes to any files. However, they do have the ability to upload new files. Inside of every users Public folder, there is a directory named Drop Box. This drop box folder is world-writeable, but not world-readable. This means that user's can place items into this folder, but they cannot see any of the items inside (including their own). The Drop Box folder is, of course, accessible to the home folders owner, so only they can see items left for them in this directory. Though everyone has write access to this folder, a user will not be able to overwrite an existing file with the same name created by a different user, only their own.

The Sites directory is a unique directory, and requires that Web Services be enabled for it to be utilized as intended. When web services are available, users can place items in this directory and they will be accessible for public consumption via a standard web browser. For instance, a user could place a PDF file, like presentation.pdf, into their sites folder. Other users would then be able to download and review this document in a web browser through the url http://clientip_or_dnsname/~username/presentation.pdf.

In large environments, the functionality of the Public and Sites folders can be less attractive when used with local home folders, and in such environments these folders are typically barren. Each workstation must have file and/or web services enabled, each with their own data stores. Other users must remember both the node to connect to as well as the user's short name. In small workgroups, bonjour discovery largely combats this problem, so all workstations on the same subnet with File Sharing enabled will be automatically listed under the Shared group in the Finder sidebar. Conversely, Safari's bonjour network discovery feature makes it easy to discover local machines running http services via Web Sharing. In a Windows environment, a Mac OS X workstation with SMB sharing services enabled will behave much like a native Windows machine.

In environments such as heavy media where workstation performance is paramount, behind the scenes file server activity may be an unwelcome resource drain. Network home folders, are better suited for use here. Data is centralized and can be served out from fewer points (if not a single point), so resource utilization can be better tracked, managed, and scaled. From an end user's perspective, a user only need remember the server's address and their coworker's short name to find the resource that they want.

Local home folders have their advantages and disadvantages. Their primary advantage lies in their minimal reliance on infrastructure. You need not have super robust network or storage systems to maintain a good user experience. All user resources are stored locally on a user's desktop internal storage, storage which will typically provide the fastest, lowest latency access to data. For this reason, local home folders are often desirable whenever performance and user experience is paramount.

The disadvantage in local home folders lies in the decentralization of data that is inherent in such a model. All data maintenance routines become more complex as you now have to deal with each individual node to gain access to data. This is particularly true for the deployment of file-system security auditing and policy enforcement. For instance, if data retention requirements require that all user data be backed up, then support requirements to manage and maintain the backup system to provide coverage for all of your nodes will increase. This isn't a big deal for a few dozen nodes, but scalability is definitely a consideration that needs to be made. Luckily, there are tools available to aid in this type of management, such as Apple Remote Desktop.

7.3.1.1. Local Home Folder Configuration

The process of configuring a user with a local home directory depends mainly on the directory services model that you are working with.

7.3.1.1.1. No Directory Services

If you have forgone the option of a centralized directory service, then your primary interface will be the Accounts pane of the System Preferences Application. The System Preferences Application can be accessed under the Apple Menu, in the Dock (by default), or by opening the application located in the Applications folder. As mentioned previously, any account created using this tool will receive a home directory in the default directory of /Users. However, introduced in this tool with Mac OS X 10.5 was the ability to specify an alternate directory as well as make additional modifications. This interface can be found by right-clicking (or control + click) on any account listed and selecting Advanced Options. As shown in Figure 7-18, you have the ability to change numerous attributes including User ID, Group ID, shortname, shell, and home directory. Additionally, you can change the user's GUID or assign aliases to the account.

7.3.1.1.2. Open Directory

If you are utilizing Open Directory for your directory system, you'll define your home directory for your users by utilizing the application Workgroup Manager.app found on any server in the folder /Applications/Server. This utility can also be installed on any OS X client machine by downloading and installing the Server Admin Tools package available on Apple's support site (http://support.apple.com/downloads/#server%20admin%20tools).

Once installed, open the application and connect to your server. To assign a user a local home directory, go to the Home tab with the appropriate user selected. Listed in this tab will be any predefined home directory paths as well as any configured automounts. As shown in Figure 7-19, /Users is the default home directory location and will typically be a predefined option. If this is not the case, you can manually specify the path. Once a path has been defined for any user, it will be listed as a predefined option. To manually specify a new local path, first note the user's short name, found under the basic tab then click the plus button. In the "Full Path" field, enter in the local path for that user. For instance, if I want to utilize the standard /Users directory for user with short name bob, then I would enter the value /Users/bob. From then on, the /Users path will be listed as an option in the list. You can also mass select users and assign them the homedirectory path with a few clicks.

7.3.1.1.3. Active Directory

Configuring Active Directory users to utilize local home directories can be done in a few different ways. If all Active Directory users on the machine are going to have local home directories, then the most straightforward way to do this is by utilizing the Force Local Home on Startup Disk option in the Active Directory plug-in. Alternatively, the Create mobile account at login option will provide the same effect, with a few differences. When used, the latter option will create a mobile account, caching all user information locally for any user that logs in. For more information on Active Directory see Chapter 3.

7.3.1.1.4. Third Party LDAP Directory

Configuring LDAP users to utilize local home directories can be done in a few different ways, depending on your user implementation. If your LDAP schema already contains the homeDirectory attribute it is typically utilized for this purpose. You just need to map the NFSHomeDirectory attribute in Directory Utility. Each user will need the value of this attribute set to /Users/shortname in your LDAP database. Upon login, they will be assigned a home directory in the /Users folder. If your LDAP schema does not support this attribute, you have a few options. The cleanest way to implement this without altering your schema is by mapping the RecordType NFSHomeDirectory to value #/Users/$uid$, where uid is the attribute that is utilized for the user's short name. This sets all users home directory to the path /Users/shortname. The big limitation here is that all users on this machine will have their home directory in /Users, which may not always be desirable. To maintain granularity, you would either have to extend your schema to support the homeDirectory attribute, or you can utilize an existing, unused LDAP attribute. To perform the mapping, use Directory Utility to map the NFSHomeDirectory record to the appropriate value, and ensure that home path values are pre-populated for all of your users. See Chapter 2 for more information on attribute mapping with LDAP.

7.3.2. Network Home Folders

Network home folders are structured identically to local home folders. They contain the same subdirectories that perform the exact same function. The difference between the two lies in where a user's data is stored. When a user with a local home directory logs into a computer, that user's home directory will be stored on that computer's hard drive. Any new files that the user creates will be stored locally to that drive. When that user later logs into a different computer, they will not have access to any files created on a different computer. If your users move from computer to computer, this creates a problem. It's certainly possible to enable file sharing on all of the workstations, so users could connect to the other computer and access their data, but this quickly turns into an unmanageable nightmare. Users need to remember which computer has which document. Those documents will get duplicated and version tracking will go out the window. Your users will be miserable, and you, in turn, will be miserable. Most often, a centralized file server comes into play, offering users the ability to upload their files and then they will be able to access them from different nodes by connecting to that server. The central flaw here is that it promotes the illusion that data is centralized. Often times in these scenarios, desktop resident data is completely forgotten. If it's not on the server, it doesn't exist, and doesn't require protection. This mind-set can lead to expensive mistakes because your data is only as protected as your users are regimented.

Enter network home folders. Network home folders store data on a network file server. (It's not just a clever name.) When a user logs into a computer, the user's home directory is never stored on that local machine, but rather directly referenced from a remote network file server. When a user creates or edits documents, those documents are actually updated on a remote server. This all happens transparently, unbeknownst to the user. The main benefit provided by this is mobility. By freeing user data from the embrace of each individual workstation, users are capable of freely moving from node to node, traveling with them their entire computing experience. If your organization does not use assigned workstations, with network home directories, your users will enjoy a single experience wherever they login. The benefits of this experience are reaped by IT as well. The advantage of having all user data centralized on the home directory server(s) is not small. Indeed, the ability to mass deploy software, settings, files, audit security, and provide data protection are all greatly increased when data is consolidated.

OS X currently supports home directories over a handful of network file protocols, such as AFP, SMB, as well as NFS. AFP is your native protocol and will typically be your first choice when available. SMB support has greatly improved in OS X over the years, and can be utilized for an acceptable experience as well, though it will typically be relegated to environments with Windows-based file servers. NFS flaws are traditional to the protocol, security being the primary barrier. However, the introduction of Kerberized NFS in 10.5 provides improvement here, trusting your environment globally supports it.

The network home folder model is not without its flaws. The largest barrier to entry is the necessary server-side resources needed to provide an acceptable computing experience, let alone approach the performance provided by fast local storage used by local homes. Robust server, network, and storage infrastructure are needed. Gigabit Ethernet to the desktop will help and to the server is also highly recommended. A dedicated Intel Xserve with fast external RAID storage and gigabit Ethernet can acceptably host 40-50 simultaneous light to moderate users when implemented properly. This is not a hard limit or a guarantee because the qualification for "acceptable performance" will vary greatly from workflow to workflow and from user to user. If performance is paramount in your environment, or if you are unfortunate enough to host particularly feisty users, then the decision to migrate to network home folders should not be taken lightly.

Special consideration must be paid to your user's workflow to identify data usage patterns, which can be detrimental to a file server. Economies of scale play a large role here. If all of your users run applications that are IO heavy, then all of those transactions hit the wire, and your server will begin to lag. Likewise, if your users are in the habit of dealing with large data sets, then even a gigabit pipe on a server can be easily saturated. Luckily, Mac OS X supports 802.3ad link aggregation, also referred to as NIC bonding. This is the process of taking two network interfaces on a server, and presenting them to the network as a single unified connection. This provides benefits both in redundancy and in throughput. It doesn't offer perfect 50/50 load balancing, because your switch must support it and it will disable Lights Out Management (LOM) capabilities on your Xserves. LOM is a big advantage for server management, so it is recommended to utilize a PCIe-based NIC if you plan to go this route. This is a good way to provide a larger pipe into a server and combat saturation in data heavy environments.

7.3.2.1. Redirection

As previously mentioned, network home directories are both a blessing and a curse. On one hand, they provide a very valuable service to any environment where users do not have pre-assigned computers and may move about from node to node at will. However, if you take into account all of the various activities that can occur inside a user's home directory, it quickly becomes apparent that the overhead necessary for deploying the storage infrastructure to handle the burden imposed by such activities is not insignificant. An IMAP account of even a moderately sized user mailbox can easily contain tens of thousands of files. A user logging into a computer results in a flurry of activity as numerous components load their support files. There is the occasional application in which file system needs are particularly burdensome on a file server. iPhoto and other media management applications involve not only high levels of I/O requests, but they can also be throughput intensive when used with higher quality or uncompressed media. Another class of horrible offenders are video editors, as they require a consistent, uninterrupted data stream. While most high-end applications of this variety rarely use the home directory for media storage, the nearly ubiquitous iMovie does. Even at its lowest quality, DV media played in iMovie requires a 5MBps stream, and things get worse with HD formats. The main thing to understand is that if your user's standard usage patterns involve high I/O or high bandwidth activities, the viability of network-based storage deteriorates. However, their exclusion shouldn't be a forgone conclusion.

Redirection is the process of utilizing symbolic links in a network home directory to redirect traffic to a local disk. For instance, if your users utilize IMAP mail (you're not using POP, right?) then there's no reason to let that traffic burden your server. Through redirection, you establish a symbolic link at ~/Library/Mail which redirects traffic to a local path of your choosing, say /Users/theUser/Library/Mail. This way, whenever you start up mail, all of your data will be accessed off of your local disk. When a user migrates to another machine and opens up mail, it will need to re-download any messages, but this will be of minor consequence compared to the alternative. The typical candidate for redirection is ~/Library/Caches, which contains a decent amount of application cache data that has no business burdening your server. The use of this folder was slightly mitigated with the introduction of 10.5 and the /var/tmp/folders caching structure, but it is still used and redirection will definitely lighten the load on your server. If your users have large numbers of fonts, redirection of the ~/Library/Fonts folder can help to reduce login times. However, this can often present its own management problems. For this reason, it is encouraged to install Fonts at the machine level in /Library/Fonts, or to utilize Font management software, such as Extensis' Universal Type Server.

Implementation of redirection can be deployed with two distinct methods. The first method is new to 10.5 and involves the use of MCX and the preference manifest provided by /System/Library/CoreServices/ManagedClient.app. Specifically, you will be editing the preference manifest for domain com.apple.MCXRedirector. When you create a new key, the Always target provides three different keys to choose from:

• Login redirections: These are redirections which are fired upon login.

• Logout redirections: These are redirections which are fired upon logout.

• Other redirections: These are fired periodically whenever policies are set. After a network change, login, logout, or reboot.

The former two are primarily the ones we're interested in. You can have a login hook that creates your symbolic links at login, but then destroys them at logout.

Once you have created your MCXRedirector key under the always target, you want to set the key Login Redirections. With the new Login Redirections key highlighted, you create yet another key, which is used to define your redirect actions and paths. The redirection system provides you with four actions to choose from:

• deleteAndCreateSymLink: This action deletes the network folder and creates a symbolic link to the specified local path.

• renameAndCreateSymLink: This action renames the existing network folder, prepending "Network" to the name of the directory. After renaming, it creates a symbolic link to the specified local path. Unfortunately, due to the lack of consistent logout cleanup, I recommend avoiding this option and instead utilizing a login hook, which gives you much more flexability. However, this option can be used instead of deleteAndCreateSymLink to ensure that you avoid deleting user data.

• deletePath: This action simply deletes any item at the specified path.

• deleteSymLinkAndRestore: This action is the counterpart to renameAndCreateSymLink. Essentially, it will delete the existing symbolic link and restore the previously renamed directory. Unfortunately, this option does not function reliably. For this type of functionality, I recommend implementing a login hook.

For these purposes, you are going to choose the second option. This allows you to maintain a network version of the redirected folder, but promotes local storage for the primary folder itself. Thus, if you were to perform redirection of the Movies folder because your users utilize iMovie, then they will have the ability to access their network movies folder at ~/Movies (Network). This provides your users with the ability to manually copy files to the network folder to facilitate migration to a different machine. At the same time, it relieves the burden of iMovie's heavy data usage from your server. While a user's movie media may not seamlessly transfer with them like the rest of their homefolder, it is an acceptable compromise in many environments.

To finish the policy creation, you will specify your Folder Path, which is ~/Library/Movies. You also want to specify the Destination Folder Path key, which signifies the local path that will house your data. For this, you enter in a value of /Users/%@/Movies. As discussed in Chapter 8, %@ is a variable for your user's shortname. Thus, when bob logs in, his home directory movies folder actually references /Users/bob/Movies.

To ensure a clean environment, you might also want to deploy a logout redirection, which deletes all of the redirections that you created at login. To do this, you will create a new Logout Redirections key under your Always target, and create a new "deletePath" action key. The key Destination Folder Path is ignored by this action and can be removed. The path specified by Folder Path is used to determine the alias to remove. If you specify the value ~/Movies, the action will delete the symbolic link at ~/Movies, but will leave the data on the local disk untouched. It will also rename your Movies (Network) folder back to just Movies and order is restored to the universe (see Figure 7-20).Unfortunately, at the time of this writing, this functionality is only partially functional.

Basic redirections deployed through MCX are quick and easy, and they work. However, there are a few implications that will determine their usefulness in your environment. The biggest gotcha is that they require 10.5. 10.4 clients will pretend they don't exist. The second consideration is in regard to MCX itself. MCXRedirector can be deployed at any level, user, group, computer, or computer group. For reasons previously discussed, I discourage the use of user-level management, though it's important to recognize that the granularity that they provide can be useful. If you only have a couple of network home users, this may be a good option, but utilizing a group for this still scales better. It is also recommended to avoid deploying these at the computer or computer group level.

The main reason for this is that these redirections are user agnostic. That is, when they're deployed at the computer level they will redirect the folders of all users who login, even those with local homes. This isn't a terribly big deal, but it's unnecessary and unsightly. If you use /Users/%@/... as your redirection store, or if you utilize portable home directories (discussed in the section "Home Directory Syncing" later in this chapter) then you will definitely have problems. Therefore, this really leaves you to deploying at the group level. This works for the most part, but what if certain users should have network homes on some computers (wired nodes), but should also have local homes on others (laptops)? If you deploy redirects at the group level, then you get your redirects on your local homes. This example illustrates the main problem with MCX-based redirections. There is no way to introduce them with logic.

This leads you to the other method of redirection: loginhooks. Because of the unparalleled freedom that you have, redirecting folders is just a few lines of code away, or not. Login hook scripts, when done properly, require a decent amount of logic. A very basic login script is pretty easy to assemble.

#!/bin/sh
PATH="/bin:/usr/bin:/usr/sbin"

# simple login redirection script

# get our user
theUser=$1

# get our home
eval theHome=~$1

# if we are a local user, exit
if [ -x "/usr/bin/nicl" ]; then
# 10.3 & 10.4 test
[ $(nicl . -read /users/"$theUser" &> /dev/null) == 0 ] &&
echo "User is a local user, aborting! " && exit 1
elif [ -x "/usr/bin/dscl" ]; then
#  10.5 test
[ $(dscl . -read /users/"$theUser" &> /dev/null) == 0 ] &&
echo "User is a local user, aborting! " && exit 1
else
        echo "DS Tool not found. " && exit 1
fi

# specify our redirect folder, make sure it exists,
# set ownership and permissions
redirectDir=/Users/Local/"$theUser"
mkdir -p "$redirectDir" &> /dev/null
chown "$theUser" "$redirectDir"
chmod 700 "$redirectDir"

# redirect ~/Library/Caches. For 10.3 compatability,
# operations on the home directory must be performed as

# the user. root does have write access to AFP shares.
mkdir -p "$redirectDir"/Library/Caches
sudo -u "$theUser" rm -rf "$theHome"/Library/Caches
sudo -u "$theUser" ln -s "$redirectDir"/Library/Caches 
"$theHome"/Library/Caches
chown "$theUser" "$redirectDir/Library/Caches"
echo "Redirected $theHome/Library/Caches to 
$redirectDir/Library/Caches"

exit 0

Then the requisite logout hook (don't blink).

#!/bin/sh
PATH="/bin"

# simple logout redirection script

# get our user
theUser=$1

# get our home
eval theHome=~$1

# if there's a symlink, break it down
[ -L "$theHome"/Library/Caches ] &&
rm "$theHome"/Library/Caches &&
echo "Removing symlink at $theHome/Library/Caches"

exit 0

For the logouthook, you don't need to test for a local user. If the users are local they won't have a symlink to begin with. If they do, it shouldn't be there, so you may as well delete it.

This is a pretty bare-bones login redirection script, and it doesn't have a ton of sanity checks. What if the destructive redirect destroys valuable data, and you need to move it rather than delete it? What if a user is logged into two sessions at once? When one instance is logged out, the other's symbolic links will be torn down, leading to an unstable environment. Therein lies the strength in loginhook based redirections, you can pretty much add any functionality that you're willing to invest time into scripting. Luckily, we've invested that time so you don't have to. For a more feature packed login script, see the package 07_loginhooks.zip in the book's resources. You can find the code samples for this chapter in the Source Code/Download area of the Apress web site, www.apress.com. This zip file contains two shell scripts, loginhook, and logouthook, which are used to create and tear down redirection environments. See the loginhook scripts inline comments for more details on configuration and usage.

Unfortunately, in reality network home directories just aren't well suited for certain uses. Apple discourages their use in Final Cut Studio workflows. Color in particular seems to have the most issues, it simply doesn't launch. Miscellaneous apps that are poorly coded may simply not behave properly. Sometimes these apps can be fooled into operating through redirections or preference modification, but not always. Make sure to take care to thoroughly test your productivity apps before deploying network home directories on a wide scale.

7.3.2.2. Network Home Folder Configuration

Depending on your directory service model, you will utilize either Workgroup Manager or Directory Utility to configure Network Home Directories. While it is possible to implement network home directories in environments without centralized directory services, their presence is highly recommended.

7.3.2.2.1. Open Directory

In order to assign a user a network home directory in an Open Directory environment, you must first configure the home directory SharePoint and automount, specifying the automount as your user's home directory. When logging in as a network home user, the bound client will utilize values stored in the user's record as well as the configured automount information in order to properly mount the user's home.

To configure the SharePoint and automount, you utilize the Server Admin application, located in /Applications/Server. Once open, ensure that your file server appears in the list, and add it if necessary. With the main server entry selected, highlight the File Sharing section and then the Share Points subsection. For this example, you will utilize the existing Users SharePoint, though it doesn't have to be. The big gotcha here is that spaces were not allowed prior to 10.5, so the SharePoint User Homes won't work out so well. With the Users SharePoint selected, check the box to enable automount. Once checked, you will be presented with a sheet to specify automount configuration, as shown in Figure 7-21.

Here you can select your protocols and your mount point. As this SharePoint will be utilized for user home folders, you select that option and save. This SharePoint has now been configured to be utilized for network home directories. You can verify this by observing your Open Directory Mounts container with Workgroup Manager's Inspector or with dscl.

[myserver:~] hunterbj% dscl /LDAPv3/127.0.0.1/ read 
/Mounts/myserver.com:/networkHomes RecordName VFSLinkDir VFSOpts 
VFSType

RecordName: myserver.com:/networkHomes
VFSLinkDir: /Network/Servers/
VFSOpts: net url==afp://;AUTH=NO%20USER%[email protected]/networkHomes
VFSType: url

An automount record contains four essential attributes in your directory. The RecordName attribute follows typical NFS mount syntax; the server's IP or DNS name, a colon, and then the path to the share. In this case, it will be the full file system path of the share from root of your server's file system. Therefore, if your "Users" SharePoint resides on a secondary volume (as it always should), then your mount RecordName might be myserver.com:/Volumes/dataVolume/networkHomes. The path portion of value is utilized clientside as the file system mount point for the automount. The VFSLinkDir attribute specifies the base path, which is prepended to the path provided by RecordName. In the previous scenario, a client machine would mount the user's home directory at /Network/Servers/hax.lbc/dataVolume/networkUsers.

One important limitation to know about here is that there is a character limit to an automount pathname when use specifically with network homes—the entire path, including /Network/Servers, cannot contain more than 89 characters. This leaves 72 total characters at your disposal. In 10.3.5-10.4.11, the automount path was at /private/Network/Servers/ which allowed only 64 usable characters. Prior to this, there was a slew of rubbish leaving you with only 39 characters. 72 characters is actually ample for most environments, but if you find yourself running against this limitation, you do have a couple of options.

The first recommended option is the cleanest, and it cuts out a decent amount of fat depending on your environment. In fact, it's so clean that I often deploy it even when the limitation is not a concern. The basic concept is that you map the top level of your share's path to the root of your file system. To understand this, consider the previous example, where the automount mount point for the "Users" SharePoint was at /Network/Servers/myserver.com/Volumes/dataVolume/networkHomes. This path contains over 19 characters which only apply to a single machine, the server itself. Your remote clients only know about the server name (myserver.com) and SharePoint (Users). Why can't you cut out all this excess, like /Volumes/dataVolume/networkHomes? In fact, you can confidently bypass this once you realize a few things about automount behavior. First, every OS X machine has a symbolic link at /Network/Servers/fqdn. On myserver, the command ls -l /Network/Servers/myserver.com/networkHomes yields the same results as ls -l /networkHomes.

Thus, by placing a symbolic link of the sharepath to its basename on the root of the file system, you can simulate this on the server:

$ln -s /Volumes/dataVolume/networkHomes /networkHomes

Once run, /Network/Servers/myserver.com/networkHomes is a fully functional path to your data. All that's left to do is modify the automount data, replacing the old path with your modified version.

The VFSOpts attribute specifies that this is a dynamic AFP automount. The ;AUTH=NO%20USER%20AUTHENT string specifies that the machine will first attempt to mount the automount as guest. Once a user logs in, it will reconnect to the SharePoint with the user's access levels. However, there is an important ramification here. If you have a limited license server, each connected home directory user will utilize two connections. This value can be changed to ;AUTH=Client%20Krb%20v2 to utilize Kerberos authentication on the automount. Alternatively, an authentication string can be dropped all together. Loginwindow will dynamically authenticate and mount the share.

VFSOpts: net url==afp://;AUTH=Client%20Krb%20v2/hax.lbc/networkHomes

Though SMB based home directories are supported, there is no GUI to perform this configuration in an OD-based environment. However, you can modify your automount's uri to specify the smb or cifs protocol:

VFSOpts: net url==smb://hax.lbc/networkHomes

To create an automount from the command line, you would perform the following:

dscl -u mydiradmin /LDAPv3/mydirsirv.myco.com
> delete Mounts/hax.lbc:\/Users VFSLinkDir /Network/Servers
 > create Mounts/hax.lbc:\/Users VFSLinkDir /Network/Servers/
 > delete Mounts/hax.lbc:\/Users
 > create Mounts/hax.lbc:\/Users VFSType url
 > create Mounts/hax.lbc:\/Users VFSOpts net
 > append Mounts/hax.lbc:\/Users VFSOpts url==afp;AUTH=NO%20USER%[email protected]/Users
 > append Mounts/hax.lbc:\/Users VFSLinkDir /Network/Servers/
 > read Mounts/hax.lbc:/Users

Open the application and connect to your server. To assign a user to a local home directory, go to the Home tab with the appropriate user selected. Listed in this tab will be any predefined home directory paths, as well as any configured automounts. /Users is the default home directory location and will typically be a predefined option in the list. If this is not the case, you can manually specify the path. Once a path has been defined for any user, it will be listed as a predefined option. To manually specify a new local path, first note the user's shortname, found under the basic tab, then click the plus button. In the Full Path field, enter in the local path for that user. For instance, if I want to utilize the standard /Users directory for user with shortname bob, then I would enter the value /Users/bob. From then on, the /Users path will be listed as an option in your list. You can then mass select users and assign them the home directory path with a few clicks.

7.3.3. Home Directory Syncing

Also referred to as Portable Home Directories, Home Directory syncing provides the ability to allow a user to use a local home directory, but also periodically synchronize files with a network home directory. This type of setup is great for users who utilize both a personal laptop and a wired desktop machine. In such cases, the wired desktop machine could utilize either network home directories, or it could be configured to utilize a local home, and then sync the content with a network home directory as well. In either case, you can configure settings which manage these preferences, specifying specific folders to include in the sync, and the interface also provides a very capable filtering system to easily ignore cache files and other machine-specific files.

Home directory syncing is broken up into two different sync types: Login/Logout syncs and background syncs. As the name suggests, Login and Logout synchronizations fire upon the beginning and end of a user session. The best utilization of login/logout syncing is probably best described by the setting's preference keys: syncedPrefsFolders. That is, this option is best used for application preference files, or any file, which during a user session is constantly in use and therefore not a good candidate for background syncing. By default, Apple specifies two folders to sync at login/logout: ~/Library, and ~/Documents/Microsoft User Data. The Former option includes Application preference and support files, Safari and Firefox bookmarks, and User Fonts. The latter folder contains many Microsoft Office settings, most notably the Entourage database.

Background synchronization, as its name implies, synchronizes files and folders in the background during an active user session, by default every 20 minutes. As mentioned, not all files are good candidates for this. For the most part, background synchronization should be configured for user-generated content, such as the Desktop and Documents folders.

One thing to consider is that Login and Logout syncing can cause significant delays in the login and logout process as the user must wait for the synchronization to finish before they can begin to use the computer or close the laptop's lid for the day. Because of this, users may be very prone to simply hitting the cancel button. Essentially, if you do not build a very specific login item sync list, then the entire login syncing process will likely be compromised due to user intervention. The entourage database is a great example of this. Entourage databases can reach gigabytes in size, and even a wired computer will take a good chunk of time to send this data to the server. Most users will not find a 30 minute login time to be acceptable. So, keep this list slim. If you need to synchronize Firefox bookmarks, explicitly specify the folder ~/Library/Application Support/ Firefox. Use ~/Library/Safari for Safari but use ~/Library/Preferences for all user application preferences. Avoid directories with deeply nested hierarchies, as these will cause syncing delays as the system scans through everything. For the grunt of the work, background syncing is your go-to player. 10.6 has some good improvements here, does a better job in general of informing you of when a particular set of items will sync, and gives you better control over the process.

One other noteworthy aspect of login/logout synchronizing is that the system has detection routines to determine if another computer has synchronized changes. If, upon logging in, the FileSyncAgent, which is responsible for synchronization, detects that the user has had an active session on another machine, it will present the user with a dialog stating that another login session was detected. The dialog will ask the user if they would like to delay syncing. Upon the next sync the system will require the user to choose a default conflict resolution source, presenting the option of local files versus network files. This setting is then applied to all items for that synchronization. This differs significantly from conflict resolution on background synchronizations, which allows you to specify the preferred source of each conflict individually.

If you have sync settings applied to a user account, upon first creation of the account, a complete sync of both login items and background items is required in order for the login process to complete. If the initial synchronization is cancelled, then the login will fail and the user will be returned to the login window. Make sure that if your user's have large home directories that you set this expectation when you deploy the change. Subsequent login syncs will attempt to perform a synchronization of background items as well, but they can be cancelled without detriment to the login; the sync will simply pickup where it left off during the next scheduled scan. Alternatively, if you are running 10.6, you can specify better control preference syncing vs. background syncing, and specify that background syncing items do not sync at login or logout.

To configure a user to utilize a portable home directory, you use a process that is a bit of a hybrid between a network home directory user and a mobile user with a local home directory, often referred to as a Portable Home Directory. In Workgroup Manager, the desired user must have their home directory specified to a configured automount SharePoint, exactly as you would configure a user with a network home directory. Once this is configured, you must specify mobility management for the user, such as you would do when setting up a user with a local home directory. Once you have done this, you must use managed preference to define the user as a mobile user. For the purposes of this exercise, you are going to utilize a computer group named "Mobile".

First, open up Workgroup Manager and connect to the Open Directory Master. Next, find the desired management object to apply the managed settings to. Once selected, open up the Mobility pane in the preference management section. In the default Account Creation Tab, under the creation section, select the option to create a mobile account at login, but do not require confirmation, as shown in Figure 7-22. Click Apply.

After this change, when the user logs into a computer that is a member of this group, a mobile account will be created—a copy of the user Open Directory record is copied into the local directory services store. This record contains the user's password, and enables the machine to permit a user to login to the computer even when the machine cannot contact the Open Directory server. Creating mobile accounts is an absolute must on laptops that will routinely leave the company campus and thereby lose access to company internal servers. In fact, in many wired-desktop environments, it may be desirable to force mobile accounts for users. This creates a more robust desktop setup that will more gracefully deal with any Open Directory outages. There are not many benefits management-wise to not create a mobile account for any user who will utilize a local home directory.

Now that you have configured mobility, you must also configure the actual syncing settings. You will first configure the login syncing, called preference syncing in 10.6. In this particular instance, you will be syncing the user's preference folder, their personal applications folder, and their Firefox and Safari bookmarks. Respective GUIs are shown for 10.5 and 10.6. Notice that the 10.6 GUI on the right has specific checkboxes allowing for granular control of when certain items sync (see Figure 7-23).

Next, you will configure the background syncing options, called Home Syncing in 10.6. In this instance, you will synchronize the User's Desktop and Documents folders. You are not concerned about other media content, such as Pictures, Movies, and Music. Users can certainly connect to their home folder manually (or you can mount it for them using MCX), and they can upload any media files that they deem important (perhaps only the server-side home directories are backed up). In this case, you want to make sure you exclude some potentially sync-busters, such as the Entourage database at ~/Documents/Microsoft User Data, or potential Virtual Machines at ~/Documents/Virtual Machines (or ~/Documents/Parallels if you are using parallels instead of VMware), as shown in Figure 7-24.

In order to reduce syncing times, Mac OS X 10.5 server introduced a new feature that would track server-side modifications to files. This adds additional logic to help a client and a server determine which files need to be synced and to help with conflict resolution. To disable server-side syncing, simply enable the option in server admin. With the main server entry selected, choose the settings tab. Under the general settings tab, you will be presented with the option to enable several OS X services, such as NTP serving, as well as Server Side File tracing for home directory syncing. When this option is enabled, clients will connect to the server via an ssh connection over port 2336. This connection is used to converse with the server to build an accurate change manifest. Once this is created, syncing is done per usual over AFP. If you do not enable this option, all change detection will be performed over AFP.

7.3.3.1. Troubleshooting Syncing Issues

Troubleshooting Home Directory syncing issues is something that you will inevitably have to deal with when you deploy them at a large scale. In the following few paragraphs, you will try to present a summary of the players involved to help you to determine the possible origin of different issues.

When syncing issues arrive, the first thing to determine is the breadth of the issue: Is the problem only occurring with a single user or is it affecting all user's with the applied management settings? One of the most common causes of syncing problems is due to conflicting sync settings. Your ~/Library/Preferences folder isn't going to sync if you exclude the ~/Library folder. Use the system_profiler and gmcxquery function discussed earlier to verify applied settings.

After this, consult the log file found at : ~/Library/Logs/FileSyncAgent.log and ~/Library/Logs/FileSyncAgent-verbose.log. Between these two log files, there will typically be evidence as to the nature of your problem.

If server-side tracking is enabled, then the client uses public key authentication to contact the server over port 2336. For this authentication, preshared keys are stored at ~/Library/FileSync/FileSyncAgent_key_dir. In this directory, there contains a public key and a private key used to authenticate to the server. In earlier versions of 10.5, if permissions of this folder were such that the user was not the owner, and did not have exclusive access to the keys, then authentication would fail. This would result in a complete sync failure. This issue was addressed in a point-release patch. The system now will detect permissions problems and repair them prior to attempting to connect to the home directory server.

If interested, you can view the ssh configurations for this service by consulting the files /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent_sshd_config and the corresponding client configuration at /System/Library/CoreServices/FileSyncAgent.app/Contents/Resources/FileSyncAgent_ssh_config.

If syncing problems persist despite your efforts, you can simply delete all of the user's Filesync databases, which will rebuild upon the next operation. Doing this operation will delete file history, it is possible that files present at one location will be deleted during the process. Because of this, and when working with syncing issues in general, it is never a bad idea to have a full backup of the user's data on both sides: server and client. If you are reasonably sure that all pertinent data exists at only one location, do yourself a favor and back it up prior to proceeding. With that out of the way, to delete the user's sync database, run the following commands from both the server and the client, replacing with the user's short name.

sudo rm -r ~theuser/.FileSync
sudo rm -r ~theuser/Library/FileSync

In the majority of scenarios, assuming the client is getting good MCX sync data, the previous action will resolve the syncing issues. If the problem still isn't resolved, you could try resetting ownership on the user's home directory, which may or may not be an issue:

sudo chown -R theuser ~theuser
sudo chmod -R o+rw ~theuser