Testing cronjob?

Server
1

Hi everyone,
I set up a server with DigitalOcean (Ubuntu 16.04.4 x64) and configured it with Serverpilot. I installed two small websites on it and created the let’s encrypt certificates separately for both of them. That’s why I renew them with --webroot (Serverpilot blocks Port 80) as well as using certonly and pointing to the respective domains.

This is what I wrote in the Shell (using Putty) while testing out the right parameters:

/root/letsencrypt/letsencrypt-auto certonly --webroot --non-interactive -w /srv/users/serverpilot/apps/vielgefiel/public -d vielgefiel.com -d www.vielgefiel.com --renew-hook "sudo service nginx-sp restart"

This works fine and gives the following output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Cert not yet due for renewal
Keeping the existing certificate

--------------------------------------------------------------------
Certificate not yet due for renewal; no action taken.
--------------------------------------------------------------------

Now I want to make it a daily cronjob. I opened crontab (sudo crontab -e) and put in:

17 1 * * * /root/letsencrypt/letsencrypt-auto certonly --webroot --non-interactive -w /srv/users/serverpilot/apps/vielgefiel/public -d vielgefiel.com -d www.vielgefiel.com --renew-hook "sudo service nginx-sp restart"

This is basically the same, and I thought it might work because of the absolute path. However, I find myself wondering how to test if the cronjob was setup correctly. When I use grep CRON /var/log/syslog I get this:

Mar 18 11:20:01 web-server CRON[20812]: (root) CMD (/root/letsencrypt/letsencrypt-auto certonly --webroot --non-interactive -w /srv/users/serverpilot/apps/vielgefiel/public -d vielgefiel.com -d www.vielgefiel.com --renew-hook "sudo service nginx-sp restart")

However, I expected to see Certificate not yet due for renewal; no action taken. or something along those lines. How can I know that the cronjob is setup correctly? I obviously don’t want to wait until it’s too late and the certificate is expired.

I hope someone of you can advise me what to do and how to tweak the cronjob so that it works for sure.

P.S. I saw that certbot seems to be the updated version of letsencrypt. I would appreciate if someone guides me on how to update without disrupting the existing certificates, but the general question concerning the cronjob remains the same no matter which version I use.

2

You should be able to just use

/root/letsencrypt/letsencrypt-auto renew

in your cron job. The parameters such as --webroot and --renew-hook are remembered and stored in /etc/letsencrypt/renewal/ and reused automatically when you use the renew command.

For testing you can use /root/letsencrypt/letsencrypt-auto renew --dry-run which attempts a test renewal even if your cert is not due to be renewed yet (it uses the staging server so as not to affect your rate limit and does not save the resulting test certificate). If you run that from cron, make sure you have a way to view the output (eg set MAILTO in your crontab file or redirect stdout and stderr to a log file) so that you can check if it worked. Or you can check the logs in /var/log/letsencrypt/ but those can be a bit harder to read. Remember to remove the --dry-run option once you’ve verified that it’s working, and you might then also want to add --quiet to avoid unnecessary noise especially if you used MAILTO.

If it doesn’t work, a common reason is some difference in the environment (e.g. the PATH variable) between your interactive shell and cron. ETA: also, you don’t need to use sudo in the --renew-hook if you’re running the cron job as root, and it might not even work if you do.

Regarding Certbot, if you’re running letsencrypt-auto and allowing it to auto-update (ie, not using the --no-self-upgrade option) then you already have the latest version of Certbot, you’re just calling it by a different name.

1 Like
3

Hey jmorahah,

that is nice to know, thanks!

Ah, that was what I struggled with. I will set up a way to view the output and have another run (considering all the other valuable information you gave).

Ah, perfect. I was worried that I copied the wrong GitHub directory. Is there a command to output the current version that is installed on my server to double check it’s the right one?

4 
/root/letsencrypt/letsencrypt-auto --version
1 Like
5

Thanks again! The certbot version is 0.22.0, so this should be fine.

Concerning the dry run, I looked at the log from letsencrypt, and at the bottom it said:

2018-03-18 12:33:09,953:WARNING:certbot.hooks:Dry run: skipping deploy hook command: service nginx-sp restart
2018-03-18 12:33:09,953:DEBUG:certbot.reporter:Reporting to user: The dry run was successful.

So, it seems that it worked (obviously the hook was skipped since there was no real renewal). However, in the beginning it said:

DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#manual,PluginEntryPoint#nginx,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
DEBUG:certbot.plugins.util:Can't find service, attempting PATH mitigation by adding /usr/sbin:/usr/local/bin:/usr/local/sbin
DEBUG:certbot.log:Root logging level set at 20
INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
DEBUG:certbot.plugins.selection:Requested authenticator webroot and installer None
DEBUG:certbot.plugins.selection:Single candidate plugin: * webroot

Am I correct that the attempt of PATH mitigation worked since in the end, the dry run was successful?

6

I believe so - if I'm reading the code correctly, if it had failed there would have been a warning about "Failed to find executable" which I don't see in the output above.

1 Like
7

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