https://bz.apache.org/bugzilla/show_bug.cgi?id=66526

--- Comment #2 from Christoph Anton Mitterer <[email protected]> ---
Hey.

Would it really open so much?
I'd have expected that there are only rather few (use-)cases where one wants to
independently reload parts of the configuration:

- Apache's main configuration (and all that it includes)... which is anyway
already supported by the graceful restart.

- TLS cert/key data

- TLS CRL data (not sure what it actually does there right now... in principle
it would only make sense if it is already (automatically) reloaded every now
and then (either via fnotify or periodically), as e.g. CRLs will get constantly
updated.

- external files like user/group files for mod_authn_file and friends (not sure
if these are read once at startup or every time a decision needs to be made).



Why do you think it would impact the performance? It would only happen when a
TLS cert/key reload is manually triggered, and there it should probably faster
(and perhaps even be less intrusive) than the general graceful restart.


> The immediate need for a certificate change reload

Well that's not the problem here IMO. 
The problem is that it will happen quite often[0] and typically automatically
(via cronjob or systemd timer) AND - and this is the point - that then (when
doing it via the graceful restart or via the restart) undesired configuration
changes may get accidentally active.

Consider that I'm just about to edit apache config... I add some new portions
that are exported e.g. via <Directory>... I save the config, but haven't added
any access control yet (which doesn't matter as I do not restart the server
yet)... but, by coincidence, certbot comes in the way and reloads/restarts.

If there was a mechanism to only reload the certs/keys, such scenarios could be
prevented.


[0] What does e.g. LetsEncrypt use? 90 days? And doesn't it try to renew 30
days ahead of expiration? Thus in effect, every 60 days.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to