spksrc
spksrc copied to clipboard
SynoCommunity
rutorrent: DSM7 support + fix torrent creation wizard
Description
Having rutorrent DSM7 ready + fix cryptic php error when trying to create torrent file via wizard
Fixes https://github.com/SynoCommunity/spksrc/issues/5288
Checklist
- [x] Build rule
all-supportedcompleted successfully - [x] New installation of package completed successfully
- [x] Package upgrade completed successfully (Manually install the package again)
- [x] Package functionality was tested
- ~~[ ] Any needed documentation is updated/created~~
Type of change
- [x] Package update
- [x] Bugfix
@smaarn this is awesome, thnx for your assistance on this, really much appreciated.
A few things for considerations:
- the 2x services startup can now be handled within
service-setup.sh.delugeis a good example https://github.com/SynoCommunity/spksrc/blob/master/spk/deluge/src/service-setup.sh rutorrent4.0-beta3 is now available, perhaps we can build around that and align with its release (or not)?- Edit: one more item for consideration, usage of the same directory structure as deluge and others with completed, incomplete and watch sub-directories.
Let me know if/how I can provide assistance.
@th0ma7 will be having a look at the deluge folder conventions to see if I can match it easily with the defaults.
Regarding your "2x" services startup I'm not sure what you mean but will be having a look at how it's done in deluge.
The rutorrent 4.0 migration is definitely something we should be doing asap but I will be, for now, focusing on having the DSM 7 installation working and operational before diving into 4.0 migration (since their documentation on what was "changed" is pretty scarce I would tend to favor a conservative approach).
Regarding your "2x" services startup I'm not sure what you mean but will be having a look at how it's done in deluge.
I revisited this and you're right, there isn't "two" daemons but rather:
- uses the default synology web server (where we could provide something else but is it worth it?)
- calls a
screenand invokerutorrent. That's done from a side script calledrtorrent-daemon
So there really is only one daemon and it's call could be integrated into the service-setup.sh script instead of being left aside which would simplify maintenance later on.
BTW, if you want to play with the screen session, first identify it:
$ sudo su -s /bin/bash sc-rutorrent -c 'screen -ls'
Password:
There is a screen on:
22652..th0ma7-nas (Detached)
1 Socket in /tmp/uscreens/S-sc-rutorrent.
Then attach to it:
$ sudo su -s /bin/bash sc-rutorrent -c 'screen -x'
To get help once connected use CTRL-a + h and to disconnect CTRL-a + d
Package tested manually under DSM 7: both install and upgrade works fine.
The open point is about DSM 6 not being broken (don't have a DSM 6 around so ... :/ ). Don't see why it would but then I changed a few things regarding the upgrade process which may have some unforeseen impacts.
Will be following up on this in the coming days.
This is awesome work! I still have a dsm6 so I'll test it over the coming days. Again, great work and long overdue!
I propose to remove the configuration of the port range from the wizards. As long as the firewall ports (in *.sc file or resources) are not adjusted to the ports from the wizard at installation time, it will not be possible to use these ports with activated firewall.
I propose to remove the configuration of the port range from the wizards. As long as the firewall ports (in *.sc file or resources) are not adjusted to the ports from the wizard at installation time, it will not be possible to use these ports with activated firewall.
I would even add that altering the file configuration wouldn't make it work natively (meaning we would need to ensure that upon file configuration changes the firewall settings are updated... which could be a terrible thing to implement and do).
Doing that would require actually adding a rutorrent documentation section to be fair.
@smaarn upgrading from DSM6 failed. Overall the logs looks ok rutorrent-DSM6-upgrade.txt like it failed silently?
Looking further, it actually fails at fixing permissions somewhere (/var/packages/rutorrent/var/rutorrent_install.log) :
Fixing shared folder rights for /volume1/@appstore/rutorrent/tmp
(synoacltool.c, 455)Unknown error
Fixing shared folder access for everyone
ACL version: 1
Archive: has_ACL,is_support_ACL
Owner: [sc-rutorrent(user)]
---------------------
[0] everyone::allow:r-x----------:fd-- (level:0)
EDIT: Although excellent news, it works really well with a fresh install! woot! so just needing to figure out what's wrong with the update.
EDIT (additional findings) - /var/log/messages shows the following at installation time:
2022-11-13T14:13:17-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_2_check[6313]: pkgtool.cpp:3136 Package deluge stops but service pkgctl-deluge start
2022-11-13T14:13:22-05:00 th0ma7-nas php: Signature file not found in archive.
2022-11-13T14:13:24-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[6313]: pkgtool.cpp:3136 Package deluge stops but service pkgctl-deluge start
2022-11-13T14:13:38-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[9879]: resource_api.cpp:289 Release service-cfg for rutorrent when 0x0002 (done)
2022-11-13T14:13:39-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[9909]: resource_api.cpp:289 Release data-share for rutorrent when 0x0002 (done)
2022-11-13T14:13:39-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[9909]: resource_api.cpp:289 Release data-share for rutorrent when 0x0002 (done)
2022-11-13T14:13:39-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[9909]: resource_api.cpp:289 Release data-share for rutorrent when 0x0002 (done)
2022-11-13T14:13:40-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install: SYSTEM: Last message 'resource_api.cpp:289' repeated 2 times, suppressed by syslog-ng on th0ma7-nas
2022-11-13T14:13:40-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[9984]: resource_api.cpp:190 Acquire data-share for rutorrent when 0x0002 (done)
2022-11-13T14:13:42-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[10500]: resource_api.cpp:190 Acquire service-cfg for rutorrent when 0x0002 (done)
2022-11-13T14:13:42-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[10500]: resource_api.cpp:190 Acquire data-share for rutorrent when 0x0002 (fail)
2022-11-13T14:13:42-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[6313]: pkginstall.cpp:1221 Failed to acquire resource after install rutorrent [0xD900 manager.cpp:204]
2022-11-13T14:14:55-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[6313]: pkginstall.cpp:295 Failed to repair package rutorrent, status: 277
/var/log/synopkg.log :
2022/11/13 14:11:26 upgrade rutorrent 3.10-13 Begin preupgrade
2022/11/13 14:11:28 upgrade rutorrent 3.10-13 End preupgrade ret=[0]
2022/11/13 14:11:28 upgrade rutorrent 3.10-13 Begin preuninst
2022/11/13 14:11:28 upgrade rutorrent 3.10-13 End preuninst ret=[0]
2022/11/13 14:11:28 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /volume1/@appstore/rutorrent
2022/11/13 14:11:29 upgrade rutorrent 3.10-13 End /bin/rm -rf /volume1/@appstore/rutorrent ret=[0]
2022/11/13 14:11:29 upgrade rutorrent 3.10-13 Begin postuninst
2022/11/13 14:11:29 upgrade rutorrent 3.10-13 End postuninst ret=[0]
2022/11/13 14:11:30 upgrade rutorrent: Uninstall 3.10-13 successfully
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 Begin preinst
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 End preinst ret=[0]
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /volume1/@appstore/rutorrent
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 End /bin/rm -rf /volume1/@appstore/rutorrent ret=[0]
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 Begin /bin/mv -f /volume1/@tmp/pkginstall/package /volume1/@appstore/rutorrent
2022/11/13 14:11:30 upgrade rutorrent 3.10-13 End /bin/mv -f /volume1/@tmp/pkginstall/package /volume1/@appstore/rutorrent ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/mkdir -p /var/packages/rutorrent
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/mkdir -p /var/packages/rutorrent ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/mv -f /volume1/@tmp/pkginstall/INFO /var/packages/rutorrent/INFO
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/mv -f /volume1/@tmp/pkginstall/INFO /var/packages/rutorrent/INFO ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /var/packages/rutorrent/scripts
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/rm -rf /var/packages/rutorrent/scripts ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/mv -f /volume1/@tmp/pkginstall/scripts /var/packages/rutorrent/scripts
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/mv -f /volume1/@tmp/pkginstall/scripts /var/packages/rutorrent/scripts ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /var/packages/rutorrent/WIZARD_UIFILES
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/rm -rf /var/packages/rutorrent/WIZARD_UIFILES ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/mv -f /volume1/@tmp/pkginstall/WIZARD_UIFILES /var/packages/rutorrent/WIZARD_UIFILES
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/mv -f /volume1/@tmp/pkginstall/WIZARD_UIFILES /var/packages/rutorrent/WIZARD_UIFILES ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /var/packages/rutorrent/conf
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/rm -rf /var/packages/rutorrent/conf ret=[0]
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 Begin /bin/mv -f /volume1/@tmp/pkginstall/conf /var/packages/rutorrent/conf
2022/11/13 14:11:31 upgrade rutorrent 3.10-13 End /bin/mv -f /volume1/@tmp/pkginstall/conf /var/packages/rutorrent/conf ret=[0]
2022/11/13 14:11:33 upgrade rutorrent 3.10-13 Begin postinst
2022/11/13 14:12:46 upgrade rutorrent 3.10-13 End postinst ret=[0]
2022/11/13 14:12:46 upgrade rutorrent 3.10-13 Begin postupgrade
2022/11/13 14:12:48 upgrade rutorrent 3.10-13 End postupgrade ret=[0]
2022/11/13 14:12:48 upgrade rutorrent from 3.10-13 to 3.10-13 failed
2022/11/13 14:12:48 upgrade rutorrent 3.10-13 Begin /bin/rm -rf /volume1/@tmp/pkginstall
2022/11/13 14:12:48 upgrade rutorrent 3.10-13 End /bin/rm -rf /volume1/@tmp/pkginstall ret=[0]
Recap, success so far:
- clean install works great!
- can download/upload, overall it looks good
- all plugins looks like working all right
- kudos, kudos, kudos!
issues found so far:
- upgrade from earlier version on DSM6 fails
- missing geoIP plugin? It's actually there but it is missing the flag in the
Peerstorrent sub-tab. - max queue of 1 currently (e.g. only download 1x torrent at a time). I believe to solve this we have to set
max_downloads_divandmax_uploads_divto0. - Listening Port: ports are set by default to
6881-6999. I noticed under it the checked option:Randomize port each time rTorrent starts. Hopefully the randomization is being done into the port range? Also the port range is quite big, but that may be ok, duno.
issues found so far:
upgrade from earlier version on DSM6 fails
Need to fix the handling of former wizard variables.
missing geoIP plugin? It's actually there but it is missing the flag in the Peers torrent sub-tab.
... Need to check.
max queue of 1 currently (e.g. only download 1x torrent at a time). I believe to solve this we have to set max_downloads_div and max_uploads_div to 0.
Can change the default but I believe this was already the case before.
Listening Port: ports are set by default to 6881-6999. I noticed under it the checked option: Randomize port each time rTorrent starts. Hopefully the randomization is being done into the port range? Also the port range is quite big, but that may be ok, duno.
It's indeed randomized within the specified range. Not too sure about the range size TBH.
Ok so some news:
- DSM 6 upgrade actually highlighted an unexpected issue: the reload_inst_variables doesn't seem to work as expected => fix proposal included in this MR
- I reworked the wizard mechanism to use shell generating wizards (to avoid all those JSON hanging around and to remain as much as possible compliant with standard DSM mechanisms) which allows for handling older versions' upgrade
- Remove the possibility in the wizard to customize the port range
With regards to the proposed folder structures I actually wonder if it's really worth having a watch directory enforced by default and worrying about concurrent application usages. I would propose instead to provide with a checkbox "use watch folder" and have the default being the proposed convention (e.g. ./watch under the download directory).
(flagging as draft since I did a few rework on the installation / upgrade procedure, still need to retest everything)
@hgy59 : removed the port customization feature @th0ma7 : I have made several changes which should enable the upgrade from DSM 6
There are two open points:
- The folders' separation logics
- 4.0 upgrade
It turns out that
- Implementing the idea with the checkbox for the watch folder logic was actually... not feasible (the javascript framework doesn't allow me to do this it seems)
- The 4.0 upgrade doesn't work as is (separated MR for that)
I will try to find some time to work on the folders' separation logic and 4.0 upgrade within the coming weeks.
As is, though (once the DSM 6 update scenario is validated), I believe it should be worth merging it. WDYT ?
At first glance things look great. But there seems to be a few corner-case to be dealth with. Although I agree, 4.0 can wait for a subsequent release.
I tested the upgrade on DSM6. Note that I uninstalled completely then reinstalled from our repo to have a clean installation. Surprisingly I ended-up having the following error in the interface (although no error in the instlallation log):
[18.12.2022 16:31:02] _cloudflare: Plugin will not work. Webserver user can't access external program (python).
And trying to download archlinux didn't worked out... (stagnated at 0%) just weird.
Anyhow, afterward I've applied your update over it and sadly it failed. What is weird is that there isn't any errors in the installation log file.
Looking a bit further I noticed the following in the /var/log/messages
2022-12-18T16:28:52-05:00 th0ma7-nas synoscgi_SYNO.Core.Package_2_list[16388]: pollingtask.cpp:506 PollingTask: unable to stop daemon when reloading
2022-12-18T16:28:52-05:00 th0ma7-nas synoscgi_SYNO.Core.Package_2_list[16388]: list.cpp:329 SYNO.Core.Package.list rollback to direct call
2022-12-18T16:30:27-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[24745]: resource_api.cpp:190 Acquire service-cfg for rutorrent when 0x0001 (done)
2022-12-18T16:30:37-05:00 th0ma7-nas synoacltool: synoacl_delete.c:43 failed to get acl of '/volume1/@appstore/rutorrent/tmp', errno=[8100]
2022-12-18T16:30:38-05:00 th0ma7-nas synoacltool: synoacl_delete.c:43 failed to get acl of '/var/services/web/rutorrent/share', errno=[8100]
2022-12-18T16:30:43-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Control_1_start[27182]: resource_api.cpp:190 Acquire php56 for rutorrent when 0x0001 (done)
2022-12-18T16:37:26-05:00 th0ma7-nas synoscgi_SYNO.Core.Package_2_list[9412]: list.cpp:329 SYNO.Core.Package.list rollback to direct call
2022-12-18T16:37:32-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_upload[10658]: process.cpp:236 Failed to run /volume1/@tmp/jiZ6Ci/WIZARD_UIFILES/upgrade_uifile_fre.sh, ret=[-1], Permission denied
2022-12-18T16:37:32-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_upload[10594]: pkgtool.cpp:1835 Failed to run /volume1/@tmp/jiZ6Ci/WIZARD_UIFILES/upgrade_uifile_fre.sh for rutorrent
2022-12-18T16:37:32-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_upload[10660]: process.cpp:236 Failed to run /volume1/@tmp/jiZ6Ci/WIZARD_UIFILES/upgrade_uifile.sh, ret=[-1], Permission denied
2022-12-18T16:37:32-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_upload[10594]: pkgtool.cpp:1835 Failed to run /volume1/@tmp/jiZ6Ci/WIZARD_UIFILES/upgrade_uifile.sh for rutorrent
2022-12-18T16:37:33-05:00 th0ma7-nas php: Signature file not found in archive.
2022-12-18T16:37:43-05:00 th0ma7-nas php: Signature file not found in archive.
2022-12-18T16:37:55-05:00 th0ma7-nas php: SYSTEM: Last message 'Signature file not f' repeated 1 times, suppressed by syslog-ng on th0ma7-nas
2022-12-18T16:37:55-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[14832]: resource_api.cpp:289 Release php56 for rutorrent when 0x0002 (done)
2022-12-18T16:38:01-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[15473]: resource_api.cpp:289 Release service-cfg for rutorrent when 0x0002 (done)
2022-12-18T16:38:03-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[15741]: resource_api.cpp:190 Acquire data-share for rutorrent when 0x0002 (done)
2022-12-18T16:38:06-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[15872]: resource_api.cpp:190 Acquire service-cfg for rutorrent when 0x0002 (done)
2022-12-18T16:38:06-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[15872]: resource_api.cpp:190 Acquire data-share for rutorrent when 0x0002 (fail)
2022-12-18T16:38:06-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[11234]: pkginstall.cpp:1221 Failed to acquire resource after install rutorrent [0xD900 manager.cpp:204]
2022-12-18T16:38:11-05:00 th0ma7-nas synoscgi_SYNO.Core.Package_2_list[16312]: list.cpp:329 SYNO.Core.Package.list rollback to direct call
So my next attempt was at trying a full removal of existing and installing fresh with your new package. From the get go there is an issue with the download folder... Mine is located elsewhere so presuming all are using that as default won't work. Better off asking the location as we used to. I would suggest re-using the deluge method personnally.
2022/12/18 16:45:58 Adding 'sc-rutorrent' to 'sc-download'
2022/12/18 16:45:58 Group Name: [sc-download]
2022/12/18 16:45:58 Group Type: [AUTH_LOCAL]
2022/12/18 16:45:58 Group ID: [65538]
2022/12/18 16:45:58 Group Members:
2022/12/18 16:45:58 0:[sc-deluge]
2022/12/18 16:45:58 1:[sc-rutorrent]
2022/12/18 16:45:58 Begin service_postinst
2022/12/18 16:46:00 Granting 'sc-download' group permissions on /volume1/downloads
2022/12/18 16:46:00 (synoacltool.c, 140)Path not found
2022/12/18 16:46:00 find: `/volume1/downloads': No such file or directory
2022/12/18 16:46:00 Granting 'sc-download' group basic permissions on /volume1/downloads
2022/12/18 16:46:00 (synoacltool.c, 140)Path not found
2022/12/18 16:46:00 Python 3.10.8
Also later on in the logs the ${folder} isn't interpreted from what I can see:
2022/12/18 16:47:01 find ${folder} -mindepth 1 -type d -exec synoacltool -enforce-inherit {} \;
2022/12/18 16:47:01 End service_postinst
2022/12/18 16:47:01 Granting 'sc-rutorrent' unix ownership on /volume1/@appstore/rutorrent/var
Hopefully I should have a few more cycles over the Holidays to play with this a help you out figuring out where the issue is.
I tested the upgrade on DSM6. Note that I uninstalled completely then reinstalled from our repo to have a clean installation.
~~There is an issue with the uninstallation: it doesn't purge directories (so you'd need to manually delete them :/)~~ (I don't know where that came from TBH)
Last time I saw this error with the _cloudflare plugin not being able to find python it was because of an issue with the installer where the php binary would refuse to run following the switch from a separate daemon bin to using the command variable (PATH tricks basically). I will try reverting that part.
2022-12-18T16:38:06-05:00 th0ma7-nas synoscgi_SYNO.Core.Package.Installation_1_install[15872]: resource_api.cpp:190 Acquire data-share for rutorrent when 0x0002 (fail)
This is bad news as it means that my "trick" for the upgrade didn't manage to actually work with the data-share worker. Do you think you could grab the contents of conf/resource.own file after your upgrade ?
Also later on in the logs the ${folder} isn't interpreted from what I can see:
Actually this was more because I was echoing with resolving, but I can guarantee it was the right command. Will be fixing it though.
What I would propose is to:
- Check how to revert the change about the script (it's causing the installer not to behave properly when configuring binary paths - python among others)
- Check what's the behaviour in DSM 6 for the following installation cases:
- Upgrade from an existing official version, checking the contents of the
conf/resource.own(it will contain the fully resolved installation outcome) - Installing from scratch (after having ensure that the former directories were purged)
So the status of this MR is as follows:
- Reverted the changes on the boot script (could be reworked but I'd first like to have DSM 7 support appropriately validated with DSM 6 still being supported)
- In DSM 7 when upgrading I have the following logs of errors:
2023/02/04 17:53:56 upgrade rutorrent 3.10-13 Begin postinst
2023/02/04 17:53:56 Begin load_variables_from_file
/var/packages/rutorrent/scripts/installer: line 42: /var/packages/rutorrent/etc/installer-variables: Permission denied
2023/02/04 17:53:56 End load_variables_from_file
2023/02/04 17:53:56 Begin initialize_variables
2023/02/04 17:53:56 End initialize_variables
I have no clue what this is caused by, knowing that I have:
root@mallinas2:~# ls -la /var/packages/rutorrent/etc/
total 12
drwxr-xr-x 2 sc-rutorrent synocommunity 4096 Feb 4 18:02 .
drwxr-xr-x 42 root root 4096 Jan 21 12:25 ..
-rw-r--r-- 1 sc-rutorrent synocommunity 48 Feb 4 18:02 installer-variables
What is not in this MR (yet) but won't be added before all the rest is validated since those are not DSM version specifics:
- Rework of the script mechanism
- Rework of the downloaded / incomplete / watch folders structures
Added help label as DSM 6 testing would be really appreciated (switching from an "old school" folder management to using data shared mechanism so... need to be sure it's still sound). I unfortunately don't have a DSM 6 version installed (and don't have the possibility to install one on my NAS)
In DSM 7 when upgrading I have the following logs of errors:
[---snip---]I have no clue what this is caused by, knowing that I have:
I've seen this recently as well and my guess is that it could be a change to the packager. See my experience in this https://github.com/SynoCommunity/spksrc/pull/5592#issuecomment-1416724363.
EDIT: This is now fixed in #5602. Once it is merged the next build of your package should benefit from the fix.
Added help label as DSM 6 testing would be really appreciated (switching from an "old school" folder management to using data shared mechanism so... need to be sure it's still sound). I unfortunately don't have a DSM 6 version installed (and don't have the possibility to install one on my NAS)
I have an instance of DSM6 in a VirtualDSM container on an x64-based NAS. If this platform can work, let me know what specifically you would like assistance testing and I'll see what I can do.
EDIT: So I tried to install this from the rutorrent_x64-6.1_3.10-13.spk and after installing the dependencies, it reports "Failed to install the package". Below are all the logs gathered during this attempt:
/var/log/packages/rutorrent.log /var/log/synopkg.log /var/log/messages
The file /var/packages/rutorrent/var/rtorrent.log didn't really initialise and only had this line:
Installation log: /var/log/packages/rutorrent.log
Hope this helps.
Pertaining to the version 4.x upgrade, it now is officially out: https://github.com/Novik/ruTorrent/releases/tag/v4.0.1-hotfix
To be included or not is a different question. Having rutorrent ported to DSM7 really was the first objective.
@smaarn, I took another look at this on DSM6.2 and the following line reoccurred from the previous log I sent up:
2023/02/04 14:21:40 find: `/volume1/downloads': No such file or directory
This struck me as strange that the downloads directory was not being created. Then I got to thinking that the installer is not prompting to create it. In fact, I didn't remember seeing any wizard prompts. Then I remembered an issue I came across when building Sonarr v4 for DSM6 (https://github.com/SynoCommunity/spksrc/pull/5524#issuecomment-1374689266), specifically, using shell scripts for the wizard files.
Your build seems to have the same issue as shown below:
% ls -all
total 80
drwxr-xr-x@ 6 mreid staff 192 Feb 12 14:44 .
drwx------@ 9 mreid staff 288 Feb 15 17:47 ..
-rw-r--r--@ 1 mreid staff 9560 Feb 12 14:44 install_uifile.sh
-rw-r--r--@ 1 mreid staff 9890 Feb 12 14:44 install_uifile_fre.sh
-rw-r--r--@ 1 mreid staff 6532 Feb 12 14:44 upgrade_uifile.sh
-rw-r--r--@ 1 mreid staff 6862 Feb 12 14:44 upgrade_uifile_fre.sh
Performing a chmod g+x *.sh on the files in the folder and then re-taring the archive I was able to successfully complete an install with DSM6. The successful log is shown here: https://pastebin.com/Ty3J74Hs.
Looking at some recently published packages ~~such as Jellyfin and SABnzbd~~ and examining their package contents I am now convinced that the permission setting for the wizard files is not working. Will need to look into this more and create a PR once the issue is diagnosed.
With your package however there are still some issues. When I have it installed on my VirtualDSM which has the admin address http://dsm62.local:5000/, I see that the URL for rutorrent is shown as http://dsm62.local/rutorrent/. The problem is that when I click the link it redirects to the DSM homepage and just gets me back to my admin address. I don't know if the webserver listening port is configured correctly to serve web clients (or is being overidden by the default webserver for DSM).
EDIT: I just installed the previous v3.10-10 and I realise the same re-direct to the admin page is happening to that version as well. I don't know if this package works in DSM 6.2.
Looking at some recently published packages such as Jellyfin and SABnzbd and examining their package contents I am now convinced that the permission setting for the wizard files is not working. Will need to look into this more and create a PR once the issue is diagnosed.
That could be easily fixed within the framework to enforce a chmod +x on the files prior to generating the .tar archive.
That could be easily fixed within the framework to enforce a chmod +x on the files prior to generating the .tar archive.
The framework already has code for this: https://github.com/SynoCommunity/spksrc/blob/5efc80869342049d9102672bb820639ea0853363/mk/spksrc.spk.mk#L394-L397
Also based on the build log for this Build (x64-6.1), it seems to be going into that section successfully:
===> Create DSM Wizards
/github/workspace/spk/rutorrent/work-x64-6.1/generated-wizards/upgrade_uifile.sh
/github/workspace/spk/rutorrent/work-x64-6.1/generated-wizards/install_uifile.sh
/github/workspace/spk/rutorrent/work-x64-6.1/generated-wizards/upgrade_uifile_fre.sh
/github/workspace/spk/rutorrent/work-x64-6.1/generated-wizards/install_uifile_fre.sh
===> Preparing conf
So either it is being set correctly and then overwritten or something else in the framework has changed. The last change to this section of code was in https://github.com/SynoCommunity/spksrc/pull/5383 but I can't see anything in there which would cause it to break.
Actually I think I may have a clue of where the problem lies:
ifneq ($(wildcard $(DSM_WIZARDS_DIR)/*),)
Depending when it is being processed wildcard can have a different behavior depending of the value being evaluated at that specific time. Also, in this case it doesn't provide any added value as both find commands won't induce any errors anyway if no files are found.
So a "potential" fix is to get rid of the ifneq call entirely and lead the find live a long free life :)
Hmm, the thing is though, when I checked another package before (redis) as in https://github.com/SynoCommunity/spksrc/pull/5524#issuecomment-1374808403, the spksrc checks that are done here results in a different build than the one that is published for download. So to me the builds for publishing are working whereas the builds for testing are not. I couldn't understand why the SPK files generated had different permissions but something is causing the permissions of the wizard files in the signed packages to be different that those of the unsigned ones.
EDIT: This I have checked with various package versions and they are all correct in the signed builds for download going back several versions (before and after the change in #5383).
EDIT: Also my earlier comment on Jellyfin and SABnzbd was incorrect now that I've looked at my previous research. These packages don't have shell script wizards so the permissions would not be executable. The only packages which include shell script wizards include minio, mosquitto, mtproxy, redis and tt-rss.
With your package however there are still some issues. When I have it installed on my VirtualDSM which has the admin address http://dsm62.local:5000/, I see that the URL for rutorrent is shown as http://dsm62.local/rutorrent/. The problem is that when I click the link it redirects to the DSM homepage and just gets me back to my admin address. I don't know if the webserver listening port is configured correctly to serve web clients (or is being overidden by the default webserver for DSM).
@smaarn, well I finally got your package to work in DSM 6.2. See screenshot below...
When I looked more into your Makefile, we have these lines:
https://github.com/SynoCommunity/spksrc/blob/46d1edbe3380f2f7b84fe4d73d04045ce1a7d898/spk/rutorrent/Makefile#L47-L49
However Apache was not being installed. To get your package to work, I had to take the following additional steps:
- Install Web Station
- Install Apache HTTP Server 2.4
- Within Web Station > General Settings, change HTTP back-end server from the default Nginx to Apache HTTP Server 2.4
I don't know if this was an expectation for users to know this but perhaps either the wizard could be updated to inform them or maybe something in the Makefile or conf/resource needs to be updated so that these changes can be automatic.
Alternately, if there can be a configuration to make the web service compatible with Nginx that would be great!
EDIT: According to the developer guide it does not appear that apache-web is a value past DSM 5:
Field Name: install_dep_services
- Description: Before the package is installed or upgraded, these services must be started or enabled by the end-user.
- Value: DSM 4.2 or older: apache-web, mysql, php_disable_safe_exec_dir DSM 4.3: apache-web, mysql, php_disable_safe_exec_dir, ssh DSM 5.0 ~ DSM 5.2: apache-web, php_disable_safe_exec_dir, ssh, pgsql DSM 6.0: ssh, pgsql DSM 7.0: ssh-shell, pgsql, network.target, network-online.target, nginx.service, avahi.service, atalk.service, crond.service, nfsserver.service
Actually I think I may have a clue of where the problem lies:
ifneq ($(wildcard $(DSM_WIZARDS_DIR)/*),)Depending when it is being processed
wildcardcan have a different behavior depending of the value being evaluated at that specific time. Also, in this case it doesn't provide any added value as bothfindcommands won't induce any errors anyway if no files are found.So a "potential" fix is to get rid of the
ifneqcall entirely and lead the find live a long free life :)
Based on some further research you seem to be spot on with this evaluation. I've created a patch for the framework under #5608 which should address this while keeping the original logic.
@smaarn, so I tried your latest package with the updated dependencies and it works out of the box with DSM6 after all. I didn't need to install Apache HTTP Server and it seems to just work once Web Station is installed. See below video of the working install:
https://user-images.githubusercontent.com/943378/219782584-19845c09-b2b8-4437-85d2-b48afe7b42f9.mp4
@smaarn, I'm not familiar with rutorrent but I was wondering if you had any thoughts on the errors seen in the log window:
Bad response from server: (404 [error,getplugins]) Not Found
Also, If I click on the Settings icon in the toolbar I get the following:
JS error: [http://dsm62.local/rutorrent/js/webui.js : 765] TypeError: this.systemInfo is undefined
These appear whether I use Nginx or Apache HTTP Server 2.4. Do you get these in your installation?
@smaarn, I'm not familiar with rutorrent but I was wondering if you had any thoughts on the errors seen in the log window:
Bad response from server: (404 [error,getplugins]) Not FoundAlso, If I click on the Settings icon in the toolbar I get the following:
JS error: [http://dsm62.local/rutorrent/js/webui.js : 765] TypeError: this.systemInfo is undefinedThese appear whether I use Nginx or Apache HTTP Server 2.4. Do you get these in your installation?
I am not getting those. Need to recheck how the rights are set on the plugins directory. Do you think you could check how they are currently set ?
I am not getting those. Need to recheck how the rights are set on the plugins directory. Do you think you could check how they are currently set ?
Sure, let me know what needs to be done. You can also hit me up on Discord for something a bit more real-time.