UCS Upgrade auf 4.3 => Kopano steht!

Apps & App Center
, , , , ,
#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?

#21

Port 25 ist nun für Postfix per explicitem Eintrag freigeschaltet. Der angebliche Vorgabewert “25” greift nicht.

Versand via swak funktioniert nun,

=== Trying 192.168.0.10:25...
=== Connected to 192.168.0.50.
<-  220 uni.kopanoadr.tld ESMTP Postfix
 -> EHLO uni.kopanoadr.tld
<-  250-uni.kopanoadr.tld
<-  250-PIPELINING
<-  250-SIZE 102400000
<-  250-VRFY
<-  250-ETRN
<-  250-STARTTLS
<-  250-ENHANCEDSTATUSCODES
<-  250-8BITMIME
<-  250 DSN
 -> MAIL FROM:<my.homeadr@kopanoadr.tld>
<-  250 2.1.0 Ok
 -> RCPT TO:<outside@gmx.de>
<-  250 2.1.5 Ok
 -> DATA
<-  354 End data with <CR><LF>.<CR><LF>
 -> Date: Thu, 22 Mar 2018 10:15:06 +0100
 -> To: outside@gmx.de
 -> From: my.homeadr@kopanoadr.tld
 -> Subject: test Thu, 22 Mar 2018 10:15:06 +0100
 -> Message-Id: <20180322101506.001386@uni.kopanoadr.tld>
 -> X-Mailer: swaks v20170101.0 jetmore.org/john/code/swaks/
 ->
 -> This is a test mailing
 ->
 -> .
<-  250 2.0.0 Ok: queued as DE8C9140FD1
 -> QUIT
<-  221 2.0.0 Bye
=== Connection closed with remote host.

der Eintrag im mail.log lautet

Mar 22 10:15:07 uni postfix/smtp[1393]: 410FC140FDB: to=<outside@gmx.de>, relay=mx01.emig.gmx.net[212.227.17.5]:25, delay=0.46, delays=0.06/0.02/0.23/0.16, dsn=2.0.0, status=sent (250 Requested mail action okay, completed: id=1MibcN-1eLjXZ2cXH-00f8nY)
Mar 22 10:15:07 uni postfix/qmgr[14641]: 410FC140FDB: removed

Aber in Kopano tut sich im Versand nichts. Eine Erklärung gibt das kopano/server.log

Thu Mar 22 08:53:08 2018: [error  ] Previous message logged 2 times
Thu Mar 22 08:53:08 2018: [warning] SQL [00000256] info: Try to reconnect
Thu Mar 22 09:00:24 2018: [error  ] LDAP search error: Can't contact LDAP server. Will unbind, reconnect and retry.

Wie bringe ich die LDAP Verbindung auf die Reihe?

grtz

Kopano und Upgrade auf 4.3
#22

Neu im kopano/server.log steht nach reload vom kopano-server:

Thu Mar 22 10:55:22 2018: [ notice] Starting kopano-server version 8.4.5.0 (pid 5489)
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'sync_log_all_changes' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'plugin_path' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'thread_stacksize' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'client_update_enabled' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'client_update_path' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'client_update_log_level' is not used anymore.
Thu Mar 22 10:55:22 2018: [warning] Config warning: Option 'client_update_log_path' is not used anymore.
Thu Mar 22 10:55:22 2018: [error  ] Coredumps will not be generated: kopano-server requires the fs.suid_dumpable sysctl to contain the value 2, not 0.

Ist das für das vorliegende Problem relevant?
Darüber hinaus hat sich kopano/search.log gemeldet nachdem über die WebApp ein Versand veranlasst wurde:

2018-03-22 10:55:18,230 - search - ERROR - Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/kopano/log.py", line 87, in log_exc
    try: yield
  File "/usr/lib/python2.7/dist-packages/kopano_search/__init__.py", line 368, in incremental_sync
    new_state = self.server.sync(importer, self.state, log=self.log)
  File "/usr/lib/python2.7/dist-packages/kopano/server.py", line 606, in sync
    return _ics.sync(self, self.mapistore, importer, state, log or self.log, max_changes, window=window, begin=begin, end=end, stats=stats)
  File "/usr/lib/python2.7/dist-packages/kopano/ics.py", line 216, in sync
    exporter.Config(stream, flags, importer, restriction, None, None, 0)
  File "/usr/lib/python2.7/dist-packages/MAPICore.py", line 1900, in Config
    return _MAPICore.IExchangeExportChanges_Config(self, lpStream, ulFlags, lpUnk, lpRestriction, lpIncludeProps, lpExcludeProps, ulBufferSize)
MAPIErrorNetworkError: MAPI error 80040115 (MAPI_E_NETWORK_ERROR)

und das kommt aus dem apache/error.log:

[Thu Mar 22 11:14:56.007407 2018] [mpm_prefork:notice] [pid 29827] AH00163: Apache/2.4.25 (Univention) OpenSSL/1.0.2l configured -- resuming normal operations
[Thu Mar 22 11:14:56.007479 2018] [core:notice] [pid 29827] AH00094: Command line: '/usr/sbin/apache2'
[Thu Mar 22 11:15:06.986484 2018] [autoindex:error] [pid 29830] [client 192.168.0.172:31886] AH01276: Cannot serve directory /var/www/univention/js/umc/: No matching DirectoryIndex (index.html,index.cgi,index.pl,index.php,index.xhtml,index.htm) found, and server-generated directory index forbidden by Options directive, referer: https://192.168.0.50/univention/login/?location=%2Funivention%2Fmanagement%2F%23module%3Dupdater%3A%3A0%3A&lang=de-DE

Und an dieser Stelle sei vermerkt daß bis zum Update auf 4.3 alles klaglos lief. …

Kopano: can´t contact LDAP server
Mastodon