 | NixOS ACME / LetsEncrypt | 107 Members |
| Another day, another cert renewal | 45 Servers |
| NixOS ACME / LetsEncrypt | 107 Members |
| Another day, another cert renewal | 45 Servers |
| Sender | Message | Time |
|---|---|---|
| 12 Nov 2024 | ||
 ThinkChaos | But yeah I think the best for the locking would be to write a small CLI tool that's less cursed and based on FIFOs so I'm playing with that | 22:55:03 |
| ThinkChaos | Would avoid the whole round robin bit of code at the cost of one more daemon to manage the FIFO (since the FIFO's data is lost when the writer closes, so daemon required| | 22:55:57 |
| ThinkChaos | * Would avoid the whole round robin bit of code at the cost of one more daemon to manage the FIFO (since the FIFO's data is lost when the writer closes, so daemon required) | 22:55:59 |
| ThinkChaos | 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. | 23:08:15 |
| ThinkChaos | Basically asking if I should spend more time pursuing those 2 tools now | 23:08:30 |
 emily | quite tempted, but please don't block any work on it, it is very far down my list of priorities | 23:08:41 |
| emily | I have no plans to actively write an ACME implementation and even if I developed such plans I would not expect a deliverable before late 2025 | 23:09:00 |
| emily | especially since I consider Caddy-as-ACME-client to be basically good enough | 23:10:06 |
| ThinkChaos | Ok, then I'll have my fun with and experiment more | 23:11:41 |
| 13 Nov 2024 | ||
 m1cr0man | In reply to @thinkchaos:matrix.org 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. | 01:30:53 |
| ThinkChaos | In reply to @thinkchaos:matrix.orgThe daemon thing is just for locking, basically replacing GNU Parallel in that^ | 01:35:01 |
| emily | fwiw I think ThinkChaos was referring to my approach of just writing a proper daemon that handles certificate management as "going nuclear", not their suggestion | 01:35:17 |
| ThinkChaos | Yeah "going nuclear" I meant replacing Lego | 01:35:40 |
| ThinkChaos | "2 tools" I mean:
| 01:36:59 |
| ThinkChaos | ATM I'm playing with 1. For 2. I have no immediate plans, maybe it's not the best thing, and contributing to Lego is better | 01:37:31 |
| ThinkChaos | I haven't looked at if 2 is worth doing | 01:37:38 |
| m1cr0man | Ok grand. I'm also going to continue with my plans to upstream what I can to Lego and look for ways to simplify things. Btw I appreciate your thorough review on the setup PR, will update it tonight | 09:48:18 |
 Inayet joined the room. | 22:16:40 | |
| 15 Nov 2024 | ||
 Stéphan | I neglected to mention this here: https://github.com/AngryBytes/nixos-certmagic It's an alternative ACME implementation using Caddy's certmagic, as a daemon. | 20:55:29 |
| Stéphan | Very much experimental, but it's got a working happy path test based on the NixOS tests. Currently trying it out on a small server as well. | 20:58:37 |
| m1cr0man | Interesting work. I will probably prod you with questions about it. One thing I have to ask off the bat is the claim in the readme is the Faster NixOS activation when dealing with lots of certificates. Are you referring to evaluation time or the actual time it takes for the services to start? | 21:31:20 |
| m1cr0man | * Interesting work. I will probably prod you with questions about it. | 21:42:01 |
| 16 Nov 2024 | ||
| emily | oh, someone beat me to it? :p | 02:56:37 |
| emily | I was going to NIH it further and not even use certmagic, but certmagic is a good direction | 02:57:01 |
| emily | ah, that someone is you :) | 02:57:33 |
| Stéphan | In reply to @m1cr0man:m1cr0man.comPlease do! I'm curious if this can be useful in NixOS / how we feel about separate implementations. | 07:53:08 |
| Stéphan | In reply to @emilazy:matrix.orgI was reading the discussion above a little bit, and it's definitely different. There're options in NixOS that I don't think I/we can implement with certmagic. | 07:55:16 |
| emily | what do you think is unimplementable other than multiple SANs in one cert? | 08:07:10 |
| emily | (which is bad practice anyway) | 08:07:13 |
| Stéphan | In reply to @emilazy:matrix.orgSkimming through it again, it may not be as bad as I thought. SAN is the big one, webroot is impossible I think, but I wonder if we could implement dnsProvider to match lego, and solve postRun/reloadServices with systemd path units. | 08:54:17 |