fix(lego): Run lego.service to fix inconsistent ownership of cert dir

[jadyndev]

This fixes a bug that only occurs on initial deployments when lego_certificate_store_group is set to something other than lego. As the handler "Run lego" is not run with this in mind, all initially generated certificates are created with the permissions which leads to failures.
This is a temporary issue that gets resolved after lego.timer triggers the service for the first time, fixing the permissions.

This is a somewhat dirty but easy fix to this problem as it ensures the service is run after changes.

[jdreichmann]

Seems ok - changing the ownership in the handlers' command looks like more work. For the record, that means that the certificates are initially created with {{ lego_user }}:{{ lego_user }} by the "Run lego" handler (when the handlers are flushed) and then the permissions are rewritten to {{ lego_user }}:{{ lego_certificate_store_group }} when lego.service is run by either the systemd timers' activation or the "Enable lego.service" task from ansible?

[jcgruenhage]

Please add a comment above why we do this? It's not clear at the moment why this line is here if you only look at the code.

Alternatively, use ansible.builtin.file to fix the permissions instead, to make it more obvious what is happening here and why.

[jadyndev]

@jdreichmann Could you incorporate this in #179?

[jdreichmann]

@jcgruenhage see here: #172 (review) - that's the reason the unit is started here.

[jdreichmann]

Alternatively, use ansible.builtin.file to fix the permissions instead, to make it more obvious what is happening here and why.

If one can trigger a handler after another handler when the first handler is already run? otherwise, one could modify the "Run Lego" handler to spawn a shell executing multiple commands. I don't think using ansible.builtin.file is the correct approach here tbh, as that only affects the time between a certificate being newly generated (not renewed!) and the first activation of the systemd timer for the renewal.

[jcgruenhage]

I know the reason, I'm just asking for that reason to be included in the ansible code, so that people don't have to go digging when they want to understand why we start the renewal unit right after we've gotten the certificates in the first place.

With regard to handler-after-handler: Why does it need to be a handler? We're flushing the handlers right before that, so we don't need to have it in a handler. We can just ensure the permissions are right after we've flushed the handlers, which will run after the run lego handler in every case.

Either way, I'm fine with both approaches ultimately, just if the approach without ansible.builtin.file is used, then I'd want a comment explaining why this happens.

[jadyndev]

Seems ok - changing the ownership in the handlers' command looks like more work. For the record, that means that the certificates are initially created with {{ lego_user }}:{{ lego_user }} by the "Run lego" handler (when the handlers are flushed) and then the permissions are rewritten to {{ lego_user }}:{{ lego_certificate_store_group }} when lego.service is run by either the systemd timers' activation or the "Enable lego.service" task from ansible?

Yes exactly.