Hallo, danke für die umfangreichen Infos. Da der Kopano Server startet, sieht zunächst alles erstmal okay aus. Das kopano-server.log zeigt keine Fehler, vermutlich läuft der Dienst anscheinend ja. Da sie sagen, der MySQL Server startet nicht, würde ich zunächst einmal mit systemctl status mysql.service den aktuellen Status abfragen und danach eine Abfrage starten: mysql -uroot -p$(</etc/mysql.secret) -e "use kopano; show tables;".
Wenn sich jetzt am Status nichts geändert hat, der Login in die WebApp also immer noch klappt, sollte man als nächstes beim Versand einer Testmail ein Auge auf die Kopano Logs unter /var/log/kopano/*.log und /var/log/mail.log werfen.
Versand und Empfang stehen immer noch aber Mysql läuft wieder.
Die Logs geben für mich wenig her. Im Spooler steht
aber das weiss ich ja bereits
das irritiert mich da ich bisher davon ausging daß der “Original-USC” maildienst vom Kopano abgeschaltet wird und Postfix aussen vor bleibt.
Welche Ports werden vom Kopano genutzt? Ist das nicht 587 für SMTP? Kann ich den Port in den Variablen von UCS/Web setzen?
die tables vom Kopano in Mysql sagen mir leider nicht:
es wäre besser, wenn Sie anstelle von Screenshots die entsprechenden Logdateien bzw. Bildschirmausgaben via copy & paste übertragen würden. Das würde mir jetzt z.B. erleichtern, via copy & paste bestimmte Logmeldungen zu zitieren und dadurch klarer zu machen. Danke
Dann: der Postfix startet nicht und sagt auch warum: weil seine Variable mailbox_size_limit kleiner als die message_size_limit ist. Für beides gibt es UCR-Variablen: mail/localmailboxsizelimit für mailbox_size_limit und mail/messagesizelimit für message_size_limit. Schauen Sie sich an, was ucr search 'mail/.*limit' ausgibt, lesen Sie die Erläuterungen, setzen Sie die Werte richtig. Anschließend Postfix neu starten: systemctl start postfix.service
Ein anschließender Blick in /var/log/mail.log und/oder systemctl status postfix.service sollte Aufschluss geben, ob es läuft.
tja, wenn es denn so einfach wäre.
Die Meldung hatte ich natürlich gelesen und als erstes entsprechende Werte eingetragen, jedoch ohne Ergebnis. Also zurück auf die Standard-Einstellung.
Und die sollten nach den angegebenen Parametern richtig sein:
mail/antispam/bodysizelimit: 300
E-mails which are bigger than the size in kilobytes configured here are not checked by the spam detection.
mail/localmailboxsizelimit: <empty>
This variable configures the maximum size in bytes of mailbox or Maildir files. If the variable is unset, a limit of 51200000 (~51M) byte applies.
mail/messagesizelimit: 102400000
This variable can be used to set the maximum size in bytes for incoming and outgoing e-mails. Please note that e-mail attachments are enlarged by approximately a third due to the base64 encoding. The default is 10240000 (~10M) byte.
Danach sollte die Mailbox mit >50M also die Messagegröße von 10M deutlich übersteigen.
Nochmal meine Frage: ist Postfix mit den Einstellungen via UCS/mail überhaupt zuständig? Sollte das alles nicht vom Kopano-Container kassiert/ überschrieben werden?
und sorry wg der screenshots: das ist für mich leichter zu protokollieren weil ich solchen DesasterThreads immer einProtokoll anfüge damit Lösungswege nachvollziehbar bleiben.
Aber klar lassen sich die Texte via c&p übertragen. Werde mich daran halten.
Dieser Wert sind 100 MB (bzw. ~ 97,65 MB), nicht 10. Da ist eine 0 mehr als gedacht Im Zweifelsfall hat Postfix immer Recht
Ja, Postfix ist zuständig. Kopano stellt nur den Mailserver und damit die Protokolle IMAP, POP3, MAPI, ActiveSync, CalDAV. Der Transport der Mail wird dem normalen Univention-Mail-Stack überlassen. Und der reguläre MTA (Mail Transport Agent) dort ist Postfix.
Es laufen im Normalfall alle Mails durch Postfix, selbst diejenigen, die rein interner Natur sind, selbst diejenigen, die z.B. in der Kopano Webapp geschrieben werden (Webapp → Spooler kopano-spooler → via SMTP an Postfix → potenziell an Anti-Viren-/Anti-Spam-Lösung Amavis und zurück zu Postfix → via LMTP an Kopano Delivery Agent kopano-dagent → Kopano Server → Datenbank).
Das ist auch der einzig vernünftige Weg, denn nur so kann sichergestellt werden, dass zentrale Maildienste die z.B. Anti-Viren-/Anti-Spam-Scans oder auch rechtssichere Archivierung an einer zentralen Stelle angedockt werden können, und diese Stelle ist der MTA, Postfix.
Das hier beschriebene Problem hat m.E. nicht ursächlich mit dem Upgrade auf UCS 4.3 zu tun. Es ist so schon seit etlichen Jahren vorhanden, siehe z.B. https://forge.univention.org/bugzilla/show_bug.cgi?id=30971. Allerdings scheint mir, dass der genannte Bug deswegen geschlossen wurde, weil die Auswirkungen gerade bei z.B. Kopano nicht vollständig durchdacht wurden.
ob dass update die Ursache ist will ich gar niicht behaupten, aber bis zum update lief alles planmäßig. Entsprechend habe ich dies als ursächlich betrachtet.
Und hierzu noch ein Beitrag von der Kopano-Liste vor 6 Tg:
We’ll have to wait for UCS 4.3 to be available on the Open Build System to build official packages. Until then you should be able to use the Debian 9 packages. These are also in the app repository (and should be configured by kopano4ucs).
Ich erinnere mich an den Schwenk von Horde zu Kopano. Damals wurde die komplette UCS-Konfig zum Thema Mail ausser Kraft gesetzt. Soweit aus meiner Erinnerung.
Neues aus dem kopano/server.log
Tue Mar 20 08:51:11 2018: [warning] SQL [00000053] info: Try to reconnect Tue Mar 20 09:00:04 2018: [error ] LDAP search error: Can’t contact LDAP server. Will unbind, reconnect and retry.
der mysqld läuft und meldet keine Fehler. Merkwürdigerweise sind aber via Kopano-WebApp alle Mails bis zum Diskonnect erhalten, einschl. der Userdaten.
Zusammen mit der Ldap Meldung habe ich eine Ahnung dass der Kopano-Container vollkommen abgekoppelt läuft. Wie bringe ich diesen wieder auf die Spur.
haben Sie jetzt Ihre Postfix-Konfiguration gefixt oder nicht? Denn wenn Postfix nicht läuft, dann bekommen Sie keine Mails, völlig egal, ob Kopano läuft oder nicht. Und das ist schlicht der nächste Schritt beim Debuggen: dafür sorgen, dass Postfix läuft, anschließend Test-Mail direkt auf dem System erzeugen (z.B. mit swaks, ein wunderbares SMTP-Debugging-Tool) und schauen, was dann im mail.log steht. Anhand der Meldungen kann man dann weitersehen, woran es liegt.
Na dann schicken Sie bitte eine Test-Mail und posten, was genau in der mail.log dann steht, damit wir einen Anhaltspunkt haben, was da gerade passiert. Sinnvollerweise können Sie dafür das Tool swaks installieren (zuerst das unmaintained-Repository aktivieren, dann apt install swaks), anschließend z.B. mit swaks --from ich@domain.de --to ich@domain.de --server 127.0.0.1 eine verschicken. Natürlich mit richtigen Absender- und Zieladressen.
Mar 20 08:49:54 uni postfix/local[13292]: D1A7713ED05: to=<systemmail@uni.address.tld>, orig_to=<root@uni.address.tld>, relay=local, delay=396504, delays=382335/14166/0/3, dsn=2.0.0, status=sent (delivered to mailbox)
Mar 20 08:49:54 uni postfix/qmgr[9199]: D1A7713ED05: removed
das sagt mir daß die mail in der mailbox abgelegt wurde. Dort steht nun ein php Fehler.
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20131226/mapi.so' - /usr/lib/php5/20131226/mapi.so: cannot open shared object file: No such file or directory in Unknown on line 0
…und diese mapi.so fehlt! Aber das hat mit dem Versand nichts zu tun. denn das ist eine Systemmeldung via cron. Mails vom Kopano-Account via WebApp bleiben im Spooler.
btw. wie kann die mapi.so verschwinden. Ein Effekt des Updates?
In einer lokalen Mailbox, sprich in einer Datei in /var/spool/mail. Was war denn die Empfängeradresse? Eine eines Benutzers, der in Kopano landen sollte?
Das mit der mapi.so wurde mehrfach hier im Forum erläutert, u.a. hier von mir ausführlich beschrieben (auch wie man es abstellt). Das ist nicht das Problem.
wie gesagt, bitte schicken Sie eine Mail, die in Kopano ankommen sollte. Spezialgeschichten wie Mails von und an root sind erst mal unwichtig. Wenn die normale Einlieferung an Kopano wieder klappt, dann können wir anschließend auch schauen, dass Mails von/an root richtig behandelt werden.
Im Zweifelsfall hat Postfix immer Recht 