§Eon
Some scenarios we could solve with a client-server API for Eon:
- We could keep track of the proliferation of federated services in an Eilean deployment including matrix, mastodon, and email.
Currently, we need to manually provision DNS
records like an A record at mastodon.example.org. We need
to run a certbot to respond to a ACME HTTP challenge by configuring a
path to serve by a webserver, or respond to a DNS challenge using
dynamic DNS UPDATES to update a nameserver. The HTTP challenge pretty
heavyweight and doesn’t work so well when e.g. load balancing accross a
webserver, and the DNS challenge typically requires providing access to
the whole domain. To demultiplex multiple HTTP services on the same
machine we typically use a reverse proxy which requires additional
configuration and is webserver-specific.
If we use Eon, services could register
themselves to the name server to provision DNS records, TLS
certificates, and reverse proxies. For example, when registering a
mastodon server we can provision an A record
mastodon.example.org. We can use the ACME DNS-01 challenge
to create the record required to generate an X.509 certificate at
_acme-challenge.mastodon.example.org. HTTP/3 and DNS SVCB
would allow UDP-only connections to be established without the need for
a TCP handshake. DNS SVCB records could also allow the use of different
ports for services, thereby removing the need to a reverse proxy to
demultiplex based on hostname. Perhaps there is some possibility of
using Eon to dynamically configure the HTTP proxy for HTTP/2
connections.
The only notable non-HTTP protocol is SMTP for a mailserver, and a TURN/STUN server for matrix VoIP calls. The mailserver requires DKIM, DMARC, SPIF DNS records for good practice.
A challenge that isn’t addressed here is managing the runtime state and secrets of these services.
Spatial naming. We could use eon to provision the network infrastructure (DNS records, certificates) required to spin up lightweight spatial services like matrix servers on a resouce-constrained computers like Raspberry Pis for communicaton in a spatial domian. This matrix server could be used for local communicaton with other building users (realtime or async), or communication with local spatial devices. The challenge with doing this with existing mechanisms is the relative labour-intensive process required to set up and configure them, which could be automated by Eon. Having a central orchestrator of this would allow us to keep track of which services are running on physical machines.
Sharing machines. Say I want to allow Patrick to get a shell into the Raspberry Pi controlling our lights at
capybara.fn06.org. The best way I would do this at the moment is register a Tailscale. It would be great if I could just share a capability for him to access this machine Many such devices are behind NATs and accessed via STUN servers, VPNs, or HTTP reverse proxies. We could dynamically configure this on a DNS request to the machine, and return the most appropriate mechanism for communication depending on connectivity (e.g. a link-local IP address, a VPN address, a NAT punched IP and port (with SVCB?), or bluetooth address?)Power management. Many machines for self-hosted services are idle for a vast amount of time, which has a big power drain over time. We could use Eon to power on a machine from full shutdown (via a networked socket or WoL) when a service hosted on it is queried on the DNS. Would require 0 TTL records and some knowledge of service idleness in order to shutdown.
Something something public key management?
§Eilean
Eilean is pretty much done as it related to static configuration. However, there is still a great deal of complexity to manage in the runtime of the services. Systemd is used as a service manager.
It would be good if we could manage the runtime services in a more inteligent way. I.e. have a policy that if we’re running out of disk space all but the highest priority services are paused writing. We could have services declared up-front what they need (e.g. a database, open ports, a reverse proxy) and figure out how we’re going to fulfill those requirements with different backends like sqlite or postgres.
NixOS modules do this to some degree but don’t really abstract accross service types (you need to declare a hard depenancy on postgres) and don’t support any runtime management.
§Shark
§Reading
I read https://garnix.io/blog/call-by-hash
and which use a Nix-like unique path for dependencies approach for DNS
records. A service is deployed
e.g. 17e03de23f56edb649df116818f1068a5b82fb53.service.example.org,
and services depend on specific hashes of domain names. This could be
something useful in lenscap.
I read RFC1105 which describes the original BGP protocol specification. Section 3.4 describes the UPDATE message format which seems to be the crux of how routing information is propagated. Notably there is no discussion of security considerations or if BGP routers advertise false routes (BGP hijacking).