AFAIK certbot documentation show how to install it via snap, and snap only.
I tried to run between different Linux distros, and any of them I checked (Ubuntu 20.04 and 18.04, Debian 19, CentOS 7) leads only to snap.
Maybe this will ease a lot the development and packaging of the product but… I don’t like to have snap installed on my (or managed by me) servers. I don’t like it at all.
Snap is a really nice tool for delivering software, but IMVHO using this kind of sandbox leads to problems
it adds a layer of possible vulnerability, the whole snap substructure
it adds the snap substructure as a required tool
maybe the software can be contained into the snap sandbox, but still neets to have some kind of permissions
IMO you are not too picky and IMO snap goes hard against all what Linux and opensource stands for: sharing and options.
Instead of sharing libraries, snap creates a independent set of libraries for an application. And I agree with you this possibly creates a vulnerability hazard when an application doesn’t get updated (in time).
I don’t think you’re being picky at all. I am considering abandoning Certbot for this.
Looking through the official documentation, the support forums, and discussions in bug reports, it is clear that the team managing Certbot has decided to run with snaps and discontinue support for any other installation methods. There are a few other options for installation (see this guide for pip), but the team has neglected to document most of them, and the ones that are documented, like pip, are heavily de-emphasized.
There are many reasons beyond just open-source ideology (which IMHO is a valid one) to avoid snap. These include:
Snap uses a mountpoint for each package, cluttering up your system’s list of mounted volumes
Snap requires a constantly-running daemon
Snap updates packages automatically and you cannot choose when it does so or disable updates
To somone running a production server, all of these are downsides. Any additional daemon running is a security risk. And the automatic updates undermines the thorough testing of versions for compatibility.
I’m currently debating whether I want to use pip to install certbot (pip doesn’t have as many downsides as snap, but it still is another package management system that I wouldn’t otherwise want to install, I am loathe to install a whole package manage system just to grab one isolated piece of software) and the emphasis on snap has made me question the values and goals of certbot.
It especially puzzles me because the objections to snap are ones that seem most serious for production servers, and these are the environments where certbot is most likely to be used. So it’s like they’re specifically picking a package system most likely to irritate or alienate their core userbase. This seems a bad management choice, at the very minimum.
If you want some other options, see this list of ACME Client Implementations on the LetsEncrypt site. I have heard others recommending acme.sh and dehydrated. There are a lot to choose from and it’s not immediately clear which ones would be best for meeting my need, but that might be a good place to start if you want to use LetsEncrypt without using certbot.
What’s wrong with yum install certbot (which is what CentOS/Neth does)? I agree in not seeing any reason for snap. I agree in not liking the dependency hell that certbot gives you (which is, AIUI, something snap avoids). I prefer simpler clients like acme.sh (though not so much since they sold out to ZeroSSL). But there are official, reasonably up-to-date OS-provided packages for certbot–I don’t see any reason not to use those, which obviates any need for snap.
As i wrote, it’s about choices on CertBot, not for necessity of CentOS. Currently, IDK if for less development footprint the choices of distro managers/developer will be to tell to the systadmins “mind it by yourself” instead of recompilate/package the source for the distro.
Anyway…
IMVHO i can understand some goals of using snap for distributing the package (less development hassle about dependencies and integration to the system for the project) but i am strongly against snap par se due to implications of the snap server (currently not open source, AFAIK).
I frankly doubt it–certbot is the “official” client that was initially developed in conjunction with the service itself. Even though it’s now separated into an EFF project, I’d be pretty surprised to see the Let’s Encrypt organization change its official recommendation. But I’m pretty sure the website itself is on GitHub, so you could always submit a PR.
I created accounts in … a lot of places during my online life. And currently github is not present into the list, nor I want to make it part.
Why? Because i already have a Microsoft account, it’s enough for me. Thanks.
I can lobby only what i think where i can. It’s the wrong place in your opinion? Fair enough, but storming (like some others did even here) for screaming, yelling and being the Karen of the community is unpolite.
Comments from people “unknown” from the community are useless. Comments from “known, reliable, skilled, charismatic” people of a community are… a bit more valuable to the community and to the managers. So entering as newbie don’t fit my feeling.
I don’t know if Let’sEncrypt will last. But IMVHO allowing snap only as “official source” for the software is like shooting the project into a feet, but with a large bullet.
There are a couple of things worth keeping in mind, IMO:
Nobody’s saying you have to use snap; they’re just saying that snap is the only way EFF is going to make certbot available going forward. Others are free to package it in any way that suits them. And misgivings about snap aside, I kind of understand EFF’s perspective here–this Just Works™, it will work with just about any Linux distro, and they only need to prepare/release one package in order to do it.
While there are many, many clients available, certbot seems to be the only popular one that isn’t corporate-owned. acme.sh is owned by apilayer. So is dehydrated. So is Caddy. So is ZeroSSL. And personally, whatever my misgivings about snap, my misgivings about apilayer are considerably greater.
snap is double-chained-linked to Canonical. So packaging into “snap” only… is not making certbot corporate-owned by Canonical, but certainly makes it Canonical dependent, mostly because the english development/support/linux-supporting company holds the sources of the “snap server”.
Is snap “distr-traversal”? Yes.
Does snap works also without a repository? Yes.
Is practical to use snap without a repository? Not that much.
Is source-compiling a suitable alternative to snap? IMO simply can’t compare, if snap is repository-supported.
The publishing of CertBot as “favourite tool” of Let’s Encrypt will lead Ubuntu Server to be “the favourite distro” of Let’s Encrypt. Not that inclusive. Nor corporate-distant.
Moreover…
If the distro mantainer is not interested into compile certbot source and pack it in a different way, this could lead to a forced choice for “the next web/mail/application/shopping server for not buy a certificate”.
What could lead to change my mind? Canonical publishing under GPLv3 license of the “snap repository server” source. Or providing computational power and assets to Certbot project for create alternate repositories and packages for most known server’s distro, starting from CentOS Stream, Debian, OpenSuse. (Not worth talking about gentoo. I think than project managers compile from source even the firmware for their ZigBee toys…)
I hope you didn’t sprain anything in that logical leap. This is true if, and only if, snap works notably better under Ubuntu than it does under Debian, Fedora, EL (and clones), etc. Is that the case? I’ll admit it isn’t something I’ve paid a great deal of attention to, but I haven’t heard that it is.
Naturally, things can change in the future. But so can certbot’s packaging.
Then:
the user/admin could consider a different client
the user/admin could consider an alternative method to install certbot (snap, pip, Docker, rolling his own packages*, using a third-party repo, just off the top of my head)
the user/admin could consider a different distro
This isn’t as extreme a suggestion as it might sound–if the software you need to run won’t run well under one distro, that sounds like a perfectly sensible reason to look for another one.
or some combination of these
*I’m far from the most experienced packager even among this group, but building RPMs really isn’t that hard, especially if you already have a SRPM to start with.
This is what I ended up settling on, for the time being.
I am a bit irked with the CertBot team for not even mentioning this approach on their site. They seem to make it out to be like this isn’t even an option. It’s particularly bizarre too how they have a distribution-specific page, but don’t mention the distribution-specific installation message.
I have conversed with enough people online that I’m aware of their rationale for this, but I don’t agree with it. It seems to me like they are putting their own desire for their userbase to be using the latest version of their rapidly-developing tool, over the stability and security of their userbase.
Haha, this would be me, butting in here (and a few other forums) just for this one issue!
And it has been many years since I contributed to any open source projects as a developer. So I’m certainly ticking the “Karen” boxes here: fussing a lot without contributing much.
I don’t think this is a fair criticism. Developers find and fix bugs and release new versions, and it’s harder for them to support their products if users are using a mishmash of (in some cases very old) versions of their software. Snap gives them a largely platform-independent way to release their software so a very large segment of their userbase can be (and keep) up to date. This generally benefits the users (as they’d rarely want to be on a three-year-old release of certbot), and it benefits the devs in terms of their support. This isn’t a case of “we’re going to do what we want, and screw the users.”
Now, the fact that certbot is complicated and dependency-laden enough to require such a packaging mechanism is its own valid criticism, and it’s a big part of why I generally prefer acme.sh over certbot–though it has its own issues.
There are lots of different ACME clients, and have been since very early on. I’m not sure what distinguishes getssl from the others, though it’s nice that it defaults to the staging CA to avoid busting rate limits.
