[gelöst] webserver konfiguration wird auf zwei Servern alle 5 Minuten erneuert

[df8oe]

Hallo in die Runde,

ich habe Froxlor 0.10.19 auf zwei Servern am Laufen. Bei beiden wird seit einiger Zeit - ich kann leider nicht genau sagen seit wann - alle 5 Minuten die Webserverkonfiguration neu geschrieben. Bei einem ist zusätzlich durch eigenen Fehler der Inhalt aller Domain-Ordner in /root/.acme.sh/name-der-domain/ gelöscht worden. Bei diesem Server erhalte ich bei einem force debug die folgende Ausgabe:

[error] Could not find file 'hullewulle.at.cer' in '/root/.acme.sh/hullewulle.at/'
[error] Could not find file 'ca.cer' in '/root/.acme.sh/hullewulle.at/'
[error] Could not find file 'fullchain.cer' in '/root/.acme.sh/hullewulle.at/'
[error] Could not find file 'hullewulle.at.csr' in '/root/.acme.sh/hullewulle.at/'
[error] Could not get Let's Encrypt certificate for hullewulle.at:

...und das für alle Domains.

Wie kann ich acme.sh dazu bringen, dass es einfach für alle Domains neue Zertifikate abholt? Damit sollte dann doch wieder alles im grünen Bereich sein - oder nicht? Ich habe es schon mit

acme.sh -f -r -d hullewulle.at

versucht, aber das ergibt nur ein 

[Sa 25. Jul 09:55:46 CEST 2020] Renew: 'hullewulle.at'
[Sa 25. Jul 09:55:46 CEST 2020] 'hullewulle.at' is not a issued domain, skip.

Damit dürfte aber das Problem dass alle 5 Minuten die Webserverkonfiguration neu geschrieben wird nicht gelöst sein. Ein force debug bringt bei diesem zweiten Server keine Auffälligkeit. Wo kann ich nachschauen was den Neubau der Webserverkonfiguration triggert?

[d00p]

Ganz einfach, froxlor triggered das weil Zertifikats Erneuerungen anstehen bei denen es offenbar Fehler gibt. Lösche in froxlor alle let's encrypt Zertifikate und auch via acme.sh --remove -d [Domain]

 

 

[df8oe]

acme.sh --remove -d hullewulle.at
[Sa 25. Jul 10:04:29 CEST 2020] hullewulle.at is not a issued domain, skip.

...das ist das Resultat auf dem Server wo der Inhalt der Domain-Ordner in /root/.acme.sh/ gelöscht wurde. Wenn ich keine Sicherungen der Apache-Zertifikate erstellt hätte gäbe es jetzt ein größeres Problem  acme.sh weigert sich bei leeren Ordnern neue Zertifikate zu holen.

 

Bei dem anderen Server kann ich das erfolgreich machen, alle Zertifikate werden dann neu geholt und auch von Froxlor wieder dem Apachen untergeschoben. Alle Domains laufen wieder mit SSL, was bleibt ist dass alle 5 Minuten die Webserverkonfiguration neu geschrieben wird - nach wie vor.

[d00p]

14 minutes ago, df8oe said:

acme.sh weigert sich bei leeren Ordnern neue Zertifikate zu holen.

dann lösch die ganzen ordner wenn sie doch leer sind

14 minutes ago, df8oe said:

Alle Domains laufen wieder mit SSL, was bleibt ist dass alle 5 Minuten die Webserverkonfiguration neu geschrieben wird - nach wie vor.

na froxlor macht das nicht aus spaß, nur wenn sich was geändert hat. außer du hast irgendwo einen cronjob der manuell --force ausführt.

[df8oe]

Quote

dann lösch die ganzen ordner wenn sie doch leer sind

Habe ich auch schon gemacht - keine Änderung.

Wie gesagt - das sind ZWEI Probleme:

