Icons Icons Icons!

Not long ago a fabulous post on doodling appeared at one of the blogs I frequent on a regular basis, Subtraction. Khoi Vihn, the site's author, posted some absolutely lovely doodles he'd made, and I was instantly transported to my note-taking, doodle-drawing grad school days. It was kind of magical, and I really liked that idea for a blog post. And while I've decided I'm way too lazy and busy at the moment to scan my doodles, I did feel TASB could use a splash of the creative. I am, in addition to being a SysAdmin, a visual artist, after all.

Since this site is primarily about systems, it seemed appropriate to focus on an art form specifically related to the computer. And since I dabble in icon creation, and have worked up quite a collection over the years, I've decided to post a little sampler, and talk about my process. Just for a wee change of pace. Just for fun.

This is the first icon I ever made. I labored on this thing for days, trying to get that shiny, translucent, jelly bean look so prevalent on the Mac. Yes. It totally sucks major ass.

My First Icon: It Sucks Major Ass
(click image for larger view)

I quickly outgrew the glossy, candy-coated style — especially once I realized that I sucked at, and didn't enjoy making them — and started developing my own. I have two basic styles. The first one to emerge was a very flat, geometric style. My process is not very elegant, but I've used it for some time now and it works so I stick with it. Basically all the drawing is done in Illustrator. When I get a version I like I simply copy and place it into a 533x533 pixel Photoshop document. Typically, some color correction is required after the transfer. Mainly, the blacks get washed out, so I have a Photoshop action that selects the black range and drops it down to zero. Then the image gets resized to 128x128 pixels. Finally I use IconFactory's IconBuilder 5.1 plug-in (no longer current) for Photoshop to export the image to the icon format. Typically, here I just do a "QuickBuild" (which, unfortunately seems to be missing from later versions of IconBuilder). I don't really worry about creating multiple versions of my icons for different icon sizes and views. I just try to make icons that scale reasonably well. This is for fun after all. I'm not a pro, nor do I aspire to be.

Geometric Icons: Not Quite as Sucky
(click image for larger view)

The second style, and the one I generally prefer to work in nowadays, is more hand-drawn and cartoonish. Still somewhat flat, with some shading but no gradients and far less geometry than the above. These are all done using my trusty WACOM tablet, which I simply adore. Working this way allows me much greater expressiveness through line weight and shape, and through the individuality of my own particular drawing style. Plus it's just way more fun, though it can be a lot more work to get everything looking just right.

Hand-Drawn Icons: My Personal Faves
(click image for larger view)

A lot of these icons were intended as drive icons. I have a few different computers I work on regularly, and I tend to file-share between them a lot. Each has a SysApps partition and Work partition. Labeling each SysApps and Work drive on each system, while being aesthetically pleasing, also has the added advantage of making it very easy to distinguish which SysApps or Work drive I'm accessing at a glance when file-sharing. It's both practical and pretty. (Well, I think so anyway.)

Marx Brothers Icons: I Got Paid!
(click image for larger view)

Recently someone took notice of some of the icons I'd used in he lab and commissioned me to make him a custom set based on the Marx Brothers, he being a big Marx brothers fan and all. We worked together to figure out what he would like, and he gave me all kinds of resources and suggestions for the project, but I had a lot of freedom. It was the first and only job I've ever had like that. The first time I've ever had to create something visual for someone other than myself, but he was very cool to work with, I liked the challenge, and it was a really fun process. Basically I worked on it in my spare time, and I'd show him progress sketches every so often. He'd give me feedback and I'd go work on them some more and show him the results when things got good. The thing I liked best about the project was this outside feedback. It really kept me from being lazy. And in the end the icons were far more polished than I think they ever would have been had I just been working on them alone. I'm kind if a loner in a lot of ways, both professionally and personally. Not a big collaborator. But every now and then it's great to have some outside eyes. Some second opinions.

Which, now that I think about it, may be the whole reason to have a blog.

Software Licensing and Registration Hell

