"Too Bad:" The Finder Gets Cheeky

Well, except for my Tiger home account traumas, and forays into the wacky world of Windows and Linux, and the giant staff upheavals at my workplace, it's been a pretty slow news week for me. Which is really to say, I've been way too busy-as-Hell for any sort of recreational writing, and pretty much everything's been going into my Lab Migration posts.

I did, however, discover another funny little error message, this time in the Finder. I use a great free utility called QuickAccessCM, from Abracode, which allows you to copy or move files to commonly used, user-defined folders in a contextual menu popup. I use it for organizing all the downloads that get dropped onto my Desktop, for instance. Just right-click any recent files and send them off to the appropriate download folder, without ever having to drill down to said folder. It's nice and handy, for me anyway.

QuickAccessCM
(click for larger view)

So what happened was, I was copying something from the Applications folder, only I accidentally told Quick Access to copy that item to the Applications folder, which, of course, you can't really do, and I subsequently got this alert:

Slightly Cheeky Finder Alert
(click for larger view)

I don't know; made me giggle. I'm a bit punchy. Long week.

Spotlight Revisited

See? Now this is what I'm talking about. Spotlight just doesn't work right. Now, I will admit, I've been using it a bit, and a couple times, over the past couple months, it's actually come in somewhat handy. But today, it lied. And I can prove it.

I was installing the nifty GoogleMaps plugin for Address Book. And I was looking around for the old GoogleMaps install, because, at least in the past, finding files whose names I knew on the filesystem was easier than reading a maunal. Lucky for me, today I got to do both. So, I open a Finder window, navigate to my home directory, and in the little search bubble thingy, I type these exact letters:

googlemaps

Now, I know that the letters "g-o-o-g-l-e-m-a-p-s" exist in the files I'm looking for, because I have the replacements right there in front of me. So when my search does not yield the files I want, I modify the search. In the same window's bubble-search thingy, I type:

BTgooglemaps

And now my files turn up.

Now wait. Doesn't "BTgooglemaps" contain the term "googlemaps"? So, shouldn't searching the latter yield the former? Yes, it should. In fact, if I just search "maps", I get my "BTgooglemaps" in the results, and lots of other crap, but not, for instance, my "com.briantoth.addressbook.googlemaps.plist", which does appear when searching "googlemaps".

This is just... Uh... How you say? Oh, right: Fucked.

If I can't trust my search engine to yield results that I know are there, then its usefulness is severly compromised. The old version of the Finder window search bubble was flawless at this. I used it all the time and it never failed me. And its functionality still exists somewhere in the Finder. We know this, because when we turn Spotlight off, the old functionality resumes. But for some reason, Apple has chosen to completely replace this functionality with a deeply flawed, and not always appropriate, method of searching: Spotlight.

Call me greedy, but I want both. I'll say it again: I want the old Panther-style, find-by-name in the Finder window toolbar search, and then I think I could live with Spotlight everywhere else. Although, in an ideal world, I would have preferences that let me define how each search method works: Finder window find, command-f find, Spotlight find. All these (or at least some of them) could (dare I say should) be configurable via preferences. And that would be sweet.

What we have right now is not sweet. It's a kludge.

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.

Duplicate Computer Names Automatically Changed

I just cloned my system to another computer. When I rebooted the clone it had the same name as my original system, for obvious reasons. Interestingly, once the computers figured out they had evil twins on the network, they both renamed themselves. So, if my computer's original name was "systemsboy," its new name became "systemsboy (3)" and its clone was renamed "systemsboy (2)." Unfortunately, taking the original machine off the network did not cause the clone to rename itself back to its original name (which makes sense, but it would've been cool). To do that, I had to go to the Sharing System Preferences and rename the computer by hand.

I think this is new in Tiger, but I'm not sure.

Escape Finder Window Resizes

Well, this is pretty stupid, but I thought it worth a quick mention as it just came in handy a minute ago.

If you're as anal about your window sizes and positions as I am (it's okay, we all have our things), and if you happen to be changing either the size or the position of a window in the Finder, and if you, for some reason, decide to change your mind and you don't want to resize or reposition that Finder window, just press the esc key, and your window will pop back to its last state.

Hey look at that: a whole post in three sentences.

Followup:
This works as described in Panther, but in Tiger it only works for size, not position. Pressing esc while moving a window in Tiger has no effect.

And there go my three sentences. Oh well.