1) acme kann auf Server 1 mit keiner Domain etwas machen (remove, renew etc.) - es kommt jedesmal "...is not a issued domain, skip". Woher weiß denn acme welche Domains es handlen soll? Kann ich acme sozusagen "from the scratch" starten? Es kann durchaus sein dass auch andere Ordner von acme nicht mehr so sind wie sie sein sollten auf Server 1.

2) es wird alle 5 Minuten die Webserverkonfig neu geschrieben. Ob das auch bei dem Server passieren würde wo Problem 1) da ist wenn das gelöst wurde - kann ich (noch) nicht sagen

Zusatzinfo:

Rufe ich den Froxlor-Mastercronjob auf Server 2 manuell auf, dann findet zum nächsten 5-minütigen Cron-Lauf KEIN Neuschreiben der Webserverkonfiguration statt - erst zum übernächsten wieder. Dann aber wieder alle 5 Minuten. Es läuft definitiv nur der eine Froxlor-Cronjob - kein zweiter mit force.

[df8oe]

Wo schaut Froxlor nach ob sich was geändert hat?

In einer Tabelle? Wenn ja: In welcher Tabelle und wie heißt die Variable in der das gespeichert wird?

Oder wird irgendwo eine Datei erzeugt? Wenn ja: Wo, und wie heißt die?

[d00p]

Nicht so hektisch und hastig alles auf einmal. Ganz ruhig  und überlegen. Keiner kennt dein System oder weiss wie die domain einstellungen sind und und und...

Jetzt noch mal von vorne

1) Stoppe den cron dienst, damit er uns nicht dazwischen kommt

2) Log dich in froxlor ein (admin), navigiere zu "SSL-Zertifikate" und entferne dort alle betreffenden (let's encrypt) Zertifikate

3) gehe zu /root/.acme.sh/ und lösche dort:

• a) via acme.sh --remove -d [domain] alle domains
• b) entferne alle nicht mehr benötigten Domain-Ordner aus /root/.acme.sh/

4) Prüfe ob bei den Domains eine SSL-IP hinterlegt ist und ob Let's Encrypt aktiviert ist

5) Führe nun manuell den cronjob mit folgendem Befehl aus: php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug

6) Reaktivere den cron dienst

Die Ausgabe des Crons bitte hier posten.

[df8oe]

Hat sich überschnitten - ich habe jetzt eine greifbare Fehlermeldung auf dem Rechner wo die Ordner in /root/.acme.sh leer sind:

 

[warning] Skipping Let's Encrypt generation for www.hullewulle.at due to no system known IP address via DNS check

Allerdings ergibt ein Ping von einem externen Rechner und auch ein ping auf dem Server selbst auf hullewulle.at und www.hullewulle.at die korrekte IP-Adresse - das verstehe ich nicht. Du hast Recht - Hektik ist nicht zielführend. Wobei dummerweise auf dem Rechner auf dem die Ordner leer sind und ich die oben genannte Fehlermeldung bekomme die meisten Zertifikate heute um 13:55 ablaufen 🤐

Und deswegen möchte ich mit diesem Rechner anfangen.

[d00p]

Also, sofern es keine Platzhalter-Domain war, ich bekomm keinen DNS eintrag für www.hullewulle.at oder hullewulle.at

[df8oe]

Das ist nur ein Platzhalter...

Bin noch weiter. Aus Gründen die ich nicht nachvollziehen kann ist bei Froxlor in die IP/Port-Konfiguration die INTERNE IP des Rechners gerutscht. Da stand bislang immer die externe drin - kein Wunder dass das nicht mit den Zertifikaten klappt. Leider kann ich die Adresse nicht ändern - ich soll die "System-IP-Adresse ändern". Nur wo? Muss ich erst eine neue anlegen, dann die System-IP darauf hin ändern und dan kann ich die alte löschen?

[d00p]

wenn du 1:1 tauschen willst schau dir das script froxlor/install/scripts/switch-serverip.php an

[df8oe]

