Report that crond was not working in the docker for the ssl certbot cert renewals

[bradymiller]

Report that crond was not working in the docker for the ssl certbot cert renewals.

Hi @adunsulag ,
Turns out this is set up in the dockers already and should be working when running docker with the letsencrypt ssl setting.

1. dcron package is installed in Dockerfile
2. ssl.sh is run when docker is started and that is where the certs and cron is set up (/etc/crontabs/root population and start of crond service).

So to test this, would need to bring the docker up with a $DOMAIN setting.

Hopefully it's not broken, although i don't have a quick way to test this in my testing environment. Are you able to test with a $DOMAIN setting?

[adunsulag]

Yes, I was using the DOMAIN setting. Here's a snippet of the docker I am using which I just had to recently renew the certificate on.

    volumes:
    - ../..:/openemr:ro
    - ../..:/var/www/localhost/htdocs/openemr:rw
    - publicvolume:/var/www/localhost/htdocs/openemr/public:rw
    - sitesvolume:/var/www/localhost/htdocs/openemr/sites:rw
    - nodemodules:/var/www/localhost/htdocs/openemr/node_modules:rw
    - vendordir:/var/www/localhost/htdocs/openemr/vendor:rw
    - ccdanodemodules:/var/www/localhost/htdocs/openemr/ccdaservice/node_modules:rw
    - logvolume:/var/log
    - couchdbvolume:/couchdb/data
    environment:
      DOMAIN: openemr.discoverandchange.net
      EMAIL: [email protected]

[jesdynf]

Options:

• Is crond busted?
• Is crond good but the task is busted?
• Is crond good and the task good but the renewal attempt is busted?

Advice: Add a second task to cron and see if that new task fires. Does this cron run as a daemon, or something somehow lurking in systemd?

[bradymiller]

Would it make sense to always run the crond service? Since folks may want to set up cron processes in their OpenEMR instance (for example, several cron scripts available for messaging and services management). If that is case, then I'd move the crond service startup right before start httpd in the openemr.sh script. This would then also make it easier to test crond to see what is going on.

[stephenwaite]

that makes sense, so take it out of ssl.sh and move it into the main script?

[jesdynf]

Well, ssl.sh is at least getting called, and it does run the crond if $DOMAIN is set. So...

• Is crond running in the container?
• Is root's crontab set as expected?
• Would root's crontab work correctly?
• Are any crontabs working?

I don't really agree that we want to just Always Run A Crond but it probably won't break anything to move it, no.

[bradymiller]

Note if did this, would need to persist the /etc/crontabs/root when do an OpenEMR version upgrade (since going to a new docker) while also not duplicating the entry in that file for the ssl letsencrypt stuff (this appears to basically re-initiate itself and populate /etc/crontabs/root when going to a new OpenEMR version (ie. a new docker).

[jesdynf]

Well, in the current scenario, if you move to a new Docker... LE reinits fully, which seems okay to me. Certs and flags aren't stored in the shared volume, so a new Docker image with a newly imported volume would make ssl.sh feel around for certs it liked, not find them, reauth with LE, and set up the new crontab, which seems correct.

[bradymiller]

If folks add more things to /etc/crontabs/root though, then would be lost when upgrade OpenEMR version.
Leaning towards not starting crond for everybody because of above and that services can be done via other means in the context of dockers. In addition, nobody has asked about this in the many years the docker has been around.
Seem best to just figure out why it's not working for certbot stuff. In addition's to @jesdynf 's questions above, also be good to see whats in the system log (i think that is where crond log goes when not specified).

[jesdynf]

If we super felt like it we could provide a prewarm.d in the shared volume, and then run all the scripts in it ( https://stackoverflow.com/questions/41079143/run-all-shell-scripts-in-folder ) every time the container cranks, right before httpd is started, and that'd let admins who do need a crond detect one or create one or manage the tasks they've added to one.

[stephenwaite]

I've got a docker in production that didn't have it's domain set when brought it up and have set it up to try to renew a cert tonight at 23:01 :)

• started crond
• added to crontab 1 23 * * * certbot renew -q --post-hook "httpd -k graceful"

[bradymiller]

Ran easy docker, started crond, and plopped very simple script in /etc/periodic/15min which I did confirm worked and ran every 15 minutes. Note it initially didn't work since i forgot the bash shebang header on top of my script, which was not logged anywhere that i could find (so if the certbot renewal command is breaking, it won't be logged and will just break silently). Then when I fixed the shebang thing, it worked fine. So guessing is issue with certbot.
btw, here is the default root crontab if curious:

*/15	*	*	*	*	run-parts /etc/periodic/15min
0	*	*	*	*	run-parts /etc/periodic/hourly
0	2	*	*	*	run-parts /etc/periodic/daily
0	3	*	*	6	run-parts /etc/periodic/weekly
0	5	1	*	*	run-parts /etc/periodic/monthly

and here it the simple script I dropped in /etc/periodic/15min (called go.sh):

#!/bin/sh
echo "hi" >> /var/www/localhost/htdocs/openemr/hi.log

Which added a 'hi' to /var/www/localhost/htdocs/openemr/hi.log every 15 minutes

[stephenwaite]

thanks Brady, mine ran, cert wasn't ready for renewal which was logged in /var/log/letsencrypt/letsencrypt.log, moved it into it's own script now living under /etc/periodic/monthly