SABnzbd Forums

I've been running SAB for a few years....rock solid, no issues whatsoever. I've also had haproxy running in front of it as a reverse proxy, so I can access it via subdomain. Again, this has worked flawlessly for a few years.

Starting last week (I believe after the latest upgrade), I cannot access the full GUI remotely. Internally, it's fine. To be clear, I CAN access the GUI, however, the history does not show, and when I go into the Interface Options, every item under Status shows as 'loading'. I've tried changing the host address from 0's, to localhost, to the actual IP....all have the same result.

Any thoughts would be greatly appreciated.

I've also updated the 'external internet access' field to Full Web Interface' as well....just to be safe.

So the basic interface loads, just not the rest?
There have been changes in the ways URLs are build.
When you inspect the requests (Right click on the page >Inspect Element, then Connections/Network tab)
What does it show as error why it cannot load the page? Assuming it's a proxy problem here with url rewriting.

Correct. The page loads, but history/postprocessing isn't there. Also, the Status/Interface options all show 'loading'. The errors I see are:

Can you check what the details are for the 404 ones.

FYI....I'm using Cloudflare for DNS, and am routing all traffic through their servers. However, I've bypassed Cloudflare, and the same issue occurs. On second look, there are a couple of 503's as well. The 503 and 404 headers are as follows:


GET /tapi?mode=history&search=&failed_only=0&start=0&limit=10&last_history_update=135&output=json&apikey=xxxxxxxxxxx&_=1502207733252 HTTP/1.1
Host: sabnzbd.xxxxxx.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://sabnzbd.xxxxxx.com/
X-Requested-With: XMLHttpRequest
Cookie: _ga=GA1.2.714002401.1495735318; __cfduid=xxxxxxxxxxxxxx
Connection: keep-alive

HTTP/2.0 503 Service Unavailable
Date: Tue, 08 Aug 2017 15:55:42 GMT
Content-Type: text/html
Cache-Control: no-cache
Server: cloudflare-nginx
CF-RAY: 38b3a955885237e6-ATL
X-Firefox-Spdy: h2


GET /static/bootstrap/fonts/glyphicons-halflings-regular.woff HTTP/1.1
Host: sabnzbd.xxxxxx.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: application/font-woff2;q=1.0,application/font-woff;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: identity
Referer: https://sabnzbd.xxxxxx.com/static/boots ... ss?p=24176
Cookie: _ga=GA1.2.714002401.1495735318; __cfduid=xxxxxxxxxxxxc
Connection: keep-alive
Cache-Control: max-age=0

HTTP/2.0 404 Not Found
Date: Tue, 08 Aug 2017 15:55:33 GMT
Content-Type: text/html
Vary: Accept-Encoding
cf-cache-status: HIT
Server: cloudflare-nginx
CF-RAY: 38b3a91eccfb37e6-ATL
X-Firefox-Spdy: h2

This is beyond my knowledge. It's clearly a proxy problem, but I am not sure if it's related to sabnzbd at all.
For example it mentions HTTP 2, while sabnzbd only does 1.1.

Is it possible to start from basic: can you access it directly by entering the IP?

From within my internal LAN, I can enter the IP, and all works as expected. It's only when I access from outside, via haproxy, that the issue occurs.

Note that this issue only started happening a couple of days ago.

Some additional info.....I just changed the web interface from Glitter to smpl, and no issues were observed. Is there something different with the way Glitter sends the URL?

Even more info:

The two URL's that are throwing a 404 are:

https://sabnzbd.xxxxxx.com/static/boots ... gular.woff
https://sabnzbd.xxxxxx.com/static/boots ... ular.woff2

When I check my sabnzbd server under /usr/share/sabnzbdplus/interfaces/Glitter/templates/static/bootstrap/fonts, I only see:

lrwxrwxrwx 1 root root 80 Jul 27 14:41 glyphicons-halflings-regular.eot -> ../../../../../../../javascript/bootstrap/fonts/glyphicons-halflings-regular.eot
lrwxrwxrwx 1 root root 80 Jul 27 14:41 glyphicons-halflings-regular.svg -> ../../../../../../../javascript/bootstrap/fonts/glyphicons-halflings-regular.svg
lrwxrwxrwx 1 root root 80 Jul 27 14:41 glyphicons-halflings-regular.ttf -> ../../../../../../../javascript/bootstrap/fonts/glyphicons-halflings-regular.ttf

This explains the 404. My question is...how do I add the .woff files?

Well...on second look, that's probably a red herring. I checked the glyphicons-halflings-regular.woff request from internal (using the LAN IP), and the same 404 is given. But...the history and Web interface settings are all there and functioning.

I'm at a loss.

Yes, you should check why the calls to /tapi are not functioning. Those should be listed there too if nothing is showing.

I don't see an issue with /tapi......all return a 200ok.

I did compare the console output from https://sabnzbd.hostname.com to https://x.x.x.x:port

The ONLY difference I see is, in the failing scenario, I see a ReferenceError: css is not defined. When I inspect the html from that line, I see:


<html>
<head>
<script type="text/javascript">
<!--
location.href = location.protocol + '//' + location.hostname + (location.port ? ':' + location.port : '') + '/sabnzbd/' ;
//-->
</script>
</head>
<body><br/></body>
</html>

Ok...the good news is, I've fixed the issue. The bad news is, I have no idea why this fixed the issue.

Under my Haproxy global config, I was passing through the following cyphers:

ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
tune.ssl.default-dh-param 2048

Once I removed this block, the issue went away. Anybody have any ideas why this would break SAB?

That's strange.
Seems mismatch between the cipher sets of browser/cloudflare/..?