Hello,
I’m in the process of migrating an old tt-rss instance (direct install) to a new dockerized version, which will be run on the same physical machine.
I’ve already gone through the migration steps to upgrade the database level, backup the migration data and import it to the new instance, now it’s about setting the external access.
My tt-rss runs on a small server (let’s call its hostname myserver) with a static IP from the local LAN.
However, the gateway/firewall is also forwarding a port to this server, so that tt-rss is reachable from outside my LAN.
To access it that way, there is a dynamic DNS mapping from the ‘public’ name
of my tt-rss, let’s call it my.public.net and the IP currently assigned by the ISP.
On the old instance, I was setting SELF_URL_PATH to http://my.public.net:<port>
However, with the new dockerized instance, if do the same, I get the login page, but I’m not able to login with any login.
The only way to get it working is to set SELF_URL_PATH to http://myserver:<port>
What is the recommended way to set up such environment?
Thanks
tt-rss (container, bound to 127.0.0.1:custom_port) ← nginx (SSL, for example letsencrypt, bound to standard ports i.e. 443, forwarding to the container on the custom port) ← router with a public IP
any other containerized services go behind the same nginx on different subdomains etc
Simply it resets to the blank form.
Hmm… Initially I thought it was the same behavior as with a wrong user/password, but that’s not correct because in this case there is no error message.
Ok. So, what hostname should I use for the SELF_URL_PATH ?
what’s your self_url_path set to? it could be custom port breaking things, docker setup is really supposed to be used with a reverse proxy.
always external FQDN.
e: what happens if you set it to your external IP address:port? something like 1.1.1.1:8080 should work, that’s more or less how my dev environment looks.
docker container on a custom port (HTTP_PORT=8380) not bound to localhost, plain HTTP, no reverse proxy (well, obviously). so, custom ports shouldn’t break login form.
Sure, in the end I was going to wrap it all with SSL (which also will be exposed on a non-443 port) but just to separate the problems I was keeping it for last.