7 ms·

Caddy cannot be found in the default repositories of Debian or RHEL. This raises the question of why one would use such a server. Personally, I am hesitant to d

Caddy cannot be found in the default repositories of Debian or RHEL. This raises the question of why one would use such a server. Personally, I am hesitant to download a random pre-built executable from Github, even if it is open source. I would much rather use the apt or dnf version, as anything else seems like just another toy server.

garbagecoder 3y ago
Just build it from source?
- 5e92cb50239222b 3y ago
  And then watch it like a hawk for vulnerabilities and rebuild as needed. No thanks.
jakebasile 3y ago
Caddy provides their own yum repo and I'm pretty sure it's in EPEL too.
cpuguy83 3y ago
While it is convenient to have software prebuilt in a trusted repo, these repos are more about providing toolchains. If something isn't in the repo (or the repo, as it often is, ie out of date) use the toolchain to build what you want.
xeeeeeeeeeeenu 3y ago
>Caddy cannot be found in the default repositories of Debian or RHEL. Debian 12 (bookworm) will have it: https://packages.debian.org/bookworm/caddy https://packages.debian.org/bookworm/caddy
- francislavoie 3y ago
  FWIW, that was created by someone not affiliated with the Caddy project, and looks to no longer be maintained (latest is v2.6.4, but it has v2.6.2). So as a maintainer of Caddy, I cannot recommend using that repo.
  - peppermint_gum 3y ago
    This is the official Debian repository. The package versions are frozen in each major Debian release. However, they may backport security and bug fixes. In practice, in the case of less popular packages, they do this on demand, when someone requests it in the bug tracker.
    - francislavoie 3y ago
      Well, users should know that if they report issues while using releases from that source, we can't reasonably help them, and that they should use an official release to get bug and security fixes promptly. I want to emphasize that we have no contact at all with the people maintaining that Debian package, they've never reached out to discuss anything. We're absolutely open to that (and they know where to find us, not hard to contact us either on GitHub, Twitter, our forums, here, etc).
      - 5e92cb50239222b 3y ago
        It's exactly the same way tens of thousands of other packages have been shipped for decades, including many other web servers like nginx, httpd, lighttpd. No need to paint so much drama over this. They will contact you if the need arises. It's the same usual process that has been used since the 90s to great success.
        francislavoie 3y ago
        Users will reach out to us first, not to debian, because we're easier to reach for help (via social or our forums). If they tell us they're using an outdated version which doesn't have the fix for what they need, I have no other choice but to tell them to stop using the debian-maintained package, and use our officially maintained package.
        account42 3y ago
        Oh please, you do have plenty of other choices. It's ok to not want to support older versions or downstream packages (even if imo there is value in doing so) but don't be a drama queen and claim you can't.
francislavoie 3y ago
Debian's requirements for packaging of Go software is unreasonable. They expect every single dependency to be individually packaged. The total dependency chain of Caddy ends up being massive. We (the Caddy maintainers) don't have time necessary to allocate to a single distribution, to package and maintain every single dependency individually when all we want to do is ship a single static binary (plus some support files). Instead, we ship with our own debian repo, hosting graciously provided by CloudSmith https://caddyserver.com/docs/install#debian-ubuntu-raspbian https://caddyserver.com/docs/install#debian-ubuntu-raspbian. This is packaged via CD with GitHub Actions, and you can verify the authenticity of the build since it's signed by Matt Holt's GPG key. For RHEL, it's in COPR, and that's the best you'll ever get for similar reasons https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
- mardifoufs 3y ago
  What's the reasoning behind that packaging requirement on Debian? Thanks for working on caddy by the way! I find it very neat.
  - francislavoie 3y ago
    Honestly, I don't understand it fully. I just know the barrier-to-entry is too high for us to spend time on it. We don't have contact with any debian packaging maintainers that would be willing to work with us. But https://go-team.pages.debian.net/packaging.html https://go-team.pages.debian.net/packaging.html is one of my main resources for my understanding of their requirements. And that goes without saying that Debian in general tends to release much slower than we'd be comfortable with. We don't want users running outdated and potentially insecure versions of Caddy. Best if users keep up to date by using a first-party installation method where we have control over the distribution pipeline.
    - e12e 3y ago
      All software in Debian needs to be Free software - the user must be able to modify and run it (ie recompile after modifying). And for software packaged for Debian that means being able to work with "apt-get source" and "apt-get build-deps". This of course includes dependencies. That creates a bit of a split between Debian packages and language specific packages like rust crates, golang, python eggs or ruby gems. There's some friction there, but the reasoning makes sense (but it is ok to disagree of course).

