But since my customers needed to be able to read and reply to emails while the primary site was down, I couldn’t just let the backup system keep the incoming email in the queue and deliver them once the primary sit was up. I decided to deliver the emails locally but also keep a copy of all emails that passed through the system.

These archived emails were to be re-delivered once the primary site was up again, and here’s how I did it, step by step.

• Set up a VPS for the backup MX host.
• Set up the system using the same guide I used for the primary site, which was the great ISPmail tutorial by Christoph Haas.
• Added the option always_bcc to the Postfix config, pointing it to a new local mailbox.
• Once the primary server was up again, I set up getmail like this:

  • [retriever]
    type = SimplePOP3Retriever
    server = hostname_of_backup_mx
    username = username_of_backup_account
    password = secret

    [destination]
    type = MDA_external
    arguments = ("-i", "-bm", "-t")

    [options]
    verbose = 2

Running getmailrc quickly restored all the emails on the primary host. Remember not to run it multiple times since the default is to re-download already processed messages.

The downsides of this setup:

• Deleted emails (like spam) are seen again by the users. POP users will receive duplicates of already retrieved messages. IMAP users will however have a mailbox which includes both old messages and the ones delivered to the backup server.
• The spam filter wasn’t used in delivery process. I realize this could be achieved with fetchmail (which includes the SMTP delivery option that getmail lacks) but I decided to use getmail anyway.

I realize there might be prettier solutions to the original problem (BOTH delivering emails locally and keeping them in a queue for a primary MX), but I couldn’t find out how and this proved to be a pretty solid solution. Feel free to suggest better ways to solve the problem!

• Try using the “Manage my network passwords” window (accessed through the “User accounts” applet in the control panel)
• If that didn’t help:

• Make sure to enter the server name in the username box, example: MACHINE\username
• Try entering the IP address of the server instead of the host name (worked for me when everything else failed).

I moved all files from the inbox to a temporary directory and started moving the back a few at a time, to isolate which emails that caused the problem. After about an hour of investigation, I noticed that there were a few duplicates with the same size and almost the same name. The only thing that differed was the Maildir “flags” after the comma.

The reason was probably that the user was viewing his mailbox while the backup was being restored, causing some files to be renamed and thus creating duplicates. The IMAP server (Courier in this case) was apparently confused by multiple files with the same timestamp but with different flags, and dropped the connection to SquirrelMail.

To isolate the duplicates, I used ls -1 and cut:
/bin/ls -1|cut -d "," -f 1|uniq -c|sort -n

Then I removed the duplicates, which were the files with file count > 2 in the list produced by ls.

When I investigated the originating IP:s, I noticed that all spam except ONE came from one of four C-nets. I quickly decided to block in the .htaccess file in the weblog directory.

Here’s what I added.

# DIE, SPAMBOTS, DIE!

I’m willing to take the very small risk that a valid user from one of these IP:s won’t be allowed to enter my weblog.

(Yes, I know that I could install a WordPress plugin, but this was quicker and less cumbersome. )

Just today, I found a program that makes things a LOT easier: StreamSniff. Just start it, and it will start sniffing net traffic for stream URLs…

It’s available for both Windows and Linux, and worked right away on my Linux firewall. Highly recommended if you like to save internet streams to disk for later converting/viewing.

NetTransport is handy for these tasks if you’re running Windows, the Linux alternative is Mplayer using the -dumpstream option.

Installing from a temporarily connected CDROM drive worked (no internal optical drive in the DL140, just space for a slimline drive), but after I removed the drive and rebooted I got a “kernel panic” message. Seems like Grub didn’t enumerate the drives in the same way as when the CDROM was connected.

A known problem with the Debian installer also made installing from CD difficult – the CDROM drive and the SATA disc became mutually exclusive! The solution was NOT to load the ata_piix and piix modules until needed.

My next approach was PXE booting (installing from the network without physical install media) the machine. The easiest way to get that running was ironically to use a Windows-based TFTP server (tftpd32) and then configure the DHCP server (dnsmasq). Booting off PXE worked, but the install image didn’t seem to contain the required SATA drivers, so the installer never found the SATA drive.

I managed to do a successful install using kernel 2.4.27 instead of 2.6.8, but upgrading the kernel to 2.6.8 after installing made the system unbootable again (kernel panic). I wasn’t satisified with using 2.4 and decided to try another way that didn’t require a time-consuming (well, for me anyway!) manual kernel recompilation…

The final solution was to create a bootable USB stick with Debian installer on it and install from it… Using “expert26″ I disabled the piix modules and voilá – the installer found my SATA drive!

First, a warning. Be careful when using Norton Ghost (in my case version 2003) on a HP machine – there’s a known problem with that combination.

In my case, I ran Ghost and chose to clone the drive. When the computer booted into the Ghost interface, it locked up and displayed an error message saying “internal stack overflow”. After retrying this a few times (same results) and trying to boot back into Windows (didn’t work since Ghost had taken over the boot sector) I booted Knoppix so I could look for assistance on the web.

(Thank god for Knoppix, BTW… I was able to access my files and documents on the disk, access the net and use email just as usual. It only took a quick configuration of Thunderbird to get myself back on track.)

Further attempts to clone the drive from within Knoppix failed – PartEd crashed when I selected the drive and both PartImage and NTFSclone gave up midway due to disk errors.

Finally I managed to remove the small partition created by Ghost and make the old Windows partition active again, and Windows on the faulty drive booted again. Well, after a few lockups during boottime anyway.

Now it was time for another try at cloning the drive… I decided to give Acronis True Image a try, and it worked beautifully.

So the lesson is – don’t use Ghost unless you’re sure it’s compatible with your hardware, because it can really screw up your computer…

Some hints:

Knoppix found the USB disk without any problems, but sharing the drive required a few more steps.

Finally I found a page with some helpful tips: