4 ms·
I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap ht
by lstamour 6y ago
I agree — the auto-updating nature of Snaps are a problem without an easy solution: https://askubuntu.com/questions/930593/how-to-disable-autorefresh-in-snap 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 latest version.
The only other alternative to suggest is to request the Certbot project deploys custom deb repos or similar. But can we expect that of every project? Perhaps we need a new standard to replace snap, if so the only folks I can see large enough to promote it would be GitHub...
Since that’s unlikely to happen, maybe just noting the auto-update “feature” more prominently in their is all they should need to do?
- erik_seaberg 6y agoToo old in what way? Is the Debian stable version relying on something that Let’s Encrypt is deprecating?
- lstamour 6y agoI’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.