So, I’ve been making a couple of servers publicly accessible so as to allow some services outside the firewall. The main things I’m aiming to have available are git and mediawiki, which in turn means making SSH and Apache services available.
I have a virtual server that is my main gateway, and I have a smoothwall that sits at the perimeter. I’ve been through a bunch of different sites and looked at lots of documentation, this post just points to a few of them in case someone else is following the same path.
I’ve been using Rdiff-backup to take an incremental backup every 15 minutes of the directory I store code in. Logic being that I occasionally decide to do some refactoring that I probably shouldn’t have, and if I’m not disciplined with using git then I don’t have a save point. I suspect I don’t really need this, but it’s been running.
Recently it started giving an error along the lines of :Exception ‘[Errno 22] Invalid argument: ‘/home/backups/development-apps/apps/tmp/rdiff-backup.tmp.479” raised of class ‘<type ‘exceptions.OSError’>’
I’ve chosen to set up my development environment with two servers – a mysql central server, and an app server on which rails runs. This reflects my eventual intent – that the production system will have the mysql database separate from the app server, I’m figuring it’s easier to work that way. I spend a lot of time ssh’ing between these servers, and a bunch of tools such as scp and git run over top of ssh.
My aim in this post is to configure for a bit more security – I’m setting up so that you use public keys to logon rather than providing a password. This is easier/quicker to log on, but actually more secure than using a password.
As I’ve noted earlier, there is code available and in kernel 3.9 that provides for native RAID5 and 6 on btrfs. I have some spare time this weekend, I’m going to compile a new kernel on a virtual machine, and have a play. This post contains instructions for anyone who might want to do the same.
This is the last part of the tutorial on installing a mail server, refer the overview, or hit the tutorials menu at the top, and look at the mail server tutorial category.
In this section, I explain how to configure spam filtering using spam assassin, and how to configure fetchmail to go and get your mail from an existing POP3 isp mail account.
I use fetchmail in this way to avoid making my mail server the primary delivery location for my domain mail. If I was a bit more confident in the uptime of my ISP and my servers I could just have my mail all come directly to my mail server, but for now I’m choosing to have it delivered to my ISP (who are pretty much always there) rather than have it bounce when my server isn’t there.
This tutorial assumes you’ve completed parts two, three and four, so you have a virtualised mail server that has Exim running on it to deliver mail into a mail box that is in Maildir format in /home/<user>, and dovecot serving that mail as an imap server. So, let’s get on with the install.
This is the fourth part of the tutorial on installing a mail server, refer the overview, or hit the tutorials menu at the top, and look at the mail server tutorial category.
In this section I explain how to install Dovecot to expose your mail directory to your various client applications (iPhones, iPads, laptops and PCs), and have that mail kept in synch across all those devices. To do this, we use Dovecot as an IMAP server, IMAP being a protocol that allows mail clients to add folders, move around mail messages and do the usual mail stuff, all working against a shared server mailbox.
This tutorial assumes you’ve completed parts two and three, so you have a virtualised mail server that has Exim running on it to deliver mail into a mail box that is in Maildir format in /home/<user>. So, let’s get on with installing dovecot.
In this post I’m talking a bit about virtualisation and the disk caching options, how I interpret what they’re doing, and why I’m choosing the settings that I am.
This discussion is really only applicable in a world where your storage is direct attached to your host, usually as SATA disk. If you’re using network attached storage (NAS) or a full-fat SAN environment, then you’d typically attach the storage directly to the virtual machine, and therefore the host is unlikely to be providing any caching for you.