[Support] binhex - rTorrentVPN


Recommended Posts

On 12/1/2019 at 6:36 AM, CellDweller said:


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....
 

 

What webuser are you using when logging into rutorrent?

I found that the default admin account has different settings than my custom made user account. This admin account is used during container startup, see below and here is the autotools code: https://github.com/Novik/ruTorrent/blob/97d5dc60febb9d8c6e5384a0a0d8fec3e4fa10cf/php/initplugins.php#L122

You can find autotools.dat in this confusing path inside config folder: \rtorrent\rutorrent\share\users\user\settings

 

 

@binhex I did find a container breaking bug related to the default admin user, when the WEBUI_USER is supplied and this initplugins line :

execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &}


It's is hardcoded as a default of 'admin' for the webuser, and also in /home/nobody/initplugins.sh uses 'admin'.

I'm not sure if it's a container bug or a rutorrent bug, but when that user is non-existent it breaks all downloads as I removed admin from my auth file, previously discussed in this thread.

 

I had removed the default admin account for security, and found my downloads all would download correctly, then fail when autotools tried to move them with a mysterious error that took a weekend to track down to the above lines.

The files would become filled with null bytes after the error, and I am glad I caught it before more files were destroyed.

 

 

 

Edited by jraid
Link to comment
1 hour ago, jraid said:

What webuser are you using when logging into rutorrent?

I found that the default admin account has different settings than my custom made user account. This admin account is used during container startup, see below and here is the autotools code: https://github.com/Novik/ruTorrent/blob/97d5dc60febb9d8c6e5384a0a0d8fec3e4fa10cf/php/initplugins.php#L122

You can find autotools.dat in this confusing path inside config folder: \rtorrent\rutorrent\share\users\user\settings

 

@binhex I did find a container breaking bug related to the default admin user and this initplugins line:

execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &}


As the default is 'admin' for the webuser, and also in /home/nobody/initplugins.sh uses 'admin'. I'm not sure if it's a container bug or a rutorrent bug, but when that user is non-existent it breaks all downloads.

 

I had removed the default admin account for security, and found my downloads all would download correctly, then fail when autotools tried to move them with a mysterious error that took a weekend to track down to the above lines.

The files would become filled with null bytes after the error, and I am glad I caught it before more files were destroyed.

I did not bother making a other account for this, still using the default admin account. Although it is a good idea to change user i think. But being not really a "linux guy" i did not think about this yet. But using the default account, should i be affected by this, i think not? (Again, i am NOT a experienced Linux user)

Link to comment
54 minutes ago, CellDweller said:

I did not bother making a other account for this, still using the default admin account. Although it is a good idea to change user i think. But being not really a "linux guy" i did not think about this yet. But using the default account, should i be affected by this, i think not? (Again, i am NOT a experienced Linux user)

Yeah you should be fine with the default account, it was just a thought as mine broke when I changed users and the default config remained the same.

Not sure what your issue is then, but take alook at autotools.dat and see if it matches the GUI settings?

Edited by jraid
Link to comment
10 hours ago, jraid said:

@binhex I did find a container breaking bug related to the default admin user, when the WEBUI_USER is supplied and this initplugins line :

execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &}

thanks for this, i see the correction that needs to be made.

Link to comment
3 hours ago, kbbeer said:

Should the autotools.dat file be saved after restarting the container or does it need to be created from scratch each time?

The UI should save to that file, and read from it on every container start. 

The error may be somewhere in that interaction, and starting from scratch might help solve it. This would include removing or renaming the file so it's recreated the next time, setting the options in rutorrent, and hopefully they appear in the file and load correctly upon a restart.
Not sure why it would only happen some of time if the web user is always the same.

Link to comment
  • 2 weeks later...
On 12/1/2019 at 1:36 PM, CellDweller said:

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!

Fixed the problem. It appears rtorrent has a problem with adding labels through the api. It errors on special characters and spaces... So "nametracker - movies" gives these weird problems, "nametracker-movies" works fine. Little weird but ok, it's all working fine now. Very happy with all this!

Last thing for me personally is to look into queuing torrents when multiple get added at the same time. Found out about pyrotorque, and pyrocore already to be in this docker. Will have to take a look into all this, but this whole docker package is awesome!

Thanks for all the hard work Binhex! I will donate something, i think your packages are very nice, keep the good work up!

  • Like 1
Link to comment

I'm having an issue with RSS feeds over VPN.  The provider I am pulling the RSS feeds from requires that the same IP address used to set up the feed is the same IP address used to load the feed/download from.  I am running this container on my server, and set everything up using my desktop using the VPN feed. 

 

