| 4 Jul 2025 |
 Christian Theune | 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 |
| Christian Theune | Which is already used for things like allowing bootstrapping the infrastructure to answer HTTP-01. | 06:33:46 |
| Christian Theune | 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 |
| Christian Theune | 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 |
| Christian Theune | (I'm using the chat to talk out my thought processes. Basically just🎈🦆ing here ...) | 06:39:22 |
| Christian Theune | *
- 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 |
| Christian Theune | 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 |
| Christian Theune | 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 |
| Christian Theune | * 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 |
| Christian Theune | 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 |
| Christian Theune | 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 |
| Christian Theune | The renewal itself does depend on the order being current/successful, though as hexa noted. | 06:48:05 |
| Christian Theune | 
Download Screenshot 2025-07-04 at 10.12.07.png | 08:12:46 |
| Christian Theune | Alright. Some discussion with leona and max lead to this ^^ | 08:12:49 |
| Christian Theune | I'll put that into code and see how that works. | 08:13:00 |
| Christian Theune | something that doesn't fit in there is that preliminary self signed certificates can be turned off currently. | 08:22:52 |
| Christian Theune | this setup would always introduce (temporary) self-signed certificates. (currently if you turn off preliminary self signed certificates and lets encrypt doesn't work for some reason, we don't start the consumer service at all because the configs will be invalid) | 08:23:50 |
| Christian Theune | i would consider it an acceptable shift in detail wrt to reduced overall complexity. | 08:24:40 |
| Christian Theune | * i would consider it an acceptable tradeoff with the benefit of reduced complexity. | 08:25:11 |
| Christian Theune | otoh if someone runs dns-01 everywhere and doesn't ever need to show self signed certificates and wants to reduce the risk of exposing users to those ... | 08:26:12 |
| Christian Theune | hmpf. | 08:26:15 |
| Christian Theune | however, if you have a more complex service that acts as a "nexus" then maybe only one of multiple vhosts uses dns-01, others might be using http-01 or tls-01 and need the self-signed certificates anyway and then you get unpredictable behaviour. | 08:29:06 |
| Christian Theune | in that sense, the tradeoff seems even more beneficial: reduced complexity and more predictable behaviour. | 08:29:26 |
| Christian Theune | we originally added it as an option when creating self-signed certificates wasn't supported yet, so ... i guess it was created as an option ... because we can? | 08:30:28 |
| Christian Theune | i'll turn into coding mode now and see how this works out. | 08:30:38 |
|  leona joined the room. | 08:31:15 |
| Christian Theune | 👋 | 08:31:20 |
|  ma27 joined the room. | 08:31:24 |
 emily | I say this every time our ACME module fails to scale for someone, but ACME issuance really wants to be a proper service rather than scripted out of systemd bits and you might want to consider trying something like Caddy for an issuance daemon :) | 09:42:56 |
| emily | (not that I don't welcome improvements especially if they simplify the code) | 09:43:10 |
