解决sops-nix中用户密码文件与持久化存储的启动顺序问题

在使用sops-nix管理NixOS系统加密配置时，用户经常会遇到一个典型问题：如何确保用户密码文件(hashedPasswordFile)在系统启动时能够被正确解密和加载。本文将深入分析这一问题产生的原因，并提供完整的解决方案。

问题背景

当使用sops-nix结合Impermanence/Preservation模块管理加密的用户密码文件时，系统启动过程中会出现以下两种典型问题：

1. 竞态条件：解密密钥的挂载单元与sops-nix服务之间存在执行顺序的不确定性，导致解密失败
2. 循环依赖：systemd检测到挂载单元、Userborn和sops-nix之间存在循环依赖关系，直接删除了相关服务单元

根本原因分析

问题的核心在于系统启动时各个组件之间的依赖关系没有正确建立：

1. 解密密钥存储在持久化分区上，需要先挂载才能访问
2. sops-nix需要在用户创建前解密密码文件
3. 用户家目录可能也需要挂载持久化存储

这种复杂的依赖关系如果没有正确配置，就会导致上述问题。

解决方案

经过深入分析和测试，发现可以通过以下配置解决这个问题：

{ config, lib, ... }:
let
  # 创建systemd服务顺序依赖关系的辅助函数
  mkSystemdOrdering = units: mount:
    lib.concatMapAttrs (name: _: {
      ${name}.unitConfig.RequiresMountsFor = mount;
    }) (lib.genAttrs units (name: name));
in
{
  # sops-nix基础配置
  sops = {
    defaultSopsFormat = "yaml";
    age = {
      keyFile = "/var/lib/secrets/master_host_key";
      generateKey = true;
    };
  };

  # 确保sops服务在相关挂载点可用后执行
  systemd.services = mkSystemdOrdering [
    "sops-install-secrets-for-users"
    "sops-install-secrets"
  ] "/var/lib/secrets";

  # 持久化配置关键点
  preservation.preserveAt.${config.persistence.disk}.directories =
    lib.optional config.persistence.enable [
      {
        directory = "/var/lib/secrets";
        mode = "0600";
        inInitrd = true;  # 关键配置：在initrd阶段挂载
      }
      {
        directory = "/var/lib/nixos";
        mode = "0755";
        inInitrd = true;  # 关键配置：在initrd阶段挂载
      }
    ];
}

关键配置说明

1. initrd阶段挂载：通过设置inInitrd = true，确保相关目录在系统早期阶段就被挂载
2. 服务顺序控制：使用RequiresMountsFor明确指定sops服务需要在特定挂载点可用后才能执行
3. 完整路径覆盖：不仅挂载/var/lib/secrets，还需要挂载/var/lib/nixos以确保所有依赖路径都可用

实施建议

1. 对于使用持久化存储的系统，建议将所有关键路径都在initrd阶段挂载
2. 仔细检查systemd的依赖关系图，确保没有隐藏的循环依赖
3. 在测试环境中验证配置，确保在各种启动条件下都能正常工作

通过以上配置，可以有效解决sops-nix在管理用户密码文件时遇到的启动顺序问题，确保系统安全稳定地启动。