Saving debug log to /var/log/letsencrypt/letsencrypt.log
manual-auth-hook command /manual-acme-auth.py exists, but is not executable.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
My web server is (include version): Manual cert
The operating system my web server runs on is (include version): Manual cert
My hosting provider, if applicable, is: GoDaddy
I can login to a root shell on my machine (yes or no, or I don't know): yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): cPanel
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.19.0
This manual auth script previously worked, but now produces the above output. The script has a line for #!/usr/bin/env python3. On the host, it has executable permissions. Any ideas what has changed?
The one thing that stands out to me is ${pwd}, which is looking for an environment variable of that name. Perhaps this command is part of a script that creates that variable, but I'm not sure. Double check that you didn't mean $(pwd) or even ${PWD} which is a POSIX shell built-in.
One thing you can try to diagnose this (to see whether it's a Certbot problem or an environment problem) is to invoke the script directly in the Docker environment, e.g.
Although I agree it's rather confusing, as the manual speaks about "custom shell scripts" at least once while at other places it just mentions "commands"..
In any case, I don't see a reason why a Python script including a proper shebang wouldn't work.
It's just a misunderstanding. Script examples are historically done as .sh because that is more consistent across environments - Python/Ruby/Perl/etc have not classically been default installations on linux distributions and must be explicitly added. Some distros now load them on, but the barebones ones usually do not.
There are lots of Certbot plugins/projects/etc that use Python scripts on the hooks.
I often prefer to use Python when I can, but shell scripts are often easier for these scripts since they have a streamlined syntax for accessing the environment variables.
Edit: You do need a shebang line on the script to invoke the correct interpreter/executable for the file.
Thanks for the quick replies. They are meant to be the same file, using CERTBOT_AUTH_OUTPUT existing or not to handle cleaning up the old validation file.
At least on my host, the script has +x set.
-rwxr-xr-x 1 user user 1.8K Sep 14 14:05 manual-acme-auth.py*
The script has the shebang line set as #!/usr/bin/env python3. I have also tried #!/usr/bin/python3 to no success.
The usage of ${pwd} might be somehwhat wrong, my own bash scripting isn't great. But since it appears that certbot finds the file, I believe it is working? Unless its a Docker thing, creating an empty directory or file or something. I'll have look at that more.
Well, I feel a bit foolish. If I change ${pwd} to $(pwd), everything appears to work as it should. I'm not sure when I made that change, but it was obviously after I last renewed this set of certificates.
Ah, this is just an unfortunate aspect of how Docker mounts volumes.
When you do:
-v "${pwd}/blah:/blah"
The ${pwd}/blah just evaluates to /blah. Docker sees that /blah does not exist on the host, so it creates that directory on the host and then mounts it into the container.
So the path exists, it's just a directory rather than an executable file.
If you look at the root directory on your server, you will probably see an empty directory named /manual-acme-auth.py/.