The issue I am running into is that, when my desktop is not on VPN and I attempt to reload the feed through the container's GUI (container is on correct VPN IP), I get errors that the IP does not match the VPN ID.  I've ran multiple checks with checkmyip.torrentprivacy.com, and the container's external IP is still showing as the correct VPN ID.  However, if I log into my VPN service on the desktop and try to reload the feed, it works perfectly.

 

This is only an issue with RSS; when I download torrents off the VPN-connected desktop, disconnect from VPN, and load them to the rTorrent container, they download as expected.  I will leave the feed alone for a few weeks to see if it is able to automatically pull from the provider, but am a bit befuddled as to why this isn't working as (I) expected.

Link to comment

Just to report, the containers are less stable than before. Despite the new auto-restart logic, after 3 to 6 days I always end with no connectivity (red icon at the bottom of rutorrent) until I restart the container manually. I'm with PIA, on a very stable 1 GB connection. With older images I was managing several weeks of uptime.

 

Unfortunately logs are pure garbage after a few hours. Is there a way that I can setup the container to dump logs as soon as connectivity is lost to help troubleshoot the issue?

Link to comment
1 hour ago, Cat_Seeder said:

Just to report, the containers are less stable than before. Despite the new auto-restart logic, after 3 to 6 days I always end with no connectivity (red icon at the bottom of rutorrent) until I restart the container manually. I'm with PIA, on a very stable 1 GB connection. With older images I was managing several weeks of uptime.

 

Unfortunately logs are pure garbage after a few hours. Is there a way that I can setup the container to dump logs as soon as connectivity is lost to help troubleshoot the issue?

sadly due to me doing dev on my production machine (im too poor to buy another machine for testing), i dont have long uptime for rtorrent, however i did do some testing before release of the latest image and have just tested again and the code looks solid so it should be changing the port once its detected as closed.

 

ok so onto debug, so i think from memory i allow up to 5 x 10MB supervisord.log files, so if you open each log file with a decent text editor, such as notepad++, and then search for the string 'incoming port closed, marking for reconfigure' this will indicate that the code to check the port state has detected the port is now closed, if you dont have this string in any of your log files then the port check code is not triggering for some reason.

 

you may want to temporarily set debug to true in order to get some more info out, and yes this will make your logs grow.

 

note:- the rutorrent open port indicator can be a little shit at times, you need to refresh the webpage after the port has been changed in order for the port indicator to work correctly, this however does not affect rtorrent's ability to allow incoming connections on that port.

Link to comment
On 12/17/2019 at 10:42 AM, binhex said:

@Cat_Seeder a thought i had whilst driving home, you havent by any chance set ENABLE_RPC2 to a value of 'no' have you?, if so this will be the cause of the issue, as i use xmlrpc in order to reconfigure the incoming port on port closed.

