nixos/opnborg: init module

[paepckehh]

Selfhostable OPNSense Appliance Configuration Management & Backup Portal

• already in nixpkgs as package
• now declarative usable as hardened systemd service

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[MarchCraft]

Result of nixpkgs-review pr 351630 run on aarch64-linux 1

1 package blacklisted:

• nixos-install-tools

Hey is this the right way to test this pr?

[patka-123]

Since you are also the upstream developer, you would most likely know best how to properly add a nice test for this module. @paepckehh would mind doing that?

It's by no means a hard requirement to get this merged, but would be cool nonetheless!

[paepckehh]

Since you are also the upstream developer, you would most likely know best how to properly add a nice test for this module. @paepckehh would mind doing that?

It's by no means a hard requirement to get this merged, but would be cool nonetheles

Yes, big fan of unit tests - will pick up that point for my other packages as well!

In this special case the opnborg orchestrator needs a special (open source) firewall appliance (https://github.com/opnsense/) access (via api-key/secret)
to configure itself.

Without counterpart it will just terminate directly.

[paepckehh]

Result of nixpkgs-review pr 351630 run on aarch64-linux 1
1 package blacklisted:

Hey is this the right way to test this pr?

Love nixpkgs-review, really a great tool! Thank you!

[bachp]

Do you need a fixed user for this service? Or can a systemd DynamicUser be used?

I think the main reason for needing a "real" user is if a local user needs to interact with the data directly, outside of the service. If the data is only accessed via the service than DynamicUser is the easiest solution.

[paepckehh]

The backup data from the appliances contain sensitive information.

Having a dedicated user as owner might help develop individual firewall / security concepts if needed.

When this is a blocking point, I can remove the user. Its no hard requirement within the application itself.

[bachp]

It's not about having a separate user. I think that makes sense. It's about creating an explicit user versus letting systemd create one implicitly via DynamicUser.

It's explained in more detail when to use what in https://discourse.nixos.org/t/predefined-uids-gids-when-to-use-them-and-when-not-to-use-them/956/3

[paepckehh]

I may need some guidance how to solve the following conflict:

• The application clearly needs a fixed reliable deterministic gid/guid to store/backup/restore the appliances config data (/var/lib/) that contain secrets (keys,...)

• The appliance (open source firewall / infrastructure / cluster) audience is rather small, so reserve a systemuser deterministic uid/gid below 399 via nixos/modules/misc/ids.nix tight address space might be not justified !?

Maybe my updated commit/proposal (fully verified & end-to-end tested) could be a common ground till rfc0052 makes more official headroom?