Danke. Der Tausch der IP-Adressen hat funktioniert. Auf dem Server sind jetzt auch ALLE Zertifikate erneuert worden - erfolgreich. Da waren ja auch nur 15 Domains drauf

Jetzt ist auf beiden Servern der gleiche Stand:

Alle Zertifikate länger als 1 Monat gültig, aber auf beiden Servern wird nach wie vor alle 5 Minuten die Webserver-Konfigurationsdatei neu erstellt.

Daher hier von dem Server, wo alle Zertifikate neu sind die Ausgabe von

 php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug:

(IP-Adressen customer und Domains sind gefaked)

[information] TasksCron: Searching for tasks to do
[information] Running Let's Encrypt cronjob prior to regenerating webserver config files
[information] Checking for LetsEncrypt client upgrades before renewing certificates:
[Sa 25. Jul 13:29:53 CEST 2020] Already uptodate!
[Sa 25. Jul 13:29:53 CEST 2020] Upgrade success!
[Sa 25. Jul 13:29:53 CEST 2020] Installing cron job
7 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
[information] Updated Let's Encrypt certificate for wergaerrgg
[information] Updated Let's Encrypt certificate for qerrgadfgvadverq
[information] Updated Let's Encrypt certificate for sdfEFf
[information] Updated Let's Encrypt certificate for dvfaesfF
[information] Updated Let's Encrypt certificate for FfeFEEf
[information] Updated Let's Encrypt certificate for EFffeSdfsdf
[information] Updated Let's Encrypt certificate for DfFEfeFE
[information] Updated Let's Encrypt certificate for ADGADGAERGGA
[information] Updated Let's Encrypt certificate for hgsrsbfdb
[information] Updated Let's Encrypt certificate for adfgaerrgaergar
[information] Updated Let's Encrypt certificate for dfaergvbdafvbdaf
[information] Updated Let's Encrypt certificate for egeargga
[information] Updated Let's Encrypt certificate for dfvagaegae
[information] Updated Let's Encrypt certificate for dffvgaegvaegv
[information] Let's Encrypt certificates have been updated
[information] apache::createIpPort: creating ip/port settings for  10.0.10.4:80
[debug] 10.0.10.4:80 :: inserted vhostcontainer
[information] apache::createIpPort: creating ip/port settings for  10.0.10.4:443
[information] apache::createIpPort: creating ip/port settings for  95.202.134.210:80
[debug] 195.202.142.210:80 :: inserted vhostcontainer
[information] apache::createIpPort: creating ip/port settings for  95.202.134.210:443
[information] apache::createVirtualHosts: creating vhost container for domain 3, customer Psfbgbgfsbsf
[information] apache::createVirtualHosts: creating vhost container for domain 32, customer bfgbsfbsfb
[information] apache::createVirtualHosts: creating vhost container for domain 12, customer sfgbsfgbsbsfbsf
[information] apache::createVirtualHosts: creating vhost container for domain 14, customer Psgbsfbsfbsfb
[information] apache::createVirtualHosts: creating vhost container for domain 10, customer Pasfbsfbsfbsf
[information] apache::createVirtualHosts: creating vhost container for domain 15, customer erqerfgerqegg
[information] apache::createVirtualHosts: creating vhost container for domain 9, customer reqrgqerrgrre
[information] apache::createVirtualHosts: creating vhost container for domain 21, customer qerrgqergqerge
[information] apache::createVirtualHosts: creating vhost container for domain 7, customer nenenen
[information] apache::createVirtualHosts: creating vhost container for domain 33, customer zhwhwhzwz
[information] apache::createVirtualHosts: creating vhost container for domain 30, customer qergeqgqrgqqer
[information] apache::createVirtualHosts: creating vhost container for domain 25, customer qegqegdfgvag
[information] apache::createVirtualHosts: creating vhost container for domain 2, customer dafveqrgqerg
[information] apache::createVirtualHosts: creating vhost container for domain 8, customer adffveqrefadfv
[information] apache::createVirtualHosts: creating vhost container for domain 17, customer eafgefasdfvadsf
[information] apache::writeConfigs: rebuilding /etc/httpd/conf/sites-enabled/
[information] apache::writeConfigs: rebuilding /etc/httpd/conf/htpasswd/
[information] apache::writeConfigs: rebuilding /etc/httpd/conf/sites-enabled/
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php73-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php72-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: fpm config directory "/etc/php71/php-fpm.d/" is empty. Creating dummy.
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php71-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php70-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: fpm config directory "/etc/php56/php-fpm.d/" is empty. Creating dummy.
[information] Froxlor\Cron\Http\ApacheFcgi::reload: running systemctl restart php56-fpm
[information] Froxlor\Cron\Http\ApacheFcgi::reload: reloading Froxlor\Cron\Http\ApacheFcgi
[notice] Creating passwd file
[notice] Writing 11 entries to passwd file
[notice] Succesfully wrote passwd file
[notice] Creating group file
[notice] Writing 6 entries to group file
[notice] Succesfully wrote group file
[notice] Creating shadow file
[notice] Writing 11 entries to shadow file
[notice] Succesfully wrote shadow file
[notice] Checking system's last guid

