I’ve been using certbot on a Centos 6.10 box for a few years, and it started failing after a recent yum update. The versions of python I have installed are:
/usr/bin/python2.6
/usr/bin/python3.4
From reading the source it looks like certbot requires 2.7 or 3.5, neither of which come with Centos 6, so this looks like the OS is just no longer supported?
I ran this command: ./certbot-auto --apache renew
It produced this output:
WARNING: couldn't find Python 3.5+ to check for updates.
Traceback (most recent call last):
File "<stdin>", line 16, in <module>
File "/usr/lib64/python3.4/distutils/version.py", line 58, in __lt__
c = self._cmp(other)
File "/usr/lib64/python3.4/distutils/version.py", line 176, in _cmp
if self.version != other.version:
AttributeError: 'StrictVersion' object has no attribute 'version'
My web server is (include version): Apache/2.2.15
The operating system my web server runs on is (include version): Centos 6.10
I can login to a root shell on my machine (yes or no, or I don’t know): yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel): no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot): unable to run that command
EDIT: Now that a fix has been released, you should be able to fix the problem by downloading and using a new version of the script at https://dl.eff.org/certbot-auto.
Yeah we’re actively working on a release to fix this issue. Even after the fix is released, users on RHEL 6 based systems affected by this will have to run a command like this manually as this problem is occurring while certbot-auto is trying to determine if it needs to upgrade itself.
To fix the issue, I recommend running sudo rm -rf /opt/eff.org/ and running certbot-auto again.
This will delete the Certbot installation on disk which will cause certbot-auto to walk you through installing any needed dependencies like it’s a fresh installation. If you’re using version 0.40.0 (or a version we’ll likely release in a couple weeks after fixing this bug), certbot-auto will ask you to enable the SCL repository so a non-EOL’d version of Python can be installed.
I’m getting a different error on Centos 6.10 (and it happens my renewal is due tomorrow)
certbot-auto renew
/usr/local/bin/certbot-auto: line 507: .: scl_source: file not found
Bootstrapping dependencies for Legacy RedHat-based OSes that will use Python3… (you can skip this with --no-bootstrap)
yum is hashed (/usr/bin/yum)
4871 packages excluded due to repository priority protections
Package matching gcc-4.4.7-23.el6.x86_64 already installed. Checking for update.
Package augeas-libs-1.0.0-10.el6.x86_64 already installed and latest version
Package openssl-1.0.1e-58.el6_10.x86_64 already installed and latest version
Package openssl-devel-1.0.1e-58.el6_10.x86_64 already installed and latest version
Package libffi-devel-3.0.5-3.2.el6.x86_64 already installed and latest version
Package redhat-rpm-config-9.0.3-51.el6.centos.noarch already installed and latest version
Package ca-certificates-2018.2.22-65.1.el6.noarch already installed and latest version
Package rh-python36-python-3.6.3-4.el6.x86_64 already installed and latest version
Package rh-python36-python-virtualenv-15.1.0-2.el6.noarch already installed and latest version
Package rh-python36-python-devel-3.6.3-4.el6.x86_64 already installed and latest version
Package 1:mod_ssl-2.2.15-69.el6.centos.x86_64 already installed and latest version
Nothing to do
/usr/local/bin/certbot-auto: line 507: .: scl_source: file not found
WARNING: couldn’t find Python 3.5+ to check for updates.
Traceback (most recent call last):
File “”, line 16, in
File “/usr/lib64/python3.4/distutils/version.py”, line 58, in lt
c = self._cmp(other)
File “/usr/lib64/python3.4/distutils/version.py”, line 176, in _cmp
if self.version != other.version:
AttributeError: ‘StrictVersion’ object has no attribute ‘version’
Thanks for the quick response, the issue was that I’m using EPEL repo with a higher priority. It’s got a slightly more outdated version of scl-utils that doesn’t contain scl_source:
Thanks for following up with that explanation @salubrium. I wasn’t aware there are packaged versions which do not contain scl_source. I opened an issue for us to look into making certbot-auto automatically work in this case at https://github.com/certbot/certbot/issues/7524.
Hello, is there any way to run certbot-auto on 32bit CentOS 6.10? SCL is available only for 64 bit OS as far as I can tell. I can install Python 3.5 without any problem so is there any reason it needs a python from SCL specificaly?
For now, you can safely use the latest version of certbot-auto and I'd recommend doing so if you're not going to upgrade your OS, however, I think a version in the near future is going to have to drop support for 32 bit CentOS 6. Too many of our dependencies are dropping support for the software available on that platform. You could try to install newer versions of Python and OpenSSL if you wanted but that's not entirely trivial.
We haven't decided what exactly certbot-auto's behavior will be on 32 bit CentOS 6 when support is dropped, but I expect it'll be similar to the behavior your currently getting with --no-self-upgrade where you will not get any new security/compatibility fixes to Certbot but the script continues to work for now probably with warning messages telling you about these problems.
Now that a fix has been released, you should be able to fix the problem by downloading and using a new version of the script at https://dl.eff.org/certbot-auto.
Thanks for the edit !
On CentOS 6.8, I had the very exact same message than on the first post (CentOS 6.10). Thanks so much for those automated warning emails from letsencrypt about the expiration date getting too close. I was about 9 days from a big big problem and would not have been aware (thing is, I hate updates on something that works !)
So all I had to do was these three steps :
