TASB Gets TUAW Link

I'm pleased as punch. Happy as a clam. A kid in a candy store. A pig in shit. Seems The Unofficial Apple Weblog (TUAW) noticed my latest post on launchd and Lingon and linked to it.

For those of you unfamiliar with TUAW, it's a great blog about general Apple goings-on. It has numerous writers, is updated frequently, the articles are short and often helpful, and the writing is fun and friendly. I read it every day, and often post comments there. I'm flattered that someone over there has taken any notice of my site, and jazzed about any traffic it might generate. Let's face it, I'm an attention whore.

Anyway, thanks, guys!

launchd and Lingon

Well, it's about time I wrote a post about launchd. launchd is the new catch-all services launcher in Tiger. It's the thing that makes everything you need in order to do anything on your computer launch, either at boot, or at the appropriate time. It's got some real problems and limitations right now, but hey, it's new. And there's plenty good to say about it, even in this early stage.

I won't go too much into how launchd works nor all of what it does. But if you want to get an idea of what services have been moved to launchd from other parts of the system, take a look at the files in:

/System/Library/LaunchDaemons

Here you'll find a list of preference files, or .plist files. These files are all named for services that used to be started and handled by init and other such UNIX daemons and config files. Among the most notable in this list are the periodic maintenance jobs once handled by cron. These, too, have now been taken over by launchd, though cron remains available for scheduling other jobs. For now.

Anyway, this should give you a good enough idea what launchd does. If you're really lost here, I suggest you do some homework. There is a great overview of launchd, complete with tutorial, over at AFP548. There's also a good launchd Developer document at Apple's Developer site. Between these two you should be able to get largely up to speed on launchd. And if all this services stuff is way over your head, well, just move along please.

One of the coolest features of launchd, though, is the fact that it is easily user-configurable, and user-specific. That is launchd items, or LaunchAgents and LaunchDaemons as they're called, can be placed in the user's home account and run on a per-user basis. The other remarkably cool feature of LaunchAgents and Daemons -- and the one I really want to talk about -- is that they can watch folders and/or files. These two features allow for a degree of conditional automation -- and by that I mean, If/when user does A, then System does B -- previously undreamt of on a Mac. Well, that may be an overstatement, but launchd will certainly make such customization a great deal easier. And it's not even that hard to use, once you get the hang of it.

If you check out the AFP548 demo, they have you create a LaunchDaemon that watches a folder for modification, and then, if the folder is modified, launchd automatically moves the items of this "watch folder" (and, yes, that is the technical term) to a new destination folder. Already you can see where this would be extremely useful for backups or versioning systems, or any kind of synchronization of files. The idea of the watch folder/file is remarkably powerful. You can have launchd run any shell script, AppleScript or command anytime any file or folder is changed. In our lab we were, at one point, using launchd to watch our list of automount user mounts, and automatically reload the automount daemon whenever a new user was added to the list. You could (and I may, at some point) make a launchd item that detects the mounting of external hard drives, and then runs a script to disable Spotlight on said drives. There are a million things you can do with this one feature alone. But to do any of it, you must know how to edit those pesky .plist files.

Being no stranger to editing XML .plist files, I started off the hard way, editing them by hand in a text editor. I then graduated to the Property List Editor included with the Developer Tools. But recently, I found an excellent and free utility called Lingon, which takes a lot of the grunt work out of creating LaunchDaemons and Agents. It even comes with an "Assistant" to help you get started creating your first LaunchDaemon. And it will blessedly load your items into launchd, so trips to the command-line and the arcane syntax of lines like this:

launchctl load -w /Volumes/Work/systemsboy/Library/LaunchAgents/com.systemsboy.LA01

become a thing of the past.


Lingon: Launch Your Dreams Right Here!
(click for larger view)

So, okay, sometimes a GUI is a great thing. No offense to the Lingon guys and/or gals, but I'd really love to see Apple include a front-end to launchd sometime in the future, so that it could be really accessible to mere mortals without all the fussing around. Until then, Lingon makes a great addition to any Admin's toolbox who might have need of the sort of auto-magic attainable with launchd.

I do want to note one more thing. It's possible to seriously lock up your system with LaunchDaemons and Agents. To wit, I somehow created a LaunchAgent that perpetually opened one of my hard drives. This, for all intents and purposes, prevented me from accessing any application but the Finder. In fact, I couldn't even navigate the Finder to remove the item as every time I tried to do anything at all, the window to the drive would open and take over the system. Nor could I easily access the offending LaunchAgent via single-user mode, as my home account is stored on a second partition that is not mounted in single-user mode. Fortunately I keep a secondary user account for just such emergencies. In the end, I was able to unload and delete the offending LaunchAgent via this secondary account. So just a word to the wise: Use launchd with care. And keep a secondary account handy, just in case.

And one last thing: Hats off to the Tiger devs. I bitch a lot about 10.4, but launchd is a keeper. One of the best hidden surprises to this new OS.

Tiger Lab Migration Part 10: Up and Running

Take it as a symbol of my incompetence. Take it as a sign of the inherent difficulties in unifying any highly cross-platform environment. Take it as an indication that major OS updates in said environments are often far more difficult than you might have ever guessed. Take it for what you will. I'm just happy and relieved to report that, after many months of difficulties, we seem to be out of the woods: Our Tiger Lab Migration is complete.

(Note the sound of me frantically knocking wood.)

