b1gMailServer 2.7.3240

patrick

patrick

Staff member
B1G-Software-Kunde
b1gMailServer 2.7.3240 für b1gMail 7.2/7.3/7.4-Beta(1,2) steht nun zum Download bereit.

Wichtig: Diese b1gMailServer-Version ist ausschließlich mit b1gMail 7.2, 7.3 und 7.4 kompatibel.

Änderungen 2.6.3208 -> 2.7.3221
* Möglicher Absturz beim Versand von Mails per SMTP i.V.m. mit b1gMail 7.4 behoben
* Logik-Fehler bei Versandlimit i.V.m. b1gMail 7.4 behoben
* Verbesserte IMAP-Synchronisierung bei Benutzung von Microsoft Outlook
* Unterstützung von Push auf iOS-Geräte
* Verschiedene Verbesserungen und Optimierungen
Click to expand...

Neuinstallation
Falls noch nicht geschehen, auf b1gMail 7.2 oder höher aktualisieren (empfohlen: b1gMail 7.3).
Bitte der Installations-Anleitung folgen, die im Wiki zu finden ist.

Update von Version 2.5/2.6/2.7
Falls noch nicht geschehen, auf b1gMail 7.2 oder höher aktualisieren (empfohlen: b1gMail 7.3).
Downloadarchiv im Kundencenter herunterladen, "liesmich.html" lesen

Hinweise:
  • Vor Update bitte zuerst, falls nötig, das Admin-Plugin aktualisieren (siehe Liesmich-Datei).
  • Die Dokumentation ist immer aktuell im Wiki einsehbar: http://wiki.b1gmail.com/wiki/b1gMailServer
  • Zur Nutzung der neuen Autodiscover-/Autoconfig-Funktion sind nach dem Update noch weitere Schritte nötig
  • Für Apple-Push-Support ist ein Zertifikat von Apple erforderlich (mehr Infos siehe hier)
 
Last edited:
Hallo, BMS (Warteschlange) startet nach Update und reboot nicht mehr automatisch, wurde hier was geändert? Haben das Problem auf meheren Servern bisher...jedoch nicht auf allen. Vorallem Debian jessie Systeme...
Startet man diese manuell neu, schmiert Sie nach einiger Zeit wieder ab.

Manueller Updatebefehl von update-rc.d brachte Erfolg!

MfG
 
Last edited:
Nach dem update musst du sytemctl daemon-reload ausführen,

Dann kannst mittels: service bms-queue restart den bms neu starten
 
Hallo, kann es sein das das Mail Limit/h in dieser Version nicht mehr stimmt. Wir haben hier Neukunden, die senden 1ne Mail und es kommt die Meldung limit reached, obwohl Sie nicht nur eine senden/h dürfen sondern z.B. 50....

MfG
 
Welche b1gMail-Version und welche Einstellungen sind genau in der Gruppe gesetzt für das SMTP-Limit und den Mindestabstand? Weiterhin bräuchte ich die genaue Log-Meldung.

Die im Changelog genannte Änderung betrifft nur Verwendung von b1gMail 7.4. Andere Stellen wurden nicht geändert in dieser Beziehung.
 
Last edited:
Hi Patrick,

Version (Admin-Plugin): 1.142
Version (Core): 2.7.3240
B1G Verison: 7.3
SMTP-Limit (Mails): 30
SMTP-Limit (Minuten): 60

Error-Meldung bei KD: 450 4.5.3 Mail limit reached: Please try again later.

Scheint auch nur bei neuen Registrierungen aufzutreten der Fehler, seit Update auf diese B1G-SRV-Version!

MfG
 
Last edited:
Und Log-Meldung im b1gMailServer-Log?

Bist du 100%ig sicher, dass das Limit nicht doch überschritten wurde?

Habe nochmal nachgesehen, am 7.3-bezogenen Code hat sich nichts geändert beim Versand.
 
Last edited:
Hallo, prüfen wir gerade bei den 3 neuen Kunden die das gemeldet haben. haben alle Live Mail von Windows. Konnte es selbst bisher noch nicht nachstellen das ganze daher teste ich gleich auf einer VM mit Live Mail mal. Nicht das die nicht im Webmail eingeloggt waren und SMTP noch inaktiv war, dann kommt nämlich glaub auch fälschlicherweise diese Meldung.
 
Hmm ich kanns hier auch nicht nachstellen, sorry, zu früher Post, aber da gleich 3 Neukunden den selben Fehler haben ist das bisl komisch, Ich rechachier mal bei den 3 Kunden. Danke dir erst mal...

PS: das Apple zert bekommsch das auch wennch im Shop bei Apple das System kaufe und auf ne VM installiere - oder brauch ich zwingend nen MAC?
 
Hallo, nach dem Update hängen die SQL Server an folgenden Befehl fest:

