6 ms·

I run wireguard on an even lower end Linksys router, and it seems to work just fine. I suppose my internet connection isn't the fastest, though. It's interesti

I run wireguard on an even lower end Linksys router, and it seems to work just fine. I suppose my internet connection isn't the fastest, though. It's interesting to see someone using a single board computer as their main computer, and preferring a Linux distro that compiles everything from source. Why bother with docker for a home server other than for the fun of it? I've been embracing systemd recently, and using it to manage processes in an embedded system. Once you wrap your head around how services work, it seems pretty convenient compared to init scripts. Notably, systemd works with legacy init scripts, so you could still go that route if you wanted to. Maybe throwing docker into the mix makes it clunkier, though?

colordrops 4y ago
NixOS uses systemd to manage containers. Works great and is hassle free IMO.
- na85 4y ago
  NixOS seems to make needless complexity a point of pride.
  - amarshall 4y ago
    NixOS makes purity and declarative configuration a point of pride. With that comes greater complexity.
  - whateveracct 4y ago
    None of the complexity is needless - it all follows from its core principles. Maybe you disagree with those principles. Maybe you disagree with software having hard principles. That's fine. NixOS isn't for you. It's wonderful for me though!
    - bayindirh 4y ago
      The problems solved by NixOS are mostly solved already. NixOS solves them differently, and that's OK, but it's not solving them for the first time.
      - colordrops 4y ago
        I've never been able to restore my entire machine completely from config files to the exact same state reliably. What else has solved this?
        bayindirh 4y ago
        From top of my head: A- If you want to be able to restore to any point after installing your system: LVM/ZFS/BTRFS snapshots got you covered. B1- If you want to install your system the way you want, you have Kickstart (RedHat family) and Preseed (Debian family). You can provide an installation template to the installers, and they install your system the way you want. You want to get your /etc/ afterwards the installation? Either provide it on a disk, or your local network, or anywhere on the internet. Either integrate it to your Kickstart/Preseed end hooks, or do it after your first boot. B2- If you want something more fancy? Create a FAI installation media which installs the system you want. C- You want to transform an existing Debian system to something you want? You get the dpkg package selection state and set to the target system, apply the state so the system is converted to your own selections. Apply the /etc via git or any way you want. D- Want something more programmatic? Run an Ansible playbook locally (This is how GitLab installs and configures itself during install). E- For fleet installations there are XCAT and network variants of B1, but they are out of scope for personal systems. We use E in our system room. I used B1 for personal systems and B2 to deploy an installation country-wide via USB sticks. I used C in the same project for a small subset of servers. In these cases, all systems are operational in the first boot, starting from a known state. I know a lot of people using A, and nudging me to try/use it. GitLab uses D every time I upgrade it.
        colordrops 4y ago
        Thanks for all the details. "A" can't really be checked into git due to size, and doesn't allow for forward config changes, just rollbacks. Do B1 or B2 allow updates to an existing system? C so far seems the closest to Nix, though it's missing the configuration side. I used D before and frankly Ansible is not great. It is meant to be idempotent but has so many holes that it never really is, and because it's a separate layer from the system itself, the scripts might not work after a system upgrade. With Nix, the config IS the system. E sounds interesting, never heard of it - sounds like you saying it's not suitable for personal use though for some reason.
    - Gordonjcp 4y ago
      What's the selling point, what's wonderful about it?
      - whateveracct 4y ago
        Entire OS configured with code, which can be modular with imports and functions. Want to run a Postgres server? One-liner in your config. Want to advertise yourself over avahi? Same deal. Need custom udev rules? One-liner again. I literally cannot bork my machine. I can always roll back. Useful when messing with low-level stuff like drivers. I have full control and understanding of updates and the exact versions of all the programs I run. I can always read the source of any program I'm running by looking in the nix store. Super easy to package new programs and contribute to nixpkgs. Super easy to tweak packaging other provided without forking via overlays. I share config across devices in a git repo, so provisioning a new machine is trivial. I got a desktop and I basically imported a bunch of common config along with like 10 lines of config specific to the desktop.
        sgarland 4y ago
        > I literally cannot bork my machine. I can always roll back. So use a templated VM, or a filesystem with easy snapshotting like ZFS or BTRFS. The former also allows for easy provisioning of new machines, and doesn't lock you down to a single OS.
        whateveracct 4y ago
        I never said NixOS uniquely solves that. And that doesn't have all the other benefits. Also it's a worse way to handle state and rollbacks. Sledgehammer for a thumbtack. I already spent the time to learn the hard stuff. So now my life is made easy by NixOS. Same idea behind learning Haskell. Huge personal gains.
        colordrops 4y ago
        I'd say it's more like vim. Steep initial learning curve for a few months then it becomes pretty easy and indespensible. Perhaps Haskell is like this but I never got past the curve.
