Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spk/rutorrent: fix startup issues #4234

Merged

Conversation

smaarn
Copy link
Contributor

@smaarn smaarn commented Oct 25, 2020

rtorrent upgrade followup: fixed invalid configuration clause for certificate path
Added: missing pgrep commandline tool (used by _tasks plugin)
Added: missing sox commandline tool
Added: php workers configuration (for webstation integration)
Fixed: automatic detection of binaries was broken because of rights on php/test.sh script
Added: if python 3 installation is present also install cloudscraper wheel (required for _cloudflare plugin)
Fixed: former configuration file was always lost upon upgrade
Fixed: .htaccess file defined at root level wasn't backed up
Fixed: permissions were lost on the tmp directory (which needed to be accessible to both web and rutorrent user)

Motivation: Having rutorrent back operational
Linked issues: Should tackle #4227

Checklist

  • Build rule all-supported completed successfully
  • Package upgrade completed successfully
  • New installation of package completed successfully

Pending issues

  • Fix auto-download of new torrent: Download event action failed: Bad return code.
  • Deleting a torrent error: Event 'event.download.erased' failed: Bad return code.
  • Fails to download torrent from https URL: Failed to add torrent. Can't retrieve URL.
  • Screen session msg every 5s Scheduled command failed: watch_directory: Command "load_start" does not exist.
  • Icon missing in DSM menu

Optional

"gzip" => '', // Something like /usr/bin/gzip. If empty, will be found in PATH.
"id" => '', // Something like /usr/bin/id. If empty, will be found in PATH.
"stat" => '', // Something like /usr/bin/stat. If empty, will be found in PATH.
+ "python"=> '', // Something like /usr/bin/python3. If empty, will be found in PATH
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to be able to define explicitely the location where to look for python binary.

"id" => '', // Something like /usr/bin/id. If empty, will be found in PATH.
"stat" => '', // Something like /usr/bin/stat. If empty, will be found in PATH.
+ "python"=> '', // Something like /usr/bin/python3. If empty, will be found in PATH
+ "pgrep" => '', // Something like /usr/bin/pgrep. If empty, will be found in PATH
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is to be able to define explicitely the location where to look for pgrep binary.

@@ -34,7 +41,7 @@ INSTALL_PREFIX = /usr/local/$(SPK_NAME)

POST_STRIP_TARGET = rutorrent_extra_install

BUSYBOX_CONFIG = usrmng daemon nice
BUSYBOX_CONFIG = usrmng daemon nice procutils
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This enables to ship pgrep binary.

