Jump to content
Froxlor Forum

rseffner

Members
  • Posts

    152
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by rseffner

  1. Ich habe eben einen Key so generiert, wie die rspamd Doku das vorschlägt. Auch dieser Key ist dann durch rspamd angeblich nicht vom richtigen Format. Ich suche dort weiter.
  2. Einstellungen und dort z.B. mal DomainKey-Einstellung Aktiviert ändern und den Speichern-Knopf drücken. Oder alternativ eine beliebige Einstellung innerhalb Einstellungen -> DomainKey-Einstellungen verändern und den Speichern-Knopf drücken.
  3. Ich nutze die durch FROXLOR generierten und im Dateisystem abgelegten DKMI-Schlüsselpaare durch rspamd. Seit der Aktualisierung von FROXLOR 0.10.19 auf 01.10.21 nörgelt rspamd aber wegen dem Format: 2020-10-20 12:41:12 #27314(rspamd_proxy) <5bae90>; proxy; dkim_module_load_key_format: cannot load dkim key /etc/postfix/dkim/dkim258: cannot parse raw private key: error:0D06B08E:asn1 encoding routines:asn1_d2i_read_bio:not enough data Rein visuell sieht so ein Key aber erstmal gut aus. Was ist da passiert?
  4. Egal welche Einstellungen ich im Kontext DKIM ändern will, quittiert mir das FROXLOR ungefähr so: Fehlermeldung Bei dem Speichern des Feldes "dkim_enabled" trat ein Fehler auf oder Fehlermeldung Bei dem Speichern des Feldes "dkim_keylength" trat ein Fehler auf Interessant dabei, die Änderung des Parameters ist aber zumindest in der Datenbank dann trotzdem nachvollziehbar. Wenn das jemand bestätigen kann, wäre das ein Fall für den Bugtracker.
  5. Ich habe je eine Datei die zu Graphen mit 0 und über 0 führen per PM geschickt.
  6. Hallo, bei einigen meiner Kunden fehlen seit unterschiedlich vielen Monaten die HTTP-traffic-Werte im Froxlor-Graph. Manche sind schon 12 Monate auf 0, andere erst seit 3 Monaten (vorher war da noch was). Ich habe zuerst die Threads hier gelesen, die irgendwie damit zu tun haben und kann daher schon etwas Vorarbeit liefern. Der cron-Job läuft einmal täglich. Auch mit --debug --no-fork liefert der keine Fehler. Es entsteht dabei unter anderem eine TXT-Datei im awstats-Verzeichnis mit Werten in den "bandwith"-Spalten. Auch ein Browseraufruf von awstats zeugt für die 14 Tage im September Werte - der Froxlor-Graph bleibt aber brav bei Null. Daraus schließe ich jetzt, dass Froxlor die TXT-Datei irgendwie doch nicht (richtig) verarbeitet. ns1:~# /usr/bin/php7.3 /var/www/webs/its/froxlor1.ANDEREDOAMIN.de/scripts/froxlor_master_cronjob.php --traffic --debug --no-fork [information] PHP compiled with pcntl but pcntl_fork function is not available. Not forking traffic-cron, this may take a long time! [information] Traffic run started... [warning] Cannot get usage for database sucharskisql3. <-- die ist neu angelegt und noch leer, vielleicht deshalb ... [information] http traffic for rabo started... [information] Running awstats_buildstaticpages.pl for domain 'DOMAIN.de' (Output: '/var/www/webs/rabo/awstats/DOMAIN.de/2020-09/') [information] Gathering traffic information from '/var/www/webs/rabo/awstats/DOMAIN.de/awstats092020.DOMAIN.de.txt' [information] ftp traffic for rabo started... [information] mail traffic usage for rabo started... [information] total traffic for rabo started [information] calculating webspace usage for rabo [information] calculating mailspace usage for rabo [information] calculating mysqlspace usage for rabo ... [notice] Checking system's last guid Ich vermute, wir können Dank der Daten in der TXT darauf verzichten die Log-Rotation oder Größe der access-Logs zu hinterfragen. Traffic-Daten kommen ja bis awstats, nur nicht ins Froxlor. Was kann ich noch tun um einer Lösungsfindung dienlich zu sein? Gruß und Dank, Ronny
  7. Das ist doch schonmal eine Aussage, die mich weiterbringt - ich muss außerhalb von Froxlor suchen. Danke.
  8. Wenn doch der tas-cron alle 5 Minuten ohne den letzten Fix lief, dann auch genau 0 Uhr. 0 Uhr laufen auch viele nicht-FROXLOR-Sachen an und erzeugen vielleicht hinreichend Load, so dass der task-cron von FROXLOR nicht so schnell fertig wird, wie sonst. Das zumindest ist meine vage Theorie, die nur dann funktioniert, wenn irgendetwas den apache reloaded, während FROXLOR noch dabei ist die Konfigurationen zu erstellen. Wie eingangs erwähnt habe ich die Scheduler durch und keinen apache2 reload/restart gefunden, der auch auf 0 Uhr matched. Auch auf das logrotate trifft das zu.
  9. Kann das hier Behobene, also dass bei jedem Cron ausgeführte Neuerstellen in Kombination mit Load weil genau 0 Uhr ja mehrere Dinge neben Froxlor laufen, vielleicht zu dem durch mich beobachteten Phänomen (apache reload/restart VOR Fertigstellung der Konfigurationen) führen? Ich konnte leider bisher kein erneutes Vorkommen tracken.
  10. Habe ich das was verpasst und kann es nicht finden oder ist die Formulierung unglücklich? Bisher konnte man mittels FROXLOR aktivieren, dass ein Verzeichnisschutz und Alias für die Logs angelegt wird - einen Menüpunkt zur Ansicht der Logs direkt aus Froxlor sehe ich in 0.10.19 nicht.
  11. Es trifft auch nur einen von 4 Servern und den auch nur hin und wieder. Ich kann aber absolut nichts anderes finden, was auch 0:00 zu einem apache2 reload oder restart führt, kein logrotate oder so. Ich werde jetzt mal 0 Uhr ein ls -la von der/den betroffenen Konfigurationen monitoren - mal sehen ob das Ergebnis eingrenzt.
  12. Mit access und found hast Du natürlich Recht Das da [1] habe ich manuell nachgetragen, weil es eben so oder ähnlich nach meiner Einschätzung auch in der 0.10.19 nicht drin ist. [1] https://github.com/Froxlor/Froxlor/commit/03bc94e69cf1a98dffc4e1001ae5ea0f04eb651e
  13. Hi, ich habe in die 0.10.18 bereits den 8 Tage jungen Patch der lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php eingebaut und glaube da war noch alles normal. Kurz darauf habe ich auf 0.10.19 aktualisiert und den Patch wieder durchgeführt. Seit dem beobachte ich fast täglich, aber nicht immer, dass genau 0 Uhr ein apache restart angefordert wird, der nicht erfolgreich ist, weil die php-fcgi-starter für den Froxlor-VHOST fehlt [Wed Jul 15 00:00:00.874456 2020] [mpm_prefork:notice] [pid 23916] AH00171: Graceful restart requested, doin AH00526: Syntax error on line 13 of /etc/apache2/sites-enabled/10_froxlor_ipandport_78.46.xx.xx.443.conf: Wrapper /var/www/php-fcgi-scripts/froxlor.panel/ns1.xxx-xxx.de/php-fcgi-starter cannot be accessed Wenn dann das Monitoring Alarm schlägt und ich mich - i.d.R. mehr als 5 Minuten später - einlogge, ist der Apache startbar und die Datei vorhanden. Ich vermute hier kommen sich Konfigurationsneuerstellung und Restart ins Gehege. Ich habe neben cron keinen weiteren Scheduler und weder in /var/spool/cron* noch /etc/cron* irgend etwas gefunden, was auch um 0 Uhr (ja, diese */5 Einträge habe ich auch berücksichtigt) am Apache rummacht außer den Froxlor-Tasks. # 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/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --tasks 1> /dev/null 2 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --traffic 1> /dev/null 0 */6 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --mailboxsize 1> /dev/null */5 * * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --letsencrypt 1> /dev/null 5 0 * * * root /usr/bin/nice -n 5 /usr/bin/php7.3 -q /var/www/webs/its/froxlor1.xxx-xxx.de/scripts/froxlor_master_cronjob.php --backup 1> /dev/null Was trifft sich hier unglücklich und kann dann wie behoben werden? Gruß, Ronny
  14. Ich bin gerade über einen Zone gestolpert, die sich vom bind nicht laden lassen wollte. Darin gab es "* CNAME ...." und "* A ...". Das "* A ..." resultierte aus der Domaineinstellung Alias = "Wildcard" und das "* CNAME ..." hat wohl der Anwender einst gesetzt (warum dann keiner gemerkt hat, das gar nichts mehr geht?). Ich habe das reproduziert und man kann das auch jetzt noch so einrichten. Damit wird klar, dass der Eintrag hier eher in den Bugtracker sollte - mein Tag war aber schon so lang und ermüdende, ich hoffe man verzeiht mir.
  15. 2) Das erklärt leider nicht, warum mir heute mehrere Dutzend abgelaufene Zertifikate um die Ohren geflogen sind, die auch ein --force nicht erneuerte ;-( Da klemmt es also woanders ... 3) Dann ist der Halbautomatismus, den ich parallel hier vorgestellt habe, eher mit Vorsicht zu genießen und für welche, die nicht klickend viele Domains "upgraden" möchten
  16. Wenn man das Ergebnis (siehe /tmp/le) folgender quick-and-dirty-Behandlung zurück nach /root/.acme.sh kopiert, im FROXLOR EC-384 aktiviert und "/root/.acme.sh/acme.sh --cron --home /root/.acme.sh --force" gefolgt von "/usr/bin/php7.3 -q /var/www/froxlor/scripts/froxlor_master_cronjob.php --force" aufruft, erhält man das Upgrade bisheriger Zertifikate hin zu ECC Es werden dabei alle Nicht-ECC Zertifikatsinfos nach /tmp/le kopiert und dort "4069" durch "ec-384" ersetzt. Jetzt der manuelle Kopierjob. Dann wird LE mittels acme.sh gezwungen die Zertifikate zu erneuern (ich hatte ja die Zeitstempel nicht angefasst) und zuletzt kümmert sich der Froxlor-Job um das Kopieren nach /etc/apache2/ssl und eintragen in die VHosts (oder eben analog für nginx). ns1:~# cat 2ecc #!/bin/bash mkdir -p /tmp/le cd /root/.acme.sh find ./ -mindepth 1 -maxdepth 1 -type d -not -name "*_ecc" -not -name "ca" -not -name "deploy" -not -name "dnsapi" -not -name "notify" | while read LINE; do if [ ! -d "$LINE"_ecc ]; then cp -r "$LINE" /tmp/le/"$LINE"_ecc sed -i "s/Le_Keylength='4096'/Le_Keylength='ec-384'/g" /tmp/le/"$LINE"_ecc/"$LINE".conf fi done
  17. Hi, ich habe irgendwann in den Einstellungen unter SSL mal eine ECC-Schlüssellänge gewählt und wohl gehofft, beim nächsten renew werden die Zertifikate "umgestellt". Bei Anlage neuer Domains mit wurde auch brav ECC berücksichtigt. Nun sind offenbar eine Menge nich-ECC Zertifikate abgelaufen und nicht verlängert worden. Rufe ich den cron-task --force --debug mit aktiviertem ECC auf so erhalte ich zu allen Domains, die schon vor ECC ein LE-Zertifikat hatten "[warning] ECC certificates activated but found only non-ecc file" und das Zertifikat in /etc/apache2/ssl beliebt ungeändert. Erst wenn ich ECC deaktiviere hat er endlich den renew gemacht. Entweder fehlt hier der fallback (hast du kein ECC such ein Zertifikat ohne) für so eine gewachsene Mischinstallation oder das ist so gewollt und ich muss jetzt überall LE deaktivieren, ECC aktivieren udn den Domains LE wieder aktivieren. Eine elegantere Methode zum Upgrade von noch-ECC auf ECC habe ich auch in acme.sh nicht gefunden. Übersehe ich etwas? Gruß
  18. Danke fürs unterstützen. Ich bin leider schon wieder darauf reingefallen, dass ein "Reseller" längst einen anderen A-record für www. eingetragen hat und vergas, das LE zu deaktivieren. Das mit 3 Domains und die Vierte, mit der ich die Gegenprobe machen wollte hatte längst den Provider gewechselt, ohne dass mir das der Kunde sagte. Ich freue mich riesig auf den Fix mit der DNS-Gegenprobe.
  19. Die Domain war vor den ganzen hier diskutierten Anpassungen am FROXLOR dort bereits in Verwaltung und mit LE versehen. Es geht also um einen RENEW. Im konkreten Beispiel rein IPv4. Ich habe in FROXLOR schon LE deaktiviert, den Zertifikatsordner aus /root/.acme gelöscht, Configs neu geschrieben und LE wieder für die Domain aktiviert sowie Configs neu geschrieben. Das konnte dann kein CRT beziehen, hat nur .conf, .csr und .key angelegt.
  20. Ich muss mich hier leider wieder melden, weil ich noch die hier genannte AcmeSh.php einsetze. Inzwischen häufen sich Meldungen wie: [Do 30. Apr 15:34:31 CEST 2020] DOMAIN.TLD:Verify error:The key authorization file from the server did not match this challenge [Do 30. Apr 15:34:32 CEST 2020] Please add '--debug' or '--log' to check more details. [Do 30. Apr 15:34:32 CEST 2020] See: https://github.com/acmesh-official/acme.sh/wiki/How-to-debug-acme.sh
  21. Auf dem 2. Server wo die Diskrepanz zwischen Expiration im Dateisystem und der DB war, ist jetzt "Einigkeit" ohne, dass sich an dem Zertifikat im Dateisystem etwas geändert hätte. Du hast es also offenbar geschafft, dass sich FROXLOR an den Daten im Dateisystem bedient und damit die DB füttert.
  22. Für offenbar jede Domain kommt PHP Warning: Use of undefined constant LOG_WARN - assumed 'LOG_WARN' (this will throw an Error in a future version of PHP) in /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 461 Und bei einer der betroffenen Domains siehts so aus PHP Warning: Use of undefined constant LOG_WARN - assumed 'LOG_WARN' (this will throw an Error in a future version of PHP) in /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php on line 461 [unknown] ECC certificates activated but found only non-ecc file [information] Updated Let's Encrypt certificate for a.mein****.de
  23. DAS ist, was ich gemacht habe, bevor das mit den Fehlern losging. Wie sieht jetzt Deine Handlungsempfehlung aus?
  24. root@ns1 ~/.acme.sh/a.mein****.de # ls -la /root/.acme.sh/a.mein****.de/ insgesamt 36 drwxr-xr-x 2 root root 4096 Jan 27 12:05 . drwx------ 73 root root 4096 Apr 4 13:45 .. -rw-r--r-- 1 root root 2301 Mär 27 12:15 a.mein****.de.cer -rw-r--r-- 1 root root 652 Mär 27 12:15 a.mein****.de.conf -rw-r--r-- 1 root root 1716 Mär 27 12:15 a.mein****.de.csr -rw-r--r-- 1 root root 242 Mär 27 12:15 a.mein****.de.csr.conf -rw-r--r-- 1 root root 3247 Mär 27 12:15 a.mein****.de.key -rw-r--r-- 1 root root 1648 Mär 27 12:15 ca.cer -rw-r--r-- 1 root root 3949 Mär 27 12:15 fullchain.cer root@ns1 ~/.acme.sh/a.mein****.de # md5sum /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php 59e6855a72207abc330d52db41368489 /var/www/webs/its/froxlor.DOMAIN.de/lib/Froxlor/Cron/Http/LetsEncrypt/AcmeSh.php root@ns1 ~/.acme.sh/a.mein****.de # Ich verstehe, das solch remotes debugging extrem anstrengend ist - drum gebe ich mir ja alle Mühe, Dir keinen Mist zu liefern.
  25. Ein zweiter Server mit FROXLOR 0.10.15 ns1:~# /usr/bin/php7.3 -q /var/www/webs/its/froxlor.DOMAIN.de/scripts/froxlor_master_cronjob.php --tasks [error] Could not get Let's Encrypt certificate for a.mein****.de: [Sa 4. Apr 13:51:20 CEST 2020] Renew: 'a.mein****.de' [Sa 4. Apr 13:51:20 CEST 2020] Skip, Next renewal time is: Mi 3. Jun 11:45:17 UTC 2020 [Sa 4. Apr 13:51:20 CEST 2020] Add '--force' to force to renew. Und nun die ausgetauschte Datei und der cronjob mit --force --debug ... [error] Could not get Let's Encrypt certificate for sola****.de: [error] Could not get Let's Encrypt certificate for 2019.seff****.de: [error] Could not get Let's Encrypt certificate for a.mein****.de: [error] Could not get Let's Encrypt certificate for prof****.at: ... Im Filesystem Renew auf 26.05. in der DB expiration auf 27.06 - das kann ja passen - ich glaube renew beginnt einen Monat vor Ablauf.
×
×
  • Create New...