Modular Services meeting #11 2026-11-06

Attendees: @eveeifyeve, @roberth, @lassulus, @kiara, + 1 guest

Discussion

Conventions and reusable pieces

  • @eveeifyeve: could we standardize conventions with specific files for aspects like portability, modular services and package modules? How do we work with multiple module _classes?
  • @kiara: my recent PRs help in this direction:
  • @kiara: making settings loadable right into NixOS was interesting. Exposing these reusable pieces (config file generation, argv) is good low-hanging fruit.
  • @lassulus: for config file construction this is the right abstraction, and other things can be built on top of it. Reduced scope is good. wrappers targets systemd and command wrappers. Not sure about the rest of the ecosystem. string-value configs instead of files.

systemd integrations

  • @eveeifyeve: we have multiple systemd integrations that do not have matching interfaces. Do we want to standardize those? Should we create a file in lib that has the systemd hardening options?
  • @kiara: we have a lot of examples of systemd hardening to mine, and NixOS already has a hardened profile.
  • @eveeifyeve: to help with hardening, we could expose the service configuration at the system service level as well as the user creation level:
system.services.instance = {
  imports = [ pkgs.ghostunnel.services.default ];
  ghostunnel.serviceConfig = {
    # NixOS options, or the options of another class.
    # For example, NixOS would implement the systemd `serviceConfig` options.
  };
};
  • @eveeifyeve: Package modules are the same as modular services, with the wrapper logic consolidated:
    • config: pkgs.modules.example.configFile
    • definition: pkgs.modules.example.definition
    • systemd unit: pkgs.modules.example.systemdUnit
  • @eveeifyeve: packages would be split up to a /modules directory, inside the folder that contains package.nix. It could hold package configuration, wrapper and modular service modules under passthru.modules.

PR review

Action items

5 Likes