 | 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 |
|---|---|---|
| 13 Jun 2023 | ||
 m1cr0man | okay yeah, so these are pretty lenient for most people I think I was only concerned about the concurrent one that the ticket opener mentioned: Right now this one is very easy to do | 20:19:53 |
| m1cr0man | * okay yeah, so these are pretty lenient for most people. I think I was only concerned about the concurrent one that the ticket opener mentioned: Right now this one is very easy to do | 20:20:03 |
 emily | ah I missed that one. never skim read! | 20:20:30 |
| emily | so yeah my inclination is that it would be good to have something default that ensures we're not issuing certificates at a rate that would surpass that. but preferably not full serialization since that's quite a lot further than that | 20:21:15 |
| emily | I feel like there should be a good way to rate limit these services starting without fussing with CPU quotas or whatever. | 20:21:44 |
| emily | okay there is | 20:22:08 |
| emily | we have StartLimitIntervalSec/StartLimitBurst/StartLimitAction which look perfect. however, I'm guessing that we would need to switch over to @ units to use it - because otherwise all our services are entirely separate | 20:22:45 |
| emily | unless it counts the bit after the @ as part of the unit for rate limiting and it's just for making restarts not spam :/ | 20:23:03 |
| emily | we need a systemd expert :) | 20:23:22 |
| m1cr0man | afaik StartLimit* only applies to services which would enter the failed state? I did consider suggesting that :) however the docs imply it's only for failure. You would need to pair it with Condition/Assert* directives in the unit section, which would be evaluated en masse and actually wouldn't stop concurrency at activation at all | 20:23:50 |
| emily | it does say "Configure unit start rate limiting. Units which are started more than burst times within an interval time span are not permitted to start any more." but yeah I'm not sure if it would work | 20:24:32 |
| m1cr0man | I was thinking we could use unit retry logic + ConditionPathExists for really easy locking and semaphores | 20:24:44 |
| emily | maybe I'm missing some verbiage that applies it's restart-specific but it seems to mostly note that as a side thing? | 20:25:27 |
| m1cr0man | afaik "Units which are started" means "for each unit started" rather than "for all units started", so dynamic services would all be individual services and have their own startlimits | 20:25:31 |
| emily | but I have a suspicion that it may treat all @ unit instantiations as separate in which case it wouldn't help us anyway. sigh, ACME issuance should really be handled as a daemon | 20:25:52 |
| m1cr0man | yarp | 20:26:02 |
| m1cr0man | at what point do I just right NixCerts-rs | 20:26:15 |
| m1cr0man | * at what point do I just write NixCerts-rs | 20:26:19 |
| emily | we are constantly trying to piece together what would be pretty simple logic for a long-running daemon out of paperclips and tape | 20:26:31 |
| emily | heh, I don't envy anyone trying to implement ACME from scratch | 20:26:51 |
| m1cr0man | ... maybe we need an RFC, to propose a new solution for acme | 20:27:00 |
| emily | something with certmagic would probably be pretty easy to do | 20:27:11 |
| emily | (but we can't just switch over to caddy without breakage because of all the lego-specific config we expose...) | 20:27:30 |
| m1cr0man | yeah, sadly | 20:27:38 |
| m1cr0man | it would be a major breaking change and people hate remembering how they set their certs up (me included) | 20:28:04 |
| m1cr0man | what would we need in lego to make this better? daemonising is out of the question, but there's a lot of logic in the renew script right now that could probably go into lego. In my own head, I had some sort of logic for offline renewal check on my list of things to try and contribute that would greatly reduce the complexity on our side today. | 20:29:09 |
| emily | I suspect the majority of people don't have any of the special lego options set. but the biggest breakage would be DNS challenge setups, esp. in terms of provider availability. | 20:29:15 |
| m1cr0man | In reply to @emilazy:matrix.orgyeah lego is pretty much unmatched for DNS support | 20:29:33 |
| emily | Caddy/certmagic/etc. do actually have a backwards compatibility layer for lego's providers | 20:29:34 |
| m1cr0man | oh? | 20:29:43 |