Please note that the Tailscale binaries for OpenWRT are pretty large (even if you cross-compile them with compact and strip). Your router might not have enough storage for it.

If that’s the case, you might work around it by only storing the tailscaled binary on persistent storage, because that’s the daemon which runs the actual connectivity. The tailscale binary is only used for making configuration changes, you can copy that to RAM disk, use it to set config params, then delete it.

Here are my basic criteria:

If you want the domain to be used long-term and tie your whole online identity around it, then stay away from all novelty domains. Only use top TLDs and ccTLDs.

Novelty domains can suffer unexpected price hikes across the registry or even be discontinued because they’re basically commercial ventures.

Particularly avoid premium TLDs, because the registry can choose to hike up the price of specific domains separately from the base domain cost, just because they look “premium”. You can have the domain priced up right from under you and come renewal time you have to match the new price or lose it.

The ccTLDs of the EU member countries are a very good idea if you’re an EU citizen because they have built-in privacy for individuals (they don’t publish their info in WHOIS) and are also subject to GDPR.

Your own country’s ccTLD would be an obvious fit but price may be a consideration, some are more expensive than others. As long as you’re an EU citizen you can shop around and get a domain from any other EU member afaik, as well as .eu.

I think .de, .nl, '.frand.ro` are the cheapest, or at least they were last time I checked this a few years ago.

Please note that .de technically requires a local German address for correspondence. You can choose to skip that but if the registry ever has reason to get in touch with you and you don’t have such an address it’s grounds for suspension. Some registrars (INWX for example) will supply their own German address for you for a small extra fee, but that brings the cost of the domain in line with the others so you might as well get a .nl to begin with.

What’s a good smart plug to use?

I assume it’s a thing you place between the machine’s power cable and the wall and can be queried over WiFi?

RRD

That’s a name I haven’t heard in a minute!

I see the rrdtool gallery is still up and my graph is still in there 🤭. (No it’s not the Christmas graph, that one’s insane.)

I’m using Influx nowadays but maybe I should revisit good old rrdtool for old times’ sake.

My money’s on Microsoft taking down the repo before that.

OK, Apple. How do I use passkeys created on iOS for accessing Apple services, on a Linux laptop?

What do you mean, which. All of them have this problem. You can’t force any platform owner to use your favorite credential storage when they decide they don’t want to. All of them will tell you “for my services you use my storage, period”.

You’re picking what vendor you want, not picking unique vendors for every unique passkey.

I don’t get to pick anything, in fact. Most often you’re told “that’s how it is, that’s where the passkey goes” and there’s nothing you can do about it.

It sounds like you just don’t like or want hardware-locked/TPM passkeys. If you generate that type of passkey, then no you can’t do much of that.

Again, _I_ typically don’t get to make that choice, it’s being made for me. And that’s a problem.

It sounds like your concern is, I have a credential manager and want to migrate to a new credential manager.

No. My concern is that I want to choose my own credential manager, and I want it to work with any passkey usage out there. And that’s impossible.

You’re not wrong to have that feeling.

Where is the passkey saved? Can I take it out and back it up? Can I use it on another device, running a completely different OS? If I lose this device the passkey is on, what happens?

The answers to most of these is negative.

There are already dozens of hardware and software passkey vendors. It’s honestly amazing how little lock-in there is.

If my passkeys are spread across dozens of vendors I wouldn’t call that good, first of all, it’s just a headache.

Secondly, just because there’s many of them doesn’t mean there’s no lock-in. Can I get my passkeys out? Can I migrate them freely between any vendors? Can I take backups for myself from all the vendors? Can I restore the backups into each vendor? Can I replace those vendors with a self-hosted solution?

Maybe you’ll prefer more practical criticism then:

https://arstechnica.com/security/2024/12/passkey-technology-is-elegant-but-its-most-definitely-not-usable-security/

To put it simply, every passkey is locked into a large combination of factors: device + platform (OS) + app + the service being used. It is not trivial and often downright impossible to change any of these factors or to render them agnostic. This makes it complicated or impossible to backup passkeys or make them portable.

It’s fine for them to not be portable when they’re used on a work phone, running the company mandated OS, authentication app and passkey store, to login into a suite of apps that are also company-approved.