- metadat 4y ago
  Does nix use underneath, or something else?
  - metadat 4y ago
    * use PodMan, docker, or?
    - alexghr 4y ago
      NixOS's virtualisation module can use either Docker or Podman and if Podman is enabled it has a Docker compatiblity mode (via `virtualisation.podman.dockerCompat = true`) that puts symlinks in all the right places (`docker` binary, `docker.sock`) so that software doesn't even know it's not running vanilla Docker :)
      - mrtesthah 4y ago
        Really not seeing the point of using docker-anything on NixOS here. Shouldn’t Nix already be able to isolate dependency trees from each other? Why would you want to duplicate all those files yet again in a docker image?
        colordrops 4y ago
        Sounds good in theory but there are a couple reasons to use docker. The first is that there are endless packages already prepared for docker that you'd have to manually set up on any OS, let alone Nix. For instance "itzg/minecraft-server". The second is that if you use docker you've got control of where all the stateful volume data sits. I keep it all in one folder for easy backup. The rest of the system is fully managed by nix.
cantagi 4y ago
> Why bother with docker for a home server other than for the fun of it? I do this. Over time you forget how each service was configured, or simply don't care. Adding more and more stuff to a home server increases the complexity and the attack surface more than linearly in the number of services. I run nearly all my home services in docker, and I have a cookie-cutter approach for generating SSL certs and nginx config for SSL termination (not dockerized). Provisioning is automated through ansible, so my machines can be cattle not pets, as far as is possible on 3 raspberry pis.
- dicknuckle 4y ago
  Same, but I haven't started with anything like Ansible yet, only beginning to learn it at work. Running all my services in Docker keeps it all clean because I'm a very messy person when it comes to Linux. Change, change, change, it works, forget about it, it breaks, find something I did years ago tripping me up now, change, change, change, it works, forget about it. With docker every service is contained and nearly separated. I can rip something out and replace it like stacking a new network switch in the rack. Delete the container, delete the image(s) and delete the volume if I want to start over with something completely fresh. I can move everything to a new server by moving bulk hard drives over, restoring docker volumes from backup and cloning docker-compose configs from git. Haven't tried any distributed volume storage yet.
  - sgarland 4y ago
    > Haven't tried any distributed volume storage yet. Having tried Gluster, Ceph/Rook, and Longhorn, I strongly recommend Longhorn. Gluster is kinda clunky to setup but works, albeit with very little built-in observability. Ceph on its own also works but has some fairly intense hardware requirements. Ceph with Rook is a nightmare. Longhorn works great (as long as you use ext4 for the underlying filesystem), has good observability, is easy to install and uninstall, and has lower hardware requirements. Its main drawback is it only supports replication, not erasure coding, which tbf is a large contributor to its ease of use and lower hardware requirements.
    - 4y ago
Karunamon 4y ago
>Why bother with docker for a home server other than for the fun of it? Because it legitimately makes things easier. Your source of truth for how an app was set up is the compose file, and as a result you only need to care about the storage each app uses for its state. This makes upgrades and back ups almost entirely painless and drama free. Deploying the average app the old way feels downright medieval.
goodpoint 4y ago
> Maybe throwing docker into the mix makes it clunkier, though? Correct. It increases the attack surface without adding benefits over light containers like systemd-nspawn or just systemd unit files.
sgarland 4y ago
> Why bother with docker for a home server other than for the fun of it? As others have alluded to, mostly for having everything in code. I went from Docker --> Docker-Compose --> Kubernetes. The latter is 100% overkill, and was mostly done to assist learning. Still, it's very nice to have as close to HA home services as possible (with the exception of a dedicated failover WAN connection, and me needing to manually fire up a generator for power - UPS will last ~15-20 minutes). Scheduling aside, though, yes you could accomplish all of that with systemd and something like keepalived.

