Max-P

In this world, money is power, and power absolutely does corrupt people.

I’ve seen a lot a fair amount of people that started off with humble beginnings, got really popular, made a ton of money, and turned into shitbags as a result because they can just fork up a bunch of cash to make problems go away.

Money and power enables you to get away with immoral stuff, if not straight up illegal.

Having the web server be able to overwrite its own app code is such a good feature for security. Very safe. Only need a path traversal exploit to backdoor config.php!

IPv6 or IPv4?

A /3 of IPv4 for that price is impossible, that’d be 10% of the entire IPv4 space. A /29 (32-3) would be more reasonable but 1k for a block of 8 IPs would be a massive ripoff.

Doesn’t make sense for IPv6 either, as that’d be exactly the global unicast range (2::/3), but makes sense they’d give you like a huge block in there, maybe a /32 as that’s what they assign to an ISP. As an end user you usually get a /48.

I want to love IPv6 but it’s unfortunately still basically impossible to get good proper IPv6 in the first place.

At home I’m stuck with fairly broken 6rd that can’t be hardware accelerated by my router and the MTU is like 1200 which is like 20% bandwidth overhead just for headers on the packets.

On the server side, OVH does have IPv6 but it’s not routed, so the host have to pretend to have all the IPv6 addresses and the OVH routers will only accept like 8 of them in use before its NDP table is full, so assigning an IPv6 to every Docker container fails miserably.

IPv6’s main problem is ISPs are so invested in NAT and IPv4 infrastructure they just won’t support IPv6. Microsoft, Google and Apple need to team together and start requiring functional IPv6 to create user demand, because otherwise most users don’t know about CGNAT and don’t care. Everything needs to complain about bad IPv6 connectivity so users complain to ISPs and pressure them into fixing it.

Yep, and I’d guess there’s probably a huge component of “it must be as easy as possible” because the primary target is selfhosters that don’t really even want to learn how to set up Docker containers properly.

The AIO Docker image is an abomination. The other ones are slightly more sane but they still fundamentally mix code and data in the same folder so it’s not trivial to just replace the app.

In Docker, the auto updater should be completely neutered, it’s the wrong way to update the app.

The packages in the Arch repo are legit saner than the Docker version.

I’ve heard very good things about resold HGST Helium enterprise drives and can be found fairly cheap for what they are on eBay.

I’m looking for something from 4TB upwards. I think I remember that drives with very high capacity are more likely to fail sooner - is that correct?

4TB isn’t even close to “very high capacity” these days. There’s like 32TB HDDs out there, just avoid the shingled archival drives. I believe the belief about higher capacity drives is a question of maturity of the technology rather than the capacity. 4TB drives made today are much better than the very first 4TB drives we made a long time ago when they were pushing the limits of technology.

Backblaze has pretty good drive reviews as well, with real world failure rate data and all.

They’re still much closer to token predictors than any sort of intelligence. Even the latest models “with reasoning” still can’t answer basic questions most of the time and just ends up spitting back out the answer straight out of some SEO blogspam. If it’s never seen the answer anywhere in its training dataset then it’s completely incapable of coming up with the correct answer.

Such a massive waste of electricity for barely any tangible benefits, but it sure looks cool and VCs will shower you with cash for it, as they do with all fads.

Ethernet splitter

What kind of splitter? Not a hub or switch, just a passive splitter?

Those do exist to do 4x 100M links on a single pair each, but you can’t just plug those into a router or switch and get 4 ports, it still needs to eventually terminate as 4 ports on both ends.

If you’re behind Cloudflare, don’t. Just get an origin certificate from CF, it’s a cert that CF trust between itself and your server. By using Cloudflare you’re making Cloudflare responsible for your cert.

There’s also Cockpit if you just want a basic UI

Does the morning coffee count? I’ll skip it if I’m being late but I do like my morning coffee.

I believe you, but I also very much believe that there are security vendors out there demonizing LE and free stuff in general. The more expensive equals better more serious thinking is unfortunately still quite present, especially in big corps. Big corps also seem to like the concept of having to prove yourself with a high price of entry, they just can’t believe a tiny company could possibly have a better product.

That doesn’t make it any less ridiculous, but I believe it. I’ve definitely heard my share of “we must use $sketchyVendor because $dubiousReason”. I’ve had to install ClamAV on readonly diskless VMs at work because otherwise customers refuse to sign because “we have no security systems”. Everything has to be TLS encrypted, even if it goes to localhost. Box checkers vs common sense.

