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.

Tiger Lab Migration Part 9: More Problems and Solutions

Well, when last we visited this issue, we were having problems saving, among other things, Final Cut Pro files. After working long and hard with the Panasas folks, I was confident I'd found a solution. And I had, but the solution has created new problems. I want to kill Apple for Tiger.

To refresh, the original problem was that Final Cut was trying to write files across filesystems, and the OS was choking on this operation. This was happening because our RAID exports its /home volume -- and this is what we mount -- but each user account is also an individual volume. FCP writes to the /home level, and then has to cross filesystems to save the file to the user's home account, itself a seperate volume. Our solution was, rather than mounting all of /home, to mount each user's home account individually. This required a whole bunch of scripting and launchd voodoo to really work the way we wanted, particularly with regards to adding new users. But we got it working, and it fixed the Final Cut problem. I implemented it, tested it, and emailed the community about the fix.

Unfortunately, I recently discovered that using this method causes some new, less ugly, but certainly annoying problems: the sidebar home account link no longer works, causing untold confusion among users who suddenly think their home account no longer exists (as per the alert message that appears when clicking this link); but most alarming, users can no longer open documents from their home accounts. Not only can users not open docs, but root via cron fails to open documents. This is a big problem, as our "Scratch" partition gets deleted every Friday, and the users rely on an alert message to warn them of the oncoming doom. This message no longer launches, and that's a real bummer.

So I was in the middle of drafting an email to the community informing them of the latest bugs and workarounds, when I was struck with extreme embarrassment and shame. How can I continue to expect users to work around these bugs when each week brings a new set? Sure, it's not my fault that Tiger is broken. It's not my fault that the Panasas is set up the way it is. But it is my responsibility to create a user environment that works seamlessly and properly for the user. So I resolved to do everything in my power to implement a solution. I stayed at work on Friday night until 2:30 AM, learning much, but left with no solution in hand.

What I learned on Friday, essentially, is that automount in Tiger is totally fucked. I already knew that NFS in Tiger was fucked in that it can't cross filesystems. But it turns out there have been some major changes to the way automount is handled in the GUI, and thus, for all intents and purposes -- or at least for our intents and purposes -- it is indeed fucked. Hard. The inability to follow sidebar references is a direct result of automount's new Finder behavior: automount mounts in the Finder are now invisible! Unless the path is explicitly called, the user accounts, mounted as they are, are quite invisible, both to the user, and apparently to the Finder's sidebar. I also discovered that the Finder's inability to launch files from the user's home account has something to do with automount, or at least how automount is implemented in the GUI. This behavior only exhibits itself from these invisible NFS mounts; it goes away if we mount the user's home account in /home, as we used to do. And it goes away if we use a different command to mount user homes.

Enter mount_nfs.

The mount_nfs command is used to directly and statically mount NFS exports, and it has its own set of peculiarities. First and foremost, mount_nfs grafts mounts to existing folders, which means that mount_nfs requires a folder named for the user who wants to log in. Secondly, and equally important in our scenario, mount_nfs magically mounts the export in the Finder. Or, rather, shows the mount in the Finder (and this has actually, probably more to do with how the Finder translates mounts requested by nfs_mount). Lastly, since the mounts are static, they remain mounted and appear in the Finder until they are explicitly unmounted. Mounting via mount_nfs is equivalent to mounting nfs exports in the Finder with command-k. It also seems to work, you may notice, completely opposite to automount.

To do what we've been doing -- which is to automount home accounts at boot -- using mount_nfs instead would require us to mount every home account at boot on every machine, and those 200+ mounts would be present in the Finder at all times. This simply would not work. So, mount_nfs at boot: not good. You thinking what I'm thinking?

Enter loginhooks.

To use mount_nfs at boot would be disastrous. What we need in this case is something that will dynamically mount and unmount users' home accounts at login and logout respectively. And that's just what loginhooks and logouthooks do, respectively. Getting loginhooks to work in Tiger was again an exercise in frustration, but this time it was due to my own poor understanding of the technology. There is a great reference on login hooks at Mike Bombich's site, and a decent one at Apple's Knowledge Base as well. Between these two resources, I was finally able to cobble together a solution over the weekend which I think will work.

Briefly, there are three things you need to do to implement loginhooks, and some info you need to know.

The info first:
1) Scripts called by loginhooks run as root (good)
2) They run before login to the GUI takes place, and after authentication (also good)
3) The user requesting login can be represented in your script by the variable $1 (excellent!)

