moreentropy

How about just shipping a networkd.conf(.d) config snippet and .network file with the wanted defaults. This is just another instance of I-hate-systemd-for-no-reason whining

> P.S. I actually run systemd-nspawn in production, but I am probably the only person on earth to do so.

You're not alone, systemd-nspawn is very much underrated. I have used it a lot for machine containers, though I'm using podman+quadlet+systemd more right now. systemd-nspawn with mkosi for generating workload images is still a nice & powerful ecosystem.

I would consider PIV and SSH through PIV/OpenPGP legacy and undesired nowadays. If you're only interested in state of the art second factor instead of passwords for sensitive use cases, a simple FIDO2 security key w/o all the extra features on a yubikey 5 is enough.

You can solve most of those with only FIDO2 nowadays:

Webauthn with fido/u2f is supported on most websites and oidc providers.

SSH with FIDO and resident / non-resident keys is supported.

PAM -> as documented in the guide, although setting origin and type manually isn't necessary and you can save keys in ~/.config/Yubico so non-root users can manage their keys. I would recommend enabling PIN verification with pamu2fcfg --pin-verification.

LUKS hard disk encryption with FIDO2 for unlocking isn't covered but is possible, systemd-cryptenroll can set this up on modern linux distributions.

While having a YK neo with all the features, I prefer the simple FIDO security key. Everything you could want apart from legacy/special use cases can be achieved with fido.

websites -> fido/u2f ssh -> native fido support in ssh-keygen login -> fido2 for windows, libpam-u2f for linux luks encryption -> systemd-cryptenroll

Currently, it is. The "S" offering is at 2€/month long term. I'm still on a "S" contract that stays at 1€.

Can't complain about 1&1, also had dedicated 1HE boxes there for a long time w/o issues but I understand the grief in case something goes wrong.

I host DNS elsewhere so I can relocate such a simple proxy within a few minutes, that's what my desaster recovery plan looks like.

No specific reason against Cloudflare, just a DIY attutide in this case.

HAProxy is fun, and I also run it as a TCP proxy, so HTTPS is terminated in my (hidden) home server and I don't need to trust my proxy server, I guess that's not possible with cloudflare.

I'm in the same situation (50 Mbps uplink at one place, 100Mbps at another) and that's enough to do all hosting for hobby projects at home, which I really love.

Instead of exposing my home directly using DynDNS, I got a really cheap low end server (currently a VM w/ 1 CPU, 512MB RAM and 400mbps traffic flat) for 1€/month that proxies all traffic to the (hidden) servers hosted at home.

The spec is enough to reliably run a HAproxy that can max out the available bandwidth w/o sweat and it allows me to do failover between servers in my two "home datacenters" + possibly cache assets.

While these tutorials are a great way to teach system administration to those who want to start tinkering, I wish people would put more energy into building well crafted firmware images using frameworks like openembedded or buildroot and teaching people how to use those.

Most of the raspbian-based tutorials or images out there treating the raspberry pi like a normal server are just going to trash the SD or fail because system state is mutating in unexpected ways.

Start building immutable images that hold temporary data strictly in RAM.

I wonder why systemd-nspawn isn't mentioned/used more. I've been using it for years for full system containerization and I'm really happy with how lightweight and functional it is. No need for additinal LXC/LXD layers.

sure. freenode for free and open projects and hackint for everything ccc / chaos community related.

That's your most pressing question?