All Tutor users need to configure DNS records to access their Open edX platform in production. In addition, many users need to run a web proxy in front of Caddy -- which is a totally legitimate use case.
But for these users, it's often difficult to figure out which hostnames need to be proxied. Sometimes, they forget to configure DNS records or SSL certificates for one or more subdomains. It's often a trial and error process, as we can see in the forum topics above. This problem is compounded by the fact that additional plugins require extra subdomain records.
Sure, some users can just add a CNAME *.<LMS HOST>. DNS record. But this is not an option for many users who may not have direct access to their DNS configuration (institutional users for instance).
We can help users by printing the hosts from the Caddy configuration. This can be achieved by parsing the Caddy configuration as json (see caddy adapt):
$ tutor local run -v $(pwd):/tmp/config caddy sh -c "caddy adapt --config /etc/caddy/Caddyfile > /tmp/config/caddy.json"
$ cat caddy.json | jq ".apps.http.servers.srv0.routes[].match[].host[]"
For instance, when both the mfe and minio plugins are enabled on a local platform, the commands above print the following output:
To run these checks we will probably have to build and push a new custom image that bundles both caddy and python. Thus it probably makes sense to add these features to a new plugin. It could be added to the "contrib" index if it is maintained by a 3rd party.
I investigated this issue after seeing these forum topics: https://discuss.openedx.org/t/payment-mfe-returns-404/9547 https://discuss.openedx.org/t/error-when-export-course-and-suggested-ingress-setting/9565
All Tutor users need to configure DNS records to access their Open edX platform in production. In addition, many users need to run a web proxy in front of Caddy -- which is a totally legitimate use case.
But for these users, it's often difficult to figure out which hostnames need to be proxied. Sometimes, they forget to configure DNS records or SSL certificates for one or more subdomains. It's often a trial and error process, as we can see in the forum topics above. This problem is compounded by the fact that additional plugins require extra subdomain records.
Sure, some users can just add a
CNAME *.<LMS HOST>.DNS record. But this is not an option for many users who may not have direct access to their DNS configuration (institutional users for instance).We can help users by printing the hosts from the Caddy configuration. This can be achieved by parsing the Caddy configuration as json (see
caddy adapt):For instance, when both the mfe and minio plugins are enabled on a local platform, the commands above print the following output:
We could probably wrap these commands in a Tutor
docommand. For instance:Optionally, we could verify IP records and/or SSL configuration with:
(IP can be obtained with python's
socket.gethostbyname.)To run these checks we will probably have to build and push a new custom image that bundles both caddy and python. Thus it probably makes sense to add these features to a new plugin. It could be added to the "contrib" index if it is maintained by a 3rd party.