That sounds awesome 
I’m happy to chat about the capabilities and limitations of rpm/yum/dnf anytime.
2 Likes
Guys, I’m writing a cross platform (windows and linux atm) CLI application. The CLI tool can download or build Caddy, more feature will be added later. I’ll announce to the forum once I’d release it. The tool might not be open source, however I’d appreciate everyone support.
1 Like
hi,
for those using docker, you can use my base-images like this to build caddy from source with pluings.
FROM ulrichschreiner/caddy-builder:0.10.9 as builder
FROM ulrichschreiner/caddy-runtime:latest
USER caddy
and simply put a plugins.go (with your import-paths for the plugins) to your directory. you can then run “docker build” and the result will be a container with caddy and your desired plugins inside.
take a look at https://github.com/ulrichSchreiner/caddy-http
4 Likes
Caddy is now available in Fedora 26! EPEL 7 is on the way as well.
EDIT: Caddy is now available in EPEL 7.
3 Likes
About that… can’t make time to post or update readme. PR is welcome 
Thanks Carl! I guess you’ll have to update (or remove) the Copr project?
I see that the spec is now here.
@matt @Whitestrake @sayem314
Dears, what about that?!
On the possibility of inserting all the available plugins/services in the compilation of the Caddy in Homebrew and Linuxbrew: => Zhiming Wang’s notes are very pertinent.
Generally speaking, adding an “all-plugins” version of Caddy is not advisable. I agree with zmwangx’s comment in the linked Github thread. If you or someone else were willing to commit not only to supporting it, but verifying the trustworthiness of the suite of plugins, maybe.
1 Like
This is possible on Caddy-X. But as zmwangx said, it’s not recommended. You could open a issue on Caddy-X and I will see what I can do!
BTW caddy is already packaged for some distros/systems already:
- Alpine Linux
- Chocolatey (Windows)
- EPEL 7
- Fedora
- FreeBSD
- Gentoo
- Homebrew (MacOS)
BTW anyone: You want to install Caddy from your distro, but still want to disable (or enable) telemetry? Not possible., at least when the Caddy devs do not decide otherwise.
They insist on a compile time configuration. So if you only have access to run-time stuff or don’t want to mess with binaries, without automatic upgrades, you have no way of disabling sending data to Caddy from your own web server.
Full thread here:
1 Like
Worth noting, though: this is the same problem for choosing your plugins. It’s why we don’t have an awesome distro package for Caddy, because they apparently don’t let you customize plugins at install-time. Telemetry is nothing special here. You might as well raise a banner that says, “You have no way of changing your Caddy plugins from your own web server.”
Yes and this is actually true and may also be not so nice. However, it is a technical limitation that e.g. nginx also have.
The option to not let the user customize this setting on runtime is a deliberate decision that you could change at any time.
1 Like
We’d lose one critical piece of information though, and that is an estimate of how representative the numbers are of the true population. Without that estimate, telemetry becomes mostly useless as a research tool because you’d have to caveat anything that cites it with, “We don’t actually know if these numbers represent the true population, so we can’t actually draw any conclusions from them.”
I actually don’t mind telemetry, and have left it enabled in the Fedora and EPEL packages.
That said, I take issue with this statement.
This is not a distro choice, this is a limitation of any software’s compile time options. Binary distros build the packages once for everyone to consume via their package manager. If a user wants full control over their compile time options they need to use a source distro like Gentoo. Nobody is right or wrong in this scenario, but this statement is a fundamental mischaracterization.
2 Likes
It doesn’t matter: our build server abstracts this away and all the package manager has to do is make an HTTP request to get the binary.