Tag Archives: dovecot

Wow, long time between posts… well, no time like the present and I thought I’d share a my notes on the Snow Leopard upgrade in case it helps anyone else.

The rant

Firstly, the obligatory rant. I had a world of pain just getting to the install process. After my initial disc was promptly shipped out, it turned out to be from a bad batch. The first support rep recommended trying again and if it failed to call back and we’d try and archive and install. Luckily the rep that responded when I called back didn’t put me through that and just put me through to order management for a replacement disc. After an hour on hold, it’s quickly sorted out and I’m told it’ll be shipped out in 2-3 days. 3 days later I discover it hasn’t been shipped, and is instead queued for a refund. Another half hour on the phone trying to explain I wanted a replacement because it was faulty, and it actually does get prepared for shipment, arriving the Monday after the first one arrived.

The install

So, armed with working disc, I pressed forward. The install proceeded as advertised – it said it would take about an hour, and it did – up until it got to the “Less than a minute” remaining, which took about… 45 minutes before I gave up. It was apparent it had frozen. No choice but to hard power down. Rebooted and it booted into the Snow Leopard welcome – the install was successful, but I was stuck in the first time set up. Everything I tried left the registration step getting to the end with all the buttons disabled… so, onto the phone with tech support. Started by rebooting in safe mode which took a really long time but didn’t help much. So we stepped through the process anyway. As it turns out…

To skip the registration process, you can use Cmd-Q and select skip.

Not very intuitive, but I guess it discourages skipping it rather than having the button right there in the dialog. So, now I can create an account (must be a new one), and I’m logged in. Everything is still there (*phew*). Reboot into normal mode (takes an eternity to shut down), log in as myself and remove the newly created account. An hour into the call, now I’m all set.

Incidently, during frequent periods of waiting for the Mac to boot / shutdown I discussed the virtues of a clean install with the tech support, but am told that wouldn’t be possible with the Snow Leopard upgrade disc (apparently in contradiction to what I was told by the very first tech support and most of what is said on the internet – curious).

I found I’d freed about 12Gb during the process (measured using df -k to avoid being duped by the redefinition of a Gb) – a handy saving.

Checking it out, I found I had a new /Recovered Items directory which was unusual. I’m not sure if I just got this because of the missed completion of the installer. About 500Mb of data, including some things that didn’t make it (like the XCode tools). I’m holding onto it for now, but it looks like I shouldn’t need it.

Next, to see what survived the upgrade.

The Victims

I was well aware of what might and might not work after the upgrade. Here’s what I’ve found so far:

I uninstalled a few other things that I wasn’t using any more to try and get rid of 32-bit system preference panels (though most seemed to be working).

XCode Command Line Tools

Oddly, gcc-4.2 and the other command line tools were moved to Recovered Items but most of the XCode installation survived. I planned to reinstall the new version anyway, which I tried. This failed about halfway through without much information other than to try again, which I did and succeeded. Go figure.

Dovecot

I had recently moved from MacPorts to Homebrew in anticipation of the upgrade, and all continued working afterwards except for Dovecot.

First up, it seems the dovecot user had disappeared during the upgrade process. Luckily, 10.6 seems to have included one by default, _dovecot in the mail group. So I adjusted the Dovecot configuration.

Next, failure to read /private/etc/ssl/certs/dovecot.pem – had just forgotten to use sudo when running launchctl. Try again.

After that, there was a period where it wouldn’t start and gave no error in the system log. To be honest, I don’t know what I did to fix that but when I came back to it later after some reboots it was working again. Reassuring.

Eventually got it started again but failed to auth from Mail.app. The system log showed:

Seems that this has been removed in Snow Leopard. I’d been using the /etc/pam.d/dovecot file given here. I used the further recommendation on the page to remove that file and change the dovecot configuration to this:

passdb pam {
args = login
}

After all that, my local mail server is back.

OmniFocus sync server

This one was a little unusual. The sync server runs a copy of Apache HTTP Server, which was failing to start up. The logs revealed:

While the short hostname of the machine was still mcbrett as before, it turned out that my installation pattern had changed the main host name to dummy's MacBook Pro 15" (dummy being the account name I created at first). I decided it was time for a change and changed my hostname to brettporter:

sudo hostname brettporter
sudo scutil --set HostName brettporter

Along with the same change in the Sharing system preferences, this was enough to get the sync server started again.

The Verdict

Other than these, my apps (including some that had received bad reports from others) seem to be working fine.

This was a much more painful upgrade than Leopard (salt in the wounds from the painful ordering process). The disk space saving is nice, but it never lasts 🙂 So far I haven’t noticed much in the way of performance improvements and have still obtained the marble of doom – time will tell if it seems to have improved or not. I’m particularly interested in Time Machine performance.

