Musings

Upgrading the Laptop

My laptop had about 7 GB of free space on it, when I popped the Leopard DVD into the drive. The upgrade went smoothly and I logged in to find that the Login Window background and my desktop had been changed to the large cats in space theme.

That image (the little PNG really doesn’t do it justice) would definitely seem really cool … if this were 1977 … and you were high. But it seems distinctly out-of-place next to the sleek, professional æsthetic Apple tries to convey. This is truly one of those instances where one is moved to ask, “What were they smoking?”

Fortunately, changing Desktop backgrounds is trivial¹. How to change the Login Window background is a little less obvious.

Anyway the above picture does illustrate something else. The new Dock is every bit as hideously unusable as John Siracusa said. Those nearly-invisible pale blue spheres? They are supposed to indicate which applications are currently running. Fortunately, this, too, was easily rectified:

defaults write com.apple.dock no-glass -boolean YES
killall Dock

produces a not-very-pretty, but at least usable, Dock alternative.

Anyway, after installing XCODE 3.0, and upgrading Fink, I realized that I had less than 1 GB of free space left. I decided to reboot, to see if that freed up some space.

That led to an interesting revelation. Upon rebooting, my account was missing from the Login Window. In fact, even though my files were still there, my user account had been disabled. I could not login, either in the GUI or at the commandline. So I logged in as another user and, following these instructions, restored my account:

su
dscl . -delete /Users/distler AuthenticationAuthority
passwd distler

The other (obvious) sign of breakage was the SSH client², which required a small patch and a recompile.

That was good for another reboot, until I ran into another problem: Leopard has a modified version of ssh-agent, which has built-in Keychain integration. Whenever you try to ssh (whether from the commandline or in a GUI application), it pops up a window to add your passphrase to the keychain. Or it would, if I had not replaced their ssh-agent with the stock one from OpenSSH 4.7p1. Now the LaunchAgent voodoo, which made this possible, caused the SSH client to deadlock. Since I’m not sure how I feel about Keychain integration for ssh-agent, I just added a

<key>Disabled</key>
<true/>

to /System/Library/LaunchAgents/org.openbsd.ssh-agent.plist. I flirted briefly with trying to port Apples’s changes to OpenSSH 4.7p1, but it quickly became clear that was a fool’s errand.

The GPGMail Bundle needed to be updated, but the author of the MailPictures bundle is AWOL, so that nice little bit of old skool technology may just have to die a quiet death.

I’m still struggling to clear out 5 Gigs or so (I, currently, have 2.6 GB free), so that I don’t have to live in constant fear of running out of disk space. But, all in all, that went pretty well.

Lingering problems:

• At least for me, the STIX fonts don’t seem to display Astral Plane characters any more. They did in Tiger. See, e.g., this page. (Fixed on Mozilla Trunk.)

• I never had DNS problems on Tiger, but now, any sort of fleeting network interruption requires a

  % sudo dscacheutil -flushcache

  to set things aright.

• And there’s the fact that iCal, no matter what I do, keeps prompting me for my Keychain password every half hour.

But, hey …

Upgrading Golem

Thus emboldened, I decided to upgrade my desktop machine.

I was ready for all of the above hassles. Then there was relatively minor stuff. Apple seems to be phasing out StartupItems (xinetd has already bitten the dust). Most of the previous contents of /System/Library/StartupItems, for daemons like Apache and the QuickTimeStreamingServer, are gone.

Some are replaced by LaunchDaemon items. Others, like the one for QTSS, are just gone (presumably, you are expected to buy MacOSX Server). Fortunately, they were easy to snag from backups.

SRP telnetd had to be recompiled, because it kept hanging after authenticating. I started again with the stock SRP-2.1.2 distribution, and patched only those bits that caused errors under Leopard – chiefly to do with utmp versus utmpx. Under earlier versions of MacOSX, there were some vagaries in pty-handling which are now fixed in Leopard (and, I’m guessing, the previous workaround was probably responsible for the hang).

Sendmail was a much bigger headache. I had to recompile it. But, even after doing so, it refused to start.

dyld: Library not loaded: .libs/libsasl.7.1.11.dylib
  Referenced from: /usr/sbin/sendmail
  Reason: unsafe use of relative rpath .libs/libsasl.7.1.11.dylib in /usr/sbin/sendmail with setuid binary

Leopard’s security has been improved, and it is rather more cautious about loading shared libraries than Tiger was. That’s good. But I needed Sendmail working, and I needed SMTP-Auth.

