Debian Config and Script Paths

[jason-klein]

Thank you for this great script! We placed our script in /usr/local/sbin/certbot-route53.sh and we use the Debian certbot package's default config location of /etc/letsencrypt/.

We had to replace $PWD with $SCRIPT and $CONFIG variables that held these paths for these reasons:

1. Certbot would fail to locate hook script if we ran script with absolute path (e.g. cd /root && /usr/local/sbin/certbot-route53.sh ...)
2. Certbot was not writing the correct hook script paths to the renewal conf files.
3. Certbot would only store config in default location if our PWD was /etc when we executed the script (e.g. cd /etc/ && /usr/local/sbin/certbot-route53.sh ...).

Other users might find it helpful to have similar variables near top of script, even if the default values for CONFIG and SCRIPT remain $PWD/letsencrypt and $PWD/$0 for now.

CONFIG=/etc/letsencrypt
SCRIPT=/usr/local/sbin/certbot-route53.sh

  certbot certonly \
    --non-interactive \
    --manual \
    --manual-auth-hook $SCRIPT \
    --manual-cleanup-hook $SCRIPT \
    --preferred-challenge dns \
    --config-dir $CONFIG \
    --work-dir $CONFIG \
    --logs-dir $CONFIG \
    $@

Thanks again for publishing this!

[jed]

@jason-klein, would you mind submitting a PR with this fix?

[joshribakoff]

Hey,

The script worked flawless out of the box for me. I just downloaded & ran it out of an arbitrary path. I assumed the reason it used $PWD as opposed to hard coding /etc/letsencrypt was some problem with clobbering existing files.

A PR with the above fix would now break my setup, since I didn't happen to place it at /etc/letsencrypt. In fact I assumed this was specifically not supported. The readme could certainly use some clarification on paths, and I think @jed as the author you should weigh in here or explain how this was intended to work.

It seems like all the issues raised by @jason-klein are a symptom of not changing the working directory prior to running the script, and I'm not sure why that's undesired. I agree its not optimal, but hard coding paths is even less optimal.

Awesome script by the way!

[jed]

@joshribakoff, this is basically what i'm thinking, though my experience in the domain is pretty shallow. not a fan of hardcoding and would like this to work on environments that don't have write permissions within /etc (lambda, et al). perhaps a better idea would be a note in the README?

[joshribakoff]

Yep the way it works now is nearly perfect. Using a flag would be better than pwd but breaks backwards compatibility so a note in the readme is the pragmatic solution

On Mon, Aug 21, 2017 at 8:14 PM Jed Schmidt ***@***.***> wrote: @joshribakoff <https://github.com/joshribakoff>, this is basically what i'm thinking, though my experience in the domain is pretty shallow. not a fan of hardcoding and would like this to work on environments that don't have write permissions within /etc (lambda, et al). perhaps a better idea would be a note in the README? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD1cOooSDghx5x0aWiJ6BbvCMDC_15Ygks5sakeggaJpZM4Ot0ku> .

-- Sent from Gmail Mobile