guix httpd

The functional infrastructure-as-code nature of a guix system configuration are attractive (rollback, immutable match to spec). Building it is hard.

Employing secrets (like a ssh host key) contort setup and the error, edit, rerun debug cycle is slow with extra steps. Given the stronger read-evaluate-print loop heritage of lisp/scheme, slower iterations is a bit ironic.

We have an old pet (vs cattle) redhat box hosting a large RAID and VMs ostensibly managed by an outside vendor with DIY ip tables for routing. The OS we're running is what we're stuck with for now.

The distro packages are out of date, and it's too old for modern containers. GUIX foreign distro packaging is a good fit, but running services (httpd) with guix packages a la guix shell in systemd could be problematic¹. A VM seems like a good fit: extra isolation from an old vulnerable OS.

It took a while to get a system configuration that would parse, largely due to it being new-to-me. I can appreciate the elegance of the configuring in scheme, despite doing so adding another not-necessarily-fully-specified layer between what's defined and where it's interpreted.

I run the VM like ^{2 3}

$(guix system vm http-system.scm \
   --no-graphic \
   --share="$static=$static")

For common settings, service configuration can be defined with records like (server-name "myserversname"), but not all possible settings have guile defined records. For where service configuration are incomplete wrapers, there are escape hatches in generic wrappers like extra-config (httpd), extra-content (sshd) or directly using (plain-file) or (file-local) ⁴. Notably, all of these put the final configuration file into /gnu/store which might be a problem if the file should include a secret.

vim /etc/httpd/httpd.conf
httpd -X -f /etc/httpd/httpd.conf

grep "$recent_change" /gnu/store/*httpd.conf # find config

$(guix system vm http-system.scm)                # run VM
cp $httpconf_from_above httpd.conf               # get writable file
# edit debug rerun
  httpd -X -f /etc/httpd/httpd.conf              # get errors
  vim /etc/httpd/httpd.conf                      # try to fix
shutdown                                         # leave VM

vim http-system.scm                              # port changse to guile
guix system vm http-system.scm                   # generate config
# try again

guix repl --listen=unix:/tmp/guile-guix
M-x geiser-connect-local /tmp/guile-guix

Secrets with in reproducible definitions push at the boundary; --expose is the escape hatch. Providing a secure shell daemon is a good illustration.

Were this not a reproducible/functional build, ssh-keygen -A once in the VM would be sufficient. guix even defaults to running ssh-keygen -A for every provision. But the changing host keys defeat the point: we'll blindly accept any connection with no good way to confirm the new key is correct.

-oStrictHostCheck=no is a nice hack for development, but not sufficient for production. I got to a fix in a round about way:

Including the necessary files with (file-local) would reveal the host key secret in /gnu/store. Biding a file like --expose=/path/to/key=/etc/ssh/host_..._key might work for a container but not for a VM using 9p mount – expose must be a directory. gnu/services/ssh.scm provides a (extra-content) record and man sshd_config documents the HostKey option. For me, this took many guix system vm, ssh -v, shutdown cycles to get working.