Beiträge von ManDal

    Ja und nein. Grundsätzlich sollte PHP die abgelaufenen Sessions selbst bereinigen, sofern die entsprechenden Einstellungen korrekt gesetzt sind. Ich hatte aber schon mehrfach Systeme, bei denen der Session-Ordner trotzdem über längere Zeit nicht oder nicht zuverlässig bereinigt wurde.

    Genau für solche Fälle halte ich eine zusätzliche, definierte Bereinigung für sinnvoll. Alles, was älter als X Tage ist, kann dabei gezielt entfernt werden. Damit ist man nicht davon abhängig, ob und wann der PHP Garbage Collector tatsächlich greift.

    Neu gibt es in b1gMail 7.5.0 die "Geplanten Aufgaben". Das ist der ehemalige CleverCron, den ich fest in den b1gMail Core integriert habe. Darüber lässt sich auch die Session-Bereinigung sauber und regelmässig ausführen.

    Die 7 Tage aus meinem Beispiel sind für Sessions wahrscheinlich etwas sportlich gewählt. Das ist aber komplett frei konfigurierbar. Man könnte die Bereinigung beispielsweise einmal pro Woche um 04:00 Uhr laufen lassen und nur Session-Dateien entfernen, die älter als 30 Tage sind.

    Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.


    Damit ersetzt b1gMail die PHP-eigene Session-Bereinigung nicht, sondern hat zusätzlich einen kontrollierten Fallback. Selbst wenn der PHP-GC aus irgendeinem Grund nicht sauber arbeitet, wächst der Session-Ordner dann nicht wieder über Monate oder Jahre auf hunderttausende oder sogar Millionen Dateien an.

    Kann ich aber auch verstehen, gerade wenn man ein Tool über Jahre genutzt hat und es einfach dazugehört. :)

    Eine Sache, die ich für die Zukunft aber tatsächlich interessant fände, wäre eine vernünftige Datensynchronisation. Also eher in Richtung eines kleinen Nextcloud-Clients: Ordner auswählen, lokale Änderungen automatisch synchronisieren und das Ganze zuverlässig im Hintergrund laufen lassen.

    Das hätte meiner Meinung nach auch heute noch einen echten Mehrwert und wäre vielleicht die sinnvollere Richtung für eine neue Toolbox, statt alte Funktionen einfach 1:1 nachzubauen oder am leben zu erhalten...

    Die Frage ist für mich vor allem, ob die Toolbox in ihrer jetzigen Form überhaupt noch das abdeckt, was man heute von so einer Anwendung erwartet.

    Interessant wäre deshalb, welche Anforderungen du bzw. die Community heute an eine neue Toolbox hättet.

    Ich weiss zum Beispiel nicht, welchen Stellenwert Fax heute noch hat. Auch die Benachrichtigung über neue E-Mails ist als eigenständige Funktion weniger relevant geworden, da b1gMail 7.5.0 dies bereits per Web Push unterstützt, auch wenn b1gMail gerade nicht im Browser geöffnet ist.

    Wenn man diese beiden Punkte einmal ausklammert, bleibt von der bisherigen Toolbox im Wesentlichen die Datensynchronisation übrig. Und gerade dort sehe ich noch einiges an Potenzial.

    Für mich wäre deshalb fast die spannendere Frage: Welche Funktionen müsste eine moderne b1gMail Toolbox heute bieten, damit sie im Alltag tatsächlich einen Mehrwert bringt?

    Ja, ich werde in der 7.5.0 noch einen Fix einbauen, damit sich solche Mengen an Session-Dateien möglichst gar nicht erst ansammeln und die Bereinigung zuverlässiger funktioniert.

    Die rund 1,5 Millionen Dateien bei Loadbox waren so viele, dass das direkte Löschen schlicht zu lange gedauert hat. Deshalb habe ich den Session-Ordner verschoben und direkt neu angelegt:

    Code
    mv temp/session temp/session_old
    mkdir temp/session
    chmod --reference=temp/session_old temp/session
    chown --reference=temp/session_old temp/session


    Danach konnte der alte Ordner separat gelöscht werden:

    Code
    rm -rf temp/session_old

    Danke für die ausführlichen Tests mit den PHP-Versionen. Das passt zu unseren Beobachtungen.

    Das Problem scheint nicht direkt am BMS-Outbound zu liegen, sondern an der DNSBL-Prüfung von b1gMail über pipe.php. Bei vielen DNSBL-Einträgen und einzelnen Timeouts kann die Verarbeitung unter PHP 8 auf über 30 Sekunden pro Mail steigen.

    Unsere Empfehlung bei b1gMailServer:

    • DNSBL unter b1gMail > E-Mail > Anti-Spam deaktivieren und stattdessen direkt in BMS als Zonen pflegen, z. B. zen.spamhaus.org oder bl.spamcop.net.
    • Danach php_path wieder auf PHP 8 setzen und die Queue beobachten.
    • Bei uns lief pipe.php danach unter PHP 8 wieder mit ca. 0,1 statt über 30 Sekunden.

    Hi Netzwerkebene passt alles bei Claus, ich vermute das es etwas mit PHP zu tun hat, da PHP 8 ja strikter agiert als php 7 und damit ggf, einiges an verbindungen oder TLS anders anfasst. Oder im B1GMailServer selber ist im Zusammenhang mit php 8 etwas anders, was noch angepasst werden muss.

    Claus sein System wurde komplett auf die neue Debian Trixie umgstellt, also nicht nur PHP. Aber Systemseitig ist alles getestet. Ich habe zum Test PHP7 parallel getestet, damit geht es. Nur PHP 8 nicht. Daher ein Zusammenhang B1GMSzu PHP8.

    danke für den Paralleltest

    "Timeout while connecting socket" entsteht beim BMS-Outbound-Connect (queue_timeout), nicht in PHP.

    PHP (pipe.php) wird nur für Inbound genutzt.


    Ein Zusammenhang mit PHP 8 ist trotzdem denkbar, eher indirekt: Inbound und Outbound teilen sich den Thread-Pool. Unter hoher Last könnte eine langsamere oder problematischere Pipe unter PHP 8 Worker länger belegen und Outbound dadurch aufstauen. Auf kleineren Systemen fällt so etwas oft kaum auf.

    Zum Eingrenzen wäre hilfreich, bei sonst gleicher Config nur php_path zu vergleichen:

    Code
    printf 'From: test@example.com\nTo: user@domain.ch\nSubject: t\n\nx\n' \
      | "$PHP" /pfad/zu/b1gmail/interface/pipe.php --timeout=60 -- "user@domain.ch"; echo exit=$?
    
    time "$PHP" .../pipe.php --timeout=60 -- "user@domain.de" < /tmp/test.eml


    In der Queue Socket-Timeouts (Zielhosts?) und Pipe-/Inbound-Fehler getrennt betrachten, treten letztere vor allem unter PHP 8 auf?

    Meine technische Einschätzung:

    "Timeout while connecting socket" kommt vom b1gMailServer-Queue-Dienst beim Aufbau der ausgehenden TCP-Verbindung zum Ziel-MX/Relay, nicht von PHP oder pipe.php. Die PHP-Version steuert die SMTP-Verbindung nach aussen nicht.

    Unsere bisherigen Änderungen an Auth/pipe.php würden eher Fehler im Bereich Pipe/Inbound verursachen, nicht diesen Connect-Timeout.

    Eine stark wachsende Queue kann entstehen durch:

    • Zielserver, die Verbindungsversuche einfach „droppen“
    • mehrere MX-/A-Records × 60 s Timeout pro Versuch
    • blockierte Worker durch hängende Outbound-Verbindungen


    Ich würde testweise ein betroffenes Ziel direkt vom Server prüfen:

    Code
    dig +short MX beispiel.ch
    nc -vz -w 5 mx1.beispiel.ch 25
    time nc -vz -w 65 <IP> 25


    Sind immer dieselben Domains/IPs betroffen und dauert der Connect tatsächlich ~60 Sekunden?

    Rein der Wechsel PHP 7.4 > 8.4 sollte diesen TCP-Connect-Timeout normalerweise nicht verursachen.

    Vielen Dank für das ausführliche Feedback, freut mich wirklich zu hören! :)

    Gerade nach den Problemen mit der RC2 ist es schön zu sehen, dass die Änderungen in der RC3 greifen und die wichtigsten Bereiche bei dir jetzt sauber laufen.

    Ich bin natürlich weiterhin an Rückmeldungen interessiert, insbesondere wenn dir beim weiteren Testen noch Fehler oder Ungereimtheiten auffallen. Je mehr unterschiedliche Installationen und Szenarien getestet werden, desto stabiler bekommen wir die 7.5.0 am Ende.

    Danke fürs Testen und Melden!

    Das Verhalten ist so nicht normal und sollte definitiv nicht auftreten.

    Wenn du möchtest, kannst du mir über support@onesystems.ch einen Zugang zum ACP sowie die SFTP-Zugangsdaten zukommen lassen. Dann schaue ich mir das gerne direkt auf dem betroffenen System an.


    Wichtig ist allerdings der Hinweis, dass es sich aktuell noch um eine RC-Version handelt und diese noch nicht für den produktiven Einsatz vorgesehen ist.

    Das kann ich so nicht nachstellen, hast du noch mehr Infos aus Logs oder Console?

    Tabler liess sich im ACP nicht auswählen, weil das Template-Dropdown kaputt war (erster Eintrag wurde verschluckt). Ist behoben — Inhalt nach modern kopieren ist nicht mehr nötig.

    Login merken ist wieder da. Mit MFA einmal auf dem Gerät bestätigen, danach nicht mehr bei jedem Besuch.


    Was mir noch aufgefallen ist beim kurzen Test: Die Passwörter beim Adminlogin dürfen nicht konvertiert werden, wenn die Tabelle nicht angepasst worden ist (z.B durch fehlerhaftes Upgrade), sonst wird ein Teil abgekürzt und Login wird unmöglich.

    In Zusammenhang mit MySQL 8.x gibt es noch einen Bug, den ich bisher aus Zeitgründen nicht gelöst habe: https://github.com/b1gMail-OSS/b1gMail/issues/2

    Passwörter werden erst beim Login umgestellt, nicht beim Update. Wenn die Spalte noch zu kurz ist, wird jetzt nicht mehr konvertiert, sonst war der Login weg.

    Der MySQL-8-Loop in update.php (int(11) vs. int) ist ebenfalls gefixt, damit die Spalte beim Update auch wirklich angepasst wird.

    Beides im nächsten Commit.


    Fix ACP Tabler selection, remember-me login, and MySQL 8 upgrades. by mkleger · Pull Request #23 · b1gMail-OSS/b1gMail
    Keep Tabler selectable in the admin template dropdown, restore Login merken without repeating MFA on a trusted device, and refuse truncated password hashes…
    github.com

    Hast du dazu Screenshots oder konkrete Fehlermeldungen, mit denen man arbeiten kann?

    Interessant wäre vor allem:

    • Was genau passiert beim Öffnen einer E-Mail?
    • Gibt es Fehler in der Browser-Konsole?
    • Gibt es Einträge im PHP-/Webserver-Error-Log?
    • Welche URL wird beim Klick auf „Einstellungen“ aufgerufen bzw. wohin wirst du weitergeleitet?
    • Tritt das Verhalten auch in einem privaten Browserfenster auf?

    Dass nach einem erneuten Login plötzlich wieder das alte Design erscheint und sogar Elemente wie der Benutzername fehlen, klingt zumindest danach, dass beim Update etwas mit Templates, Cache oder den übernommenen Einstellungen nicht sauber zusammenspielt. Da die Neuinstallation auf demselben Server funktioniert, wäre der Unterschied zwischen Update und Neuinstallation besonders interessant.

    Mit Screenshots und den konkreten Fehlern kann ich das wesentlich besser eingrenzen. Nur anhand von „geht nicht“ wird die Fehlersuche leider etwas mühsam.

    7.5 braucht PHP 8.1+ (8.2/8.3/8.4/8.5 ok). PHP 7.4 ist nicht mehr vorgesehen.

    Ein leerer 500 kommt meist daher, dass nach dem PHP-Wechsel die Module fehlen.

    Vor dem Update im b1gMail-Verzeichnis (Inhalt von src/):

    Code
    php -v
    php -m | grep -Ei 'mysqli|mbstring|json|openssl|session'


    Alle genannten Extensions müssen für genau diese PHP-Version aktiv sein. Danach Cache leeren, Update-Lock entfernen und setup/update.php aufrufen:

    Code
    rm -f templates/*/cache/* admin/templates/cache/* temp/cache/*.cache
    rm -f setup/lock_update


    Wenn es dann noch 500 ist: die erste PHP-Zeile aus dem Error-Log posten.

    Läuft die 7.5 auch noch mit unterordner (z.B. domain.de/b1gmail) oder nur auf dem Rootverzeichnis der Subdomain/Hauptdomain? Das kriege ich aktuell in der Konstellation nicht zu laufen.

    Bin den Code durchgegangen und ja das ist aktuell ein Problem da die Routen hart auf / gehen also nicht nur in der .htaccess, werde das anpassen.