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.
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?
Just to understand better:
If all of the above is correct I would look at the network interfaces that are up on the mini-PC and the NAS, as well as inside the containers of the proxy and of Jellyfin, and see if there isn’t a 192.168.65.1 up on there somewhere for whatever reason.
You can also try making a manual request (wget, curl, nc) from the proxy container to Jellyfin and see what it shows up as.
May also want to see what’s the DNS situation in your LAN and on those machines. You mentioned “names” being used, how are those defined and resolved?
Last but not least are the containers you mentioned using docker bridge networks or ipvlan?
What is “the API”?
Good question. When you have multiple implementations of an API, the API (the authoritative version) is what gives the reference spec that all other apps must follow.
If the authoritative version will be fully implemented only by the closed backend and in the closed apps, it will cripple the FOSS backend and apps.
This is a common tactic used by companies that want to sideline the FOSS options and slowly make them irrelevant.
Yes, today all apps talk to both Bitwarden and Vaultwarden the same way. Be on the lookout in case that changes.
If there are two version of Bitwarden backend (closed and FOSS), and the closed one changes its API, and the closed Bitwarden apps also switch to the closed API, then what value does the FOSS API have anymore?
Both backend and frontend revolve around the API, and Bitwarden owns that not Vaultwarden.
If Bitwarden decides to modify the API so that only their closed-source backend has the full spec, and only gives that spec to their own apps, everything else (Vaultwarden and 3rd-party apps) will fall behind or become unusable.
To counter that, Vaultwarden and the 3rd-party apps need to declare their own API and prepare to fly solo completely independently from Bitwarden.
Such a move would force Bitwarden to show their true colors. If they really mean to stay true to the open version they will keep cooperating and keeping their API in sync with the Vaultwarden API.
The current FOSS backend used to be the center of the ecosystem. Going forward that may change. If it stops being that center and it becomes merely a token offering so Bitwarden can claim “we’re still doing FOSS” then it will become pointless.
Simply forking the backend is meaningless without the work to also drag along the entire ecosystem, or establish a new one. Forking a project takes time, effort, vision, persistence, determination.
Everybody can still fork/rename/publish the FOSS version
Yeah, but there’s no guarantee the FOSS version will be the same as the closed one.
Vaultwarden (and all the client apps) depend on Bitwarden for the API spec. If Bitwarden introduces closed features in the API that Vaultwarden can’t/won’t implement, but the client apps do, it will split the spec. They can also introduce API license keys, which would render Vaultwarden mostly irrelevant.
The only way for Vaultwarden to remain relevant going forward is to own it and split ways from Bitwarden. This would in turn mean that the FOSS client apps have to decide which to support. But I think the ecosystem is going to fragment eventually anyway, so the sooner every app decides which way they want to go, the better.
RAID comes down to reducing the risk of any single disk failure making you lose data. But you can also approach that with backups.
There’s also the secondary benefit of avoiding downtime but that’s questionable in a self-hosted setup, unless you’ve come to depend on services that can’t continue when the server is offline. In my case that’s not true because email is not self-hosted, things like calendar and contacts can function offline on the phone, just don’t have server sync for the duration, and things like photo archive aren’t essential (important yes, but not “can’t function daily without them”-essential).
Speaking of which, I think the first thing you should do is categorize your data by degrees of gravity along these two criteria: (1) how over would my life be if I lost this data and (2) how essential it is to my daily function.
It’s important to realize that these two criteria overlap but aren’t the same, first of all. Secondly, I think you’ll find that data criticality in regard to your life is maybe not what you expected. Truly essential things will probably end up being smaller than you think, and that makes them easy to back-up, making RAID maybe not such a must-have.
IMO it’s more important to set up a 3-2-1 backup strategy and consider your methods for achieving that than to have a RAID setup. Some cheap and effective methods are: backups to “cold” HDDs (which you keep in the closet, bring out once a month for a backup, and put back); backups to optical disc (Blu Ray); backups to online storage.
Please be aware that backups tools and copy/sync tools are different beasts. Rsync or rclone for example is not backup tools, they’re fancy copy tools. A true backup tool (borg, restic) will give you integrity checks (independent on the supposedly-still-pristine-source), deduplication, incremental backups, encryption (essential for online storage), recovery, adaptive compression etc. They also work transparently on top of regular filesystems and/or SSH, which lets you use generic online storage for backup. For example you can sync a local borg repo to a free Dropbox account, or use borg over ssh with a Hetzner storage box.
Personally I stay away from complicated array setups. I use pairs of HDDs in RAID1 and that’s all the RAID I need. RAID5 is a data loss waiting to happen because the long and intensive rebuild puts too much stress on the rest of the array members in case of one disk loss, so basically RAID6 is a must, but that makes things even longer and more complicated. ZFS is a very complex beast, it needs a lot of RAM to function efficiently, and the misconfiguration scenarios and subtle failure scenarios are terrifying. It’s also not going to solve any problem that you can solve with backups, which you should prioritize anyway.
Another thing that you must realize and commit to, with any approach that uses disks, is that any disk can fail at any time. Any of the backup drives, any of the live drives. You MUST always have at least one known good spare on hand. And I mean literally in hand, because if you have to go shopping in today’s day and age that means weeks away. Always have the spare local.
Also, don’t think this doesn’t include SSD’s, particularly system disks. Losing the M.2 that the server runs off can hurt like a bitch. Losing any of the fancy SSD’s in your desktop/gaming computer/laptop, even more so. But people often overlook those and hope for the best, when same logic applies: backup, and have a spare in hand.