If --bind is not an external iface, then Go’s server is not reachable from the outside and the very first consequence is that no LE certificate is generated => installer unavailable.
If --bind is an external IP address, then an apparently SSL-enabled socket binds but no certificate is provided to client (invalid SSL), eg; openssl s_client -crlf -connect xxxx:443 -showcerts : no peer certificate available
If --bind is set to <external hostname:external port>, then the installer succeeds but:
I’m still having the warning about giving public access to the broker.
Note: The documentation says --bind must be a server name .
And on top of that there is the warning: Warning: no private IP detected for binding broker. Will bind to XXX, which may give public access to the broker.
I’m having hard time understanding the reasons for this message. It even happened when setting --bind to localhost (but see the above issue n°1).
So, what’s the right way to set --bind ?
Documentation excerpt:
Internal URL: it defines the interface where the internal webserver of the application is bound. It MUST contain a server name and a port, should be of this form :.
External URL: This is the main entry point from the outside world, the address you will communicate to your endusers. It typically differs from the internal URL when you are behind a reverse proxy or in a container.
If pydio cells is running in a docker container and is reverse proxied via another docker container, binding the server to localhost or 127.0.0.1 will prevent the reverse proxy container from accessing it.
Binding to 0.0.0.0 will on the other hand allow that connection.
External url is the reverse proxy address and I believe is used for generating share links and such.
I’m using the linuxserver pydio cells image, which by default binds to 0.0.0.0 with https disabled, and I’m reverse proxying it via the linuxserver letsencrypt image, which connects to the pydio-cells container directly via docker network (utilizing the container name as dns host name), and handles the https connection via ssl certs. Here’s the built-in proxy conf for it:
# make sure that your dns has a cname set for pydio-cells
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name pydio-cells.*;
include /config/nginx/ssl.conf;
client_max_body_size 0;
# enable for ldap auth, fill in ldap details in ldap.conf
#include /config/nginx/ldap.conf;
location / {
# enable the next two lines for http auth
#auth_basic "Restricted";
#auth_basic_user_file /config/nginx/.htpasswd;
# enable the next two lines for ldap auth
#auth_request /auth;
#error_page 401 =200 /login;
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_pydio_cells pydio-cells;
proxy_pass http://$upstream_pydio_cells:8080;
}
location /ws {
include /config/nginx/proxy.conf;
resolver 127.0.0.11 valid=30s;
set $upstream_pydio_cells pydio-cells;
proxy_pass http://$upstream_pydio_cells:8080;
proxy_buffering off;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Thank you @aptalca. This loopback vs non-routable IP now makes perfect sense in the context of containers. Still, Pydio cells is provided with a built-in webserver. If using it, is there any drawbacks in binding on the public/routable IP address (as the warning suggests), as long as I’m behind a CF reverse-proxy?