[SOLVED] Docker-compose apache reverse proxy - no route to host

I am running pydio with docker-compose, with such recipe: https://gist.github.com/michimau/e054e2d17dfc51b9204d322826ecec3c

My reverse proxy is part of my docker stack with the simple rule: https://gist.github.com/michimau/85f354bb4e55e086fa0df8a33a48ec54

I have a rule in /etc/hosts to emulate dns against mypydio.com

I can run the init procedure without issues via http://mypydio.com, but when I try the first login i bump into the following error:

cells_1 | 2019-07-14T11:57:17.075Z ERROR pydio.rest.frontend Rest Error 401 {“error”: “Post http://mypydio.com/auth/dex/token: dial tcp: lookup mypydio.com on 127.0.0.11:53: no such host”}

apache log is set to info level and shows:

192.168.0.1 - - [14/Jul/2019:12:08:36 +0000] "GET / HTTP/1.1" 302 232 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
192.168.0.1 - - [14/Jul/2019:12:08:36 +0000] "GET /login HTTP/1.1" 200 49486 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
192.168.0.1 - - [14/Jul/2019:12:08:36 +0000] "POST /a/frontend/session HTTP/1.1" 200 444 "http://mypydio.com/login" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
192.168.0.1 - - [14/Jul/2019:12:08:36 +0000] "GET /plug/gui.ajax/res/themes/common/images/hires-photos/40/05.jpg HTTP/1.1" 200 11918 "http://mypydio.com/" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
192.168.0.1 - - [14/Jul/2019:12:08:36 +0000] "GET /plug/gui.ajax/res/themes/common/images/hires-photos/1200/05.jpg HTTP/1.1" 200 107341 "http://mypydio.com/login" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"
192.168.0.1 - - [14/Jul/2019:12:08:43 +0000] "POST /a/frontend/session HTTP/1.1" 401 558 "http://mypydio.com/login" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36"

nothing in the apache error log.

Any clue?

Hello,

Could you try with the internal URL set also with the domain,

     environment:
            - CELLS_BIND=mypdio:8080
            - CELLS_EXTERNAL=http://mypydio.com
            - CELLS_NO_SSL=1

Absolutely the same result, with “mypydio.com:8080”.
I get “404 Site mypydio.com is not served on this interface” with “mypydio:8080”

In addition, “mypydio” and “mypydio.com” are not resolvable within the “cells” container, so i doubt these will make any improvement.

This might be the issue,
the domains must be reachable from the container, could you try to sh inside the container and curl one of the domain.

I am afraid this is not how docker network works; “mypydio” and “mypydio.com” are not resolvable within the container as expected.
I am a little surprised this is not supposed to work, as it is very common microservice like scenario.
Both “nextcloud” and “seafile” do accept such layout.

How about enriching documentation providing a compelling example?

Maybe I was not clear but what I meant was that the container must be able for instance to curl http://mypydio.com.

Here’s why:

  • Trying to reach your instance of Cells from inside the container itself to ensure there is no network issue: Cells needs to access itself using its PUBLIC URL to generate the JWT token.

I will give an explicit example of this matter.

fyi, the file /etc/resolve.conf within the cells container is somehow influencing the response.

If i put:
nameserver 172.19.0.3 (got it from running “docker inspect | grep IP”), I have:
2019-07-15T11:18:32.368Z ERROR pydio.rest.frontend Rest Error 401 {“error”: “Post http://mypydio.com/auth/dex/token: dial tcp: lookup mypydio.com on 172.19.0.3:53: read udp 172.19.0.3:39303->172.19.0.3:53: read: connection refused”}

If i put:
nameserver cells, nameserver mypydio.com or nameserver mypydio:8080 or nameserver mypydio

2019-07-15T11:19:14.024Z ERROR pydio.rest.frontend Rest Error 401 {“error”: “Post http://mypydio.com/auth/dex/token: dial tcp: lookup mypydio.com on [::1]:53: dial udp [::1]:53: connect: cannot assign requested address”}

If I am understanding your lines correctly, cells container needs to access itself via internet (dns -> proxy container -> cells container) in order to have the token issued. Is that correct?

Not sure this would work without a proper dns service in the game (something i do not have for the time being in my test environment) nor in localhost.

I did not expect this behavior at all, a quick and dirty fix is making the container resolve to its loopback address by executing the following:

/bin/sh -c “echo ‘127.0.0.1 mypydio.com’ > /etc/hosts”

Make sure you don’t overwrite the wrong /etc/hosts

Also, check your internal (container) and external (load balancer) ports.
This cannot be fixed using /etc/hosts so they need to be identical.

i have given a try, but this results into a:
pydio.rest.frontend Rest Error 401 {“error”: “Post http://mypydio.com/auth/dex/token: dial tcp 127.0.0.1:80: connect: connection refused”}

from inside the cells container:
/pydio # wget -S 127.0.0.1
Connecting to 127.0.0.1 (127.0.0.1:80)
wget: can’t connect to remote host (127.0.0.1): Connection refused
/pydio # wget -S 127.0.0.1:8080
Connecting to 127.0.0.1:8080 (127.0.0.1:8080)
HTTP/1.1 302 Found
Content-Type: text/html; charset=utf-8
Location: /login
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Thu, 18 Jul 2019 20:55:40 GMT
Server:
X-Xss-Protection: 1; mode=block
Connection: close
Transfer-Encoding: chunked

saving to ‘index.html’
index.html 100% |**********************************************************************| 194k 0:00:00 ETA
‘index.html’ saved

So the reverse proxy seems to be correctly set.The problem is that (from the previous comment) pydio is trying on port 80 while it should try on 8080 instead. As in /etc/hosts the port cannot be set, ny idea on how to overcome this?

the trick seems to be to change in docker-compose.yml:

  • CELLS_BIND=0.0.0.0:80

Then the rules in the apache must be changed to use port 80 instead of 8080 too.