LetsEncrypt certs are DV certs. That a put a TXT record for LetsEncrypt vs a TXT record for a paid DigiCert makes no difference whatsoever.

I just checked and Shopify uses a LetsEncrypt cert, so that’s a big one that uses the plebian certs.

Neither does Google Trust Services or DigiCert. They’re all HTTP validation on Cloudflare and we have Fortune 100 companies served with LetsEncrypt certs.

I haven’t seen an EV cert in years, browsers stopped caring ages ago. It’s all been domain validated.

LetsEncrypt publicly logs which IP requested a certificate, that’s a lot more than what regular CAs do.

I guess one more to the pile of why everyone hates Zscaler.

That’s more of a general DevOps/server admin steep learning curve than Vaultwarden’s there, to be fair.

It looks a bit complicated at first as Docker isn’t a trivial abstraction, but it’s well worth it once it’s all set up and going. Each container is always the same, and always independent. Vaultwarden per-se isn’t too bad to run without a container, but the same Docker setup can be used for say, Jitsi which is an absolute mess of components to install and make work, some Java stuff, and all. But with Docker? Just docker compose up -d, wait a minute or two and it’s good to go, just need to point your reverse proxy to it.

Why do you need a reverse proxy? Because it’s a centralized location where everything comes in, and instead of having 10 different apps with their own certificates and ports, you have one proxy, one port, and a handful of certificates all managed together so you don’t have to figure out how to make all those apps play together nicely. Caddy is fine, you don’t need NGINX if you use Caddy. There’s also Traefik which lands in between Caddy and NGINX in ease of use. There’s also HAproxy. They all do the same fundamental thing: traffic comes in as HTTPS, it gets the Host header from the request and sends it to the right container as plain HTTP. Well it doesn’t have to work that way specifically but that’s the most common use case in self hosted.

As for your backups, if you used a Docker compose file, the volume data should be in the same directory. But it’s probably using some sort of database so you might want to look into how to do periodic data exports instead, as databases don’t like to be backed up live since the file is always being updated so you can’t really get a proper snapshot of it in one go.

But yeah, try to think of it as an infrastructure investment that makes deploying more apps in the future a breeze. Want to add a NextCloud? Add another docker compose file and start it, Caddy picks it up automagically and boom, it’s live and good to go!

Moving services to a new server is also pretty easy as well. Copy over your configs and composes, and volumes if applicable. Start them all, and they should all get back exactly in the same state as they were on the other box. No services to install and configure, no repos to add, no distro to maintain. All built into the container by someone else so you don’t have to worry about any of it. Each update of the app will bring with it the whole matching updated OS with the right packages in the right versions.

As a DevOps engineer we love the whole thing because I can have a Kubernetes cluster running on a whole rack and be like “here’s the apps I want you to run” and it just figures itself out, automatically balances the load, if a server goes down the containers respawn on another one and keeps going as if nothing happened. We don’t have to manually log into any of those servers to install services to run an app. More upfront work for minimal work afterwards.

Good luck with that given 3D printers are full of open-source software.

Yeah, that didn’t stop it from pwning a good chunk of the Internet: https://en.wikipedia.org/wiki/Log4Shell

IMO the biggest attack vector there would be a Minecraft exploit like log4j, so the most important part to me would make sure the game server is properly sandboxed just in case. Start from a point of view of, the attacker breached Minecraft and has shell access to that user. What can they do from there? Ideally, nothing useful other than maybe running a crypto miner. Don’t reuse passwords obviously.

With systemd, I’d use the various Protect* directives like ProtectHome, ProtectSystem=full, or failing that, a container (Docker, Podman, LXC, manually, there’s options). Just a bare Alpine container with Java would be pretty ideal, as you can’t exploit sudo or some other SUID binaries if they don’t exist in the first place.

That said the WireGuard solution is ideal because it limits potential attackers to people you handed a key, so at least you’d know who breached you.

I’ve fogotten Minecraft servers online and really nothing happened whatsoever.

If your stuff is all Docker then yeah, immutable makes sense as it makes the entire box declarative and immutable: you can get back the exact same operating Docker environment on the server, and then you can get back the exact same Docker workloads going with the Docker compose configurations.

If you ever need to run stuff you’d run on Debian, you can just shove it in a Debian container.

That said, if most of the stuff is containers, the risk of just the core Debian breaking is fairly low. Pick whatever is easiest for you to deal with based on your needs. Immutable distros have a bit of a learning curve.

Texting is also damn convenient, I can deal with several conversations at once without having to pause the movie I’m watching.

Speaking on the phone doesn’t just tie your line, it ties your whole life too.