What to do:
1) Write a script to be executed at login, make it executable, put it somewhere accessible
2) Run this command:
sudo defaults write com.apple.loginwindow LoginHook /path/to/loginScript
3) Test the script! This is imperative! You can test it as any user you want by running it thusly:
sudo /path/to/script User

For "User," specify a user who would actually log in, and who is available to the system. "User" here will be interpreted in your script with the $1 variable, just as it will at login. If it works in your test, it should work in practice as a loginhook.

Setting up a logouthook works the same way, except you run the command:
sudo defaults write com.apple.loginwindow LogoutHook /path/to/logoutScript

And, BTW, to ch eck that the loginhook (or logouthook, or both) has been successfully added, you should see your script(s) listed, when running this command:
sudo defaults read com.apple.loginwindow

Finally, to disable, login(logout)hooks run:
sudo defaults delete com.apple.loginwindow LoginHook
and:
sudo defaults write com.apple.loginwindow LogoutHook

So, what I have now are two scripts. The login one creates a folder in /home named for the user who's logging in, and then uses mount_nfs to requset the user's home account from the server and mount it in this folder. The logout one forcibly unmounts the user's home account. And that is all.

I've only tested this at home, but it seems to work brilliantly here, and is fast even over a wireless connection. I will be trying it at work on Monday morning and will post back with my results, success or failure.

Wish me luck.

UPDATE 1:
So far, so good. There were some snags, though. I came in a little early this morning (in hopes of starting before the lab became overrun with students) to implement and test my loginhook plan, only to find the home account server had crashed. So, I had to spend the first hour restarting and troubleshooting the Panasas. By the time I'd finished, the lab was filling up. So I had to do everything piecemeal, and it took a bit longer then I'd hoped. That was snag one.

The next snag was that, after one user logged in, the next user would be locked out of his/her home account. This turned out to be a simple matter of setting permissions (on the /home directory) via the loginhook in a manner in which this did not happen.

There are some advantages and disadvantages to this new mounting method. The greatest benefit is that any changes to the mount method are done via very simple shell scripts, and changes don't require a reboot to take effect. Just change the script and you're done. Another big plus it that, if the home account server goes down, the machines aren't really affected to the extent they once were. If no one's logged in, there's no server access happening, so the machines are fine. Only if someone's logged in is it a problem, but then, that's always a problem. It occurs to me, though, that I may want to add a -hard option to my mount script sometime soon. Another advantage is the fact that, since only individual user accounts are mounted, and not the entire home account server, a command like sudo rm -rf /home can't wipe out the entire server as it could before. The final advantage is that reboots are now much faster, since nothing happens at boot time.

The disadvantages are twofold, and solvable but minor: First, since the entire home account server is never mounted now, users no longer have easy access to each other's home accounts. To access another user's home account, they now must connect to the home account server via the Finder's "Connect to Server..." command (or command-k). Secondly, any user who wants to ssh to one of the other Macs, say, from a laptop, will not have access to his home account since the mount only occurs when logging in to the GUI. These issues are minor, and can be solved by simply mounting the home account server somewhere other than /home, but I think we'll try and live without it for now, as I kind of like not having the whole RAID mounted.

Anyway, no complaints thus far. I'll be convinced this is a go after a week or so without problems. But I'm cautiously optimistic at this point.

UPDATE 2:
Day two, and all's quiet on the Western front, as it were. I'm obsessively monitoring the situation, but it's looking very good at this point. Fingers crossed.

Tiger Lab Migration Part 8: Home Account Woes

Boy have we got troubles. Sure I tested everything. Sure I did everything I could to make sure this upgrade went smoothly. But does that ever matter? No. It doesn't.

