| 4 Sep 2023 |
 osnyx (he/him) | In reply to @m1cr0man:m1cr0man.com
I think your arguments are solid. I'm not on board for waiting for systemd to add features (and your hammer saying is the same reason why). Like I said if you're willing to just be around to take questions or PR fixes into that portion of the module, I'm happy to see your one merged. I do think it is more complicated but I can live with that if I'm not the only one that understands how it works.
I would like you to copy over the test case I made though, to prevent future regressions That's why I wanted to get another opinion of the team regarding not the only one that understands how it works.
I try to get the tests in this week. | 13:59:31 |
 raitobezarius | I think it's fair that we set the "direction of the ACME module" to: we can welcome this feature and urge/usher into an era where systemd will provide it and we can decrease the complexity in the future | 14:05:46 |
 m1cr0man | I also want to upstream some stuff to Lego, so between the two hopefully complexity will fall over the next while. | 14:11:31 |
| osnyx (he/him) | * My take on the "let's solve it with systemd unit options alone" approach is just the idea that we must be careful to not fall into the when all you want to use is a systemd-253 hammer, everything looks like a unit option nail.
It might be a hammer you know, but that hammer bight also just be adding things to the evergrowing list of interwoven systemd unit relationships… | 14:24:55 |
| osnyx (he/him) changed their display name from Oliver Schmidt to osnyx (he/him). | 20:10:48 |
| 9 Sep 2023 |
| osnyx (he/him) | m1cr0man: Can you take care of the concurrency PR or shall I use the opportunity at NixCon to ask some other ACME team maintainers as well? | 17:13:59 |
| m1cr0man | Yo merge it? You need to ask like anyone with merge permissions. I approved it right? | 17:15:21 |
| osnyx (he/him) | In reply to @m1cr0man:m1cr0man.com
Yo merge it? You need to ask like anyone with merge permissions. I approved it right? I cannot see any approval, sorry. | 17:40:41 |
| osnyx (he/him) | There's a merge party right now. So I guess I should still squash the commits I guess? | 17:41:07 |
| osnyx (he/him) | https://github.com/NixOS/nixpkgs/pull/244511 | 17:41:33 |
| osnyx (he/him) | So in case I get your approval, I can certainly get it merged. | 17:42:26 |
| m1cr0man | Ah well I can do that | 17:43:06 |
| osnyx (he/him) | I'll squash the commits, give me a sec | 17:43:21 |
| osnyx (he/him) | m1cr0man: squashed an pushed | 17:45:28 |
| m1cr0man | Cool ok | 17:45:42 |
| osnyx (he/him) | Thanks a lot | 17:54:08 |
| 21 Sep 2023 |
|  dedmunwalk joined the room. | 23:08:48 |
| 22 Sep 2023 |
|  K900 changed their profile picture. | 09:53:38 |
| 25 Sep 2023 |
| osnyx (he/him) | m1cr0man: Hey, you probably want to close your alternative PR https://github.com/NixOS/nixpkgs/pull/246665 | 21:38:44 |
| m1cr0man | ty for the reminder | 21:52:45 |
| 2 Oct 2023 |
|  Train joined the room. | 01:42:45 |
| osnyx (he/him) | Hey,
I might have run into a general issue with acme and nginx again, but wonder whether I am holding it wrong because nobody else has complained about it so far:
Initial acme certificate generations fail for newly added vhosts when nginx has already been running | 12:33:31 |
| raitobezarius | I don't think I encountered this issue personally | 12:40:47 |
| raitobezarius | How is it failing? | 12:40:59 |
| osnyx (he/him) | Background:
When changing the config file by e.g. adding new vhosts at switch time, nginx is not immediately reloaded and being made aware of the config changes. One of the reasons is that new vhosts might rely on certificate files yet to be generated by the acme subsystem. Reloading is thus triggered by nginx-reload-config.service.
Its dependencies are configured as such that it runs before the respective acme-domain-finished.target, but after the acme-domain.service renew service. That service though communicates with an acme registry and makes the registry fetch the validation response from nginx. With the config not being reloaded yet, nginx does not know the respective vhost and cannot serve a valid response. | 12:45:48 |
| osnyx (he/him) | acme: error: 403 :: urn:ietf:params:acme:error:unauthorized | 12:46:49 |
| osnyx (he/him) | Failed to fetch certificates. This may mean your DNS records are set up incorrectly. Selfsigned certs are in place and dependant services will still start. | 12:47:15 |
| osnyx (he/him) | As nginx is reloaded even after failing scme service runs, the next retry of the service succeeds and after a few minutes, the certs are successfully validated. But the initial switch-to-configuration exits with a failure code. This is not very useful if you call taht switch as a part of a deployment script. | 12:48:56 |
| osnyx (he/him) | I mainly want to know whether
- folks here are aware of such issues
- this was a concious decision to live with a failing
switch that repairs itself after a few minutes
- I am holding it wrong.
| 12:50:03 |
| osnyx (he/him) | The reload situation right now is
<nginx.conf updated> -> <acme-selfsigned service run> -> <acme-renew run> -> <nginx-reload-config.service> -> <acme-finished target> | 12:52:15 |