Sending data
REPLACE INTO bm60_bms_imapuid(`imapuid`,`mailid`) SELECT `id` AS `imapuid`, `id` AS `mailid` FROM bm ...

Speicherst du nun die Mails pro Kunde in eine Tabelle oder was genau hast du damit vor :)
Mails pro Kunde hatten wir ja schonmal gesprochen das dies Sinvoll wäre...
 
Nach dem Update erhalten wir diese Meldung:

Die DB ist außerdem nicht erreichbar (Database Error).

Ausserdem werden in den b1gMail-logs jede Menge Fehlermeldungen geschrieben.
 

Attachments

  • DB-fehler.jpg
    DB-fehler.jpg
    42.6 KB · Views: 230
Sagt mal... Die Datenbank von euch ist ja bei solchen Updates öfters überfordert, weil sehr viele Daten verändert werden müssen. Wie sehen die Änderungen meistens aus? Konkret meine ich: Ist es theoretisch möglich, nach den Änderungen noch mit der alten Version von b1gmail und b1gmail-Server zu arbeiten? Wenn ja (z.B. weil nur neue Tabellen erstellt oder aber Nutzer-Daten erweitert werden), dann wäre es vielleicht sinnvoll, über eine Zwischenstufe zwischen der früheren Version und dem Update nachzudenken. Das würde ich mir so vorstellen: Bei einer neuen Version von b1gmail-Server oder eines wichtigen Plugins führt ihr zuerst ein "pre-Update-Script" aus. Das führt alle notwendigen Änderungen an der Datenbank aus und zwar ohne dabei gleich die gesamten System-Ressourcen zu belegen. Wenn es nach ein paar Stunden oder Tagen fertig ist, könnt ihr ohne Unterbrechung das eigentliche Update einspielen. Oder beziehen sich die Probleme eher auf Dinge, die man nicht im Voraus erledigen könnte?
 
Die Datenbank ist damit nicht überfordert @möp. Der Punkt ist aktuell, dass beim Update des b1gMailServers eine neue Tabelle angelegt wird und dort Millionen von Datensätzen geschrieben/kopiert o.ä. werden (zumindest bei uns).

In solchen Fällen erwarte ich als Kunde eigentlich, dass Entwicklungsseitig an sowas gedacht wird und - wie du es beschreibst - eine Lösung gibt, die den normalen Betrieb nicht behindert.

Weder in der Dokumentation, noch im changelog stand etwas davon, dass der Vorgang sehr lange dauern kann. Dann hätten wir das Update aufs WE oder einen anderen Termin verlegt.

Wir haben heut gegen 15:45 Uhr damit angefangen, das Update ist immer noch nicht fertig. Man muss sich dann auch noch in den sozialen Medien blöde anreden lassen, weil das System nicht nutzbar ist.

Heute bin ich echt mal sauer.. und das kommt selten vor X(
 
Hallo, wenn man nicht nur 10000 Einträge hat sondern 10 Mio Einträge hat oder 100 Mio und mehr dann hilft auch ein CloudServer mit 16 Quadcore und 12 SSD HDDs nichts mehr denn die DB Struktur wurde bei diesem Update irgendwie geändert und es wird irgendwas von einer in eine neue Tabelle kopiert. Dauert nun schon seit frühen Nachmittag an und rennt auf Vollast dann wieder nur HDD Read Write dann wieder Vollast etc. So toll ist das nicht da in dieser Zeit der SQL kaum erreichbar ist bzw. garnicht und der Slave das selbe macht da er sich ja abgleicht. Also auch keine Lösung. Leider stand von dieser Updateroutine auch nichts im Changelog sonst hätten wir alle betroffenen Server mit großen Datenbanken Nachts geupdatet. Wenn man überlegt das noch pro Minute im ~ 100.000 - 250.000 neue Einträge dazu kommen und dann noch die regulären Nutzer versuchen zuzugreifen dann weis man das nichts mehr geht wenn die DB schon voll ausgelastet ist. Dieses update ist also nicht so schön beschrieben und durchführbar, zumindest nicht auf großen Systemen.


In der DB stehen zich 1000 Zeilen damit drin:

Sorting result
SELECT GROUP_CONCAT(bm60_mails.`id` SEPARATOR ',') AS mailIDs,SUM(bm60_mails.`size`) AS mailSizes,bm ..
und
Waiting for table metadata lock
LOCK TABLES bm60_bms_imapuid WRITE
und
Waiting for table metadata lock
SELECT flags,fetched,LENGTH(body),id,datum,size,imapuid FROM bm60_mails LEFT JOIN bm60_bms_imapuid O
und
Sorting result
SELECT GROUP_CONCAT(bm60_mails.`id` SEPARATOR ',') AS mailIDs,SUM(bm60_mails.`size`) AS mailSizes,bm
und
Writing to net
SELECT flags,fetched,LENGTH(body),id,datum,size,imapuid FROM bm60_mails LEFT JOIN bm60_bms_imapuid O
und
Sending data
SELECT flags,fetched,LENGTH(body),id,datum,size,imapuid FROM bm60_mails LEFT JOIN bm60_bms_imapuid O

Habe jetzt meine queue erst mal angehalten, damit nicht nochmehr aufläuft... Evtl. gibts ja eine Lösung durch Patrick oder so...
 
Last edited:
Nach ca. 7h ist nun alles fertig. Also Update dauert bei ~50Mio Mail-Einträge ca. 7h wenn bms aus ist. Für die die größere Systeme haben :)
Bei den ganz großen lass ichs über Nacht laufen^^ Da habt Ihr wenigstens schonmal ein paar Anhaltspunkte...
MfG :]
 
