macOS macht einem das in neueren Versionen sehr schwer, da Apps notarisiert werden müssen etc, um keine Warnungen und Verrenkungen bei der Installation zu erfordern. Ein on-the-fly-Generieren der Toolbox ist damit deutlich erschwert, man muss vermutlich bei Apple die entsprechenden Mitgliedschaften/Zertifikate kaufen etc...
Beiträge von patrick
-
-
sshfs scheint kein Locking zu unterstützen, daher kann das gefährlich werden. Ich würde es nicht tun.
-
Die Meldung deutet darauf hin, dass die .msg-Datei der jeweiligen E-Mail im data-Ordner entweder fehlt oder aus anderen Gründen nicht geöffnet werden kann (Rechte, etc).
-
Sehr konfuser Thread, bin mir nicht sicher ob hier nicht Dinge vermischt werden, die eigentlich nichts miteinander zu tun haben. Es fehlt weiterhin an vielen Informationen (zB wie der „Fehler“ (welcher?) behoben wird und was das Template damit zu tun hat).
-
Die Fehlermeldung sollte eigtl auch schon im Setup auftreten, wenn mich nicht alles täuscht. Man merkt es also früh genug.
-
Stimme ich voll und ganz zu. jeder Benutzer sollte seine eigene Tabelle bekommen mit seinen eMails.
Ich denke ein Sharding-Ansatz wäre sinnvoller, habe dazu hier im Forum schonmal irgendwann was geschrieben.
-
Das synchronisiert bei mir praktisch sofort… Ist das ein sehr großes Postfach? Wie lange dauert das denn bei dir ca.?
Was habt ihr als „Internes Idle-Poll-Intervall“ eingestellt in den bMS-IMAP-Einstellungen?
-
Gute Initiative, habe ich mal aufgegriffen (siehe https://github.com/b1gMail/b1gMailServer/issues/20). Ich vermute, dass das OpenSSL-Library-Problem daher kommt (kam), dass der MariaDB-Connector noch gegen OpenSSL 1.1 gelinkt hatte. Hatte aber bisher noch keine Zeit, zu testen. Wäre super wenn das jemand testen könnte.
-
Wenn jemand einen betroffenen Account mit mir teilen könnte, den ich zum Test auf einem Testgerät einrichten darf, plus ACP-Zugriff, wäre das super hilfreich. Ich konnte es selbst bisher nur einmal reproduzieren, und konnte den speziellen Fall durch eine Änderung entschärfen (siehe letzter bMS-Commit auf GitHub (*)). Es scheint aber noch mehrere andere Ursachen zu geben, die ich bisher nicht reproduzieren konnte.
-
Super, dass es wieder funktioniert.
Manchmal sind's einfach komische Zufälle...
-
Ja, an der Datei liegt es nicht, das muss was anderes sein.
Die Mailserver-Queue wird aber abgearbeitet? Was sagen die b1gMail-Logs?
-
Die Datei gehört zum Adminbereich und wird beim Mailempfang nichtmal geladen. Ein Zusammenhang mit der Änderung dürfte ausgeschlossen sein.
Um rauszufinden, woran das Problem liegt, sind also mehr Informationen nötig. -
Ich benutze einen eigene SMS Lösung, bestehend aus einer Lebara 3€/mon SMS Flat, nen Billigen UMTS Stick, Debian als Betriebssystem und nem PHP SMS Script welches über GET mittels URL abgerufen wird.
PSA: Man sollte da aber genau die AGB lesen, vor allem wenn man das nicht nur selbst nutzt.
-
Was heißt "ist aus"? Lebt der Prozess nicht mehr? Falls der Prozess abstürzt (-> syslog / dmesg), mit welchen Details? Mail/Syslog-Einträge? Fragen über Fragen
-
SMTP als Versandmethode ist in der Hinsicht deutlich weniger fehleranfällig. Ich würde empfehlen, umzustellen.
-
Die Mail mit der ID 98.120.000 liegt in 98/12/00/00.msg
ID 99.999.999 in 99/99/99/99.msg
ID 100.000.000 in 10/00/00/00/0.msg
Es geht also dann in Ordner 10/ weiter.
-
Ich habe optimize auskommentiert das dauert halt immer, kann man ja danach noch machen, genau wie ich beim user löschen jetzt aktuell die spamindex nicht mit lösche, dauert auch immer. Das letzte mal habe ich die Kisten 0:00 ausgemacht und 05:00 morgens war das update von 7.2 auf 7.4 durch dabei war das lange Update bei b1gmail 7.3 und das auf 7.4 dauert nur paar Minuten, ich weiß ja nicht wie lange es dann auf 7.4.1 dauert aber bestimmt nicht lange
Die OPTIMIZE-Schritte kann man auch ruhig komplett aus dem Updater rauswerfen, denke ich. Kann ja jeder selbst entscheiden, wie und wann er mal die Tabellen optimieren lässt.
-
Vermute mal das liegt an der Verwendung von Windows, da dort Ausführungsrechte (chmod +x) nicht abgebildet werden können und dann den Weg nicht mit ins Ziel-Image finden...
Edit: Habe mal eine Änderung gepusht, die das beheben könnte...
-
Verstehe ich. Das DB-Update könnte man aber auch manuell durchführen, wenn man die SQL-Anweisungen zur Verfügung hat. Damit könnte man zumindest den Fortschritt selbst steuern, eventuell ja schon vorbereiten, während man dann das Script updatet.
Das betrifft Systeme nicht die nur wenige Nutzer haben. Bei mir klingeln sämtliche Kanäle, wenn das System mal ne halbe Stunde nicht zur Verfügug steht.Oft gibt es leider keine statischen Queries für das Update sondern es handlet sich um kompizierte Logik (z.B. wenn Daten konvertiert werden müssen). Ansonsten stimme ich zu, dass man zumindest für die 'ALTER TABLE'-Queries im Updater auch eine Liste ausgeben könnte.
-
Ein DB-Update im Hintergrund ist schwierig, da der neue Code ja schon das geänderte Schema vorausetzt. Man müsste die Änderungen dann immer abwärtskompatibel halten und bis zum Abschluss die vorherige Version weiter betreiben. Gerade wenn Backfilling neuer Felder nötig ist, ist das u.U. nicht ganz trivial, da die Daten während des Updatevorgangs weiterhin "lebendig" sind und sich verändern...
Ein möglicher Schritt zu einem stabileren Update wäre es aber, eine Kommandozeilen-Version des Updaters zu erstellen, die nicht durch Timeouts etc beeinträchtigt wird und nicht von einer Browsersitzung abhängt. Bei etwaigen Fehlern könnte man weiterhin ein Token ausgeben, mit dem die Fortsetzung möglich ist (was auch schon beim Web-Updater eine realisierbare Sache wäre).
