should be possible to disable certbot cron job

[Jonathan Kamens]

The `certbot` package comes with `/etc/cron.d/certbot` which contains a cron job that executes twice per day if `/usr/bin/certbot` is executable. There is no way to disable the cron job other than removing the executable bit from the binary.

I have my own, separate cron job configured for using certbot to renew our certificate. My cron job is in `/etc/cron.daily`, and there is necessary logic in it that the job in `/etc/cron.d/certbot` doesn't have.

It should be possible to set a variable in `/etc/default/certbot` or something to prevent the cron job in `/etc/cron.d/certbot` from running.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dave James Miller (d13r)]

I have the same problem - I'm trying to make sure Apache and MySQL are reloaded after the renewal happens so they pick up the new SSL certificate. (I don't know if that's handled by this package already, but I haven't seen anything to indicate it is - there's no post-renew hook in the cron job.)

Note: There's also /lib/systemd/system/certbot.timer that needs to be disabled if systemd is used (on Xenial at least).

[Dave James Miller (d13r)]

I think I've found a solution (for my issue at least):

# certbot --version
certbot 0.17.0

# cat /etc/letsencrypt/cli.ini
deploy-hook = /srv/letsencrypt-post-renew.sh

# certbot renew --dry-run
...
Dry run: skipping deploy hook command: /usr/sbin/service apache2 reload
...

In later versions it looks like there is a standard location for these hooks - /etc/letsencrypt/renewal-hooks/deploy - but this isn't mentioned in the 0.17 docs so I think it was added in a later version.

Still, more control over the cron job would be nice - especially as the official docs (and most tutorials) assume the user is going to set up their own cron job (and I haven't been able to find any documentation that says the Ubuntu package is different and will do it for you).

Refs:
https://github.com/certbot/certbot/blob/v0.17.0/docs/using.rst#configuration-file
https://github.com/certbot/certbot/blob/v0.17.0/docs/using.rst#renewing-certificates
https://certbot.eff.org/#ubuntuxenial-other
http://letsencrypt.readthedocs.io/en/latest/using.html#renewing-certificates

[Dave James Miller (d13r)]

(Sorry can't edit my comment - the output of renew that I pasted doesn't match the cli.ini contents because I ran them at different times and forgot I'd changed it from one to the other!)

[Robie Basak (racb)]

You should be able to remove or edit /etc/cron.d/certbot, and by policy packaging is required to respect your change. Does this not work?

[Robie Basak (racb)]

(and similarly you should be able to disable the systemd certbot.timer using systemd's usual mechanisms, and this change should also be preserved by packaging)

[Jonathan Kamens (jik)]

>You should be able to remove or edit /etc/cron.d/certbot, and by policy packaging is required to respect your change. Does this not work?

Yes, this appears to work (at least, after removing the file, `apt-get install --reinstall python3-certbot` on disco doesn't recreate it), but as I understand it, this is a non-standard mechanism for disabling a cron job. In the past the standard mechanism has been to include a variable in /etc/default/[whatever] to indicate whether the cron job should run.

I don't want to delete files from the source package. What happens if I decide to switch back to the packager's version of the cron job later, but the file is gone because I deleted it to prevent it from running?

>(and similarly you should be able to disable the systemd certbot.timer using systemd's usual mechanisms, and this change should also be preserved by packaging)

I suppose this is actually the correct answer in the age of systemd. Thanks.

[Robie Basak (racb)]

On Fri, Mar 15, 2019 at 02:41:22PM -0000, Jonathan Kamens wrote:
> >You should be able to remove or edit /etc/cron.d/certbot, and by policy
> packaging is required to respect your change. Does this not work?
>
> Yes, this appears to work (at least, after removing the file, `apt-get
> install --reinstall python3-certbot` on disco doesn't recreate it), but
> as I understand it, this is a non-standard mechanism for disabling a
> cron job. In the past the standard mechanism has been to include a
> variable in /etc/default/[whatever] to indicate whether the cron job
> should run.

It is a standard mechanism for packages to provide tunables in
/etc/default/<package>. However I'm not sure this has ever been the case
for cron jobs. Could you provide some examples, specifically for cron
jobs, of your "standard mechanism" assertion in popular packages that
ship cron jobs? In any case, I see that as optional. It's a reasonable
feature request to add an additional disabling mechanism, but expecting
the sysadmin to edit something else in /etc is equally valid.

> I don't want to delete files from the source package. What happens if I
> decide to switch back to the packager's version of the cron job later,
> but the file is gone because I deleted it to prevent it from running?

Keep a backup of the file if you like, or edit it to comment out the
line in question. I'd have to check in the case of deletion, but for an
edited file if the packager changes their version, you'll usually be
given the option (if interactive) of adopting it, and will end up with a
<package>.dpkg-new file if not.

Editing /etc *is* the standard mechanism on Debian and derivatives.
Preserving sysadmin changes to files in /etc is explicitly set aside in
Debian policy as mandatory for packages, and package maintainers
sometimes have to go to extraordinary lengths to comply. Deleting or
changing these files is safe and is a supported mechanism.

> >(and similarly you should be able to disable the systemd certbot.timer
> using systemd's usual mechanisms, and this change should also be
> preserved by packaging)
>
> I suppose this is actually the correct answer in the age of systemd.

Note that on Ubuntu, systemd is the only supported init system (from
16.04 onwards), and the cron job is inactive if systemd is running. So
the mechanism of disabling the cron job as we discussed above is moot,
unless I missed something?

[Launchpad Janitor (janitor)]

[Expired for python-certbot (Ubuntu) because there has been no activity for 60 days.]

[qji (qji)]

Isn't this cron config already redundant and unnecessary as there is a certbot.timer systemd unit?

[Harlan Lieberman-Berg (hlieberman)]

On Thu, Mar 31, 2022 at 9:36 AM qji <email address hidden> wrote:
> Isn't this cron config already redundant and unnecessary as there is a
> certbot.timer systemd unit?

The certbot cronjob will short-circuit itself if systemd is running on
the host, so that the systemd timer takes precedence.