Web-ssl container gone?

1

Hi there - I may have missed it, but I haven’t seen this breaking change anounced anywhere?: https://git.tt-rss.org/fox/ttrss-docker-compose/commit/9b94702a4dcf5d9175c1a5faab3aec62890ccffd

I was aware that web-nginx was becoming the preferred container as frontend for tt-rss, but my understanding was that caddy would remain an option (December 20: “we’re going to keep caddy as an optional ssl-aware frontend”).

Was the deletion of both caddy containers accidental? Not only would that be a silent reversal of recently-announced plans, but there are still several references to the web or web-ssl containers - including in .env-dist (lines 8 and 9), and in the FAQ (“I’m running into 502 errors”, para 2).

I can explain the issue this seems to have caused me to run into:

I use caddy v2 as reverse proxy in front of several services. Using nginx or apache would be a painful alternative, since they don’t handle SSL certs (via ACME) automagically.

I’ve pointed the caddy reverse proxy at the new nginx-web container, but that container is returning 502 errors to caddy.

I think it’s because the caddy reverse proxy is somehow assuming that when I try to access TT-RSS via an HTTPS:// address, it will be able to itself connect to TT-RSS over HTTPS. Back when the web-ssl container existed, it would - no problem there. But now it doesn’t, and I think that’s where the errors are arising.

The following Caddyfile section, and most imaginable combinations/tweaks of it (including changing " ttrss-docker_web-nginx_1" for “localhost” or "127.0.0.1), don’t work:

reverse_proxy /tt-rss/* http://ttrss-docker_web-nginx_1:8280 {
header_up X-Forwarded-Proto https
}

tls {
    dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}

Grateful for any ideas/guidance here - the answer can probably be added as a new example to https://git.tt-rss.org/fox/ttrss-docker-compose/wiki/Home#how-do-i-put-this-container-behind-a-reverse-proxy

2

Just to add, in case it helps:

  • When on the server via SSH, I can curl http://127.0.0.1:8280/tt-rss/ just fine - this returns the warning about SELF_URL_PATH. All is well.

  • Evidently, with web-ssl gone, I can’t curl the https version of the above.

  • If I curl the actual domain, https://example.com/tt-rss/ , I get the usual good-looking stuff about SSL certs matching, HTTP/2 and TLS1.3 being used, etc, and then:

    • TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
    • Connection state changed (MAX_CONCURRENT_STREAMS == 250)!
      < HTTP/2 502
      < server: Caddy
      < content-length: 0
      < date: Sun, 14 Mar 2021 00:58:56 GMT
      <
    • Connection #0 to host [REDACTED] left intact

The corresponding error log entry for the caddy reverse proxy is:

{“level”:“error”,“ts”:1615683851.641759,“logger”:“http.log.error”,“msg”:“dial tcp 127.0.0.1:8280: connect: connection refused”,“request”:{“remote_addr”:“192.168.0.3:37460”,“proto”:“HTTP/2.0”,“method”:“GET”,“host”:“REDACTED”,“uri”:“/tt-rss/”,“headers”:{“User-Agent”:[“curl/7.68.0”],“Accept”:[“/”]},“tls”:{“resumed”:false,“version”:772,“cipher_suite”:4865,“proto”:“h2”,“proto_mutual”:true,“server_name”:“REDACTED”}},“duration”:0.000766143,“status”:502,“err_id”:“hnvhcp74w”,“err_trace”:“reverseproxy.(*Handler).ServeHTTP (reverseproxy.go:440)”}

3

Support for the caddy server has been deprecated for a while now and recently was removed entirely. You will have to figure out how to replicate your previous setup using nginx.

4

Thanks, that is precisely what my post is aiming to do.* Got any suggestions?

*Also to point out that limited caddy support was (1) still fox’s announced policy on the forums, and I’ve quoted that; (2) still featuring in both FAQs and .env-dist itself.

5

Sorry if I misinterpreted your post. The way I set up mine to use https was to set up an nginx instance outside the container with all the ssl stuff and reverse proxy to the container using the instructions from the https://git.tt-rss.org/fox/ttrss-docker-compose/wiki#faq wiki. The relevant section is near the bottom.

6

btw you can always simply put it back in docker-compose.override.yml and keep using it.

e: its probably a good idea to change caddyfile a bit then: instead of routing to fpm directly, make it go to web-nginx, this way this configuration would be future proof. maybe someone can post an example here.

7

Update: the problem seems to be related to trying to run the caddy reverse proxy using docker/docker compose.

When running caddy without containerising it, the following entry in the Caddyfile works fine (and could be added as an example in the FAQ, if you see fit to do so):

example.com {
        reverse_proxy /tt-rss/* http://127.0.0.1:8280
}

I don’t know what the problem is with my containerised caddy - it was running smoothly before. Maybe user error - perhaps when trying to figure out what had broken after my latest git pull (yes, I’m still salty about the unannounced deletion of the web and web-ssl containers!), I changed something, e.g. in the reverse proxy container’s docker-compose.yml . But whatever - problem “solved” (by using caddy without containerising it)

8

ITT: we learn that containers have their own localhost

9

I’m not saying you’re wrong that this might be the error, but remember that I was also trying the container by its name, and that I previously had it working, including by putting the containers all on the same virtual network…

10

using port 8280, right?

right. well, wrong.

this is the kind of issues you run into when you do things without any attempt to understand how they work.

11

Ah, great. Thank you. In case anyone else is like me - they only have to grapple with Docker/Docker Compose once every year or so - the answer is as follows:

If you’re running a Caddy v2 reverse proxy in a container, not bare on the box, then don’t get confused by the instructions in .env-dist (referring to port 8280); you can also ignore the FAQ’s instruction to “Don’t forget to pass X-Forwarded-Proto to the container if you’re using HTTPS,” (with Caddy, this is unnecessary - Caddy passes that header automatically).

Instead, put your reverse proxy container in the same Docker network as the container serving TT-RSS** (probably ttrss-docker_web-nginx_1), and then in the reverse proxy’s Caddyfile, use the following:

example.com {
        reverse_proxy /tt-rss/* http://ttrss-docker_web-nginx_1
}

** If using docker-compose, this is as simple as putting the following at the bottom of the docker-compose.yml files for your reverse proxy and for TT-RSS:

networks:
  default:
    external:
      name: proxy
12

a full caddy v2 sample with letsencrypt would probably be useful to some people, maybe deserving its own thread.

e: and a faq entry / wiki link

are those confusing? i think the comments should mention that this is the external port.

if the description is not clear enough (there and otherwise), clarifications are always welcome.

13

That literally is the full Caddyfile for my site, example.com - Caddy will automatically (try to) fetch an SSL cert from LetsEncrypt for “example.com” (unless I tell it otherwise, it will assume I want example.com accessible by HTTPS on port 443)

If I have other things running on example.com, then I can have extra “reverse_proxy” lines for each one.