• 0 Posts
  • 51 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle




  • Yeah, tunnelbroker.net is what I use. It works behind NAT too, and they even give you a /48! For free!

    To be clear I wouldn’t mind paying for guaranteed speeds because the he.net tunnel can be a bit slow at times. My problem with this is that they don’t give you a /64 which basically makes it useless for anything but the “host a couple services” use case. Most people who would consider this, including me, probably don’t have IPv6 connectivity from their ISP at all and would like to get routable IPv6 address space for their home network.








  • I use distro packages. In the rare case something isn’t packaged yet, I package it myself. And for the isolation, systemd services can do most of the things docker can if you need (check systemd-analyze security).

    For just hosting services that can be done instead with normal system services, docker makes your setup a lot more complex (especially on the networking side), for little if any gain. Unless I need to spin up something multiple times temporarily on demand or something has a hard dependency on it, I’m not going to bother with it anymore.








  • Declarative configuration of services and the rest of the entire system, and everything that brings with it.

    • Want to test some new service, or make changes to an existing one, but don’t know if you want to keep it? Sure, just temporarily switch to the new configuration, you can always switch back to the old one and everything will be back as it was.
    • Have multiple servers and want to share configuration between them? Absolutely, just import the same file from both. I have a git repo storing configurations for 10 machines and a huge part of it is shared configuration.
    • Want to use one service’s endpoint (such as a socket path) in another? Sure, just use the socket path configuration option for the first service in the configuration for the second, such as here. This works since everything is a single tree of options which all the service configuration files are then generated from, so interpolate stuff as you wish.
    • Checks for configuration correctness during build of the system (NixOS options are type checked during evaluation, and then during the actual system build there’s more checks, like nginx config has to succeed nginx -t, otherwise the system build fails and you can’t switch to it)
    • Want to spin up a VM to test changes before putting it on the actual target? There’s a builtin command (nixos-rebuild build-vm) that makes a script that starts a QEMU VM with your configuration running in it. It’s as fast as building the real system, so a couple seconds if you’re making small changes.
    • Setting up services is also often as easy as putting services.foo.enable = true; in your configuration. And, if you remove that line, the service is gone, so you’re never left with “the random package or file you installed once to test something and has been forgotten about”. That’s the biggest thing it has over any kind of imperative solution IMO.

    I feel like even if I want to distro hop again and end up putting something else on my desktop, NixOS is going to stay on my servers indefinitely. It’s pretty much a perfect fit for servers.