| 4 Jul 2025 |
 Theuni |
- the assurance: the files referenced in your config file are now available and are valid ssl certificates. Go forth and start!
| 06:31:58 |
| Theuni |
- the signal: the content of the files has changed and you likely want to reload/restart to pick up the new content.
| 06:32:22 |
| Theuni | The assurance doesn't really even have to be a valid/current/... acme certificate, but basically something that allows the service to start (e.g. the self signed certificates or maybe even an outdated acme cert). | 06:32:53 |
| Theuni | Which is already used for things like allowing bootstrapping the infrastructure to answer HTTP-01. | 06:33:46 |
| Theuni | Now, we do need some unit that stays active (we used the -finished targets for this previously) so that s-t-c can trigger config updates. This was very indirect previously - moving this to a unit that is oneshot/remainafterexit (the "order" unit in my patch) makes config changes trigger more precisely. | 06:35:11 |
| Theuni | However, active units can't be triggered by timers, hence a "renew" unit that can be triggered by a timer. Initially I started out with the renew unit just being a "systemctl restart acme-${cert}", having all the tasks in a single bash script. I was somewhat wary of duplicating too much (bash) code (i did duplicate the nix code for the units) so I chose an inversion of control pattern where the renew unit then triggers the order unit again to make sure permission settings, relocating the updated certificates etc. happens in only a single place as well as triggering the reloads for consumers. | 06:37:21 |
| Theuni | (I'm using the chat to talk out my thought processes. Basically just🎈🦆ing here ...) | 06:39:22 |
| Theuni | *
- the assurance: the files referenced in your config file are now available and are (syntactically) valid ssl certificates. Go forth and start!
| 06:39:57 |
| Theuni | That inversion makes the dependencies muddied again. I could split it up in more units, moving the post-processing code in a separate unit, or just use a shared (execstartpost) script (or partial). | 06:42:16 |
| Theuni | Hmm. Consolidating multiple certificates renewing at the same time isn't much of an issue I guess as we distribute the renewal timers over time anyway. | 06:43:05 |
| Theuni | * Hmm. Consolidating client reload signals for multiple certificates renewing at the same time isn't much of an issue I guess as we distribute the renewal timers over time anyway. | 06:43:18 |
| Theuni | So. I guess two units would suffice: 1st unit (acme-${cert}) is what clients depend via want/after on, which guarantees a syntactically valid certificate is there - which updates the certificate parameters when the config changes. Interestingly, the last part isn't really needed for the assurance itself. 2nd unit to issue ACME renewals. | 06:46:40 |
| Theuni | I wonder whether the "update the parameters" (which requires an active unit to trigger selectively) could/should move elsewhere. It can't be merged with the 2nd unit because that conflicts with the timer requirement. | 06:47:22 |
| Theuni | The renewal itself does depend on the order being current/successful, though as hexa noted. | 06:48:05 |
| Theuni | 
Download Screenshot 2025-07-04 at 10.12.07.png | 08:12:46 |
