nixos/qbittorrent: copy config instead of symlinking to nix store

[Titaniumtown]

The serverConfig option generates a declarative config file, but the current implementation uses a tmpfiles L+ rule to create a symlink to the config in the nix store. This doesn't work because:

1. qBittorrent reads its config and then writes back to it at runtime
2. The nix store is read-only
3. qBittorrent silently falls back to default/stale settings
   This PR changes the approach to use ExecStartPre to copy the declarative config to the runtime location before qBittorrent starts. With this change, WebUI changes won't persist across service restarts.

I came across this issue when trying to get qBittorrent working again once Vuetorrent was updated. Because of the update, the nix store path changed, breaking the WebUI.

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[sith-lord-vader]

Looks good. Much-needed change

[undefined-landmark]

Thanks for the PR, came across it by coincidence. Pinging @fsnkty as well, as we're listed as maintainers.

First off, I think moving to copy/install instead of symlinking is the right way to go.

Some sidenotes:

Before the initial merge I did some digging and found out that qbit deletes the config before writing, as can be seen in the source code. So when trying to write to the config file it will remove the symlink and than write a new config. That explained why the symlink disappeared and qbit can write to the config. I'm not certain if this behavior is still the same, but I expect it is.

Currently changes made in the webUI also do not persist across reboots, as tested.

So this is what happens at the moment

• symlink gets made
• optionally: user makes changes
• qbit deletes symlink and writes config
  A restart or changes to the declarative config repeat this cycle. So changes do not persist when using a declarative config.

[Titaniumtown]

@undefined-landmark sorry about the late reply. my latest change addressed your comment. Thanks!

[undefined-landmark]

Thanks. In another PR of mine I received feedback that tmpfiles is preferred over install/cp: #483956 (comment).

Same applies here I assume. Probably tmpfiles can simply be changed from symlinking to copying?

[Titaniumtown]

@undefined-landmark I don't know how to use tmpfiles that way, could you provide an example?

[Titaniumtown]

I understand what you are requesting now. I am pushing a fix shortly.

[Titaniumtown]

Take a look now!

[undefined-landmark]

Yes, that's what I had in my mind.

With this change we do duplicate part of configFile = pkgs.writeText "qBittorrent.conf" (gendeepINI cfg.serverConfig);. I believe we don't need to write the config file to the nix store anymore, now that it doesn't get symlinked. So you could adapt that line and restartTriggers = optionals (cfg.serverConfig != { }) [ configFile ];

Any opinions @fsnkty @kira-bruneau?

[Titaniumtown]

@undefined-landmark Pushed!

[undefined-landmark]

Sorry for the frequent back and forth. One last comment. Tests are building fine, almost there!

[undefined-landmark]

We repeat line 159 here. We could create a variable, e.g. configContent, in the let block. That variable can than be used in both this line and in line 159.