[Support] binhex - rTorrentVPN


Recommended Posts

I'm trying to automate the removal of torrents using ratio groups. FWIW, I also use Sonarr to pick the files up once they're downloaded.

 

I have one main ratio group that's set to Remove data (All). This seems to MOSTLY work, however, I also have unpack enabled and it won't delete the unpacked file which leads to an error in my Unraid log that says:

 

Feb 2 06:45:14 ZEUS shfs: error: shfs_rmdir, 1517: Directory not empty (39): rmdir: /mnt/cache/downloads/complete/tv/xxxxxxxxxxxxxxxxxxxxxxxxx

 

Any ideas in Sonarr or RuTorrent? TIA!

Link to comment

So I'm getting an error where the config file for my VPN is not being recognised, I've tried downloading the config files from NordVPN and putting the keys into separate files but the system just doesn't recognise the .ovpn file.

 

Any suggestions?

Thanks

 

Log output:

2018-02-03 00:52:28.263939 [crit] No OpenVPN config file located in /config/openvpn/ (ovpn extension), please download from your VPN provider and then restart this container, exiting...

Link to comment
1 hour ago, BrttClne22 said:

I have one main ratio group that's set to Remove data (All). This seems to MOSTLY work, however, I also have unpack enabled and it won't delete the unpacked file which leads to an error...

 

"Remove data (all)" should remove the entire directory, regardless if it contains more files that were included in the torrent.

 

That said, I am trying to come up with some means (bash script + pyrocore?) that will run as a cron job and confirm that Sonarr has actually imported video before permanently deleting the files.

 

I'm honestly surprised that no one has fixed the issues in rTorrent that prevents Sonarr from cleaning up after itself.

Link to comment
14 minutes ago, Zonkeeh said:

Log output:

2018-02-03 00:52:28.263939 [crit] No OpenVPN config file located in /config/openvpn/ (ovpn extension), please download from your VPN provider and then restart this container, exiting...

 

Are you sure your mounting your volume to /config properly, are you sure the permissions are all correct on the .ovpn file.  Lets see your docker run command, and an ls of the config/openvpn directory.

Link to comment

config is mounted properly as the rutorrent files and directories have been created ls is as follows:


-rw-rw-rw- 1 root users 3010 Feb  2 13:49 uk399.nordvpn.com.tcp443.ovpn
-rw-rw-rw- 1 root users 3035 Feb  2 13:49 uk399.nordvpn.com.udp1194.ovpn
-rw-rw-rw- 1 root users 1720 Feb  2 13:52 uk399_nordvpn_com_ca.crt
-rw-rw-rw- 1 root users  602 Feb  2 13:52 uk399_nordvpn_com_tls.key
root@zonkeeh-Server:/mnt/user/Docker/ruTorrent/config/openvpn#

 

edit: I've also tried changes the file permissions to no effect.

edit 2: Upon further review, the .opvn file has a ca and a key already in it, however, this would still not stop the file from being loaded surely.

Edited by Zonkeeh
Link to comment
4 minutes ago, Zonkeeh said:

config is mounted properly as the rutorrent files and directories have been created ls is as follows:

 

The only thing I see odd is that you have 2 .ovpn files... I would think it would just use the first though?

 

Regardless... need more detail.  Attach logs, lets see the command your running, a full "ls -al" of each of the folders in /config... give too much info.

 

