Tiger Lab Migration Part 7: Wiggly-Niggly

Well, we're getting close. We're down to last, wiggly-niggly little tidbits. Here's where we've been in the last few weeks:

The Master System
We have completed a very nice build of Tiger with most of the software we need on all machines, though we're lacking all the most recent Adobe stuff due to not having received the most recent Adobe stuff. 'S'okay. We'll make do with CS1 for now. Our system is all loaded up with our custom scripts, and a new, beefier home account mount script. And it's got a nice, big, 75GB system partition. Why, it's just swell.

We've used this system to clone to all our other lab machines. We boot these other machines in firewire target disk mode, and then we use Disk Utility to restore the Master System to the new machine's system partition. Or, we wanted to use Disk Utility. Turned out that our first Disk Utility-cloned system had some problems due to -- yep, you betcha -- Tiger bugs. The problem was that Disk Utility wasn't blessing the new system partition, so when we'd boot the new machine, we'd get the flashing question mark of doom. So we'd have to then boot off the Tiger install disk, and set the new system partition on the newly built machine to be the startup disk. I decided this was a pain, and that it would be much easier and more instructional to do our clones with a tiny, tiny shell script that calls ASR (Apple Software Restore, via the asr command).

#!/bin/bash

## Script to Clone Local Volumes #### systemsboy - Aug 18, 2005 ##

clear

## Define Variables ##

echo "Please enter the path to the SOURCE volume or ASR-ready disk image...(Example: /Volumes/MyVolume)"read SOURCE

echo "Please enter the path to the TARGET volume...(Example: /Volumes/MyVolume)"read TARGET

## ASR Portion of Script ##echo "Building Clone... Please wait...________________________________"sudo asr -source "$SOURCE" -target "$TARGET" -erase

exit 0

This did the trick indeed, and was as easy to use, if not as purdy, as the Disk Utility application. This method only yielded one problem, and that was that all the invisible folders -- /var /etc /private and the like -- were not made invisible on our cloned systems. This is another Tiger bug, but one that was fixed in 10.4.2's version of Disk Utility. Apparently not fixed in ASR from the command-line, however. This problem yielded both an intersting solution, and some interesting information. Back in the day, these files were made invisible to the Finder by the magic of the .hidden file. The .hidden file was simply a list of files or folders at the top level of the root drive that should be treated as invisible by the Finder. Want to make something invisible on /? Just add it to the .hidden file and restart the Finder. (Ironically, the .hidden file was also at the root level of the system, but was rendered invisible by the fact that its name began with a period.) Nowadays, however -- in Tiger, that is -- this is no longer that case. Files on root are now made invisible, according to this Apple KBase article, by setting certain file attributes. I'll tell you, I have yet to figure out what those attributes are, or how to modify them, but when I do I'll shout. In the interim, I was forced to locate the "SetHidden" program on my original Tiger install DVD. After insering the DVD, it can be found at:

/Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg/Contents/Resources/

I've now copied this file to a folder called SetFile, which I've placed in the Applications folder for future use. Also, I needed the hidden_MacOS9, which can be found, and should be placed, in the same folder as the SetHidden command. So I now have a folder in my Applications folder, called SetHidden, in which the SetHidden command and the hidden_MacOS9 files reside, installed on my master, and I've added the commands:

cd /Applications/SetHiddensudo SetHidden /Path/To/My/Clone/System hidden_MacOS9

to my shell script, and voila! Clone script complete!

#!/bin/bash

## Script to Clone Local Volumes #### systemsboy - Aug 18, 2005 ##

clear

## Define Variables ##

echo "Please enter the path to the SOURCE volume or ASR-ready disk image...(Example: /Volumes/MyVolume)"read SOURCE

echo "Please enter the path to the TARGET volume...(Example: /Volumes/MyVolume)"read TARGET

## ASR Portion of Script ##echo "Building Clone... Please wait...________________________________"sudo asr -source "$SOURCE" -target "$TARGET" -erase

## Set Hidden Files (Tiger Bug Workaround) ##echo "Mac OS X 10.4 does not properly set hidden files.We will now use the SetHidden command to rectify the problem.For this step, the SetHidden folder must be present in /Applications.---------------------------------"cd /Applications/SetHiddensudo ./SetHidden "$TARGET" hidden_MacOS9

exit 0

Cloning all 14 systems on the floor took my Lab Assistants a few short hours.

Spotlight
I mentioned some concerns regarding Spotlight and the particular way in which users use our lab. After some mucking around, and testing of various methods of disabling Spotlight, both forced and optional, I've decided to do nothing. I do this kind of thing all the time. Worry and worry about something, and then, finally, throw caution to the wind and do nothing about it. It's my way. It's part of what makes me so gosh-darn lovable. But I do have two things behind that decision: a rationale, and a backup plan.

