Cat_Seeder
-
Posts
95 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Cat_Seeder
-
-
On 3/12/2019 at 10:58 AM, Djoss said:
What are the errors now?
Sorry, took a while trying to fix it by myself (and I've "succeeded").
Initially I was having the same errors as before:
2019/03/16 04:36:26 [error] 904#904: *3 connect() failed (113: Host is unreachable) while connecting to upstream, client: 192.168.X.Y, server: mydomain.local, request: "GET / HTTP/1.1", upstream: "http://192.168.X.Y:3000/", host: "mydomain.local"Turns out that Docker wouldn't me to access my host IP (be it public or internal) without --net=host. That's of course, an undesirable workaround. A better solution is to create a user-defined bridge network so that containers can talk directly.
After doing that I've enabled IPv6 and modified NGINX configuration:
listen 8080; listen [::]:8080;And finally it worked as expected:
$ curl -6 -g -v -H "Host: mydomain.local" http://[::1]:8080 * Rebuilt URL to: http://[::1]:8080/ * Trying ::1... * TCP_NODELAY set * Connected to ::1 (::1) port 8080 (#0) > GET / HTTP/1.1 > Host: mydomain.local > User-Agent: curl/7.60.0 > Accept: */* > < HTTP/1.1 200 OK[16/Mar/2019:05:14:09 +0000] - 200 200 - GET http mydomain.local "/" [Client 192.168.X.Y] [Length 543] [Gzip -] [Sent-to 192.168.X.Y] "curl/7.60.0" "-" [16/Mar/2019:05:18:40 +0000] - 200 200 - GET http mydomain.local "/" [Client ::1] [Length 543] [Gzip -] [Sent-to 192.168.7.2] "curl/7.60.0" "-"However, I have to say that while I love the Nice UI and have nothing but praise for the Developers, the container is not really what I was expecting. It is not currently able to generate configuration on the fly when I run new containers (that's probably the most important feature of jwilder/nginx-proxy); plus, I quickly outgrown the UI and had to intervene manually in order to make the container work with IPv6, make it play well with Syslog, etc.
On 3/13/2019 at 10:15 AM, binhex said:before i go pestering the developer on github, does anybody know if its possible to configure multiple ports for a proxy host?, i have tvheadend running and i would like to forward to ports 9981 and 9982, as far as i can tell there i currently no way of doing this through the ui, maybe some additional advanced nginx config would allow me to do this? (anybody got any examples) until this is included in the ui - assuming it is possible.
You will need to set a Proxy Host configuration for the http port (9981) and a stream for the other port (9982). In the Stream configuration UI you can select a different port than 8080 (or whatever you http port is). Don't forget to publish that second port (e.g., -P 9982:9982) and add a rule to allow incoming traffic to that port in your firewall.
-
20 hours ago, geoyil said:
Hi,
Bare with my I am quite new to docker. I have a problem that I am not sure how to fix. I have searched the internet but cannot really seem to fix it. So I am using Kitematic for windows because I find it easy with a GUI to handle the containers. I downloaded rtorrentvpn. I used the following values (see image). The ports were set automatically. I have understood that you must publish port in order to access container from outside the network and this seems to be in placed when i look in the output of the "Docker inspect ..." command. But I only want to access it from within my own network but from another device, so over wifi for example. I wouldnt mind to access it from outside aswell but then I have to make my host reachable.
So I can access the rtorrent through http://localhost:32862/
but I cannot access it through host ip as said in the guide from another device connected to the same network. I cannot even access it with this address from the host:
http://<host ip>:9080/
I have replaced host ip with my computers ip from https://www.myip.com/. I have also tried 192.168.99.100:9080, which i found online that is the default docker machine. I am not sure how to access rtorrent with host ip, can anyone please help me?
Please keep in mind all this is new to me.
I would probably drop Kinematic all together and go native (e.g., Docker Desktop). I'm not familiar with Kitematic, but it seems to be binding ports to localhost only (e.g. -p 127.0.0.1:32862:9080 instead of -p 9080:9080).
The CLI is not that hard to learn; plus not having to deal with Docker Toolbox / VirtualBox will make your life easier.
-
1
-
-
13 hours ago, Djoss said:
The upstream server IP is 127.0.0.1. You should set instead a local IP. If the service is running on unRAID, use the unRAID's IP.
Hi Djoss, no luck with my local (192.168.x.y) or public IPs :(. Any other ideas?
My setup is:
* Linux Host
* Your image running on Docker
* Another image running on Docker, exposing port 3000 to the router.
Accessing my local IP directly works and nginx-proxy image works as expected.
Any other ideas?
-
11 hours ago, Spies said:
I can never get past 200 before everything stops but I feel like it's an issue with my hardware, I just haven't identified what yet.
Just sharing one of the links that I've sent you in private yesterday in case anyone else hits the same issue. Please ignore the Haproxy specific tweaks: https://medium.com/@pawilon/tuning-your-linux-kernel-and-haproxy-instance-for-high-loads-1a2105ea553e
Number of open files, max TCP connections and "reservation" times can all affect the end result when dealing with a large amount of torrents. I'm on Linux (not Unraid) and had to fine tune the host to get it all working with 1k+ torrents.
-
1
-
-
6 hours ago, Johan76 said:
How do I get Flood frontend working?
I set ENABLE_FLOOD to yes in docker settings.
Some thing about preventing rutorrent from starting since Flood is enabled in log. Docker start without any problem.
No webinterface at all at port 9080 anylonger. Am I doing this wrong?
Edit:
Ok changed to "no" and now Im not even get rutorrent interface back.
Have restarted docker several times
NO idea what could have been messed up by just changing the variable from no to yes and then back to no
Flood listens in port 3000.
Rutorrent listens in port 9080 and 9443 (Https).
If you want both you can set ENABLE_FLOOD to BOTH.
Be warned that, while it looks great, flood uses a lot of memory and is not as feature complete as rutorrent. With 1k torrents Flood's Node.js process is using quite a bit of memory, plus the UI lags so much that it's barely usable; Rutorrent is still doing "reasonably" fine.
As for rutorrent not starting, try to start from scratch. Delete the container, pull the latest image and start with a fresh volume / host folder bound to the container's /config folder.
-
11 hours ago, binhex said:
sounds good to me, tbh i am no expert when it comes to the details of rtorrent config, the currently bundled rtorrent.rc is a carbon copy taken from the github repo with a few tweaks to enable dht etc, so its just the default config
i can change this to what you are suggesting so that new users will pick up the change, im being lazy here and not looking this up, just want to confirm the above would mean it still could fallback to plaintext if required, right?, i dont want new users to start complaining that speeds are low due to not being able to connect to all peers.
I think so. Have a look at the documentation bellow:
Quoteencryption = option,...
Set how rtorrent should deal with encrypted Bittorrent connections. By default, encryption is disabled, equivalent to specifying the option none. Alternatively, any number of the following options may be specified:
allow_incoming (allow incoming encrypted connections), try_outgoing (use encryption for outgoing connections), require (disable unencrypted handshakes), require_RC4 (also disable plaintext transmission after the initial encrypted handshake), enable_retry (if the initial outgoing connection fails, retry with encryption turned on if it was off or off if it was on), prefer_plaintext (choose plaintext when peer offers a choice between plaintext transmission and RC4 encryption, otherwise RC4 will be used)
enable_retry will turn off encryption in the second case.
So basically the difference is that 1) Tries plain text first and then retry with encryption. If client can do both it will prefer plaintext 2) Tries encryption first and then retry plain text. If client can do both it will prefer encryption.
Both strategies, in theory, will allow the user to connect with any kind of peer.
Effects on speed are somewhat hard to predict. All things being equal, plaintext is probably faster. However, if the ISP is traffic shaping, encryption will probably boost the speeds.
Maybe go for 1 when VPN is enabled and 2 otherwise?
-
@binhex, I'm sorry to keep bothering you.
Just want to check something. In rtorrent.rc we have:protocol.encryption.set = allow_incoming,enable_retry,prefer_plaintextAs far as I understand rTorrent will work in plain text mode by default right?
Is there a reason not to change it to something like:protocol.encryption.set = allow_incoming,try_outgoing,enable_retrySo that it tries to use RC4 encryption when possible? As far as I understand this is safer and it's a good neighbour police (helps people that do not use a VPN).
-
1 hour ago, dbsps said:
I'd be fore this. I have no need of the openVPN / Privoxy or ruTorrent stuff myself but I understand if this might be a bit more work than you want to take one as well.
I haven't tried it myself but if rTorrent + flood is all you need maybe the following image may fit the bill: https://hub.docker.com/r/wonderfall/rtorrent-flood
You may, of course, use binhex's image with the correct flags to disable vpn, privoxy and ruTorent + autodl-rssi, however, given that you do not need 80% of its features, if might feel like driving your kids to school with a lorry :).
-
Hi guys,
Thanks for the great container. Amazing work.
I'm currently trying to migrate from the also excellent (but CLI oriented) Jason Wilder nginx-proxy container.
So far I have a couple of problems:
-
IPv6 support. Looks like the proxy is failing to forward to the desired destination when I reach it over IPv6.
I'm looking for something around the lines of nginx-proxy's:ENABLE_IPV6=trueIs IPv6 supported?
I've tried manually addinglisten [::]:8080;to the server block in /config/nginx/proxy_host/3.conf, however, the proxy is currently returning 502 Bad Gateway:$curl -g -6 -v -H "Host: mydomain.local" http://[::1]:8080 * Rebuilt URL to: http://[::1]:8080/ * Trying ::1... * TCP_NODELAY set * Connected to ::1 (::1) port 8080 (#0) > GET / HTTP/1.1 > Host: mydomain.local > User-Agent: curl/7.60.0 > Accept: */* > < HTTP/1.1 502 Bad Gateway < Server: nginx < Date: Sat, 09 Mar 2019 16:06:32 GMT < Content-Type: text/html < Content-Length: 166 < Connection: keep-alive < <html> <head><title>502 Bad Gateway</title></head> <body bgcolor="white"> <center><h1>502 Bad Gateway</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host ::1 left intact
Error logs:
[error] 872#872: *2 connect() failed (111: Connection refused) while connecting to upstream, client: 172.17.0.1, server: mydomain.local, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "mydomain.local"I can reach port 3000 directly from my host. nginx-proxy container is also able to proxy it with no issues.
-
Consolidated logs. Another problem is consolidating and formatting the logs. I would like to have a consolidated view of the logs (i.e., everything at /config/nginx-proxy-manager/logs/) so that I can send it to another tool. I would also like to be able to customise its format.
At the moment I'm using multitail to consolidate the logs and manually editing nginx configuration files to customise formatting. However, it would be great if there was a more permanent solution to the problem.
All of the best
-
IPv6 support. Looks like the proxy is failing to forward to the desired destination when I reach it over IPv6.
-
On 3/8/2019 at 11:05 AM, binhex said:
yeah size is def one aspect but support and maintenance are the killers, i really dont want this docker image to become a big bloated monstrosity and its getting that way already.
I understand. This may not be a very popular opinion given that lots of people are running your image in very limited devices such as an entry level NAS. However, maybe it would be worth it to break down services in separate containers, potentially binding everything together with a "do it all" docker compose file? E.g., one image with openVPN + port forwarding stuff, one image with rtorrent-ps exposing just port 5000, one image with rutorrent, one image with flood, one with privoxy, etc.
That way you will be able to add features to individual images without worrying too much about overly bloated containers.
On 3/8/2019 at 11:05 AM, binhex said:you have seen the excellent nginxproxymanager docker image right?, if not then i STRONGLY encourage you to give it a spin, its awesome and sounds like it does what you have managed to do manually.
im using it now for all my external access and its great, its something ive wanted for a LOOOOONG while, that combined with geo blocking and hopefully shortly fail2ban integration and my network will be tighter than a ducks ass 🙂
link:- https://forums.unraid.net/topic/76460-support-djoss-nginx-proxy-manager/
Looks very promising. The GUI is awesome. Straight out of the box beats my solution. I just need to check if it is working well with IPv6
Thanks for the great hint. Not sure why I haven't found the container above while looking for it :).
-
15 hours ago, binhex said:
thanks for that!.
i will take a look, im hoping the plugin isnt too large, this container already has a LOT going on so i am very conscious of that.
TYVM for considering it.
Stats in my machine:
filemanager + fileuploader folders: 344.9 KiBzip package: 549.6 KiB
rar package (AUR): 862.6 KiB
rutorrent: each one of the nginx containers are now averaging around 1640 K. Before installing both plugins containers where using around 1550 K - 1580 K each.
Overall it is a very lightweight set of plugins, however, I do understand that it is one more thing to manage in an image that is already doing a lot :).
---
Different topic: I'm also making a lot of progress with nginx reverse proxy. My containers have been running smoothly for around 10 days.
I've created a docker-compose projects that servers rtorrentvpn + nginx-proxy. It is currently able to expose rutorrent and optionally flood to the internet with their own custom domains (e.g., rutorrent.mydomain.xyz and flood.mydomain.xyz) over https, with A+ SSL scores. It works over IPv4 and IPv6 (for those of us behind CGNAT).
I don't think that my solution is complex enough to deserve it's own git repo for now. Is this something worth sharing in the forums?
Cheers, -
11 hours ago, binhex said:
see here for a PR that apparently (not tried it) allows you to install file manager plugin:-
Great stuff @binhex. I did manage to make it work adjusting some of the OP instructions. I left a few comments in the GitHub issue.
File Manager is probably a very good addition to your image. It's certainly very useful when you are sharing your "seedbox" with non-technical users or just need a quick way to decompress a set of rar files, etc remotely (It comes out of the box in most managed seedboxes).
I've noticed that, so far, there are no PRs merged to your repo, so I didn't take the time to open a PR. However, if you do decide to add support for file manager, I can send you a patch (afaic my patch is public domain). Otherwise, I think that my instructions should be good enough to add support from scratch with no hassle.
If you do decide to add support (or at least install zip and rar packages) it would be great. That way I can avoid building images locally.
-
No noticeable regressions after the upgrade. Memory consumption is holding well. rtorrent process using around 55 MB memory with a couple of torrents and about the same as before with ~1000 torrents. I was expecting much more of a hit given the extra features.
Fantastically done.
I still can't manage to install FileManager with the ruTorrent v3.8 + rtorrent 0.9.6/0.13.6 combo. Don't know what I'm doing wrong :(.
-
On 3/1/2019 at 10:05 AM, binhex said:
hi all, just to make you all aware of this:-
I've been using rtorrent-ps + tmux in a VPS for a while. It works great.
Version downgrade is fine by me. Just need to double check if that specific version is not blacklisted in any major private trackers.
Unrelated to above: Did anyone manage to get FileManager, FileShare and / or Unpack to work? If so, can you please share the version and installation instructions that you have used? I've tried the custom plugin folders but all plugins end up in "unloaded" state.
-
2 hours ago, hypno-techie said:
Dear all,
I've been trying to connect to "Remote Torrent Adder" (an extension on Chrome) to ruTorrent, but I seem not to be able to do it.
I put in the IP address, port (9443), also checked the SSL box and put the correct username and password.
The settings work fine on nzb360 and Transdrone on my Android...
Has anyone got this to work for them?
Or know of an alternative method? (Windows client?)
Thanks!
I gave my server a domain name and it is working fine with Remote Torrent Adder. I have a real domain with a DNS entry pointing to my box so that I can access it from the internet. However, inside a LAN you can get away with setting a Domain Name in your DHCP server (e.g., your Router) and a hostname for your NAS. I don't own a Synology router, however, most Linux based distros will update /etc/hostname with whatever you have selected as the server name.
I wouldn't bother with SSL if you are only using it in your LAN (Port 9080 / SSL off should be fine). If you are outside of your LAN you will need to either generate a valid SSL certificate (e.g., with Let's Encrypt) or import the container self signed certificate (https://github.com/bogenpirat/remote-torrent-adder/wiki/Import-self-signed-certificates)
-
6 hours ago, binhex said:
Ipv6 is not supported in any of my VPN containers and is actually actively blocked via ip6tables
Sent from my EML-L29 using Tapatalk
Humm... That's interesting. At the moment I can access the rutorrent exposed port through my host IP address (i.e., http://[20xx:yyyy:yyyy:yyyy:yyyy:yyyy:yyyy:yyyy]:9080 works when the request comes from inside my lan). Is the IPv6 request getting translated to IPv4 somehow when I access it inside my LAN?
-
Hi guys,
I'm sorry to bother but I'm still struggling with this. Although I understand that external connectivity is not a functionality of the container per see, any help would be very welcome.
I really think that this is a problem related with IPv6 and the container iptable and network settings. If I tunnel traffic through IPv4 (i.e., ngrok) everything works well.
However, I'm stuck behind cgnat and would very much like to have a direct connection to my host.
The symptoms that I'm witnessing are very similar to the ones reported by people trying to set up a reverse proxy (with nginx, traefick, etc). Has anyone managed to get their reserve proxy working? If so, could you please share a copy of your configuration?Kind regards,
-
Hi guys,
Just wondering if anyone managed to expose rTorrent's interface to the web over IPv6.
So far I have:- Deleted the default admin user / created a non-standard one
- Created an SSL certificate and replaced the original certs in /config/nginx/certs
- Exposed ports 9080 and 9443 in my router's firewall
- Add an AAAA record on my domain pointing to my IPv6 address
From inside my LAN everything works fine. I can access rTorrent using my custom domain over http and https with no problem.
From outside my LAN I can only access rTorrent through http, and the UI only loads partially (it gets stuck trying to request getplugins.php).
And I missing something?It definitively looks like I need to open a few more ports. Plus, I may be missing something regarding the container's iptable rules. I.e., what should LAN_NETWORK be?
[Support] binhex - rTorrentVPN
in Docker Containers
Posted
Humm. I'm not familiar with Proton VPN, but I would check if they support Port Forwarding. Without it you will have a half-baked experience at best. No incoming connections means passive mode. You will get in trouble in private trackers. In public trackers you may not find many (or even any peers)... If you want to set up a VPN always check if they do allow port forwarding and if the port that you have opened is reachable (https://www.yougetsignal.com/tools/open-ports/).
Other than that, while it is not related to your issue, you may not be able to access the webui remotely (see Q2 at