Thicket data repository for the EEG
anil.recoil.org
1{
2 "id": "https://ryan.freumh.org/2024-03-18.html",
3 "title": "18 Mar 2024",
4 "link": "https://ryan.freumh.org/2024-03-18.html",
5 "updated": "2024-03-18T00:00:00",
6 "published": "2024-03-18T00:00:00",
7 "summary": "<div>\n <span> Previous: <a href=\"2024-03-11.html\">11 Mar 2024</a> </span>\n <span> Next: <a href=\"2024-03-25.html\">25 Mar 2024</a> </span>\n </div>\n \n \n\n <h3>Eon</h3>\n<p><span>Some scenarios we could solve with a\nclient-server API for Eon:</span></p>\n<ol>\n<li>We could keep track of the proliferation of federated services in an\nEilean deployment including matrix, mastodon, and email.</li>\n</ol>\n<p><span>Currently, we need to manually provision DNS\nrecords like an A record at <code>mastodon.example.org</code>. We need\nto run a certbot to respond to a ACME HTTP challenge by configuring a\npath to serve by a webserver, or respond to a DNS challenge using\ndynamic DNS UPDATES to update a nameserver. The HTTP challenge pretty\nheavyweight and doesn’t work so well when e.g. load balancing accross a\nwebserver, and the DNS challenge typically requires providing access to\nthe whole domain. To demultiplex multiple HTTP services on the same\nmachine we typically use a reverse proxy which requires additional\nconfiguration and is webserver-specific.</span></p>\n<p><span>If we use Eon, services could register\nthemselves to the name server to provision DNS records, TLS\ncertificates, and reverse proxies. For example, when registering a\nmastodon server we can provision an A record\n<code>mastodon.example.org</code>. We can use the ACME DNS-01 challenge\nto create the record required to generate an X.509 certificate at\n<code>_acme-challenge.mastodon.example.org</code>. HTTP/3 and DNS SVCB\nwould allow UDP-only connections to be established without the need for\na TCP handshake. DNS SVCB records could also allow the use of different\nports for services, thereby removing the need to a reverse proxy to\ndemultiplex based on hostname. Perhaps there is some possibility of\nusing Eon to dynamically configure the HTTP proxy for HTTP/2\nconnections.</span></p>\n<p><span>The only notable non-HTTP protocol is SMTP for\na mailserver, and a TURN/STUN server for matrix VoIP calls. The\nmailserver requires DKIM, DMARC, SPIF DNS records for good\npractice.</span></p>\n<p><span>A challenge that isn’t addressed here is\nmanaging the runtime state and secrets of these services.</span></p>\n<ol>\n<li><p><span>Spatial naming. We could use eon to\nprovision the network infrastructure (DNS records, certificates)\nrequired to spin up lightweight spatial services like matrix servers on\na resouce-constrained computers like Raspberry Pis for communicaton in a\nspatial domian. This matrix server could be used for local communicaton\nwith other building users (realtime or async), or communication with\nlocal spatial devices. The challenge with doing this with existing\nmechanisms is the relative labour-intensive process required to set up\nand configure them, which could be automated by Eon. Having a central\norchestrator of this would allow us to keep track of which services are\nrunning on physical machines.</span></p></li>\n<li><p><span>Sharing machines. Say I want to allow\nPatrick to get a shell into the Raspberry Pi controlling our lights at\n<code>capybara.fn06.org</code>. The best way I would do this at the\nmoment is register a Tailscale. It would be great if I could just share\na capability for him to access this machine Many such devices are behind\nNATs and accessed via STUN servers, VPNs, or HTTP reverse proxies. We\ncould dynamically configure this on a DNS request to the machine, and\nreturn the most appropriate mechanism for communication depending on\nconnectivity (e.g. a link-local IP address, a VPN address, a NAT punched\nIP and port (with SVCB?), or bluetooth address?)</span></p></li>\n<li><p><span>Power management. Many machines for\nself-hosted services are idle for a vast amount of time, which has a big\npower drain over time. We could use Eon to power on a machine from full\nshutdown (via a networked socket or WoL) when a service hosted on it is\nqueried on the DNS. Would require 0 TTL records and some knowledge of\nservice idleness in order to shutdown.</span></p></li>\n<li><p><span>Something something public key\nmanagement?</span></p></li>\n</ol>\n<h3>Eilean</h3>\n<p><span><a href=\"https://github.com/RyanGibb/eilean-nix\">Eilean</a> is pretty much\ndone as it related to static configuration. However, there is still a\ngreat deal of complexity to manage in the runtime of the services.\nSystemd is used as a service manager.</span></p>\n<p><span>It would be good if we could manage the\nruntime services in a more inteligent way. I.e. have a policy that if\nwe’re running out of disk space all but the highest priority services\nare paused writing. We could have services declared up-front what they\nneed (e.g. a database, open ports, a reverse proxy) and figure out how\nwe’re going to fulfill those requirements with different backends like\nsqlite or postgres.</span></p>\n<p><span>NixOS modules do this to some degree but\ndon’t really abstract accross service types (you need to declare a hard\ndepenancy on postgres) and don’t support any runtime\nmanagement.</span></p>\n<h3>Shark</h3>\n<p><span>Patrick’s been hacking on Shark to provide a\nmarkdown interface to scripting. The next thing to do is VPNkit\nproxying.</span></p>\n<h3>Reading</h3>\n<p><span>I read <a href=\"https://garnix.io/blog/call-by-hash\">https://garnix.io/blog/call-by-hash</a>\nand which use a Nix-like unique path for dependencies approach for DNS\nrecords. A service is deployed\ne.g. <code>17e03de23f56edb649df116818f1068a5b82fb53.service.example.org</code>,\nand services depend on specific hashes of domain names. This could be\nsomething useful in <code>lenscap</code>.</span></p>\n<p><span>I read <a href=\"https://www.rfc-editor.org/rfc/rfc1105\">RFC1105</a> which\ndescribes the original BGP protocol specification. Section 3.4 describes\nthe UPDATE message format which seems to be the crux of how routing\ninformation is propagated. Notably there is no discussion of security\nconsiderations or if BGP routers advertise false routes (BGP\nhijacking).</span></p>",
8 "content": "<div>\n <span> Previous: <a href=\"2024-03-11.html\">11 Mar 2024</a> </span>\n <span> Next: <a href=\"2024-03-25.html\">25 Mar 2024</a> </span>\n </div>\n \n \n\n <h3>Eon</h3>\n<p><span>Some scenarios we could solve with a\nclient-server API for Eon:</span></p>\n<ol>\n<li>We could keep track of the proliferation of federated services in an\nEilean deployment including matrix, mastodon, and email.</li>\n</ol>\n<p><span>Currently, we need to manually provision DNS\nrecords like an A record at <code>mastodon.example.org</code>. We need\nto run a certbot to respond to a ACME HTTP challenge by configuring a\npath to serve by a webserver, or respond to a DNS challenge using\ndynamic DNS UPDATES to update a nameserver. The HTTP challenge pretty\nheavyweight and doesn’t work so well when e.g. load balancing accross a\nwebserver, and the DNS challenge typically requires providing access to\nthe whole domain. To demultiplex multiple HTTP services on the same\nmachine we typically use a reverse proxy which requires additional\nconfiguration and is webserver-specific.</span></p>\n<p><span>If we use Eon, services could register\nthemselves to the name server to provision DNS records, TLS\ncertificates, and reverse proxies. For example, when registering a\nmastodon server we can provision an A record\n<code>mastodon.example.org</code>. We can use the ACME DNS-01 challenge\nto create the record required to generate an X.509 certificate at\n<code>_acme-challenge.mastodon.example.org</code>. HTTP/3 and DNS SVCB\nwould allow UDP-only connections to be established without the need for\na TCP handshake. DNS SVCB records could also allow the use of different\nports for services, thereby removing the need to a reverse proxy to\ndemultiplex based on hostname. Perhaps there is some possibility of\nusing Eon to dynamically configure the HTTP proxy for HTTP/2\nconnections.</span></p>\n<p><span>The only notable non-HTTP protocol is SMTP for\na mailserver, and a TURN/STUN server for matrix VoIP calls. The\nmailserver requires DKIM, DMARC, SPIF DNS records for good\npractice.</span></p>\n<p><span>A challenge that isn’t addressed here is\nmanaging the runtime state and secrets of these services.</span></p>\n<ol>\n<li><p><span>Spatial naming. We could use eon to\nprovision the network infrastructure (DNS records, certificates)\nrequired to spin up lightweight spatial services like matrix servers on\na resouce-constrained computers like Raspberry Pis for communicaton in a\nspatial domian. This matrix server could be used for local communicaton\nwith other building users (realtime or async), or communication with\nlocal spatial devices. The challenge with doing this with existing\nmechanisms is the relative labour-intensive process required to set up\nand configure them, which could be automated by Eon. Having a central\norchestrator of this would allow us to keep track of which services are\nrunning on physical machines.</span></p></li>\n<li><p><span>Sharing machines. Say I want to allow\nPatrick to get a shell into the Raspberry Pi controlling our lights at\n<code>capybara.fn06.org</code>. The best way I would do this at the\nmoment is register a Tailscale. It would be great if I could just share\na capability for him to access this machine Many such devices are behind\nNATs and accessed via STUN servers, VPNs, or HTTP reverse proxies. We\ncould dynamically configure this on a DNS request to the machine, and\nreturn the most appropriate mechanism for communication depending on\nconnectivity (e.g. a link-local IP address, a VPN address, a NAT punched\nIP and port (with SVCB?), or bluetooth address?)</span></p></li>\n<li><p><span>Power management. Many machines for\nself-hosted services are idle for a vast amount of time, which has a big\npower drain over time. We could use Eon to power on a machine from full\nshutdown (via a networked socket or WoL) when a service hosted on it is\nqueried on the DNS. Would require 0 TTL records and some knowledge of\nservice idleness in order to shutdown.</span></p></li>\n<li><p><span>Something something public key\nmanagement?</span></p></li>\n</ol>\n<h3>Eilean</h3>\n<p><span><a href=\"https://github.com/RyanGibb/eilean-nix\">Eilean</a> is pretty much\ndone as it related to static configuration. However, there is still a\ngreat deal of complexity to manage in the runtime of the services.\nSystemd is used as a service manager.</span></p>\n<p><span>It would be good if we could manage the\nruntime services in a more inteligent way. I.e. have a policy that if\nwe’re running out of disk space all but the highest priority services\nare paused writing. We could have services declared up-front what they\nneed (e.g. a database, open ports, a reverse proxy) and figure out how\nwe’re going to fulfill those requirements with different backends like\nsqlite or postgres.</span></p>\n<p><span>NixOS modules do this to some degree but\ndon’t really abstract accross service types (you need to declare a hard\ndepenancy on postgres) and don’t support any runtime\nmanagement.</span></p>\n<h3>Shark</h3>\n<p><span>Patrick’s been hacking on Shark to provide a\nmarkdown interface to scripting. The next thing to do is VPNkit\nproxying.</span></p>\n<h3>Reading</h3>\n<p><span>I read <a href=\"https://garnix.io/blog/call-by-hash\">https://garnix.io/blog/call-by-hash</a>\nand which use a Nix-like unique path for dependencies approach for DNS\nrecords. A service is deployed\ne.g. <code>17e03de23f56edb649df116818f1068a5b82fb53.service.example.org</code>,\nand services depend on specific hashes of domain names. This could be\nsomething useful in <code>lenscap</code>.</span></p>\n<p><span>I read <a href=\"https://www.rfc-editor.org/rfc/rfc1105\">RFC1105</a> which\ndescribes the original BGP protocol specification. Section 3.4 describes\nthe UPDATE message format which seems to be the crux of how routing\ninformation is propagated. Notably there is no discussion of security\nconsiderations or if BGP routers advertise false routes (BGP\nhijacking).</span></p>",
9 "content_type": "html",
10 "categories": [],
11 "source": "https://ryan.freumh.org/atom.xml"
12}