In reply to @thinkchaos:matrix.org
I definitely use per cert targets, and think it's indeed vital that if one cert fails it doesn't prevent the whole system from functioning

In reply to @m1cr0man:m1cr0man.com
Is that so you could do http-01 with multiple external addresses + servers?

In reply to @thinkchaos:matrix.org
I don't use the self signed certs and my services use requires = [ "acme-finished-${cert}.target" ];

In reply to @stephank:stephank.nl
I wonder if I can hack around that with certmagic, haha. I kinda don't want to run the daemon as root, but maybe a separate service can run as root, act on PathModified to check for valid certs, then fire the targets. 🙃

In reply to @stephank:stephank.nl
Exactly, certmagic coordinates using some shared storage. So you'd get some rudimentary balancing via DNS RR, but no redundancy. For that you still need some IP failover setup.

Cool ok. This is one of those things that I don't think we will ever support in the in-tree ACME module, at least not whilst we use Lego. The main thing going around in my head is that I don't want either project to give the impression that the other is broken in some way, but if there are additional use cases and features in nixos-certmagic that security.acme does not currently offer, then users who stumble upon both options can understand when to chose one implementation over the other.

I find it hard to justify ever changing from lego right now. Most people treat ACME as set-and-forget, literally. If we break people's configs, we need to have a really good reason to do so, and right now I don't think that removing a few lines of bash or improving activation time for more-than-average cert configs is worth it. That's why I'm apprehensive about all this talk of using daemons. Out of tree - sure, I can see the appeal as both an upgrade for those who can handle the reconfiguration of their system, and to cover extra use cases.

Generally, it is expected that /run/ directories map to RuntimeDirectory entries in systemd services.

That's not how I view it, for instance secrets go in /run too. To me it's for anything ephemeral.

AFAIU tmpfiles is generally used for stuff that's required as long as the system is active. Which fits well here.
Relying on a service to start to create a dir then used by other things seems more convoluted to me

That's not how I view it, for instance secrets go in /run too. To me it's for anything ephemeral.

I agree with this, however /run/acme is directly related to service activation + logic implemented in systemd services. Having its lifecycle managed as a RuntimeDirectory definitely makes things easier. I will definitely add a comment to say where it's created, that's a good call that the relation is not obvious

In reply to @k900:0upti.me

webserver # [  426.884702] (es-start)[2816]: acme-lockfiles.service: Changing to the requested working directory failed: Permission denied
webserver # [  426.934208] (es-start)[2816]: acme-lockfiles.service: Failed at step CHDIR spawning /nix/store/n24xs3nmndyyivq3q5w52f7aqlb06hqh-unit-script-acme-lockfiles-start/bin/acme-lockfiles-start: Permission denied

In reply to @thinkchaos:matrix.org
I'll reply and approve 🙂