Is it just me, or has software licensing and registration in some quarters become a total nightmare? Case in point: Today I'm trying to install Autodesk's Combustion 4, a fine compositing and effects program, somewhat akin to Adobe's AfterEffects. From a SysAdmin's standpoint, however, the two are night and day. To activate AfterEffects, one simply need install it and enter the serial number provided with the software bundle. That's it. It's done. Ready to use. Moreover, this one serial number is valid for the number of machines specified by our license agreement with the company. Adobe trusts me to install the software only on the number of machines agreed upon by our license contract, or to otherwise monitor licenses on our network. The software does not perform network license checks to see if we've exceeded our licenses. Adobe leaves that to me. That's my job, after all, and I get in big trouble if I fail to do that job. In this scenario, the onus of license enforcement falls to me. Adobe trusts me to do my job, and in return, installing software is fairly straightforward. It's a good deal.

Autodesk Combustion Splash Screen
(click image for larger view)

Other software manufacturers, however, are not so trusting and approach software license management via far more convoluted and Byzantine methods. Autodesk is among these companies. To install Combustion, not only do I have to provide a serial number, I also need to provide an authorization number. This authorization number can be obtained by registering each and every copy of Combustion I intend to use. The process of installing just one copy of Combustion goes something like this:

1. Install the software from disk.
2. Launch the application and type in the serial number for this copy.
3. Activate the "Licensing Wizard."

Autodesk Registration Splash Screen: Here We Go...
(click image for larger view)

4. Upon magical transportation to the Autodesk registration page, register the software by entering every personal or professional detail they can think to ask you about, including the serial number of said copy of said software.
5. Check your email, where you should shortly receive the authorization number for your copy of Combustion.
6. Enter this Authorization Code into the special box.
7. You should finally be able to use Combustion.
8. Lather, rinse, repeat for every copy you bought.

Autodesk Registration Panel: Are We Having Fun Yet?
(click image for larger view)

Whew!

Okay, there are a couple of big problems with this scenario. First off, if there's any problem along this insane route, you can get quite stuck. In my case, the registration site did not work. The error page directed me to file a Customer Service Request, but the link to said request was also broken. This means that I will have to register my software either by fax, mail or possibly telephone. It also means I will have to do this myself for each and every copy of Combustion I've purchased. I have five copies. Thank god I don't have more, because it's going to take me a while to install this software. And this is the other problem with this sort of arcane licensing scheme: It doesn't scale. Imagine if I had a hundred machines I wanted to install Combustion on. It's practically infeasible at worst, unbelievably annoying at best. And I have to say, all it makes me want to do is buy any product other than Combustion, just to avoid the install hassles.

Autodesk Online Registration: Broken!
(click image for larger view)

There are a number of software companies besides Autodesk that use these sorts of tactics: Cycling '74 and Digidesign spring immediately to mind as some of the most heinous offenders, but there are others. They seem to think that the best way to protect their intellectual property is to make their products difficult to install and maintain. The companies that do it right are ones like Apple, Adobe and, shockingly, Microsoft. These companies have volume license schemes and educational versions of their products that are relatively easy for institutions to install and maintain. They recognize the value of getting their software in the hands and minds of young users, and they make it as easy to do so as possible. And I think they recognize the value of happy SysAdmins, too. They know we're the ones who make the recommendations for future purchases, and that maybe — just maybe — it might be a good idea to not make our lives a total living hell.

So, to Autodesk and others like you, here's a little secret: Systems Administrators hate you. We hate your fucking guts. Because, for us, installing your software is ten kinds of torture. There's no reason for you to do this except for a clear contempt on your part towards the SysAdmin community, and most likely your users in general. Or just general stupidity. You're not stopping anyone from stealing your software, and frankly you're keeping those of us who plan to use it legitimately from even wanting to do so. In fact, I'd argue that stealing your software is far easier than installing it legitimately. So all you're really doing is punishing your legitimate users. It's so stupid, and I'm so sick of it, and I'm sure I'm not alone. But more than that, it's just bad business. The next time someone asks me to recommend a piece of compositing software, I'll think of all the hassle I had to go through to install Combustion.

And then I'll recommend AfterEffects.

