Bug 2256999

Summary:	How to handle caddy plugins?
Product:	[Fedora] Fedora	Reporter:	Davide Cavalca <davide>
Component:	caddy	Assignee:	Carl George 🤠 <carl>
Status:	CLOSED CANTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	low
Version:	rawhide	CC:	carl, go-sig, ngompa13
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-02-08 07:13:32 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Davide Cavalca 2024-01-05 22:47:22 UTC

caddy has a plugin system, but it's "special" in that plugins are supposed to be included at compile time into the build (either via xcaddy, or by manually plumbing them in cmd/caddy/main.go). This is obviously tricky from a packaging standpoint, and there are _a lot_ of plugins: https://caddyserver.com/download

My interest here stems from personally needing https://github.com/caddy-dns/cloudflare and ideally not having to maintain (and have to keep up to date security-wise) a custom caddy build, but I'd like to find a generic solution if possible.

An option here is foreach plugin, add logic to the caddy spec to import the plugin, add it to main.go and provide a caddy-$plugin subpackage. This would lead to multiple caddy variants (a "stock" one, a per-plugin one, and possibly a "kitchensink" one with all the plugins enabled) -- we'd likely need to use alternatives to handle /usr/bin/caddy. That also leaves the matter of getting the plugin sources unspecified; given that caddy vendors sources (as opposed to using the regular golang macros), that's probably the approach we'd take for plugins too? The upside is that everything is selfcontained to the caddy package, the downside is that its complexity would quickly skyrocket once we're past a couple of plugins.

Alternatively, I suppose we could package xcaddy, add some documentation on how to use it (which might end up involving alternatives as well). I don't love this option because it still requires the sysadmin to remember to rebuild whenever security updates are required though.

Comment 1 Davide Cavalca 2024-01-24 16:35:42 UTC

I put up a review for xcaddy in https://bugzilla.redhat.com/show_bug.cgi?id=2260140 as that was easy enough.

Comment 2 Carl George 🤠 2024-02-08 07:13:32 UTC

> the downside is that its complexity would quickly skyrocket once we're past a couple of plugins.

100% this.  I used to include a set of plugins I cared about in caddy 1.x.  I dropped all plugins in caddy 2.x because:

- the complexity of the spec file, as you noted
- each plugin increases the binary size significantly
- no one will agree on the exact set of plugins that should be included by default
- removing plugins would be a breaking change

And those drawback were while providing just a single caddy binary.  Creating multiple subpackages with different sets of plugins would just multiply those problems.  There just really isn't a reasonable way to go about this due to the nature of statically compiling plugins.  I've discussed this with upstream before, and suggested reworking the plugin system to use separate binaries for plugins that can be executed by the main caddy binary.  They were not willing to entertain this idea due to concerns about reduced speed.  At they time they preferred folks to use their download service, that would create custom binaries with plugins selected in the web interface.  They eventually dropped that approach and created xcaddy instead.  I agree with you about the disadvantage of xcaddy (remembering to run it separate from system updates), so there really isn't any good answer here.

For my own maintenance sanity I've stuck with a plugin-less caddy build, and I'd like to keep it that way.  Sorry.