NixOS ACME / LetsEncrypt | 103 Members | |
| Another day, another cert renewal | 42 Servers |
| Sender | Message | Time |
|---|---|---|
| 8 Nov 2024 | ||
| https://github.com/NixOS/nixpkgs/pull/354629/files#diff-352faa44c3da86e70bd6b5a55ff13f0a900b0f2fac44229f352ed1fd5b93a262R749-R751 | 23:11:25 | |
| How did this ever work | 23:11:28 | |
| what's wrong with that? | 23:12:31 | |
| OK this makes no sense | 23:12:38 | |
| It's starting the cert renewal first | 23:12:49 | |
| And then the server | 23:12:58 | |
| Ngl, it's pretty vindicating that someone else is witnessing the quantum hell that is the ACME test suite, and not just my imagination. | 23:13:19 | |
| And I think the ordering on it is actually just all wrong | 23:13:22 | |
Download {A552CC2F-C32F-444C-8CDC-9B4F274FF447}.png | 23:14:17 | |
| Yeah this is 100% wrong | 23:14:45 | |
The acme units need to wants httpd for this | 23:14:55 | |
If not requires | 23:15:09 | |
Actually probably requires, just so we fast-fail | 23:15:16 | |
I'm not following. Part of this is from the change earlier today. That's a screenshot from a webserver module right? It's only set to before on the renewals that use HTTP-01. wanting the target means that renewal gets queued in the same job as the web server start. | 23:16:49 | |
| it's convoluted, but in the case of a web server it's generally as follows on startup:
| 23:19:49 | |
this all hinges on my understanding/observations of wants dependencies on a target, and how start job transactions are evaluated | 23:20:36 | |
| That before isn't enough | 23:20:47 | |
| You need the http-01 units to actually wants it | 23:21:07 | |
| I know before/after don't queue start jobs, but the target implicitly will | 23:21:10 | |
| iirc the target requires the renewal, so that will queue the start job, and those before/after should queue them appropriately in the same transaction | 23:21:32 | |
| The target will if you start the server, yes | 23:21:33 | |
| But not if you start the target | 23:21:38 | |
| oh fuck | 23:21:51 | |
| So either the test needs to wait for the server before the target | 23:21:55 | |
| Or the units need to also wants the server | 23:22:07 | |
| Which I think is more correct because they actually do | 23:22:18 | |
| hm let me quickly check sth in the webserver units | 23:22:41 | |
| Yeah no, it's totally missing | 23:24:00 | |
Problem is now, from the acme module, we can't determine what web server will be serving .well-known/acme-challenge. We can solve this per-webserver, as you said flip the before to a requiredBy (actually... maybe keep before and add requiredBy). I'm now remembering a very old conversation about having web server units register a common target, but I ended up implementing
I wonder how bad it would be to remove the install/wantedBy directives from the acme module, and let dependent services trigger its startup? Infact what if we had a | 23:30:00 | |
*
Problem is now, from the acme module, we can't determine what web server will be serving .well-known/acme-challenge. We can solve this per-webserver, as you said flip the before to a requiredBy (actually... maybe keep before and add requiredBy). I'm now remembering a very old conversation about having web server units register a common target, but I ended up implementing
I wonder how bad it would be to remove the install/wantedBy directives from the acme module, and let dependent services trigger its startup? Infact what if we had a | 23:30:16 | |