I have to copy instead of symlink the php files because it tries to import files from the share directory using a relative path. Using symlink it search relative to the nix store path instead of the ${cfg.home}.

I find better to use symlink and tried to find a way to configure php so it would import files relative to the symlink and not it's target. I didn't find anything, is it possible? Otherwise I might end up patching the relative paths.

Same things for the plugins.

@iv-nn So I came up with a bit of a magical solution using bind mounts. This is probably even more hacky, but I kind of like it because it leaves the /var/lib/rutorrent clear of non-state clutter.

Basiaclly what I do is I set the nginx root = pkgs.rutorrent, so it points to the ruTorrent nix store directly. Then I mount the config.php file on top of it, along with the whitelisted plugins. I also set the $profilePath = '${cfg.home}'; so it points directly to the data dir. I do all of this in the phpfpm service file, so we don't even need the setup service.

Here's the modified phpfpm-rutorrent service:

phpfpm-rutorrent.serviceConfig = {
  ExecStartPre = [
    (pkgs.writeShellScript "setup-rutorrent" ''
      mkdir -p ${cfg.home}/{logs,settings,torrents,users}
      chown -R rutorrent:rutorrent ${cfg.home}/{logs,settings,torrents,users}
      chmod -R 755 ${cfg.home}/{logs,settings,torrents,users}
    '')
  ];
  TemporaryFileSystem = [ "${pkgs.rutorrent}/plugins" ];
  BindReadOnlyPaths = [
    "${rutorrentConfig}:${pkgs.rutorrent}/conf/config.php"
  ] ++ map (p: "${pkgs.rutorrent}/plugins/${p}") cfg.plugins;
};

We don't really need to mount the config file though. We could just replace it in the package with an env var pointing to the real config. Like this

phpConfig = writeText "config.php" ''
  <?php
    return require(getenv('RUTORRENT_CONFIG'));
  ?>
'';

installPhase = ''
  mkdir -p $out/
  cp -r . $out/
  cp -f ${phpConfig} $out/conf/config.php
'';

So I think this is only a problem with plugins.

What do you think? I think if mounting on top of the nix store is ugly, we could also mount the whole app to something like /var/run/rutorrent.

I like the idea of using bind mounts, it's clever. But I think I would rather mount the store files in the dataDir than the other way around.

But seeing your other comment I realise changing $profilePath should be enough.

The plugins dir is the only issue really. With the modified config file you could easily have nginx point directly to /nix/store/... and load the settings through an env var, without any need for any bind mounts or symlinking.

Tbh, I would just skip the whole NixOS plugin management because you can manage plugins in the UI anyway. And it would greatly simplify the whole setup, though at the cost of unnecessary dependencies. Up to you though.

I kept the copy for now because I thought maybe it's an issue to tie the plugin setup to the php-fpm service. Shouldn't there be a way to use this service without setting nginx.enable = true, using some other web server?

Does using copy pose a real problem?

It even allow to use custom plugins, although a better way would be to allow adding them directly through the plugins option.

@iv-nn I think it's fine, forget it. I've seen Nix services do it both ways. Usually using the /nix/store/... as the vhost root when it's simple enough, or by copying/symlinking the application into the state directory in more complex cases. I think with plugins it might be complex enough to keep it as it is. Regardless, nginx.enable = true is not necessary as you can always point your custom vhost root to pkgs.rutorrent.

This is dirty but I need a way to make rtorrent's rpc socket accessible by nginx if exposeInsecureRPC2mount is set. This would get overwritten if someone use mkForce to set it's rtorrent's configText. Maybe I should use some systemd post start hook to chown the socket.

Yes, this is better since rutorrent doesn't actually need the rpc mount if it use one of the rpc or httprpc plugin. Also one could use rtorrent and the rpc mount with some other client (like flood or a mobile client).

Btw, something related to this that I noticed in the documentation. It's recommended to add this line to rtorrent so that rutorrent plugins get initialized on startup. Otherwise the plugins don't start until you open the ruTorrent client manually.

execute2 = {sh,-c,/usr/bin/php /var/www/ruTorrent/php/initplugins.php tom &}

https://github.com/Novik/ruTorrent/wiki/Plugins#starting-plugins-with-rtorrent

Though, this is super annoying for a number of reasons:

1. the user (tom) depends on the http auth username
2. rtorrent now depends on rutorrent running

I'm not really sure how to approach this one. Maybe we could run it ourselves after ruTorrent starts? Though that still leaves the issue with the http auth user name which would have to be part of the config, or detected by a script scanning through the state dir (/var/lib/rutorrent).

I added a way to change rtorrent's socket group and change it if rutorrent is enabled. Should I make a separate PR for the rtorrent's change?

For initplugins.php the simplest way would be to let the user do it, just adding some documentation about it.

Or I could check if the nginx vhost has auth and add the config line directly to rtorrent config if rutorrent is enabled.

I guess this is needed if you manage the filesystem with ruTorrent? So rtorrent still has access to it?

Hm, personally I would run ruTorrent and rtorrent as the same user because otherwise it's gonna create an owner mess on the filesystem. Though I wonder if that would be a good default for NixOS too.

Yes, that would be better.

Actually I was testing this and I didn't notice anything weird going on with file ownership. It seems rutorrent tries to do as much as possible through rtorrent with XMLRPC. So I think it's actually fine to have a separate user as long as they're in each other's groups. Though in that case it would be nice to have the user and group configurable.

Actually, when I was testing this it also requires some additional python libraries that are not in NixOS. Maybe we should just skip this plugin?

This is missing the php package. Either that or we need to add php to every plugin that requires it.

I'm not sure what the issue is here, I don't get any error without it.