Jump to content

Cat_Seeder

Members
  • Content Count

    24
  • Joined

  • Last visited

Community Reputation

2 Neutral

About Cat_Seeder

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Cat_Seeder

    [Support] binhex - rTorrentVPN

    Yes. Certainly proxing with auth is better than directly exposing port 5000 to the internet. I don't know much about nzb360. I have however enabled HTTPRPC and tested Sonarr with it (plugins/httprtc/action.php endpoint). It is working well (for about 5 hours). Not really impacting my CPU usage very much (testing on a laptop with I7 CPU). I do understand and thank you for taking action. If possible, however, I would at least recommend pushing basic authentication in the /RPC2 mount to everyone ASAP (as per my understanding you are already planning to do it as soon as you get confirmation that it works). While it is not as effective as completely removing the attack vector by default; with basic authentication exposed containers are at least safer from scanning bots.
  2. Cat_Seeder

    [Support] binhex - rTorrentVPN

    Hi @binhex, it works. However... Is that /RCP2 mount proxying 9080 and 9443 to 5000 over SCGI really necessary for rutorrent or flood to work over the internet? As far as I can tell from config.ini, rutorrent is actually going straight to 127.0.0.1:5000: $scgi_port = 5000; $scgi_host = "127.0.0.1"; Flood can also connect directly to port 5000. There are even a couple of plugins meant to replace SCGI altogether (see https://github.com/Novik/ruTorrent/wiki/PluginHTTPRPC for instance), it even promises to reduce bandwidth usage in exchange for extra CPU load. Regardless of authentication. If WAN exposure to XML-RPC can be limited I think that it would be a great idea. There are several known exploits that target insecure RPC deployments. There are also bots looking for this kind of thing (you can thank years and years of insecure WordPress deployments for that). If XML-RPC exposure over WAN is not strictly necessary I would vote to disable it by default. Maybe include an ENABLE_XMLRPC_OVER_SCGI flag for people that really need it. Basic authentication should certainly be enabled and I would really advice that people thinking about enabling such a flag first take the time to tighten security (or better yet, do not expose ports to WAN. Use a VPN instead). Further reading * Discussion about rtorrent and XML-RPC exploits: https://github.com/rakshasa/rtorrent/issues/696 * "Secure" setup with rtorrent + local / UNIX socket + Nginx reverse proxy with basic authentication + rutorrent: * rTorrent - ruTorrent communication: http://forum.cheapseedboxes.com/threads/rtorrent-rutorrent-guide.1417/ - HTTPRPC sounds like a great alternative to XML-RPC over SCGI (unless you are running a potato PC).
  3. Cat_Seeder

    [Support] binhex - rTorrentVPN

    You don't need to expose port 5000. Just expose 9443 (or 9080 if you are offloading Https to the proxy). As far as rutorrent is concerned it is talking to XML-RPC in the container's localhost. If you are using other clients that require access to port 5000, you can use a similar strategy. I've personally created a docker compose file for all applications that require access to rtorrent. Docker compose creates a shared network where services are discoverable by name (https://docs.docker.com/compose/networking/). Applications like Sonarr can access port 5000 even though it is not directly exposed to the internet. (E.g., use container hostname:5000) I would not recommend exposing RPC2 over the internet. However, if you want to do it for whatever reason (e.g., Sonarr is running in a separate box in the internet and for whatever reason you don't want to use a VPN) you will need to really beef up security. Username and password is just a first measure; monitoring your logs, setting up fail2ban, etc are all good steps. Otherwise you will soon find a crypto miner installed at your server...
  4. Cat_Seeder

    [Support] binhex - rTorrentVPN

    Hi guys, Just sharing (no support needed). I have missconfigured autodl-irssi and ended up with over 3k torrents in the container. Tonight I got several emails warning me that OOM Killer was running in a loop (since VPN IP changes every time I was also blocked from a tracker for spamming... Again! :(). Out of curiosity I had a look at the running process tab. rtorrent-ps + rutorrent + nginx + PHP were sitting at a cool 1.2 GB. Flood on the other hand quickly goes from 500 MB to 4 GB to 6 GB to OOM. node.js processes are basically eating all available run (not sure if this is expected or a memory leak). What I've learned today: 1) Always double check that you have setup autodl-irssi correctly. Do set sane daily limits on every filter. 2) Disable Flood. Honestly, it's not worth it. I've stopped and removed 2700+ torrent files manually. Even with only ~300 torrents Flood was still using ~550 MB memory (a good 4x more than rtorrent + rutorrent combined). At this stage I would say that Flood is only for casual users. 3) Be very careful with VPNs + container auto restart.
  5. Cat_Seeder

    [Support] binhex - rTorrentVPN

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

    [Support] Djoss - Nginx Proxy Manager

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

    [Support] binhex - rTorrentVPN

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

    [Support] Djoss - Nginx Proxy Manager

    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?
  9. Cat_Seeder

    [Support] binhex - rTorrentVPN

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

    [Support] binhex - rTorrentVPN

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

    [Support] binhex - rTorrentVPN

    I think so. Have a look at the documentation bellow: 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?
  12. Cat_Seeder

    [Support] binhex - rTorrentVPN

    @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_plaintext As 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_retry So 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).
  13. Cat_Seeder

    [Support] binhex - rTorrentVPN

    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 :).
  14. Cat_Seeder

    [Support] Djoss - Nginx Proxy Manager

    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=true Is IPv6 supported? I've tried manually adding listen [::]: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
  15. Cat_Seeder

    [Support] binhex - rTorrentVPN

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