Everything tested out fine. Tiger was able, from day one, to mount our NFS home account server -- a network RAID known as the Panasas. It was able to read files, to write files. It seemed fine. But we'd had our fair share of troubles with the Panasas, even in the beginning, even in Panther. Certain Macromedia products -- actually, Flash MX 2004, to be specific -- had certain functional disabilities. In particular, when any user was logged onto the Mac as a network user whose home account was located on the Panasas, he would find himself unable to publish HTML previews from within the Flash MX 2004 application. The error message was something along the lines that Flash was unable to read the HTML templates, which live in the user's home account. Oddly, on first launch, Flash could write the templates, but for some reason, it could not read them for the preview. If you have any Flash knowledge whatsoever (which I don't -- I was informed by student experts) this renders Flash essentially useless. The problem did not, however, exhibit itself with network home accounts mounted on Apple shares, neither via AFP nor NFS. So the workaround was to create a special account for Flash developers, which they could log into when doing Flash work, and which was mounted directly on the MacServer and shared via AFP. Hence was born our FlashDev account, which has worked fine all year.

Jump ahead to the present: we've upgraded to Tiger. It seems to have gone fine. Suddenly, certain apps begin acting strangely. Illustrator can't save files. Word also has trouble saving files, and behaves erratically, complaining of "permissions problems" and the inability to write temp files to a "network disk." Final Cut, too, begins acting flakey. Shit. It's like one of these sci-fi-horror flicks where the brain transfer experiment seem to have gone perfectly, but then, gradually, the patient begins acting... Different somehow...

And then all Hell breaks loose.

Tracking down all the problems, I finally came to the conclusion that a number of applications are unable to read their preference files in Tiger when those files reside on the Panasas. This perhaps causes a chain reaction that makes these apps unable to properly write or save files: FCP writes 0 byte files; Illustrator CS just can't save your document. Oddly, Illustrator CS2 doesn't seem to suffer from this problem, and all these apps (except, of course, Flash) seem to work properly from within the Panther environment.

Seems to me like a nasty reaction between Tiger and the Panasas home account server.

I've done some testing, and I plan to do more. So far, I've tried booting into a Panther client and found that the problem is greatly reduced in Panther (though it always existed to some extent, particularly, again, with Flash) and exacerbated in Tiger. I've also tried resharing the Panasas NFS export via AFP from the MacServer. I was fairly sure this would provide a reasonable, if temporary, workaround, but it didn't. I want to try it again, just to be sure, but if resharing via AFP does not provide a cure, it would indicate that the fault lies somewhere with the Panasas. The other possible culprit is Tiger's implementation of NFS. To test this, I am building a more generic (non-Apple, non-Panasas, non-proprietary) NFS server to test from, on a Linux install on my new Dell laptop.

So, best laid plans, and all that. What a frickin' mess.

I'll keep you posted as I learn more.

UPDATE 1:
I built a Linux install for the express purpose of testing networked Mac home accounts on a non-proprietary (non-Mac, non-Panasas) NFS mount. When running a Mac home account from this mount, the Final Cut problem disappeared, and the application acted normally. The same was true for Microsoft Word. Illustrator CS still behaved badly, though, as did Flash MX 2004. It's clear now that these problems result both from Tiger's implementation of NFS as well as Panasas's. So, the breakdown goes something like this:

• The Flash problem is probably Flash/NFS-specific (though possibly Mac-specific as well)
• The Illustrator problem is Tiger/NFS-specific
• The Final Cut and Word problems are Tiger/Panasas-specific

None of this makes my job any easier. It kind of sucks to realize that there is no magic bullet, because that means that there probably is no single fix. Still, it's useful to know.

UPDATE 2:
The issue with Final Cut is not a matter of the application being unable to read files; it's a matter of it being unable to write them. Essentially, FCP cannot write a preference file. Launching with no preference file, FCP creates a 0 byte preference file in the user's home account. Also, if you try to save the FCP project file to the NFS share, it will be a 0 byte file and unopenable. Saving the FCP project file to a local volume results in a perfectly usable FCP project file. The complete inability to write files seems to be unique to Final Cut. Other applications (Illustrator, Flash) seem to have trouble reading files, but writing them seems to work fine (which is why I assumed this was the case in FCP). Word (now updated to 11.2) also has trouble writing files, but only when saving an open, modified document. That is, if you create a new document in Word, and hit "Save," it saves just fine. If you keep the document open, make changes, then hit "Save" again, it complains that it can't write to the shared disk. Hit "Save" again, and Word will create a new document and use the first string of characters in the document as the name. "Save As..." however, works as expected.

UPDATE 3:
It occurs to me (through the suggestion of other, smarter folks) that maybe this is not completely an NFS problem, particularly in the case of the apps that have problems writing files (Word and FCP). Those apps work just fine when we mount our homes on a generic NFS export. So it's possible that the write problems we're having are filesystem-related, not NFS-related. This theory holds a lot of water considering the fact that the Panasas uses its own, proprietary file system.

UPDATE 4:
I've been in contact with the Panasas folks, and I'm working with them in trying to determine the problem. So far, I've sent them tcpdump results from both the Panasas and the Mac while FCP tries to save a file. I'm told that there are a "massive number of 'file not found' type errors" from the dump. That can't be good. I've also sent them a few file listings from the home account of the user in question. Meanwhile, I'm wondering if the next Tiger update will do anything to correct these issues, or if upgrading the Panasas shelf would help, while at the same time, trying to come up with a reasonable workaround, in case Panasas is unable to reslove the issue. The only thing I can think of is to move the Mac home accounts to another server. Which would suck hard. Two steps backward.

UPDATE 5:
Still in constant contact with Panasas. I'm sending them log files now, and planning to do a ktrace, which will be a new experience for me. Also, I'm seeing this issue occur with other applications now. In particular, Macromedia Director MX 2004 is unable to write files to the Panasas mount. This is particularly odd because under Panther that application had a completely different problem: it just wouldn't launch. So I'm currently dealing with three seperate incident reports: one for the problem noted here, one for a blade crash that happened a couple of weeks ago, and one for the original Flash problem from our Panther days. It's a pain. Fortunately, the Panasas people are very nice, professio nal, and helpful.

UPDATE 6:
So, this does seem to be a filesystem issue at its core. Sort of. After much work with the Panasas guy, we've narrowed down the problem considerably.

Mac applications write temporary files -- files that are in use but that haven't yet been saved -- to various locations depending on the app. Final Cut writes its temporary files to a folder called .TemporaryItems at the top of whatever volume the user is working from. So in our model, the top volume is /home, and the sboy home account is inside /home. The whole thing looks like this: /home/sboy. Final Cut wants to write its temp files in /home/.TemporaryItems. And it is able to do this. If I look in /home/.TemporaryItems, I find all the files I've been unable to save to my user account, perfectly intact. So, temporary files go in /home/.TemporaryItems, and saved files in /home/sboy. Now, here's the grind: The Panasas setup requires that each home account be a seperate volume. So, /home is one big volume, and /sboy is another volume inside /home. This means that when Final Cut tries to move the temporary files from the .TemporaryItems folder, which is located on the volume /home, to the sboy user account, which is another volume at /home/sboy, it is moving the files across filesystems. And we get an error.

Interestingly, moving files across filesystems when Panasas is mounted on a Linux box produces the same error, but Linux does something to compensate for this problem, and is then able to save the file. But the error still gets produced. It's just that Mac OS X 10.4.2 (this did not happen in Panther) does not have the mechanism to correct for this error. It gives up and leaves the file in its original location: the /home/.TemporaryItems directory.

Also, this explains why everything works fine when I mount the user's home account on my Linux NFS export. In that case, everything is on the same volume, and there is no moving of files across filesystems. It's got nothing to do with NFS at all.

I'm curious to know why this doesn't happen in Panther. Is it possible that Panther has the same error correction function we see on Linux? What about earlier versions of 10.4? Do they have this mechanism? Will 10.4.3 have it? I surely hope so. I'll be looking into who I should contact at Apple about all of this.

Incidentally, the Panasas guys have figured all this out by examining ktrace and tcpdump files made while the program ran and the error occured. I did not figure any of this out on my own. All I did was run the commands and upload the files. Still, it's a nifty bit of sleuthing. I'm learing a lot.

UPDATE 7:
So, after mulling this over for a while, a rather obvious workaround occured to me. Currently, we mount the entire Panasas volume on our systems. This volume includes all home accounts within it, as well as the .TemporaryItems folder at its top level. Each user's home account on Panasas is a separate volume, and so is the top-level volume that contains .TemporaryItems, so saving files must cross filesystems (from the .TemporaryItems folder on /home to the user's folder). The workaround is to mount each user's home account individually. Doing so causes FCP to treat the user's home account as the active volume, and to use the .TemporaryItems folder in said home account. In this scenario, no filesystem boundaries are crossed, and no error occurs. I tried it, and it works. FCP (and Word, incidentally) can now both save files to the user's home account normally, and application preference stick. Final Cut is again usable.

