Yes, I know this would be a fairly radical change for Nethserver, but perhaps it can be considered for NS8…
I’ve long been a fan of the Caddy web server. It automatically handles TLS certs (obtaining and renewing them from Let’s Encrypt and ZeroSSL, in case one CA is having problems); implements a modern, sane, and secure TLS configuration; and implements a much simpler configuration syntax. In particular, reverse proxies are trivial to implement in Caddy:
That’s it–given those three lines, Caddy will obtain and renew certs for plex.domain.org, automatically redirect http to https, and proxy that FQDN to the specified IP:port. I haven’t found a web app yet for which the default reverse proxy settings don’t work, though they can be tuned if needed.
For other configurations (not involving a reverse proxy), Caddy is once again much simpler than Apache or nginx. For one example, the complete server config for a Nextcloud installation is only 44 lines (38 excluding whitespace). When I was using Apache for this, it required over 1000 lines of configuration files.
If NS8 is going to depend heavily on containers for its services, it’s going to need a reverse proxy. Caddy will be much simpler to configure than Apache or Nginx. I think it’s worth some serious consideration.
Besides consideration for NS8, have a simple and effective use case right now: caddy file-server
Works like a charm to create a temporary local software repository for a project you work on.
I see EPEL has a RPM for Caddy, but it’s version 1.0. Caddy 2.0 is pretty much a complete rewrite and (unfortunately, though apparently of necessity) badly breaks backward compatibility, and they’re currently up to 2.3.0. I’ll see if I can get a RPM built and pushed out to my repo.
Edit: Turns out there’s an official Caddy RPM:
It doesn’t include any of the DNS plugins, though.
And it doesn’t look like I can build a RPM myself; the version of git that CentOS7 uses is too outdated, and installing an updated version of git breaks some important things like nethserver-mock.
If I understand Go correctly, its binaries should run anywhere with the correct architecture (i.e., Linux/x64), regardless of whether the distro matches. Based on that, I set up a simple build environment under FC33 and built a Caddy RPM there, including all the DNS validation modules (if you don’t need any DNS validation, you’re probably better off using the official RPM I linked above). It will be available in my repo within an hour or so.