Docker-DocumentServer icon indicating copy to clipboard operation
Docker-DocumentServer copied to clipboard

DocumentServer does not respect HTTP_PROXY, HTTPS_PROXY variables

Open Gnork opened this issue 4 years ago • 8 comments

Do you want to request a feature or report a bug?

bug

What is the current behavior?

In our network, we have to use an outgoing HTTP proxy, otherwise the Firewall will block the request. The DocumentServer needs to contact the Nextcloud server and therefore needs to do outgoing requests through the proxy. The DocumentServer is started via Docker. We specify the proxy by setting environment variables in the Container using the Docker options -e HTTP_PROXY=proxy.example.com -e HTTPS_PROXY=proxy.example.com -e http_proxy=proxy.example.com -e https_proxy=proxy.example.com . The DocumentServer ignores these settings and does not use the proxy. As a result, the automatic download of a Document from Nextcloud to the DocumentServer has a timeout (due to the firewall). Timeout errors from nodejs request can be seen in docker logs.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

Requires setup of an HTTP proxy and firewall rules to prevent request from bypassing the proxy.

What is the expected behavior?

The expected behaviour is, that the software in the container picks these variables up and uses the proxy, as many other Linux programs do. ButPreferably, DocumentServer should support HTTP_PROXY, HTTPS_PROXY, NO_PROXY and/or http_proxy, https_proxy, no_proxy environment variables

Did this work in previous versions of DocumentServer?

Don't know. First time user.

DocumentServer version:

docker.io/onlyoffice/documentserver:5.5.0.165 (latest)

Operating System:

Debian 9

Browser version:

Not relevant

Gnork avatar Apr 07 '20 14:04 Gnork

@agolybev please take a look, do we have some workaround for this

And according to https://superuser.com/questions/944958/are-http-proxy-https-proxy-and-no-proxy-environment-variables-standard those variables are not standart, but more a convention (which seems we do not support)

ShockwaveNN avatar Apr 07 '20 15:04 ShockwaveNN

For anybody coming across this issue. There is a work around, that requires the following:

  1. Running a Redsocks proxy in http-connect mode on the host, that forwards all traffic to the outside proxy I have described above.
  2. Redirecting outgoing traffic of your host to the Redsocks proxy using IPtables
  3. Running the DocumentServer Docker container with the --net=host flag, such that the container traffic goes through redsocks
  4. Patching the nginx config in the DocumentServer container image, such that the listening port is something other than port 80, as it clashes with the Apache/Nginx reverse proxy, that is already running on the host (due to --net=host).

@ShockwaveNN Do you know if there is a config option to change the nginx listening port in the Docker container?

Gnork avatar Apr 10 '20 17:04 Gnork

Do you know if there is a config option to change the nginx listening port in the Docker container?

There is no such option, but you can replace it in container with something like this:

sed -i 's/80/8008/g' /etc/onlyoffice/documentserver/nginx/ds.conf
service nginx reload
``

ShockwaveNN avatar Apr 13 '20 07:04 ShockwaveNN

That's exactly what I did. Except, there is no need for the service nginx reload line when the Docker image is patched before running the container. I think that having this configuration option would be a nice addition as it makes the adoption of the Docker image easier. Should be quite easy to implement, too.

While this workaround can be done, it is not convenient at all and in my opinion does not replace proper support for the proxy environment variables.

Gnork avatar Apr 13 '20 16:04 Gnork

@Gnork Yeah, it's better to create separate issue for changing default port. Thank you

ShockwaveNN avatar Apr 14 '20 06:04 ShockwaveNN

Nevertheless, the workaround is a little bit useless when running multiple instances on one host, is there any other way out of this problem? Why is the HTTP client inside the docserver not using HTTP_PROXY or http_proxy, etc. when the coresponding environment variable is set. Still in 7.2 or 7.3 it doesnt work

trickert76 avatar Apr 13 '23 16:04 trickert76

The problem, that the service ignores the ENV vars seems to be, that it is using supervisord to start the service and it defines some internal env vars. So, I'm overriding this config files via a volume, like

    volumes:
      - "./conf/ds-docservice.conf:/app/ds/setup/config/supervisor/ds/ds-docservice.conf:ro"
      - "./conf/ds-converter.conf:/app/ds/setup/config/supervisor/ds/ds-converter.conf:ro"

which contains something like this

[program:converter]
command=/var/www/onlyoffice/documentserver/server/FileConverter/converter
directory=/var/www/onlyoffice/documentserver/server/FileConverter
user=ds
environment=NODE_ENV=production-linux,NODE_CONFIG_DIR=/etc/onlyoffice/documentserver,NODE_DISABLE_COLORS=1,APPLICATION_NAME=onlyoffice,HTTP_PROXY=http://10.255.0.14:8888,HTTPS_PROXY=http://10.255.0.14:8888,NO_PROXY="10.255.0.5,127.0.0.1,[::1]"
stdout_logfile=/var/log/onlyoffice/documentserver/converter/out.log
stdout_logfile_backups=0
stdout_logfile_maxbytes=0
stderr_logfile=/var/log/onlyoffice/documentserver/converter/err.log
stderr_logfile_backups=0
stderr_logfile_maxbytes=0
autostart=true
autorestart=true

where 10.255.0.14:8888 is the forward proxy and 10.255.0.5 is the reverse proxy.

Then the error changes, so the service is reacting on HTTP_PROXY env variable, but the service is using websockets for communication and I'm not 100% sure, what should be in NO_PROXY var to avoid websocket proxying (which doesnt really work, as far as I know). I don't really understand, what is the endpoint of the websocket (converter, docservice, upstream proxy, internal nginx, ...)

6242#6242: *9 connect() failed (111: Unknown error) while connecting to upstream, client: 10.255.0.5, server: , request: "GET /7.3.3-49/doc/81649929212/c/?EIO=4&transport=websocket HTTP/1.1", upstream: "http://[::1]:8000/doc/81649929212/c/?EIO=4&transport=websocket", host: "onlyoffice.mydomain.tld"
6242#6242: *9 connect() failed (111: Unknown error) while connecting to upstream, client: 10.255.0.5, server: , request: "GET /7.3.3-49/doc/81649929212/c/?EIO=4&transport=websocket HTTP/1.1", upstream: "http://127.0.0.1:8000/doc/81649929212/c/?EIO=4&transport=websocket", host: "onlyoffice.mydomain.tld"

Maybe somebody has a better idea.

trickert76 avatar Apr 13 '23 17:04 trickert76

Hello, sorry for the late reply, i created ticket #67009 to implement this.

igwyd avatar Mar 20 '24 06:03 igwyd