Limit your sites to VPN-connected (*and local) clients only

The problem: You have a bunch of sites running behind an nginx proxy, and you want to limit access to some of the more critical ones to your VPN clients only as a second security layer. You also have an ISP that will sometimes change your public IP address, so you are using the services of a dynamic DNS provider such as DuckDNS.

The solution: YMMV, but generally, web requests from your VPN clients will originate from the public IP of your VPN server. Well that’s handy – you only have to tell nginx to allow anything from this IP, right?

Not so fast: nginx has no idea of its own public IP address. There are nginx modules that will do a reverse DNS lookup on a hostname (like the one provided by your dynamic DNS provider), but as this has to happen on every request, the performance hit will be substantial.

However, you already have a cron job running every once in a while informing DuckDNS of your current IP address – you simply have to add a couple of lines to your script so that it informs nginx, too! Here’s an example of that addition:

resolved_ip=$(dig a your-subdomain-here.duckdns.org +short);
if [ -n "$resolved_ip" ]; then
    echo "allow $resolved_ip;" > /path/to/duck.conf;
fi

Test your script – duck.conf should now contain a single allow directive with your public IP. You can safely include it in the configuration file for the site you’d like to limit – under the server, location or http block:

include /path/to/duck.conf;
deny all;

Restart nginx and test accessing with and without VPN.

edit: It hadn’t occurred to me originally, but this will also cover any clients from your local network too (since they are also behind the same public IP) – unless they access the sites via IP instead of domain name. This may or may not be an added benefit.
edit 2: Encased that echo in an if block because saving an empty $resolved_ip (say, if your Internet connection is temporary down) will bork your whole nginx on the next restart.

Digital Life Redundancy

This is a belated response to the “I’ve locked myself out of my digital life” post that was circulating earlier this month. Its author describes a hypothetical situation in which a single unexpected disaster (such as a lightning strike) could cause disruptive damage to your digital – and in turn, to your “analogue” – footprint.

The post is thoughtful and makes a good point – I’m not really arguing against it. In fact, I believe that everyone should be doing some sort of prep work for unforeseen events. However, a lot of the theoretical aftermath can be avoided with this one simple trick: redundancy. Keep a spare work laptop* at your office or in your parents’ house, use a password manager with a secure online repository (such as pass with git), and you’ll be fine until Russia invades. Plus, that’s a little less dead weight to lug around when biking to work.

* – five-year old Thinkpads and Latitudes go for around 250 EUR, but you can run Firefox and Vim on a 10 year old X220 anyway

Openbox scaling for HiDPI displays

I recently switched to a laptop with a 16:10 QHD display (popularized as Retina by a certain shoddy company), and I faced a problem that I had been fearing for a while – scaling on X11/Openbox. Specifically, I really didn’t want to switch to anything Wayland, GNOME and/or KDE related – not because I have anything against them, but because I’m too old and don’t want to. I have been using Openbox (and some version of the same configuration files) for 10+ years, longer than my current Linux distribution, so you can say that there is some attachment involved.

Searching online does not yield any helpful guides or tips, and while there is a detailed article on HiDPI displays on the Arch Wiki, it doesn’t go into any detail on the less popular window managers out there. There is, in fact, a singular grain of gold, but it is well hidden under a section cryptically titled “X Resources”:

If you are not using a desktop environment such as KDE, Xfce, or other that manipulates the X settings for you, you can set the desired DPI setting manually via the Xft.dpi variable in Xresources:

Xft.dpi: 192

After about half an hour of messing around with fonts for individual applications, it turned out that this was the only setting that had to be changed. Of course, there will always be that app that does not care about your system-wide configuration (looking at you, tint2), but 95% of the work was handled by that change.