Let's Encrypt, certbot, Firewall - welche IPs erlauben?

[Raketenwissenschaftler]

Das macht certbot wohl selbst.

Daran möchte ich ernsthafte Zweifel anmelden, weil der certbot überhaupt nicht wissen kann, ob er einen NGINX, Apache, HAProxy oder was auch immer neustarten muss. Mission Impossible.

Ich nutze die GetSSL-Scripte für LetsEncrypt und VirtHosts.

Die Sache ist auf eine ganz einfache Formel herunterzubrechen:

• certbot ist certbot ist certbot, geschrieben in Python3, und bewirkt (bei korrekter Installation) den Reload selbst.
• Andere Programme sind andere Programme sind andere Programme und tun (äh:hoffentlich), was deren Programmierer vorgesehen hat.
• Ich benutze certbot, der Mitleser benutzt nach seiner eigenen Angabe certbot-auto - das ist ein Unix-Shellskript, also was anderes als certbot, Du benutzt „GetSSL-Scripte“.

Warum glaubt ihr also, dass man mir mit Erfahrungen, die für $arrAndereSkripte gelten, von mir mehrfach überprüfte und insoweit qualifizierte Aussagen über die Funktion von certbot widerlegen - oder auch nur in Frage stellen kann?

Da muss man das Restart-Kommando bei der Grundeinrichtung eintragen.
BTW: Am Anfang hatte ich dort den Servicebefehl eingetragen und es hat funktioniert. Irgenwann dann nicht mehr. Jetzt steht jedenfalls der Pfad zur /etd/initd/apache2 drin. Und es funktioniert auch wieder.

Das bedeutet nichts: Erinnerungen (auch meine eigenen) sind, gelinde gesagt, „Scheiße“. Grund dafür ist auch, dass man zeitlich nur punktuell nach „Schroedingers Katze“ sehen und deren Zustand wahrnehmen kann. Die Logfiles in der Kiste indes kennen die Wahrheit mit Zeitstempel.

Es kann z.B.(sic!) ein Typo vorgelegen haben und der Neustart des Apache erfolgte nach dem Update und vor dem Nachschauen, ob die neuen Zertifikate benutzt werden, zufällig, z.B. implizit durch ein Update des Apache oder PHP oder zufällig willkürlich nach einer manuellen Konfigurationsänderung und dem folgendem explizitem Reload oder Restart.

Ich kann auch aus einem weiteren Grund nichts aus Deiner Aussage entnehmen: $Servicebefehl kann etwas wie

• /bin/systemctl restart apache2 oder
• /usr/sbin/service apache2 reload oder
• /usr/sbin/apache2ctl reload oder
• /usr/sbin/apache2 -k graceful

gewesen sein. Die Pfade gelten für $meinModernesSystem und können sich sogar von Linuxdistribution zu Linuxdistribution unterscheiden. Und ich weiß nicht, ob Deine Skripte sich selbst updaten und was die dann aus dem $Servicebefehl machen.

Wie schon dargestellt würde ich unter Linux (Es soll noch BSD-Varianten geben, die systemd ablehnen) nichts neues mehr mit einem Verweis auf /etc/init.d/$irgendwas einrichten. Denn falls da noch ein Skript für die Steuerung eines Dienstes ist, dann ist es nur „noch“ dort und soll dafür sorgen, dass andere Skripte der Firma Asbach noch funktionieren.

Im speziellen Falle ist also der Eintrag von /usr/sbin/apache2ctl (außer vielleicht unter Red-Hat-Derivaten - die kochen da ein eigenes Süppchen und nennen den Apache, wohl ebenso wie manche BSDs, gerne /httpd2{0,1}/i ), stets richtig.

Der Certbot wird doch auch nur per Request involviert. Die lokale Arbeit machen die jeweiligen Scripte. Oder?

[Y] Oder der certbot ist ein (übrigens im Original-Setup per Cronjob gestartetes) Phyton-Skript, welches nach dem Erneuern der Zertifikate den Reload des Apache auslöst. Was soll ich eigentlich noch machen, wenn mir selbst nach dem Hinweis auf den Quelltext, also wieder jeder Vernunft, widersprochen wird?