Problems with letsencrypt crontab entry


#1

Hello,

I’m having some issues I think. I’ve generated SSL certs for my domain and the virtual hosts for cPanel and WHM. I have a GoDaddy VPS setup. I’ve setup a crontab entry that gets run daily and then it e-mails me letting me know the return status.

The script that the crontab file runs just tries to renew. My understanding was that it should return 0 if the command runs successfully, even if it doesn’t renew the certs. I’m getting a return code of 1 though. Here’s the script I created for the cron.daily stuff:

#!/bin/bash
letsencrypt="/home/sporkschivago/src/letsencrypt/letsencrypt-auto certonly --standalone --keep-until-expiring --agree-tos  --email my_real_email@JetBBS.com -d jetbbs.com -d www.jetbbs.com -d cpanel.jetbbs.com -d whm.jetbbs.com -d webmail.jetbbs.com -d webdisk.jetbbs.com -d cpcalendars.jetbbs.com -d cpcontacts.jetbbs.com"

# Stop Apache so we can update letsencrypt certs
/etc/init.d/httpd stop

# Call the letsencrypt-auto program
eval $letsencrypt

# And store the exit code in a varible
return_code=$?

# Check the exit status of the letsencrypt-auto program
if [ $return_code = "0" ]; then
#       Send an e-mail saying everything went okay...
        mailx -s "SSL Cert Status" my_real_email@gmail.com << MSG_BODY_HERE
command line: $letsencrypt

Return Status: successfully ($return_code).
MSG_BODY_HERE
        /etc/init.d/httpd start
else
#       Send an e-mail saying something went wrong...
        mailx -s "ERROR: SSL Cert Status" my_real_email@gmail.com << MSG_BODY_HERE
command line: $letsencrypt

ERROR: Return Status: ($return_code).

Please check the log file /var/log/letsencrypt/letsencrypt.log for details.
MSG_BODY_HERE
        /etc/init.d/httpd start
        exit 1
fi

exit 0

The script last ran this morning, at around 4:03AM (January 22nd). /var/log/letsencrypt/letsencrypt.log shows it hasn’t been updated since January 21st.

virtualenv --version

shows 13.1.2.

The output from the crontab is as follows:

/etc/cron.daily/renew_certs:

Bootstrapping dependencies for RedHat-based OSes...
yum is /usr/bin/yum
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
 * base: mirror.san.fastserv.com
 * extras: centos.sonn.com
 * updates: mirror.web-ster.com
Package python-2.6.6-64.el6.x86_64 already installed and latest version
Package python-devel-2.6.6-64.el6.x86_64 already installed and latest version
No package python-virtualenv available.
Nothing to do
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
 * base: mirror.san.fastserv.com
 * extras: centos.sonn.com
 * updates: mirror.web-ster.com
Package gcc-4.4.7-16.el6.x86_64 already installed and latest version
Package dialog-1.1-9.20080819.1.el6.x86_64 already installed and latest version
Package augeas-libs-1.0.0-10.el6.x86_64 already installed and latest version
Package openssl-devel-1.0.1e-42.el6_7.2.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-44.el6.centos.noarch already installed and latest version
Package ca-certificates-2015.2.4-65.0.1.el6_6.noarch already installed and latest version
Nothing to do
WARNING: Python 2.6 support is very experimental at present...
if you would like to work on improving it, please ensure you have backups
and then run this script again with the --debug flag!

I’ve installed Python 2.7 but I still need Python 2.6 installed.

Is there away to tell letsencrypt to use Python 2.7 instead of 2.6? I don’t see any options for it when I run letsencrypt-auto --help all.

Also, could it be returning a 1 because it can’t find the virtualenv package? I had to manually install it. I guess, to me, it just looks like it’s trying to run for the first time again, like it’s never been ran. You know, checking everything out. I’m afraid when it comes time for me to actually renew my cert, it’s going to fail. Does anyone have any suggestions? Thank you!


#2

It definitely works as expected when I manually run the crontab entry, either directly by type /etc/cron.daily/renew_certs or by type run-parts /etc/cron.daily/renew_certs…

Wonder if it’s a username issue or something. Perhaps root isn’t running the crontab?


#3

I might of found the problem. /etc/cron.d/dailyjobs runs the daily, weekly and monthly cron jobs. My script is a daily script. But instead /etc/cron.d/dailyjobs, I see
PATH=/sbin:/bin:/usr/sbin:/usr/bin

If I manually run /etc/cron.daily/renew_certs, it works fine. If I use run-parts to execute /etc/cron.daily/renew_certs, it works fine.

I’ve modified the PATH variable in /etc/cron.d/dailyjobs to reflect my current PATH variable. I think this will fix the issues. Python2.7 wasn’t in the old dailyjob’s PATH variable. virtualenv wasn’t either. Hopefully modifying the path environment like I did won’t mess anything up.