Archimedes

Und genau daran lag es! In "Froxlor/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php" wird geprüft ob es einen Eintrag in der Datenbank gibt. Wenn es einen gibt und dort "validtodate" leer ist wird ein Issue ausgelöst Oder wenn es keinen Eintrag in der Datenbank gibt UND keine Zertifikatsdatei existiert die noch gültig ist. private static function issueFroxlorVhost() { if (Settings::Get('system.le_froxlor_enabled') == '1') { // let's encrypt is enabled, now check whether we have a certificate $froxlor_ssl_settings_stmt = Database::prepare(" SELECT * FROM `" . TABLE_PANEL_DOMAIN_SSL_SETTINGS . "` WHERE `domainid` = '0' "); $froxlor_ssl = Database::pexecute_first($froxlor_ssl_settings_stmt); // also check for possible existing certificate if (($froxlor_ssl && empty($froxlor_ssl['validtodate'])) || (!$froxlor_ssl && !self::checkFsFilesAreNewer(Settings::Get('system.hostname'), date('Y-m-d H:i:s'))) ) { return true; } } return false; } Um dies zu umgehen, müsste man beim löschen der Zertifikate auch die Dateien in /root/.acme.sh/ löschen. Dies wäre aber auch riskant, wenn die Zertifikate auch für andere Dienste verwendet werden. Leichter wäre vermutlich einfach die Prüfung checkFsFilesAreNewer hier raus zu nehmen, oder übersehe ich da etwas? also quasi so: if ( !$froxlor_ssl || ($froxlor_ssl && empty($froxlor_ssl['validtodate'])) ) { return true; } Vielen Dank auf jeden Fall

Auch bei mir funktioniert das auf 6 anderen VMs 🙂 Nur auf dieser einen zickts und so ganz sehe ich noch nicht warum. in der Tabelle domain_ssl_settings gibts auf jeden Fall keinen Eintrag mehr für die domainid 0 - nur für die Kundendomains wo auch alles läuft (hab auch gerade einen neue angelegt zum Testen und hier wird problemlos ein Zertifikat erstellt) Tabelle panel_settings zeigt le_froxlor_enabled = 1 und le_froxlor_redirect = 0 danke aber für deine Hilfe

Ich habe Let's Encrypt für den Froxlor vhost deaktiviert und dann den Cronjob laufen lassen. Die Zertifikate sind auch weg ( auch "/root/.acme.sh/acme.sh --list" bestätigt dies). Unter Froxlor>Ressourcen>SSL Zertifikate wird natürlich auch kein Zertifikat mehr gelistet. Nach dem wieder aktivieren habe ich nun zweimal den Cronjob laufen lassen (froxlor-cli froxlor:cron -f -d) - und nicht deutet darauf hin, dass versucht wird ein neues Zertifikat zu holen.

Hallo, wisst ihr evtl. noch was damals dann das Problem war? Ich habe aktuell exakt das selbe Thema. Lg

Servus die Runde, ich habe dies nun seit ein paar Tagen so am laufen und es funktioniert sehr gut soweit. Schöner wäre noch logrotation über den froxlor-cronjob Traffic zu triggern, aber das muss ich mir erst genauer anschauen ob das elegant werden kann. Lg

Jup das hat funktioniert. Die Daten welche aktuell im Log stehen wurden verarbeitet. Auch die Trafficberechnung im Panel bestätigt das. Vielen Dank für deine Hilfe.

So richtig mitteilsam wurde es deshalb auch nicht: Checking froxlor file permissions...OK Running "traffic" job (debug) (not forking) [notice] Checking system's last guid

ok das macht Sinn - danke für den Hinweis. Was ich aber immer noch nicht versteht ist warum der Aufruf von froxlor-cli froxlor:cron 'traffic' nicht dazu führt, dass die Einträge im Log (welche vorhanden sind) jetzt verarbeitet werden. Das Froxlorpanel zeigt zwar an, dass der Cronjob gelaufen ist aber domain.tld/goaccess sagt noch immer "Zuletzt aktualisiert: 2023-12-14 00:00:02 +0100" - dies stimmt mit der Dateizeit/Datum der .db Dateien überein. Kann ich dies irgendwie gezielt triggern?

Ich dokumentierte hier einfach ein bisschen mit was ich inzwischen so festgestellt habe, in der Hoffnung dass es mal jemanden weiter hilft. logrotate startet meist um genau 0:00 Die Konfiguration dazu läuft über einen systemd timer welcher in der Datei /lib/systemd/system/logrotate.timer liegt und nach /etc/systemd/system/timer.wants.target/logrotate.timer verlinkt ist. Die Datei sieht so aus: [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=daily AccuracySec=1h Persistent=true [Install] WantedBy=timers.target AccuracySec=1h finde ich hier normalerweise auch ausreichend genau..... wenn man die Logfiles aber automatisiert verarbeitet kann das durchaus doof sein. Froxlor Cronjob "froxlor:cron 'traffic'" läuft laut logs ebenfalls um 0:00 - meist jedoch ein paar Sekunden nach Logrotate: Dez 12 00:00:00 vm002 systemd[1]: Starting logrotate.service - Rotate log files... Dez 12 00:00:00 vm002 systemd[1]: logrotate.service: Deactivated successfully. Dez 12 00:00:00 vm002 systemd[1]: Finished logrotate.service - Rotate log files. Dez 12 00:00:01 vm002 CRON[146340]: (root) CMD (/usr/bin/nice -n 5 /usr/bin/php -q /var/www/html/froxlor/bin/froxlor-cli froxlor:cron 'traffic' -q 1> /dev/null) Dez 13 00:00:01 vm002 systemd[1]: Starting logrotate.service - Rotate log files... Dez 13 00:00:01 vm002 CRON[196280]: (root) CMD (/usr/bin/nice -n 5 /usr/bin/php -q /var/www/html/froxlor/bin/froxlor-cli froxlor:cron 'traffic' -q 1> /dev/null) Dez 13 00:00:02 vm002 systemd[1]: logrotate.service: Deactivated successfully. Dez 13 00:00:02 vm002 systemd[1]: Finished logrotate.service - Rotate log files. Es sieht also genau so aus wie d00p beschreiben hat. Im Moment wo der Froxlorcronjob goaccess anwirft wurde gerade/werden gerade die Logfiles rotiert und sind somit wohl leer. Nun habe ich den Timer mal auf folgendes geändert: [Unit] Description=Daily rotation of log files Documentation=man:logrotate(8) man:logrotate.conf(5) [Timer] OnCalendar=*-*-* 00:05:00 AccuracySec=1s Persistent=true [Install] WantedBy=timers.target Damit startet logrotate immer um 00:05 und damit nachdem der Froxlor Cronjob lief. Ich berichte auf jedenfall wieder 😉

danke für die schnelle Antwort. logrotate klingt wirklich wahrscheinlich. Ich schau mir mal eben an was da genau um welche Uhrzeit läuft. mich erstaunt aber auch noch etwas, dass die goaccess .db Dateien nicht neu erzeugt werden wenn ich die Cronjobs von Froxlor manuell starte.

Hallo Die Runde, ich habe soeben festgestellt, dass in in goaccess nur Logs von drei Tagen finde. In meinem Fall vom 3.12 - 5.12: Die Cronjobs habe ich heute mal manuell gestartet: Irgendwie fehlt mir gerade total der Ansatz zur Fehlersuche, da auch die Cronjobs im Debugmodus keinen Fehler liefern. Auch die .db files /var/customers/webs/username/goaccess/ sind alle vom 14. Dez 00:00. Auch unter admin_traffic.php wird nur der Traffic von Anfang Dezember angezeigt. Wenn Irgendwer einen kleinen Denkansatz hätte, würde ich mich sehr freuen. Lg Simon Systeminfos: Froxlorversion: 2.1.1 OS: Debian 12 PHP Version: 8.2.13 goaccess version: 1.7