NixOS ACME / LetsEncrypt | 107 Members | |
| Another day, another cert renewal | 45 Servers |
| Sender | Message | Time |
|---|---|---|
| 1 Apr 2025 | ||
| 13:57:36 | ||
| 13:59:16 | ||
| 4 Apr 2025 | ||
| 15:55:33 | ||
| 5 Apr 2025 | ||
| 15:53:09 | ||
| 15:56:20 | ||
| 19 Apr 2025 | ||
| ok, so bummer | 22:48:50 | |
| enabling ARI caused lego to keep waiting | 22:49:54 | |
| 22:49:56 | |
| but that resulted in nginx not starting up | 22:50:03 | |
| because it depends on all the acme-${domain}.service units | 22:50:28 | |
| hm, I thought we were going to set it to just not wait? | 22:52:10 | |
| and we did not set it to anything in nixpkgs | 22:54:08 | |
| but I set it to something on my private infra | 22:54:16 | |
| right | 23:00:12 | |
| I think the current format will only work well when set to not wait at all | 23:00:19 | |
| (which should be fine as the cron job runs often anyway, though we might want to bump it) | 23:00:29 | |
| 21 Apr 2025 | ||
| There was some talk about bumping it when they announced the lower lifetime certs. Wouldn't be the worst thing to do. | 19:18:58 | |
| 22 Apr 2025 | ||
| now 47 days was announced to be the next shorter lifespan | 23:08:50 | |
| and I don't think it warrants trying more than daily for 7-14 days | 23:09:13 | |
| * and I don't think it warrants trying more than daily | 23:09:33 | |
| for 6 days that changes of course | 23:09:45 | |
| 28 Apr 2025 | ||
| https://github.com/NixOS/nixpkgs/pull/376334#pullrequestreview-2801003367 this is ready to go. I tested it too. | 21:26:09 | |
| 29 Apr 2025 | ||
| 23:42:45 | ||
| 5 May 2025 | ||
| hi everyone, does anybody have a workaround that fixes this pesky dns resolution issue when
| 17:59:16 | |
| what seems to be happening is that acme is starting so early that the container is unable to route things yet. Maybe the host has not installed routes yet? but that somehow acme blocks until it times out. | 18:00:34 | |
| once it times out, then everything works fine. I have whittled it down to acme, because when I remove any acme things the container boots up just fine and is able to route/ping quite quickly | 18:01:46 | |
| so, by that, I mean that the issue does not seem to be pertaining to (in my case)
that the behavior occurs. | 18:04:57 | |
what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) | 18:07:29 | |
* what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) until it times out. There must be something I do not understand about how systemd works or calls this, but I woudl like to learn ;) | 18:07:56 | |
* what I am most confused about (and why I am posting here) is why the call to lego --accept-tos --path . -d '*.<redacted>' --email <redacted> --key-type ec256 --dns rfc2136 --dns.propagation-disable-ans --dns.resolvers 127.0.0.1:53 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --days 30 seems to block all network traffic, even for other services (like wireguard, bind, etc) until it times out. There must be something I do not understand about how systemd works or calls this, but I would like to learn ;) | 18:08:04 | |