@@ -5,6 +5,6 @@ schedule = watch_directory,5,5,load_start=@watch_dir@/*.torrent
max_memory_usage = @max_memory@
log.open_file = "rtorrent.log", "/usr/local/rutorrent/var/rtorrent.log"
log.add_output = "warn", "rtorrent.log"
http_cacert = /etc/ssl/certs/ca-certificates.crt
network.http.cacert = /etc/ssl/certs/ca-certificates.crt
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since rtorrent upgrade this is the new parameter name.

Note: this means that current rutorrent ui won't be able to change that value (it may even break the configuration to be honest but I didn't take the time to check this)

@@ -0,0 +1,8 @@
{
"php56": {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Officially rutorrent seems to be PHP 5.6 only... Didn't bother adding other PHP versions in case it wouldn't work. I'll leave that to some other user who would be interested in testing it ;)

spk/rutorrent/src/installer.sh Outdated Show resolved Hide resolved
spk/rutorrent/src/installer.sh Outdated Show resolved Hide resolved
@@ -147,6 +183,22 @@ postinst ()
chown -R ${USER}:${APACHE_USER} ${INSTALL_DIR}/tmp
chown -R ${APACHE_USER}:${APACHE_USER} ${WEB_DIR}/${PACKAGE}

# Fix rights using ACL (so that test.sh remains executable)
if [ "${BUILDNUMBER}" -ge "7321" ]; then
set_acl_full_permissions "${WEB_DIR}/${PACKAGE}" "user:${USER}"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, so basically the issue here was that rutorrent (running with user http) relies on rtorrent (running with user sc-rutorrent) to execute a file under php/test.sh to detect / valid external programs.
So here we basically need to ensure that (following rutorrent official documentation) web installation directory is accessible to sc-rutorrent with full rights.
And, unfortunately, it seems that for Synology it's either you're going all in on ACLs or you're using standard Linux rights. So I needed to give full acl permissions to sc-rutorrent and web user / groups.

spk/rutorrent/src/installer.sh Outdated Show resolved Hide resolved
@@ -207,24 +259,67 @@ preupgrade ()
rm -fr ${TMP_DIR}/${PACKAGE}
mkdir -p ${TMP_DIR}/${PACKAGE}
mv ${WEB_DIR}/${PACKAGE}/conf/config.php ${TMP_DIR}/${PACKAGE}/
if [ -f "${WEB_DIR}/${PACKAGE}/.htaccess" ]; then
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If someone defines a .htaccess to configure authentication you'd better not lose it when upgrading :)

@smaarn smaarn marked this pull request as draft October 25, 2020 18:02
@smaarn
Copy link
Contributor Author

smaarn commented Oct 25, 2020

Flagging this PR as a draft one since installation from scratch seems to be facing issues with default user configuration (e.g. it prompts for an "Unavailable" message and in the logs I find

synoscgi_SYNO.Core.Package.Installation_1_install[6772]: privilege_api.cpp:343 Failed to set default owner of rutorrent [0x2000 bdb_get.c:40]

@smaarn
Copy link
Contributor Author

smaarn commented Oct 25, 2020

Flagging this PR as a draft one since installation from scratch seems to be facing issues with default user configuration (e.g. it prompts for an "Unavailable" message and in the logs I find

synoscgi_SYNO.Core.Package.Installation_1_install[6772]: privilege_api.cpp:343 Failed to set default owner of rutorrent [0x2000 bdb_get.c:40]

Same error occurring when trying to update.

At this stage I guess I'd better migrate this package to a standard package layout in order to minimize the burden...

Comment on lines 17 to 24
CHANGELOG ="1. Update rutorrent to 3.10<br/>2. Update to rtorrent 0.9.8<br/>3. Update to libtorrent 0.13.8<br/>4. Update to xmlrpc-c 1.51.06<br/>5. Update openssl to 1.1"
CHANGELOG = "1. Update rutorrent to 3.10<br/>
CHANGELOG += 2. Update to rtorrent 0.9.8<br/>
CHANGELOG += 3. Update to libtorrent 0.13.8<br/>
CHANGELOG += 4. Update to xmlrpc-c 1.51.06<br/>
CHANGELOG += 5. Update openssl to 1.1<br/>
CHANGELOG += 6. Embed cloudflare requirements (requires python 3)<br/>
CHANGELOG += 7. Embed pgrep (required by tasks)<br/>
CHANGELOG += 8. Fixed stat<br />"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry but as this changelog targets end-user audience, I would go into so much details - whereas I am pleased to find in it commit message.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed the changelog but I must confess I didn't find anything really satisfactory to put in there (fixing ? :/ )

Comment on lines 49 to 52
set_syno_permissions ()
set_traverse_permissions ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This old beta code has been replaced by generic installer to avoid copy-paste pattern: https://github.com/SynoCommunity/spksrc/blob/master/mk/spksrc.service.installer#L145
Really it is worth move to generic installer:

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I moved to the generic installer.

By doing so I found a tiny bug though in the (very much used) set_syno_permissions function and I find this a little bit unsettling and weird... :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad about the tiny bug I had misunderstood the way it worked. A classic.

@smaarn smaarn force-pushed the fix/rutorrent/add-webstation-support branch from f21c3a1 to e135c17 Compare November 11, 2020 12:01
@th0ma7 th0ma7 mentioned this pull request Nov 11, 2020
55 tasks
@th0ma7 th0ma7 linked an issue Nov 11, 2020 that may be closed by this pull request
9 tasks
@th0ma7
Copy link
Contributor

th0ma7 commented Nov 11, 2020

@smaarn before I hard disk died I had barely looked into converting dsm-control.sh and installer.sh into service-setup.sh. Is that a longer-term goal for this PR?

@smaarn
Copy link
Contributor Author

smaarn commented Nov 11, 2020

@smaarn before I hard disk died I had barely looked into converting dsm-control.sh and installer.sh into service-setup.sh. Is that a longer-term goal for this PR?

Not necessarily but the real concern here was about fixing the overall permission logic issue (I may have identified the issue but it seemed to be a little bit more complicated than this and migrating to using service-setup seemed like a good way to simplify the thing).

@smaarn smaarn force-pushed the fix/rutorrent/add-webstation-support branch from e135c17 to 2a79ce9 Compare November 11, 2020 19:52
@smaarn smaarn marked this pull request as ready for review November 11, 2020 19:52
CHANGELOG += 3. Update to libtorrent 0.13.8<br/>
CHANGELOG += 4. Update to xmlrpc-c 1.51.06<br/>
CHANGELOG += 5. Update openssl to 1.1<br/>
CHANGELOG += 6. Embed missing binary requirements<br/>"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couldn't find a better changelog entry I must confess :|

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such details have a right place in a commit message but means nothing for end-users.
Please mind target audience and simplify to only "Update to version 3.10" (for instance)

# Sets recursive read / execute permissions for ${KEY} on specified directory
# Usage: grant_basic_permissions "${SHARE_FOLDER}" "user:<user>"
# Usage: grant_basic_permissions "${SHARE_FOLDER}" "group:<group>"
grant_basic_permissions ()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I needed this method because I'm in case where I need specific locations to be available for the web user to execute code... And I didn't want the apache user to be allowed to do anything in those directories.

spk/rutorrent/src/service-setup.sh Show resolved Hide resolved
spk/rutorrent/src/service-setup.sh Show resolved Hide resolved
@smaarn
Copy link
Contributor Author

smaarn commented Nov 11, 2020

At this stage:

  • Upgrade works
  • Installation from scratch works
  • No more warnings in the web UI about stuff which wouldn't work

The only thing I would which was weird was that when adding a torrent it would always tell me there was an error when it was actually successfully added - though not started - and visible in the web ui, this may totally be due to misconfiguration on my side to be honest.

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 12, 2020

I'll give it a shot and see if the same behavior hapens on my side.
Also suggesting updating the icon for: https://fleet.linuxserver.io/images/linuxserver_rutorrent.png

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 12, 2020

Compiled and installed like a charm. Really awesome work @smaarn

Issues found so far (haven't yet investigated them):

  1. Icon does not show in the DSM menu
  2. Fails to download from URL - perhaps due to not configuring a monitor directory, but ends-up giving this error msg:
[12.11.2020 08:36:37] https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debian-10.6.0-amd64-DVD-1.iso.torrent - Erreur: le torrent n'a pas pu être ajouté à rTorrent. Impossible de résoudre l'URL.
  1. When using a .torrent file already downloaded, getting this error message in the background screen session:
( 8:37:43) Download event action failed: Bad return code.

But it actually put the torrent to STOP with a success message:

[12.11.2020 08:37:43] debian-10.6.0-amd64-DVD-1.iso.torrent - Torrent ajouté à rTorrent avec succès.

There is some info on this on archlinux wiki:

  1. Also when deleting a torrent it is generating this error:
( 9:01:30) Event 'event.download.erased' failed: Bad return code.

Hints are that this may be caused by a dysfunctional plugin...

@smaarn
Copy link
Contributor Author

smaarn commented Nov 12, 2020

Made a wild attempt by enforcing explicit binary paths... not really sure it will solve anything to be honest but it seemed to be me that curl misconfiguration could actually explain the root cause for failures in fetching files.

@smaarn
Copy link
Contributor Author

smaarn commented Nov 12, 2020

Having a look it seems that there are lots of plugins which seem to be using shell scripts which are supposed to be invoked by rtorrent remotely... and obviously the ACL rights are not appropriately configured... I may have an option here.

@smaarn
Copy link
Contributor Author

smaarn commented Nov 12, 2020

From what I see the "downloading of the torrent from an URL" part is actually not handled by rtorrent but by some internal code of the ruTorrent wrapper.

At the same time there are authorizations which need being fixed so that rutorrent binary has at least appropriate rights on plugin shell executables when relevant.

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 12, 2020

Great work! Event failures looks like solved.
I've added items to track pending known issues and added optional plugin support that was requested in an old issue.

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 13, 2020

Suggesting to add the following into the configuration file: log.execute = "/usr/local/rutorrent/var/rtorrent-execute.log"
Helps confirming proper access to binaries...

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 13, 2020

I have new hints related to the failure to download torrent from URL.
It actually do work with http but not with https.
I first thought this was due to inability to access the /etc/ssl/certs directory from http user but no.

$ sudo su -s /bin/bash sc-rutorrent -c '/usr/local/rutorrent/bin/curl http://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-10.6.0-amd64-netinst.iso.torrent --output /tmp/test1'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 28466  100 28466    0     0  51105      0 --:--:-- --:--:-- --:--:-- 51014
$ sudo su -s /bin/bash sc-rutorrent -c '/usr/local/rutorrent/bin/curl https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-10.6.0-amd64-netinst.iso.torrent --output /tmp/test2'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 28466  100 28466    0     0  27853      0  0:00:01  0:00:01 --:--:-- 27853
$ sudo su -s /bin/bash http -c '/usr/local/rutorrent/bin/curl http://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-10.6.0-amd64-netinst.iso.torrent --output /tmp/test3'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 28466  100 28466    0     0  37259      0 --:--:-- --:--:-- --:--:-- 37210
$ sudo su -s /bin/bash http -c '/usr/local/rutorrent/bin/curl https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debian-10.6.0-amd64-netinst.iso.torrent --output /tmp/test4'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 28466  100 28466    0     0  37259      0 --:--:-- --:--:-- --:--:-- 37210

@smaarn smaarn force-pushed the fix/rutorrent/add-webstation-support branch from 198fbcf to 424b4b1 Compare November 14, 2020 10:42
@smaarn
Copy link
Contributor Author

smaarn commented Nov 14, 2020

Ok I did a rebase with several squashing to avoid the "back and forth".

@th0ma7 I'm afraid the test case isn't exactly that. It's more about the following command (this is a mock code I need to test it to be honest !):

php -r "require_once('/var/services/web/rutorrent/php/Snoopy.class.inc');
      require_once('/var/services/web/rutorrent/php/rtorrent.php');
      set_time_limit(0);
      \$cli = new Snoopy();
      print(@\$cli->fetchComplex('<your torrent url>'));
      print_r(\$cli);"

That's basically what's causing the issue (code can be read from php/add-torrent.php).

EDIT (1 and 2): corrected the command to execute

@smaarn
Copy link
Contributor Author

smaarn commented Nov 14, 2020

Ok I did a rebase with several squashing to avoid the "back and forth".

@th0ma7 I'm afraid the test case isn't exactly that. It's more about the following command (this is a mock code I need to test it to be honest !):

php -c "require_once('/var/services/web/rutorrent/php/Snoopy.class.inc'); \
      $cli = new Snoopy();
      print(@$cli->fetchComplex('<your torrent url>'));
      print('Status :'.$cli->status);
      print('Name  : '.$cli->get_filename());"

That's basically what's causing the issue (code can be read from php/add-torrent.php).

Just re-read the code and it seems to be using curl under the hood. Need to check this.

@smaarn
Copy link
Contributor Author

smaarn commented Nov 14, 2020

Ok I did a rebase with several squashing to avoid the "back and forth".
@th0ma7 I'm afraid the test case isn't exactly that. It's more about the following command (this is a mock code I need to test it to be honest !):

php -c "require_once('/var/services/web/rutorrent/php/Snoopy.class.inc'); \
      $cli = new Snoopy();
      print(@$cli->fetchComplex('<your torrent url>'));
      print('Status :'.$cli->status);
      print('Name  : '.$cli->get_filename());"

That's basically what's causing the issue (code can be read from php/add-torrent.php).

Just re-read the code and it seems to be using curl under the hood. Need to check this.

Ok just found the issue... the temp directory path wasn't ending with a slash... :'(

@smaarn smaarn force-pushed the fix/rutorrent/add-webstation-support branch from 2e9b1c5 to cf35fd5 Compare November 14, 2020 11:48
@smaarn
Copy link
Contributor Author

smaarn commented Nov 22, 2020

More into the "make it clean" phase: use normalized service command workflow + removed custom service privilege thing (which may actually be messing up several thing to be honest). It seems to still work on my end, any better luck on your end ?

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 22, 2020

Working like a charm. I haven't tested all functionalities but at first glance it rocks!
Honestly, you really surpassed yourself on this package that was candidate for potential removal :)

Note that directory permissions are still the same (e.g. 0777) like my previous comment. I've tried updating, uninstall/reinstall, all working great but directory permissions stays odd on my side.

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 24, 2020

Ok, finally have my PC back...
I've cleaned-up the installation log file and re-did uninstall/install (see attached log file)
To me there are 3x lines of interest:

Granting 'sc-rutorrent' unix ownership on /volume1/@appstore/rutorrent
Granting 'sc-rutorrent' unix ownership on /volume1/web/rutorrent
Granting 'sc-rutorrent' unix ownership on /volume1/web/rutorrent/php/test.sh

And the directory permissions are being set as followed:

$ ls -lad /volume1/@appstore/rutorrent /volume1/web/rutorrent /volume1/web/rutorrent/php/test.sh
drwxrwxrwx+ 1 sc-rutorrent rutorrent  66 Nov 23 21:04 /volume1/@appstore/rutorrent
drwxrwxrwx+ 1 sc-rutorrent rutorrent 202 Nov 21 09:54 /volume1/web/rutorrent
-rwxrwxrwx+ 1 sc-rutorrent rutorrent 305 Jun 26 18:41 /volume1/web/rutorrent/php/test.sh

Reading the service-setup.sh script I don't see anything special out there...

For comparison purpose I gave it a shot at installing transmission and all permissions are OK. No 0777 anywhere...

drwxr-xr-x 1 sc-transmission transmission  24 Nov  1 11:34 app
drwxr-xr-x 1 sc-transmission transmission 324 Nov 23 21:17 bin
drwxr-xr-x 1 sc-transmission transmission 916 Nov  1 11:34 lib
drwxr-xr-x 1 sc-transmission transmission  24 Nov  1 11:34 share
drwxr-xr-x 1 sc-transmission transmission 186 Nov 23 21:17 var

How can I run the installer script manually? I could set -x and try to confirm where the issue is.

rutorrent_install.log

@th0ma7
Copy link
Contributor

th0ma7 commented Nov 24, 2020

This is really odd (and its getting late)... In trying to figure out where the issue is I commented out the following lines in hope to un-comment and confirm the change of behavior:

    # Ensure that the rutorrent group still owns the installation directory
  #  set_syno_permissions "${INSTALL_DIR}" "rutorrent"

    # Ensure that the web user has read access to var/.session directory
#    grant_basic_permissions "${INSTALL_DIR}/var/.session" "user:${APACHE_USER}"

    # Ensure that the apache user has full rights on the web directory
#    set_syno_permissions "${WEB_DIR}/${PACKAGE}" "${APACHE_USER}"

    # Ensure that the app directory (which contains DSM Web integration resources)
    # are accessible in read and execute mode to everyone
#    grant_basic_permissions "${INSTALL_DIR}/app" "everyone:\*"

#    grant_basic_permissions "${INSTALL_DIR}/bin" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/lib" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/env" "user:${APACHE_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}" "user:${EFF_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}/php/test.sh" "user:${EFF_USER}"

The directory end-result is the following (note the no ACL + sign):

drwxr-xr-x 1 sc-rutorrent rutorrent   24 Nov 23 21:50 app
drwxr-xr-x 1 sc-rutorrent rutorrent  574 Nov 23 21:50 bin
drwxr-xr-x 1 root         root        32 Nov 23 21:50 env
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 etc
drwxr-xr-x 1 sc-rutorrent rutorrent 4568 Nov 23 21:50 lib
drwxr-xr-x 1 sc-rutorrent rutorrent   12 Nov 23 21:50 sbin
drwxr-xr-x 1 sc-rutorrent rutorrent   46 Nov 23 21:50 share
drwxrwxrwx 1 http         rutorrent    0 Nov 23 21:52 tmp
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 usr
drwxr-xr-x 1 sc-rutorrent rutorrent   88 Nov 23 21:50 var

And in rutorrent everything is working out all right... sigh... I'll sleep on it.

@smaarn
Copy link
Contributor Author

smaarn commented Nov 24, 2020

This is really odd (and its getting late)... In trying to figure out where the issue is I commented out the following lines in hope to un-comment and confirm the change of behavior:

    # Ensure that the rutorrent group still owns the installation directory
  #  set_syno_permissions "${INSTALL_DIR}" "rutorrent"

    # Ensure that the web user has read access to var/.session directory
#    grant_basic_permissions "${INSTALL_DIR}/var/.session" "user:${APACHE_USER}"

    # Ensure that the apache user has full rights on the web directory
#    set_syno_permissions "${WEB_DIR}/${PACKAGE}" "${APACHE_USER}"

    # Ensure that the app directory (which contains DSM Web integration resources)
    # are accessible in read and execute mode to everyone
#    grant_basic_permissions "${INSTALL_DIR}/app" "everyone:\*"

#    grant_basic_permissions "${INSTALL_DIR}/bin" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/lib" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/env" "user:${APACHE_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}" "user:${EFF_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}/php/test.sh" "user:${EFF_USER}"

The directory end-result is the following (note the no ACL + sign):

drwxr-xr-x 1 sc-rutorrent rutorrent   24 Nov 23 21:50 app
drwxr-xr-x 1 sc-rutorrent rutorrent  574 Nov 23 21:50 bin
drwxr-xr-x 1 root         root        32 Nov 23 21:50 env
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 etc
drwxr-xr-x 1 sc-rutorrent rutorrent 4568 Nov 23 21:50 lib
drwxr-xr-x 1 sc-rutorrent rutorrent   12 Nov 23 21:50 sbin
drwxr-xr-x 1 sc-rutorrent rutorrent   46 Nov 23 21:50 share
drwxrwxrwx 1 http         rutorrent    0 Nov 23 21:52 tmp
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 usr
drwxr-xr-x 1 sc-rutorrent rutorrent   88 Nov 23 21:50 var

And in rutorrent everything is working out all right... sigh... I'll sleep on it.

Just confirmed: it works very well without the lines you removed. The only bits which were actually required were the share and tmp. Come to think of it I actually even wonder if the share directory needs also to be fixed...

@smaarn
Copy link
Contributor Author

smaarn commented Nov 24, 2020

This is really odd (and its getting late)... In trying to figure out where the issue is I commented out the following lines in hope to un-comment and confirm the change of behavior:

    # Ensure that the rutorrent group still owns the installation directory
  #  set_syno_permissions "${INSTALL_DIR}" "rutorrent"

    # Ensure that the web user has read access to var/.session directory
#    grant_basic_permissions "${INSTALL_DIR}/var/.session" "user:${APACHE_USER}"

    # Ensure that the apache user has full rights on the web directory
#    set_syno_permissions "${WEB_DIR}/${PACKAGE}" "${APACHE_USER}"

    # Ensure that the app directory (which contains DSM Web integration resources)
    # are accessible in read and execute mode to everyone
#    grant_basic_permissions "${INSTALL_DIR}/app" "everyone:\*"

#    grant_basic_permissions "${INSTALL_DIR}/bin" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/lib" "user:${APACHE_USER}"
#    grant_basic_permissions "${INSTALL_DIR}/env" "user:${APACHE_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}" "user:${EFF_USER}"
#    grant_basic_permissions "${WEB_DIR}/${PACKAGE}/php/test.sh" "user:${EFF_USER}"

The directory end-result is the following (note the no ACL + sign):

drwxr-xr-x 1 sc-rutorrent rutorrent   24 Nov 23 21:50 app
drwxr-xr-x 1 sc-rutorrent rutorrent  574 Nov 23 21:50 bin
drwxr-xr-x 1 root         root        32 Nov 23 21:50 env
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 etc
drwxr-xr-x 1 sc-rutorrent rutorrent 4568 Nov 23 21:50 lib
drwxr-xr-x 1 sc-rutorrent rutorrent   12 Nov 23 21:50 sbin
drwxr-xr-x 1 sc-rutorrent rutorrent   46 Nov 23 21:50 share
drwxrwxrwx 1 http         rutorrent    0 Nov 23 21:52 tmp
drwxr-xr-x 1 sc-rutorrent rutorrent    6 Nov 23 21:50 usr
drwxr-xr-x 1 sc-rutorrent rutorrent   88 Nov 23 21:50 var

And in rutorrent everything is working out all right... sigh... I'll sleep on it.

Just confirmed: it works very well without the lines you removed. The only bits which were actually required were the share and tmp. Come to think of it I actually even wonder if the share directory needs also to be fixed...

Ok so it turns out that share and tmp folders are actually the only folders on which operations are required.

Directory permissions where first set using Linux type
and after superseeded with ACL.  Permissions on http
user was too wide leading the ability to the application
to change ownership to default 0777.  Following changes
only uses ACL and reduce permissions to http user and group
to only what it needs to work.
@th0ma7
Copy link
Contributor

th0ma7 commented Nov 26, 2020

I ended playing a bit with rutorrent tonight and its permission schema.
I found (and hopefully fixed) 3x issues:

  1. The code was using a conjunction of both 1) Linux permission and 2) ACL which ends-up superseding the Linux permissions.
    Thus, even dough permissions where set to 0770 in Linux mode they showed as drwx------+ 1 http rutorrent
  2. user and group where reverted. user is now sc-rutorrent and group http
  3. this one was really tricky and took me a while to discover and understand. It also explain the previous behaviors found earlier in this PR thread...
    After installation files looked like this:
$ ls -lad /var/services/web/rutorrent/share /var/packages/rutorrent/target/tmp
drwx------+ 1 http rutorrent  0 Nov 25 19:47 /var/packages/rutorrent/target/tmp
drwx------+ 1 http rutorrent 60 Jun 26 18:41 /var/services/web/rutorrent/share

$ sudo synoacltool -get /var/services/web/rutorrent/share
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [http(user)] 
--------------------- 
	 [0] user:sc-rutorrent:allow:rwxpdDaARWcC-:fd--  (level:0)
	 [1] user:http:allow:rwxpdDaARWcC-:fd--  (level:0)
	 
$ sudo synoacltool -get /var/packages/rutorrent/target/tmp
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [http(user)] 
--------------------- 
	 [0] user:sc-rutorrent:allow:rwxpdDaARWcC-:fd--  (level:0)
	 [1] user:http:allow:rwxpdDaARWcC-:fd--  (level:0)

After a first torrent download the /var/packages/rutorrent/target/tmp would then switch back to Linux permissions defaulting to 0777 such as:

$ ls -lad /var/services/web/rutorrent/share /var/packages/rutorrent/target/tmp
drwxrwxrwx  1 http rutorrent  0 Nov 25 19:51 /var/packages/rutorrent/target/tmp

$ sudo synoacltool -get /var/packages/rutorrent/target/tmp
(synoacltool.c, 359)It's Linux mode

I've now restrained the ACL of both rutorrent and http to ensure they cannot change ACL. I've also restricted the permissions much further for http while opening up to everyone in equivalent to regular rx like other directories:

$ ls -lad /var/services/web/rutorrent/share /var/packages/rutorrent/target/tmp
drwxrwxr-x+ 1 sc-rutorrent http  0 Nov 25 20:30 /var/packages/rutorrent/target/tmp
drwxrwxr-x+ 1 sc-rutorrent http 60 Jun 26 18:41 /var/services/web/rutorrent/share

$ sudo synoacltool -get /var/services/web/rutorrent/share
Password: 
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [sc-rutorrent(user)] 
--------------------- 
	 [0] everyone::allow:r-x----------:fd--  (level:0)
	 [1] group:http:allow:rwxp-D-------:fd--  (level:0)
	 [2] group:rutorrent:allow:rwxpdDaARWc--:fd--  (level:0)
	 [3] user:sc-rutorrent:allow:rwxpdDaARWc--:fd--  (level:0)
	 [4] user:http:allow:rwxp-D-------:fd--  (level:0)

$ sudo synoacltool -get /var/packages/rutorrent/target/tmp
ACL version: 1 
Archive: has_ACL,is_support_ACL 
Owner: [sc-rutorrent(user)] 
--------------------- 
	 [0] everyone::allow:r-x----------:fd--  (level:0)
	 [1] group:http:allow:rwxp-D-------:fd--  (level:0)
	 [2] group:rutorrent:allow:rwxpdDaARWc--:fd--  (level:0)
	 [3] user:sc-rutorrent:allow:rwxpdDaARWc--:fd--  (level:0)
	 [4] user:http:allow:rwxp-D-------:fd--  (level:0)

Now all looks good, and stays good.

@th0ma7 th0ma7 requested a review from hgy59 November 26, 2020 01:47
@th0ma7 th0ma7 linked an issue Nov 26, 2020 that may be closed by this pull request
@th0ma7
Copy link
Contributor

th0ma7 commented Nov 26, 2020

@smaarn I now believe the package is good for a round of review so I've also asked @hgy59 and @ymartin59 to have a look at it.
And again, you did an amazing job on this, thnx!

Copy link
Contributor

@ymartin59 ymartin59 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the package "setup" script contains support that I expect to be provided by framework "installer" script - and probably because of "exit" statement kept when converting original control script.

CHANGELOG += 3. Update to libtorrent 0.13.8<br/>
CHANGELOG += 4. Update to xmlrpc-c 1.51.06<br/>
CHANGELOG += 5. Update openssl to 1.1<br/>
CHANGELOG += 6. Embed missing binary requirements<br/>"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such details have a right place in a commit message but means nothing for end-users.
Please mind target audience and simplify to only "Update to version 3.10" (for instance)

spk/rutorrent/Makefile Outdated Show resolved Hide resolved
spk/rutorrent/Makefile Outdated Show resolved Hide resolved
spk/rutorrent/src/bin/rutorrent-daemon Outdated Show resolved Hide resolved
spk/rutorrent/src/service-setup.sh Outdated Show resolved Hide resolved
spk/rutorrent/src/service-setup.sh Outdated Show resolved Hide resolved
@th0ma7
Copy link
Contributor

th0ma7 commented Dec 5, 2020

I've reviewed your latest changes and besides the changelog numbering that started at 9. to which I added minimal details about rtorrent & openssl (which was the PR initiator). Currently re-building and will do another round of testing to confirm all is still ok with the recent changes.

@ymartin59 and/or @smaarn is this PR good for a merge (presuming testing is good)? If so I'll take care of merging + pushing up updated packages + closing all relevant pending issues.

@smaarn
Copy link
Contributor Author

smaarn commented Dec 5, 2020

Nothing to add / change or my side. Thanks a lot for the help !

Pre-allocating the download file reduces the overhead when validating
the hash post-download resulting in a better behavior of the NAS
(reduces halt of other processes du to IO wait on large files).
Functionality is compatible with xfs, ext4, btrfs and ocfs2 as such
compatible with Synology filesystems.
@th0ma7
Copy link
Contributor

th0ma7 commented Dec 5, 2020

Nothing to add / change or my side. Thanks a lot for the help !

Thnx, will squash & merge shortly then after I finish testing (added pre-allocation configuration option to reduce NAS overhead when checking large file hash).

@th0ma7 th0ma7 merged commit 3a15395 into SynoCommunity:master Dec 5, 2020
@smaarn smaarn deleted the fix/rutorrent/add-webstation-support branch December 5, 2020 20:35
@defaultsecurity
Copy link

defaultsecurity commented Dec 7, 2020

Thank you for your work and dedication. I installed the package on DS918+. The package runs, but I'm getting errors in rutorrent's log tab.

I used rutorrent.v9.f15047[apollolake-avoton-braswell-broadwell-broadwellnk-bromolow-cedarview-denverton-dockerx64-geminilake-grantley-purley-kvmx64-v1000-x86-x86_64].spk

[07.12.2020 20:25:02] WebUI started.
[07.12.2020 20:25:02] _cloudflare: Plugin will not work. Webserver user can't access external program (python).
[07.12.2020 20:25:02] unpack: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] loginmgr: Some functionality will be unavailable. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] ratio: Some functionality will be unavailable. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] autotools: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] rss: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] datadir: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] scheduler: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] _task: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] xmpp: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] retrackers: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] rutracker_check: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] trafic: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] create: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] history: Plugin will not work. rTorrent user can't access external program (php).
[07.12.2020 20:25:02] screenshots: Plugin will not work. rTorrent user can't access external program (ffmpeg).
[07.12.2020 20:25:02] rss: Some functionality will be unavailable. rTorrent user can't access external program (curl).
[07.12.2020 20:25:02] _task: Plugin will not work. rTorrent user can't access external program (pgrep).
[07.12.2020 20:25:02] spectrogram: Plugin will not work. rTorrent user can't access external program (sox).
[07.12.2020 20:25:02] mediainfo: Plugin will not work. rTorrent user can't access external program (mediainfo).

@th0ma7
Copy link
Contributor

th0ma7 commented Dec 7, 2020

@defaultsecurity Thnx for your feedback.

Can you please create an new issue so we can track that independently from this closed PR?
Also, can you confirm you have php5.6 installed?
And lastly, can you provide info upon was it installation or upgrade of an existing installation?
And does downloading a torrent from URL or uploading a torrent file do work?
(Debian Linux CD image are good and easy to work with: https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment