[Support] binhex - rTorrentVPN


Recommended Posts

2 minutes ago, mbc0 said:

I am running 6.8.0-rc4 are there still performance issues on that version?

i have no idea, i stay away from release candidates unless i have an urgent issue to resolve with the stable version, as your issue started with rc3 i would suspect that, but its only a guess.

Link to comment

First off thank you for a great docker image..

QQ... I want to add a new tracker file to my autodl setup.  Where should I place the file in order for it to be recognized by autodl?  I was thinking /mnt/user/appdata/binhex-rtorrentvpn/autodl/*****.tracker but that didn't appear to work.

 

Thanks.

  

Link to comment

I've noticed over the past week or so that some of my stuff has loaded into rTorrent, but was not starting or doing anything. I finally figured out that sometimes, upon loading, the Priority is being automatically set to "Don't Download" and/or the Channel is set to "up256" (which also has 0 set for download, thus stalled). 

 

Is there anything that has changed that might cause this? Not sure if those settings come from rTorrent or ruTorrent. I don't remember setting those in my rtorrent.rc file ever (and not even sure you can if they are part of ruTorrent), and even so I haven't edited my .rc file in months but this has suddenly started happening only recently. Going into settings in ruTorrent, my channels I think are still default and the "Default Channel" option is set to "Don't Set" so it shouldn't be automatically selecting any channel, much less up256.

Link to comment
I've noticed over the past week or so that some of my stuff has loaded into rTorrent, but was not starting or doing anything. I finally figured out that sometimes, upon loading, the Priority is being automatically set to "Don't Download" and/or the Channel is set to "up256" (which also has 0 set for download, thus stalled). 
 
Is there anything that has changed that might cause this? Not sure if those settings come from rTorrent or ruTorrent. I don't remember setting those in my rtorrent.rc file ever (and not even sure you can if they are part of ruTorrent), and even so I haven't edited my .rc file in months but this has suddenly started happening only recently. Going into settings in ruTorrent, my channels I think are still default and the "Default Channel" option is set to "Don't Set" so it shouldn't be automatically selecting any channel, much less up256.
No change from me, the only thing I changed in tTorrent.rc was the addition of a commented out maximum size for a file in a torrent, that's it.

Sent from my CLT-L09 using Tapatalk

Link to comment
54 minutes ago, binhex said:

No change from me, the only thing I changed in tTorrent.rc was the addition of a commented out maximum size for a file in a torrent, that's it.

Sent from my CLT-L09 using Tapatalk
 

OK. Is there a way to clear/reset the ruTorrent settings without having to reload the entire container? A conf file(s) or folder(s) that I can just delete and will be recreated with defaults when I restart the container? Seems like maybe a stuck or old setting in there is messing things up.

 

Edit: Actually I do have some RSS saved in ruTorrent so I guess I don't want to delete the entire configuration. 

I see /config/rutorrent/share/settings/throttle.dat file which looks like it maybe relates to the channels. If I delete that will it recreate with defaults upon a restart?

 

Edit2: So I took a closer look at that throttle.dat file.

O:9:"rThrottle":3:{s:4:"hash";s:12:"throttle.dat";s:3:"thr";a:10:{i:0;a:3:{s:2:"up";i:64;s:4:"down";i:0;s:4:"name";s:4:"up32";}i:1;a:3:{s:2:"up";i:128;s:4:"down";i:0;s:4:"name";s:5:"up128";}i:2;a:3:{s:2:"up";i:64;s:4:"down";i:256;s:4:"name";s:11:"up64down256";}i:3;a:3:{s:2:"up";i:128;s:4:"down";i:1024;s:4:"name";s:13:"up128down1024";}i:4;a:3:{s:2:"up";i:256;s:4:"down";i:2048;s:4:"name";s:13:"up256down2048";}i:5;a:3:{s:2:"up";i:0;s:4:"down";i:16;s:4:"name";s:6:"down16";}i:6;a:3:{s:2:"up";i:0;s:4:"down";i:32;s:4:"name";s:6:"down32";}i:7;a:3:{s:2:"up";i:0;s:4:"down";i:64;s:4:"name";s:6:"down64";}i:8;a:3:{s:2:"up";i:0;s:4:"down";i:128;s:4:"name";s:7:"down128";}i:9;a:3:{s:2:"up";i:0;s:4:"down";i:256;s:4:"name";s:7:"down256";}}s:7:"default";i:5;}

Looking at this reminded me that I did play with channels a while back and setup some custom ones in the web GUI. I also played with setting a default channel, which was #5 at the time. I think when I restarted the container they just went back to defaults so I didn't bother with them anymore since they didn't seem to stick. Even though the ruTorrent GUI settings didn't show the above custom channels anymore and didn't seem to be using them either, it seems like it would occasionally use the default channel as #5 lately, which in the default channels is "up256". It looks like it would happen when Medusa was sending torrents/magnets over, maybe because it doesn't use the "admin" user but just a default of some kind via SCGI? Still doesn't explain the "Don't Download" priority being set sometimes, but maybe related somehow.

 

Anyway, I stopped the container, deleted the /config/rutorrent/share/settings/throttle.dat file, and started it up again. It didn't initially recreate the file. I logged into the ruTorrent web GUI as admin and made a change to the channels and then it created a file under /config/rutorrent/share/users/admin/settings/throttle.dat instead. Now that I know how it works I'll probably just delete that file anyway and leave it at defaults as I don't really use channels currently. Here's what that new default (except small change on one channel) file looks like:

O:9:"rThrottle":3:{s:4:"hash";s:12:"throttle.dat";s:3:"thr";a:10:{i:0;a:3:{s:2:"up";i:16;s:4:"down";i:0;s:4:"name";s:4:"up16";}i:1;a:3:{s:2:"up";i:32;s:4:"down";i:0;s:4:"name";s:4:"up32";}i:2;a:3:{s:2:"up";i:64;s:4:"down";i:0;s:4:"name";s:4:"up64";}i:3;a:3:{s:2:"up";i:128;s:4:"down";i:0;s:4:"name";s:5:"up128";}i:4;a:3:{s:2:"up";i:256;s:4:"down";i:1024;s:4:"name";s:5:"up256";}i:5;a:3:{s:2:"up";i:0;s:4:"down";i:16;s:4:"name";s:6:"down16";}i:6;a:3:{s:2:"up";i:0;s:4:"down";i:32;s:4:"name";s:6:"down32";}i:7;a:3:{s:2:"up";i:0;s:4:"down";i:64;s:4:"name";s:6:"down64";}i:8;a:3:{s:2:"up";i:0;s:4:"down";i:128;s:4:"name";s:7:"down128";}i:9;a:3:{s:2:"up";i:0;s:4:"down";i:256;s:4:"name";s:7:"down256";}}s:7:"default";i:0;}

If it continues doing weird stuff, I'll try to update here. Otherwise hopefully this will help somebody else if something similar happens to them.

Edited by deusxanime
research
Link to comment
On 10/22/2019 at 6:35 PM, binhex said:

Hi guys, so historically it has been difficult/impossible to change the listening port for rtorrent programmatically whilst its running, this lead to the only option which is to sigint rtorrent and change the port and then restart the process, this unfortunately can lead to situations where the process does not end nicely and thus rtorrent cannot be restarted.
 

Wind forward in time and this is now possible, however in order to do this we need to supply the credentials the authenticate with rtorrent before we can issues commands. As i don't know what each user has set their rpc2 and web ui passwords to (and i obviously shouldn't know this either!) then the only way for me to do this going forward is to allow the user to define the credentials for rpc2 and web ui as environment variables.
 

So from the next build if you have changed the username and password from the defaults (user admin, password rutorrent) then you will need to add in the following 'variables' :-
 


Key                 Value               Default         Description
RPC2_USER           <your username>     admin           sets the username for RPC2 auth
RPC2_PASS           <your passs>        rutorrent       sets the password for RPC2 auth
ENABLE_WEBUI_AUTH   yes/no              yes             sets web ui authentication for web ui (nginx) - if you are reverse proxying you probably want this set to no, otherwise yes.
WEBUI_USER          <your username>     admin           sets the username for web ui auth
WEBUI_PASS          <your passs>        rutorrent       sets the password for web ui auth

The above will result in a more stable rtorrent/rutorrent experience, whilst allowing us to maintain a working incoming port during all situations, i hope you agree a worthy improvement! (testing was a bitch).

 

Any questions please post them.

 

 

Hi @binhex, sorry that I'm kinda late to the party. The upgrade path wasn't totally smooth for me. I haven't noticed the new parameters, and since they have defaults (and also given that you've changed nginx.conf to read credentials from the new webui_auth file bypassing my custom settings) my container's rutorrent has been exposed to the internet with default credentials for a while.

Luckily I had

ENABLE_RPC2=no

Or it would have also exposed XML RPC over the internet with easily guessable default credentials. I guess I've shared the following article already, but it demonstrates why exposing RPC2 with no password or default credentials is not a good idea: https://www.f5.com/labs/articles/threat-intelligence/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

 

I know that ultimately this is a trade-off between security and convenience but given how many people are using your container I would suggest that you make it as secure as possible by default. I guess that two good ways to handle RPC_USER/RPC_PASS/WEBUI_USER/WEBUI_PASS without making the container vulnerable by default are:

 

1. Remove the mentioned variables. From inside the container you can probably issue XMLRPC commands straight to port 5000 or use a sgci_local socket (bypassing nginx authentication altogether) right? Otherwise, during container startup you can generate random credentials.

2. Keep the variables but fail to start the container if no values are provided. IMO, default credentials are a really bad idea. Of course that a simple docker inspect will reveal the passwords, but I guess that this is not a big issue given that VPN_PASS is already exposed (secrets are a better alternative but it is limited to docker swarm and docker-compose).

 

Cheers

Edited by Cat_Seeder
Link to comment

Im having constant issues with the docker bringing my server to a crawl. Im migrating from qbittorent and it seems like everything I do in rtorrent maxes out my CPU utilization on my server and locks up the server. I've had to force reboot twice already.

 

Simple things like deleting dead torrents that have been removed from trackers or force rechecking files so that I can get everything migrated is causing the server to be at 100% CPU most of the time. Ive never had this problem before installing this docker. 

 

In order to keep this from completely killing my server, I run operations on 5 torrents at a time and even still, I have issues with that.

 

Does anyone know what may be causing this? I'm going to have to disable this docker until I find out why this is happening.

 

 

53552108630b68b4f65c392f0262aede.png

Edited by DazedAndConfused
Link to comment
On 11/10/2019 at 3:43 AM, DazedAndConfused said:

Im having constant issues with the docker bringing my server to a crawl. Im migrating from qbittorent and it seems like everything I do in rtorrent maxes out my CPU utilization on my server and locks up the server. I've had to force reboot twice already.

 

Simple things like deleting dead torrents that have been removed from trackers or force rechecking files so that I can get everything migrated is causing the server to be at 100% CPU most of the time. Ive never had this problem before installing this docker. 

 

In order to keep this from completely killing my server, I run operations on 5 torrents at a time and even still, I have issues with that.

 

Does anyone know what may be causing this? I'm going to have to disable this docker until I find out why this is happening.

 

 

53552108630b68b4f65c392f0262aede.png

That's a weird one, maybe attach to the container and run `top` to understand what processes are using CPU Time. You can also limit the how many CPUs are available to the container with Docker's --cpu option (see https://docs.docker.com/config/containers/resource_constraints/ for further info). I've noticed that rutorrent may get stuck for a while when I delete large (as in 100GB+) torrents with data, other than that I normally seed a few thousand torrents with no issues (and nowhere near 100% CPU usage). 

Link to comment

Can someone give me some advice about how to handle rtorrent with use of the autotools move option? I changed rtorrent.rc with a folder to put new downloads in, and configured autotools to move torrents after they are completed. With the options "add torrent's label in path"  and "add torrent's name to path" enabled. This is working fine, torrents are downloaded to /data/torrents/incoming. And after there are done they get moved to /data/torrents/completed/{label name}/{torrent name}. Just the way i want it to, nice!

However, when i restart the rtorrentvpn docker, it "resets" all the save path's of all the torrents already done. While the data is still in the "completed" folder, rtorrent is looking in the "incomplete" folder and cannot find the data. This causes rtorrent to stop seeding which i do not want.

I already did some search on google and here on the forums, but i'm not yet on the right path to fix this problem. Anyone?

Link to comment

Ok, so i did give it some more try's today, but failed just the same. I really don't know where i'm going wrong here. I am pretty new with unraid and containers. Today i read this topic from page 40 to 72 in hope to get some more information, and i did the following after multiple tries.

- Deleted the container, image and the whole binhex-rtorrentvpn folder inside of appdata.
- Shutdown Docker in Unraid Settings, and started it all again after a minute or so. Just to be sure

- Did not start any other container while doing all of this
- Installed binhex-rtorrentvpn
- Started the container, open settings, only to change autotools. I did not do anything else!
- Downloaded a torrent, first it gets in incomplete, moves to completed once done, great

- Restarted the container trough Unraid Webgui

- And rtorrent again expects the file to be in incomplete, its not there, shows 0,0% and in paused state

Only setting i changed is the network type i guess in container settings. I have a Mullvad vpn setup on my pfSense, which filters some ip's and put them on vpn. But i did also try this whole process described above, and use the normal bridge mode. Also with the same result...

 

Still having the same problem... I added the log, settings, screenshot of rutorrent after the restart. Anyone who has a idea how to solve this?

rTorrent Settings.png

Container Settings.png

Almost forgot, as frustrating as this has been for the last 3-4 hours. A friend who also has a unraid server @ home with rtorrentvpn looked at my config. We were not able to compare the settings exactly this after noon, but he also did not see anything weird, while he is supposed to have the same settings. But again, even "out of the box" i have this problem. The other "rutorrent" plugin is working, but i rather use this one...

supervisord.log

rtorrent.rc

Edited by CellDweller
Almost forgot story...
Link to comment
On 11/3/2019 at 7:20 PM, Cat_Seeder said:

 

Hi @binhex, sorry that I'm kinda late to the party. The upgrade path wasn't totally smooth for me. I haven't noticed the new parameters, and since they have defaults (and also given that you've changed nginx.conf to read credentials from the new webui_auth file bypassing my custom settings) my container's rutorrent has been exposed to the internet with default credentials for a while.

Luckily I had


ENABLE_RPC2=no

Or it would have also exposed XML RPC over the internet with easily guessable default credentials. I guess I've shared the following article already, but it demonstrates why exposing RPC2 with no password or default credentials is not a good idea: https://www.f5.com/labs/articles/threat-intelligence/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

 

I know that ultimately this is a trade-off between security and convenience but given how many people are using your container I would suggest that you make it as secure as possible by default. I guess that two good ways to handle RPC_USER/RPC_PASS/WEBUI_USER/WEBUI_PASS without making the container vulnerable by default are:

 

1. Remove the mentioned variables. From inside the container you can probably issue XMLRPC commands straight to port 5000 or use a sgci_local socket (bypassing nginx authentication altogether) right? Otherwise, during container startup you can generate random credentials.

2. Keep the variables but fail to start the container if no values are provided. IMO, default credentials are a really bad idea. Of course that a simple docker inspect will reveal the passwords, but I guess that this is not a big issue given that VPN_PASS is already exposed (secrets are a better alternative but it is limited to docker swarm and docker-compose).

 

Cheers

 

I agree with removing default credentials. I ended up removing admin manually from my config file.

 

Also the edit to the readme file here: https://github.com/binhex/arch-rtorrentvpn/commit/487dac431e87fc67d8e0106217b20af1cfeba017#diff-04c6e90faac2675aa89e2176d2eec7d8

is confusing as you used <> for variable holders, which are normally inside of markdown code blocks (`), but in this case they are not. To the casual viewer, it looks like there is no username or password when viewing the readme, but in reality it's either the default or custom set creds.  I don't see the default mentioned in the readme either.

Perhaps change usage of <> to [] or more judicious use of code blocks?

Edited by jraid
Link to comment

Edit: I'm an idiot and forgot to download new openvpn configs...

 

 

Attemping to move from PIA to AirVPN but so far am unsuccessful. Any ideas what could be wrong. I changed

 

VPN_PROV to airvpn

Updated VPN_USER and VPN_PASS to the new credentials. Tested this on my local machine and am able to connect.

 

Is there something else I'm needing to change?

 

2019-11-22 13:46:26,534 DEBG 'start-script' stdout output:
Fri Nov 22 13:46:26 2019 WARNING: file 'credentials.conf' is group or others accessible

Fri Nov 22 13:46:26 2019 OpenVPN 2.4.7 [git:makepkg/2b8aec62d5db2c17+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 19 2019
Fri Nov 22 13:46:26 2019 library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10

2019-11-22 13:46:26,535 DEBG 'start-script' stdout output:
[info] OpenVPN restarted
Fri Nov 22 13:46:26 2019 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2019-11-22 13:46:26,535 DEBG 'start-script' stdout output:
Fri Nov 22 13:46:26 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]XXX.XXX.XXX.XXX:1198
Fri Nov 22 13:46:26 2019 UDP link local: (not bound)
Fri Nov 22 13:46:26 2019 UDP link remote: [AF_INET]XXX.XXX.XXX.XXX:1198

2019-11-22 13:46:26,670 DEBG 'start-script' stdout output

 

Edited by Fiala06
Link to comment
1 hour ago, binhex said:

probably cos you exec'd in as user root not user 'nobody', im assuming you have enabled irssi right?.

Ah yeah, that seems to be the problem. 

In order to access the container I do

 

docker exec -it binhex-rtorrentvpn /bin/bash

 

That logs me in as root.

 

How is the normal procedure to access it as nobody?

 

just

 

docker exec -it --user nobody binhex-rtorrentvpn /bin/bash?

 

Edited by Jeffarese
Link to comment

Hi, long time user here:

My container is getting stuck here and isn't coming back up. I've waited about 10 minutes. Any idea?

 

2019-11-28 13:32:55,119 DEBG 'watchdog-script' stdout output:
[info] rTorrent not running

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] Privoxy not running

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] rTorrent incoming port 49160 and VPN incoming port 48349 different, marking for reconfigure

2019-11-28 13:32:55,124 DEBG 'watchdog-script' stdout output:
[info] Removing any rTorrent session lock files left over from the previous run...

2019-11-28 13:32:55,126 DEBG 'watchdog-script' stdout output:
[info] Attempting to start rTorrent...

2019-11-28 13:32:55,127 DEBG 'watchdog-script' stdout output:
Script started, file is /home/nobody/typescript

2019-11-28 13:32:55,144 DEBG 'watchdog-script' stdout output:
Script done, file is /home/nobody/typescript

Link to comment
10 hours ago, kbbeer said:

I'm having a similar issue, trying to configure the autolabel and unpack plugins.  After restarting sometimes the settings are there, other times they are blank.

 

Do these features need to be setup in the config file?


I don't think so. I spend a couple of hours on this. Trying different settings and versions. I was trying to download something, let autotools do it's thing, try a reboot. I saw it failing, and did try again, and again, and again....

This changed last week when i downloaded something, but my girlfriend told me to come eat something. In early'er attempts there would not be more than ten or twenty minutes between the download and reboot. But i was away for a hour or so, did a reboot, and it worked like i should. For some reason i takes ages for rtorrent to update the session file. I did try the "rutorrent" container, that one looked like t was behaving better with this, although i did try that one for like 1 or 2 downloads. So not quite sure...

Decided to just go with it, because it should only reboot on a update, so not as often, most torrents would be for hours of days in rtorrent before an update. I thrown all my torrents (650 torrents, just shy of 12TB) into rtorrent, did a recheck, en hoped to roll with it. For the most part it works awesome. System load is minimal, and uploading goes great. Upload averages on 31TB each day, very nice.

However, i'm having troubles at this moment with sonarr/radarr. It can add torrents, but they "start" with error, without the configured "label", and no "added date". And when downloaded, sometimes they stop, and i cannot get them to start again... So i still have to check this manually en start the downloads them self... Going to investigate in the next couple of days, but i someone has some tips where to start looking, that would be great!

Link to comment

Hey, one question.

 

Given that I'm running in a more or less powerfull machine (R9 3900x, 64GB RAM), with plenty of resources, is there any settings/tweaks that can be done to increase the performance further? 

 

I'm currently sitting at 1700 torrents and sometimes I get timeouts, it seems that nginx can't handle it that well (even if rTorrent itself is a beast)

Link to comment
  • binhex locked this topic
Guest
This topic is now closed to further replies.