Dustin C. Hatch
2fa28dfa5f
The *dch-proxy* role has not been used for quite some time. The web server has been handling the reerse proxy functionality, in addition to hosting websites. The drawback to using Apache as the reverse proxy, though, is that it operates in TLS-terminating mode, so it needs to have the correct certificate for every site and application it proxies for. This is becoming cumbersome, especially now that there are several sites that do not use the _pyrocufflink.net_ wildcard certificate. Notably, Tabitha's _hatchlearningcenter.org_ is problematic because although the main site are hosted by the web server, the Invoice Ninja client portal is hosted in Kubernetes. Switching back to HAProxy to provide the reverse proxy functionality will eliminate the need to have the server certificate both on the backend and on the reverse proxy, as it can operate in TLS-passthrough mode. The main reason I stopped using HAProxy in the first place was because when using TLS-passthrough mode, the original source IP address is lost. Fortunately, HAProxy and Apache can both be configured to use the PROXY protocol, which provides a mechanism for communicating the original IP address while still passing through the TLS connection unmodified. This is particularly important for Nextcloud because of its built-in intrusion prevention; without knowing the actual source IP address, it blocks _everyone_, since all connections appear to come from the reverse proxy's IP address. Combining TLS-passthrough mode with the PROXY protocol resolves both the certificate management issue and the source IP address issue. I've cleaned up the _dch-proxy_ role quite a bit in this commit. Notably, I consolidated all the backend and frontend definitions into a single file; it didn't really make sense to have them all separate, since they were managed by the same role and referred to each other. Of course, I had to update the backends to match the currently-deployed applications as well.