nixos/paperless: Support remote databases

[gefla]

When the database is on another host, unit isolation for the document consumer has to be disabled.

Things done

Using this in a local setup.

• 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.

@leona @SuperSandro2000 @erikarvstedt

[gefla]

@ofborg test paperless

[ambroisie]

Presumably this is incompatible with dabase.createLocally?

[SuperSandro2000]

I won't accept a new option for this.
How about we make it conditional on the local database option added in #359563 ?

[gefla]

I won't accept a new option for this. How about we make it conditional on the local database option added in #359563 ?

Updated. PTAL.

[Atemu]

Am I missing something or does the code not reflect the intention? This only adds hardening when ran locally rather than loosen it when not local.

This also doesn't really make much sense to me; why does it need private networking? Local DB connections are made using unix sockets, not networking, right?

[SuperSandro2000]

This only adds hardening when ran locally rather than loosen it when not local.

If the option is not sec, aka no private networking, then it is open to connect via TCP to other things.

why does it need private networking? Local DB connections are made using unix sockets, not networking, right?

yeah and none local DBs are done via networking.

[Atemu]

If the option is not sec, aka no private networking, then it is open to connect via TCP to other things.

Right but that's not the stated intention. Currently, networking doesn't appear to be restricted at all, so what this really does is add hardening?

It's extremely confusing. The intention should be re-stated and explained in the commit message to remove this confusion.

yeah and none local DBs are done via networking.

The correct hardening to apply would be to block networking entirely then.

[gefla]

If the option is not sec, aka no private networking, then it is open to connect via TCP to other things.

Right but that's not the stated intention. Currently, networking doesn't appear to be restricted at all, so what this really does is add hardening?

No. If you check the default service config that's underlying all unit definitions in the module, it sets PrivateNetwork = true.

It's extremely confusing. The intention should be re-stated and explained in the commit message to remove this confusion.

yeah and none local DBs are done via networking.

The correct hardening to apply would be to block networking entirely then.

That won't work since networking is required at least for the web frontend and the task queue to function. For the scheduler and consumer to work with a remote database, they also need to disable the default PrivateNetwork = true setting inherited from defaultServiceConfig.

I believe the commit message concisely explains that. Of course I'd welcome specific proposals for a better message. Do you have any?

[Atemu]

That clears it up, thanks.

You should put into the commit message a description or explanation of your changes when it's not obvious why they were done in a certain way or what the intention is.
Actually, you should do this even if you think it's obvious because reviewers aswell as future us looking at the history won't necessarily be familiar with how this specific part works, so an explanation is extremely helpful in any case.

What you wrote in reply to me is basically that; you could just reword that slightly.

[gefla]

That clears it up, thanks.

You should put into the commit message a description or explanation of your changes when it's not obvious why they were done in a certain way or what the intention is. Actually, you should do this even if you think it's obvious because reviewers aswell as future us looking at the history won't necessarily be familiar with how this specific part works, so an explanation is extremely helpful in any case.

What you wrote in reply to me is basically that; you could just reword that slightly.

Reworded the commit message accordingly.

[Atemu]

Intention and diff LGTM.