| 19 Aug 2023 |
 m1cr0man | God damn acme tests | 18:46:57 |
| m1cr0man | I'm gonna fix that add-a right now | 18:47:02 |
|  @cel:pussy.accountants left the room. | 18:56:00 |
| m1cr0man | here we go https://github.com/NixOS/nixpkgs/pull/250260 | 21:43:25 |
| 22 Aug 2023 |
| m1cr0man | Any comments from people on the locking PRs? Discussion here. Would appreciate an arbiter/voting on the preferred solution. | 18:21:42 |
 raitobezarius | Personally, I'd prefer to see this solved in systemd | 19:32:27 |
| raitobezarius | And used in NixOS | 19:32:29 |
| raitobezarius | Rather than solved in NixOS | 19:32:32 |
| raitobezarius | As you said it, we have too much complexity in our NixOS module | 19:32:54 |
| raitobezarius | Because we don't have enough good primitives for this | 19:32:59 |
| raitobezarius | systemd is in the good position to create the right primitive | 19:33:05 |
| raitobezarius | Meanwhile, an official patch can be blessed | 19:33:12 |
| raitobezarius | And can be applied to nixpkgs | 19:33:17 |
| raitobezarius | https://github.com/systemd/systemd/issues/28075 | 19:33:38 |
| raitobezarius | As the OP is interacting here, I'd just encourage to push through | 19:33:49 |
| raitobezarius | And coordinate with NixOS systemd folks if help is needed | 19:33:56 |
| raitobezarius | It's not like anyway we don't need that feature for something else than ACME | 19:35:56 |
| raitobezarius | So I wish we don't see hacks to generalize this behavior everywhere | 19:36:03 |
| m1cr0man | I do agree this should be solved upsream. I don't know if you clicked in but the "competing" PR (my one) is a pure systemd + nix implementation with arguably less overheads. | 20:26:48 |
| m1cr0man | It's annoying to add more complexity but personally I am trying to keep the diff and unique code low where possible. Both lego and systemd could do with upstreamed features to help us out. For example, if lego had an "offline ok" flag for checking renewal that would remove all the openssl shenanigans. I did plan to upstream that at one point but just never had the time | 20:29:25 |
| 30 Aug 2023 |
|  ajs124 joined the room. | 17:38:15 |
|  Andreas Schrägle left the room. | 17:57:46 |
|  osnyx (he/him) joined the room. | 23:06:39 |
| 31 Aug 2023 |
|  moritz.hedtke removed their display name moritz.hedtke. | 16:13:38 |
| 4 Sep 2023 |
| osnyx (he/him) | Finally noticing there's a NixOS ACME room, I'd like to kindly invite you to give your opinion on https://github.com/NixOS/nixpkgs/issues/232505#issuecomment-1669434562 and how we can move this forward. It'd be really great to get this into 23.11 as a fix that does change some default behaviour.
I'll also be present at NixCon later this week for further discussions there, but feel free to spread the discussion on this over Matrix and the GitHub issue/PRs as well. | 12:12:12 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.org
Personally, I'd prefer to see this solved in systemd I'd like to see such primitives in systemd as well. Unfortunately, the issue being resolved by the PR is a thing right now. The only WIP systemd PR #27985 though has seen its last activity in July, and currently also does not really provide what we need anyways as it makes the services exceeding a concurrency limit fail instead of blocking them.
Given the last systemd releases took 4-5 months, even under favourable circumstances it'd probably take at least until NixOS 24.11 until we could have a systemd with locking primitives in NixOS and have managed to change the acme module accordingly. | 12:27:10 |
| osnyx (he/him) | I was actually the one suggesting in the PR that this should include support for blocking services as well. While Lennart Poettering has supported the idea, this is the only thing that happened towards that, the PR still does not support blocking/ delaying unit starts.
When it comes to doing the systemd patches myself, I unfortunately do not really feel comfortable with writing system-level C code for such delicate subsystems. | 12:30:44 |
| osnyx (he/him) | What I could pledge is that I'll rebuild the ACME locking code away from the introduced intermediary solution towards systemd locking primitives, if they ever arrive. | 12:31:44 |
| osnyx (he/him) | TL;DR: Wanting to solve the acme generation concurrency issues with systemd is a nice approach, but implies leaving the issue unresolved for at least a year, if not longer. It is unclear whether the required mechanisms will ever be introduced to systemd, who's taking care of achieving this, and when this might happen. | 12:34:01 |
| osnyx (he/him) | If we decide to go with one of the PRs, there's another thought:
m1cr0man has implemented the run exclusions using systemd, citing a reduction of module complexity. I do agree with the general goal, we need to consider what kind of complexity we mean here.
When it comes to understanding and reading what the module does to be able to maintain it, it's not just about the number and variety of involved software components but also about their scoping and the mental model presented by their interface. | 12:47:11 |
