Cat_Seeder

Members
  • Content Count

    81
  • Joined

  • Last visited

Everything posted by Cat_Seeder

  1. How many torrents are you seeding? And how fast are your drives? Rutorrent's PHP backend isn't exactly the fastest one, and honestly, after 1500 or so torrents it's easier to manage everything from the command line. I have SSD caches and well tuned Linux box, even so, deleting the data of a big torrent file using Rutorrent's File Manager often makes the UI unresponsive. If you are dealing with a few hundred torrents or less then rutorrent is manageable, otherwise I deeply recommend getting familiar with pyrocore. Using the CLI feels weird at first, but once you get used with it there's r
  2. You can make it run automatically on startup. See A2 here - https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md . For sinology: https://help.synology.com/developer-guide/integrate_dsm/run_with_system_boot.html
  3. And everything is working again. Thanks Binex, you are awesome. I know that eventually we'll need to jump off rtorrent-ps (unless a miracle happens and it pick up the pace again). Hopefully there's a way to do it without having to force users to expose RPC2 mounts and someone will find a way to make file manager before that. For now, I'm glad to be on good ol' versions :).
  4. For the old version of the container with rtorrent-ps + old version of file-manager (before it was split on its own repo) see: https://github.com/binhex/arch-rtorrentvpn/issues/96 For the latest version of the container + newest version of file manager I can't get it to work at all. Had to revert back. Please do let me know if you figure out.
  5. rtxmlrpc is part of pyrocore. @binhex, without pyrocore we'll not have rtxmlrpc, and reverting to xmlrpc means that port-forwarding will need /RPC2 mounts and we'll be back discussing security shenanigans. I understand that you want to get alway from rtorrent-ps, but can you maybe include an individual release of pyrocore in the image?
  6. I've installed an old version manually. Can't get the newer version working for the life of mine.
  7. Well, with the last update my ancient version of rutorrent's file manager plugin is officialy dead. Did anyone get the newer version of https://github.com/nelu/rutorrent-filemanager, https://github.com/nelu/rutorrent-filemanager-media and https://github.com/nelu/rutorrent-filemanager-share to work? I can't live without file manager.
  8. No comments about security, but it's certainly fast, and so far it has been stable. Thanks @binhex, sending another beer your way. By the way, did the autodl-rssi + recent version of php issue got sorted? Kind regards,
  9. The unofficial script below already works with OpenVPN. https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh
  10. PS. Looks like someone already managed to create a bash script to make port forwarding work with next-gen servers. It's experimental but according to the author comments it should also work with OpenVPN. https://github.com/thrnz/docker-wireguard-pia/blob/master/extra/pf.sh .
  11. I got port forwarding working with the Spainish server (one of the old ones), before that I could make it to work with servers in Switzerland but it no longer works for me. Unfortunately, until PIA stabilises old servers or provide APIs to port forward on next-gen servers there's no much that can be done other than server hopping and praying.
  12. Have a look at nginx logs for suspicious activity, particularly requests to /RPC2 from unusual IP addresses. Make sure to secure both ruTorrent and RPC2 with strong passwords (or disable RPC2 entirely I'd you don't need it). Don't use the defaulr auto-generated passwords as they are logged in plain text. If you can, do not expose anything over the internet (you can use a VPN to access your box). If you need to expose rutorrent do the internet then make sure to use a hardened reverse proxy (nginx-proxy / traefick, etc), Https only, with a real certificate (e.g., Let's Encrypt) and a strict fail
  13. You are looking for network.port_range.set, for further information check rtorrent guide at https://rtorrent-docs.readthedocs.io/en/latest/cookbook.html The container README.md also has a sample configuration for AirVPN demonstrating how to change incoming ports: https://github.com/binhex/arch-rtorrentvpn/blob/master/README.md
  14. Privoxy is starting fine at port 8118. Make sure to expose that port (e.g., -p 8118:8118 if you are using docker CLI) and then configure your end machine to use the host's IP address and port 8118. No need for FoxyProxy, Chrome / OS settings work fine. You can check that it's working on http://config.privoxy.org/
  15. Looks like it. I'm building a custom image from source and can't reproduce the issue either.
  16. Well, the easier alternative is to follow binhex advice and wait for someone more familiar with autodl-rutorrent codebase to have a look at the issue that you have reported. If you want to troubleshoot the issue by yourself I wouldn't expect much hand-holding, sorry. However, if you are ok with the frustration of being stuck, I'm not discouraging you from going down that route, trying to fix my own problems is how I got to learn a thing or two to share with the community. I'm not an arch guy but by what I understood you can clone the package source and run makepkg or install some
  17. Hey @td00, you can actually do it by yourself, although I've been running the container with PHP7 with no issues. In order to create your custom image running php5.6 first clone rtorrentvpn repo: https://github.com/binhex/arch-rtorrentvpn Then edit the following line to include the dependencies that you want: https://github.com/binhex/arch-rtorrentvpn/blob/master/build/root/install.sh#L53, for instance, you can replace php-fpm and php-geoip with php56-fpm and php56-geoip Finally you can run docker build command to build your custom image and run it locally w
  18. Hi Nora, unfortunately there ain't much that I can do to help since both problems are in the IRC side of things. As I've previously recommend, I would get acquainted with IRC (see https://opensource.com/article/16/6/irc-quickstart-guide for a quick start) as well as with the specific rules for each one of your trackers (you can generally find a Rules and FAQ for each private tracker) before even attempting to use autodl-irssi. Once you feel confident - IRC looks complicated but it really isn't - join each one of the tracker's respective IRC channels to figure out what went wrong.
  19. No problem. If I were you I would join your private tracker IRC channel and talk with mods to understand if you haven't been k-lined permanently and, maybe, if you can get unbanned (careful on how you approach mods, some private trackers are terrible). This is definitely on the IRC side of things instead of the container. If you are not familiar with NickServ I would Google for it (long story short, you want to register a unique username for your bot, make sure that only one process is ever using this nick and that autodl-irssi correctly identifies it).
  20. To my untrained eyes The PGID and PUID looks ok. I'll leave the in-depth analysis of the logs to binhex. I was thinking about your problem though, are you always testing and getting K-Lined on the same server? If so, could you try a different one? Nowadays most servers are pretty reasonable and use bots that only temporarily ban users logging as root (generally for a few minutes), however, there are exceptions to the rule...
  21. Try deleting the entire contents of /mnt/user/appdata/binhex-irssi and /mnt/user/Downloads/autodl. It's a long shot but some leftovers from previous runs may be getting in the way. PGID and PUID should be the same as the host user. That's ok. Docker doesn't map usernames (I.e., they don't match), all it does is to assign the host UID to the container user. For more info see: https://medium.com/@mccode/understanding-how-uid-and-gid-work-in-docker-containers-c37a01d01cf Start by simplifying your setup so that you can get acquainted with the container. Stop both conta
  22. -v /mnt/user/Downloads/autodl:/config \ -v /mnt/user/appdata/binhex-rtorrentirssi:/config If that's not a copy and paste error the above lines are wrong. What the two lines above are doing is to mount two different folders from the host (/mnt/user/Downloads/autodl and /mnt/user/appdata/binhex-rtorrentirssi) to the same place in the container (/config). This does not make much sense from a file system perspective and I really don't know what docker would try to do with it, this may be the cause of your issue. What you actually need is something like:
  23. Ok, I assume that this was done in the host right? (As in, your Unraid Box, not your container). You are mounting several volumes from your host into your container right? For instance, using the options bellow taken from rtorrentvpn's README: -v /root/docker/data:/data \ -v /root/docker/config:/config /root/docker/data and /root/docker/config are both folders in the host owned by a user (example: docker), this user most likely has read and write permissions to the folder that it owns. I'm not familiar with Unraid but if you have ssh access to
  24. Just to verify. 1. You have created a new user in the host right? 2. Have you given access to your shared folders in the host to this new user? 3. Have you passed the new user's UID and GID through PUID and PGID docker's environment variables as mentioned in https://github.com/binhex/arch-rtorrentvpn/blob/master/README.md? Just to clarify, no new user has to be created in the container. Actually, you don't even need to create a new user in the host unless you need isolated permissions for security reasons, all that is required for you to do is to figure out th
  25. Check out the conversation between WiperWoper, binhex and me starting bellow. Long story short, you need to set the right UID and GID.