 | NixOS ACME / LetsEncrypt | 93 Members |
| Another day, another cert renewal | 43 Servers |
| NixOS ACME / LetsEncrypt | 93 Members |
| Another day, another cert renewal | 43 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Sep 2023 | ||
 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 |
| osnyx (he/him) | Building a component that presents the clear abstraction "I am doing locking and exclusion" can be treated just by its promised functionality at superficial reading. Only when there are clues that it's actually the locking internals that are problematic, the internal component's implementation needs to be read and understood as well. The solution by m1cr0man works well, too, but we might face the danger of the additional systemd unit parameters getting lost in the noise of the already present multitude of systemd unit parameters of acme units. | 12:51:09 |
 raitobezarius | In reply to @os:matrix.flyingcircus.ioThe question is for whom are you solving this such urgently? | 12:53:13 |
 m1cr0man | This really comes down to a question of maintenance in my head. Both add complexity in their own ways, and have other merits. To be honest, I'm stuck for time at the moment and I would gladly take the help on keeping the module functioning at the moment. If you are willing to help maintain this portion of the module Oliver, then I'm happy to see your pr merged 🙂 | 12:53:40 |
| raitobezarius | If we implement the solution in systemd, while it's true that the latency of getting those changes in systemd takes time, it does not prevent anyone running them inside of an organization :) | 12:53:46 |
| raitobezarius | I am biased either way as a systemd and NixOS developer and see the value of having this upstream rather than specialized here | 12:54:48 |
| raitobezarius | So don't take my opinion as a blocker or whatever | 12:55:06 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.orgWhether this is urgent for NixOS upstream is partly your decision as the maintainers team (as a personal user I'd say yes as well), but the implementation I am doing for FlyingCircus. | 12:55:25 |
| raitobezarius | From my personal perspective as a NixOS developer, there's an appetite for anti concurrency for any systemd service honestly | 12:55:59 |
| raitobezarius | Giving a pass to ACME is probably fine because of the importance | 12:56:14 |
| raitobezarius | But I don't think we could accept the proliferation of this ad-hoc everywhere | 12:56:25 |
| raitobezarius | Hence my desire to solve it at the primitive level | 12:56:35 |
| raitobezarius | Therefore I don't think there's an emergency beyond ACME large users (you and some folks, including me) | 12:57:16 |
| osnyx (he/him) | AFAIK keeping patches on NixOS modules downstream is not that easy, correct me if I'm wrong. Additionally to being good citizens in the NixOS community and trying to wor upstream-first for apparent bugs, I'd of course also want to prevent having to maintain a downstream module fork. | 12:57:38 |
| raitobezarius | (of course I say this and microman is the maintainer of this subsystem) | 12:57:42 |
| raitobezarius | In reply to @os:matrix.flyingcircus.ioI do keep 20ish patches for my own infra for a large infra, I am not sure if you are targeting stable or unstable | 12:58:10 |
| raitobezarius | Surely having a custom systemd will set you for some pain if you don't have large build farm or too regular builds | 12:58:27 |
| raitobezarius | Also, I do see running this downstream as an extremely valuable way to gather feedback on systemd primitives and experience | 12:58:56 |
| raitobezarius | Ultimately paving the way to push it upstream | 12:59:04 |
| osnyx (he/him) | In reply to @raitobezarius:matrix.orgI'm supportive of that. But as I said, I won't be the one writing that C code, but could be the one solving this as I had done in the PR with the lowest footprint I could do. | 12:59:13 |
| raitobezarius | Large features like this are often blocked because everyone is paralyzed by it not being "finalized" | 12:59:20 |