Hallelujah!

I'm testing this on a couple machines before I go and announce it to the community and put it on all the Macs, just to make sure it works properly. But it's looking good. I'm glad to know that the past two weeks I've spent on this haven't been in vain.

Why We Need Anti-Virus Software for Mac

I recently wrote a review of the excellent antivirus utility, ClamXav. I also read constant articles and hear constant debate about whether or not you need virus protection on the Mac. I used to be in the camp that says, "There are no viruses for Mac, so why use antivirus software?" But nowadays, I find myself in the other camp, the one that says, "Of course we need virus protection on the Mac, you idiot."

To be honest, I was never as cavalier as to suggest that no virus protection was ever needed on Macs. But we Mac folk are in an interesting predicament (though not as interesting as our Windows-using pals): Currently no viruses directly affect us, and antivirus software for Mac is, by and large, abhorrent. In fact, it is far more likely that your system will be adversly affected by antivirus software than it will by a virus. To wit, Norton Anti-Virus has frequently caused numerous problems on client Macintoshes I manage in my freelance duties. Moreover, many antivirus software packages install kernel extensions, which is the surest way to hose a system. Even Apple recommends against it to developers, citing kernel extensions as a last resort. I frankly don't understand why antivirus software would have need of kernel extensions, given that all it really needs to do is scan files and compare them against a list of known viruses, but apparently the Norton folks think this is important. And it's been wrecking people's systems.

