nixos/omnom: init module

[eljamm]

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[xanderio]

We do we have this option and the settings.app.debug option

[eljamm]

That does seem a bit redundant. What do you think about keeping cfg.debug and removing cfg.settings.app.debug as the former is easier to set?

[xanderio]

What use-case is there for running the service without DynamicUser?

[eljamm]

Currently, you can't register users from the command line if the service is running as a DynamicUser. This is because the Omnom CLI tool runs as the user that starts it and it requires that all the files it needs are in its CWD.

As such, you'd need to cd into dataDir and run the command, but normal users/groups can't access the DynamicUser's work directory.

Another use-case is if you want to run the service as a normal user in your system.

[xanderio]

Currently, you can't register users from the command line if the service is running as a DynamicUser. This is because the Omnom CLI tool runs as the user that starts it and it requires that all the files it needs are in its CWD.

In that case we should create a wrapper script that changes the user and set the CWD to the dataDir. See the occ wrapper in nextcloud module for example.

Another use-case is if you want to run the service as a normal user in your system.

As this disables some security features that systemd provides when using DynamicUser I would personally recommend against it.

[eljamm]

In that case we should create a wrapper script that changes the user and set the CWD to the dataDir. See the occ wrapper in nextcloud module for example.

This is a great idea, but even with this, I wasn't able to create users from the command line as a DynamicUser, as it can't cd there (which I even tried to do with systemd-run).

I think that it'd probably be better to run the service non-dynamically for now until the program doesn't need to run from the CWD anymore. What do you think?

[xanderio]

Could you please move this into an option, this makes this default show option in the documentation.

[eljamm]

It was originally an option, but I removed it because fs is currently the only variant for the storage type, so I don't think it's that useful for users.

[eljamm]

Should I squash the commits?

[pluiedev]

Yes please :)

[xanderio]

I hope I don't seam to picky :)

One thing that currently completely missing from the module is handling the SMTP password, this will probably require some preStart config patching. Have a look at the wg-access-server module I've done something like that there.

[xanderio]

We don't need to link the config into /etc we can just pass the store path directly.

By placing this in the let in at the top, where settingsFormat is defined.

configFile = settingsFormat.generate "omnom-config.yml" cfg.settings; 

And then replacing this line with --config ${configFile}

[eljamm]

In my opinion having the config in /etc makes it easier for the users to find and read, without having to hunt down the generated config.

[eljamm]

One thing that currently completely missing from the module is handling the SMTP password, this will probably require some preStart config patching. Have a look at the wg-access-server module I've done something like that there.

I'll probably have a look at this tomorrow, thanks!

[eljamm]

These are the main changes from the recent squash:

• Remove debug option and use settings.app.debug instead.
• Add secretsFile option and handle starting service with secrets.
• Add settings.smtp and settings.storage.type settings.
• Assert that settings.smtp.{username,password} are set in secretsFile.
• Assert that settings.storage.root is in dataDir.

Please let me know if there is anything else that should be improved :)

[xanderio]

Think this is going to be the final review round :)

[fricklerhandwerk]

Thanks everyone for your help and patience! ❤️

[misuzu]

This probably deserves a release notes entry