NixOS ACME / LetsEncrypt - Public Room Timeline

	NixOS ACME / LetsEncrypt	106 Members
	Another day, another cert renewal	42 Servers

Load older messages

Sender	Message	Time
12 Nov 2024
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 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.	01:30:53
ThinkChaos	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 ...'` The 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: a daemon to implement the locking without Nix hackery a tool to create the ACME provider account without obtaining a cert, and writing it to where Lego expects it	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.com Interesting work. I will probably prod you with questions about it. Please 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.org I was going to NIH it further and not even use certmagic, but certmagic is a good direction I 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.org what do you think is unimplementable other than multiple SANs in one cert? Skimming 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
emily	ah, trying to maintain compatibility with the weird lego format of configuration for every single DNS provider is hopeless I think – that'd have to be a compat break	08:54:45
emily	systemd stuff is vital though	08:54:55
Stéphan	I haven't looked at the dns stuff yet, but lots of storage options for certmagic are available as caddy modules, not necessarily standalone. I wonder if dns providers are the same, and if that makes it more difficult to implement broad support.	08:57:44
emily	we could probably just bundle every libdns provider in the universe into our executable	08:59:36
Stéphan	In reply to @emilazy:matrix.org systemd stuff is vital though I skipped all the target units while implementing with certmagic. Are those vital? 😇	09:00:04
Stéphan	Not sure how much people depend on the specific units to build dependencies.	09:05:52
m1cr0man	What is your overall goal with this implementation?	11:04:03
Stéphan	In reply to @m1cr0man:m1cr0man.com What is your overall goal with this implementation? Primarily reduce time of activation with a lot of certs.	14:05:11

Show newer messages

Back to Room ListRoom Version: 6