Automounting NFS Home Accounts

In the lab where I work, we have networked home accounts for all our Mac users. These accounts live on an NFS RAID on another, non-Apple machine. This, as they say, "took some doin'," but we've had it working very reliably for some time now. It's a neat process, and one I'm rather proud of figuring out. So I thought I'd write a quick (yeah, right!) explaination of what we do.*

General Overview
Generally speaking, in our setup, three things need to happen:
1. The client must be set up to bind to the MacServer with the Directory Access application.
2. The client must automount the NFS RAID at startup so that home accounts are available for the user.
3. The MacServer must authenticate the user and specify where her home account is mounted.

On The NFS Server
I do not administer our NFS RAID. I am not an NFS expert, but I can tell you what I do know:
1. For our purposes, the entire directory containing the user accounts must be exported.
2. Root, I believe, should be mapped to root. It is crucial that the client system have root access to the NFS export.
3. Most typical NFS setups should work withouot a great deal of tweaking, but, if I remember correctly (it's been awhile since we set this up), that last root thing is a deal breaker.

On The Client
The client needs a couple things done to it:
1. The client must be bound to a properly configured MacServer (see below), using the Directory Access application. Most folks who've set up networked home accounts know how to do this. If you don't, read the manual. It's not hard.
2. The client needs to mount the NFS share, preferably at each startup. And this is where the fun begins. Our goal here will be to create a custom StartupItem that automounts our NFS export at each boot.**

For purposes of this example, we'll call our local mount point /home, and our NFS export we'll say lives at the IP address 192.168.1.100 in the folder /Users/Home. (If you're following along at home, feel free to substitute your own values for anything provided in these examples.)

To mount our NFS server, we use a command called automount. automount is sweet, and you can do a lot with it, which we'll get to in a minute. For now, a command you may want to use to test your NFS setup before adding startup scripts and whatnot, is the mount_nfs command, and it looks something like this: IPaddress_of_NFSShare:/path/to/share /local_mount_pointDon't forget to create that local mount point directory first:sudo mkdir /home So, for this example:sudo mount_nfs 192.168.1.100:/Users/Home /home This is a good command to use for temporary mounts of the NFS export. Anything mounted this way will unmount after reboot. Or you can simply use:sudo /umount /hometo umount the NFS share. Now let's get into automount. One of the cool things about automount is that it uses maps to call NFS and other shared disks. Once you've established a startup procedure, you can use maps to add, remove, or change your automount setup. This is handy if you're using scripts (which we are) because it means we really shouldn't have to ever change our scripts. Any changes can happen to the maps and are easy to do. The automount map file looks like this:home rw,net,tcp 192.168.1.100:/Users/Home The first field specifies the local mount point, the second field specifies NFS options (these work best for us, your mileage may vary, but the rw option is necessary and the net option is recommended), and the third field is the NFS export. Place these values in a space-delimited, plain text file, and call it something you'll remember. For our example we'll call it MyMounts. (Do not use a .txt file suffix on this file. Doing so will break all the examples to come.) automount syntax is fairly simple, if confusing at times. It looks something like this:automount -m /mount /path/to/mymountswhere /mount is where the NFS mount will be mounted. The -m flag tells automount to use a map file, the path to which is specified in the second argument to the command. automount then reads the map file, and grafts the home mount point to a symlink inside the directory /mount.*** So, with your NFS server properly configured, and your MyMounts file on your Desktop, if you do this:sudo automount -m /mount ~/Desktop/MyMountsYou should see your home mount appear in the directory /mounts. In Tiger, however, this initial mount point does not show up in the Finder. To see it, you must type "command-shift-g" and type /mount in the text field. Or you can look in the Terminal with:ls /mountYou should also see the mount point listed when using the df command in Terminal. If you don't see the /mount with home inside, something is wrong. You need to troubleshoot your NFS setup. If the share is there, move on to the next step. Once you've got automount properly mounting the NFS export, it's time to create a very simple StartupItem to handle all this at each boot automatically. This is about the simplest StartupItem imaginable. You need three files:1. A simple shell script2. Your MyMounts file3. A StartupParameters.plist filePut these in a folder, which we'll call MountNFS. If you're following along, you have the MyMounts file already, so that's done. Put it in the folder. Next, let's make the StartupParameters.plist file. This file just specifies a thing or two about how the startup item should run, and what messages it will generate. Copy and paste the following text into a plain text file, call it StartupParameters.plist, and save it to your MountNFS Folder:

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd"><plist version="0.9"><dict> <key>Description</key> <string>Automount NFS</string> <key>Messages</key> <dict
>      <key>start</key>      <string>Mounting NFS</string>      <key>stop</key>      <string>Mounting NFS</string> </dict> <key>OrderPreference</key> <string>Late</string> <key>Provides</key> <array>      <string>AutomountNFS</string> </array> <key>Requires</key> <array>      <string>NFS</string> </array></dict></plist>

Finally, we need the shell script, which simply looks like this****:

#!/bin/sh

### Automount NFS Export##

. /etc/rc.commonConsoleMessage "Automounting NFS"rm -rf /homeautomount -m /mount /Library/StartupItems/MountNFS/MountNFSln -s /mount/home /home

Copy this text into a new plain text file, and save the file as MountNFS (it must be the same name as the folder, and it must not end with a .txt or any other file suffix). Make sure it is executable:
chmod 755 ~/Desktop/MountNFS/MountNFS

So, this folder, MountNFS, becomes your actual StartupItem. At this point, you probably want to have this thing run at startup, and the way to do that is to place the MountNFS folder in /Library/StartupItems. (If the StartupItems folder doesn't exist, create it.) You should also set permissions on the MountNFS folder and its contents as well since Tiger will complain (and then kindly fix things) if there are any errors. The permissions should be set so that the owner is root, the group is wheel, and (I think) permissions on all files can be 755, so:
sudo chown -R root:wheel /Library/StartupItems/MountNFS
sudo chmod -R 755 /Library/StartupItems/MountNFS

Once NFS and automount are working properly together, and this StartupItem is in place, all you need to do is reboot your client Mac. You should see your NFS share mounted at /home. (If Tiger complains that the permissions are wrong after the first reboot, tell it to "Fix" the problem and reboot again. It's just making sure the permissions are secure, and if all's good, your StartupItem should work ever after.)

Congratulations! That was the hard part.

On The MacServer
As I said, home accounts for our Mac users live on a RAID which is shared via NFS. Authentication is handled (at present) by a MacServer. Briefly, this is what happens when a user logs in to one of our Macs:
1. When the user types in her username and password, the information is sent to the MacServer, which authenticates the user.
2. The MacServer also specifies where the home account of the user is located on the client machine, in our case, the NFS mount point /home.
3. The client allows the user access to the workstation, and places them in the home directory specified by the MacServer, which, again, is our NFS mount point /home.

This involves a little voodoo on the MacServer. Our MacServer users have their home accounts set in a way slightly different than what is generally done on OSX Server. Usually the home accounts are set to AFP or NFS shares that reside on the MacServer and that get automounted by the client. In this scenario, three fields are populated in the Workgroup Manager's home account settings for any given user. Go to the Home tab for any user, and click the edit button (the one that looks like a pencil) to examine these fields. The first field specifies where on the server the home account lives. The second field specifies the name of the folder for the home account (usually just the user's name). The third field specifies where on the client the home account will mount. In our setup, there is no AFP or NFS share on the MacServer itself, so the first two fields are irrelevant. The only field we need to concern ourselves with is the third field -- the one that tells the client machine where to find the user's home account. And all we need to put here is the absolute path to the mount point of our NFS share, which, by our example, would be /home/username. (Subsequent users can have their home directories indicated by simply selecting the new home location that gets created after setting this up. The "username" is assumed by Workgroup Manger, and does not need to be added for each user.)

That's it. Done.

If you've got all this set up properly, you should be able to reboot your client and log in to your Mac as a networked user whose home account is actually located on an NFS share on another computer. It's what we do, and it works great. And it allows us to centralize our Mac and Linux home account locations. Windows is another story. But we're working on it.

* NOTE: These instructions are for Tiger client authenticating to Panther Server. If details change when we get Tiger Server, I'll post them here.

** There is a simpler, though less elegant way to do all this if you don't feel like creating your own StartupItem. You can edit the existing /System/Library/StartupItems/NFS/NFS script. To do this, add the line:
automount -m /mount_point /path/to/mount_map
at the end of the "Start the automounter" section. This may, however, cause problems in Tiger client as the mount may not show in the Finder. Symlinks can be created here, as they are in our script, to alleviate this problem. The other problem with this is that system updates may overwrite this edit, causing you to redo everything. So I strongly recommend the custom StartupItem method outlined above.

*** Clever readers may notice that this method precludes mounting an export in a top-level directory in /. Unfortunately, using automount, the only way I've gotten it to work is by mounting the share inside the directory specified in the command, so if you want your share at the top level of the file system -- i.e. in / -- you'll have to symlink it. This is what we do. It works fine in Tiger (in fact, in Tiger the initial mount point -- in this case /mount -- doesn't appear in the Finder), but we had problems with this in Panther. In Panther we just used the nested mount point and lived with it.

**** This is the script we use for our Tiger clients. Tiger will not reveal the original mount point specified in the script in the Finder, so we use a symlink to the mount point for our actual home location. This is why you see symlink creation in the script. The first line destroys the symlink before recreating it at boot. If this doesn't happen, a broken link could interfere with the script. And, BTW, the symlink method was unreliable in Panther.

A Video iPod I'd Buy

I don't have an iPod. It's true. Frankly, I don't really have much interest in listening to music anywhere other than the comfort of my own home. When I listen to music, I want to sit there and actually listen to the music, not catch a bus or ride the subway or eat lunch or work out. (Yeah, like I work out.) And I hate earbud-style headphones.

There's been a lot of talk about the idea of a Video iPod for some time. As much as I'm disinclined to listening to music on-the-go, I'm even less interested in watching videos on-the-go. Particularly on a little, tiny, 2.5 inch LCD screen. Somehow I just don't think The Exorcist or 2001: A Space Odyssey would have the same impact, however titilating the idea of carrying around movies in your pocket might seem. And Steve Jobs would seem to agree. And so, for the longest time, the Video iPod has been tabled.

Fine by me.

Not too long ago, however, Apple came out with the iPod Photo. Now the iPod Photo is kind of a neat idea, though I doubt it would appeal to many people. The basic idea is that you can carry around photos and show them on your iPod. But what really takes this to the next level -- and by that I mean the potential of a Video iPod -- is the device's ability display photos on a television. Now we're talking. And I'd posit the theory that that's the real motivation behind the iPod Photo: to get people to wrap their brains around the idea of the iPod as a convergent device, one made to work with other media appliances in the home. Rest assured, if we do see an iPod video device -- and I think it's pretty likely at this point -- it will connect to your TV.

That's right, folks. You heard it here first.

Now to be perfectly honest, while this is a nice idea, I'm still not satisfied. Sure, there's a certain appeal to a bringing an iPod to a friend's house, plugging it in to his TV, and choosing from a list of movies to watch, all from a device that fits in the palm of your hand and operates on batteries. In fact, I like this idea a lot. But it's not a deal maker for me. I'm not sure it's something I want to pay hundreds of dollars for. Lots of folks will, but probably not me.

What will it take? Okay. I will tell you.

In addition to the iPod media player, Apple also makes a audio-video capture device. I'm sure you've heard of it. It's called the iSight. The iSight is a fabulous creature. It's essentially intended as a webcam. Unlike most webcams on the market, however, it captures audio and video via firewire rather than USB, and is therefore capable of producing some pretty decent looking, fairly high quality video. I have one and I love it. It's got a very grainy quality, and a nice saturated color palatte. It also produces deinterlaced video, so it has something of a film quality to my eye, though other things about the video it produces are distincly digital. Say what you will, the look is unique, and I think it's quite beautiful. Unfortunately, the iSight is hobbled out of the box. It's really only made to work with iChat, the video conferencing software made by Apple. You can get third party software, like the excellent BTV Pro, to take full advantage of the iSight, but there's nothing from Apple. Which is too bad, because in my humble opinion, the iSight is capable of so much more.

Enter the Video iPod.

For awhile now, I've envisioned a combination of these two ingenious devices. I've longed for an ultraportable video capture solution, and a Video iPod with iSight capture integration would more than fit the bill, provided, of course, the device allowed for full-frame, high-quality captures (or something close to it). Imagine: you've got your iPod, and you decide you want to capture some nice, decent looking video of you oversized poodle in Central Park. Don't have your video camera? No problem. Just whip out your iSight, plug it into your iPod, click record and go.

Sweet!

So far, Apple has shied away from the iPod as a capture device. Add-ons can be had to record audio to the iPod, but as far as I know, photos could never be captured to the iPod, and nothing in the realm of media aquisition directly to the iPod has ever been produced by Apple. So I really wonder if this is something Apple's even thinking about seriously. I worry that it isn't. But I will say, right here, right now, that if Apple (or anyone, for that matter) were to produce such a device, I would buy one in an instant. In a heartbeat. In a New York minute.

Hell, I might buy a couple.

On Another Topic Entirely...

Hey, so here's a post that has absolutely nothing to do with operating systems whatsoever. I'm so psyched.

(And yes, this will be a rant.)

First off, let me say, I'm a huge Final Cut Pro fan. I use it in my work, I teach a class in it, and I use it for personal projects. I've been using and loving it since version 1. In the school where I've worked for five years, I've managed to evangelize so effectively on the part of Final Cut, that when I started working in my department, Media 100 was the dominant editing software in my department, and now it's Final Cut across the board. I love it like an old friend. I feel that level familiarity with it. And I'm proud to be a Final Cut user.

That said, there's a feature I've been longing for in Final Cut Pro for quite some time now. I know I'm not the only one: I took a survey at some online FCP forum, god-knows-how-long ago, and it was among the top feature requests. I also spoke to someone who is a beta tester for FCP, and he also said it was a very popular feature request, and that, "It's coming." I was pretty sure that version 5 would include my feature. But after downloading a crack of the latest version (my department still has not received any software, which will be a perennial theme on this blog) I found that this feature had again managed to be excluded. What's the feature, you ask? Simple: Per-project scratch disks.

I'll explain.

When you first open Final Cut, you are prompted to choose the location of your scratch disk. The scratch disk, in case you don't know, is the place where, most importantly, all your captured media, among other things, goes. Anytime you capture from tape and digitize footage into Quicktime movie files, they go into the folder you've chosen as your scratch disk, into a subfolder named after your project. Now this is all fine and good, but file management in Final Cut -- and in video projects in general -- can be a real bitch. You've got all your project files, and you've got all these media files, and they're all over the place. This is actually true in all sorts of workflows -- graphics, web, audio, you name it. And many applications include utilities for managing media. Quark's "Collect for Output" is a good example: It takes all the media needed for a given project and puts it all into one folder for easy transport to a printer or client or wherever you may need to take it. Final Cut itself has a similar feature, the Media Manager, that allows you to do much the same thing. In fact, most programs that rely on multiple media files spread across the hard drive have some sort of media management tool. Great. I like this.

Now back to my feature request, again: per-project scratch disks. This seems to me an obvious solution to at least part of the media management problem. I tend to keep all my projects in seperate locations. Makes sense, right? You want to look at items that have something to do with your "Great Big Humongous Boil" project, say, so you go to the folder "Great Big Humongous Boil," and there it all is. But if you're using Final Cut, it's not. In fact, a significant portion of it -- perhaps the main ingredient, the video clips -- are not there. They're in the scratch folder. Now for some people this is fine. I understand the desire to keep this media seperate from the projects themselves. There's a logic to that, and it's justified. But there's also a logic to wanting to keep the media together with the project. This is clearly something Apple is aware of, that's why they give you the option to consolidate all your media using the Media Manager. But if you know you want all your media and project files stored together before you even start a project -- and I know a lot of people who do -- it would be much simpler and smarter if we had the option to decide this at the outset of any new project, and it would save a whole lot of error-prone media management after the fact. Seems to me like managing your media from the get-go is usually the best way to go if you can swing it. And, by the way, Media 100 had this option.

So Final Cut 5 is out now, and still no per-project scratch disk setting. We've got all the new, admittedly great, productivity features. The real-time capabilties alone are simply phenomenal. But it's this one, tiny, little feature that would really mean the world to me. And I can't, for the life of me, figure why, after all this time, it's been ignored. As a user I would consider it a huge boon, and as a teacher of the software it would dramatically simplify explaining the scratch disk concept. (Do you have any idea the sort of confused-puppy stares I get when I tell students, "Your Quicktime movies will get stored in this arbitrarily determined folder on such-and-such a drive, but you should store all your projects in another place?") I suppose the obvious solution is to keep your projects all in the same Final Cut Pro Documents folder that the scratch disk is set to. But what if you have projects on multiple drives? Or what if you just plain want to organize things in a way that makes sense to you, rather than in the way that Apple has deemed it best you do? Since FCP 4, I could set the key command for wiggling my big toe, but I still can't set scratch disks on a per-project basis. This level of customizability just seems so basic that I'm left scratching my head over its exclusion.

I'm no programmer, but this seems like a very simple thing to implement on Apple's part. Way easier than multiple angles and intgrated LiveType. A ten minute job. And yet, it continues to fall by the wayside.

I'm bummed.

Tiger Lab Migration Part 6: Base Config

So this is the part of this epic in which I build what I call the "Base Config" or "BC." The idea behind the BC is simple, really: Build a machine that's got it all (well, almost all), from which all subsequent machines in the lab can be cloned. Building the BC is always a little scary, because any mistake I make on the BC will be propegated to about 25 machines, and consequently will have to be corrected on said 25 machines. So I've got to be careful and thorough in my planning.

Essentially, all my machines are the same, or at least share the same core: the latest and/or greatest version of Mac OS X, major applications from Adobe, Macromedia, Microsoft, and of course Apple, and some smaller applications here and there, mostly utilities and drivers or things like Suitcase. These things go on every Mac in the lab. So they go into the BC Mac as well.

In addition to the OS and the applications, there are some admin things that need to get done: We have some custom scripts and dock items we like to put on the Macs, as well as a Startup Item to mount our home account server via NFS. And, of course, Directory Access must be configured to get authentication, and whatever other services we set up, from our Macserver. Then each preference pane in System Preferences should get configured the way we want. Finally, we add a few things to /etc/hosts and there are a couple cron jobs that need to get setup. And I believe that's it.

And, like I said, I hope that's it, because if it's not -- if I've missed anything -- I'll be paying for it later.

Here's where lists start to come in real handy:

• Mac OS X 10.4.2

1. Install OS
2. Install all Software Updates

• Local User Accounts

1. Me (admin)
2. Lab Assistant (admin)
3. Student (generic non-admin)

• System Preferences

1. Configure All

• Adobe

1. Photoshop
2. Illustrator
3. InDesign
4. Acrobat
5. AfterEffects

• Apple

1. XCode
2. Final Cut Pro Suite (FCP, DVDSP, Motion)

• Macromedia

1. Director
2. Studio

• Microsoft

1. Office 2004

• Other Software

1. Stuffit
2. Suitcase
3. USB Serial Drivers
4. WACOM Drivers
5. KeyServer Software

• Admin Junk

1. Configure Directory Access to authenticate against MacServer
2. Mount Home Account Startup Item
3. Admin Scripts (local delete, quota alert)
4. Add servers to /etc/hosts
5. Add cron jobs (local delete)
6. Spotlight Disable Script (so that home accounts do not get indexed)
7. Application Menu

So, that should do it. I'll build this, start testing it, and add anything to the list I forgot. But that's pretty much it. Once this is built and working well, it will be time for the trial by fire. We'll start cloning this machine to the other workstations. This year will be extra special fun, because not only will we be cloning these, we'll also be wiping and repartitioning the internal drives of all our machines. Fortunately I have lots of firewire cables, and very capable and energetic Lab Assistants who are ready, willing, and able (and paid, for that matter) to help me out with all this.

And one last side note: As I build this machine, just for fun, I may create disk images along the way of slightly leaner builds than the final. Like a build with just the OS, then one with just the commercial apps, then one with the drivers, and finally one with all the fixin's. This way I have the various stages available to me in case I need to build, say, staff machines, from a leaner base system, or in case I screw something up and need to go back a step or two, I won't have to start completely from scratch.

So that's the plan. I'll let you know how it goes.

UPDATE 1:
I've just finished the first stage: installing and updating the system software. The OS is at 10.4 2 and all Software Updates have been applied. I have also configured my account, and the other local accounts, and configured all the System Preferences. I have created a disk image of this install, called SysAppsBC-BaseOS.dmg, and scanned it for ASR.

Blog Plans

So I spent much of today looking into how I would go about moving the blog. What I discovered is that moving a blog is a big fat pain in the ass.

Fortunately, that's not all I discovered. But first, some quick background: I've had some wild ideas about moving this blog to a permanent home on some good host somewhere and setting it up all myself with something like WordPress or Movable Type. My main reasons for wanting to do this were twofold: 1) I wanted more control over the design of the site and 2) I wanted categories so that I could organize and cross-reference things on the site, as I see this blog mainly as a reference for myself and, possibly, others. In my travails, however, I discovered that doing any of this -- getting a host, getting a domain, getting blog software, installing it, setting it up, and, finally, migrating all the existing posts, links, comments and all to the new site would take a lot of time and effort. Time and effort spent not working on the main reason for having the blog in the first place: blogging. So I started looking for alternatives.

My main concern is having categories on the site. This is so that if I want to see everything related to my Tiger Lab Migration, which is chronologically all over the map, I didn't have to dig through tons of posts and archives. I could just, in theory, go to the "Lab" category, and pretty much get everything there. After hunting around a bit, I found an extremely clever solution at Freshblog, that uses the del.icio.us community bookmark site to emulate categories for blog posts on Blogger. While it's not the easiest or best solution, I found I was able to implement it and categorize all my posts to date in a very short amount of time. So, the blog now has a rudimentary category system. Hooray.

Regarding design, I realized, at some point, perhaps many years ago, though I was reminded of it while thinking about all this site re-implementation crap, that I am not a designer, and by no means a web designer (a whole other ball of wax), and that were I to attempt to redesign the site from scratch I would most certainly spend a whole lot of time mucking things up for no good reason. There are a lot of fine templates available for the Blogger way of doing things. The are freely downloadable and modifiable. So, again, I decided to forego the design challenge and find a template out there that suited me. I've always liked the simple, easy-to-read WordPress default theme. It's simple, classy, and it doesn't get in the way. And lucky for me, someone has modified it to be usable on Blogger. So, for now, I'm going with that. I'm pretty much using the stock theme originally designed by Michael Heilemann and modified for Blogger at this site. All I've done is add my "Categories" and "Archives" pull-down menus, and increased the font size ever-so-slightly. At some point I may get graphically restless again, but for now, this is just fine.

With my mods in place, I'm sated for the time being. So I'll be staying at Blogger for awhile. If, for some reason, this ever becomes more than just a fun, though often quite useful, side project for me, I may roll my own blog some day. But I can't see that happening for quite some time. Until then I'm just going to make myself comfy right here.