lemmyvore

Lol I don’t know, I’ll have to try. I would’ve never thought of it. If it works it’s definitely not intuitive. Dark art indeed.

I mean, Valve is doing the minimum copy protection for keeping both players and studios happy.

Let’s not forget that Valve also has a dedicated device, the Deck, and it uses the same minimal methods as the PC version. It has a standard configuration out of the box because that makes sense for a pre-built device, but they allow you to hack it to your heart’s content.

Meanwhile there are companies that feel the need to host their platform on completely locked down devices, like Sony/Microsoft/Nintendo, and invalidate your games on older devices so you’ll buy them over and over again, and make you pay for Internet access etc.

There’s also companies like Epic whose game store app on PC are very invasive.

So yeah, Steam is not completely open, but it’s as good as it gets. There are much worse ways of doing things.

I recommend taking a look at the new Tailscale access controls > policies (aka “grants”). Much easier to understand than their old ACLs. You can quickly draw up rules that only let specific devices access specific nodes and even only specific ports.

There’s one small potential point of confusion, in that you can’t use node names directly in the rules. You have to go to access controls > definitions > hosts and make up a name there assigned to the node IP address, and then you can use that name in a policy.

In other words, even if you already have a tailnode called “nas” with a fixed IP, you can’t just say “nas” in a policy. You have to go to hosts, define one called “nas” that points to that tailnode’s IP, and then you can use “nas” in the policy… 🤪

I understand the logic, which is that hosts and definitions in general are much more powerful and can define IP netmasks and IP groups and then you can use those groups in policies… but boy, the redundancy when you have to do this for single nodes that are already assigned a name and an IP is rubbing me wrong.

It’s very easy to make a custom CA and issue certs. Here’s a good tutorial.

Unfortunately in practice It depends greatly on what’s on the other side (the client app). Some examples:

• DAVx5 on Android works perfectly fine and uses the client cert from the system store. 10/10, this is how all apps should work.
• Ntfy on Android works perfectly fine but wants the client cert file loaded in the app, it doesn’t use the one loaded in the system store. This sucks because instead of loading a cert into the system store once and then deleting it you have to keep the cert file around for this kind of apps, in Android shared storage, which is accessible to all apps.
• Same for Immich, wants the cert loaded in the app. Also, it will randomly lose it (on both iOS and Android). Yes, you heard that right. So it’s basically useless and I had to resort instead to a key in a custom HTTP header; which isn’t exactly the same as mTLS, but helps secure the service at reverse proxy level so it’s better than nothing.
• Firefox on Android will use the cert from the system store, and then it will crash. Again, useless.

Oh did I mention how you get a mTLS client cert to an app on an iOS device? You send it over email to an account that the device has access to through the Mail app, then share the attachment. Yep.

It’s also not exactly straightforward to use mTLS with reverse proxies.

Let’s take for example Caddy and say you want unconditional mTLS for all reverse proxy hosts. Easy enough:

tls /path/to/domain-cert/fullchain.pem /path/to/domain-cert/privkey.pem {
  client_auth {
    mode required
    trust_pool file /path/to/custom/ca.pem
  }
}

But suppose you don’t want unconditional mTLS, you’d like to let clients in if they have mTLS or a custom header, or do different things depending if the client has valid mTLS or not. Does Caddy offer a built-in conditional to act on mTLS status? Nope!

As a workaround I’m setting the client_auth mode to verify_if_given and then using a DIY conditional that checks if the variable http.request.tls.client.certificate_der_base64 is empty or not. But it’s undocumented so who knows if it may break at any point.

For reference, how you handle both custom headers and mTLS at once (after setting the mode as I’ve mentioned):

@immich host "whatever.example.com"
handle @immich {
  @not_authorized {
    not header X-Custom-Pass "LONGRANDOMKEY01" # jim
    not header X-Custom-Pass "LONGRANDOMKEY02" # bob
    vars_regexp {http.request.tls.client.certificate_der_base64} ^$
  }
  error @not_authorized 403
  reverse_proxy http://immich.lan:port
}

The nested “not not” is required because Caddy can only do logical AND in group conditionals, so to do logical OR you basically have to do NOT (NOT a AND NOT b).