colordrops 4y ago

NixOS uses systemd to manage containers. Works great and is hassle free IMO.

na85 4y ago
NixOS seems to make needless complexity a point of pride.
- amarshall 4y ago
  NixOS makes purity and declarative configuration a point of pride. With that comes greater complexity.
- whateveracct 4y ago
  None of the complexity is needless - it all follows from its core principles. Maybe you disagree with those principles. Maybe you disagree with software having hard principles. That's fine. NixOS isn't for you. It's wonderful for me though!
  - bayindirh 4y ago
    The problems solved by NixOS are mostly solved already. NixOS solves them differently, and that's OK, but it's not solving them for the first time.
    - colordrops 4y ago
      I've never been able to restore my entire machine completely from config files to the exact same state reliably. What else has solved this?
      - bayindirh 4y ago
        From top of my head: A- If you want to be able to restore to any point after installing your system: LVM/ZFS/BTRFS snapshots got you covered. B1- If you want to install your system the way you want, you have Kickstart (RedHat family) and Preseed (Debian family). You can provide an installation template to the installers, and they install your system the way you want. You want to get your /etc/ afterwards the installation? Either provide it on a disk, or your local network, or anywhere on the internet. Either integrate it to your Kickstart/Preseed end hooks, or do it after your first boot. B2- If you want something more fancy? Create a FAI installation media which installs the system you want. C- You want to transform an existing Debian system to something you want? You get the dpkg package selection state and set to the target system, apply the state so the system is converted to your own selections. Apply the /etc via git or any way you want. D- Want something more programmatic? Run an Ansible playbook locally (This is how GitLab installs and configures itself during install). E- For fleet installations there are XCAT and network variants of B1, but they are out of scope for personal systems. We use E in our system room. I used B1 for personal systems and B2 to deploy an installation country-wide via USB sticks. I used C in the same project for a small subset of servers. In these cases, all systems are operational in the first boot, starting from a known state. I know a lot of people using A, and nudging me to try/use it. GitLab uses D every time I upgrade it.
        colordrops 4y ago
        Thanks for all the details. "A" can't really be checked into git due to size, and doesn't allow for forward config changes, just rollbacks. Do B1 or B2 allow updates to an existing system? C so far seems the closest to Nix, though it's missing the configuration side. I used D before and frankly Ansible is not great. It is meant to be idempotent but has so many holes that it never really is, and because it's a separate layer from the system itself, the scripts might not work after a system upgrade. With Nix, the config IS the system. E sounds interesting, never heard of it - sounds like you saying it's not suitable for personal use though for some reason.
  - Gordonjcp 4y ago
    What's the selling point, what's wonderful about it?
    - whateveracct 4y ago
      Entire OS configured with code, which can be modular with imports and functions. Want to run a Postgres server? One-liner in your config. Want to advertise yourself over avahi? Same deal. Need custom udev rules? One-liner again. I literally cannot bork my machine. I can always roll back. Useful when messing with low-level stuff like drivers. I have full control and understanding of updates and the exact versions of all the programs I run. I can always read the source of any program I'm running by looking in the nix store. Super easy to package new programs and contribute to nixpkgs. Super easy to tweak packaging other provided without forking via overlays. I share config across devices in a git repo, so provisioning a new machine is trivial. I got a desktop and I basically imported a bunch of common config along with like 10 lines of config specific to the desktop.
      - sgarland 4y ago
        > I literally cannot bork my machine. I can always roll back. So use a templated VM, or a filesystem with easy snapshotting like ZFS or BTRFS. The former also allows for easy provisioning of new machines, and doesn't lock you down to a single OS.
        whateveracct 4y ago
        I never said NixOS uniquely solves that. And that doesn't have all the other benefits. Also it's a worse way to handle state and rollbacks. Sledgehammer for a thumbtack. I already spent the time to learn the hard stuff. So now my life is made easy by NixOS. Same idea behind learning Haskell. Huge personal gains.
        colordrops 4y ago
        I'd say it's more like vim. Steep initial learning curve for a few months then it becomes pretty easy and indespensible. Perhaps Haskell is like this but I never got past the curve.