Recompiling Cyrus-SASL did not help. Switching to using Leopard’s SASL2 Libraries allowed Sendmail to launch, but I could not get anything to authenticate using those libraries. Eventually, I tried using Fink’s Cyrus-SASL2 libraries, and once I figured out that the users’ secrets are to be stored in /sw/etc/sasldb2, instead of /etc/sasldb2, everything worked. Why Fink’s libraries worked, but hand-compiled SASL libraries didn’t, is a mystery.

Another mystery is that Leopard changed the numeric groupid of smmsp from 19 to 25. This managed to break client mail submission till I did a

sudo dscl . -change /Users/smmsp PrimaryGroupID 19 25
sudo chown smmsp:smmsp /var/spool/clientmqueue

Finally, most inscrutably, all my crontab files had disappeared. Well, not really. They were all still there in /var/cron/tabs/; they just weren’t being used anymore³. No big deal; I just did a

crontab -e

and copy/paste the old ones.

That didn’t entirely solve the problem. I get a proliferation of error messages, of the form

Nov 9 16:20:00 golem com.apple.launchd[1] (0×11e900.cron[10402]): Could not setup Mach task special port 9: (os/kern) no access

in the system logs.

Otherwise, things seem, mostly, to work. Doubtless, I’m overlooking something.

Update (11/15/2007)

A few more pitfalls.

(Re)compiling Apache produced the following interesting error, when attempting to start the daemon:

httpd: Syntax error on line 287 of /usr/local/apache2/conf/httpd.conf:  
Cannot load /usr/local/apache2/modules/mod_ssl.so into server: Symbol  
not found: _ssl_cmd_SSLCACertificateFile\n  Referenced from: /usr/
local/apache2/modules/mod_ssl.so\n  Expected in: flat namespace\n

Not clear what the deal is, but changing the configure flag from --enable-ssl=shared to --enable-ssl=static (and commenting out the corresponding LoadModule directive) solved the problem.

And apr_sendfile is (still?) borked under Leopard. So, to get Apr-1.3 (which I needed for the version of Apache I’m running — long story) working, I needed to disable it, to prevent a recurrence of this bug.

More grievous is that OSXvnc (now Vine Server) no longer works, unless someone is actually logged into the target machine. This, again, is side-effect of the tightened security in Leopard. A fix is, apparently, in the works.

Say Something Nice…

The upgrade hasn’t been all a vale of tears.

Time Machine

Time Machine is really nice. The initial, comprehensive backup was really slow. But incrementals are lightning-fast. And restoring files from a snapshot is also incredibly easy.

I’ve used Retrospect for years. Retrospect’s incrementals are slow, since it has to scan the entire disk to see what’s changed⁴. Restoring files from a snapshot is painful in the extreme (no excuse, here). And, when your backup destination fills up, you’ve no choice but to do a whole new comprehensive backup; there’s no way to ‘cull’ old incrementals.

All in all, Time Machine wins hands-down. My only reservation is that it doesn’t support multiple backup destinations. You get to choose one (external) hard drive for your backups. The truly paranoid among us would prefer a little redundancy.

iCal

iCal is much improved. The previously clunky interface is much better. And I am jonesing to set up a CalDAV server.

Ruby, …

Leopard comes with the latest version of Ruby, Rails, Python, …

Among the other cool things, this means that, out-of-the-box, it has all the prerequisites for installing Instiki. Perhaps I need slap together a one-click Installer Package for Leopard.

Data Detectors

As alluded-to above, Leopard has recreated the functionality of Apple Data Detectors, in the guise of LaunchAgents.

Mail uses this rather extensively, but the real fun is writing your own LaunchAgents to do things you find useful.

Application Firewall

Leopard introduces a new Application-based firewall, to supplement the existing port-based ipfw firewall. Since I’m happy with my existing ipfw firewall rules, I didn’t worry much about the reports of problems with the new firewall in 10.5.0. In 10.5.1, those problems have been fixed.

To make effective use of the new Application firewall, however, I’d really need to understand a bit more about the infrastructure of digitally-signed applications. It’s one thing to allow incoming connections on port 25 (ipfw). It’s another thing to restrict such connections to be handled by Sendmail (the Application Firewall). When I add such a rule, apparently, the Sendmail binary gets digitally-signed. The sigature must verify for the connection to be allowed. What happens when I recompile Sendmail? Do I need to delete and re-add the firewall rule? Or is there another way to generate a signature for the new binary? Is there a commandline interface, so that I can make this part of the installation process?

---