6 ms·

Why is this better than Certbot, which has more options and more support? Set up a daily cron to run the certbot-auto `--renew` flag and forget about it. Done.

Why is this better than Certbot, which has more options and more support? Set up a daily cron to run the certbot-auto `--renew` flag and forget about it. Done. https://certbot.eff.org/ https://certbot.eff.org/

hlieberman 10y ago
Installing certbot through the Debian/Ubuntu packages will automatically setup a cron job for you.
lorenzhs 10y ago
The Debian package is even more convenient, it sets up the cronjob automatically (with a random delay to prevent everyone from hitting the servers at the same time). It's even quicker to set up.
- chrsstrm 10y ago
  Is this a new-ish feature or did I just not read the docs thouroughly when I first used it almost a year ago? Thanks for the tip either way.
  - guitarsteve 10y ago
    Same here, I just set up LetsEncrypt for a second site last week and didn't know this. From a glance at the docs it looks like it's relatively new. Ubuntu 16.10 has the automatic cron setup but not Ubuntu 16.04 which is what I used.
    - chrsstrm 10y ago
      That's strange. I swore last year I would never use a non-LTS version for a server. Unless I'm missing something, it seems to be more headaches than it is worth to roll with the XX.10 vs XX.04.
  - lorenzhs 10y ago
    I'm not sure, it was there when I finally switched from the git repo to the packaged version some months ago. I'm using Debian stable (with the backports repo enabled)
- garaetjjte 10y ago
  Convenient? To me adding cron jobs/systemd timers without question is user-hostile.
  - JdeBP 10y ago
    It's not added without question. It's added by dint of the administrator taking the explicit action to install the package. This is actually the Debian practice that the systemd people tried to take account of in the design of their presets system. Installing a package on Debian not only installs the software, but it automatically configures and runs it, too. Hence the idea that systemd presets can be made to default to "enable" on Debian and default to "disable" elsewhere. This is a Debian norm. It's one that various Debian developers have tried to change over the years. The convention of having separate "run" packages exists and a few people adhere to it. (bcron-run, socklock-run, qmail-run, dqcache-run, bincimap-run, ...) But that convention is not (yet) the Debian norm. This is even though people have been regularly pushing for it since the turn of the century. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107862 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107862 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804018 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804018

hlieberman 10y ago

Installing certbot through the Debian/Ubuntu packages will automatically setup a cron job for you.

lorenzhs 10y ago

The Debian package is even more convenient, it sets up the cronjob automatically (with a random delay to prevent everyone from hitting the servers at the same time). It's even quicker to set up.

chrsstrm 10y ago
Is this a new-ish feature or did I just not read the docs thouroughly when I first used it almost a year ago? Thanks for the tip either way.
- guitarsteve 10y ago
  Same here, I just set up LetsEncrypt for a second site last week and didn't know this. From a glance at the docs it looks like it's relatively new. Ubuntu 16.10 has the automatic cron setup but not Ubuntu 16.04 which is what I used.
  - chrsstrm 10y ago
    That's strange. I swore last year I would never use a non-LTS version for a server. Unless I'm missing something, it seems to be more headaches than it is worth to roll with the XX.10 vs XX.04.
- lorenzhs 10y ago
  I'm not sure, it was there when I finally switched from the git repo to the packaged version some months ago. I'm using Debian stable (with the backports repo enabled)
garaetjjte 10y ago
Convenient? To me adding cron jobs/systemd timers without question is user-hostile.
- JdeBP 10y ago
  It's not added without question. It's added by dint of the administrator taking the explicit action to install the package. This is actually the Debian practice that the systemd people tried to take account of in the design of their presets system. Installing a package on Debian not only installs the software, but it automatically configures and runs it, too. Hence the idea that systemd presets can be made to default to "enable" on Debian and default to "disable" elsewhere. This is a Debian norm. It's one that various Debian developers have tried to change over the years. The convention of having separate "run" packages exists and a few people adhere to it. (bcron-run, socklock-run, qmail-run, dqcache-run, bincimap-run, ...) But that convention is not (yet) the Debian norm. This is even though people have been regularly pushing for it since the turn of the century. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107862 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=107862 * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804018 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804018