Comment by darklajid | Hacker News Reader

Comment by darklajid | Hacker News Reader

This looks like _a lot_ of work was put into the article.

Nevertheless, I think you shouldn't do this. This takes a lot of time and is basically copy/pasting things around. For something as crucial as your own mail server I'd go with a solution that is automated: If your server goes away you fire up a different one in a couple of minutes, restore backups and change DNS records, done.

Reasons for this might be, in no particular order:

- VPS provider goes away

- hardware failure

- user error (think "Oh, I probably shouldn't have issued that command as root on my mailserver")

- maintenance: This guide is (initially) from 2009. How are you making sure that your system is up to date, after you followed the instructions/installed it? Either you'll leave the system to bitrot or you need to actively maintain it and probably will run into issues upgrading the machine. Or .. you migrate to a brand new machine every 6-12 month, which gives you a decent excuse to verify that your backup/restore process is working as well.

> vps provider goes away

Backups. Your colo, cloud host, mail provider are equally likely to disappear.

> hardware failure

Unlikely to be a big issue unless you own your own kit and can't afford redundancy or replacement. Otherwise, it's a case of firing up another VM and restoring it as per any other computer.

> User error

Less likely to happen than on a hosted service from experience. I've seen massive data loss on a couple of big names.

> Maintenance

Seriously you just leave it. "apt-get upgrade". Perhaps some minor reconfiguration required between distro versions but I haven't had to do this in 5 years on Debian.

Also don't forget, bar gross misconfiguration, if your mail server goes away even for a couple of days, email usually makes its way to you eventually anyway. It's quite resilient.

As for backups, I always test restore at least once a month.

Is your reply bourne out of experience?

Mail hasn't changed much in more than a decade. Systems like Ubuntu update cleanly from release to release. Maildirs are very easily migratable.

You can literally set up a new mail host, and then rsync the old Maildir contents -- aka, all your user's e-mail -- onto your new host, whenever time permits, without disrupting mail delivery or reading. User's historic e-mail will simply gradually fill in.

If your VPS disappears, or hardware failure occurs, or user error strikes -- simply restore your Maildirs on a new system from your backups (tarsnap works great!).

This documentation is long and thorough, but once you know what you're doing, setting up a basic mail server, even manually, should only take you a few hours at the most.

That's why I use Virtualmin for this stuff.

1) It backs up every day to one of my own machines

2) If it goes down, I'll re-upload the backup file and my whole system (mail, web, DNS, MySQL, etc) is running again.

I actually wrote a script for Ubuntu server (works on 13.04) that encapsulates most of this tutorial. It doesn't include ClamAV or Spamassassin, but does everything else. You end up with a server that uses three mysql tables.

But then I discovered that Virtualmin does all of what this tutorial does, with an understandable u/i and all of the same capabilities from Dovecot/Postfix/saslauth. Doh!

"restore backups"

Never restore anything but user data. Best implementation is a herd of puppet modules and classes.

So your class mailserver { include shorewall ; include mysql-server ) and a whole bunch of other modules. That way you can leverage your efforts to have a class like database-server { include mysql-server } or whatever.

then you have node 'somevps.something.com' inherits mailserver {} or whatever other future/load balanced machines.

You can go from bare iron to in production in a couple minutes if done right. This makes troubleshooting easy, just bring up a test box during a coffee break and see what happens under identical conditions as production. And the other way around, never change anything in production until it worked on the test box, which only takes ten minutes...

My experience with postgrey has been utter failure in that 3rd parties too dumb to have a mail server that responds correctly to temp fails by retrying and instead give an insta-perma-bounce in response to a temp fail invariably are also too stupid to understand the problem is on their side. All they know is the mail server they installed in 1996, and never touched since, always gets bounces when they email you, therefore the problem must be on your side. And the global population of idiots will exceed any normal human level of patience. So, yeah, greylisting... bad, bad idea...

I've had the exact opposite experience. I've been using greylisting for almost a decade now. Greylisting is so common that people with broken mail servers is a non-issue. It is literally just exchange 2003 without any updates applied. That is a tiny number of servers, and they will generate bounce messages when trying to deliver to tons of domains, not just yours. Greylisting cuts down on a huge amount of spam with virtually no additional load on your server like content filtering does. So, yeah, greylisting... good, good idea...

> I've had the exact opposite experience.

Then you have not received any email from Comcast's email servers (or at least the few I've seen).

The one's I've seen retry three times to a temp fail in 1 second intervals, then bounce back to the recipient.

Considering that this can be installed to a VM, an image of which is backed up, what is not automated about this solution?

Maintenance: can't the distro package manager take care of that for me?

Sorry for the ignorance in my stance, but I came across this article because I'm looking to move away from Google infrastructure to hosting my own stuff, and this seemed like a great piece :)

VM Images not very portable, and have essentially no built-in documentation. They're also large if you're not working from a snapshot system.

Basically, if the exactly prescribed restore procedure fails, a sysadmin is stuck with a virtual black box of bytes and will have to divine out what sort of configuration mismatch there might be between the image and the new host. Different block devices? Different network devices? Wrong CPU architecture? Wrong virtualdisk format? Some other magic of some sort? It can be awhile before you even get the machine up and running, to say nothing about running services.

In contrast, a scripted install starts with a running, networked machine and if any point in the install procedure fails, you'll know what point it failed will have a detailed error message explaining why. You can read the script to see what it's trying to do and may be able to either correct the script for the new environment or correct the environment for the script. You can make steady progress towards restoration while if the VM restoration fails, you just keep slamming your head into the brick wall until it gives way.

It's true in many situations that restoring a virtual machine snapshot is much faster and easier than a rebuild and data-restore. My experience is that it's great when it works, but a nightmare when it doesn't.

I've been running a mix of http://james.apache.org/ and postfix for years. I've migrated 3 times with no issues over the years. (zip up database dump and distribution, done.)

Reply on news.ycombinator.com