Our lab Macs authenticate against an OpenLDAP server. Users have network home directories, accessed via AFS (as in Andrew File System), so their home attributes are of the form /afs/ir/users/*. (AFS root is mounted at /afs on all the machines.) Up through Panther we used a loginhook to redirect a lot of directories within these AFS homes to local disks, using symbolic links. For example, ~/Library/Caches, ~/Library/Preferences/Adobe/GoLive/Cache, &c. are all replaced with symlinks to new directories created in a secure user-owned location on the local drive.
Problem the first: After moving to Tiger, Word will not save a pre-exisiting document that has been opened and edited. Error messages abound. Investigation with `ktrace` shows a lot of thrashing about in ~/Library/Caches/TemporaryItems, so we change our cache redirection scheme. Now ~/Library/Caches remains in AFS, and we redirect around 20 subdirectories (~/L/C/Acrobat, ~/L/C/Adobe, &c.) to the local drive, *but* leave ~/Library/Caches/TemporaryItems in AFS. It's a pain to track down all the cache locations used by our other apps, but now Word saves fine, both to AFS and to local drives.
Second problem: AFS homes exhibit the same "Insert Object" problem as AFP/SMB homes. The first time Word is opened and "components are registered", all the functionality is there. The second time Word is opened, the "Insert Object" dialog has no entries in it. No equations, no graphs, no nothing.
Now since accounts with local homes do not have this problem, we open Word as our local admin user, then copy the resulting ~/Library/Preferences/Microsoft/OLE Registration Database 11 and ~/Library/Preferences/Microsoft/Office Registration Cache 11 to a world-readable location. A loginhook copies these files into place in LDAP users' AFS homes (symlinking to them is insufficient). This restores functionality for the LDAP user, but results in delays of 20-25 seconds every time the user logs in and opens Word. It turns out that Word determines whether the Registration Cache is invalid and needs rebuilding by storing in that cache the creation date of the Registration Database. When the database file is copied into AFS, the creation date does not go with it, since AFS does not store that particular metadatum. Word sees the wrong date in the cache and reregisters everything.
However, a creation date of 0 (the epoch) is reliably returned for files in AFS (at least using OpenAFS 1.4.1, as we do). So we alter the creation process for our pregenerated database and cache files. Log in as the local admin user, open Word, close Word, then use SetFile (from the Developer Tools) to change the creation date of the Registration Database to the epoch. (`date -r 0` is useful in determining the right value for your time zone. You'll know you have it right when `GetFileInfo -d` prints no output for the file.) Then open Word again, let it recreate the cache, close Word, and give the resulting files to LDAP users with a loginhook.
Third problem: There's still a significant delay in opening Word for the first time as it "optimizes the font menu". (I trust everyone is already removing the Do Fonts file to prevent Word from actually copying fonts into users' homes at launch; this is a different issue.) It turns out that the file involved, ~/Library/Preferences/Microsoft/Office Font Cache (11), is susceptible to symlink redirection, so we use the admin account to create a font cache for our full deployed image, put it in a world-readable location on the image, and have our loginhook symlink the user's cache to it. (Though first we check whether ~/Library/Fonts has any contents—if the user has installed his/her own fonts we let them create their own font cache.)
One caveat to all this is that we don't deploy Entourage. I imagine these tactics would work for those that do, but we haven't tested that combination ourselves.
That's all. I hope this info can be of use to someone—at least it should be Google-able now.
—IWC
_____________________________________________________
Subscription Options and Archives
http://listserv.cuny.edu/archives/macenterprise.html
No comments:
Post a Comment