My Second Cron Job

Nothing like waiting until the last minute.

I’ve been getting increasingly frequent “renew your Let’s Encrypt cert” emails but the task kept getting postponed because I didn’t have the command(s) memorized and wanted to create a cron job for it but whenever I thought of it, I didn’t have the time or whatever to look it up or do it.

That’s my excuse.

Yesterday, I received the “your cert expires in 0 days” email and promised myself I’d renew it yesterday.

I didn’t.

This morning, I got up and had a faint hope that it expired at an exact time and not just the date. I checked that last email and the gods were merciful. I had a few hours left. Just renewed it and saw this in bright red amidst the bright green:

Encountered vhost ambiguity when trying to find a vhost for but was unable to ask for user guidance in non-interactive mode. Certbot may need vhosts to be explicitly labelled [sic] with ServerName or ServerAlias directives. Falling back to default vhost *:443 ...

I was concerned, especially because it was a particularly important subdomain, but below that I also saw (in the normal bright green):

Congratulations, all renewals succeeded.

I do want to check into that though. I’ll probably be as quick about that as I was about renewing …

I did, however, create the cron job so I wouldn’t have to stress or worry about it in the future. Things to note:

That tute states, “The certbot Let’s Encrypt client has a renew command that automatically checks the currently installed certificates and tries to renew them if they are less than 30 days away from the expiration date.” DO shows a cron task that tries the renew command every single day so if the cert is within 30 days of expiration, it gets renewed.

I know it’s a tiny little command, but I hate the idea of something happening every single day that doesn’t have to. I think running the command bi-monthly is best (“best” meaning it makes me feel like I’m beating the system) so I thought using * * 31 * * would be super-nifty. I thought months with 31 days are pretty much every other month so it would be perfect and I’m so brilliant.

When I drew it on the whiteboard I saw

  • It would have worked for today (Nov 24) because Oct 31
  • It would work for the next renewal in 90 days on Feb 24 because Jan 31
  • Before it hits another two consecutive renewals successfully (Aug and Nov 2018) it would totally miss May 2018 because April has only 30 days.

This concept could still work if I could get it to attempt renewal on the first day of a month following any month with 31 days.

TIL: You can use If statements in UNIX shell scripts.

For now, so that I can complete this task, we’ll just go with the first day of every month.

I’ll update this post once I write the shell script.

Hmm …

Just typed sudo ctrontab -e and saw what looked like an empty file. That command is what I usually see in cron tutorials. I wonder what it does …?

So, while I file that question away in a drawer I may never check, I’ll just edit the crontab file like I did in My First Cron Job post … as I suspected and hoped, my other command is, indeed, there with my new job now beneath it.


But there are still at least a couple things I want to know.

  • In my first cron job, I indicated a user because one (just one) tute said to and the directions in the file have a column for that. Do I need that? I didn’t put one for my new cron job so we’ll see.
  • In the first job, there’s a command to change directories which makes sense for the file and the scripts in that file. DigitalOcean’s tutorial that inspired my second job/line of code includes /usr/bin/certbot renew but, knowing that I can run certbot from any location, I’m going to see if I can omit that path. The script should run in a few days and I’ll also have a couple more months during which I can experiment.
  • That second command in the job writes the output of renew in a file located at /var/log/le-renew.log but that log file didn’t exist and I haven’t created it. I’m thinking that the command creates the file if it doesn’t already exist. We’ll see in a few days.

I wish I’d noticed where the renew command I did earlier stored any output. The tute states output should have included a line saving debug info to /var/log/letsencrypt/letsencrypt.log and I had already check in that letsencrypt folder to see if le-renew.log was in there. Trying to cd into it as me got me Permission denied and trying as root got me No such file or directory!

So, as I said, we’ll see …


About jotascript

Aiming to please. Seeking to impress.
This entry was posted in Security, Site Admin, UNIX. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s