Jump to content
Froxlor Forum

rseffner

Members
  • Posts

    217
  • Joined

  • Last visited

  • Days Won

    9

Posts posted by rseffner

  1. Ich zähle zuerst mal kurz auf, wie ich glaube verstanden zu haben, wie froxlor zu seiner Traffic-Statistik (HTTP) kommt:
    - /etc/con.d/froxlor lässt täglich um 0:00 Uhr den traffic task los
    - dieser grept nach Monat und Jahr (nicht Tag) durch die Logs, so wie sie im VHost auch hinterlegt sind und piped das zu goaccess
    - dieses wiederum kann dann ja u.a. nur eine Summe für den Monat, aber nicht den Tag liefern
    - ein Rückschluss daraus ist, dass froxlor in der Trafficnutzung, die auf einzelne Tage auflöst, Differenzen der einzelnen goaccess-Summen verwenden muss
    So weit so gut.

    Jetzt beobachte ich aber an jedem Monatsersten einen gewaltigen Peak in der Tagesleistung, der sich bei Stichproben auch NICHT NUR nur aus der Summe des Vormonats spießt (er ist deutlich größer). Kann es sein, dass durch falsche Reihenfolge von traffic-task und logrotate die Monatssummen jeweils in den Monatsersten fakultativ aufbauen?
    - im Januar mit 0 begonnen und 1GB gemacht
    - 1. Februer mit 1GB gebucht und im Rest des Monats ein weiteres GB gemacht
    - 1. März mit den 1+1GB aus Feb gebucht und wieder 1GB gemacht
    - Jahressumme bis hierher 1 (Jan) + 2 (Feb) + 3 (Mär) = 6 !
    Genau so sieht leider auch der Jahresgraph aus ;-(

    Ich wollte mir unter Debian 12 bookworm nun logrotate anschauen. Das findet sich in cron.daily, dessen Skripte 6:25 Uhr getriggert werden. in logrotate.d habe ich ein file froxlor, welches sich monatlich um alles unter /var/customers/logs kümmert. Erstaunlich, dass die Rotationen aber eher gegen 0 Uhr stattfinden, denn 6:25 Uhr. Das syslog belegt, dass es einen logrotate.timer und -.service gibt, die gegen 0 Uhr gestartet und beendet werden.

    Da meine "Kunden" gern weiter in die Vergangenheit schauen, unterscheidet sich meine logrotate-Konfiguration in daily->monthly und rotate 7->13. Das sollte doch aber nicht ursächlich sein.
    btw.: die Funktion "Logdateien einsehen" gewährt vermutlich mit einem "tail" auch nur Zugriff auf die letzten paar dutzend Zeilen - richtig?

    Wenn logrotate 0 Uhr läuft, aber auch goaccess durch den traffic-task 0 Uhr getriggert wird, findet letzteres am Rotationstag doch entweder ein leeres Log vor oder ihm wird es beim Lesen unterm Hintern weggezogen. Nicht? 

    - Was verursacht bei mir diese Peaks immer am Monatsersten? Wie verhindere ich das?
    - Sollten die Zeitpunkte von traffic-task und/oder logrotate überdacht werden?
    - Wie könnte man den Kunden "mehr Log" als nur die paar letzten Zeilen dauerhaft zugänglich machen (skript mit symlinks in deren home?)

  2. Was für Magie.

    Beides gleichzeitig ging hier noch nie, und so sieht der erste cron-Lauf auch aus:
     

    [information] Requesting 1 new Let's Encrypt certificates
    [warning] Skipping Let's Encrypt generation for hem-architektur.de due to an enabled ssl_redirect
    [error] Could not find certificate-folder for domain 'hem-architektur.de'
    [information] Let's Encrypt certificates have been updated

    Ich habe den cron dann gleich nochmal laufen lassen und nun habe ich den ssl_redirect auf "1". Muss ich meine interne Doku anpassen, die "immer erst LE, dann cron, dann Redirect, dann cron" besagte.
    Bleibt der "bug" mit dem nachträglichen redirect.

  3. Da sehe ich das leider nicht.
    Im 1. Schritt deaktiviere ich die SSL-Weiterleitung und LetsEncrypt - dann cron - ssl_redirect ist "0"
    Im 2. Schritt aktiviere ich LetsEncrypt - dann cron - es wird erfolgreich ein Zertifikat abgelegt, ich kann die Seite dann auch ohne Browserwarnung mit https aufrufen - ssl_redirect ist weiter "0"
    Im 3. Schritt aktiviere ich wieder die SSL-Weiterleitung - dann cron - ssl_redirect ist wieder die "3" / es wird kein redirect angelegt

    Das Problem habe ich der "3" zu Folge mit 4 Domains.

    [information] Running Let's Encrypt cronjob prior to regenerating webserver config files
    [information] Checking for LetsEncrypt client upgrades before renewing certificates:_[Do 28. Nov 15:51:07 CET 2024] Already up to date!_[Do 28. Nov 15:51:07 CET 2024] Upgrade successful!_[Do 28. Nov 15:51:07 CET 2024] Installing cron job_20 0 _ _ _ LANG_en_US.UTF-8_ /root/.acme.sh/acme.sh --cron --home /root/.acme.sh _ /dev/null_[Do 28. Nov 15:51:07 CET 2024] Changed default CA to: https://acme-v02.api.letsencrypt.org/directory
    [information] Updated Let's Encrypt certificate for *****rchitektur.de
    [information] Let's Encrypt certificates have been updated
    
    [information] apache::createIpPort: creating ip/port settings for  [2a01:4f8:***:****::101]:80
    [debug] [2a01:4f8:***:****::101]:80 :: inserted listen-statement
    [notice] [2a01:4f8:***:****::101]:80 :: namevirtualhost-statement no longer needed for apache-2.4
    [information] apache::createVirtualHosts: creating vhost container for domain 337, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 338, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 336, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 335, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 334, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 333, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 506, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 504, customer *****rich
    [information] apache::createVirtualHosts: creating vhost container for domain 331, customer *****rich
    [information] apache::writeConfigs: rebuilding /etc/apache2/sites-enabled/
    [information] apache::writeConfigs: rebuilding /etc/apache2/htpasswd/
    [information] apache::writeConfigs: rebuilding /etc/apache2/sites-enabled/
    [information] Froxlor\Cron\Http\ApacheFcgi::reload: reloading Froxlor\Cron\Http\ApacheFcgi
    

     

  4. INSERT INTO `panel_domains` (`id`, `domain`, `domain_ace`, `adminid`, `customerid`, `aliasdomain`, `documentroot`, `isbinddomain`, `isemaildomain`, `email_only`, `iswildcarddomain`, `subcanemaildomain`, `caneditdomain`, `zonefile`, `dkim`, `dkim_id`, `dkim_privkey`, `dkim_pubkey`, `wwwserveralias`, `parentdomainid`, `phpenabled`, `openbasedir`, `openbasedir_path`, `speciallogfile`, `ssl_redirect`, `specialsettings`, `ssl_specialsettings`, `include_specialsettings`, `deactivated`, `bindserial`, `add_date`, `registration_date`, `termination_date`, `phpsettingid`, `mod_fcgid_starter`, `mod_fcgid_maxrequests`, `letsencrypt`, `hsts`, `hsts_sub`, `hsts_preload`, `ocsp_stapling`, `http2`, `notryfiles`, `writeaccesslog`, `writeerrorlog`, `override_tls`, `ssl_protocols`, `ssl_cipher_list`, `tlsv13_cipher_list`, `ssl_enabled`, `ssl_honorcipherorder`, `ssl_sessiontickets`, `description`) VALUES
    (333, '*****rchitektur.de', '*****rchitektur.de', 2, 25, NULL, '/var/www/webs/*****rich/*****rchitektur.de/', 1, 1, 0, 0, 0, 1, '', 1, 185, '-----BEGIN RSA PRIVATE KEY-----\nMIIEp*****zBn+de5lQ=\n-----END RSA PRIVATE KEY-----\n', 'MIIBI*****AQAB', 1, 0, 1, 1, 0, 1, 3, '', '', 1, 0, '2024112809', 1521111357, '2018-03-15', NULL, 59, 0, 0, 1, '0', 0, 0, 0, 1, 0, 1, 1, 1, 'TLSv1.2,TLSv1.3', 'EECDH+AESGCM:EDH+AESGCM', '', 1, 1, 1, '');
  5. Hallo,


    ich habe hier eine Domain (habe es noch nicht mit anderen probiert), für die bekomme ich die SSL-Weiterleitung nicht aktiviert. VHosts für http sowie https funktionieren einzeln betrachtet. Egal ob Schalter ein, aus und wieder ein mit Cron dazwischen, oder Configs neuschreiben. Der http-VHost wird immer neu angelegt, aber nie mit dem https-redirect.

    Was übersehe ich?

    Gruß, Ronny

  6. Ich krame das hier nochmal raus, weil ich mich dann nicht weiter drum gekümmert habe:

    Wir haben doch aktuell folgende Query in der mysql-virtual_sender_permissions.cf

    SELECT DISTINCT username FROM mail_users WHERE email in ((SELECT mail_virtual.email_full FROM mail_virtual WHERE mail_virtual.email = '%s' UNION SELECT mail_virtual.destination FROM mail_virtual WHERE mail_virtual.email = '%s'));

    Damit (und den settings in main.cf) müssen nach wie vor SASL login und envelope from übereinstimmen.
    Um eine Analogie zum catch-all - also ein send-all - zu realisieren, habe ich in den smptd_sender_restrictions das reject_sender_login_mismatch entfernt. Nun könnte doch aber jeder SASL-Nutzer mit einer beliebigen (die eines anderen Kontos, die eines anderen Froxlor-Kunden, ja sogar jeder beliebiger) Adresse versenden. Das sollte ich tunlichst wieder einschränken.

    Pflicht wäre ein match zwischen SASL domain und envelope from domain.
    Wäre das dann korrekt?

    # VOR permit_sasl_autheticated
    check_sender_access mysql:/etc/postfix/mysql-sender-domain-check.cf,
    
    # da drin dann
    user = xxx
    password = xxx
    hosts = 127.0.0.1
    dbname = xxx
    query = SELECT domain FROM mail_virtual WHERE '%s' LIKE CONCAT('%%', domain)
    
    # und auf reject_sender_login_mismatch verzichten oder ZWISCHEN check_sender_access und permit_sasl_authenticted?


    Kür wäre dann aber ein Match zwischen SASL domain und beliebiger envelope from domain des Froxlor-Kunden.

    Kann denn jemand eine entsprechende Query formulieren?


    Danke für die Aufmerksamkeit, Ronny

  7. Das kann zu hier. Kein bug.

    In "rspamadm configdump" sind die Einträge under dieser ominösen frx_ID doppelt. in der froxlor_settings.conf nicht.
    Ich kopiere die settings.conf von zwei Servern zusammen, dass auch der backup-MX weiß, was der Postfachbesitzer wünscht und SPAM nicht über den backup-MX eingeschleust werden kann. Offenbar ist in der DB eines Servers ein verwaister Eintrag zu der Domain, während die eigentlich auf dem anderen Server eingerichtet ist. Zweimal die Domain, zweimal md5() und dann include mit merge.

    Ich geh mich schämen und räume auf.

  8. Es ist wieder dieser Teil:

     

    # Email: @ptz-prototypen.de
    frx_0ba31014ba51a9fa2916fb3dd646fde8Z_rcpt {
           id = "frx_0ba31014ba51a9fa2916fb3dd646fde8Z_rcpt";
           priority = low;
           rcpt = "@ptz-prototypen.de";
           apply {
                   actions {
                           "add header" = 7;
                           rewrite_subject = 7;
                           reject = 14;
                   }
           }
    }
    frx_0ba31014ba51a9fa2916fb3dd646fde8Z_from {
           id = "frx_0ba31014ba51a9fa2916fb3dd646fde8Z_from";
           priority = low;
           from = "@ptz-prototypen.de";
           apply {
                   actions {
                           "add header" = 7;
                           rewrite_subject = 7;
                           reject = 14;
                   }
           }
    }
    

    Das "Z" da anzuhängen wirkt (nun? hatte ich mich zu früh gefreut) nicht mehr.

  9. Ich habe lib/Froxlor/Cron/Mail/Rspamd.php ab Zeile 173 wie folgt angepasst (ein "Z" eingefügt) und erstmal Ruhe:

    $this->frx_settings_file .= 'frx_' . $email_id . 'Z_' . $type . ' {' . "\n";
    $this->frx_settings_file .= '<->id = "frx_' . $email_id . 'Z_' . $type . '";' . "\n";

    Bugreport bei rspamd ist auch eröffnet. Erstaunlich, dass das in anderen Versionen zu funktionieren scheint.

  10. 12 minutes ago, d00p said:

    steht halt nur dazu:
     

    name - section name that identifies this specific setting (e.g. some_users)

    weder was über länge, verbotene zeichen, nix ...würdest du es mal probieren mit gleicher länge nur ohne zahlen? Vllt mag er die nicht ...

    Die Ziffern allein können das Problem nicht sein, denn die ganzen anderen "frx_" Bezeichner und ID haben auch Ziffern und funktionieren. Ich vermute eher, dass da LUA oder rspamd-code intern eine De-/Codierung/Interpretation erfolgt, die zu Zeichen führt, die in der weiteren Verarbeitung auf eine Tabelle hindeuten. Vielleicht sollte der "Zufall" nicht ganz so HEX (vielleicht einfach zwangsweise in den Mittelteil ein Zeichen >f einstreuen 😉 aussehen. Vermutlich ein Fall für den rspamd Entwickler, aber ich brauche auch mit Froxlor erstmal eine Lösung, bis sich der Entwickler bewegt. Machst Du ein Ticket bei rspamd auf oder soll ich (später)?

  11. Es ist der Bezeichner!
     

    frx_0ba31014ba51a9fa2916fb3dd646fde8_rcpt {
            id = "frx_0ba31014ba51a9fa2916fb3dd646fde8_rcpt";
    

    Ändere ich den zu "frx_test_rcpt" ist der Fehler weg. Wer weiß was LUA da in den String interpretiert, den es ja dann offenbar für eine Tabelle hält.

    Ich habe 754kB mit ca. 1.500 Mailadressen und nur dieser eine Bezeichner macht die Probleme.

  12. Der Fehler liegt (unter anderem?) hier:

    frx_0ba31014ba51a9fa2916fb3dd646fde8_rcpt {
            id = "frx_0ba31014ba51a9fa2916fb3dd646fde8_rcpt";
            priority = low;
            rcpt = "@ptz-prototypen.de";
            apply {
                    actions {
                            "add header" = 7;
                            rewrite_subject = 7;
                            reject = 14;
                    }
            }
    }
    

    Das einzig Verständliche in der Fehlermeldung ist für mich "(string expected, got table)". Ein Formatierungsfehler vermutlich - nur kann ich den nicht sehen.

    rspamd 3.9.1 aus dem deb vom rspamd repo.

  13. Ja ich meine das rspamd web UI.

    Ich habe eine Spur:

    2024-09-12 12:31:43 #1809170(main) <ergubd>; cfg; rspamd_lua_run_config_post_init: cannot run config post init script: /usr/share/rspamd/lualib/lua_settings.lua:174: bad argument #1 to 'update' (string expected, got table); trace: [1]:{[C]:-1 - update [C]}; [2]:{/usr/share/rspamd/lualib/lua_settings.lua:174 - numeric_settings_id [Lua]}; [3]:{/usr/share/rspamd/lualib/lua_settings.lua:236 - register_settings_id [Lua]}; [4]:{/usr/share/rspamd/plugins/settings.lua:1152 - process_setting_elt [Lua]}; [5]:{/usr/share/rspamd/plugins/settings.lua:1215 - fun [Lua]}; [6]:{/usr/share/rspamd/lualib/fun.lua:34 - call_if_not_empty [Lua]}; [7]:{/usr/share/rspamd/lualib/fun.lua:192 - for_each [Lua]}; [8]:{/usr/share/rspamd/plugins/settings.lua:1207 - process_settings_table [Lua]}; [9]:{/usr/share/rspamd/plugins/settings.lua:1429 - <unknown> [Lua]};; priority = 100

    Ich baue gerade die froxlor_settings.conf Stück für Stück zusammen und kann dann hoffentlich einen Hinweis liefern.

  14. Hallo,

    ich habe an Mailadressen individuelle scores für rewrite und reject eingestellt. Ein 'rspamadm configdump' bestätigt, dass die Einstellung den weg in die geladene rsmapd-Instanz gefunden hat. Schaue ich allerdings ins UI sehe ich noch immer in der Spalte "score" hinte dem "/" den default von "14". Entsprechend werden die Mails auch nicht so behandelt, wie von mir durch individuelle Einstellungen gewünscht.

    Was kann ich falsch gemacht haben?

    Gruß, Ronny

  15. Ist doch offensichtlich. Der Installer läuft mit einem VHost der PHP 8.3 hat und dem PHP8.2 fehlen die genannten Module. Da nützt es auch nix, wenn Du deren 8.eer Geschwister installierst. Und warum erwähnst Du dann noch die gnadenlos veraltete (kein Support mehr) 5.6?

    Du willst Serveradmin sein, dann übernimm Verantwortung und recherchiere, lies Meldungen genau und denke nach. Der Post war echt unnötig.

  16. Seit zwei, drei Tagen gibts Mail vom cron (traffic-task) in der Form:

    [SETTING UP STORAGE -] {0} @ {0/s}
    [SETTING UP STORAGE -] {0} @ {0/s}
    [SETTING UP STORAGE -] {0} @ {0/s}
    [SETTING UP STORAGE -] {0} @ {0/s}
    [SETTING UP STORAGE -] {0} @ {0/s}
    [SETTING UP STORAGE -] {0} @ {0/s}
    [PARSING -] {11,268} @ {0/s}

    Wo kommt das her, wie stelle ich das ab?

    Der Task dazu:

    /usr/bin/nice -n 5 /usr/bin/php -q /var/www/html/froxlor/bin/froxlor-cli froxlor:cron 'traffic' -q 1> /dev/null

×
×
  • Create New...