NOTE:  I had this working on Nord two days ago (just switched since Nord doesn't do port forwarding)... so I'm confident its your setup, not the image.

Link to comment

Just figured it out, there was a problem with the config folder not registering correctly even though it was created and defined in the same place in the settings, changing it to /mnt/usr/Docker/ruTorrent/ seemed to work just fine.

 

PS: Is there any way to test if the connection is in fact routing via a VPN?

Edited by Zonkeeh
Link to comment

Could I get some help or insight into this error?

2018-02-04 10:04:53,034 DEBG 'rutorrent-script' stderr output:
2018/02/04 10:04:53 [error] 1470#1470: *46 FastCGI sent in stderr: "PHP message: PHP Notice: Undefined offset: 29 in /usr/share/webapps/rutorrent/plugins/trafic/stat.php on line 165" while reading response header from upstream, client: 172.17.0.1, server: localhost, request: "POST /plugins/trafic/action.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:7777", host: "rutorrent.server.xxxxxxx.com:443", referrer: "https://rutorrent.server.xxxxxxx.com/"

xxxxxxx = myserver

 

My webui seemed 'stuck' but restarting the docker brought that back - but the error was in the log again.

Edited by dstanley
Link to comment

I'm trying to setup Sonarr with rTorrentVPN but I keep getting an issue where it says the connection failed.

 

I noticed that both httprpc and rpc are included within the docker, but I must be doing something wrong with regards to the URL path.

 

Here is what I have:

 

image.thumb.png.b7af7b6e0171865a987976018bab7a60.png

 

image.thumb.png.9a97dac588d87f9c958d92d4a54fd5b3.png

image.thumb.png.0ea99c670ff2cb80b94eee8d6d12d132.png

image.thumb.png.36f15b9eda1718a14fa80cb2a4346370.png

 

I tried searching through the support thread and came across someone having issues with sickbeard but even after attempting the suggested fix, I still can't get it to work.

 

Any help is appreciated, thank you!

Link to comment
1 hour ago, GroxyPod said:

I'm trying to setup Sonarr with rTorrentVPN but I keep getting an issue where it says the connection failed.

 

I noticed that both httprpc and rpc are included within the docker, but I must be doing something wrong with regards to the URL path.

 

Here is what I have:

 

image.thumb.png.b7af7b6e0171865a987976018bab7a60.png

 

image.thumb.png.9a97dac588d87f9c958d92d4a54fd5b3.png

image.thumb.png.0ea99c670ff2cb80b94eee8d6d12d132.png

image.thumb.png.36f15b9eda1718a14fa80cb2a4346370.png

 

I tried searching through the support thread and came across someone having issues with sickbeard but even after attempting the suggested fix, I still can't get it to work.

 

Any help is appreciated, thank you!

Try URL Path in Sonarr as "RPC2" (no quotes).

Link to comment
13 minutes ago, IndianaJoe1216 said:

Is there a way to change the default username and password for the WebUI? Loving this container but I would like to be able to adjust that if possible.

 

This is copied from the description on DockerHub linked in the OP:

 

If you want to create an additional user account for ruTorrent webui then please execute the following on the host:-

docker exec -it <container name> /home/nobody/createuser.sh <username to create>

If you want to delete a user account (or change the password for an account) then please execute the following on the host:-

docker exec -it <container name> /home/nobody/deluser.sh <username to delete>
Link to comment
5 hours ago, BrttClne22 said:

Try URL Path in Sonarr as "RPC2" (no quotes).

 

Looking at the nginx config, I definitely should be using RPC2.

 

When I use xmlrpc within the docker, everything is reporting just fine.

 

EDIT: Fixed, the docker does not like being attached to a dedicated IP. Soon as I switched it to bridge networking, I was able to get it to connect without issue.

 

Thanks BrttClne22!

Edited by GroxyPod
Link to comment

Getting the following PHP error, seems to be related to timezone, but I don't know where to change that.


 

2018-02-05 20:50:55,417 DEBG 'rutorrent-script' stderr output:
2018/02/05 20:50:55 [error] 730#730: *1 FastCGI sent in stderr: "PHP message: PHP Warning: getdate(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 269
PHP message: PHP Warning: mktime(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 272
PHP message: PHP Warning: getdate(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 269
PHP message: PHP Warning: mktime(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 272
PHP message: PHP Warning: getdate(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 269
PHP message: PHP Warning: mktime(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 272" while reading response header from upstream, client: 192.168.1.94, server: localhost, request: "GET /php/getplugins.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:7777", host: "192.168.1.6:9080", referrer: "http://192.168.1.6:9080/"

2018-02-05 20:50:55,604 DEBG 'rutorrent-script' stderr output:
2018/02/05 20:50:55 [error] 733#733: *5 FastCGI sent in stderr: "PHP message: PHP Warning: fopen(/usr/share/webapps/rutorrent/share/users/admin/settings/uisettings.json): failed to open stream: No such file or directory in /usr/share/webapps/rutorrent/php/getsettings.php on line 7" while reading response header from upstream, client: 192.168.1.94, server: localhost, request: "POST /php/getsettings.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:7777", host: "192.168.1.6:9080", referrer: "http://192.168.1.6:9080/"

 

Link to comment
10 hours ago, poots said:

Getting the following PHP error, seems to be related to timezone, but I don't know where to change that.

 


2018-02-05 20:50:55,417 DEBG 'rutorrent-script' stderr output:
2018/02/05 20:50:55 [error] 730#730: *1 FastCGI sent in stderr: "PHP message: PHP Warning: getdate(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 269
PHP message: PHP Warning: mktime(): Invalid date.timezone value 'NZST', we selected the timezone 'UTC' for now. in /usr/share/webapps/rutorrent/php/settings.php on line 272

 

Did you set the PHP timezone correctly?  NZST is not a valid PHP timezone... your probably looking for "Pacific/Auckland"

Link to comment

Another question:

Despite what is written in your image homepage, it seems the flood version installed in your image is the latest release (i.e 1.0.0) and not the latest git master commit.

Would you consider changing this and actually taking the latest master commit instead?

If not, would you have some advice on how to update your container afterwards? I tried the following, but flood did not start, and I didn't really know where to look for clues.

 

root@Syno:~# docker exec --tty --interactive my_rtorrent_container bash

cd /etc/webapps/
git clone https://github.com/jfurrow/flood.git flood_git
cd flood_git
pacman -S --needed make gcc --noconfirm  # Now needed compile a flood dependency
npm install --production

# config-backup.js creation probably useless as it was already copied as the actual config.js
cp config.template.js config-backup.js
sed -i "s~host:.*~host: '127.0.0.1',~g" config-backup.js
sed -i "s~sslKey:.*~sslKey: '/config/nginx/certs/host.key',~g" config-backup.js
sed -i "s~sslCert:.*~sslCert: '/config/nginx/certs/host.cert',~g" config-backup.js
sed -i "s~dbPath:.*~dbPath: '/config/flood/db/',~g" config-backup.js
sed -i "s~floodServerHost.*~floodServerHost: '0.0.0.0',~g" config-backup.js

chmod -R 775 .
chown -R nobody.users .
cd ..
mv flood flood_orig
mv flood_git flood

Restart container

 

Thanks

Link to comment
  • 2 weeks later...
  • 2 weeks later...

I've seen a few headlines concerning rtorrent and it's security around xml-rpc

https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

https://arstechnica.com/information-technology/2018/03/hackers-exploiting-rtorrent-to-install-unix-coin-miner-have-netted-4k-so-far/

 

This was discussed on github in the following issue

https://github.com/rakshasa/rtorrent/issues/696

 

I don't see network.scgi.open_port or network.scgi.open_local set in the rtorrent.rc but in not 100% familiar with the setup of this docker container. Is there another place to check if this security issues affects us?

 

Link to comment
3 hours ago, fatalfurry said:

I've seen a few headlines concerning rtorrent and it's security around xml-rpc

https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

https://arstechnica.com/information-technology/2018/03/hackers-exploiting-rtorrent-to-install-unix-coin-miner-have-netted-4k-so-far/

 

This was discussed on github in the following issue

https://github.com/rakshasa/rtorrent/issues/696

 

I don't see network.scgi.open_port or network.scgi.open_local set in the rtorrent.rc but in not 100% familiar with the setup of this docker container. Is there another place to check if this security issues affects us?

 

I saw this today as well. 

 

I'm not very knowledgeable so take this with a grain of salt, but my understanding is you should be secure as long as you don't have the RPC port exposed ( I think it's port 5000 by default).

 

Again, I expect to be corrected... This is just my understanding.

Link to comment
On 3/2/2018 at 9:33 PM, fatalfurry said:

I've seen a few headlines concerning rtorrent and it's security around xml-rpc

https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

https://arstechnica.com/information-technology/2018/03/hackers-exploiting-rtorrent-to-install-unix-coin-miner-have-netted-4k-so-far/

 

This was discussed on github in the following issue

https://github.com/rakshasa/rtorrent/issues/696

 

I don't see network.scgi.open_port or network.scgi.open_local set in the rtorrent.rc but in not 100% familiar with the setup of this docker container. Is there another place to check if this security issues affects us?

 

 

A few things to consider before you start to worry.

1. This container is not exposed to the internet directly... it uses a VPN.  When connected, it's public IP is not the IP of your machine, but the shared public IP of your VPN server.. often used by hundreds of others. (whole point of VPN for anonymity with torrenting)  So an attacker cannot target your rtorrent server directly.

2. Because your running rtorrent behind a shared IP address, the ONLY way to allow an incoming connection is with a port forward, and in most cases, the only port you would forward would be the rtorrent "listening port", if any, and only if your VPN provider even allows it.

3. When you start the container, you specify ports mappings... there is little reason to create a port mapping for the RPC port 5000 unless you are planning on running rutorrent or other XML-RPC management tools outside the container.  Because rutorrent is included inside, this is very unlikely.

 

That said, even if network.scgi.open_port is set, you are safe using this unless you made some very intentional implementation decisions to expose RPC to the world ( for example added a port mapping for port 5000 in docker and at your VPN provider).

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