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?
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.
-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?
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.
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.