server-iac

Terraform + Ansible for reproducing the setup of the mail/git/web server currently running as ubuntu-us-ord (Linode, us-ord), serving andrewgundersen.net and crimata.com.

This captures the parts of the box that are pure configuration. It does not capture secrets — see below.

Layout

terraform/ Provisions the Linode itself (size, region, image, networking) ansible/ Installs and configures software on a provisioned box

What's captured

• Base packages, unattended-upgrades, ufw firewall rules
• nginx site configs (as templates, parameterized by domain)
• dovecot config (system-user auth via PAM, mbox mail location, chasquid integration socket)
• chasquid config (dovecot auth, LMTP delivery, hostname)
• gitweb config (feature flags, highlight extension map, branding)
• certbot renewal hooks that sync certs into chasquid's cert store and restart dovecot/chasquid on renewal

What's deliberately NOT captured (secrets)

These can't be "replayed" from config — they're per-identity secrets that either need fresh generation per node or a separate secure transfer:

• TLS certificates (/etc/letsencrypt/) — regenerate fresh via certbot --nginx for whatever hostname the new node actually has. Don't try to copy these; a cert for one IP/hostname looks suspicious presented from another.
• DKIM private keys (/etc/chasquid/certs/<domain>/dkim_privkey.pem) — these DO need to match what's published in DNS, so unlike TLS certs they can't just be regenerated per node without also updating DNS. If this ever becomes a real multi-node setup, these need deliberate secure distribution (not this repo).
• Per-repo GitHub deploy keys (/var/www/.ssh/id_ed25519_*) — each mirrored git repo has its own SSH deploy key scoped to just that repo (see the [[dedicated SSH keys]] rationale — least privilege, so a compromised key only exposes one repo). These are generated per-setup, not shared.
• Mail data (/var/mail/*) — this is state, not config. Not in scope for IaC at all; needs its own backup story.
• System user passwords (andrew, me) — set manually per node.

Multi-region context

This repo exists because of a discussion about whether it'd ever make sense to run this setup in more than one region for durability. The honest breakdown of what that would actually require:

• git: already solved. Git is distributed by design; this is just more remotes and more post-receive hooks, same pattern already in use to mirror to GitHub.
• mail (dovecot): needs dovecot's built-in dsync replication feature. Not set up here — this repo only stands up a single node.
• mail (chasquid): not actually a sync problem — chasquid is stateless per-message once it hands off to dovecot via LMTP. The real requirement is routing (secondary MX / anycast), not new chasquid config.

None of that is implemented yet. This repo is step one: capture the single node's setup so it's reproducible, before deciding whether multi-node is actually worth the added complexity.

Client routing decision

For directing clients to the nearest node once there's more than one, decided on GeoDNS first, anycast later if needed:

• GeoDNS (e.g. Cloudflare/Route53 geo-routing policies): near-zero extra infrastructure — DNS just returns a different node's IP depending on the resolver's location. Failover is bounded by TTL (clients keep using a cached, possibly-dead IP until the record expires), not instant. A low TTL (~60s, most providers' practical floor) shrinks that window but doesn't eliminate it - DNS-based routing is fundamentally "wait until the client asks again," no matter how low the TTL goes.
• Anycast: the same IP announced from every node via BGP; the network itself routes each client to the topologically nearest one, with near-instant failover since it's not cache-bound at all. The real answer if "instant" (not just "fast") failover ever actually matters, but it's a different tier of operational complexity - normally means running your own ASN/BGP peering, or paying a provider (e.g. Cloudflare Spectrum) to do it for you.

Chose GeoDNS for now because it's proportionate to actual scale (one user, two mailboxes) - revisit anycast only if a real need for sub-TTL failover shows up, not preemptively.