Prefer to avoid snaps too. First time I'm hearing of dehydrated. I've dabbled a bit with acme.sh too and it's good (can do ECC certs and it's a single shell script).

I've stopped using Ubuntu in favour of good old Debian due to Canonical foisting snaps. I know you can remove snapd but the whole Ubuntu ecosystem is pivoting towards them.

What does certbot have to do with snaps..? You have all the options of container, build from source, download a binary release, get it from apt (or what have you) repos.

certbot does not officially support binary packages on Linux, so you have three choices for supported releases: snap, docker, or pip (best effort). If I’m not already using docker for the site (spoiler: I’m not) then why the fuck would I install docker if I’m not willing to install snap?

I guess the installation via pip is only best effort in the sense that they can't support every platform that pip is able to run on. For example their dependency on the "cryptography" library might cause problems on platforms which can't get a pre-compiled version from PyPi and have to built it from source.

If you are on x86 and use a distribution with glibc I wouldn't expect any problems.

I've had no issues installing it from debian apt repos on arm64 and amd64... I mean, if you don't want to use certbot and prefer something else, fine, but I can't see how docker/pip/snaps are the only options.

They're even listed as alternative methods here: https://certbot.eff.org/docs/install.html

I wish at least one of the other people downvoting my comment would pipe in to what their issue is, or what I could be missing.

And yes, I've encountered the cryptography-switched-to-rust-thing in various other scenarios.

Genuine question : Whya re snaps a nightmare on headless servers? Their auto-updating nature does add some stability issues but any other reasons?

Because it's not conjusive to a minimal attack surface - by way of example: https://www.helpnetsecurity.com/2019/02/13/cve-2019-7304/

Not to completely minimize it, but that says local attacker, not remote attacker. So someone would still have to gain access to the system in question in the first place.

Just because a server is headless does not mean that it isn't interactive in some way or running some user-submitted scripts or code.

Also, compromising a service running as a user (not root) would be sufficient to then escalate.