#mx.bitfehler.net infrastructure

This repository contains the full code (minus the secrets) used to deploy mx.bitfehler.net, the mail server for bitfehler.net.

All aspects of the systems are described in code in the form of a makeimg IMGBUILD. Anemos is used for deployment. Besides the obvious utility of this repository its main purpose is to serve as a demo for these projects.

Note that this server has a second disk containing the /home folder, which is not touched during deploy. Hence, some files referenced in the IMGBUILD might not be part of it, as they simply remain in place across deploys (they are, however, backed up separately).

#How it is being used

The server is redeployed by running make deploy. This assumes it is already running the system as described in this repo.

#How it works

In rough terms, this is what happens:

• makeimg is used to reveal all used secrets - these secrets are only accessible on my laptop and need to be shipped somehow.
• A tarball is prepared containing the entire IMGBUILD (i.e. the IMGBUILD file plus additional input files) and the secrets
• The tarball is sent to the server
• Anemos is executed on the server

The execution of Anemos will lead to the following events:

• Anemos prepares a special initramfs, based on the Anemos base image but including the prepared tarball (the "payload" in Anemos terms)
• Anemos boots the server into the prepared initramfs (via kexec)
• The initramfs executes makeimg, bootstrapping a system exactly as described in the IMGBUILD
• The server is rebooted, now booting into the newly deployed system

#What is notable about this?

#Entire system defined in code

The system description includes low-level details like disk partitioning, file systems, and boot loader setup. These things can be changed because the deploy is performed by an initramfs.

#Secrets

In this case, the secrets are resolved on the workstation triggering the deploy and then transferred to the server with the IMGBUILD. In larger environments that feature network-based secrets management systems, this step could be performed on the host itself.

#Network usage

A deployment requires relatively little bandwidth for the client triggering it. Only the IMGBUILD definition has to transferred to the server. All the packages are then pulled from the server, which presumably has a decent connection.

#Shit can blow up

It might be obvious, but still worth pointing out: this method of deployment provides ample opportunity to render a system unbootable. You should not attempt this on systems unless you have some means to restore an unbootable system, e.g. physical access, recovery systems, or vendor-supplied remote re-imaging.