omg.. why is certbot now requiring snapd? No.
Please go back to offering non-snap packages. Can't stand the snap ecosystem and honestly refuse to use it at this point.
2 Likes
snap is included with most distributions now
nothing to install except apps
"snap is included with most distributions now"
Well.. except ArchLinux, Fedora, CentOS, Haiku, BSD's...
Why would I install an entire package subsystem for one set of python scripts? That's pretty nuts.
I just did some searching and there's literally a native certbot package for Arch.. but the instructions on the site say..
- ???
- Use snap
- profit.
We have VM's with like 1GiB of ram for simple things.. tossing snapd on top of 1GiB doesn't really sound like something I want to attempt.
3 Likes
When I look at the instructions, there's a big fat box Snap Support says that Get Certbot — Certbot 1.11.0.dev0 documentation as instructions to install without snap. Have you looked at that page?
Also, there are many other ACME clients than Certbot, so if you don't like Certbot, why not using another one?
3 Likes
Hi @kallisti5, and welcome to the LE community forum 
Have you tried the acme.sh client?
But to answer/discuss your topic:
I think there is already a plan to continue a non-snap certbot version.
[other will surely know more and chime in]
3 Likes
Fair. It's just a bummer because certbot has been my goto for such a long time. This one act pretty much killed it for me personally. I wouldn't be as up in arms if the site documented an alternative plain python / pip method or still had the shell script... but the lacking ArchLinux instructions show it was a "canvas" move.. distros or users not using snapd be damned.
1 Like
I read this recently:
2 Likes
Ah, more fodder for my theory on how even skilled tech users can be turned away open source documentation that doesn't meet their needs. Hope the thread that @rg305 linked brings you a little hope.
The experience of distro packaging hasn't been that great for the certbot team, so they decided they wouldn't support those packages any longer. The certbot team releases new versions of certbot quite frequently with often quite important bugfixes, especially in the beginning.
While you might not like the choice of snap (I personally certain don't like it), the need for a better way of distributing their software is understandable I think. Distro packages just didn't cut it.
That said I think distro packages are often not that bad too. However, without official support by the certbot team, it would be unlogical, I think, to have installation instructions for them. Why would anyone write instructions for unsupported methods? Doesn't really make sense.
If ArchLinux chooses to keep their packages of certbot, I recommend they also write a guide for it. For example, Gentoo has its own Let's Encrypt wiki, including instructions for certbot.
1 Like
Arch has a wiki page (as for many packages): Certbot - ArchWiki
Also Arch packages tend to be pretty much the latest versions, due to Arch being a rolling distribution. As opposed to, say, Debian/Ubuntu
1 Like
Haha, true.
For more data, personally it's just "fast path documentation". If I'm working through a project, I want the "easy stuff to be easy". Standing up a quick ssl web server to be a open source mirror for 10's of thousands of distro packages, I really don't want to spend 6 hours setting up automatic ssl cert renewals.. so fast-path is my first choice.
I'm doing this as an unpaid labor of love, so I really don't want to have to "spend more money (needing a bigger vm due to snapd) and time (installing snapd, being forced into learning snapd which is completely "extra"). I've been in Linux sysadmin industry for almost 20 years now, i've collected skills on doing so many things.. but snapd just isn't something i'm interested in.
I solved this one by going with something other than certbot... and honestly this will be my last interaction with it. Because as @rg305 said... lots of other options exist for non-container / devops / cloud deployments of things.
This is a good example of what documentation improvements are needed. The site literally only references snapd on Arch (without install instructions)... even though much faster / better / less painful installation methods exist. Linking to the Arch wiki or something would be better.
tldr; yelling "snapd" on every page and then dropping the chain of documentation there is pretty lazy (as a policy, not calling out the folks who wrote the documentation) and could disenfranchise advanced users. If there were at minimum bread crumbs pointing other places and giving alternatives "with the 'unsupported by certbot team'" moniker, i wouldn't have even opened this thread 
Here's the process as the documentation stands today:
- Go to lets encrypt.
- Certbot is front and center
- certbot == lol snap!
- Users not wanting to / unable to use snap left Googling for manual install methods... and certbot has had a lot of installation methods over the years.
3 Likes
You can still install Certbot from source or Python's PyPi.
However, the packaging systems were a complete mess. It would take months for a Certbot release to hit any given linux distribution's current version, and even more time for it to be ported to the various supported legacy versions.
Your best bet to keep Certbot running and updated to most current LetsEncrypt API is to use snapd. I don't like snapd either, but I ONLY use it for Certbot on a few machines. Otherwise, just find another script.
I just did some searching and there's literally a native certbot package for Arch..
The certbot team may or may not be making that package. They have decided to focus their limited resources on snap and promote that mechanism.
There are a lot of linux distributions. Packaging for a single distribution is not easy, packaging for multiple distributions is extremely laborious.
I can't speak for EFF/Certbot and I don't know what was in their mind when they made this decision, but as someone who has managed development teams, their options were likely:
- Spend resources on packaging for distributions
- Spend resources on monitoring third-party packaging/ports for distributions
- Support snapd
The first two options make no sense. The last option is a decent way to provide first-party support for wide adoption.
Also, FWIW, all the "use snapd!" stuff is on the Certbot website, not the documentation. If you read the actual certbot docs, detailed installation instructions for various methods are listed.
3 Likes
The pip instructions are up on the certbot.eff.org website now. Might need to do a hard browser fresh (Ctrl-Shift-R) if you visited recently.
6 Likes
Nice! A massive improvement. That solves pretty much every major complaint I could muster about the policy update
4 Likes
Hooray! So glad that your documentation and policy update woes were also somewhat sorted out as well. Welcome to the forums!
1 Like
Same problem here. Using Debian Stretch. Certbot is too old, giving me some 405 messages when trying to get a cert. Same with the version from Backports.
Issue with installing snapd on Debian Stretch is, it requires AppArmor. Apparmor, from what I can tell requires kernel support and a modification to Grub and the kernel commandline.
So now I cannot install a simple userspace program on a production webserver without making modifications to the kernel commandline and grub. I'm not sure if I have to reboot, or what happens after Apparmor is installed (not sure what the default configuration is). Also, when doing modifications to grub, there is always a risk of the system not coming up after the reboot.
It may be easy for you guys to only have to provide one package, but for people using your software it's just annoying, I'll have to install it at night now probably, because I don't want to risk my server going offline. Or figure out how to install from source, which, according to your site is "only for developers". Well, I am not a developer, I just want to use your software. Is there no tarball?
And like somebody else has already stated: All this just for a simple userspace program. For a simple userspace program people have to install a completely different package management solution that is not native to their distribution and that makes heavy changes to the system. The system often being a production webserver.
@ganzgustav22 Have you seen the post about the newly made pip instructions a few posts above? As far as I can see, it doesn't mention to be specifically for developers.
1 Like
I've just installed via pip and now when running it I get:
Python 3.5 support will be dropped in the next release of Certbot - please upgrade your Python version.
I'll try out acme.sh now.
@ganzgustav22 Are you really still running Python 3.5 only without more recent versions of Python? Because Python 3.5 is end of life and doesn't receive security updates since 13 Sep 2020.
You really should consider upgrading your Python to a secure version.
2 Likes
It's the version that comes with Debian Stretch. Actually, I wasn't "running" it because until I installed certbot, there was not a single program using it. So, no security issue.
No, I won't be updating Python. That would mean updating the whole server to Debian Buster. Remember, it's a production server. Much easier to run a shell script like acme.sh.