metadat 4y ago
Does nix use underneath, or something else?
- metadat 4y ago
  * use PodMan, docker, or?
  - alexghr 4y ago
    NixOS's virtualisation module can use either Docker or Podman and if Podman is enabled it has a Docker compatiblity mode (via `virtualisation.podman.dockerCompat = true`) that puts symlinks in all the right places (`docker` binary, `docker.sock`) so that software doesn't even know it's not running vanilla Docker :)
    - mrtesthah 4y ago
      Really not seeing the point of using docker-anything on NixOS here. Shouldn’t Nix already be able to isolate dependency trees from each other? Why would you want to duplicate all those files yet again in a docker image?
      - colordrops 4y ago
        Sounds good in theory but there are a couple reasons to use docker. The first is that there are endless packages already prepared for docker that you'd have to manually set up on any OS, let alone Nix. For instance "itzg/minecraft-server". The second is that if you use docker you've got control of where all the stateful volume data sits. I keep it all in one folder for easy backup. The rest of the system is fully managed by nix.

cantagi 4y ago

> Why bother with docker for a home server other than for the fun of it? I do this. Over time you forget how each service was configured, or simply don't care. Adding more and more stuff to a home server increases the complexity and the attack surface more than linearly in the number of services. I run nearly all my home services in docker, and I have a cookie-cutter approach for generating SSL certs and nginx config for SSL termination (not dockerized). Provisioning is automated through ansible, so my machines can be cattle not pets, as far as is possible on 3 raspberry pis.

dicknuckle 4y ago
Same, but I haven't started with anything like Ansible yet, only beginning to learn it at work. Running all my services in Docker keeps it all clean because I'm a very messy person when it comes to Linux. Change, change, change, it works, forget about it, it breaks, find something I did years ago tripping me up now, change, change, change, it works, forget about it. With docker every service is contained and nearly separated. I can rip something out and replace it like stacking a new network switch in the rack. Delete the container, delete the image(s) and delete the volume if I want to start over with something completely fresh. I can move everything to a new server by moving bulk hard drives over, restoring docker volumes from backup and cloning docker-compose configs from git. Haven't tried any distributed volume storage yet.
- sgarland 4y ago
  > Haven't tried any distributed volume storage yet. Having tried Gluster, Ceph/Rook, and Longhorn, I strongly recommend Longhorn. Gluster is kinda clunky to setup but works, albeit with very little built-in observability. Ceph on its own also works but has some fairly intense hardware requirements. Ceph with Rook is a nightmare. Longhorn works great (as long as you use ext4 for the underlying filesystem), has good observability, is easy to install and uninstall, and has lower hardware requirements. Its main drawback is it only supports replication, not erasure coding, which tbf is a large contributor to its ease of use and lower hardware requirements.
  - 4y ago

Karunamon 4y ago

>Why bother with docker for a home server other than for the fun of it? Because it legitimately makes things easier. Your source of truth for how an app was set up is the compose file, and as a result you only need to care about the storage each app uses for its state. This makes upgrades and back ups almost entirely painless and drama free. Deploying the average app the old way feels downright medieval.

goodpoint 4y ago

> Maybe throwing docker into the mix makes it clunkier, though? Correct. It increases the attack surface without adding benefits over light containers like systemd-nspawn or just systemd unit files.

sgarland 4y ago

> Why bother with docker for a home server other than for the fun of it? As others have alluded to, mostly for having everything in code. I went from Docker --> Docker-Compose --> Kubernetes. The latter is 100% overkill, and was mostly done to assist learning. Still, it's very nice to have as close to HA home services as possible (with the exception of a dedicated failover WAN connection, and me needing to manually fire up a generator for power - UPS will last ~15-20 minutes). Scheduling aside, though, yes you could accomplish all of that with systemd and something like keepalived.