UPDATE:
In the comments some astute readers have provided a link to a whole site that deals with application installers and requirements that present problems from the standpoint of educational lab administration. The site is more concerned with apps that require user-level authorization files or user-level access to parts of the filesystem that should be protected, while my article deals more with plain-old annoying installers and licensing schemes. Still, it's a great site, and a good compliment to this post, and I wanted to link to it directly:
Poorly-Made Applications

Amazingly, some of these practices are holdovers from the OS 9 days, when security and multiple users weren't really issues to Apple or developers (or Lab Admins). It's shocking to me that after all this time a lot of software developers still can't figure out how to properly, securely, or even conveniently install apps in Mac OS X.

Thanks to those who sent in the link.

Adobe Legal Hosed My System

So recently there's been a bug in, according to Adobe anyway, Mac OS X that causes certain files in certain Adobe CS2 applications to wreak untold havoc on HFS+ filesystems. In a fairly recent Adobe Support Knowledgebase article on this issue Adobe says, and I quote:

Background information

Mac OS X causes illegal file names to be reported when it reads some of the font data used in the Vietnamese End User License Agreements, which are installed in the Legal or Legal.localized folders. This problem causes severe file system and hard disk corruption if the files are not deleted or if the file system is not repaired.

Apple fixed this problem in Mac OS X 10.4.7.

The fix for this, Adobe goes on to say, is to get rid of any folder in any Adobe CS2 application folder called "Legal" (in the Finder) or "Legal.localized" (in the Terminal), and then run Disk Utility to repair the disk. They also suggest that upgrading to Tiger 10.4.7 or later is a good last step as it halts the corruption process.

I'd actually had the problem last summer on my lab systems, which had exhibited evidence of it during a clone operation. Any clone of a system would fail, and the asr command would actually report the name of the trouble file. Indeed, running Disk Utility's "Repair Disk" (or in our case, fsck from single-user mode) would fix the problem and our clones would subsequently succeed. Those systems were running 10.4.7.

My office system, on the other hand, never went through the cloning process, so I never detected the problem. But I seem to have been bitten by this bug and in a bad way. Please note the last sentence in the above quote:

This problem causes severe file system and hard disk corruption if the files are not deleted or if the file system is not repaired.

Yesterday I was running Disk Utility on a problem drive and decided to run it on my system partition as well, for good measure. This was the output:

Disk Utility: Reports Unfixable "Illegal name"
(click image for larger view)

See that "Illegal name" error in bright red? That's a telltale sign that you've got the "Adobe Legal bug" (as I like to call it). It's also, I can tell you from cold, hard, agonizing experience, a telltale sign that you are indeed fucked. Hard. I think this is what Adobe is referring to as "severe file system and hard disk corruption." I tried everything to make that "Illegal name" error go away. Actually, attempts to fix the problem took more time than it took for me to rebuild my system, which is what I ultimately had to do. Now I hate rebuilding systems. Almost as much as poking myself in the eye with white hot forks. So I spent the better part of the day attempting to fix the problem.

The first thing I did was to boot into a good system partition. I just happened to have a base Tiger OS installed on a firewire drive, so I booted into that. I then went through the aforementioned Disk Utility and fsck routines. (I also tried Disk Utility from the Tiger DVD, just to be thorough.) No luck. I always got the "Illegal name" error. I also tried fsck with some options to see if I could actually track down the file with the illegal name and delete it. Running:

sudo fsck_hfs -frd /dev/disk0s10

Produced the following output:

