 | NixOS ACME / LetsEncrypt | 126 Members |
| Another day, another cert renewal | 53 Servers |
| NixOS ACME / LetsEncrypt | 126 Members |
| Another day, another cert renewal | 53 Servers |
| Sender | Message | Time |
|---|---|---|
| 4 Sep 2023 | ||
 osnyx (he/him) | In reply to @raitobezarius:matrix.orgI'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 |
| 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 (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | From my personal perspective as a NixOS developer, there's an appetite for anti concurrency for any systemd service honestly | 12:55:59 |
| raitobezarius (DECT: 7248) | Giving a pass to ACME is probably fine because of the importance | 12:56:14 |
| raitobezarius (DECT: 7248) | But I don't think we could accept the proliferation of this ad-hoc everywhere | 12:56:25 |
| raitobezarius (DECT: 7248) | Hence my desire to solve it at the primitive level | 12:56:35 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | (of course I say this and microman is the maintainer of this subsystem) | 12:57:42 |
| raitobezarius (DECT: 7248) | 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 (DECT: 7248) | 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 (DECT: 7248) | Also, I do see running this downstream as an extremely valuable way to gather feedback on systemd primitives and experience | 12:58:56 |
| raitobezarius (DECT: 7248) | Ultimately paving the way to push it upstream | 12:59:04 |