Breaks https://github.com/geerlingguy/ansible-role-certbot/blob/master/tasks/install-from-source.yml on Ubuntu-based systems (Probably the rest of debian too).
You are really deprecating certbot-auto on all Debian based systems ? Just like that ?
1 Like
This is really weird.. What can we do? Did you find a solution for our Debian servers?
This is really weird.. What can we do with our Debian servers? Do we need to stop using Certbot or are there workarounds?
Certbot-auto is a specific distribution method for certbot that is being deprected if I understand correctly. The certbot utility will still work just fine. I believe you just need to change how you are installing it. The currently preferred method on most Linux distributions is via a snap package. The Certbot Instructions page can give you specific guidance for your server software and OS distribution.
3 Likes
That's a rather strange script anyway.. It pulls the whole git repository for just one file.. Seems to me you'd better find a different solution altogether, as this script clearly wasn't properly thought through..
3 Likes
What happened?
In our 1.10.0 release on Tuesday, we deprecated certbot-auto, one of the ways to install Certbot, on Debian based systems including Ubuntu. In our 1.11.0 release, we plan to deprecate the script on every OS. It is only certbot-auto that we deprecated. Our other distribution methods or Certbot more generally was not deprecated on Debian.
The behavior you can expect from certbot-auto on a deprecated OS is that if you had run the script before and had an existing Certbot installation from it, that installation will continue to work, however, you will no longer receive updates and a message will be printed every time the script is run explaining this. If you do not have an existing certbot-auto installation, the script will refuse to install Certbot and say that you need to use a different installation method.
Why did it happen?
If certbot-auto had been working well for you, I'm glad to hear it, but it became infeasible for our small team to maintain. It's a custom, self-updating shell script that tries to support all popular UNIX OSes. Keeping this script working in all the different environments out there and the changes being made to them was just too much work.
The biggest factor that drove this deprecation now was Python 2 reaching its end-of-life this year. When this script was initially written 5 years ago, it was written to use Python 2 on most systems. While Python 2 is still receiving security support by various distros, the Python ecosystem has moved on and many of our dependencies are dropping support for Python 2. In order to continue to provide updates to our users, we have to get them on Python 3. We tried to migrate certbot-auto users to Python 3 in the past, but it's a ton of work and extremely error prone. Instead of trying to do this work and hope we didn't break anything (like we did last time), we decided to sunset the script in favor of other distribution methods.
How do I install Certbot now?
The way we recommend most users install Certbot is through snaps. You can find instructions for doing this at https://certbot.eff.org/instructions.
Some of the benefits of installing Certbot this way are:
- Certbot automatically stays up-to-date, giving you access to the latest features including updates to the TLS configuration Certbot uses when installing certificates with Apache and Nginx.
- Automatic renewal comes preconfigured, so there is no need to manually set up a cron job or systemd timer.
- All of our DNS plugins are available and it is possible for 3rd parties to write their own Certbot snap plugins as well.
If you don't want to install Certbot through snaps, other installation methods are documented at https://certbot.eff.org/docs/install.html. (certbot-auto is still documented there but that will be removed soon.)
Finally, while I do not recommend this, if certbot-auto was working for you, it's possible to continue to use the last version of the script that worked on Debian based OSes. Taking this approach means you will not receive any bug fixes, security fixes, or compatibility fixes with Let's Encrypt's servers. If that does not deter you, you can find the last version of the script that worked on Debian at https://raw.githubusercontent.com/certbot/certbot/v1.9.0/certbot-auto. If you use this, make sure you are fully comfortable with all of these downsides and include --no-self-upgrade on the command line to prevent the script from updating itself to a deprecated version.
6 Likes
@ bmw
Do the alternative ways of installing certbot work as a drop-in replacement? To be more specific, I am using certbot-auto like this for automated DNS verification, where 2 of the scripts call an externally hosted PHP script to do the creating/removing of TXT records:
#!/bin/bash
/usr/local/bin/certbot-auto certonly
--keep-until-expiring --manual
--manual-public-ip-logging-ok
--preferred-challenges=dns
--manual-auth-hook /home/pi/certificates/certbot-auto-authenticator.sh
--manual-cleanup-hook /home/pi/certificates/certbot-auto-cleanup.sh
--post-hook /home/pi/certificates/certbot-auto-reload.sh
-d domain.com -d *.domain.com | mutt -s "Let's Encrypt" -- email@domain.com
Please tell me I can still use this, the same options I mean...
1 Like
I don't see any certbot-auto script related options, so it should also work with the certbot program directly.
Note that the manual-public-ip-logging-ok option has been deprecated since 1.10.0.
2 Likes
At first it looked like the snap version as drop-in replacement wasn't working (my mistake), now it does. Sort of.
The 1st dry-run seems to have worked, the 2nd and 3rd attempt failed at the challenge part, not sure why. If I had to guess, it's because the DNS-servers aren't updated yet.
Immediately after creating 2 TXT records, "dig -t txt _acme-challenge.mydomain.com +short" gives random outputs, sometimes no results, sometimes one, sometimes two, in random order.
.... and after a little editing of the authenticator script, it now seems to work like it should.
I already had a check build in to see if the dig command produces results, now I made it so the script will wait till dig outputs two results, that seems to have done the trick.
So it seems the command I've been using (minus --manual-public-ip-logging-ok) can still be used with the snap version of certbot 
edit: Except the part where mutt is supposed to mail me the output, doesn't happen when run with sudo.
1 Like
This could be due to propagation delay or possibly a problem with one or more DNS servers.
As @Osiris warned, don't count on it remaining that way.
Well, the underlying program (certbot) is the same.. Perhaps only versions would be different and the certbot-auto wrapper script does have some extra options for itself (which obviously aren't supported by the certbot program itself), but otherwise it should be the same.
Certbot should still work when you use it though, it's just a no-op since version 1.10.0.
1 Like
@ griffin
"This could be due to propagation delay or possibly a problem with one or more DNS servers."
With certbot-auto I never had any problems, this started after having switched to certbot. but having the script now wait till dig outputs more than one result (instead of just one) seems to work. Just leaves mutt, still don't have a clue why it is not working with sudo, I like having a weekly update so that I can immediately see if something certificate related happened.
1 Like
I mentioned elsewhere: if you don't want to install Certbot via snap, but do want to install it with your OS package manager (like apt or yum), you may want to let your OS distributor know about this, to see if the distributor would be willing to have someone officially package more recent releases of Certbot. One of several reasons that the Certbot team switched over to recommending snaps as the official distribution method is that operating system distributors were having a hard time keeping up with the upstream Certbot releases, even when they contained moderately important changes, or fairly useful improvements that many users would probably want to have.
That could change in the future (on one or more distributions), and the distributions still have the right to make their own Certbot packages if they want—but it would be helpful for them to know if their users consider this a priority, because it would require extra ongoing work on the distributors' part.
3 Likes
You managed to kill letsencrypt on a Linux Fedora 33 server with the certbot-auto 1.10.0 update
The setuptools used contains a buggy compatibility script setuptools/py33compat.py stopping certbot-auto in its tracks setting up the virtual environtment
1 Like
Is the certbot-auto wrapper even still supported on Fedora?
1.9.0:
certbot-auto was deprecated on all systems except for those based on Debian or RHEL.
1.11.0 (upcoming release):
certbot-auto was deprecated on all systems.
I would advice you to move away from the certbot-auto script and use the recommended method of installing certbot according to the instructions on https://certbot.eff.org
1 Like
Please, note, that 'deprecated' does not mean 'non-functional'
It may be intended to move the users to another product, but updates should be tested properly and not break anything, especially not when they still are performed behind the back of the users.
In this case a test was as simple as running python on the file from a command line.
1 Like
Sorry for the trouble joergent, but there were no changes in our 1.10.0 release related to this problem. With the following Dockerfile, I hit the same problem with the previous version of certbot-auto:
FROM fedora:33
RUN dnf install wget -y
RUN wget https://raw.githubusercontent.com/certbot/certbot/v1.9.0/certbot-auto
RUN chmod +x certbot-auto
RUN ./certbot-auto --version -n --no-self-upgrade
I believe the problem is the version of setuptools we have pinned in certbot-auto does not support Python 3.9 so if you recently upgraded to Fedora 33 which uses Python 3.9, the script would break. These are exactly the kind of environment changes I described in my previous post that make certbot-auto hard to maintain for all of the OSes it tried to support.
Regardless of the root cause though, the script will be fully deprecated in our next release so we're not going to add support for Fedora 33 now and I'd recommend you install Certbot through another method. We recommend most people use snaps for the reasons I outlined above, but the maintainers of the Certbot packages on Fedora do a pretty good job keeping their packages up-to-date so that's another reasonable option.
2 Likes
I understand the difficulties to support various distros inside one script but I've found that the certbot installed for Centos via EPEL is just not stable enough to keep working. Sometimes a Python module called python-requests-2.6.0-10.el7.noarch is updated by pip to a newer release breaking certbot from functioning and renewing certs. If this requirement was not so strict I would not have had any need for certbot-auto but because the EPEL package can break (and it does) I get problems with servers not renewing the certs and affecting clients.