☰

Warum kann Certbot keine Post-Hook-Skripte ausführen?

tag-icon • tag-icon lets-encrypt certbot
Warum kann Certbot keine Post-Hook-Skripte ausführen?

Dies ist mein erster Versuch, Let’s Encrypt-Zertifikate über Certbot zu erneuern. Nachdem ich das Certbot-Benutzerhandbuch sorgfältig gelesen hatte, erstellte ich zwei Post-Hook-Skripte wie diese:

root@pelargir:~# ls -l /etc/letsencrypt/renewal-hooks/post
total 8
-rwxr-xr-x 1 root root 697 Aug 29 16:35 10-setup-courier.sh
-rwxr-xr-x 1 root root 377 Aug 29 16:32 20-restart-services.sh

Anschließend habe ich den Erneuerungsprozess manuell über die Befehlszeile ausgeführt (also nicht über Cron). Die Zertifikate wurden erfolgreich erneuert, die Ausführung der oben genannten Post-Hook-Skripte ist jedoch fehlgeschlagen. Hier ist die entsprechende Ausgabe:

[...]
Running post-hook command: /etc/letsencrypt/renewal-hooks/post/10-setup-courier.sh
Hook command "/etc/letsencrypt/renewal-hooks/post/10-setup-courier.sh" returned error code 127
Error output from 10-setup-courier.sh:
/bin/sh: /etc/letsencrypt/renewal-hooks/post/10-setup-courier.sh: not found

Running post-hook command: /etc/letsencrypt/renewal-hooks/post/20-restart-services.sh
Hook command "/etc/letsencrypt/renewal-hooks/post/20-restart-services.sh" returned error code 127
Error output from 20-restart-services.sh:
/bin/sh: /etc/letsencrypt/renewal-hooks/post/20-restart-services.sh: not found
[...]

Ich habe keine Ahnung, warum das passiert. Ich habe es noch einmal überprüft:

  • Die Skriptdateien existieren
  • Die Skriptdateien sind ausführbar
  • Ich kann die Skripte manuell ausführen (mit den Umgebungsvariablen RENEWED_DOMAINSund RENEWED_LINEAGEgesetzt und exportiert) und sie erledigen ihre Arbeit wie erwartet

Eine weitere Sache, die ich wahrscheinlich erwähnen sollte, ist, dass ich Certbot in einem Docker-Image ausführe, da ich mit Wildcard-Zertifikaten arbeite. Mein DNS-Anbieter ist Cloudflare. Hier ist die Befehlszeile, die ich verwende, um den Erneuerungsprozess zu starten:

docker run -it --rm --name certbot \
           -v "/etc/letsencrypt:/etc/letsencrypt" \
           -v "/var/lib/letsencrypt:/var/lib/letsencrypt" \
           certbot/dns-cloudflare
           renew

Das Docker-Image führt Certbot Version 0.25.0 aus. Das System ist Debian 9 (Stretch), kürzlich aktualisiert von Debian 8 (Jessie).

Irgendwelche Hinweise, was das Problem sein könnte?

BEARBEITEN: Wie gewünscht, hier der Inhalt der beiden Dateien, leicht bearbeitet, um meine Domäne durch „example.com“ zu ersetzen:

root@pelargir:~# cat /etc/letsencrypt/renewal-hooks/post/10-setup-courier.sh 
#!/bin/bash

# Exit immediately if a command exits with non-zero status
set -e

case $RENEWED_DOMAINS in
  # Courier runs only under a example.com subdomain
  example.com)

    # We don't care about file permissions because we know that the
    # filesystem folder where we generate the file is not generally
    # accessible
    cat "$RENEWED_LINEAGE/fullchain.pem" "$RENEWED_LINEAGE/privkey.pem" >"$RENEWED_LINEAGE/courier.cert-and-key.unsecure"
    ;;
esac

root@pelargir:~# cat /etc/letsencrypt/renewal-hooks/post/20-restart-services.sh
#!/bin/bash

# Exit immediately if a command exits with non-zero status
set -e

case $RENEWED_DOMAINS in
  # Courier and Exim run only under a example.com subdomain
  *example.com*)
    systemctl restart courier-imap.service
    systemctl restart exim4.service
    systemctl restart apache2.service
    ;;

  # Apache has vhosts for all domains. Unfortunately the daemon is
  # restarted several times if several certificates are renewed.
  *)
    systemctl restart apache2.service
    ;;
esac

Antwort1

Ihre Shell-Skripte verwenden ein Shebang #!/bin/bash, was bedeutet, dass sie mit diesem Programm ausgeführt werden sollen, aber der Docker-Container, in dem sie ausgeführt werden, enthält kein Bash. Aus diesem Grund wird beim Aufruf dieser offensichtlich vorhandenen Skripte /bin/shder verwirrende not foundFehler gemeldet. Es sind nicht die Skripte, die nicht gefunden werden, sondern der Bash-Interpreter, mit dem Sie sie ausführen wollten.

Sie können das Problem lösen, indem Sie den Skriptinterpreter ändern /bin/shund alle Bash-Ismen aus den Skripten entfernen (wahrscheinlich schnell und einfach) oder indem Sie Bash im Container installieren (wahrscheinlich chaotisch).

verwandte Informationen