If we’re counting, Caddy 2 has more features than Caddy 1.
Like Francis said, Caddy 1 never had the DNS plugins included either. You have to build from source. This is an open source project – not paid, plushy, proprietary software – so is that so surprising?
Is it too hard to build an open source project from source? Especially one written in Go? With tools like xcaddy available? You get what you pay for. We’ll get around to a shiny new build server when we have the chance, probably.
When a great deal of open source software–including the previous stable release of this software–is widely available as binary packages, yeah, it kind of is.
Obviously all the Caddyfiles need to be rewritten from scratch anyway. But it sounds like the scope of the work has expanded to include installing a build environment and building Caddy, documenting that as clearly as possible, and incorporating that in the scripts. None of that’s impossible, of course. Whether it’s worth it is something I’ll have to think about.
You know that we have dozens of binary packages available through our GitHub releases and our download page links to several distributions that are pre-built and ready-to-go, right?
Virtually no other open source projects let you make custom builds of the open source software with a few clicks. We’re really lucky to have had it for v1, and as time and other constraints allow, we might get it for v2 eventually – I’m the only one working full-time on this project currently. It took Caddy 1 several years to get there, Caddy 2 has moved much quicker.
It’d be a good idea to update those, since getcaddy.com only ships v1 and if we keep using it will be upgraded to v2 soon. Our website is not a package manager though, and we don’t recommend it for long-term, unmaintained installations – use a proper package manager that comes with your distro instead. (And if one doesn’t exist, then help us make one for your distro.)
That’s… normal… for pretty much all open source projects that you customize.
You could always just build it once and then ship that binary to your users yourself, rather than having all of them build the same thing from source.
Caddy is an amazing product. As an enthusiast, I don’t feel it’s wise spending my time learning Apache or NginX when I could better spend my time learning about other aspects of technology that I would rather devote my time to. Caddy has made this possible for me. Caddy V2 is the next step in the evolutionary chain.
@danb35 is a highly respected and influential member of the FreeNAS Community. He has also almost single-handedly been the spokesperson for Caddy to the FreeNAS Community. Several of the most popular resources he has provided to the community are built with Caddy V1 being a key component. The resources are in widespread use, both in depth and spread, from simple to enterprise applications.
Caddy V2 presents some challenges for the FreeNAS and FreeBSD communities, which, while not insurmountable, still need to be carefully considered from those communities’ perspectives. The main concerns with V2 for these communities are:
Compared to V1, the perception, whether true or not, is that V2 still isn’t feature-complete, particularly concerning DNS validation for certs.
V2 is incompatible with V1. There are very good reasons for the change, but the fact remains that Caddyfile backward compatibility is virtually nonexistent.
While a FreeBSD executable is available, there is as yet no FreeBSD pkg or port for it.
Individuals may be willing to readily embrace a .0.0 version of any major software. However, where resources built on Caddy are being used by significant cross-sections of communities, the risks of adopting a .0 release are magnified considerably.
The support that the Caddy team are providing to stakeholders for the transition from V1 to V2 is tremendous. Each side has valid concerns and each side needs to be empathetic to the views of the other side, Individuals can traverse any one or all of the issues above relatively quickly and with limited risk. However, individuals who are here as advocates for a much larger group don’t have the same luxury as the stakes are much higher for the groups they represent.
There’s a lot to be taken away and reflected on by both sides on this transition from V1 to V2. Hopefully, the learnings will be useful for making the transition from Caddy V2 to V3 even smoother when that eventually comes around.
Thanks for chiming in with some clarity and missing context, @basil.
Please communicate to those communities that Caddy 2 supports all 75+ of lego’s DNS provider implementations: GitHub - caddy-dns/lego-deprecated: (DEPRECATED) DNS modules so Caddy can solve the ACME DNS challenge with over 75 providers - that module is a shim, and it does work, but with the same limitations of v1 that v2 is intended to obsolete. So if you want the latest and greatest, best to use one of the other providers in caddy-dns · GitHub – and there are many yet to be implemented. That is purely a community effort, and implementing one is not difficult. Either way you look at it though, Caddy 2 has very good support for DNS providers.
Yeah. Sorry. It was necessary. Please refer your community to this handy upgrade guide: Upgrading to Caddy 2 — Caddy Documentation – I’d be surprised if their Caddyfiles are very long and complex, so upgrades shouldn’t be more disruptive than setting it up for the first time.
I don’t think anyone on our team uses FreeBSD. Would you or someone in your community be willing to maintain an official FreeBSD package?
The .0 is not particularly important. On the whole, I’d wager Caddy 2 as more stable and reliable than any v1 or pre-v1 version. I’d say your users are at higher risk by staying on v1 which is no longer maintained.
It sounds like, in between the complaints here, what is being asked for is a FreeBSD package. We’ll happily make room for one in our CI releases, as long as someone is willing to maintain it.
I’ll try to answer some of the questions posed there, I don’t feel like setting up an account for that bug tracker.
There is no official list of changes, they created a site highlighting the changes: https://caddyserver.com/v2
Since it’s a rewrite, the list of changes would be “everything”. We do have an upgrade guide though which covers most of it though:
For my own understanding, how important is it that Caddy V2 create a PID file, or require LOGIN and DAEMON? I haven’t found these to be showstoppers in getting Caddy V2 working in the rc.d framework.
v2.1 will have a --pidfile CLI flag, so if that’s a dealbreaker for the moment, you could wait until v2.1 to finish the FreeBSD packaging:
I wonder if the order should be switched though, or whether it matters? i.e. command_args="--config ${caddy_config} ${caddy_flags}"
Order doesn’t matter to Caddy, so that’s up to you.
Why? For instance, it may facilitate implementing a ‘quiet mode’. As you will be aware, the Caddy start and reload commands generate quite a lot of output. In its simplest form, this can be prevented by setting caddy_flags="> /dev/null 2>&1" in /etc/rc.conf.
I HIGHLY recommend not dropping Caddy’s log output. It’s very important to trace and debug any problems, including Let’s Encrypt rate limiting or other issues that would require support. If you do this, then people who come here to ask for help wouldn’t have any logs to show how Caddy behaved. Please don’t do this.
The location of the Caddyfile and Caddy executable, I’ve set up as configurable script parameters caddy_config_path and cadd_bin_path. For instance, I think in the V1 rc script, the default Caddyfile location was /usr/local/www/Caddyfile. This may be important for some users migrating from V1 to V2.
FWIW we’ve been putting the default Caddyfile in /etc/caddy/Caddyfile and the binary in /usr/bin/caddy with our other packages. Consistency there would be nice if possible. If not, it’s not a big deal. Just thought I’d mention it.
Is it possible to build Caddy’s plugins with this port? I’m most interested in the DNS validation plugins, but I’d suppose any others would work the same way.
It’s always possible to build Caddy with plugins as already described in this thread, but the default distribution shouldn’t come with any plugins preinstalled other than the code modules.
Hmm, yeah, dropping the log output will be unacceptable for us, as it will result in a lot of help requests where we can’t do anything to help, and a lot of confused and frustrated users on the FreeBSD platform. Surely they don’t want that.
I’ve got Caddy V2 behaving nicely in a FreeNAS jail atm.and doing all the right things within the FreeBSD rc.d framework so I’m trying to comprehend the usefulness of the pidfile… Could be for strict FreeBSD framework compliance, but I’m not sure. Not that it’s impacting my testing atm, but is there an ETA for 2.1?
Point taken. I’ve heard you and @matt loud and clear and have dropped the idea.
Noted, though I believe /usr/local is the default destination for the FreeBSD ports framework, so like the pidfile could be a compliance requirement.
Thanks Basil. We can bend on binary location if necessary.
Quoting from that thread:
Given the complete lack of backward compatibility, might it be better to have a separate port for Caddy v2 (called, perhaps, “caddy2”)?
Given that whatever is using that name right now isn’t officially sanctioned and is not maintained, we’d really like to replace that rather than take second place as “caddy2”. In other words, we’d like to step in as the official distribution team and say, “This is the official caddy package” – otherwise everyone going to install “caddy” will get an old, unmaintained version, and all the tutorials and documentation they find online will not work for them, and all the FreeBSD users will be upset. FreeBSD surely doesn’t want that, right?
Hi Matt, I’ve provided the FreeBSD Caddy package maintainer with additional feedback. Please continue to monitor the aforementioned FreeBSD thread for the latest developments.
