| 17 Feb 2025 |
 emily | we do at least randomize enough to avoid a periodic thundering herd | 17:14:28 |
 hexa | I think for now it would be good to just enable ARI, so lego would do early renewal, even if the cert lifetime is fine | 17:14:31 |
| hexa | * I think for now it would be good to just enable ARI, so lego would do early renewal, even if the perceived cert lifetime is fine | 17:14:37 |
| emily | yes, would be a good incremental improvement, should be harmless to do by default | 17:14:44 |
| hexa | * I think for now it would be good to just enable ARI, so lego would do early renewal, even if the perceived cert lifetime as sufficient | 17:15:04 |
| emily | if this supports sleeping until lego thinks it'd be a good time to renew even if the endpoint doesn't support ARI, then maybe we could get rid of timers entirely and just run a lego renewal process per domain | 17:15:25 |
| emily | I suspect not though, in which case it would be a horrible pain to bifurcate the logic | 17:15:34 |
| hexa | + lego --accept-tos --path . -d juno.lossy.network --email hexa@darmstadt.ccc.de --key-type ec384 --dns rfc2136 --server https://acme-v02.api.letsencrypt.org/directory renew --no-random-sleep --ari-enable --days 30
2025/02/17 17:17:18 [INFO] [juno.lossy.network] acme: renewalInfo endpoint indicates that renewal is not needed
2025/02/17 17:17:18 [juno.lossy.network] The certificate expires in 89 days, the number of days defined to perform the renewal is 30: no renewal.
| 17:17:42 |
| hexa | https://github.com/go-acme/lego/blob/master/cmd/cmd_renew.go#L175 | 17:18:36 |
| hexa | so we could pass a willingness to sleep 23h59m for example | 17:19:06 |
| hexa | * so we could pass a willingness to sleep 23h for example | 17:19:13 |
| hexa | and lego wouid apparently wait sleeping | 17:19:38 |
| hexa | extraLegoRenewFlags = [
# https://datatracker.ietf.org/doc/draft-ietf-acme-ari/
"--ari-enable"
"--ari-wait-to-renew-duration=${toString (86400 - 3600)}s" # 23h
];
| 17:33:19 |
| emily | yeah, but what if your ACME provider doesn't support ARI? | 18:52:09 |
| emily | I think we'd want an unlimited --ari-wait-to-renew-duration in theory, but if it's just going to exit out immediately if ARI isn't present then we can't get rid of the timer | 18:53:06 |
| hexa | In reply to @emilazy:matrix.org
yeah, but what if your ACME provider doesn't support ARI? Then nothing happens | 23:20:04 |
| 18 Feb 2025 |
 Sandro 🐧 | FYI https://github.com/NixOS/nixpkgs/pull/382863 | 16:52:15 |
| 19 Feb 2025 |
| hexa | https://github.com/go-acme/lego/commit/98371c4695dd4e45d7458d8ba42272f6fa0c625d enables ARI by default | 16:41:06 |
| hexa | in 4.20.2 | 16:41:09 |
| hexa | so we just need to agree on the proper wait duration | 16:41:26 |
| Sandro 🐧 | I have extraLegoRenewFlags = [ "--ari-enable" "--ari-wait-to-renew-duration" "5m" ]; in my config but I cannot tell you any advtanatages/disavtanages of it sadly | 16:44:34 |
| hexa | 5m is not a reasonable wait duration 😄 | 16:44:47 |
| emily | I think we don't want to limit it at all if we're using ARI. the ACME server will pick the appropriate time to wait. but I'm still not clear on how it's meant to integrate into our timer system. my understanding is that lego renew won't block indefinitely when not using ARI, but does block when using it? | 16:44:47 |
| hexa | yep | 16:45:05 |
| emily | the two modalities seem totally different: one is a ~non-blocking poll on a timer, the other is a long-running waiting daemon | 16:45:16 |
| hexa | I think I set it to 23h to not interact with the timer | 16:45:24 |
| hexa | but to cover most of the time when it would not run | 16:45:34 |
| emily | I don't see how that works with our setup unless we can get lego renew to also wait for non-ARI certificates | 16:45:37 |
| hexa | I think infinite could work, but infinite would then probably be something like 30 days? 90 days? | 16:45:56 |
| emily | does --ari-wait-to-renew-duration force renewal when the timer expires? or does it just exit without renewing if the wait is further than that? | 16:45:59 |
