df8oe

Ich habe eben von 10.21 auf 10.22 upgegraded. Danach ist kein Aufruf der Startseite von Froxlor mehr möglich. Es erscheint nur noch die Meldung Fatal error: Uncaught Error: Class 'voku\helper\AntiXSS' not found in /var/www/froxlor/lib/init.php:94 Stack trace: #0 /var/www/froxlor_10.22/index.php(20): require() #1 {main} thrown in /var/www/froxlor/lib/init.php on line 94 Ich mache meine Updates mit den Dateien von GitHub: 1) Alle Dateien kopieren 2) lib/userdata.inc.php rüberkopieren 3) gesamten Ordner Vendor rüberkopieren (in dem Ordner von Github ist fast alles outdatet, einiges unused) 4) Ordner .well-known rüberkopieren Nach dem Aufruf kommt nur obige Meldung. Mein Fehler? Bug? Hatte ich vorher noch nie...

Solange ich Debian hatte habe ich die fertigen .deb-Pakete genommen - das war für mich "das Release". Seit ich Arch habe nehme ich git - weil es sowieso auf dem Server läuft und ständig aktuell ist. Der Rest von Arch ist ja auch "bleeding edge" - da warte ich nicht auf die Releases.

Wir reden einfach eine andere Sprache. Ich will niemanden ärgern Und Froxlor ist echt Klasse. Dann ändere ich es bei mir nicht sondern mache einfach ein rebase. EDIT: Ich nutze ja sowieso die Dateien von Github und nicht die eines Releases - weil ich meine Server mit Arch betreibe. DF8OE

