One option to get fitter, reduce car costs and reduce carbon emissions is to:
- Drive myself and the kids to school in the car;
- Get bike out of the car boot and cycle home;
- Cycle back in at pick up time, dismantle bike and put it back in the boot of the car;
- Get kids and drive back in the car.
I discovered that a bike my dad bought me for school will fit in the boot of the car with its wheels off. It is a nice bike – great fun to ride. However the freewheel was free in both directions and the paint was coming off, leading to rust.
First stage was to strip off the old paint. I was going to get the frame shot-blasted and powder coated. However I couldn’t find anyone locally to do this – most calls went unreturned – and I didn’t want to put the frame in the post due to the risk of damage. For this bike I don’t really care what it looks like – the paint needs to stop rust and if it looks rough it is less likely to get stolen.
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.
This is basic server configuration – making sure that the time on the server is set by NTP otherwise lots of weird things happen.
# Install NTP to keep the time correct
The first thing we need to do is ensure that SaltStack itself is configured for masterless mode. We need to ensure that the minion isn’t running as a daemon:
# Turn off the salt minion daemon as we're running masterless
- enable: False