I have multiple VIRTUAL HOST domains on a Apache 2…2.15 based Centos 6.9 host (all updates installed) that I have root/ssh access to. This is a DELL blade server with 32GB of memory with equal amount of swap space.
When running the command
/usr/local/bin/certbot-auto renew --no-bootstrap --apache
from the command line it does what it supposed to do without error message albeit the 2.6 DeprecationWarning:
/root/.local/share/letsencrypt/lib/python2.6/site-packages/cryptography/init.py:26: DeprecationWarning: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of cryptography will drop support for Python 2.6
DeprecationWarning
Saving debug log to /var/log/letsencrypt/letsencrypt.log
and for every domain cert I have it shows
Cert not yet due for renewal
which is correct as I only installed them recently.
However, running the CRON job through CRONTAB
23 3 * * * root /usr/local/bin/certbot-auto renew --no-bootstrap
is a different thing:
Creating virtual environment…
Installing Python packages…
Had a problem while installing Python packages.
pip prints the following errors:
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6
Requirement already satisfied (use --upgrade to upgrade): argparse==1.4.0 in /.local/share/letsencrypt/lib/python2.6/site-packages (from -r /tmp/tmp.fhMh8I2wGC/letsencrypt-auto-requirements.txt (line 11))
Collecting pycparser==2.14 (from -r /tmp/tmp.fhMh8I2wGC/letsencrypt-auto-requirements.txt (line 17))
//.local/share/letsencrypt/lib/python2.6/site-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform.
+This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
//.local/share/letsencrypt/lib/python2.6/site-packages/pip/vendor/requests/packages/urllib3/util/ssl.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause
+certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
InsecurePlatformWarning
Downloading pycparser-2.14.tar.gz (223kB)
…
…
…
You should consider upgrading via the ‘pip install --upgrade pip’ command.
Certbot has problem setting up the virtual environment.
We were not be able to guess the right solution from your pip
output.
NORMAL FORM:
Please fill out the fields below so we can help you better.
My domain is: multiple
CRON ran this command: /usr/local/bin/certbot-auto renew --no-bootstrap
It produced this output: Certbot has problem setting up the virtual environment.
My web server is (include version): Apache/2.2.15 (Unix)
The operating system my web server runs on is (include version): CentOS release 6.9 (Final)
My hosting provider, if applicable: myself
I can login to a root shell on my machine (yes or no, or I don't know): ssh/root access
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): NO
Few thoughts. First, are you sure it’s being run under the same user? root directly is different than normal user via sudo, and this changes the paths of the application. Second, have you tried calling the installed certbot directly in cron?
I do not use sudo. If I have to install anything or have to do any system administration work (like updates/installs) I use “su -”, install/update/whatever and get out - root in crontab is perfectly correct.
The machine in question only has a very limited number of accounts … the editors/developers of webpages and the su account for root.
I just saw that the files are in the private folder for root and not in /usr/share …
Why not giving an option of installing it globally?
certbot-auto runs sudo internally, so if you run it from a normal user account, it won’t work properly when run directly as root from cron. If you run certbot-auto while running as root (and HOME is set to /root), then it should be okay.
Supported systems have packages for them that you can install globally. Certbot-auto doesn’t use system packages for some things, and thus can’t easily be installed globally. Unfortunately, Certbot isn’t packaged for EL6 (it is for EL7 as part of EPEL).
Why not giving an option of installing it globally?
We're talking about changing the default behavior to install Certbot globally for a number of reasons, but in the meantime you can control where certbot-auto places its files using the environment variable VENV_PATH.
What's going on here is certbot-auto is trying to create a new installation (or upgrade an old one if you ran without --no-self-upgrade and there was an upgrade available), but this process failed. If using VENV_PATH doesn't fix the problem for you, can you provide the full error output from certbot-auto? It looks like the relevant output for debugging this problem was excluded from the original post.
Sorry cannot use attach “new users are not allowed” … so lines below might be broken although I made sure they are not.
Creating virtual environment…
Installing Python packages…
Had a problem while installing Python packages.
pip prints the following errors:
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please upgrade your Python. A future version of pip will drop support for Python 2.6
Requirement already satisfied (use --upgrade to upgrade): argparse==1.4.0 in /.local/share/letsencryptlibpython2.6/site-packages (from -r /tmp/tmp.fhMh8I2wGC/letsencrypt-auto-requirements.txt (line 11))
Collecting pycparser==2.14 (from -r /tmp/tmp.fhMh8I2wGC/letsencrypt-auto-requirements.txt (line 17))
//.local/share/letsencrypt/lib/python2.6/site-packages/pip/vendor/requests/packages/urllib3util/ssl.py:315: SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name Indication) extension to TLS is not available on this platform. This may cause the server to present an incorrect TLS certificate, which can cause validation failures. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#snimissingwarning.
SNIMissingWarning
//.local/share/letsencrypt/lib/python2.6/site-packages/pip/vendor/requests/packages/urllib3util/ssl.py:120: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning
.
InsecurePlatformWarning
The error there is an instance of #4640 which has a fix in our development branch that will be included in our release next week. Sorry for the trouble but I’m glad you got it working.
@bmw - but this is different as it works from the command line and NOT when initiated by cron. So when initiated by cron it misses some vital info (environment, path, ???) it should have and then barfs. Starting the cron job with a "ssh localhost " in front of it will give it that missing info (which I do not know what it is) and then executes it properly.
I am not sure what changes in the environment on your system are causing this problem to manifest. Executing certbot-auto using cron on CentOS 6.9 works for me. My best guess is Python environment variables or the Python installation or virtualenv executable available in your PATH.
Regardless of what that change is though, I believe the problem that occurs due to these environment changes will be fixed in the next release. The error that’s happening is:
In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
setuptools>=11.3 from https://pypi.python.org/packages/fc/cb748dcabb152fbc7eceaf585d052b8bc11cf028b917a7d2343cf1e0c092c3/setuptools-36.0.1-py2.py3-none-any.whl#md5=7a52500dcfd7c4f37f5d20e462c93560 (from cryptography==1.8.2->-r /tmp/tmp.fhMh8I2wGC/letsencrypt-auto-requirements.txt (line 45))
This problem has been fixed and should not occur using the version of certbot-auto we are releasing with Certbot 0.16.0 late next week.
If you’re interested in continuing to help debug this, I encourage you to try running certbot-auto in cron without using SSH after this release comes out. If you still have the problem then, feel free to @name me directly.