floodServerProxy & 502 Bad Gateway

Created on 12 Nov 2017  ยท  16Comments  ยท  Source: Flood-UI/flood

@jfurrow what's up with bd8a5fe152c06cf0d359521774678ab60251c18e, what is floodServerProxy: 'http://127.0.0.1', for?

I tried to removed it, put it to floodServerProxy: 'http://127.0.0.1', and floodServerProxy: 'https://127.0.0.1', but none worked, I always get 502 Bad Gateway from nginx. Of course I restarted flood service each time I made a change. And also restarted nginx.

I currently don't know if it's a flood issue or a nginx one due to a nginx update. But as my others virtual servers are working and flood is the only one that is proxified and you introduce a new floodServerProxy, so I think the new parameter in config.js is in cause.

bug code linux waiting feedback

Most helpful comment

@dcousens Oh wait, that's not going to work...

The only reason the example you provided works is because you're forwarding all requests from subdirectory /my/foo to the Flood server _and_ all of the requests from the root (/) to the Flood server. This won't work for people who want Flood to be completely isolated to a single subdirectory (which is most people who are interested in using the reverse proxy, I think).

People want to be able to run multiple web services and serve them on a single host/port. So Flood's assets and API requests need to be accessible via a subdirectory on the domain, but _not_ the root of the domain. For example, let's say I want the Flood app to be accessible at john.com/flood, but I want john.com to serve a completely different resource. There's no way to do that, as far as I know, without telling Flood where it should be making requests. This is why both the nginx rewrite rule and Flood's baseURI configs are necessary.

All 16 comments

I just found that there was a wiki page wiki for that. My config is different but worked before.

Actually in config.js I have baseURI: '/', and my nginx config for flood looks like:

location / {
  proxy_pass https://127.0.0.1:3000;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection 'upgrade';
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
 }

So what do I need to set for floodServerProxy? Do I need the rewrite rule?

A snip from my own nginx configuration, with added example

        upstream flood { server 127.0.0.1:9900; }

        # snip

        server {
                listen 80;
                server_name _;

                location / {
                        proxy_pass http://flood;
                        proxy_max_temp_file_size 0; # necessary for downloads >1.1G
                }

                location /my/foo {
                        proxy_pass http://flood; # https://.../my/foo/overview becomes http://flood/overview
                        proxy_max_temp_file_size 0;
                }
        }

The re-write rule is not necessary.
If you suffix the proxy_pass URL with /, as in http://flood/, then you will have issues.

baseURI: '/' is an unnecessary configuration option IMHO.

Thanks @dcousens .So my nginx config should be good, and in fact I'm sure it is because it was working until a few days ago.

what's up with bd8a5fe, what is floodServerProxy: 'http://127.0.0.1', for?

@noraj1337 That's part of a massive refactor, so it makes sense that things broke. floodServerProxy is _only_ meant to be used for local development by webpack-dev-server, it just proxies requests to a specific (maybe external) Flood instance (I found this useful to test against different Flood instances). The floodServerProxy string is passed to prepareProxy, which is a utility in create-react-app that generates a proxy config for webpack-dev-server.

@dcousens So with the configuration you provided, we don't need baseURI in config.js, nor the rewrite rule in the nginx config? I'll have to test it, but it would be awesome to get rid of that the baseURI config option.

@dcousens I just tested the example you provided, and I'm thrilled to see that it works as expected. So baseURI should be removed from Flood, and the nginx config example in the wiki should be updated. This is going to break a bunch of people's nginx proxies, but I think it's worth it.

@dcousens Oh wait, that's not going to work...

The only reason the example you provided works is because you're forwarding all requests from subdirectory /my/foo to the Flood server _and_ all of the requests from the root (/) to the Flood server. This won't work for people who want Flood to be completely isolated to a single subdirectory (which is most people who are interested in using the reverse proxy, I think).