The first problem I'd anticipated was that Spotlight would begin indexing user home accounts over the network all at once as soon as everyone logged in, and that this would cause problems with network performance and incomplete indexes. Upon further reflection (read: obsessing), I decided that that Spotlight's network resource usgae would probably be low, and that it would probably avoid incomplete indexes by either continuing in the background after logout, or by resuming at next login. Also, since home accounts have quotas, the largest of which is 7 GB, indexing shouldn't take too long, and any problems should be quickly mitigated.

The second possible problem I'd worried about was that Spotlight's insistance on indexing firewire drives would take forever to yield complete indexes on large drives -- a process that would likely be interrupted at logout before it was complete -- leaving many users with partially indexed drives. In my tests, however, Spotlight picked up right where it left of with drives that were partially indexed when ejected and then re-mounted, so I'm not convinced this will even be a problem. I also worried that Spotlight's firewire drive indexing would cause performance problems that would incapacitate users who were working on video. This may yet be the case. We'll know soon enough.

I came up with a number of possible solutions to these problems, all messy, all imperfect. Ultimately, I decided that the best option was to wait and see what problems arose, and then tackle those problems with the most appropriate of the solutions I devised. Who knows? Maybe it will all work out great without any intervention from me. And that'd be just ducky.

Network
We have an intersting and complex network. It consists of Mac, Linux, and Windows machines, a network RAID, and web and mail storage. And all of this is accessible, in one way or another, via the network. The problem comes when you try to explain all this to new (or sometimes even old) students. It's not an easy picture to paint. And overwh elmed first years usually don't quite catch on for some time. But as we design our network, and build our systems, we're very concerned about how all that is presented to the users. And we try to make it as simple and as understandable as possible, which is, after all, the Mac way, and is why people love the Mac. So let me just say, right here, right now, what the fuck is up with the "Network" view? That piece of shit gets worse with every OS revision. And no one seems to care. I can't find diddly about it on the forums.

So here's the background on this outburst. Back in the Panther years, the Network view offered up a pretty nifty way to present a great deal of our network -- the shared drives of all platforms -- to our Mac users. The coolest part was that it looked much like what you saw on Windows, which simplified things greatly by presenting a consisten network view across platforms. There were a couple things that made this possible. One was SMB workgroup names. SMB does a great job of not only sharing files, but broadcasting itself as a service on a network. Setting up computers under SMB with a workgroup name based on the platform of the given machine got all our Mac, Linux and Windows computers grouped appropriately on the network. And Mac can read those groups and smartly creates folders in the Network directory named after those groups and populated with the systems that belong to them. So in my Network browser, there'd be a folder called "Linux," and all the Linux computers would be in there. Same for Windows. Here's the catch: Our Macs share via SMB to Windows, but we want them to share via AFP to other Macs. Personal File Sharing, which uses AFP, does not, by default broadcast any kind of grouping. If you turn on AFP, you just broadcast the service, but you can't specify it's appearance or where on the client the shares will appear. Computers broadcast via AFP in Panther just show up in the "local" folder, not in a "Macs" folder like their SMB sharing counterparts. There was, however, a sneaky way to define this in Panther, by editing a little file called /etc/slpsa.conf, and thereby magically creating what are known as SLP scopes. In fact, SLP scopes are just that -- a way to group a particular service from a particualr device into logical groups. So we scoped our Macs to the "Macs" scope and they showed up in our "Macs" group in /Network, and all was well in the universe. If you're unbearably astute, you'll probably be wondering why, though, our Macs, when connecting to other Macs via the "Macs" scope in the Network folder, didn't connect to said Macs via SMB rather than AFP. And here was something amazingly cool in Panther. Panther smartly dealt with the folder full of Macs in our Network view. So, when it saw these other Macs broadcasting and sharing over two protocols -- AFP and SMB -- it intellegently chose the best one, which for a Mac was AFP, of course. That was the thing of beauty that allowed us to present the same view of the entire, heterogeneous network the same way on all platforms while still allowing us to connect with different protocols. It was frickin', frackin', goddamn sweet, is what it was. Brilliant. And now it's gone.

Not only is this intelligent decision making gone from Tiger, at least in the latest incarnation (10.4.2 as of this writing), but so too is the ability to define SLP scopes. So, this means two bad things: 1) I can no longer define specific locations for my AFP-shared Macs, and 2) any connection made via the "Macs" folder in the Network folder (which, remember, is now only defined by SMB, not by SLP) connects via SMB; my Macs connect to each other via the Windows file sharing protocol, which is a big fat problem.

So, I'm currently trying to devise a way to scope the Mac shares into some sort of logical grouping that will allow me to present those shares in a palatable way. But it ain't easy. I know you can do this with Tiger Server, and this is probably why they've crippled it on the client, but I don't a Tiger Server yet, and I'm hesitant to build one this close to the beginning of the semester. So we shall see...