Fazit: Wenn bei jemandem dieses Problem auftritt kann man sich mit einem Workaround helfen. Vermutlich sind bei denen, die das Problem haben, im IP/PORT-SSL-Vhost die beiden Pfade "Pfad zum Zertifikat" und "Pfad zum SSL-Private-Key" nicht leer, sondern haben eine Pfad/Dateikombination, die auf dem Server nicht existiert. Löscht einfach die dort vorhandenen Einträge und lasst die Felder leer. Dann erkennt Froxlor beim Neuanlegen einer Domain mit den Defaulteinstellungen ("aktiviere SSL" gesetzt, "Letsencrypt" nicht gesetzt) dass es kein gültiges Zertifikat gibt und erstellt einen leeren SSL-Vhost für die neue Domain (wie es sein sollte). Nicht existente Zertifikatsdateien im IP/PORT-SSL-Vhost werden nicht als "fehlend" erkannt - im Gegensatz zu leeren Pfadangaben, dort funktioniert die Erkennung! Es gibt nur eine logische Erklärung für das bei mir beobachtete Fehlverhalten (Erstellung eines SSL-Vhosts mit nicht existentem Zertifikat): Die Überprüfung ob eine Zertifikatsdatei existiert wird nicht durchgeführt. Für mich ist das Ganze gelöst - ihr könnt selbst entscheiden ob ihr mit diesem Hinweis irgendwas anfangt oder nicht. Das, wozu ich mich als Nutzer verpflichtet fühle (Fehlfunktionen nicht einfach schulterzuckend hinzunnehmen, sondern das Fehlverhalten zu benennen, zu beschreiben, wie man es reproduziert, wo vermutlich die verursachende Stelle im Code liegt), habe ich hiermit getan! EDIT: korrigierte Zeile 416 aus lib/Froxlor/Cron/Http/Apache.php: if ($row_ipsandports['ssl_cert_file'] == '' || ! file_exists($row_ipsandports['ssl_cert_file'])){ Ich wünsche allen einen entpannten Restsonntag DF8OE

Nein, hat er nicht. Und Flames sind auch unnütze Zeitverschwendung - genauso wie Diskussionen. Ich werde mich nachher drum kümmern und hier entweder die Lösung in Form geänderter Einstellungen oder in Form eines Patches veröffentlichen. Vielleicht macht das dann das Problem transparenter. Das Ziel ist die Behebung einer Fehlfunktion, die für weniger versierte Nutzer zu einem Problem führen kann, das sie nicht ohne weiteres wieder beheben können.

Ich denke ich verschwende meine Zeit nicht Logs zu verändern oder hier das Fehlverhalten zu posten, sondern den Fehler selbst zu fixen und in mein Froxlor-Github einzufügen. Es existiert auch ein Pull-Request für meine Implementierung von DKIM, der aber schwebt, weil der Part für die Erstellung der DKIM-Serverkonfigurationen fehlt (und ich keine Zeit habe ihn zu erstellen). Aktuell gibt es aber noch keine Merge-Konflikte Alles, was zum Verstehen der Fehlfunktion nötig ist, steht hier bereits. Und dass eine IP/Port-Kombination für den Vhost von Froxlor verwendet wird kann ich weder nachvollziehen noch wäre das ein für mich erwünschtes Verhalten. Ich muss nicht gleich jeden Hacker der auf meine IP zugreift auf Froxlor stupsen. Und ein Aufruf einer IP mittels ssl ist nur sinnvoll und möglich, wenn man ein IP Zertifikat hat. Sorry wenn ich euch aufgehalten habe und danke für die Hilfe. Leider ist es mir nicht gelungen, das Problem deutlich zu machen. Die geposteten Stellen, an denen die Zertifikate geprüft werden, helfen aber bei einer schnellen Fehlerbehebung defintiv weiter!

Froxlor läuft nicht über IP (weil ich kein teures IP-Zertifikat habe), sondern auf einer Subdomain. Und die hat ein Letsencrypt-Zertifikat. Das manuelle Anonymisieren frisst jede Menge zeit (ich schrieb es bereits). Ich kann also die IP/Port-Kombination für SSL nicht löschen, wenn irgend eine Domain via SSL läuft. So gut wie niemand dürfte ein IP-Zertifikat haben. Wie lange es sowas überhaupt noch gibt ist auch fraglich. Aber es werden sehr viele Leute auch ohne existentes IP-Zertifikat Domains mit SSL genutzt werden. Man *MUSS* also eine IP/Port-Kombination für SSL anlegen - auch, wenn man kein IP-Zertifikat besitzt. Kein Problem, weil man ja den IP-Port-ssl-Vhost nicht erstellen lassen muss. Denn einfach "irgendein anderes" oder ein selbsterstelltes Zertifikat dort einzutragen ist kontraproduktiv. Damit würde ja jede neu erstellte Domain "versorgt" werden, bei der Letsencrypt nicht angewählt ist! Folglich dürfte bei den meisten dort ein ungeeignetes Zertifikat oder eben ein ungültiger Pfad drinstehen. Beim Anlegen einer neuen Domain sollte nicht geprüft werden ob beim IP/Port-ssl-Vhost ein Pfad eingetragen ist, es sollte beim Anlegen der Domain geprüft werden ob die im IP/Port-ssl-Vhost eingetragenen Zertifikatsdateien auch existieren. Das jetzt vorliegende Verhalten erzeugt Arbeit und beim ein oder anderen der weniger Kenntnisse vom System hat auch größere Probleme, wie er den Webserver wieder zum Laufen bekommt nach dem Anlegen einer neuen Domain mit den Default-Einstellungen.

Die ganzen Einstellungen kann ich nicht unverändert posten weil da Kundendaten drin sind (DSGVO). Und die ganzen Stellen unkenntlich zu machen ist eine Heidenarbeit. Aber wir nähern uns. Es ist auf allen drei Servern auch eine IP/Port-Kombination für Port 443 in Froxlor eingetragen - aber es soll kein Vhost dafür erstellt werden. Dementsprechend stört es auch nicht, dass die dort eingetragene Pfad/Zertifikat-Kombination nicht existiert. Alle drei Server laufen seit Äonen - bis Mai mit Debian, seit Mai mit Arch Linux. Das Problem, dass ssl-Vhosts erstellt werden ohne existente Zertifikate ist erst vor ein paar Tagen zum ersten Mal aufgetaucht. Ich habe das letzte Mal vor ca. 1 Jahr eine neue Domain eingetragen - das verlief ohne Probleme. Das ist leider zu lange her und ich weiß nicht mehr ob da - kein automatischer Haken bei "aktiviere ssl" gesetzt war - der Haken zwar gesetzt war aber mangels Zertifikat kein Vhost erstellt wird. Es wird wohl nicht explizit geprüft ob die Zertifikatsdateien existieren - es wird geprüft ob ein Pfad in den IP/Port Einstellungen eingetragen ist und wenn ja, wird das benutzt - auch, wenn die Dateien nicht existieren. Kann man denn die IP/Port Kombination für SSL gefahrlos löschen ohne dass der Rest auseinanderfliegt? Ein Vhost wird dafür sowieso nicht erstellt. Vielleicht löst das das Problem.

Bei Arch Linux gibt es keine Ordner oder Dateien die mit"apache*" benannt sind. Die haben alle ein "http*" im Namen - ganz sicher. Es gibt weder einen Unterordner "apache" noch irgendwo Zertifikatsdateien die mit "apache" benannt sind.

Hier die beiden relevanten Zeilen aus der erstellten ssl-Vhost-conf: SSLCertificateFile /etc/ssl/apache/apache.crt SSLCertificateKeyFile /etc/ssl/apache/apache.key Ich habe es vermieden die gesamte conf zu posten da das Unkenntlichmachen der 30 für dieses Problem absolut irrelevanten Stellen sinnlos Arbeit erzeugt. Der Knackpunkt wurde klar beschrieben: Es ist default "SSL aktivieren" ausgewählt. Es gibt kein systemweites oder IP-basiertes Zertifikat. Letsencrypt ist nicht angehakt. Dann erstellt Froxlor einen ssl-Vhost mit den oben aufgeführten Zeilen und startet den Webserver neu. Der Start des Webservers schlägt fehl weil die Zertifikatsdateien (oben aufgeführt) nicht exitieren - ein Zugriff via Web ist ab sofort nicht mehr möglich. Einzige Lösung ist den ssl-Vhost via Konsole zu löschen, dann den Webserver neu zu starten (dann startet er natürlich), dann via Froxlor die betreffende Domain zu bearbeiten und entweder den Haken bei "aktiviere SSL" rauszunehen ODER einen Haken bei "Letsencrypt" zu setzen.

Leider wird der Vhost bei drei unterschiedlichen Server nicht deaktiviert. Es wird ein Vhost angelegt dessen Zertifikat in /etc/ssl/apache/apache.crt / /etc/ssl/apache/apache.key liegen soll. Da liegt aber keines (es gibt noch nicht mal den Ordner /etc/ssl/apache) und das wars dann mit dem Webserver...

Das Neuanlegen einer Domain führt jetzt oft dazu, dass der Webserver nicht mehr startet. Wie kommt das zu Stande? Beim Neuanlegen einer Domain wird, wenn in den Webserver-Grundeinstellungen SSL enabled ist, in der Sektion "Webserver SSL-Einstellungen" bei "Aktiviere Nutzung von SSL:" generell ein Haken gesetzt. Bei "SSL Zertifikat erstellen (Let's Encrypt):" ist dagegen kein Haken gesetzt. Das führt dazu, dass beim nächsten Cron-Lauf die Konfiguration so geschrieben wird, dass von einem lokal vorhandenen Zertifikat ausgegangen wird. Das ist aber nicht vorhanden - und damit startet der Webserver nicht mehr. Dieses Verhalten war nicht immer so - erst seit einiger Zeit laufen mehr und mehr Nutzer in diese "Falle". Wer ein wenig Kenntnisse von der Konsole hat und einen ssh-Zugriff, kann sich leicht selbst helfen. Das hat aber nicht jeder... Lösungsvorschlag: - SSL wird nicht generell aktiviert. Ich glaube das war bis vor ??? auch der Default oder: Wenn SSL aktiviert wurde wird überprüft, ob der Haken bei Letsencrypt auch gesetzt ist ODER ein Zertifikat existiert. Wenn nicht, wird die Aktivierung von SSL nicht ausgeführt und eine Warnung angezeigt LG DF8OE

Bingo - solved.

Nein, funktioniert immer noch nicht. Ich habe vor der Entscheidung ein var_dump($renew_domains) eingefügt und dort wird mir nach wie vor die komplette Liste aller Domains incl. der Keys ausgegeben - auch nach dem Patch. Könnte hier dran liegen: private static function renewDomains($check = false) damit ist $check immer false und das Ergebnis immer so wie vorher - oder nicht?

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...

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.

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...

Ein Downgrade auf die 0.10.18 behebt die Fehlfunktion.

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.

# 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.

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.

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?

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.

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?