Extra Pepperoni

I’ve said it before, and I’ll say it again: Apple should’ve picked a simpler mail server for Mac OS X Server — preferably one that used user-accessible mail files or folders, like UW or Dovecot or Courier (I’ve only used UW, and it wasn’t great, but it was simple, and Apple obviously liked plain files over databases enough to customize Blojsom instead of WordPress).

Somebody in Cupertino decided it was a point of pride that MOSX must be able to handle a large-scale enterprise workload, and they picked software that’s cluster capable, but who would choose (very nice) Xserves to provide mail service for tens of thousands of users? Apple isn’t even actively pursuing this market, although they assure us clustered Xserves running Xsan over Xserve RAIDs would be fast. No way — in that market, lack of RAID controller redundancy is an instant deal-breaker, just as lack of redundant power was in pre-Intel Xserves.

If you’re going to provide an industrial-strength mail server (intended to be no harder to install and configure than a USENET newsfeed — yowch!) to Mac users, you need to provide more than 2 buttons for troubleshooting Reconstruct (account) and Repair (database). They have never solved a problem for me.

When these fail, Mac users are out in the cold. Apple’s documentation is grossly inadequate for troubleshooting, their fora are not helpful, and their build of Cyrus is just different enough to make things more even complicated than they need to be.

I’ve had database corruption about 3 times in the past, and eventually writhed my way out of it. This time, my $15 CyberPower UPS (which I liked, as it worked better than my $100 APC & Tripp-Lite UPSes) spontaneously expired Christmas Eve while we were at my parents’ house. Feh! When we got back home, it wouldn’t turn back on.

Apparently this happened at a poor time, and a message got eaten (INBOX #76641, to be exact). Eudora simply couldn’t check my INBOX — the server died every time. Eventually, I got an informative error from SquirrelMail which helped finger the bad message, copied another message to user/pepper/76641., fixed up ownership, and sacrificed a few Tamagotchi while running /usr/bin/cyrus/bin/reconstruct (I’d love to know who decided on /usr/bin/cyrus/bin) with different guessed arguments, until Eudora started sucking down mail as it’s supposed to once again.

That was thoroughly unpleasant. Why can’t Cyrus survive a missing message? Why can’t it warn about a missing message, or an unreadable/root-owned message?

PS-It doesn’t help that syslogd periodically stops logging mail traffic. There’s probably a better way to make syslogd work again, but rebooting does the trick. Unfortunately, this means I often have no logs of problems since it dies a little later…

Update: Apple just updated Reconstructing cyrus mailboxes in Mac OS X Server 10.3, 10.4, which provides correct usages for the (very picky) reconstruct command, but no explanation whatsoever.

I use vi daily, but much prefer BBEdit. The way I integrate them has evolved over time (see previous posts here, Useful subversion shell aliases, and BBEdit Gems (which appears to be down right now). In particular, I no longer configure BBEdit directly in ~/.subversion/config.

The new improved integration uses BBEdit whenever it’s available (I’m in front of the Mac), and falls back to the default (vi) when I’m connected via ssh.

First, I created ~/bin/edit.sh to hand off to BBEdit. I use edit.sh whenever BBEdit is appropriate:

#!/bin/sh
# Edit in BBEdit, for programs that don't support arguments in $EDITOR.
bbedit --wait --resume "$@"

Next, I configured my bash profile to prefer edit.sh when I’m not connected via ssh (which means when I am in front of the Mac or using ARD/VNC), as my EDITOR and PAGER. My profile doesn’t automatically determine whether to use bbdiff for Subversion, because I sometimes find it necessary to use non-BBEdit diff for Subversion (there are cases where the svn-to-bbedit handoff doesn’t work well, and I have ended up editing scratch files instead of the real files, for instance). Here’s the snippet that does this, from my profile:

if [[ ! $SSH_TTY ]]
then
  if [ -x ~/bin/edit.sh ]
    then
      export EDITOR=~/bin/edit.sh
    else export EDITOR=vi
  fi
  if [ -x /usr/bin/bbedit ]
    then export PAGER="col -b | bbedit --clean --view-top"
  fi
else export EDITOR=vi
fi # [[ ! $SSH_TTY ]]

In addition, I set up aliases for reviewing output from the svn command, based on Bob’s suggestions. I just copy and paste one or more lines from svn output to review changes in BBEdit:

alias  A='bbedit --wait'
alias AM='bbedit --wait'
alias  C='bbedit --wait'
alias  D='true'
alias  G='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  I='true'
alias  M='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  R='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias  U='bbedit --wait'

I update and then review status so often that I built my own TLA:

alias sus='svn update && svn status'

The following two commands provide “Subversion diff, with BBEdit” and “Subversion diff, no BBEdit”:

alias sdbb='svn diff --diff-cmd bbdiff --extensions "--resume --wait"'
alias sdnb='svn diff --diff-cmd diff -x -u'

When I’m way behind and have a lot of changes to review, I use a one-off command to review all the changes since I fell out of step. I also scan the email log messages, but this catches all the changes, skipping intermediate versions which have already been replaced and consolidating multiple edits to the same file. The command is something like:

svn diff --diff-cmd bbdiff --extensions "--resume --wait" -r1039

PS-I get the Subversion client with “fink install svn-client-ssl“.