Yeah it’s a very good rule of thumb to always bind to explicit IPs.

Another issue with 0.0.0.0 is that it will bind to basically everything, including whatever bridge or tunnel interfaces you may have up on that machine. And that’s how you end up with random services exposed through VPNs and God knows what, when you thought it was a “private” service that only lives on your LAN.

It’s very light DRM and it doesn’t lock the majority of game files nor the save files. You can freely back up the save files and it’s very easy to pirate the games. What stops people from doing that is because it’s much more convenient to have Steam manage them. Valve has always been all about convenience not the DRM.

Also, Steam being open means you can also use an app like Ludusavi to make your own savegame backups, just in case.

True but they can’t rely on the US alone. They have to do business elsewhere. Funding Firefox is a ridiculously cheap way of making sure they can operate with impunity everywhere. It’s brilliant, really.

In the future it will probably come out there was a massive backroom deal. Neither this nor dropping Windows Phone have made any sense.

It also opens the possibility of a manifest v4 which restricts even further what ad blockers can do. But if they do in small steps they hope people will just accept it. They’re basically trying to boil the frog.

In Docker’s case is a non-issue because they were careful to use completely different names for all their packages. It’s only when the external repo uses the same names as the core that the dependency resolver can get confused.

Rant:

apt should either completely forbid external repos from using core package names (like Arch does), or look at both the package name and repo URL when deciding if a package is the same, not just package name.

I’m guessing that letting external repos “hijack” a package name was once upon a time seen as a feature and then they never got around to fixing it.

You say that but sometimes they come up with stuff that’s really useful and it can be very annoying to not have it. Like when they integrated compose into the main.

Also, if you later decide to switch to the official version you’ll have to handle the upgrade carefully or you risk wiping out all your images, containers, networks, volumes etc. Which can be fine if you have backups of all the relevant functional definitions and the volumes and so on, but obviously a huge pain if it catches you unprepared.

Mind you, this can also happen by tinkering with stuff in /etc/docker/daemon.json, which is how I originally learned to back up my shit.

Debian’s versions lag badly behind Docker’s. You’d always be missing the latest features. Docker introduces them at a steady pace and it can get annoying to see people talking about a new useful improvement and then months passing before it gets to you.

If you already know Debian that’s a big point in its favor. Nothing beats a distro you’re familiar with. (And I’d make the same argument if you were used to Ubuntu.)

I’ve used both Debian and Ubuntu Server on my home servers and I ended up returning to Debian.

• Debian embodies and follows the most essential Linux values. It’s open, it’s run by an open organization, it avoids proprietary stuff.
• Debian is long-lived. It’s been around for 30 years, it’s mature, self-sustaining, community-run project, and it will be around 30 years from now. Whereas I wouldn’t bet on Canonical being around in 30 years.
• The upgrade path for Debian is better than for Ubuntu Server LTS.(1) You can upgrade it in-place between major versions a lot more reliably and painlessly than Ubuntu.
• Debian is dedicated to being stable. (Please run stable, btw.)
• Debian is a lot more resource-friendly than Ubuntu Server.

I’ve ended up concluding that Ubuntu Server is Debian, just with more quirks. It offers nothing essential that you can’t do on Debian, and it will just complicate your life when the LTS support period eventually runs out (and even during LTS, when you have to jump through hoops like Ubuntu One to keep updates coming.)

(1) You can fuck up both Ubuntu and Debian’s upgrades by adding a lot of 3rd-party repos because apt doesn’t safeguard against external repos interfering with the core repos’ dependency graph.

So the trick is to keep the OS minimal, install only Docker from its repo and install anything else in Docker containers. That way you benefit the most from Debian being stable and very little from Ubuntu Server.

If you also need to run system containers and virtual machines you can add Incus later to the mix alongside Docker and still keep your host OS lean and simple.

You can also consider completely migrating to Proxmox later, which is also Debian under the hood but it’s a more turnkey solution. I wouldn’t recommend jumping straight into Proxmox unless you’re fairly sure that you’d need to run VMs. (If you’re unsure stick to plain Debian for now.)