Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Certbot deprecates operating system packages, “standardizes” on snaps

certbot.eff.org

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#51

Post by linsomniac »

rlpb wrote: post #46
linsomniac wrote: post #17

Just to clarify something I think a lot of replies don't understand: The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. The PPA for Certbot includes updates of a lot of OS packages, with with incompatibilities with other Ubuntu provided packages. I've spent hours tracking down and fixing the problems that have come from installing certbot via apt. Usually, I'm much more…

> The Ubuntu Certbot packages have been horribly broken for well over a year, probably at least two. I think you're mistaken. The Ubuntu Certbot packages are maintained and work fine. What you're referring to is the PPA, which is no longer required (since Ubuntu's distribution-shipped certbot packages have worked fine for a long time now). Or, if not, can you point to specific issues with Ubuntu's own certbot package…

You are correct, it is the PPA, I mention this in the second paragraph.

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#52

Post by rstuart4133 »

mmastrac wrote: post #3
JetSpiegel wrote: post #2

This was mentioned 2 months ago, but without traction. https://news.ycombinator.com/item?id=25141524 This is a ridiculous requirement for a glorified Python script, over-engineering at its worst.

This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script". The rationale makes sense for me: "While the Certbot team tries to keep the Certbot packages offered by various operating systems working in the most basic sense, due to distribution poli…

> This seems unnecessarily hostile. Certbot is a complex beast that generates TLS configurations, has multiple plugins that likely require specific system configuration, and is I think charitably more than "a glorified Python script".

Yeah, it is complex. Far too complex for what it does.

What it does is implement a not particularly complex IETF protocol between your server and letsencrypt's servers, and run a few of your scripts when the protocol wants something done, like "install DNS entry".

In fact the protocol is so simple a bash script can do it. Dehydrated https://dehydrated.io/ is just that - a bash script that implements ACME. It also is in Debian. I moved to dehydrated when certbot was slow to implement DNS wildcards.

The nice thing about simplicity is it infects everything else: the document becomes simple, which is nice because I had to read certbot's doco several times just to figure out what scenario would work for me. And distribution packaging becomes simple, so no snap's needed. And installation becomes simple.

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#53

Post by bccdee »

floatingatoll wrote: post #49
lokedhs wrote: post #35

Earlier quoted context omitted.

Flatpak, probably. I'm not saying Flatpak is great, but it's the best we have, in my opinion. That said, having published one application on Flathub, packaging Flatpak is not a great experience, especially when the two major repositories: Flathub and Fedora both use two completely different build processes.

Is Flatpak better than snapd, if we set aside that one is ‘open’ and one is ‘closed’ and evaluate them by the merits of their functionality in service of the goal?

Yeah flatpak is much more mature, as I understand it.

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#54

Post by lstamour »

hlieberman wrote: post #33
lstamour wrote: post #29

Earlier quoted context omitted.

Debian is still on version 0.x when the snap is at 1.1 ... this is one of those cases where the Debian stable branch is too stable when you need to ship software that interacts with a lot of remote APIs the way the certbot-dns packages do. It’s impossible to use the old Debian versions with the more secure API tokens from CloudFlare, for example.

The certbot-dns packages are certainly the most fragile part of the process -- however, I don't have any bug reports showing that the version in stable is currently broken for any of the dns plugins. If you're experiencing that, please file a bug against them and I can look into having a stable backport done for them.

I’ll see what I can do, I’m not familiar with Debian package bug tracking. For reference, the incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between version 0.23 distributed in stable and 1.11 distributed via snap. Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site. As CloudFlare is used by a lot of folks for DNS, and was a suggested default install, I’m probably not the only one that encountered problems setting it up, without a backport available for a newer package of Certbot.

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#55

Post by lstamour »

erik_seaberg wrote: post #36
lstamour wrote: post #24

Earlier quoted context omitted.

I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autore... But I would also point out that on stable Debian it’s near impossible to deploy Certbot because the versions available are too old, especially the plugins. I’ve been routinely installing the snap instead because it’s a quick and easy way to deploy the service at the lates…

Too old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?

I’m not sure, but it’s possible. The version in stable was 0.31 or so, while the version in snap and unstable/sid is 1.11. The specific incompatibility I faced was for the CloudFlare DNS plugin, which added support for API Tokens that had granular permissions somewhere between the 0.23 version in stable and the current version of the plugin at 1.11. Current Certbot docs and CloudFlare docs both encourage you to use API tokens instead of account-wide API secrets and the previous install instructions for wildcard DNS support suggested installing the CloudFlare DNS plugin by default on the Certbot site.

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#56

Post by ivansavz »

ivansavz wrote: post #19

If y'all want to try a high-magic solution based on a single-host docker-compose setup with traefik 2+ as ingress, here is the paragraph for configuring Let's encrypt certs: https://github.com/rocdata/rocserver/blob/main/docker-compos... It works great. Host just needs to have ports 80 443 open and docker installed: https://github.com/rocdata/rocserver/blob/main/fabfile.py#L2... PS: In case I can save anyone days of…

Updated link to traefik container config: https://github.com/rocdata/rocserver/blob/main/docker-compos...

(link changed because only need SSL certs in prod -- so moved to a prod-specific docker-compose file)

Re: Certbot deprecates operating system packages, “standardizes” on snaps

#57

Post by [deleted] »

ryebit wrote: post #23
Havoc wrote: post #9

Literally just switched from Ubuntu to Debian to get away from snaps

Linux Mint has even removed snap, which is impressive since they're downstream from Ubuntu. After hearing some of the issues with it (here and elsewhere), I'm kinda grateful to them for making the effort. Though this concerns me -- I use certbot on some debian servers, I hope that at least stays up to date.

[deleted]
Post reply on HN