I develop the Salt scripts against a local VM. Once it is time to deploy remotely the process is as follows:

1. Start up the VM with provider of choice (I use and recommend Bytemark)
2. Log in via SSH
3. Add the appropriate Saltstack Package Repoisitory
4. apt-get update
5. apt-get upgrade
6. apt-get install salt-minion
7. Configure the SaltStack Minion to run masterless: edit /etc/salt/minion and ensure that file_client: local is set.
8. Tar up the SaltStack configuration files you’ve created, scp them across to the server, and tar xzf them out into /srv/salt/
9. salt-call --local state.apply
10. Now wait a bit. Hopefully there won’t be any errors.
11. /usr/sbin/update-exim4.conf
12. systemctl restart exim4

A couple of basic security utilities: fail2ban and logcheck.

srv/salt/fail2ban.sls

Fail2ban scans the SSHD log files looking for failed login attempts. After a few attempts from one IP address it adds a firewall rule to block that IP address from further connections. Given that any SSHD exposed to the Internet will receive a continuous stream of connection attempts within seconds of going online, protection of this kind is very necessary.

My user accounts are system accounts too. This probably isn’t the best way to do it but it has the merit of simplicity. There aren’t many users on this system so managing users this way is easy. More users would need a different management system

I’m going to install a couple of services – SMTP (exim) and IMAP (dovecot) – and I want to share the SSL key and certificate between them. Having separate certificates for each is additional hassle when it comes to updating them.

Thus I’ve got a sslcerts.sls file to manage the certificate installation which I can share between exim.sls and dovecot.sls.

I use Dovecot as my IMAP/IMAPS server – it has always worked very reliably for me.

srv/salt/dovecot.sls

First, this file needs to include sslcerts.sls to make sure that the certificates are installed. Dovecot starts as root so it doesn’t need any special groups to get access to the key.

Once the packages are installed there is a bit of configuration to set up:

• Configure the system to use Maildir format;
• Get rid of any configuration to use mbox format;
• Ensure that SSL is turned on and that the ssl_cert and ssl_key values are set correctly;
• Ensure that SSL isn’t turned off.

It isn’t really possible to run an email server without a spam filter these days – there is just too much spam. Spam Assassin does the job very well, even with just its default configuration. Once exim is configured to use it, configuration of Spam Assassin itself is easy.

srv/salt/exim.sls

This YAML file is responsible for installing and configuring exim. First thing is to install SASL to handle authentication – exim needs access to the passwords and SASL is one of the standard ways to do this.

As discussed previously I’ve chosen to install the SSL certificates centrally in /etc/ssl; I’ve set up a group ssl-cert to allow access to these. Exim also needs to run under the sasl group to get access to the authentication daemon.

Debian uses a complex configuration system for exim. This makes it easy to configure with Saltstack – we can just add our configuration to the default and Debian will put it all together for us. However it must be noted that there appears to be a bug in Saltstack at present – it should be able to tell Debian to update the configuration when a file changes but at present I’m getting infinite recursion so that bit is commented out for now.

This is basic server configuration – making sure that the time on the server is set by NTP otherwise lots of weird things happen.

ntp.sls

# Install NTP to keep the time correct
ntp:
  pkg:
    - installed