Support read-only root #9812
Support read-only root #9812
Conversation
When using a root filesystem that's mounted read-only, certbot fails handle the lock for its configuration in */etc/letsencrypt*. The easiest solution is to place a symlink at */etc/letsencrypt/.certbot.lock* that points to a writeable location like */var/lib/letsencrypt/etc-letsencrypt-lock*. But even this requires some tweaking of the code: At release time, we have to check for a symlink and don't remove it but the target. To get a writeable filesystem during operation the filesystem must be remounted rw. This could be done with a pre-hook, but they are run to late. Hence, the run of the pre-hook is scheduled earlier to allow mounting the filesystem read-write before any access takes place.
There was a problem hiding this comment.
Hello @jo-so !
The pre-hook and post-hook are designed to be run along the lifecycle of a certificate issuance/renewal, not for the lifecycle of the certbot client itself. Your change modifies significantly the scope of the hook here, since it would then be run also for actions like install or enhance. Given the nature of a hook, which is to inject an arbitrary logic, I am concerned by the adverse effects of this change.
Given that your action is basically valid for any certbot action, why not add it on your side at the top level, by calling it along with certbot itself, for instance /my/pre-hook.sh && certbot renew && /my/post-hook.sh in a CRON line?
|
Hi @adferrand, thank you for your reply. I don't want to remount the filesystem every time certbot gets started; in the best case every quarter instead of every day. It should happen as few as possible and only certbot knows when it's needed. And running the hook for each action that requires write access, is what is needed. |
|
Hello @jo-so, yes I understand your point of view from the perspective of But the way you change things here has wider changes and impacts several commands like |
|
Would it be possible to get a new hook or change the behaviour of the hook
with a setting, i.e. only those who want a the early action for read-only
root e.g. can enable the modified behaviour of the pre_hook; something like
`run_pre_hook_early = true`?
|
When using a root filesystem that's mounted read-only, certbot fails handle the lock for its configuration in /etc/letsencrypt. The easiest solution is to place a symlink at /etc/letsencrypt/.certbot.lock that points to a writeable location like /var/lib/letsencrypt/etc-letsencrypt-lock.
But even this requires some tweaking of the code: At release time, we have to check for a symlink and don't remove it but the target.
To get a writeable filesystem during operation the filesystem must be remounted rw. This could be done with a pre-hook, but they are run to late. Hence, the run of the pre-hook is scheduled earlier to allow mounting the filesystem read-write before any access takes place.
Pull Request Checklist
mastersection ofcertbot/CHANGELOG.mdto include a description of the change being made.AUTHORS.mdif you like.