Hallo,

das Update ist hier ein Sonderfall, da sich die IMAP-UID-Indizierung geändert hat und wir nun die Cache-Tabelle (bm60_bms_imapuid) brauchen, um Eigenheiten von Outlooks IMAP-Support zu unterstützen. Das ist eine einmalige Sache, die sich leider nicht anders lösen ließ. In der Zeit muss die bm60_mails-Tabelle gelockt werden, um einen konsistenten Datenstand zu gewährleisten. Daher sind andere Queries betreffend dieser Tabelle nicht möglich und werden von MySQL gequeued.

Wir haben das erst in einer Vorabversion ohne diese Tabelle gelöst, indem wir die IMAP-UIDVALIDITY erhöht haben. Das ist laut Standard erlaubt, hat in unseren Tests aber bei einigen Android-Clients zu tausenden falsch synchronisierten Mails geführt, da diese Clients darauf nicht vorbereitet sind. Wir haben uns daher für die sichere Lösung entschieden, auch wenn sie eine neue Tabelle erfordert, in die alle Mail-IDs dupliziert werden.

Bei 50 Mio. E-Mails ist das eine Datenmenge von grob 50 Mio * 8 Byte, also 381 MB. Mich wundert, dass das bei euch so lange gedauert hat. Ich habe das natürlich vorher auch für große Installationen überschlagen, hätte aber mit einer Transferzeit von unter 5 Minuten gerechnet. Vielleicht ist die bm60_mails-Tabelle bei euch sehr stark fragmentiert. Hier sind übrigens nicht Anzahl der Cores der Flaschenhals, sondern höchstwahrscheinlich die I/O-Geschwindigkeit.

Da hilft dann leider nur abwarten. Belohnt wird man aber mit einem wesentlich flüssigeren und stabileren IMAP-Support bei Verwendung von Outlook und einer besseren Standardkompatibilität.

Ich stimme dir aber zu, SLM, das dies hätte in den Release Notes erwähnt werden müssen. Ich hatte einfach nicht gedacht, dass es so lange dauern würde, da meine lokalen Tests Anderes gezeigt hatten. In dieser Hinsicht bitte ich um Entschuldigung; künftig wird sowas Erwähnung finden.
 
Last edited:
PS: das Apple zert bekommsch das auch wennch im Shop bei Apple das System kaufe und auf ne VM installiere - oder brauch ich zwingend nen MAC?
Click to expand...
Wenn du eine VM mit aktueller OS-X-Version hast und funktionierendem App Store, sollte das auch gehen. Ob das in Einklang mit Apples AGB steht, kann ich aber nicht beurteilen.
 
@Patrick: Danke für die Info. Die Tabelle ist nicht fragmentiert. Woran das lag kann nur vermutet werden.

Habt ihr das im laufenden Betrieb getestet? Also mit Mails, die eintreffen und verarbeitet werden? Im laufenden Betrieb ist es nicht möglich, die Queue 7 Stunden zu stoppen, geschweige denn, den Wartungsmodus für diese Dauer zu aktivieren. Hierzu auch meine Vorschlag: http://board.b1gmail.com/project.php?issueid=1749

2. Wir hatten mal geschrieben bezügl. der Warteschleifen-Anzeige im bg1Mailserver-Plugin, bei Installation auf einem externen Server (funktioniert ja derzeit nicht). Ist das noch in der Pipeline?
 
Hallo zusammen,
ich bekomme nach dem Update nun auch die Meldung wenn ich bms-queue starten möchte
MySQL: Unknown column 'imap_uids_initialized' in 'field list'
Click to expand...

Da meine Installation aber doch verhältnismäßig zu eurer relativ klein mit wenigen Usern & Mails ist dachte ich mir beim Update nichts.

Laut Update-Assistenten ist das Update auch erfolgreich und fertig, beim starten bekomme ich dennoch weiterhin diese Meldung.
Muss hier noch was extra ausgeführt werden oder ist beim Update irgendwas schief gegangen?

Danke schonmal!

EDIT: Ok, nach Deinstallation und erneuerte Installation vom Adminplugin funktionierts wieder!
 
Last edited:
You must log in or register to reply here.
Back
Top