I do need portability and backup as an individual who wants to be able to login into multiple services across multiple apps running on multiple OS on multiple devices. But I can’t, because the big tech players (Microsoft/Google/Apple etc.) are actively trying to capture passkeys into their platforms and make it hard to get out in any practical way.

With passwords and TOTP I can run something that will sync them across devices and fill them in into any app in a unified manner (or use copy & paste if all else fails). With passkeys I can’t.

Need to edit the proxy host for Jellyfin in NPM (advanced tab) and send the X-Forwaded-For header to it.

proxy_set_header X-Forwarded-For $remote_addr;

And also in Jellyfin settings you have to set the IP that it sees the reverse proxy coming from as a “known proxy”, so it knows it can trust that header when it comes from that IP.

https://jellyfin.org/docs/general/post-install/networking/reverse-proxy/#forwarded-for-headers

Yeah that’s because most people are under the impression that Docker only allocates 172. addresses for its bridge network. I was under that impression too.

Turns out it also allocates 192.168 addresses.

Does it overlap my LAN? Is 192.168.65.X not distinguishable from my defined subnets with a 24-bit mask, now that I know where they’re coming from?

The problem is that the default says 192.168.0.0/16, so it can also generate overlapping addresses. The fact it generated a 192.168.65.x address instead of an 192.168.1.x address was pure luck.

Somehow all of the tutorials I’ve found in the past months to set up services behind a reverse proxy never mentioned any of these gotchas with Docker and networks.

The common-sense assumption is that you will adjust your Docker daemon settings so that you prevent overlap with your LAN. (Also, I expect lots of tutorials aren’t that high quality to begin with.)

If you edit daemon.json like I explained and explicitly only put 172. ranges in there you should be safe from overlaps in the future.

Yep, you’ll have to fix that by telling your proxy to put the client IP in a header that the target app can recognize and use:

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For

But, also, it’s a good idea to have Docker network ranges that don’t overlap your LAN. That would make me uncomfortable too.

You can also look into using IPv4 link-local addresses for Docker bridges (169.254.). Here’s an explanation:

https://github.com/11notes/RTFM/blob/master/linux/container/docker/daemon.md#networking

That frees you from accidental overlaps with pretty much everything else, but it comes with its own gotcha: link-local isn’t routable. This can come back to bite you if you have an app that relies on announcing a public UDP ip:port to a peer and announces the link-local IP. When a peer tries to connect back, it won’t work. So you have to either tweak the app’s config to make sure you announce a non-169.254. IP, or put the app container on a bridge/macvlan network so it auto-detects and announces a routable IP. There’s all kinds of apps that can be affected by this kind of peer-to-peer behavior (file transfer apps, games, VoIP apps etc.)

But TBH I’ve been using link-local ranges for a while now and only got bitten once (Deluge).

Hope you saw my other comment. Docker now also makes 192.168. networks in addition to 172. I’ve explained how to edit your daemon.json to stop it from doing that.

I think I’ve figured it out. Apparently now Docker also adds an 192.168. range on top of 172. ranges for its bridge networks:

https://docs.docker.com/engine/network/#automatic-subnet-allocation

Copy that example to your /etc/docker/daemon.json on all your docker machines, without the 192.168 line, and restart docker, and the 192.168.65. addresses will go away.

(Don’t forget to remove the trailing comma on the last address line.)

Mind you, this won’t solve anything, just remove some potential conflicts with your LAN. You will still see clients appearing to come from bogus addresses, except they’ll be in 172. ranges now.

Well I’ll be damned, there’s a 192.168. tucked away at the end of the 172. ranges:

https://docs.docker.com/engine/network/#automatic-subnet-allocation

{
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 }
  ]
}

seems to have identified this as some NAT setting built in to Docker

TBH I also thought about it being the default range used by Docker for its bridge networks, but I was under the impression it uses 172. ranges by default. The official example on their site says it uses 172.30.0.0/16 and 172.31.0.0/16. Also I have an unmodified docker running on one of my machines and it allocated 172.18.0.0/16 for a bridge network.

You can try to docker network create a bridge network and see what range it gets, you’ll see if it gets a 172. or a 168..

BTW I hope you’re looking at the docker on the reverse proxy machine, not on the jellyfin machine.

Is it?! I always thought that Docker uses 172.16.0.0/16 by default for its networks. Did that get changed at some point?