[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Letsencrypt-devel] Certbot in Debian Stretch



On 11/30/2016 02:33 PM, Virgo Pärna wrote:
> On Fri, 25 Nov 2016 15:41:45 +0100, Christian Seiler <christian@iwakd.de> wrote:
>>
>> is not an issue (it works fine), but I had modified the cron job to
>> pass --renew-hook and --post-hook to certbot. (As far as I can tell,
>> there's no way of setting these in a configuration file.) The only
> 
> 	I think that /etc/letsencrypt/cli.ini is supposed to work for it.

As far as I am aware this is non-standard, and all examples with
that file name I could find would do

certbot --config /etc/letsencrypt/cli.ini

However, certbot --help paths clearly states that --config has no
default value, so by default certbot does not read that file, and
strace confirms it. Actually, the only files read in by certbot
in /etc/letsencrypt are /etc/letsencrypt/renewal/$certname.conf
and /etc/letsencrypt/archive/$certname/cert$N.pem.

And manually adding --config to the cron job would have left me in
the same situation when the package migrated to a systemd service.

Don't get me wrong: it's not my intention to bad-mouth certbot
here, I only want to make clear that in the past by using the
package from jessie-backports I've experienced two situations
where I had to manually intervene during an upgrade. Once when the
package was renamed and once when the systemd timer was
introduced. In both cases I was knowledgeable enough to cope with
that, so nothing really broke for me, but both cases were an
example where an upgrade did not go as smoothly as I'd expect
from Debian stable. I hope this feedback helps the certbot
maintainers in gauging where they still need to improve their
processes in the future. On the other hand, I've upgraded certbot
and previously letsencrypt a lot of times on the same system, and
never had any other problems, the rest was completely smooth
sailing for me, so I believe they're doing something right.

Regards,
Christian


Reply to: