CentOS6 certbot-auto updates

I have certbot-auto installed on a pair of CentOS6 servers that host ruby apps which are proxied through nginx. These ruby apps rely on the rvm environment to run (necessary detail). The renewals are working fine. What I’m a bit confused about is when certbot will try to update itself & any dependencies. The reason this concerns me is because RVM sets up ruby environments based on libraries installed via yum. Updating these system libraries can break gems. So, I have some concern that certbot-auto will update itself & any necessary system dependencies will be installed/upgraded automatically via yum, which can, in turn, break RVM.

The thing is, I don’t understand how certbot-auto is updating itself. It’s been running fine via cron for 2 months. However, I ran a dry-run to test something today & all of a sudden it started to call yum to update dependencies, like it was bootstrapping itself all over again. This may be a total coincidence, but I’m wondering why certbot didn’t seem to try to update itself while running via cron, but did when I ran it manually? Is that use case accurate?

Is it possible that your cron invocation included the --no-self-update flag?

No, this is how it’s being run via cron:

0 3,15 * * * root scl enable python27 "python -c 'import random; import time; time.sleep(random.random() * 3600)' && /usr/local/sbin/certbot-auto renew" > /dev/null 2>&1

Well, it might be a coincidence due to your running it right after a new release became available. You might be able to get more information from logs in /var/log/letsencrypt to confirm whether this is plausible.

Timestamps on the logs when it was run:

-rw-r--r-- 1 root root 1.2K Mar 17 15:08 letsencrypt.log.6
-rw-r--r-- 1 root root 1.2K Mar 18 03:29 letsencrypt.log.5
-rw-r--r-- 1 root root 1.2K Mar 18 15:18 letsencrypt.log.4
-rw-r--r-- 1 root root 1.2K Mar 19 03:25 letsencrypt.log.3
-rw-r--r-- 1 root root 153K Mar 19 15:25 letsencrypt.log.2
-rw-r--r-- 1 root root 1.2K Mar 19 15:33 letsencrypt.log.1
-rw-r--r-- 1 root root 154K Mar 19 15:59 letsencrypt.log

The 1.2K log size are the ones run from cron. The 153K & 154K logs are the ones I ran myself via dry-run. I think I ran some others earlier but I canceled them out when I saw they were trying to update yum (wasn’t sure if it would just update without consent or not). The Mar 19 15:59 was the one I ran with --no-bootstrap so it would update certbot without updating any system dependencies. This upgraded certbot to v0.22.0 from v0.21.0, which is what it used when I set it up originally a month ago. I’m not sure when v0.22.0 was released but if it wasn’t today, then it seems like cron would have caught it?

@bmw, any ideas about this?

certbot-auto will never automatically install packages from your OS package manager unless you include -n, --non-interactive, or --noninteractive on the command line. What will happen if an update to Certbot requires new OS packages (which has only happened once) is certbot-auto will print:

Skipping upgrade because new OS dependencies may need to be installed.

To upgrade to a newer version, please run this script again manually so you can
approve changes or with --non-interactive on the command line to automatically
install any required packages.

and then continue running the older version of Certbot.

What I think happened in your case is when you ran certbot-auto yourself, you didn’t run scl enable python27 first. In this case, Certbot couldn’t find Python 2.7+ so it determined it needed to install a newer version of Python (it uses Python 3.4 from EPEL). Because you were running the script interactively, it went ahead with this process and invoked yum for you to approve or disapprove manually.

If you were running the script from cron (and had removed scl enable python27), it would have printed the warning above and continued using the old Certbot installation.

Actually, all of the commands I used included scl enable python27:

  958  scl certbot-auto --help
  959  scl enable python27 'certbot-auto --help'
  960  scl enable python27 'certbot-auto -version'
  961  scl enable python27 'certbot-auto --version'
  962  scl enable python27 'certbot-auto renew --dry-run'
  963  scl enable python27 'certbot-auto renew --dry-run --no-bootstrap'
  965  scl enable python27 'certbot-auto --version'
  973  scl enable python27 'certbot-auto --version'
  992  scl enable python27 'certbot-auto --version'
 1001  history | grep certbot

The opposite is also possible. If you had run certbot-auto without python27 in your PATH at some point and then run it again interactively with scl enable python27, it would have switched back to Python 2 and invoked yum to ensure the necessary Python 2 packages were installed. certbot-auto only keeps track of the last list of packages it installed.

Trying to retroactively figure out why it invoked yum is a bit difficult without the terminal output from the script, but I hope my previous post about when certbot-auto would ask to install new packages makes sense and allows it to work for your use case.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.