People want to be able to run multiple web services and serve them on a single host/port. So Flood's assets and API requests need to be accessible via a subdirectory on the domain, but _not_ the root of the domain. For example, let's say I want the Flood app to be accessible at john.com/flood, but I want john.com to serve a completely different resource. There's no way to do that, as far as I know, without telling Flood where it should be making requests. This is why both the nginx rewrite rule and Flood's baseURI configs are necessary.

@noraj1337 To be honest, I have no idea how your configuration worked _without_ the rewrite rule, unless Flood was also accessible at the root of your host. It is necessary, as is the baseURI option. I just tested this and it's still working as expected.

@noraj1337 Is this working for you with the rewrite nginx rule? Can we close the issue?

@jfurrow Stop me if I'm wrong. So I can remove floodServerProxy from my config.js. In my case baseURI is not needed but it is better to keep it and in general it is needed. And I need to add the rewrite in my nginx flood.conf.

So I updated it to:

 location / {
  proxy_pass https://127.0.0.1:3000;
  rewrite ^/(.*) /$1 break;
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection 'upgrade';
  proxy_set_header Host $host;
  proxy_cache_bypass $http_upgrade;
 }
}

I restarted nginx and flood, but flood broke into an error due to argon2, I need to fix this before telling you if this worked or not.

TL;DR : I know it's a long comment, sorry :/

I re-updated flood and rebuilt all. I tried with the new config I told you in my previous comment.
So see my previous comment for my flood nginx conf and here my config.js:

const CONFIG = {
  baseURI: '/',
  dbCleanInterval: 1000 * 60 * 60,
  dbPath: './server/db/',
  floodServerHost: '127.0.0.1',
  floodServerPort: 3000,
  /*floodServerProxy: 'https://127.0.0.1',*/
  maxHistoryStates: 30,
  pollInterval: 1000 * 5,
  secret: 'anonymized',
  scgi: {
    host: 'localhost',
    port: 5000,
    socket: false,
    socketPath: '/tmp/rtorrent.sock'
  },
  ssl: true,
  sslKey: '/srv/flood/ssl/flood.key',
  sslCert: '/srv/flood/ssl/flood.crt',
  torrentClientPollInterval: 1000 * 2
};

module.exports = CONFIG;

Flood start without error and is running but nginx still giving me http 502 bad gateway so this is a proxy error of course.

So here is my nginx version:

$  nginx -V
nginx version: nginx/1.13.6
built with OpenSSL 1.1.0f  25 May 2017 (running with OpenSSL 1.1.0g  2 Nov 2017)
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --sbin-path=/usr/bin/nginx --pid-path=/run/nginx.pid --lock-path=/run/lock/nginx.lock --user=http --group=http --http-log-path=/var/log/nginx/access.log --error-log-path=stderr --http-client-body-temp-path=/var/lib/nginx/client-body --http-proxy-temp-path=/var/lib/nginx/proxy --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-cc-opt='-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -D_FORTIFY_SOURCE=2' --with-ld-opt=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now --with-compat --with-debug --with-file-aio --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_degradation_module --with-http_flv_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-pcre-jit --with-stream --with-stream_geoip_module --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-threads

I don't see a change that can be breaking in recent nginx changelog.

So I stopped flood again and started it back, and sometimes I get an error, and when running it manually with sudo npm start same error:

$ sudo npm start

> [email protected] start /srv/flood
> node server/bin/start.js

Failed to start web server:
Error: Could not locate the bindings file. Tried:
 โ†’ /srv/flood/node_modules/argon2/build/argon2.node
 โ†’ /srv/flood/node_modules/argon2/build/Debug/argon2.node
 โ†’ /srv/flood/node_modules/argon2/build/Release/argon2.node
 โ†’ /srv/flood/node_modules/argon2/out/Debug/argon2.node
 โ†’ /srv/flood/node_modules/argon2/Debug/argon2.node
 โ†’ /srv/flood/node_modules/argon2/out/Release/argon2.node
 โ†’ /srv/flood/node_modules/argon2/Release/argon2.node
 โ†’ /srv/flood/node_modules/argon2/build/default/argon2.node
 โ†’ /srv/flood/node_modules/argon2/compiled/8.8.1/linux/x64/argon2.node
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] start: `node server/bin/start.js`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2017-11-17T18_42_31_577Z-debug.log