** /dev/rdisk0s10** Checking HFS Plus volume.** Checking Extents Overflow file.** Checking Catalog file.** Rebuilding Catalog B-tree.hfs_UNswap_BTNode: invalid node height (1)** Rechecking volume.** Checking HFS Plus volume.** Checking Extents Overflow file.** Checking Catalog file.Illegal nameillegal name is 0x00 54 00 69 00 65 03 02 03 01 00 6E 00 67 00 20 00 56 00 69 00 65 03 02 03 23 00 74 00 2E 00 68 00 74 00 6D 00 6Creplacement name is 0x00 54 00 69 00 65 03 02 03 01 00 6E 00 67 00 20 00 56 00 69 00 65 03 23 03 02 00 74 00 2E 00 68 00 74 00 6D 00 6C** Checking multi-linked files.** Checking Catalog hierarchy.** Checking Extended Attributes file.** Checking volume bitmap.** Checking volume information.Verify Status: VIStat = 0x0000, ABTStat = 0x0000 EBTStat = 0x0000        CBTStat = 0x0000 CatStat = 0x8000** Repairing volume.replacement name already existsduplicate name is 0x00 54 00 69 00 65 03 02 03 01 00 6E 00 67 00 20 00 56 00 69 00 65 03 23 03 02 00 74 00 2E 00 68 00 74 00 6D 00 6CFixIllegalNames - repair failed for type 0x23B 571** The volume SysApps could not be repaired.volume type is pure HFS+primary MDB is at block 0 0x00alternate MDB is at block 0 0x00primary VHB is at block 2 0x02alternate VHB is at block 66846718 0x3fbfffesector size = 512 0x200VolumeObject flags = 0x07total sectors for volume = 66846720 0x3fc0000total sectors for embedded volume = 0 0x00

This seemed to suggest that, yes, there is an illegally named file somewhere, but that it can't be replaced because the replacement name already exists. Ew! I'm not sure what that means, but it does not sound good.

Undaunted (alright, maybe a little daunted), I decided to try cloning the system to see if I could get the name of the illegal file like I did last summer, using the asr command. I also thought it was possible that any filesystem damage, depending on the nature of that damage, might be repaired by cloning the system to a clean, undamaged filesystem. So I created a 40GB disk image, which actually took quite some time, probably because I was booted from a slow firewire drive. But it finally completed, and once it did I cloned my sick system partition to it. This also took a great deal of time over firewire. Like hours, actually. Like I actually had a good excuse to go to lunch for once. But it did finish successfully, and it never reported an illegal name in the process of cloning. So I ran Disk Utility on it, hoping that maybe the new filesystem did the trick. No such luck. Same error.

By this time I'd spent — wasted, actually — an entire day on this problem. A problem apparently caused by "font data" robbed me of an entire day of productive work and put me in a nasty mood to boot. My options spent, I did the thing I hate to do so very much: I rebuilt.

There is at least one silver lining to all this, and that is the magic of disk partitions. You see, it's for reasons just such as these that I partition my user data from my system and application data. Every Mac system I build has a partition called SysApps — that houses the system components and applications — and one called Work — that houses all the data I generate, from home account preferences to Final Cut files. In the above scenari o it was the SysApps partition that was corrupted, but the Work partition checked out just fine. This two-partition method offers numerous advantages in such a scenario. For one, after booting into the firewire drive it was a simple matter of telling NetInfo Manager to use my home account on the Work partition and I was right back to work checking email and the like, which is pretty crucial for me to be able to do. All my setups and preferences worked normally, my browser bookmarks were all there, my calendars were all intact, and I could at least work on actual work instead of being stopped dead in my tracks by this corruption problem. Secondly, in this case reformatting the SysApps partition was necessary. Had all my data been on that partition I would have had to back it all up somehow. And what if that corruption lay somewhere among my user data? I'm not sure what I would have done then. I may just have been screwed. But because my data was walled off, it was a non-issue. Thirdly, my Work data takes up the majority of the data on my system, and it's quite large — about 170GB. In a single-partition system I'd have had to blow all that away and restore it somehow. Backing up and restoring 170GBs of data takes a long time and would have significantly increased the amount of time I spent getting back on my feet. With my two-partition system, about 30GB was all I had to worry about. And all that cloning I did in the hopes of finding a fix? With my 30GB SysApps partition it was painful and time-consuming, but it was doable (though whether it was worthwhile is debatable). If I'd had to do that with 200GB of system, application and user data combined it would have been downright impossible.

Restoring the SysApps partition was a pain, to be sure. But there was nothing there that didn't already exist somewhere among the myriad software installation discs in my office, so it wasn't so bad. And there was a lot of stuff I could restore right from the backup I'd made with asr — things like drag-n-drop applications, crontab and host files, and the like. Troubleshooting the problem took about a day, but rebuilding the system took a few short hours, in part because most of my preferences reside in my perfectly preserved home account. It was mostly just a matter of cloning a working system (from my base Tiger install on my firewire drive), reinstalling a few broken applications (Final Cut, Adobe stuff, etc.), and running Software Update as needed. Along the way I checked the health of my SysApps drive, and no "Illegal name" errors were reported. Phew!

