I develop the Salt scripts against a local VM. Once it is time to deploy remotely the process is as follows:
- Start up the VM with provider of choice (I use and recommend Bytemark)
- Log in via SSH
- Add the appropriate Saltstack Package Repoisitory
apt-get install salt-minion
- Configure the SaltStack Minion to run masterless: edit
/etc/salt/minion and ensure that
file_client: local is set.
- Tar up the SaltStack configuration files you’ve created,
scp them across to the server, and
tar xzf them out into
salt-call --local state.apply
- Now wait a bit. Hopefully there won’t be any errors.
systemctl restart exim4
A couple of basic security utilities: fail2ban and logcheck.
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.
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.
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.