And here is the full log:

0 info it worked if it ends with ok
1 verbose cli [ '/usr/bin/node', '/usr/bin/npm', 'start' ]
2 info using [email protected]
3 info using [email protected]
4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info lifecycle [email protected]~prestart: [email protected]
6 info lifecycle [email protected]~start: [email protected]
7 verbose lifecycle [email protected]~start: unsafe-perm in lifecycle true
8 verbose lifecycle [email protected]~start: PATH: /usr/lib/node_modules/npm/bin/node-gyp-bin:/srv/flood/node_modules/.bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
9 verbose lifecycle [email protected]~start: CWD: /srv/flood
10 silly lifecycle [email protected]~start: Args: [ '-c', 'node server/bin/start.js' ]
11 silly lifecycle [email protected]~start: Returned: code: 1  signal: null
12 info lifecycle [email protected]~start: Failed to exec start script
13 verbose stack Error: [email protected] start: `node server/bin/start.js`
13 verbose stack Exit status 1
13 verbose stack     at EventEmitter.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:280:16)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at EventEmitter.emit (events.js:213:7)
13 verbose stack     at ChildProcess.<anonymous> (/usr/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
13 verbose stack     at emitTwo (events.js:125:13)
13 verbose stack     at ChildProcess.emit (events.js:213:7)
13 verbose stack     at maybeClose (internal/child_process.js:927:16)
13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
14 verbose pkgid [email protected]
15 verbose cwd /srv/flood
16 verbose Linux 3.14.32-xxxx-grs-ipv6-64
17 verbose argv "/usr/bin/node" "/usr/bin/npm" "start"
18 verbose node v8.8.1
19 verbose npm  v5.5.1
20 error code ELIFECYCLE
21 error errno 1
22 error [email protected] start: `node server/bin/start.js`
22 error Exit status 1
23 error Failed at the [email protected] start script.
23 error This is probably not a problem with npm. There is likely additional logging output above.
24 verbose exit [ 1, true ]

And here just a reminder of my flood service, I don't if the --production is still used or not.

$ cat /etc/systemd/system/flood.service
[Unit]
Description=Flood, web interface for rTorrent
After=network.target

[Service]
User=flood
ExecStart=/usr/bin/npm start --production /srv/flood
WorkingDirectory=/srv/flood/
Restart=on-failure

[Install]
WantedBy=multi-user.target

I also used npm-check-updates to check if some important dependencies are outdated.

$  sudo ncu
Using /srv/flood/package.json
[..................] \ :
 axios                    ^0.16.2  โ†’  ^0.17.1
 babel-core                6.25.0  โ†’   6.26.0
 babel-eslint               7.2.3  โ†’    8.0.2
 css-loader                0.28.4  โ†’   0.28.7
 d3                        ^3.5.6  โ†’  ^4.11.0
 debug                     ^2.2.0  โ†’   ^3.1.0
 feedsub                   ^0.4.0  โ†’   ^0.5.1
 file-loader               0.11.2  โ†’    1.1.5
 jsonwebtoken              ^7.0.1  โ†’   ^8.1.0
 passport                  ^0.3.2  โ†’   ^0.4.0
 passport-jwt              ^2.1.0  โ†’   ^3.0.1
 postcss-loader             2.0.6  โ†’    2.0.8
 react                    ^15.6.1  โ†’  ^16.1.1
 react-dev-utils           ^3.0.2  โ†’   ^4.2.1
 react-dom                ^15.6.1  โ†’  ^16.1.1
 react-dropzone            ^3.4.0  โ†’   ^4.2.3
 react-error-overlay       ^1.0.9  โ†’   ^3.0.0
 react-router              ^3.0.0  โ†’   ^4.2.0
 style-loader              0.18.2  โ†’   0.19.0
 url-loader                 0.5.9  โ†’    0.6.2
 babel-jest                20.0.3  โ†’   21.2.0
 eslint                    3.19.0  โ†’   4.11.0
 eslint-config-airbnb     ^15.1.0  โ†’  ^16.1.0
 eslint-config-react-app   ^1.0.5  โ†’   ^2.0.1
 eslint-loader              1.7.1  โ†’    1.9.0
 eslint-plugin-flowtype    2.34.0  โ†’   2.39.1
 eslint-plugin-jsx-a11y    ^5.1.1  โ†’   ^6.0.2
 eslint-plugin-react        7.1.0  โ†’    7.4.0
 jest                      20.0.4  โ†’   21.2.1

The following dependencies are satisfied by their declared version range, but the installed versions are behind. You can install the latest versions without modifying your package file by using npm update. If you want to update the dependencies in your package file anyway, run ncu -a.

 babel-preset-react-app        ^3.0.1  โ†’   ^3.1.0
 chalk                         ^2.0.1  โ†’   ^2.3.0
 extract-text-webpack-plugin   ^3.0.0  โ†’   ^3.0.2
 moment                       ^2.14.1  โ†’  ^2.19.2
 react-custom-scrollbars       ^4.0.0  โ†’   ^4.2.1
 tar-stream                    ^1.5.4  โ†’   ^1.5.5
 webpack-bundle-analyzer       ^2.9.0  โ†’   ^2.9.1
 source-map-loader             ^0.2.1  โ†’   ^0.2.3
 webpack-dev-server            ^2.6.1  โ†’   ^2.9.4

Run ncu with -u to upgrade package.json

$ sudo ncu -g
[..................] / :
All global packages are up-to-date :)