There are several things that have transpired -- things mostly out of my control -- that have made this migration, at last, complete. If you recall, there were two initial major problems from which we were suffering at the outset of the migration: 1) Mac OS X 10.4.2 was unable to write files across filesystems, which was impeding our use of certain software, particularly Final Cut Pro, which is used heavily in our lab; and 2) our Panasas brand home account RAID (on which we host our networked Mac home accounts via NFS) was crashing, almost daily at the end there. Problem number one was mitigated by certain workarounds I was able to implement using mount_nfs and loginhooks rather than the preferred automount method for mounting home accounts on our client workstations. Problem number two had both myself and the Panasas engineers scratching our heads.

Ironically, both problems are solved by system updates.

The inability of Mac OS X 10.4 to successfully write files across filesystems is cured, thankfully, with the latest update to the OS: 10.4.3. I have not yet implemented 10.4.3 lab-wide as yet, and so we're still running my mount_nfs workaround on the client systems, but on my admin machine I am testing the new update, and so far so good. Things behave properly again. I will also be running the update and the automount method on a test system on the floor for good measure, but I'm reasonably confident that this issue can, at last, be put to rest.

The home account server crashes also seem to have been cured by updating the Panasas RAID OS software. We upgraded on Friday, November 4th, 2005, and have not had a single crash since. This could be mere coincidence, but I'd be pretty surprised if that were the case. The crashing seems to have stopped, and I'd bet a fair chunk of cash that the update is the reason why this is so.

The best part of all this is that, for the past week, the lab has been quiet. People come in. They log on to the systems. They do their work. And everything functions properly, without incident, for the first time in months. The knocks on my door, the panicked moments, the hair-pulling-filled long nights and weekends have all subsided. My stress levels are slowly returning to what they once were, which is not to say normal, but rather normal for me. It is truly a thing of beauty.

There are two things a SysAdmin likes best in the world: a good challenge, and successfully overcoming said challenge. The Tiger Lab Migration has afforded me a hefty dose of both. And despite all the trauma, it's been an enlightening and illuminating experience from which I've learned a very great deal.

File Creation Dates Hosed Copying from Mac to Windows

I just wanted to draw some attention to a potentially fairly nasty Finder/Mac OSX bug that hasn't gotten the attention it probably should. A few days ago I posted on the latest Tiger release, what it fixes, what it doesn't. And in the comments section of that article, two people wrote in about a problem wherein the Finder loses the creation dates of files saved to MS-DOS formatted disks. That is, any file saved to a Windows formatted disk (and I don't know if this only applies to fat-32 disks or all Windows formats, but I would suspect the latter) will lose its creation date, which will be set to nothing. It will simply be blank, from my understanding of the problem. And please be aware, I have not experienced this problem myself. But a number of people have. We don't hear about it much in the Mac community, because much of the Mac community tends to work only on Macs. To be affected by this bug, you'd have to be both working from Mac to Windows, and have a serious need for file creation dates. This is not everyone, but it is a serious problem nonetheless, and Apple should hear about it. Though I have not personally suffered from this problem (yet), I sincerely sympathize with folks who need to get things to work cross-platform. I have the need myself, and it can be a real bitch. But when basic functionality like the preservation of file creation dates begins to fail when working cross-platform, it's way more than a bitch. It's a fucking nightmare. A lot of people turn to Apple for cross-platform compatibility, because -- let's face it -- no one else is doing half as good a job as Apple in this arena. But sometimes it seems like it's the cross-platform arena that gets the short-shrift when it comes to Apple's priority list. This is understandable, I suppose. We're the minority. Still, when basic things go wrong, Apple should hear about it, no matter how small the affected group may be. And they should fix it. Promptly.

So, if anyone out there in Mac-Land is having a problem with this, I say go vent. If you want to do it here in the comments section, by all means, be my guest. But you may want to take a moment and let Apple know about your problem as well (and trust me, they don't read this blog). There are a few good places to do this:

  1. Apple's Mac OS X Feedback Page
    Here is the best, and most appropriate, place to lodge a complaint or report a bug. Keep it business-like and polite, but specific and thorough. Vent someplace else.
  2. Apple's Discussion Forums
    Here you might actually find some help for your problem (though I think this particular problem is up to the Apple Developers at this point). Help notwithstanding, enough complaints on the discussion forum are likely to escalate the problem in the queue of stuff-needs-doin'. So it's worth a shot.
  3. Call AppleCare (1-800-275-2273)
    Again, a good place to get heard. It might be a pain. You might get put on hold. A lot. But if you've got the time -- and, of course, your machine is still under warranty -- this could escalate your cause up through the ranks of the Apple engineers. As always, be polite but firm. You may need to explain your problem to -- and humor -- a number of lower-tier help-desk types before you get someone knowlegeable. But it might pay off. Don't do this, though, unless you've got some time and patience. Trust me.
  4. Finally, spread the word
    That's what I'm trying to do with this post. Start writing to forums and blogs of some prominence. MacOSXHints is a good one to post on. There's also The Unofficial Apple Weblog. Hell, there are a ton, and they're all more prominent than this one. Start hitting them up. No one likes bad press. Least of all Apple. The more noise people make, the more likely they'll be heard.

So, anyway, hopefully this does somthing to draw a tiny bit of attention to an easily-overlooked, but non-trivial problem. I'm pushing for you kids. If anyone hears of a solution, please post it here in the comments. I'll do the same.

Now go start pestering.

Cool Mail Feature

Just a quickie: I just discovered a feature in Mail.app that I was completely unaware of. It is possible to save Mail messages as .rtf (rich text) files. Just open or highlight a message, and click "File->Save As..." But the niftiest thing is that you can save multiple mail messages in one .rtf file. Just highlight a group of messages, by command- or shift-selecting them, and again, "File->Save As..." The file you save will contain all the messages you selected, complete with email headers and all.

And just so you know, you can also save your messages in Plain Text (.txt) or Raw formats.

Neat-O.