garbagecoder 3y ago

Just build it from source?

5e92cb50239222b 3y ago
And then watch it like a hawk for vulnerabilities and rebuild as needed. No thanks.

jakebasile 3y ago

Caddy provides their own yum repo and I'm pretty sure it's in EPEL too.

cpuguy83 3y ago

While it is convenient to have software prebuilt in a trusted repo, these repos are more about providing toolchains. If something isn't in the repo (or the repo, as it often is, ie out of date) use the toolchain to build what you want.

xeeeeeeeeeeenu 3y ago

>Caddy cannot be found in the default repositories of Debian or RHEL. Debian 12 (bookworm) will have it: https://packages.debian.org/bookworm/caddy https://packages.debian.org/bookworm/caddy

francislavoie 3y ago
FWIW, that was created by someone not affiliated with the Caddy project, and looks to no longer be maintained (latest is v2.6.4, but it has v2.6.2). So as a maintainer of Caddy, I cannot recommend using that repo.
- peppermint_gum 3y ago
  This is the official Debian repository. The package versions are frozen in each major Debian release. However, they may backport security and bug fixes. In practice, in the case of less popular packages, they do this on demand, when someone requests it in the bug tracker.
  - francislavoie 3y ago
    Well, users should know that if they report issues while using releases from that source, we can't reasonably help them, and that they should use an official release to get bug and security fixes promptly. I want to emphasize that we have no contact at all with the people maintaining that Debian package, they've never reached out to discuss anything. We're absolutely open to that (and they know where to find us, not hard to contact us either on GitHub, Twitter, our forums, here, etc).
    - 5e92cb50239222b 3y ago
      It's exactly the same way tens of thousands of other packages have been shipped for decades, including many other web servers like nginx, httpd, lighttpd. No need to paint so much drama over this. They will contact you if the need arises. It's the same usual process that has been used since the 90s to great success.
      - francislavoie 3y ago
        Users will reach out to us first, not to debian, because we're easier to reach for help (via social or our forums). If they tell us they're using an outdated version which doesn't have the fix for what they need, I have no other choice but to tell them to stop using the debian-maintained package, and use our officially maintained package.
        account42 3y ago
        Oh please, you do have plenty of other choices. It's ok to not want to support older versions or downstream packages (even if imo there is value in doing so) but don't be a drama queen and claim you can't.

francislavoie 3y ago

Debian's requirements for packaging of Go software is unreasonable. They expect every single dependency to be individually packaged. The total dependency chain of Caddy ends up being massive. We (the Caddy maintainers) don't have time necessary to allocate to a single distribution, to package and maintain every single dependency individually when all we want to do is ship a single static binary (plus some support files). Instead, we ship with our own debian repo, hosting graciously provided by CloudSmith https://caddyserver.com/docs/install#debian-ubuntu-raspbian https://caddyserver.com/docs/install#debian-ubuntu-raspbian. This is packaged via CD with GitHub Actions, and you can verify the authenticity of the build since it's signed by Matt Holt's GPG key. For RHEL, it's in COPR, and that's the best you'll ever get for similar reasons https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/ https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/

mardifoufs 3y ago
What's the reasoning behind that packaging requirement on Debian? Thanks for working on caddy by the way! I find it very neat.
- francislavoie 3y ago
  Honestly, I don't understand it fully. I just know the barrier-to-entry is too high for us to spend time on it. We don't have contact with any debian packaging maintainers that would be willing to work with us. But https://go-team.pages.debian.net/packaging.html https://go-team.pages.debian.net/packaging.html is one of my main resources for my understanding of their requirements. And that goes without saying that Debian in general tends to release much slower than we'd be comfortable with. We don't want users running outdated and potentially insecure versions of Caddy. Best if users keep up to date by using a first-party installation method where we have control over the distribution pipeline.
  - e12e 3y ago
    All software in Debian needs to be Free software - the user must be able to modify and run it (ie recompile after modifying). And for software packaged for Debian that means being able to work with "apt-get source" and "apt-get build-deps". This of course includes dependencies. That creates a bit of a split between Debian packages and language specific packages like rust crates, golang, python eggs or ruby gems. There's some friction there, but the reasoning makes sense (but it is ok to disagree of course).