Configuration management
──────────────────────────────────────────────────────────────────────

Automation.

This is a fairly vast topic, so let's start from the beginning.

# Principles

The first thing to do after setting up a server is configuring it,
and then the services that it will run.

This includes the following:

- Nameservers
- Installed packages
- Running services
- Service configurations
- …

Performing these configurations (in their simplest form) means creating
files on the server, and running specific commands.

Many tools are available to automate this process:

- [ansible][0]
- [puppet][1]
- [chef][2]
- …

Each of them have their own strengths, and a declarative language used
to describe the server state.  
All of them need you to learn a new DSL, and a new language to perform
the task you would expect.

There has to be a simpler way.

As a sysadmin, and long-time Linux and BSD user, the language I'm the
most familiar with is the shell.
And as you certainly guessed, there is a tool for that !

# drist(1)

By relying only on ssh(1) and rsync(1), [drist][3] is the simplest
configuration management tool I know of.

It works in a centralized fashion. You first create a module on the
deployment machine:

	gopherhole/
	├── files/var/gopher/index.gph
	└── script

The script file may contain whatever is needed to configure the service:

	#!/bin/sh
	pkg_add geomyidae
	rcctl enable geomyidae
	rcctl start geomyidae

Then you apply the module on your server with:

	cd webserver
	drist -ps root@server.tld

Everything in `files` will be uploaded on the server "as-is". Once all
files are deployed, the `script` file will be uploaded, executed over
ssh(1), and then deleted.

All you need is an ssh connection to your server!

Per-server configuration files can be uploaded by naming the `files`
directory as `files-FQDN`. These files will then be uploaded only to
the server who's FQDN match the directory name.

# Rationale

I love simple tools.

Over the years, I got to use both chef and puppet in entreprise-grade
environments.  
They work well for environments with thousands of servers,
and their greatest advantage is that they provide a client/server
configuration. Thus, centralization is built-in and makes it great to
work in a team.

Over the years I built a few servers to host various services, like
emails, httpd, gopher, git, … Whatever.
Setting up these servers is fun, but at some point I lost track of
everything I did. At first I wanted to document it all, but documentation
is doomed to lack behind at some point, so I figured the best way to
"document" it would be to automate the whole configuration, so replicating
it would only be a matter of commands I can easily read, and run again
when needed.

This is where drist(1) comes into play. By being a shell-first citizen,
and simply being a local mirror for your configuration files, it becomes
fairly easy to understand what it does.

In the past few monthes, I'm slowly been migrating all my server
configuration to drist, and ensuring that I could apply any module at
any time without breaking anything. Some notable modules I made are

- gopherhole - publish notes in my gopher hole
- acme - check/update let's encrypt certificates
- ssh_keys - deploy my SSH keys
- syspatch - path/upgrade OpenBSD servers

Configurations have never been so quick & easy !

[0]: https://ansible.com
[1]: https://puppet.com
[2]: https://chef.io
[3]: gopher://dataswamp.org/0/~solene/article-drist-intro.txt

20200824.1132