So, the state of things being what they are, it's no surprise that Mac users just go, "Fuck this," and ignore the problem, or worse, deny it. I mean, what else is a poor Mac gal or fella to do?

Let me back up here and explain why I've switched camps. There are two reasons, actually. One, I work in a very heterogenous network, and I see the effect Windows viruses can have on our systems. And on our Windows admin. It's hellish. And it's a problem that, while I don't personally suffer from it, I certainly don't want to contribute to. Macs can and do spread viruses to other computers. I've seen it happen. At this point I could launch into a whole number about how we're all citizens of the internet, and how it's our responsibility to be good ones. But I won't. Instead I'll tell you my second reason for switching camps: I got a virus. Yep. Sure did. This virus (actually, I think it was a worm, but we'll treat all such programs as "viruses" for the purpose of this article) was passed to me, I believe, by a Windows user inside a Word document. Unfortunately, I needed this document, and I needed to send it back out to other Windows users. Fortunately, I had a trusty old copy of Norton Anti-Virus and an OS9-bootable system from which to do the repairs. But if I hadn't, I would not have been able to use the document. If my job had been dependent upon that document... Well, you can extrapolate. Unless you're planning on never sharing files with anyone other than Mac users -- ones who also only share files with other Mac users, by the way -- you do have to worry about viruses. Just not as much as Windows users. Here I like to paraphrase the AIDS prevention folks: When you're sharing files with someone, you're sharing files with everyone they've ever shared files with. And the internet is, like, one big, giant file-sharing orgy. Do you really want to be running around out there without a condom?

Me neither.

I don't want to get too much into the options. This is more an explaination of why we Mac kids do actually need some form of virus protection. But I will quickly tell you what I do, and why I've settled on my method. My method is the ounce of prevention method. I use ClamXav on my systems and do weekly scans. Also, using ClamXav's new "Sentry" feature, I have a few watch folders: my mail, my downloads folder, and any folder I might be sharing on my LAN. (Keep in mind here that ClamXav does not scan subfolders, for performance reasons.) This pretty much covers most of the bases. If you get ClamXav set up right, you should be in real good shape when it comes to detecting viruses. Unfortunately, ClamXav does not repair viruses. So if you already have one, or if, God forbid, one should squeak by, you'll need something to fix it. I'm lucky. I have my old OS9-Norton system. But these are becoming almost as rare as Mac viruses themselves. If you have a virus now, you should quarantine all instances of that puppy, go do some research, and find the least invasive, non-kernel extension installing antivirus repair software you can. If you can run it off the CD without installing anything, all the better. Otherwise, just wait. Yeah, you heard me. Wait. The chance that you'll get a virus is pretty slim, and it's quite likely that, by the time you do, any virus software you buy today will be out of date, obsolete, or just plain useless. So wait, and if a virus ever rears its ugly head on your system, then go buy something to fix it. Oh, I might also suggest that if the antivirus software does have to be installed on the system, you might want to use a spare firewire drive for the install, provided you have one, of course. I like to have a lean, bootable OSX system on a small firewire drive, install the antivirus software there, and boot from this drive when I have a problem. That keeps my primary boot drive clean of antivirus cruft.

So that's what I do. And that's what I think. And so far, it's worked pretty well. The only thing that kind of breaks my flow is when freelance clients freak out and install Norton AV on their systems without asking me about it first. Ever try to remove that shit? Holy Hell. Thank my lucky stars for this uninstall script, but until I found it, it was murder.

Okay, kids. Time to go put a helmet on that soldier.