The big wins probably won’t come until applications start to take advantage of grand central and so on. All in all that is what appeals to me most about the release – most developers would love the opportunity to take some time and just clean things up in their projects and build out the core support.

Like this:

I recently got a shiny new MacBook Pro, and of course have been instantly hooked. In less than a week I seem to have learned my way around with equal proficiency to that other inferior operating system I’ve used for so long.

However, some habits die harder than others. I kept using Thunderbird since all my mail was stored in that format and was tagged up with labels (well, they are actually tags now that its Thunderbird 2.0).

Some guy I know had been raving about how good Apple’s mail was, especially in combination with MailTags and Mail ActOn. I was keen to try it out, but not quite brave enough to switch (and even now, I’m still considering this an experiment). Most of my mail is POP from my ISP, so its stored locally.

Given that Thunderbird can’t read Apple Mail stores and vice versa, I needed a solution that wasn’t all or nothing, and something that would hopefully allow me to read and store my mail on my other machines without going through the POP keep/delete hoops which are a bit gross. I wanted one canonical store.

Given that I don’t run a server constantly, I’ve decided to use my primary machine, the MacBook, to POP all my mail to and run an IMAP server locally to read the mail from both Apple Mail and Thunderbird. The only gotcha will be that I won’t be able to share the incompatible tags, but that’s ok. If I need to move between machines I won’t be using them and I can always open the other client on this one.

So, here’s how I went about it for those that would like to try it. It was fairly straightforward (I’ve never done this before and I was completely set up in 4 hours). Still, I recommend doing some additional reading around each of the steps so you understand what you are doing – you don’t want to lose your mail or turn your box into a SPAM relay.

Set up Postfix

Postfix comes pre-installed on Mac OS X, so all I needed to do here was configure it. I needed 2 things – to change it to use Maildir (IMAP won’t allow subfolders if you are using mbox), and to get it to listen on localhost port 25 so I could relay mail from localhost (not strictly necessary, but I use that so that it is easier to work with the defaults for javamail, for example).

So, editing /etc/postfix/main.cf, I add:

# This is required to get postfix to start up
myhostname = localhost.localdomain
# Use maildir instead of mbox
home_mailbox = Maildir/

You’ll also want to set relayhost if you are going to relay your mail, and be sure to configure the networks to keep that to only come from your machine or network.

Seeing it arrived in my maildir, I used mail to read it in the terminal.

Set up Dovecot

Dovecot needs to be installed, and unfortunately isn’t in fink, so I used the DarwinPorts version. It’s one release behind at the moment, but I already had it installed before I realised that so I’m sticking with it for now. With DarwinPorts installed, I ran:

sudo port install dovecot

The configuration goes pretty much as the docs say. I created /opt/local/etc/dovecot/dovecot.conf from the example in the same directory and added these options:

I tried to disable SSL support since I’d only be running this locally, but that dies with a Signal 10 on RC6 from DarwinPorts, so I turned it back on and generated a fake certificate. I copied the dovecot-openssl.conf file from a source distribution I downloaded as I couldn’t find one from the DarwinPorts version. That was used to generate the certificate using mkcert.sh from the same source distribution.

For the PAM settings, I followed those here, but none of the other steps were necessary – DarwinPorts already created the dovecot user and launchd script that just needed to be activated . Instructions for that appear during the installation, but at a later date it can be started using launchctl:

So, now that I had dovecot running, I opened up Apple Mail, added an account for it, and checked that my earlier test mail was there. I sent another one for good measure to see it was picked up.

Set up Fetchmail

Update 3/9/06: I removed the fink installation instructions here since the version in there was waaaay out of date. Instead, get fetchmail from BerliOS and follow the normal configure/make/make install steps (also listed in the article below). I’ve updated the launchd configuration below to use /usr/local/bin instead of fink’s /sw/bin.

These instructions are useful for setting it up. I started out with the keep option turned on, but other than that my config was the same. (Update 23/8/06: I’ve since removed the StartupItems entry for FetchMail so that isn’t needed from this guide. See below.)

I turned these all on, tested, and once confirmed it was working, rebooted and it all came up. So now I get to POP my mail regularly, and can read it from both Thunderbird and Apple Mail using IMAP. Next adventures will be moving the existing mail there, and backing it all up!

That’s it! Thanks to John, Jesse and Jason for putting up with my questions on various aspects. I was being extra paranoid, but this ended up working very nicely.

Update 23/8/06: I discovered that under the above set up that fetchmail would stop running whenever I put the macbook to sleep and I’d need to kick it again when I opened it back up. To correct that, I removed the StartupItems entry for FetchMail created above, and created a launchd item instead. This is /Library/LaunchDaemons/de.berlios.fetchmail.FetchMail.plist:

Book

Coverage of intermediate Apache Maven concepts with a focus on best practices and "tying it all together". Significant coverage of automated build and repository management concepts, illustrated using Apache Continuum and Apache Archiva.