UCS Upgrade auf 4.3 => Kopano steht!

Apps & App Center
, , , , ,
#1

Nach einem Seeehr langen UpgradeLauf ( ca. 2Std) lief das Sstem wieder ohne erkennbare Fehler.

Jedoch: Kopano tut´s nicht mehr.

Status: Core läuft, WebApp ebenso. Alle Mails + User sind nach wie vor da.
Aber kein Empfang und kein Senden mehr.

repo

Die ConfigReg sagt:

ConfigReg

Frage: wo bleibt port 587? Sollte nicht SMTP hier werkeln?
Meine Fehlersuche bisher:

“apt-cache policy mysql-server”

grafik

“systemctl status kopano-server.service”

status_kopanp

“systemctl list-units | grep kopano”

list_units

“dpkg -l | grep kopano”

grafik

nach de/re-install von Core & webapp sagt das server Log:

grafik

systemctl show kopano-server.service

grafik

systemd-analyze critical-chain kopano-server.service

grafik

grafik

und ja, der mysql-server startet nicht!

Ich bin jetzt ratlos. Never touch a…

Kann jemand helfen?

grtz

Kopano und Upgrade auf 4.3
#2

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.

#3

danke für die rasche Antwort.

Versand und Empfang stehen immer noch aber Mysql läuft wieder.

Die Logs geben für mich wenig her. Im Spooler steht

spooler_log

aber das weiss ich ja bereits :frowning:

mail_log

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:

kopano_tables

Ich weiss momentan nicht wo ich bohren soll…

#4

Huhu,

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 :slight_smile:

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.

Gruß
mosu

1 Like
#5

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?

#6

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. :wink:

#7

Huhu,

Dieser Wert sind 100 MB (bzw. ~ 97,65 MB), nicht 10. Da ist eine 0 mehr als gedacht :slight_smile: Im Zweifelsfall hat Postfix immer Recht :grin:

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.

Gruß
mosu

#8

Noch ein Kommentar von meiner Seite dazu:

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.

#9

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

“should” heisst nicht “you are”…

liegt der Hund dort begraben?

#10

leuchtet ein soweit.

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.

#11

Huhu,

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.

Gruß
mosu

#12

ja, habe ich: die mailbox Größe lässt zwar die msg verschwinden & postfix “läuft” aber, wie ich bereits berichtete, ändert sich ansonsten nichts.

#13

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.

#14

im mail.log steht:

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?

#15

Huhu,

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.

#16

Absender war

From: root@uni.address.tld (Cron Daemon)

Das die mapi.so hier nicht relevant ist war schon klar darum hatte ich das nicht weiter verfolgt. Den thread werde ich lesen. Danke hierfür.

#17

Huhu,

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.

Gruß
mosu

#18

tja, die kommen halt nicht im Kopano an.

Versuche gerade swaks zu installieren, jedoch trotz

repository/online/unmaintained yes

im Repo nicht verfügbar.

NACHTRAG: …mein Fehler, hatte updaten vergessen. Läuft jetzt

#19

Nach der Aktivierung muss man einmal die Paketquellen aktualisieren: apt update

#20

swaks sagt:

root@uni:~# swaks --from me@address.tld --to master@gmx.de --server 127.0.0.1
=== Trying 127.0.0.1:25...
*** Error connecting to 127.0.0.1:25:
***     IO::Socket::INET6: connect: Connection refused

warum via port 25? Ich dachte der sei im UCS-mail gesperrt?

Mastodon