Das war um 13:31 Uhr,

Um 13:35 wurde dann wieder eine neue Config geschrieben und das geht jetzt endlos weiter so.

[d00p]

2 minutes ago, df8oe said:

aber auf beiden Servern wird nach wie vor alle 5 Minuten die Webserver-Konfigurationsdatei neu erstellt.

kann dir leider so ausm stand nicht sagen woher das kommt. Neu erstellung gibt es eigentlich nur wenn Änderungen vorgenommen wurden, sonst macht es ja keinen sinn die configs neu zu schreiben.

Wie sieht denn deine /etc/cron.d/froxlor Datei aus?

[df8oe]

# automatically generated cron-configuration by froxlor
# do not manually edit this file as it will be re-generated periodically.
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
#
*/5 * * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --tasks 1> /dev/null
0 0 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --traffic 1> /dev/null
5 0 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --usage_report 1> /dev/null
0 */6 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --mailboxsize 1> /dev/null
*/5 * * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt 1> /dev/null
10 0 * * * root /usr/bin/nice -n 5 /usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --backup 1> /dev/null

 

...genau um hier zu debuggen warum das an zwei Servern passiert wollte ich ja wissen, was Froxlor da abprüft um zu entscheiden, ob eine neue Config geschrieben werden soll oder nicht. Ich finde es merkwürdig dass das bei zwei völlig unabhängigen Servern jetzt ist. Das war nicht immer so! Die Sache mit den falschen IP-Adressen und den resultierenden Fehlern von letsencrypt hatten nichts mit Froxlor zu tun. Da hat vermutlich der Inhaber des Servers im Admin-Panel etwas gelöscht, was er nicht verstanden hat. Aber der zweite Server ist mein eigener - und da kann nur ich was ändern. Und ich habe nichts geändert. Außer dass ich vor kurzem auf beiden Server ein Froxlor-Update auf die 0.10.19 vorgenommen habe.

Übrigens führt der Lauf von

php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug

dazu dass im Admin-Panel bis zum nächsten Cron-Lauf bei "ausstehende Cron-Aufgaben" genau solange "Zur Zeit gibt es keine ausstehenden Aufgaben für Froxlor" steht, bis der nächste Cron-Lauf stattfindet. Bei dem werden keine neuen Configs erstellt - aber nach dem Lauf ist die Zeitbombe wieder scharf. Nach den Cronlauf steht bei "ausstehende Cron-Aufgaben" jetzt "Neuerstellung der Webserver-Konfiguration" und das erfolgt dann auch endlos.

[d00p]

5 minutes ago, df8oe said:

...genau um hier zu debuggen warum das an zwei Servern passiert wollte ich ja wissen,

