Making Software Update your bitch

One of the frequent problems I have with Software Update is the quaint notion that a 32M download never chokes. Instead of breaking these larger updates (usually iPod fixes) into smaller manageable downloads to be reassembled and checksummed later, Apple sincerely believes that their users will robotically sit in front of their Macs and retry these choked downloads.

In many cases you can bypass the process by going to Apple:Support:Downloads, and downloading the file directly with your browser (Safari tends to have better luck with resuming large downloads).

Trouble is, not every update is visible there. SU seems to think I need an iPod updater from 9/23/05, but there isn't an equivalent download I can grab it from. What to do, what to do.

Open the Console app, is what. Not Terminal, but Applications/Utilities/Console.app, and attempt the download once more. In all likelihood you'll find the following type of error:
2005-11-12 17:49:02.582 Software Update[2493] session:product:061-2099 didFailWithError:NSError "timed out" Domain=NSURLErrorDomain Code=-1001 UserInfo={
NSErrorFailingURLKey = http://swcdn.apple.com/content/downloads/63/63/061-2099/ FT96wN8RF2sM3TL@FpDNGm9RjbdCfj/iPod2005-09-23.tar;
NSErrorFailingURLStringKey = "http://swcdn.apple.com/content/downloads/63/63/061-2099/ FT96wN8RF2sM3TL@FpDNGm9RjbdCfj/iPod2005-09-23.tar";
NSLocalizedDescription = "timed out";
}
Nov 12 17:55:15 Andrew-Roazens-Computer mDNSResponder: ERROR: read_msg - client version 0x32303035 does not match daemon version 0x00000001
Mac OS X Version 10.4.3 (Build 8F46)


Irritating, eh? But notice now that you have an actual URL to attempt a direct download from. Select the URL, right-click it and a context menu will give you the option of going directly to that URL in your default browser. Perfect, no. Doable, yes.

Edit: Unless Apple's running Apache 2.0 with mod_deflate enabled, this isn't even being sent as a gzip but a regular tarfile. (If you're a *nix n00b, most patches and software that you have to compile yourself tend to be .tar.gz/.tgz files.) OTOH if the file is being compressed server-side live as a gz, that isn't terribly smart either. Right-click, open the tarfile with BOMArchiveHelper and you'll get a folder with another tarfile inside and a signature file; ignore the signature and right-click the second tarfile to unpack it with BOMArchiveHelper. Voila, your update package.

Obligatory Tiger/SMB gripe and fix

Upgrading to Tiger broke one quizzical thing: I couldn't Samba mount the server our library website lives on. I could mount my staff account on another almost identical Solaris server, but not the library server. Extensive research led me down a blind alley thinking that the library server's authentication was being maintained by a W2K3 server using a proprietary SMB digital signing, but when the sysadmin told me this server does its own authentication, this got puzzling.

I even hunted down the BSD command that OS X uses behind the Apple-K Connect To Server GUI, mount_smbfs, and attempted to tweak every parameter possible in the Terminal. No go.

Hopefully you're here because of a Google search for "Error -36" or something like that. Here's the link to Apple's solution. In a nutshell, passwords can be sent to a server either as plaintext (which other computers on your LAN can packetsniff) or encrypted. Most Samba servers at this point are configured to handle either; the library server (for tech reasons I can't disclose) has to use plaintext.

Prior to Tiger, OS X's Samba authentication was equipped to deal with either kind; because it posed a security hazard, Tiger disables plaintext (unless you follow their instructions and restart your Mac). Apple's helpful response is that we should all force our sysadmins to go with encrypted only. Good luck on that one.

If you're not using Tiger, this won't be an issue. If you're using Tiger and your Samba server accepts encrypted passwords, this won't be an issue. But legacy servers (or servers with a specific reason for using plaintext) will require you to do the tweak mentioned before.

I have no idea whether the code behind this change is open source enough that it could be rewritten so that each entry in the Connect to Server dialog could have a checkmark next to it for encryption and let the software make the connections case by case.

Perl, XML, and XSLT

Our website has a thumbnail of a campus photo which rotates randomly and links to a gallery page of all of the student/faculty-submitted photos. In the past, we would have managed this one of two ways:

1. A JavaScript reading an array file, typically a comma-delimited list of filename and metadata, and picking a random array element to output to HTML
2. Perl doing the same thing and being SSI included
   

Thing is, the amount of metadata we're collecting about our photos is reasonably complex. The thumbnail image URL, the fullsize image URL, the author, their title... and whether the image should only appear in the gallery. This is the kind of data that looks less like a table of columns and more like an XML manifest.

The translation of the manifest to the gallery is tailor made for XSLT (XML stylesheet transformation), and strictly speaking a modern browser is capable of doing the translation by itself -- as long as that's the only content on the page. Inserted into the middle of an XHTML document, that's another story. So, it makes sense to have the server manage the XSLT.

In order to that, the Perl we use has to be made aware of XML and XSLT. Good things and bad: first, an XML file really needs a DTD. Why? For one thing, Firefox and IE throw hissies at XML without DTDs even though they don't validate the XML against them. For another, it forces you to define the syntax of your XML. Better yet, XML editors (even Dreamweaver) actually read them and autocomplete your entries. DTDs aren't hard to write once you get used to SGML definition syntax.

Perl still sucks its thumb and sits in the corner, until you integrate XML parsers into it. XML parsers in turn rely on libexpat, whose installation was covered earlier in this blog. As a non-root user, I have to install the XML modules to a local directory; fortunately, previous experience installing FAQ-O-Matic helps here.

Why go to all this trouble? The answer's simpler than it seems. It's a database important enough to need server-side manipulation but not important enough to justify an Oracle table. Currently we're manually editing the XML manifest for the gallery, but with a DTD-based framework for this XML, we can construct webapps for maintaining that database that aren't dependent on a particular language.

With XML::Parser, XML::Simple, and XML::XSLT, we can slurp the database to a Perl dataset, add/edit/remove items and output the resulting dataset back to XML. Should another application need to work with the data, it's there in a friendly, future-extensible format.