From 0bd0dcfebefa62fccbd745fdca2cd89b51cb0930 Mon Sep 17 00:00:00 2001 From: Alejandro Soto Date: Thu, 29 Dec 2022 23:41:23 -0600 Subject: sys/nspawn: implement dmz container --- sys/nspawn.nix | 39 ++++++++++++++++++++++++++++++++++++--- 1 file changed, 36 insertions(+), 3 deletions(-) (limited to 'sys/nspawn.nix') diff --git a/sys/nspawn.nix b/sys/nspawn.nix index 528223a..e854e06 100644 --- a/sys/nspawn.nix +++ b/sys/nspawn.nix @@ -1,11 +1,44 @@ -{ lib, config, ... }: +{ lib, config, pkgs, ... }: with lib; let cfg = config.local.nspawn; in { options.local.nspawn.dmz.enable = mkEnableOption "DMZ services in a container"; - config.systemd.nspawn.dmz = mkIf cfg.dmz.enable { - execConfig.PrivateUsers = true; + # Situación con os-release + # + # La idea aquí es poder hacer 'btrfs subvol create /var/lib/machines/foo' y + # dejar que systemd-nspawn y el activation script creen todo lo demás. Esto + # no sirve bien debido a la prueba barata que hace systemd para revisar si el + # árbol parece contener una imagen de sistema operativo. Esta prueba falla en + # dos momentos distintos: + # + # 1. Inmediatamente tras crear un árbol vacío, puesto que os-release no existe. + # La solución naive es 'mkdir rootfs/etc && touch rootfs/etc/os-release'. + # + # 2. Luego de reiniciar el contenedor una vez que NixOS ha preparado /etc, ya que + # systemd espera un archivo regular y no telera el symlink a la store. + # + # Resulta ser que systemd revisa tanto /etc/os-release como /usr/lib/os-release. + # NixOS evidentemente no usa la segunda ruta por ser FHS, así que la duct tape + # final es 'mkdir rootfs/usr/lib && touch rootfs/usr/lib/os-release'. + + config = mkIf cfg.dmz.enable { + systemd.nspawn.dmz = { + execConfig.PrivateUsers = "pick"; + + filesConfig.BindReadOnly = + let + containerModule = { ... }: { + config.boot.isContainer = true; + }; + + system = pkgs.nixos [ ../dmz containerModule ]; + in + [ + "/nix/store" + "${system.toplevel}/init:/sbin/init" + ]; + }; }; } -- cgit v1.2.3