§Writing
Scientific method: My thesis is that the DNS is the root of the Internet. That is, every network request starts off with a DNS resolution. The DNS is in a great position to manage resources in the Network, like certificates, keys, services, etc. But for some reason people don’t do this now.
One advantage Eon has over the state-of-the-art dynamic DNS updates for the ACME DNS challenge is the principle of least privilege. We can provide a capability to only a subdomain, with the thread model a rough service or machine.
Regarding scenario 5, the DNS is a very small key value store. “The DNS is a general (if somewhat limited) hierarchical database, and can store almost any kind of data, for almost any purpose,” RFC2181. We can keep track of what values are being used. Like GitHub s SSH keys, and Tailscale’s key expiry. These could be SSH keys for machines with SSHFP. DNSSEC would be nice for this. A UI into this might be appropriate, possibly authenticated with something like webauthn.io
Additional scenarios:
- Self-healing OS.
Setting up and configuring machines is a time and labour-intensive process. Installing the operating system, networking the machine, updating software, never mind deploying services. Instead, we could deploy a machine just with a capability to access a name service, which could register itself and boot whatever services are configured. It could manage its own upgrades, resources including disk space, etc.
- Bridging domains.
TBD…
§Reading
I was looking at the godot engine as an open source alternative to unity for mixed reality development and came across github.com/Nitwel/Immersive-Home.
On the topic of a self-healing OS, one gripe I’ve had with NixOS since I started using it is that it doesn’t support mutable runtime state. It turns out there’s a masters thesis exploring this exact topic denbreejen.net/web/thesis.pdf. Some of these ideas could be useful for a self-healing OS. I could imagine a modern solution using container technologies like Linux namespaces to achieve this.
§Managing state in a purely functional deployment model
The purely functional deployment model doesn’t extend to mutable system state such as databases and log files. Managing state out-of-band hinders the reproducibility of deployments. For example, when migrating a component users are required to migrate the state separately, there’s no mechanism to specify multiple instances of a component that use different instances of state, rolling back software versions may be incompatible with state, and similarly upgrading software often requires a state transformation. The versioning file system Ext3cow is used to store multiple instances of state. This seems similar to ZFS snapshotting.
They treat state as analogous to values in a purely functional language. Executions of components are transformations of state
execute_component :: Component -> State -> StateState
is stored in a state store /nix/state. This is extending
Nix to be more active in the runtime.
As far as I can tell this hasn’t seen real-world adoption. Perhaps as it constrains the deployment unduly (requiring specific file system).
§Hacking
I need to modify the NixOS ACME config that uses the lego bot to instead use Eon to provision certificates for my own VPS as well as Eon.
The way the existing configuration works is that a systemd services is created for every certificate to handle renewals, and webserver services are set up to restart on a new certificate being provisioned.
The simplest solution seems like modifying the systemd service to invoke a small client to provision a certificate. We can get the capability for a domain from a file protected with file permissions (e.g. allow the nginx group access). This is similar access control to a Unix domain socket, but we’re separating access control and network connectivity, so a service could be running on another machine and still use this capability.
We’re inverting the renewal logic here. Currently, systemd triggers timers for renewal scripts, but Eon can handle certificate renewals with callbacks. We’ll need a mechanism to restart the webserver when certificates are renewed. We could probably accomplish this for systemd with paths to the cert files. Or just having the client exit on renewal, triggering a restart of the systemd unit, and restarting the client with the same renewal callback.
We’re only talking about restarting the webserver as it looks like every HTTP service (matrix, mastodon, etc) is expected to run behind a reverse proxy which handles things like TLS. (With SVCB records specifying a port, maybe this is unnecessary.)
I don’t think this is not fulfilling the full capability of this approach, but is a worthwhile MVP to use it in deployment. For dynamically created services, a small wrapper executable to provision certs and restart on renewal seems appropriate. This is more like docker compose.
I’m in the middle of hacking in Nix to get this working.
§polyglot package management
David was very keen on the project proposal as it mirrored a lot of what he’d been thinking about from the Opam for Windows perspective. The reasons why he thinks Nix isn’t sufficient by itself are:
- Platform support
- Version solving
- A lack of ‘just works’ tooling
- He’s suspicious of monolithic build system approaches to package management (e.g. bazel) as they just recreate the world in their own format, and as package management is orthogonal to build systems.
We talked a lot about his own ideas for Opam (a lot of it in the context of windows). He talked about dynamically generating opam files from what is available via the system package manager, and feeding that back to the solver. It’s really useful stuff to know, but he said it shouldn’t affect the deliverables for this proposal.
We talked about the limitations of trying to build a universal package manager to invoke others, and how a common format could work (though this ‘holy grail’ is a bit of a pipe dream at the moment). We also talked about Dune’s upcoming package management functionality.
He’s really keen on the dream2nix proposal 2 for supporting the Opam solver. But the thought proposal 1 a Nix backend for Opam depexts was the lower hanging fruit to be getting on with in the first instance. This is essentially indexing Nixpkgs for versions of packages, and solving for the correct version with the opam solver.
He said that the best way to support this might be an Opam plugin. Though it might require changes to the depext logic e.g. for sandboxing and environement variables. The depopts field of the opam file might be the place to specify this, as conf packages don’t really support versions like we do.
The
nix-shell -p <package> command makes available
binaries in the $PATH variable. I need to think about the best way to
make this available to the Opam sandbox.
David said setenv might be what we need. The command also makes available libraries in various language specific environment variables, like $NIX_LDFLAGS (for the C compiler wrapper) and $PYTHONPATH for Python. I need to think about if and how these could be supported for shared libraries.
The next task is probably modifying https://github.com/lazamar/nix-package-versions to index Nixpkgs in our Opam repo.