So nothing for node-gyp or argon2.

In conclusion when sometimes flood service says it is running, it's no true, it's false positive, in reality it's always failing due to this error that's why nginx gives 502 error because flood is not working.

If you suffix the proxy_pass URL with /, as in http://flood/, then you will have issues.

location /flood/ {
    proxy_pass http://localhost:3000/;
}

@JohnFlowerful As you can see my proxy pass is proxy_pass https://127.0.0.1:3000; without trailing /. it seems to be an issue with argon2.

  1. I removed node_modules
  2. chown all the folder to my flood user (some files were owned by root)
  3. auth with flood user su flood
  4. do the install npm i without sudo this time so without --unsafe-perm too and it install worked without --python="/usr/bin/python2" maybe because this time python2 is installed and in the path.
  5. Still as flood user npm run build
  6. I removed the --production flag from my flood systemd service
  7. Restarted nginx and flood
  8. This time I have no fails during the install, build or when launching flood but still get 502 bad gateway
  9. It's hard to check localhost connectivity on my server because all the web stuff is built without SSL support and I'm having SSL fails with every tools. See #543

@jfurrow In fact I think that nginx is unable to connect to flood because of the SSL alert:

$ sudo tail -1 /var/log/nginx/error.log
2017/11/20 19:30:08 [error] 31459#31459: *97 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 82.64.24.82, server: seedbox2.myowncloud.cf, request: "GET / HTTP/2.0", upstream: "https://127.0.0.1:3006/", host: "seedbox2.myowncloud.cf"

Because on archlinux openssl is built without ssl support: see openssl PKGBUILD

So this issue depends of #543

I need someone to confirm that installing flood (fresh install) from the git (not the release) AND using ssl in config.js results into a breaking installation (at least for systems like archlinux that forbid outdated security protocols).

After confirmation we will be able to say that's a critical bug because it's blocking.

Solving issue #543 will solve this one by the way.

For people having problems with proxy: https://github.com/Flood-UI/flood/wiki/Using-Flood-behind-a-reverse-proxy#served-from-the-root

Now config.js also says

  // Used for development. See the "Local Development" section of README.md
  // for detail.
  //floodServerProxy: 'http://127.0.0.1:3000',
Was this page helpful?
0 / 5 - 0 ratings

Related issues

noraj picture noraj  ยท  4Comments

abduct picture abduct  ยท  3Comments

rarescosma picture rarescosma  ยท  3Comments

EternalBlack picture EternalBlack  ยท  6Comments

runaroundhome picture runaroundhome  ยท  6Comments