Letsencrypt provisioning failed when deploying to root at new site

[jernst]

Check that Decko exempts mapping .well-known.

[jernst]

It does not, so the Letsencrypt challenge will fail.

[ethn]

Is the point that we need APPCONFIGROOT/.well-known to go to /ubos/http/wellknown/SITEID/.well-known?

[jernst]

It's more that Decko shouldn't handle .well-known. Is there a way to tell Passenger (?) not to handle this?

Here's what what we do for Mattermost -- where Apache is used as a reverse proxy in front of their daemon, and we exclude mapping .well-known (and a bunch of other things) -- note the ! at the end of the line to exclude:

https://github.com/uboslinux/ubos-app-mattermost/blob/cdfdc14ca483cd884fca4e1e9bdda5c8b5bd90b4/mattermost/tmpl/htaccess.tmpl#L17

Actually Decko shouldn't handle all the other paths either that are excluded in the lines right above and below.

[ethn]

The way it works is that apache looks for files in ${appconfig.datadir}/public. If it doesn't find anything there, it sends everything else to passenger. This is configured by having the public directory override the Location config here: https://github.com/decko-commons/decko-ubos/blob/master/decko/tmpl/apache2_fragment.tmpl

Afaik, there's no way to have Passenger hand things BACK to apache once apache has handed it to Passenger. But we can explicitly tell Apache what to do with the .well-known directory with another configuration. Is it possible the solution is just to use the configuration you already use but to have it come later?

[jernst]

This will take some experimenting. If we can't get Passenger to not handle certain requests, I guess the htaccess file needs to look different for when Decko is deployed to root ("find .well-known over there") and when not deployed to root (nothing).

[ethn]

It doesn't seem like appconfigs should even be entitled to override the .well-known configuration; the configuration should override *them*, no? Otherwise every app designer has to know what to avoid. Seems like ubos should assert itself here.

…

On Fri, May 21, 2021 at 1:06 PM Johannes Ernst ***@***.***> wrote: This will take some experimenting. If we can't get Passenger to not handle certain requests, I guess the htaccess file needs to look different for when Decko is deployed to root ("find .well-known over there") and when not deployed to root (nothing). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFLEEN7AGNHENSNTHWP5LTO2HJ7ANCNFSM4JFLXSUA> .

-- Ethan McCutchen Executive Director, Decko Commons Decko. You hold the cards.

[jernst]

You are right, but the trouble is that certain Apache configuration statements override others, and the priorities aren't necessarily the way we need them. I seem to recall I played with different options some time ago for the reverse proxy case -- which is similar to the Passenger case -- but concluded that I needed to put those "exception" statements into every app.

[ethn]

Ah, I assumed it was an order issue. Like all we needed was a Directory directive that came last.

…

On Fri, May 21, 2021 at 2:07 PM Johannes Ernst ***@***.***> wrote: You are right, but the trouble is that certain Apache configuration statements override others, and the priorities aren't necessarily the way we need them. I seem to recall I played with different options some time ago for the reverse proxy case -- which is similar to the Passenger case -- but concluded that I needed to put those "exception" statements into every app. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAFLEFRLU2S7S3ZZLYWP2TTO2ONJANCNFSM4JFLXSUA> .

-- Ethan McCutchen Executive Director, Decko Commons Decko. You hold the cards.