wllm

After some software wrangling, mail list diving, and good old-fashioned googling, I now have a more-or-less functional QmailToaster installation on my Fedora Core 4 server. I'll tell you about the problems I had and how I solved them, then make a half-assed attempt to generalize the experience in to a statement about Linux and FLOSS in general. Let me first warn you, however, that I'm no hard-core sysadmin or technology obscurist. I'm just a guy who likes to run his own server and believes software should not only be free to all, but usable by all- including those of us who don't happen to be software experts and/or geniuses. If you'd like to follow along at home, see these instructions (Nevermind references to CentOS, I just replaced all "cnt40" strings in the instructions with "fdr40". CentOS seems to be the test distro for QmailToaster, and they provide the same instructions for all other distros). So, with that in mind, here we go. . .

Step 1: Skipped. I already have an installed and configured server.

Step 2: Skipped. "

Step 3: Skipped. "

Step 4: Done. That wasn't so hard.

Step 5: Done, but lost a few hours. It had nothing to do with QmailToaster, however. My dedicated server didn't come back up after updating all packages. It seems the new kernel didn't recognize my ethernet card. I called tech support and had them change the default kernel to the old one (they are saved on a yum update) and reboot. Old kernel seems to work fine, so I'm leaving it in this state until I upgrade to FC5 or 6. Well, maybe it did have a little to do with QmailToaster- "yum -y update" can update a whole lot of software on your box, as it did mine. I still don't see why this is really necessary as long as QmailToaster dependencies are in place. Maybe it is assuming a newly installed OS without too much time investment.

Step 6: Done. Went off without a hitch.

Step 7: Done, but took some doing. First off, all packages need compiling. The FAQ mentions that this is to meet the licensing requirements of D. J. Bernstein (author of qmail and many other useful pieces of software, hereafter referred to as djb). I found this odd, because qmail has no licensing requirements; djb is a strong proponent of License-free software, as he has published on his site. So, I understand that while the distribution of compiled software isn't directly addressed in djb's explanation of software law, he has publicly and specifically mentioned that he doesn't want qmail- or any of his other software- distributed as binaries. OK, but where is it written or implied that any software that depends on qmail must be distributed as source? I'd love a sensible explanation, please comment if you have one.
I ran in to a few issues while compiling. Some of them were a little hard to spot, since the failure had occurred earlier in the fdr40-install-script.sh script and showed up as more obvious failed dependencies later. A diligent sysadmin would have read every line of the script output; alas I'm no diligent sysadmin. It might make sense for the scripts to detect ANY errors on execution and put them front and center as a continue, abort, retry prompt. The only non-trivial issue that I had to go to the mailing lists for was a failed dependency on the libtools-ltdl and libtools-ltdl-devel packages, as explained here. If they haven't been put back in to the fdr40-deps.sh script already, please, O QmailToaster gods, get to this soon as it is an entirely avoidable waste of time. Maybe I'll take a look around to see if I can do this myself. . .
After running the scripts several times, skipping all previously compiled/installed packages, I finally got every package in place.

Step 8: I don't need bind, and this seemed to be a simpler solution (and better explained in step 10), so I installed djbdns. No problems to speak of.

Step 9: Here's where I spent some time. "qmailctl stat" looked fine. I added a domain and a user via the vpopmail shell commands. I logged in to www.wllm.com/admin-toaster/ (with unmodified rewrite rules from QmailToaster, the trailing '/' is required). I got some relatively innocuous php errors, many of which I cleared up by substituting "'r'" for "r" and "'w'" for "w". I'd assume this has something to do with differing versions of php; I intend to clear up the remaining errors later. I set the admin password without a problem. www.wllm.com/webmail came up, and I could log in with the user I just created. Sent myself an email. Fine. Sent a mail to my gmail account. Fine. Replied from my gmail account. Not fine. Looking in the smtp log at /var/log/qmail/smtp/current I only found a "connect(): Connection refused" error. My server was soft bouncing all incoming remote mails with a (#4.0.3) code. This proved to be a bugger to figure out, since I couldn't find any leads on the qmail or QmailToaster mailing lists. I found a red herring in the /var/log/qmail/send/current log: a (#4.2.1) code error. But then I noticed that this only showed up for addresses that I hadn't yet created a vpopmail account for. After trying a bunch of things, including tweaking the firewall, changing the nameserver config, and playing with the /etc/hosts file, I finally got it to deliver remote mail when I resorted to turning off clamav in /var/qmail/control/simcontrol and running simscanmk. It seems that clamav was returning an error, but I didn't see anything about it in the logs beyond the cryptic "connect(): Connection refused" line. I suppose I was lucky that I tried this relatively early in the troubleshooting process. I still haven't fixed clamav, but I can get by without it until I have a little free time.

Step 10: Followed all instructions, but http://domainkeys.sourceforge.net/policycheck.html could not find any domain key for wllm.com. I figured that maybe- just maybe- this was a dns propagation issue, but alas, it didn't work 10 minutes ago after I had waited for a few days. I'll troubleshoot this later.

Step 11: Not really a step. It might make sense to mention this in Step 9, however, since that's where I needed this info. Didn't really hold me up.

So that's where I've left it: a mostly working QmailToaster install in about 8 short hours. Don't get me wrong, I really appreciate what the QmailToaster team has done here. And I'm quite sure setting up a similar system from scratch would have taken much longer. But it does say something about the usability, installability(?), and configurability of some open source software. I realize that this is server software that not everyone would be interested in installing and maintaining, but it is interesting that even with the dedication of a team of very smart developers, an integrated mail system still takes next-to-expert-level skill to install correctly if there are any problems. Granted, a binary based distribution that could end up in yum repositories might ease some of the pain (PostfixToaster, anyone?), but it seems to me that there is far too much effort put in to making Linux usable. It simply won't scale with the complexity and number of packages. Linux distributions might learn some lessons from other open source software: convention above configuration, standards can be very good things, and the performance/complexity tradeoff is very real and relevant to all software. After all, it should be the software serving us. ;)