There were a few, but the biggest were:
I didn't realize at the time that I'd be dealing with "dev who's aggressively pushing users to migrate from a stable release to beta code" or "dev who would completely abandon backward compatibility in v2."
- Simpler configuration file (the Apache config file for Nextcloud is at least 10x longer than the Caddy one)
- Automatic TLS setup, including getting (and renewing) certs from Let's Encrypt
- Including a much more sensible OCSP implementation
Thanks, though I'd probably be more inclined to go back to Apache if I switch away from Caddy (nice thing about git: I can pull those config files out of the history and reuse them).
I'm sure it would; acme.sh is pretty much universal. Obviously the config file would need to be set up for SSL, but given that acme.sh ought to work fine.
Tend to agree here. Counterpoints:
- Though I've said otherwise in frustration, the rework of the config files is not gratuitous. He's discussed at some length reasons why he felt he needed to make the change. I'm inclined to believe him--why put in the work to completely change the configuration format (and thereby hack off your users) if there isn't some big gain out of it?
- Nothing prevents people from using Caddy1, you just can't use his build server to build you a binary with the plugins you want. This means you need to either use someone else's binary (e.g., the FreeBSD package), or build your own from source.
- This is, at least partially, an artifact of Caddy's having been written in Go. As I understand it, Go doesn't support plugins or modules in the way that, say, Apache does--if you want to use it, it needs to be compiled in. So I can't install Caddy and separately install the Cloudflare plugin; the Cloudflare plugin needs to be compiled into Caddy (which IMO makes "plugin" a bit of a misnomer)
- The obvious way to deal with this, IMO, would be for the FreeBSD port to be set up in such a way that it can be built with whatever plugin(s) is(are) desired. But it isn't there yet, and it's unclear if it's going to happen at all.
Sure, that could be done, and would be relatively straightforward as far as it goes. The rc file needs to be different, but I can pull that out of the proposed FreeBSD port. The big problem is the Caddyfile, as the format is completely different. I don't doubt a reference copy will be developed fairly quickly--Nextcloud is a pretty popular package, and for all I know there may be one out there already. But that's probably the biggest piece that would be needed, aside from getting Caddy2 in the first place.
Sorry this happened to you. I do hope you abandon caddy and go anywhere else. That makes really bad precedent. Non of the scripts with caddy played friendly with my pfsense router running haproxy with ssl termiantion, not even with no cert. So a little rational self interest here. Sorry for the disappointment.