Wanting to compile a small program I’d written in Rust to run on my home router, I found this guide to cross compilation of Rust code. The router is a Netgear R7000 with an ARM processor, running FreshTomato, a distribution of Linux for ARM and MIPS architecture consumer routers. The top of that guide shows an example of installing the cross-compilation toolchain for ARM on Ubuntu, but it required some work to adapt to Mac OS High Sierra, my desktop environment.

On Debian, there’s a group named ssl-cert which grants access to TLS certificates and private keys, so that services that don’t run as the root user can still use TLS certificates. For example, the PostgreSQL Debian package installs PostgreSQL to run as a user named postgres, which is a member of the ssl-cert group, and so it can use certificates and private keys in /etc/ssl.

The certbot Let’s Encrypt client, by default, makes the certificates and private keys it installs only readable by the root user. There is an open issue against certbot, requesting that on Debian, certbot should follow the Debian standard of making the certificates and keys readable by the ssl-cert group as well. In the meantime, until that issue is resolved, the ownership can be set by a post-hook which will be run by certbot after obtaining or renewing a certificate.

Dnsmasq can be configured to add various types of records like SRV, PTR, and NAPTR to its internal DNS server by various directives in its configuration file. But what if there’s a less common type of DNS record that you want to serve, which dnsmasq doesn’t have a specific configuration directive to handle?

Handily, dnsmasq also supports serving arbitrary DNS resource records using the dns-rr option. However you have to supply the binary value of the response encoded in hexadecimal. Here’s an example of how to do this for a URI record with Python. The URI record type is described in RFC 7553 which describes the binary value of the response (“wire format”) as: