In reply to @thinkchaos:matrix.org
emily: how tempted are you by going nuclear and writing an ACME daemon?
Cause my view is it's easier to write the 2 small tools to move complexity out of the module and call it a day, and I'm willing to spend time on it. But I agree a fully NixOS blessed daemon would be the best solution, just sounds like a lot more work.

I would want to get a set of concrete goals for whatever daemon you are thinking of here. There's features of the systemd implementation we absolutely want to keep, and things we are implementing to get around limitations.

I'm currently of the view that going nuclear isn't required. We can simplify the locking with systemd targets as I demonstrated before, and this is in line with how the account leader is implemented today. Some of the scripting can also be upstreamed to lego - specifically returning a different return code when certs are not expired but cannot be checked online. This only leaves some minor setup things to a daemon, plus perhaps evaluating a locking system.

I'm not going to say don't do it, this sort of passion to solve the problem can only result in positive improvement 😄 do bare in mind though that there's a lot of skeletons in the ACME module closet - so many edge cases we've engineered it to fit. There's good reason to keep the cert:service 1:1 mapping for many of the integrations that now exist, and if there is another way, it will need careful testing.

In reply to @thinkchaos:matrix.org
For simplifying the max concurrency, sem from GNU parallel seems like the right tool: https://man.archlinux.org/man/sem.1
The cert ExecStart would look like sem --id nixos-acme --fg --max-procs ${cfg.maxConcurrentRenewals} 'lego ...'

"2 tools" I mean:

1. a daemon to implement the locking without Nix hackery
2. a tool to create the ACME provider account without obtaining a cert, and writing it to where Lego expects it