Mylar - Not another RPC mount issue

QuickBox Support
#1

Hi,

I’ve decided to post my problem here since I’ve narrowed the problem down to the apache quickbox configuration I believe.

I’ve been struggling to get Mylar which is a fork based on SickRage/SickBeard to use RPC mount point of rutorrent to work with torrents.

I have looked through the threads here and here about the RPC issue within SickRage and it’s communication with rutorrent/torrent.

Similarly to SickRage, it has a place to specify the rtorrent Host and port as shown below:

I’ve used trying to use
http://SERVER_IP:80/RPC2 - 401 unauthorised
https://SERVER_IP:443/RPC2 - 401 unauthorised

http://SERVER_IP/sadpanda/RPC2 - 401 unauthorised
https://SERVER_IP/sadpanda/RPC2 - 401 unauthorised

http://SERVER_IP/rutorrent/plugins/httprpc/action.php - 401 unauthorised
http://SERVER_IP/rutorrent/plugins/rpc/action.php - 401 unauthorised

I’ve checked to see if its a bug within the software by trying another server of mine which is running a nginx based install and can confirm that the specified format https://SERVER_IP/SADPANDA works. In this case, /SADPANDA is what the scgi is called in the rutorrent user conf file whereas on Quickbox it’s called /RPC2.

I’ve tried all sorts of combinations to try and get it working but, I’m getting a 401 unauthorised access on anything relating to RPC and rutorrent. As seen above, I’ve tried using the httprpc plugin and still also getting a 401 unauthorised access.

Now 401 unauthorised access would suggest incorrect credentials. I thought so too, and so checked Mylar’s config file and can confirm that the user/pass to access my Quickbox rutorrent are indeed correct with no mistakes or typos. I can also rule out that because all I have to do is replace the server ip of the quickbox with my old server’s ip and the connection is successful.

I know that Quickbox is using apache and my second server is running nginx. My guess Is that it’s related to the way Apache2 is setup and somehow blocking blocking plugins like rpc and httprpc from working correctly when trying to access outside the localhost.

I’ve done some testing in programs like Sonarr that use RPC to communicate with rutorrent to narrow down the problem further.

I get a “Forbidden” error when I enable SSL and use port 443 and use the mount point /sadpanda/RPC2.
However when I use port 80 and disable SSL and leave the mount point the same /sadpanda/RPC2 connection is successful.

I’ve noticed in terms of accessing RPC via web It is definitely mounted at https://SERVER_IP/sadpanda/RPC2/ because I get a forbidden to access page using my browser. When I try to use http however, I get a page not found. Is this another reason to suspect it’s the way apache is setup and how scgi is configured with Quickbox?

I am in the midst of trying to migrate everything from my old server to my new quickbox based install one, and this is really the last hurdle but I’m a little stumped on how to fix this.

#2

I’ve never used Mylar but is there a setting in there for basic auth vs digest auth? You’ll want digest auth for quickbox.

#3

Unfortunately there is not a way to toggle between the two types of authentication like in SickRage. It could be that Mylar is trying to communicate via basic auth only.
I have reached out to the developer of this software to see what we can do.

I might try and edit the apache config of Quickbox to allow for basic auth which may confirm the problem.

#4

try:

localhost:443/sadpanda

or grab the scgi port specific to your install cat ~/.rtorrent.rc | grep port and

scgi://localhost:<scgiportnum>

auth details should be left blank if using the scgi port directly

sickrage works without issue on our setup… if it’s based on sickrage it should work, unless the author has changed things which you never know

#5

Thanks for the suggestion liara!

I tried localhost:443/sadpanda which resulted in a “Non Implemented” error. Looks like the developer hasn’t configured the program to accept formats such as localhost/127.0.0.1/0.0.0.0 etc

I then tried your next suggestion using the scgi link directly without the credentials and it worked! Thank you so much!

I did actually try that at one point following advice from the SickRage threads linked above, but I never knew the auth details had to be left blank! I had left it in thinking it was needed so it kept resulting in “Non Implemented” errors and so figured it wouldn’t work and so moved onto trying to get it to mount via RPC.

I have communicated to the developer to try and incorporate some changes including accepting digest authentication. Thanks again RXWatcher and liara.

#6

No worries :slight_smile:

If you think about it, this is the same port that ruTorrent uses to connect directly to rtorrent and communicate with the client. The port is not owned by apache, rather started by rtorrent upon boot. Therefore, it is not covered by basic/digest auth like when we mount it via SGCIMount in the apache config.

That said, the port is only available to localhost and is also randomized. I’ve given this thought and it would require more access (read: sudo) from a potential miscreant on a shared server than we currently allow for this direct access to rtorrent to be abused. It is the RPC mount in the apache configuration that exposes it remotely and we take care to protect that mount point with digest authentication.