I would like to install certbot without snap. On certbot website, it says "You can find instructions for installing Certbot without using snap by selecting your OS in the dropdown above. ". I chosed my OS, but the instruction is still for using snap.
6 Likes
I'm afraid this is the result of moving the documentation from distribution based to snap. The banner you're seeing at the top is a generic one from the situation before the aformentioned documentation restructuring. Earlier, there was only the "snap" choice of OS which would present the snap instructions and all the other OSses would have specific instructions. However, this banner isn't uptodate for a lot of OSses any longer indeed, as those OSses have also moved to the snap instructions.
I opened a Github issue for this earlier, but it seems this situation is going to keep existing, until the documentation for all the OSses which are moved to snap are restructured..
Personally, I understand your reluctance for using snap.. Luckily, I'm running Gentoo, so I'm not forced to move to snap. However, other OSses might not be so lucky. There is absolutely no guarantee your OS repository will update their package of certbot, so it might be unwise to use anything differently than snap. It should however still be possible. But that depends on the OS you're using.
5 Likes
The arch wiki always seems to be better than anyone else's
4 Likes
I also do not understand at all why snap is forced upon us. I am anything but satisfied with this decision! It is really annoying.
11 Likes
I wasn't very involved in this decision (and not at all in its implementation), but I believe the main reason that the Certbot team decided to use snaps as the recommended distribution method for Certbot is that most Linux distributions weren't willing to update their packages frequently without some urgent reason like a security hole. Or, if they were willing, they didn't necessarily have packagers who had the time to perform those updates frequently.
I find snap kind of mysterious and uncomfortable, but as someone who provides a lot of support on the forum, I'm sad to see people routinely still running two-year-old (or sometimes even older) versions of Certbot because those are the last versions that their OSes had officially packaged. Sometimes forum members will comment on this (like "could you update your Certbot?" or "maybe this would work better with a newer Certbot version?") and the users asking questions will then reply, quite reasonably, that they followed official instructions for their OSes and got the most recent official package—which may be years out of date.
Certbot rarely has security holes, but it frequently has useful functionality improvements. It's been under very rapid development all along, and these old OS-packaged versions would often be missing non-security-critical but extremely useful features, sometimes such as improvements to the reliability of the integration with web server applications, or improvements to the command-line syntax.
The Certbot license obviously still permits distributions to package Certbot, and perhaps some still do, or still will. I think the challenge that needs to be overcome in order to have OS packages be an appealing option for the Certbot developers, or for most users, is how the OS packages will get more frequently updated, so that they won't lag years behind Certbot releases. If you run an OS where you would like an officially-packaged Certbot outside of snap, can you find a way to get your OS developers to find the resources (and in a few cases, the policy approval) to track EFF's upstream releases more frequently?
5 Likes
I think this is indeed something that isn't very "compatible" with the regular way of distribution packaging.
For Gentoo however, it's simply checking if dependencies have changed and if so, test for dependency hell or if certain dep versions are not stable yet. And check if there has been some low-level change requiring the way the program compiles or installs et cetera.If there's no issue with the deps, you can simply bump the version number. Easy peasy.
Gentoo has its drawbacks, but for getting cutting edge versions of your software, it's great!
4 Likes
Adding to the above, as someone who is also not a fan of snap: I actually like this usage as an integration.
-
The various linux distributions are always very much behind in upgrading to the latest Cerbot versions. Their support is also varied across the install base. Ubuntu, for example, has 5 currently supported variants (of their OS) and a total of 13 package repositories for them. Every Ubuntu version has a different Certbot version. This is insane for the package maintainers, and terrible for end users.
-
You can install Cerbot via pip; it's just a Python package. The problem, however, is that Certbot has a lot of specific version dependencies and is not friendly to exist within a system's normal Python installation. You really need to install it using a virtual environment - which is simple, but can be burdensome to constantly run and execute with. Certbot has a system that does this -
cerbot-auto- but it a bit of a mess and slowly being deprecated and removed. It works, until it doesn't, and just causes issues and confusion. -
The snapd system basically automates the Python installation and streamlines some things to help keep it up-to-date.
In my experience: the only thing we are using snap for is certbot. IMHO, it's a great way to manage Certbot. I wish I did not have to use snap and there were better options, but thinking of it as "the certbot management system" really changed my opinion and made me appreciate it. is it perfect? no -- but it is the best distribution method Certbot has used so far.
4 Likes
What’s the second best option to migrate away from certbot if I don’t want to use snap on my servers?
Just got the EOL message from cron:
Your system is not supported by certbot-auto anymore. Certbot will no longer receive updates.
3 Likes
acme.sh ? pure bash script, and first class client if you want to use DNS challenge by APIs
5 Likes
I use Debian, I installed snap, installed the latest certbot for the ECDSA certs and uninstalled snap. No more snap demon running in the background.
3 Likes
I just switched to using acme.sh as the client, Let's Encrypt is its default certificate issuer. The shell script is a lot lighter than a snap, and I'd already completely removed the snapd system from my server, so I wasn't in a hurry to put it back on. It's worked fine so far.
2 Likes
It just doesn't work. Certifcates are here for servers to run smoothly and stably, not for playing the last computer games.
Snap is just lacking what is necessary to be used in the production server world: network reliability capacity, cache server solutions to allow scalability etc ... In short all installations fail simply because we can't get snaps from the available network reliably and there is not even a shared caching system to lighten this problem (apt, docker all have shared caching options, snap WTF).
The outcome of this certbot decision is the opposite of its objective: we'll have to keep older distributions that work until certbot fixes this ill-inspired change.
Or move away from letsencrypt/certbot if they stop working. Wonderful move !
2 Likes
Certbot is just one of many ACME clients 
Also, certbot is nowadays administrated by EFF, not Let's Encrypt any longer (for a while now), so no need to type "letsencrypt/certbot" as those just aren't the same thing.
2 Likes
I don't understand why snap is put forward as the only solution to update software more frequently than the OS maintainers update their software packages. In Debian-based systems, people routinely set up their own signed package repository (using add-apt-repository) similarly to how docker does this. This way the software gets updated from its own private repository at the same time as the OS gets updated from its repository, all using the same tried and true mechanisms. Clearly certbot isn't the first software project to face this issue, and every other software project to face this issue has chosen a solution other than snap.
As mentioned above, a substantial number of people will not be running snap in production environments, so it seems that this should be solved in the same way as other mission-critical software like docker. I'm not advocating for eliminating snap or even not making it the default choice, but there must be an officially supported alternative to it, especially since alternatives to snap are more common.
3 Likes
What is the benefit for not using snap? OS flavor? My method's is to use a few binaries or scripts as possible for any configuration.
BTW - first time lets encrypt user.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.