da passiert nix an zwei stellen, der --letsencrypt cron ist nur aus historischen gründen noch da drin, weil es ein eigenständiger call ist zum PRÜFEN ob sich was geändert hat (und wenn, einen task zum neuerstellen der configs einfügt)

7 minutes ago, df8oe said:

Übrigens führt der Lauf von

php /var/www/froxlor/scripts/froxlor_master_cronjob.php --force --debug

dazu dass im Admin-Panel bis zum nächsten Cron-Lauf bei "ausstehende Cron-Aufgaben" genau solange "Zur Zeit gibt es keine ausstehenden Aufgaben für Froxlor" steht

und das wundert dich wieso? Ist doch klar das es danach keine aufgaben gibt, wenn du die Abarbeitung dieser forcierst!

8 minutes ago, df8oe said:

Nach den Cronlauf steht bei "ausstehende Cron-Aufgaben" jetzt "Neuerstellung der Webserver-Konfiguration" und das erfolgt dann auch endlos.

dann würde ich tippen das es doch irgendein zertifikat ist, was laut froxlor aktualisiert oder generiert werden soll und das fehlschlägt. Davon sagt aber der --force cron nix, also kann es ja doch irgendwie nich sein...ich kenn wie gesagt deinen server nicht und was da wo ggfls eingestellt ist. Normal ist es jedenfalls nicht

[df8oe]

War auch bislang nicht - bei keinem der beiden Server.

 

Jetzt wird es noch kurioser. Ich habe die Ausgabe im Admin-Panel mal öfter refresht. Da stand beim letzten Mal drin, dass es keine ausstehenden Aufgaben gibt und trotzdem ist der Zeitstempel der sites-enabled Dateien ein eindeutiger Beweis dafür, dass sie exakt zur Cronlaufzeit ausgetauscht wurden.

 

EDIT:

Sollte im Admin-Panel unter "Erstellen von Konfigurationsdateien:" der letzte Zeitstempel drin sein dann wird der beim Cron-Lauf nicht erneuert.

 

EDITEDIT:

Ob die Webserverkonfiguration neu geschrieben werden muss ist vom Luftdruck in Shanghai abhängig. Mal steht 10 Minuten lang drin, dass keine ausstehenden Cron-Aufgaben anstehen (es werden aber trotzdem alle 5 Minuten die Webserverconfigs neu geschrieben) - mal steht drin dass die Konfiguation neu geschrieben werden muss - es hat aber keiner was im Admin-Panel gemacht.

 

EDITEDITEDIT:

Kann ich gefahrlos ein Downgrade auf einem der Server auf die 0.10.18 machen? Ich würde gerne testen ob das was mit dem Update zu tun hat. Ich will aber die Datenbank nicht schrotten.

[d00p]

11 minutes ago, d00p said:

ich kenn wie gesagt deinen server nicht und was da wo ggfls eingestellt ist. Normal ist es jedenfalls nicht

 

[df8oe]

Quote

Kann ich gefahrlos ein Downgrade auf einem der Server auf die 0.10.18 machen? Ich würde gerne testen ob das was mit dem Update zu tun hat. Ich will aber die Datenbank nicht schrotten.

 

[d00p]

Dafür gibt es kein prozedere, die updates haben ihren Sinn. Die Änderungen zwischen 0.10.18 und 0.10.19 siehst du hier: https://github.com/Froxlor/Froxlor/compare/0.10.18...0.10.19

[df8oe]

Ein Downgrade auf die 0.10.18 behebt die Fehlfunktion.

[d00p]

