rseffner

Welche weitere Info braucht es denn?

Keine AliasDomain als "Alias für Domain" eingetragen und ein richtiges DocumentRoot statt "http(s)://irgend.wo.anders". Ich kanns reproduzieren und sehe es ja am Zeitspempel der VHost-Config. Betrifft offenbar alle Domains, die bisher noch keine Weiterleitung hatten. Ich kann keine umkonfigurieren obwohl die VHosts neu erstellt werden. FROXLOR 2.2.5 aus https://files.froxlor.org/releases/froxlor-latest.tar.gz

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

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

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.

Wenn ich diesen Teil in ein settings.conf eines anderen Servers A kopiere, ist das reproduzierbar. Kopiere ich auf Server B, dann nicht. Jetzt muss ich wohl schauen, wo der Unterschied zwischen Quelle + Server A und Server B liegt.

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.

Das hat auch nicht (lange) geholfen. Der Fehler ist wieder da, nur finde ich diesmal die Stelle in der config nicht so schnell ;-( Der LUA-code, der die settings liest, stolpert irgendwo über "...string expected, got table...".

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.

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)?

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.

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.

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.

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

Hallo, wenn man in den E-Mail-Adress-Einstellungen gleichzeitig Werte in den editierbaren Feldern (z.B. reject score) anpasst und dann einen der "Umschalter" (z.B. für SPAM-Schutz oder Greylisting) betätigt, wird durch das Neuladen der Seite der geänderte Wert wieder zurückgesetzt. Vielleicht lässt sich das zukünfig besser lösen. Gruß, Ronny

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.

Ich konnte es eingrenzen auf Logfiles mit 0 Byte Größe. Bei diesen kommt die eingangs zitierte Formatfehler-Meldung. Logfiles Größe 0 gab es aber auch bisher schon. Ich glaube noch immer, dass sich das Verhalten von goaccess da geändert hat.

Gestern wurde für debian goacces 1.9 ausgerollt und nun gibts vom traffic-cron ==1286357== Formatfehler - Prüfen Sie das Log-/Datums-/Zeitformat ==1286389== Meldungen. Vermutlich muss ich code wieder der goaccess-Aufruf angepasst werden.

@d00p hat Dir meinen Artikel verlinkt, wenn Du qualifizierte Fragen hast ... bei mir läuft das noch so (oder ähnlich) und ich kann sicher antworten.

Der unerwünschte Output ist weg.

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

Beim Verstehen kann ich im Moment auch nicht helfen, aber bestätigen, dass die Anpassungen auch für mich funktionieren.

Ich habe FCGID aktiviert, falls das eine Rolle spielt. Das Ändern der PHP-Konfiguration unter System -> Einstellungen -> Froxlor VirtualHoste Einstellungen führt leider nur zu: error.not in option Was habe ich falsch gemacht?

Drücke ich einen der Sortierpfeile neben "In Verwendung für Domain(s) unter den PHP-Konfigurationen, erhalte ich folgenden Fehler: 500 SQLSTATE[42S22]: Column not found: 1054 Unknown column 'domains' in 'order clause' Ist das eine SYSCP-Leiche oder ein aktueller Bug? An der Stelle würde ich mir sogar Sortierung "in zwei Ebenen" wünschen: primär nach Kurzbeschreibung und innerhalb dieser Trefferblöcke dann nach Domain.

Ich konnte das nicht nochmal reproduzieren. Also: kein Fehler.