| 17 Feb 2025 |
 hexa | given that lego is not in control about when we run it again that algorithm seems moot | 17:12:30 |
| hexa | --ari-wait-to-renew-duration value The maximum duration you're willing to sleep for a renewal time returned by the renewalInfo endpoint. (default: 0s)
| 17:13:24 |
| hexa | so this needs to stay at 0, since we cannot deviate interactively from the timer schedule | 17:13:41 |
 emily | probably we would need to rearchitect the entire timer logic to implement LE's recommendations | 17:13:54 |
| emily | it's another thing where modern ACME practices are better suited to long-running manager daemons than cron jobs | 17:14:11 |
| 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 |