So that's the saga of how Adobe Legal hosed my hard drive. I'm not sure if the blame really lies with Apple or Adobe. What I do know is that I'm sticking with my two-partition system, and I'm permanently deleting all those "Legal" folders associated with Adobe products. I suggest you follow this latter step yourselves, 'cause, if left untreated, it's true what they say: It really can cause severe filesystem and hard disk corruption. I'm living proof.

Publishing iCal Calendars via Mac OS X Server

So a lot of people are familiar with my articles on publishing iCal calendars to the 'net with box.net. But it turns out that I also have to provide iCal publishing for staff on our internal network, and I do this using a Mac OS X server. Recently, after rebuilding my server, I had some problems with it and had to set it all up again after not having done it in quite some time. It's pretty easy, but there's one snag I got hung up on. We'll get to that in a minute. But first let's run through the steps to set this up. First and foremost, setting up iCal publishing on Mac OS X Server requires the web server to be running. This can easily be done with the flick of a switch in the Server Admin application. But before we start the service, let's make all our settings. The first thing we need to do is set the root folder for our site. Now in my situation I'm not actually doing any web serving. All I'm doing is calendar serving, and only on our internal network, and that's all I'll describe here. The standard site root folder in Mac OS X Server is /Library/WebServer/Documents. To make things a bit cleaner and easier I'll put all my calendars in a subfolder of this called "calendar," and since that's all I'm serving I'll make that my site root: /Library/WebServer/Documents/calendar. I've given my site a name — systemsboy.com — and manually set the IP address. Otherwise I've left everything alone.

Server Admin: General Web Settings (click image for larger view)

Next up we want to set some options. WebDAV is, of course, key to all this. Without it the calendars can't be served in a form we like. So turn on WebDAV. I've also left Performance Caching on and turned everything else off. Again, this is just for serving calendars.

Server Admin: Web Options (click image for larger view)

Finally, we need to set up our "realm" which is a place where WebDAV/calendar users can share files. To do this, first add a realm to the first box on the left there by clicking the big plus sign beneath it. Give the realm a name, and give it the path to the calendar folder we set as our site root. I am just using "Basic" authentication as this is only going on our internal network and security isn't a big concern in this instance. Once your realm is set up, save the changes and then add some users or a group to the boxes to the right of the realm box. In my setup I added a group called "icalusers" which contains all the users who need to and are permitted to share calendars. I've set the group to be allowed to browse and author. This is necessary for users to read from and publish to the server respectively. You can do the same with individual users in the upper box. Once you've got that set up, save your changes and start the web service.

Server Admin: Realms (click image for larger view)

That's pretty much it, except for one crucial thing: permissions. I always seem to forget this, but permissions on the calendar folder must be properly set. Since WebDAV permissions are handled by the web server, the proper way to set this up is to give the user that runs the web server ownership and read/write access to the calendar folder. In most cases that user is called www. It's probably a good idea to give group ownership over to the www user as well. So before this will work you need to run:

sudo chown www:www /Library/WebServer/Documents/calendar

To set the ownership to www, and:

sudo chmod 770 /Library/WebServer/Documents/calendar

To give said user full access to the folder. [Updated to reflect user comments. See note at end of article for details. -systemsboy]

Once that's done, just start the web service in the Server Admin application by selecting the "Web" service in the far left-hand column and pressing the big green "Start Service" button in the app's toolbar. You should now be able to publish and subscribe to calendars on your Mac OS X Server from iCal. The publishing URL for my example would look something like this: http://systemsboy.com

And subscribing to the calendar, where "Birthdays" is the calendar name, would look like: http://systemsboy.com/Birthdays.ics

Simple, right? Yeah, I thought so too. Just watch those permissions! Bites me every time.

NOTE: I had originally reported that permissions for the calendar folder should be set to 777. A couple readers pointed out in the comments section that this is not the case. I have edited this article to reflect their suggestions which are a much better solution than my original one.

Thanks, guys, for pointing that out! Really good to know!