Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certbot renewal no env variables for hooks #9141

Open
t0mtaylor opened this issue Dec 13, 2021 · 12 comments
Open

Certbot renewal no env variables for hooks #9141

t0mtaylor opened this issue Dec 13, 2021 · 12 comments

Comments

@t0mtaylor
Copy link

Certbot renewal no env variables for hooks

when setting the post and deploy hook, the environment variables are not set by cerbot

$RENEWED_DOMAINS
$RENEWED_LINEAGE

I have tried printenv in the hook script and the variables dont exist

@alexzorin
Copy link
Collaborator

  1. --post-hook doesn't set these environment variables. This is intentional, because a post-hook may be covering multiple certificates:

    If multiple renewed certificates have identical post-hooks, only one will be run.

  2. --deploy-hook always sets these environment variables. If you have found a situation where this isn't a case, it would be a bug.

@harridu
Copy link

harridu commented Jan 11, 2022

RENEWED_DOMAINS could provide a space-separated list (as indicated by the name).

About case 1:
Not sure about the pre-hooks, but apparently all post-hooks are run, even if only one cert got renewed. This can be pretty expensive. How could this be avoided in the post-hook script without information provided by certbot? It would be easy to ignore these variables in the script.

@alexzorin
Copy link
Collaborator

alexzorin commented Jan 11, 2022

apparently all post-hooks are run, even if only one cert got renewed. This can be pretty expensive. How could this be avoided in the post-hook script without information provided by certbot

Yes, if you put pre/post hook scripts into the /etc/letsencrypt/renewal-hooks/{pre,post}/ directories, they will all be run indiscriminately (but only once each, regardless of how many certificates got renewed). They are global.

If you want to a pre/post hook which is specific only to one certificate, issuing the certificate with the --pre-hook and --post-hook CLI flags will achieve that. Certbot will remember, at the next renewal, to run those hooks, for that certificate only. The setting will be remembered in the /etc/letsencrypt/renewal/*.conf file.

@harridu
Copy link

harridu commented Jan 11, 2022

You mean I have to put the pre- and post-hook scripts into another directory to make sure that they are run only if "their" certificate got updated? Can this still be a common directory for all certificates?

@alexzorin
Copy link
Collaborator

I think it's helpful to think of the pre/ and post/ directories as global. For example, if all your certificate renewals require stopping and starting nginx, then it's a way to do that in a single place.

Otherwise, anything certificate-specific should go outside of those directories and be set per-certificate, yes.

@harridu
Copy link

harridu commented Jan 11, 2022

I wonder where this could be found in the man page?

@alexzorin
Copy link
Collaborator

A lot of this information is buried in https://eff-certbot.readthedocs.io/en/stable/using.html#renewing-certificates, but it could be improved, yes.

@lordspace
Copy link

lordspace commented Apr 17, 2022

I am testing the --deploy-hook command line argument with --dry-run and --force-renewal and my php script is NOT receiving the environment variables that it's supposed to. I have tried to access them via getenv() function and also using $_ENV and $_SERVER arrays too.

Do you have an idea why?

@alexzorin
Copy link
Collaborator

--dry-run does not invoke --deploy-hook.

@Pakbon

This comment was marked as outdated.

@github-actions
Copy link

github-actions bot commented Jul 1, 2023

We've made a lot of changes to Certbot since this issue was opened. If you still have this issue with an up-to-date version of Certbot, can you please add a comment letting us know? This helps us to better see what issues are still affecting our users. If there is no activity in the next 30 days, this issue will be automatically closed.

@lordspace
Copy link

Cool. Will test this in the next few weeks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants