It's summer, and that means the attic gets hot. I'm looking to get some kind of easy way to check the attic temperature from afar, so that I can keep tabs on it, and so that I can adjust the fans and the windows appropriately. This is really basic telemetry, a task that has been done many times before, using nearly every network protocol ever invented.
I decided for 2021 that I wanted to do this monitoring with some old-fashioned protocols, so the query tool of choice is "finger". I found a very nice modern implementation called finger2020 from Michael Lazar (mozz), which is designed for single-user systems. This runs under systemd, which makes it easy to install.
A simple crontab pulls temperature data from wherever it can find it, which on a Linux system could be lots of things. From past experience I have found that simply tracking the /sys/class/thermal values from the kernel give you CPU temperature for whatever computer you're running on, and that if your computer is hot, the rest of your space is probably hot too. As a bonus it's easy to grab with no additional external sensors needed.
I'm running Tailscale, which means there's a trustable inside
network on tailscale0, and an untrusted outside network on
ethernet or wifi or whatever interfaces are exposed. This led
to the question: can you deliver different content to the world
depending on which interface the traffic comes in on, without
putting any of that logic into the program serving up the data?
After some spelunking through the systemd documentation and not
a lot of searchable examples from the net, I came up with either
a brilliant hack or an awful kludge to make this work. systemd
has a BindToDevice directive in its socket files that lets you
associate a socket with an interface (not just its address,
which could change, but the interface itself). So I took
the unit files from finger2020, replicated them three ways,
and for each one added an appropriate BindToDevice=tailscale0
or whatever interface I had and then created a service file
that pointed to that socket.
The slightly weird part is that if you are on a machine querying itself, even if you specify an IP address of an external interface, you'll get packets on the loopback (lo) interface. So one socket handles loopback, one handles eth0 (for queries on a public network), and one handles tailscale0 (for queries on the private VPN).
A more elegant approach if you want to change your server is to look up the address from Tailscale, using the function tailscale.WhoIs. An example of this logic is in the hello service run by Tailscale which switches on the results of the WhoIs call and lets you further serve individual content because you know not just the interface the user is coming in on but the user name! So very handy if you have more than one user on your network.
The BindToDevice approach should work for any VPN you are using, and it should also let you do deliver services that are reachable only from private addresses and that don't ever show up on the public Internet, even if the code you are running is ignorant of that distinction.
Brilliant hack or awful kludge? Hard to say yet.
Comments