| 16 Nov 2024 |
 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 |
| Stéphan | For some reason I find the long activation a bit nerve wrecking. 😬 | 14:06:18 |
| Stéphan | The other pro mentioned, the clustering, is more PoC than anything else. You could do DNS RR that way, but not something I'd want to deploy. It might be interesting to build load balancers with failover, but I don't yet have an easy solution for that. (We currently rely on AWS ALB for that.) | 14:09:29 |
 ThinkChaos | I definitely use per cert targets, and think it's indeed vital that if one cert fails it doesn't prevent the whole system from functioning | 16:26:41 |
| m1cr0man | Is that so you could do http-01 with multiple external addresses + servers? | 16:50:46 |
| ThinkChaos | I use DNS validation but have multiple independent services using ACME, mostly an HTTP server and a (secure) DNS server | 16:52:04 |
| ThinkChaos | BTW I'm trying a different approach to simplifying the locks (had a "why didn't I think of this earlier moment"). Basically remove all the round robin stuff from Nix and just use a loop in the shell script to try each lock with a timeout until one works
That makes the locking pretty straightforward, and activation should be quicker since we'll parallelize more by using whatever lock is available at a given time | 17:30:39 |
| ThinkChaos | Here's that code: https://github.com/NixOS/nixpkgs/commit/ec145d8ccdd64ea6faef4881163e3811a5bf07f3 | 18:00:48 |
| ThinkChaos | m1cr0man do you prefer I wait for your PR to be merged before opening one for this to avoid conflicts? | 18:02:56 |
| m1cr0man | I would yeah, if that's alright? I'd also like to give that a review when I get a moment | 18:06:34 |
| ThinkChaos | Ok no worries | 18:07:40 |
| Stéphan | In reply to @thinkchaos:matrix.org
I definitely use per cert targets, and think it's indeed vital that if one cert fails it doesn't prevent the whole system from functioning Definitely. I used the same approach generating selfsigned first, then notify systemd to continue dependant units.
Do you use the targets to sequence startup of other services, or something else? | 18:26:49 |
| ThinkChaos | I don't use the self signed certs and my services use requires = [ "acme-finished-${cert}.target" ]; | 18:29:39 |
| Stéphan | In reply to @m1cr0man:m1cr0man.com
Is that so you could do http-01 with multiple external addresses + servers? Exactly, certmagic coordinates using some shared storage. So you'd get some rudimentary balancing via DNS RR, but no redundancy. For that you still need some IP failover setup. | 18:32:53 |
| Stéphan | In reply to @thinkchaos:matrix.org
I don't use the self signed certs and my services use requires = [ "acme-finished-${cert}.target" ]; I wonder if I can hack around that with certmagic, haha. I kinda don't want to run the daemon as root, but maybe a separate service can run as root, act on PathModified to check for valid certs, then fire the targets. 🙃 | 18:45:05 |
| ThinkChaos | The daemon should be ok running as acme user and group combined with something like SupplementaryGroups = lib.unique (map (c: c.group) cfg.certs) | 19:13:33 |
| ThinkChaos | Actually plain acme user should do, certs.*.user doesn't do anything anymore so the acme user can read/write all certs | 19:21:53 |
| emily | In reply to @stephank:stephank.nl
I wonder if I can hack around that with certmagic, haha. I kinda don't want to run the daemon as root, but maybe a separate service can run as root, act on PathModified to check for valid certs, then fire the targets. 🙃 maybe you can hook something up with user systemd | 19:39:29 |