da muss was bei dir komisch sein, denn eigentlich ist es andersrum und die neuere version behebt fehler in der alten. Hauptsächlich von 0.10.18 auf 0.10.19 bzgl acme.sh (siehe https://github.com/Froxlor/Froxlor/compare/0.10.18...0.10.19#diff-90b9b5d026e90e56e291aee17a56d76dL499) - hier im spezielles das synchronisieren der Zertifikate mit der Froxlor-Datenbank. Ohne weitere Details deines systems und was wo wie kann ich dazu halt nix sagen - wenn für dich die 0.10.18 läuft dann ist es halt so

[df8oe]

Systeme:

Arch Linux, Apache, php-fpm, postfix, dovecot, amavisd, proftpt. Nichts Subtropisches.

Wenn Du an einem Debugging Interesse haben solltest sag was Du noch für Infos brauchst, was ich machen soll, welche Logs Du brauchst.

 

Es ist definitiv mit der 18 in Ordnung und mit der 19 schreibt er alle 5 Minuten eine neue Webserverconfig. Ich denke, da schlummert ein Bug drin, der vielleicht nicht in jeder Konstellation auftaucht. Oder ich bin der erste dem augefallen ist dass da ein Bug ist.

Nach meiner Erfahrung (und ich habe auch schon Erfahrung mit solchen Fehlern in meinen Softwareprojekten!) ist "...dann ist es halt so" keine optimale Lösung. Das kann eine gefährliche Zeitbombe werden bei der es später sehr viel schwieriger ist die Ursache zu finden als sofort...

[d00p]

Naja, ein downgrade ist genauso keine Lösung, du wirst definitiv Probleme beim renew der Zertifikate haben. 

Ohne ssh Zugang zum Testen kann ich da nix zu sagen. Und dich da jetzt durchzuführen und jedes Mal 5 min auf Antwort warten ohne zu wissen ob du exakt das gemacht hast was ich gemacht hätte - sorry, aber das übersteigt meine Zeit einfach und führt meiner Erfahrung nach kaum zum Ziel.

[df8oe]

Einen ssh-Zugang kann ich Dir aus DSGVO-Gründen bei keinem der Server geben. Aber ich kann forschen - auch ohne weitere Tipps.

Vielleicht fällt Dir als der "Schöpfer von Froxlor" mit dem entsprechenden Überblick ja mit irgendeinem meiner Hinweise was ein.

starte ich

/usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --tasks

aus der Konsole so ist im Admin-Panel immer zu finden, dass keine Cron-Aufgaben anstehen.

Warte ich ab bis der Cronjob das tut dann steht nach Lauf des Cronjobs im Admin Panel, dass die Webserverconfig neu geschrieben werden muss.

Ich kann das auch beschleunigen, wenn ich

/usr/bin/php -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --letsencrypt

auf der Konsole starte. Dann wird sofort im Panel engezeigt, dass die Webserverconfig neu geschrieben werden muss.

[d00p]

11 minutes ago, df8oe said:

Einen ssh-Zugang kann ich Dir aus DSGVO-Gründen bei keinem der Server geben.

vollkommener quatsch, aber gut, wenn du meinst. ich kanns nur anbieten. Ist ja nicht so als hätte ich eine firma mit sitz in deutschland und würde DSGVO konform arbeiten.

Und sorry, wenn du jetzt nur blind "rumprobierst" ist das noch weniger zielführend. Das führt so zu nix. Ich persönlich habe dieses Problem auf einigen Servern nicht, daher kann ich nur davon ausgehen dass bei dir was hängen muss. Was das ist kann ich ohne debugging nicht sagen - und nein, wild cronjobs ausführen und hoffen das einem das ergebnis ins gesicht springt ist kein debugging.

[df8oe]

Das Problem entsteht in

/var/www/froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php
 

und zwar durch diese Zuweisung in Zeile 65:

$renew_domains = self::renewDomains();

Da kommt hier true raus und deswegen sollen die Configs neu geschrieben werden. Wenn ich $renew_domains eine Zeile danach auf false setze wird kein false-renew der Config mehr gemacht.

 

EDIT:

Da kommt nicht true raus - da werden alle Domains mit letsencrypt als Array zurückgegeben. Und damit ist die nachfolgende Bedingung immer erfüllt - es sei denn, man hat keine Domains mit letsencrypt. Oder sehe ich da was falsch? Eigentlich kann das auf keiner denkbaren Installation laufen wie gedacht...