Sorry for the late response, that's a good guess, thanks! I do actually have RPC2 disabled. I did downgrade to a previous image a few days ago, but I'll upgrade to the latest image, enable RPC2 and see how it goes for the sake of troubleshooting (if it breaks again  I'll try to extract something useful from the logs using your previous hints).

 

I know that I'm being a little - well, more than a little :D -  insistent about this, but since the port renew scripts are operating from inside the container, are you sure that exposing RPC2 over Nginx is necessary? Can't xmlrpc client issue commands straight to localhost:5000 (rtorrent scgi port)?

Or even better, can't you move to a socket setup? For users that really need to expose RPC2 to Sonarr / Radarr / etc Nginx can still act as a Proxy (see: https://www.reddit.com/r/seedboxes/comments/92oi6u/creating_a_scgi_socket_file_to_http_proxy_for/ for an example ).

 

If this works you can revert all of the unnecessary security compromisses. No necessity for default credentials, no requirement to expose RPC to the outside world for those of us that don't need it, etc. Don't take this the wrong way, auto-restart is a great feature and I don't want it to go away, however, as it is the security compromisses are really bothering me.

Link to comment

Hi all,

 

I'm having issues where the rTorrent process is failing to start. I've enabled the debug log and I just see multiple:

 

2019-12-22 18:52:27,735 DEBG 'watchdog-script' stdout output:                                                                         
[debug] Waiting for rTorrent process to start...
2019-12-22 18:52:28,744 DEBG 'watchdog-script' stdout output:          
[debug] Waiting for rTorrent process to start...                 
2019-12-22 18:52:29,760 DEBG 'watchdog-script' stdout output:         
[debug] Waiting for rTorrent process to start...        

 

And then:

 

2019-12-22 18:52:34,820 DEBG 'watchdog-script' stdout output:                                                                                                                                                  
[warn] Wait for rTorrent process to start aborted, too many retries                                                                                                                              
2019-12-22 18:52:34,827 DEBG 'watchdog-script' stdout output:                                                                                                                                                  
[info] Autodl-irssi not enabled, skipping startup                                                                                                                                                               
2019-12-22 18:52:34,828 DEBG 'watchdog-script' stdout output:                                                                                                                                                  
[info] Initialising ruTorrent plugins (checking rTorrent is running)...  

 

I've created a bash shell into the running Docker container and verified my VPN connection to AirVPN is running correctly and I can ping google.com successfully. Also, if I go into /home/nobody and:

 

export vpn_ip=x.x.x.x
export external_ip=y.y.y.y
./rtorrent.sh

Then rTorrent launches and everything seems fine. But, then after that if I restart the container the rTorrent process will again fail to start.

 

It's not immediately clear to me where I can see log files to tell why rTorrent is failing to start so I'm a bit stuck right now. Would appreciate some help at this point. Thanks!

 

Link to comment
14 hours ago, binhex said:

yep, xmlrpc needs a url specifying to connect to rpc2, thus it needs to be exposed.

 

I see, that's a limitation from the xmlrpc cli tool. Libraries can talk to rtorrent straight over SCGI. This is how software like pyrocore talks with rttorent.

 

Actually, pyrocore even exposes its own xmlrpc cli tool that does not require an http endpoint https://pyrocore.readthedocs.io/en/latest/references.html#cli-usage-rtxmlrpc

 

Would it be much of a hassle to replace xmlrpc with pyrocore's rtxmlrpc client?

 

As far I understand you already have pyrocore installed. Changes would probably be limited to the first if statement in  https://github.com/binhex/arch-rtorrentvpn/blob/master/run/nobody/rtorrent.sh and then, AFAICT, the requirement for default credentials can go away.

 

If you are busy and accept contributions I can even take a stab at it myself.

 

What do you think?

 

Edited by Cat_Seeder
Missing space after URL
Link to comment

Hi all, I'm getting this error bellow when I load the open vpn file to the docker. Any ideas on how I can fix this? Im with winscribe VPN so may be a different way of saving the open vpn file?

 

 

Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: auth-user-pass (2.4.7)

 

 

Link to comment
Hi all, I'm getting this error bellow when I load the open vpn file to the docker. Any ideas on how I can fix this? Im with winscribe VPN so may be a different way of saving the open vpn file?
 
 
Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: auth-user-pass (2.4.7)
 
 
Follow these instructions:-
https://github.com/binhex/documentation/blob/master/docker/faq/help.md

Sent from my CLT-L09 using Tapatalk

Link to comment
3 minutes ago, binhex said:

i thought it might be this:-


VPN_OPTIONS defined as 'no'

not sure where you got the idea this should be set to 'no' but this is not a valid option (argument) for openvpn, remove the value and you should get further.

Damn thanks, appreciate it.

Link to comment
On 5/28/2016 at 3:04 PM, binhex said:

ok lets take this step by step here, as there is a lot of misconception here:-

 

 

 

firstly support for airvpn does not automatically set the incoming port for you, this is not possible as its up to the user to configure and decide which port they will get forwarded via the airvpn config webpage, so you need to configure rtorrent manually for the port you have defined (should be the same as the port defined in delugevpn). This is done by editing the rtorrent.rc file, NOT via the rutorrent webui.

 

 

 

this is true that dht is set by default to port 6881 BUT so is the default incoming port, so the indicator at the bottom is ONLY for the incoming port, it does not monitor or show you DHT issues, what your seeing in indication that the incoming port is not open, which it wont be as you need to configure rtorrent to use the airvpn incoming port you defined.

 

 

 

so configuring port forwarding on your router will have ZERO effect on the vpn tunnel, a vpn tunnel is a secure independent link to another network that is routed over your standard internet connection, thats why you need to configure the incoming port via your vpn providers website, or in the case of PIA programatically.

 

I hope the above clears up some of your issues, if your still stuck then let me know.

Hi, so im noticing the same issue. What part of the rtorrent.rc needs to be changed? is it the below?

 

image.png.db6658af17fa174cad9e1f5c2ba01489.png

 

and

 

image.png.f4ec00c52838605a6e36ab3898e36efd.png

 

Also the openVPN file I generated had a port of 443, this need to be set as a static port? like this? or do they need to be the same so 10032:10032 and once I fix the rtorrent.rc file it should work?

 

image.png.a611b8ac45421f07ebc35765dd780192.png

 

Would love some pointers on how to fix this. Thanks in advance :)

Link to comment
14 hours ago, Gursh said:

is it the below?

 

image.png.db6658af17fa174cad9e1f5c2ba01489.png

 

and

 

image.png.f4ec00c52838605a6e36ab3898e36efd.png

 

yes and yes

 

14 hours ago, Gursh said:

Also the openVPN file I generated had a port of 443

that is the port used to connect to the vpn endpoint, it has NOTHING to do with port forwarding, so just use whatever port you want, it should be a straight mapping e.g. port 1234 to 1234 then configure rtorrent.rc to use this port for listening port, and dht port.

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