[9dev]

The only joke here is Certbot, a tool intended for use on servers but distributed on a channel intended for consumer use - Snap. The only package manager that will update on its own, when it feels like it, without a killswitch, runs as a daemon intertwined with the system.

Icing on the cake is that the Certbot team advertises alternative install methods, of which none work and all of the lengthy guides for them recommend to use Snap instead. It’s an insult for professionals.

[candiddevmike]

I'm a simple man, I see a comment complaining about snap and I automatically upvote.

It's 2024. If you're still distributing snaps as the preferred method of install, you're alienating your users. AppImage, Flatpak, and regular containers are all far better deployment options.

[groestl]

> If you're still distributing snaps as the preferred method of install, you're alienating your users.

Dropped lxd because of it. Now I hear they're a proper debian package, but that decision was so weird (especially the auto-update part) I don't trust them anymore.

[johnisgood]

Same. I have a couple of comments as to why snap is awful.

[eyegor]

I wish everything in linux land just had an AUR equivalent.

[blackfawn]

I wish I could upvote this more... snaps are the worst!

[crispyambulance]

Yep, this.

So ridiculous to have to install yet another package manager, snapd, to get certbot installed "the easy way".

The alternative to get around snapd works fine (IMHO, for my situation, a lightsail instance running amazon linux 2023 where installing snapd is a pain in the ass), but you still have to jump through some hoops.

[bakugo]

> the Certbot team advertises alternative install methods, of which none work

I've only been using it for a little while, but the pip + venv method seems to work decently well: https://certbot.eff.org/instructions?ws=other&os=pip

[9dev]

Did you see that bold disclaimer on top?

> Partial support > The Certbot team supports this installation method on a best effort basis. If you are on a more obscure or heavily customized system, these instructions may not work and the Certbot team may be unable to help you resolve the problem.

This is an instant no-go for any professional environment I ever worked in.

[chx]

I am doing docker run -it --rm certbot/certbot

Is there a problem with that?

[9dev]

I wouldn’t call it a problem, but let’s hear what the Certbot docs have to say:

> this mode of operation is unable to install certificates or configure your webserver, because our installer plugins cannot reach your webserver from inside the Docker container. > > Most users should use the instructions at certbot.eff.org. You should only use Docker if you are sure you know what you are doing and have a good reason to do so.

These problems are solvable if you know what you do, but the whole premise of ACME was making it easier to obtain certificates; plus, I shouldn’t need to decide between an autonomous and hostile package manager or keeping a container environment running, secure, and configured - to set up bloody TLS certificates for a Webserver. That said, good for you if it works :)

[chx]

I mount webserver docroot and /etc/letsencrypt directories into the certbot container, /docroot and /etc/letsencrypt mount points respectively, it is totally prepared for this.

[9dev]

How did you implement reloading the modified TLS certificates after renewal tho?

[chx]

it's a two line script running periodically. the first line is docker the second is nginx -s reload. As /etc/letsencrypt dir is mounted from nginx into certbot, certbot upgrades that, nginx reload picks them up. Easy as pie.

[egorfine]

so much this. Certbot is a monster with incredible amount of dependencies.