Change crontab user for Letsencrypt renewal

[enricostano]

WAT!? Why!?

Right now we pass openfoodnetwork to the cerbot role as the crontab user for Letsencrypt renewal cron job.

openfoodnetwork@staging:~$ crontab -l
#Ansible: Certbot automatic renewal.
30 3 * * * /opt/certbot/certbot-auto renew --quiet --no-self-upgrade

The problem is that openfoodnetwork user doesn't have permissions to run the certbot binary. Give a look at the CRON log:

oct 24 03:30:01 scw-ecce22 CRON[10274]: (openfoodnetwork) CMD (/opt/certbot/certbot-auto renew --quiet --no-self-upgrade)
oct 24 03:30:01 scw-ecce22 sudo[10278]: pam_unix(sudo:auth): auth could not identify password for [openfoodnetwork]
oct 24 03:30:01 scw-ecce22 sudo[10278]: openfoodnetwork : user NOT in sudoers ; TTY=unknown ; PWD=/home/openfoodnetwork ; USER=
oct 24 03:30:03 scw-ecce22 sudo[10299]: pam_unix(sudo:auth): auth could not identify password for [openfoodnetwork]
oct 24 03:30:03 scw-ecce22 sudo[10299]: openfoodnetwork : user NOT in sudoers ; TTY=unknown ; PWD=/home/openfoodnetwork ; USER=
oct 24 03:30:03 scw-ecce22 CRON[10270]: (CRON) info (No MTA installed, discarding output)
oct 24 03:30:03 scw-ecce22 CRON[10270]: pam_unix(cron:session): session closed for user openfoodnetwork

Proposal

Let's use ofn-admin user instead since it has permissions to run it. There is still a pending problem about the standalone web server but it will be covered in another issue. Will link to this one once created.

[mkllnk]

On the server I just provisioned, the root user already had the crontab entry. I just needed to remove the entry from the openfoodnetwork user.

[enricostano]

On the server I just provisioned, the root user already had the crontab entry.

Who created it? Are you using latest ofn-install?

[mkllnk]

I'm using the master branch. My version is based on 19f5e81. I think that installing the crontab is a new feature of certbot. So the role is probably not up-to-date with certbot's current behaviour.

[mkllnk]

https://certbot.eff.org/all-instructions/#ubuntu-16-10-yakkety-nginx

The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire.

[enricostano]

@mkllnk Yakkety? This playbook I'm afraid it only supports 16.04 LTS for now. Can we verify if the new version behave similarly on 16.04 LTS?

[mkllnk]

Oh sorry, I quoted the wrong source. https://certbot.eff.org/#ubuntuxenial-nginx

The Certbot packages on your system come with a cron job that will renew your certificates automatically before they expire.

Same thing. The new server I set up runs 16.04:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.3 LTS
Release:	16.04
Codename:	xenial

And that's what I observed there. I don't want to setup a new server just to test this and my machine is too slow to do it.

[enricostano]

Nice, thanks! I'll test it and report back.

[enricostano]

I just created a Ubuntu Xenial 16.04 LXC container and installed python-certbot-nginx following the steps from doc and I get the following:

ubuntu@hola:~$ cat /etc/cron.d/certbot 
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

[enricostano]

I also discovered this:

root@hola:~# cat /etc/systemd/system/timers.target.wants/certbot.timer 
[Unit]
Description=Run certbot twice daily

[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target

and

root@hola:~# systemctl status certbot.timer
● certbot.timer - Run certbot twice daily
   Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Wed 2018-02-28 18:49:11 UTC; 21min ago

Feb 28 18:49:11 hola systemd[1]: certbot.timer: Adding 4min 28.160109s random time.
Feb 28 18:49:11 hola systemd[1]: Started Run certbot twice daily.

aaaand

root@hola:~# cat /lib/systemd/system/certbot.service 
[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

More details here https://github.com/certbot/certbot/pull/5460/files

[enricostano]

I'm not sure which one actually run the renewal between cron and systemd.timer, but the latter surely run:

enrico@scw-064c30:~$ systemctl list-timers
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Thu 2018-03-01 00:29:23 UTC  4h 53min left Wed 2018-02-28 15:56:10 UTC  3h 39min ago apt-daily.timer              apt-daily.ser
Thu 2018-03-01 00:40:41 UTC  5h 5min left  Wed 2018-02-28 12:09:29 UTC  7h ago       certbot.timer                certbot.servi
Thu 2018-03-01 17:35:49 UTC  22h left      Wed 2018-02-28 17:35:49 UTC  1h 59min ago systemd-tmpfiles-clean.timer systemd-tmpfi

3 timers listed.

and

enrico@scw-064c30:~$ systemctl status certbot
● certbot.service - Certbot
   Loaded: loaded (/lib/systemd/system/certbot.service; static; vendor preset: enabled)
   Active: inactive (dead) since Wed 2018-02-28 12:09:31 UTC; 7h ago
     Docs: file:///usr/share/doc/python-certbot-doc/html/index.html
           https://letsencrypt.readthedocs.io/en/latest/
  Process: 4351 ExecStart=/usr/bin/certbot -q renew (code=exited, status=0/SUCCESS)
 Main PID: 4351 (code=exited, status=0/SUCCESS)

[elf-pavlik]

I think #124 fixed it