The migration is nearly complete. Time permitting, I would abasolutely love to build a fresh new Tiger Server. I'll probably give it a shot in this last week before classes begin, but I'll be sure and keep a clone of the existing Panther Server in case things go awry. Beyond that, and the aforementioned wiggly-niggly, we're done. We're upgraded, on the workstations anyway. And it is good.

There will, most likely, be problems that arise once the students come in and start using the new systems. I will share those in a later post. Until then...

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.

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.

Spotlight/UTI Conflict or: Still Useless

Awhile ago I wrote this regarding Spotlight:

The other thing that's helped me understand the usefulness of Spotlight is actually coming up with a reason for using it. Initially I had no real need for it, or at least I didn't think I did. But the other day I was looking for something in a script that did a particular something or other. Problem was I had no idea what script I had put that something-or-other line in. So I'm looking through nested folder upon nested folder, trying to decipher my own script names, and realizing that it was all futile because I had no idea what the script was about, only that it had a line in it that used such-and-such a command. And that's when it hit me: how great would it be if I could search inside my scripts? And then it hit me again: Spotlight!

I also wrote a brief rant about Tiger's new UTIs and how they screw up my scripting workflow:

Tiger, as in many of my other workflows, has made fundamental changes to the operating system that break the original functionality to some degree, and thus break my workflow. In Tiger, text files with the .command suffix open in Terminal, but so do ones with the .sh suffix. If I change the "Open With..." application for .sh to TextEdit, using "Get Info" and apply the "Change All" option, files with the .command get changed too, though the ensuing warning message still (erroneously) states that the change will only affect files with the .sh suffix. So for some reason, Tiger is now associating .sh and .command files with the same application type -- essentially seeing them as the same types of files, which, in a way, they are. But Panther didn't do this, Panther allowed me to specify which apps opened certain types of files based on their suffix.

Today in another cruel twist of fate, the promise of Spotlight and the annoyances of UTIs collided, merged, and then mutated into one horribly disfigured total and utter lack of functionality. Not only are the UTIs for the .command and .sh suffixes hard-coded to one and only one application at a time, but Spotlight treats them differently than regular text files as well. In fact, Spotlight does not index the content of files with the .sh or .command suffixes. That's right. The one area where Spotlight could really prove its usefulness to me is one of the many areas it doesn't work as one might hope. I can't search inside any of my scripts -- the one place I could really see myself wanting to search by content -- because, like a good boy, I named all my scripts with either the .sh or the .command suffix.

I'll say it again, this use of UTIs, which are allegedly supposed to alleviate file suffix dependence, has actually stolen a very useful feature away from the user. Namely, the ability to have two files that are identical in content open in different applications based on some property other than content -- in this case, the file suffix. This was a great thing to be able to do, and, conversely, it sucks to not be able to do it. So I don't get it. What's the advantage? And not to developers, what's the advantage to the user? From my point of view, I just lost functionality, and the only way to get it back is to rename all my scripts with a file suffix that Apple has now taken full control of. I'm locked in. I have fewer choices and less control. And I'm more dependent on file suffixes than ever.

Actually, the file suffix thing is still around. File suffixes still determine the UTI to which the file belongs. So they still do the same thing. It's just that now they're more limited because of the hard-coded and seemingly arbitrary groupings imposed by Apple's implmentation of UTIs. Am I missing something? This is worse, not better.

Until someone can show me otherwise, I have to say that UTIs are bad.

Or at best, badly implemented.

Tiger Lab Migration Part 5: File Sharing Broken

I've been building my Master Tiger system. Actually, it's built, and I've been testing it. And I was going to make it my Radmind Master Client, but I've since scrapped my Radmind plans altogether. So fine. It's now just a matter of uninstalling Radmind from the Master and testing it and making sure all is well. Well, all is not well. Somewhere along the line, Apple File Sharing broke. I don't know exactly how or why. All I know is that, yesterday, after uninstalling Radmind, I tried connecting to the Master from my admin machine via AFP. The share mounted for a few minutes, then my Finder beachballed and I got a new error message alert. I'd never seen this one before:

Pressing the "Disconnect" button does just what you'd think: It disconnects you from the now defunct share.

So, looking into this a bit more, I've discovered that the AppleFileServer process on the Master is crashing whenever I try to connect to it via AFP. After the crash there is copius and completely useless output in the AppleFileService.crash.log, and Personal File Sharing is off in the Sharing System Preference pane. I can connect in the opposite direction -- from the Master to my admin box. File Sharing on the Master, however, seems hopelessly broken.

I'm not sure what to do.

I figure I have three options: 1) I can spend forever and a day trying to figure out what went wrong and maybe fix it, 2) I can wait for the much-anticipated 10.4.2 update and hope that whatever got broken on this machine gets overwritten with fresh new copies from the update, or 3) I can wipe and reinstall. Since it's likely I'll have no luck figuring out the problem, and since I'm not really the wait-and-hope type, I think I'll go with option 3.

Time to build another system.

I hate Tiger.