Probleme mit Zarafa nach Update auf 7.2.3.657

Hallo allerseits,

nach der Installation des neu verfügbaren Updates auf Version 7.2.3.657 funktioniert Zarafa nicht mehr wie vorgesehen.

Das Update ließ sich einwandfrei installieren und schien auch in den Log-Dateien keine näheren Probleme zu benennen. Beim Versuch, per WebApp eine Email mit Anhang zu öffnen erschien folgende Fehlermeldung:
{“success”:false,“zarafa”:{“error”:{“type”:1,“info”:{“hresult”:-2147221233,“hresult_name”:“MAPI_E_NOT_FOUND”,“file”:“download_attachment.php:313”,“display_message”:“Der Anhang konnte nicht gefunden werden.”}}}}

Per Outlook ließen sich Anhänge ebenfalls nicht mehr öffnen.

Darüber traten verschiedene weitere Probleme auf, laut meinem Überblick konnten teils nicht einmal mehr aktuelle Emails per Fetchmail abgerufen bzw. abgelegt werden. Der Speicherort für Anhänge ist bei meiner Zarafa-Installation “files”, der in der server.cfg genannte Pfad ist “attachment_path = /var/lib/zarafa/attachments”. Dies funktionierte vorher einwandfrei.

Ein vorheriger Blick in den Changelog gab schon an, dass Zarafa zukünftig nach einem erfolgreichen Start nicht mehr als root sondern als Nutzer “zarafa” ausgeführt würde. Dies ist auch die Quelle des Problems, da Zarafa anschließend die Lese- / Schreibrechte für bestimmte Pfade fehlen.

Das Zarafa-Manual empfiehlt lediglich folgende Befehle:
chown zarafa:zarafa /var/log/zarafa
chown zarafa:zarafa /etc/zarafa/report
chown -R zarafa:zarafa /var/lib/zarafa

Dies scheint jedoch nicht auszureichen, das System funktionierte nach wie vor nicht. Als Workaround habe ich nun die UCS-Variablen “zarafa/cfg/server/run_as_group” und “zarafa/cfg/server/run_as_user” vom empfohlenen Wert “zarafa” auf (leer) gesetzt. Hierdurch wird der Server wieder wie vorher als root ausgeführt.

Wieso stellt Univention ein Update bereit, welches offenbar die notwendigen Dateisystemzugriffsrechte nicht anpasst? Was wäre eine dauerhafte Lösung für die Problematik, so dass wieder auf den Nutzer zarafa zurückgegriffen werden kann?

Hallo ikue,

[quote=“ikue”]
Wieso stellt Univention ein Update bereit, welches offenbar die notwendigen Dateisystemzugriffsrechte nicht anpasst? [/quote]

Das stimmt so nicht. Das Integrationpaket führt folgendes aus, womit die Rechte entsprechend gesetzt werden:

# Set correct permissions for conf and socket files
owner=$(ucr get zarafa/cfg/server/run_as_user)
group=$(ucr get zarafa/cfg/server/run_as_group)

chown -R ${owner}:${group} /etc/zarafa
chown -R ${owner}:${group} /var/lib/zarafa

Wenn aber der Server selbst bei manuell angepassten Rechten nicht funktioniert, dann würde ich ein weitergehendes Problem vermuten. Sollte eine Zarafa/Kopano Subskription vorhanden sein würde ich empfehlen einen Support Case zu öffnen, damit jemand aufs System schauen kann. Sollte keine Subskription vorhanden sein brauchen wir hier mehr Logs (inkl. Ausgaben von ps, aktuelle Rechte von var/lib/zarafa, etc).

Hallo fbartels,

danke für die schnelle Rückmeldung. Ich habe das ganze nun weiter beobachtet:

Ein manuelles Auslösen des Befehls “chown -R zarafa:zarafa /var/log/zarafa” (fehlte dies dann im Integrationspaket?) löste zumindest das Problem, dass Zarafa wieder in seine Log-Dateien schreiben konnte.

Nach wie vor treten aber seit dem Update verschiedene Probleme auf:

  • Ein wiederholtes “Disconnect from LDAP because of search error Can’t contact LDAP server” in der “/var/log/zarafa/server.log” nachdem der Server mittlerweile erfolgreich gestartet wird (Häufigkeit unregelmäßig, aber oft)

  • Viel problematischer: Emails werden den Nutzern nicht mehr zugestellt, obwohl sie von Fetchmail abgerufen werden. Konkret wirkt es fast so, als wenn zwei Instanzen von Fetchmail aktiv wären und unabhängig voneinander abrufen, da die Verfolgung des Logs “/var/log/mail.log” ganz selten mal eine Email findet, obwohl verschiedene Testmails eingetroffen sein müssten auf dem externen IMAP-Server.

Das Versenden und Empfangen von Emails intern funktionioniert, das Versenden von Emails nach extern ebenfalls. Nur der Empfang klappt nicht mehr seit dem Update.

Gibt es eine Möglichkeit, dass durch die neue Rechtesituation Fetchmail doppelt gestartet wird? Kann es sein, dass der zarafa-dagent nicht mehr funktioniert? Die Logdateien geben leider keine Hinweise, ich habe alle relevanten Pfade über einen längeren Zeitraum beobachtet. Die Emails werden still abgerufen und scheinen zu verschwinden.

Ist es normal, dass ps folgende Prozessliste ausgibt?

root@red2:/var/lib/zarafa# ps aux | grep zarafa
zarafa 4702 0.0 0.0 146976 9188 ? Sl Mai26 0:00 /usr/sbin/zarafa-dagent -d -c /etc/zarafa/dagent.cfg
zarafa 4704 0.0 0.0 131484 4864 ? Sl Mai26 0:00 /usr/sbin/zarafa-dagent -d -c /etc/zarafa/dagent.cfg
zarafa 4734 0.0 0.0 119724 7932 ? S Mai26 0:00 /usr/sbin/zarafa-gateway -c /etc/zarafa/gateway.cfg
zarafa 4736 0.0 0.0 112428 4368 ? Sl Mai26 0:00 /usr/sbin/zarafa-gateway -c /etc/zarafa/gateway.cfg
zarafa 4766 0.0 0.0 112716 7724 ? S Mai26 0:00 /usr/sbin/zarafa-ical -c /etc/zarafa/ical.cfg
zarafa 4768 0.0 0.0 105420 3612 ? Sl Mai26 0:00 /usr/sbin/zarafa-ical -c /etc/zarafa/ical.cfg
zarafa 4797 0.0 0.0 200104 9348 ? Sl Mai26 0:01 /usr/sbin/zarafa-licensed -c /etc/zarafa/licensed.cfg
zarafa 4827 0.0 0.0 183260 11036 ? Sl Mai26 0:01 /usr/sbin/zarafa-monitor -c /etc/zarafa/monitor.cfg
zarafa 4858 0.4 0.2 269732 48496 ? Sl Mai26 3:05 /usr/bin/python /usr/sbin/zarafa-search -c /etc/zarafa/search.cfg
zarafa 4921 0.0 0.0 156920 13316 ? Sl Mai26 0:02 /usr/sbin/zarafa-spooler -c /etc/zarafa/spooler.cfg
zarafa 4923 0.0 0.0 131412 5088 ? Sl Mai26 0:00 /usr/sbin/zarafa-spooler -c /etc/zarafa/spooler.cfg
zarafa 5491 0.0 0.2 268660 33220 ? Sl Mai26 0:18 /usr/bin/python /usr/sbin/zarafa-search -c /etc/zarafa/search.cfg
zarafa 5492 0.0 0.1 190760 17728 ? Sl Mai26 0:00 /usr/bin/python /usr/sbin/zarafa-search -c /etc/zarafa/search.cfg
root 24476 0.0 0.0 7052 496 pts/1 S+ 10:22 0:00 tail -f /var/log/zarafa/server.log
root 24867 0.0 0.0 11320 2040 pts/0 S+ 10:30 0:00 grep zarafa

Für mich sieht das so aus, als wenn manche Prozesse doppelt gestartet wären. Kann das sein?

Hmmm… da könnte was dran sein. Bei meinen Testsystemen ist dies zwar überall korrekt gesetzt, ich finde aber gerade nicht die Stelle an welcher der Ordner gesetzt wird.

Dies kann ignoriert werden, das kann in vorherigen Versionen auch beobachtet werden und heißt nichts weiteres als “libldap hat die Verbindung geschlossen, zarafa-server musste eine neue aufmachen”.

[quote=“ikue”]
Gibt es eine Möglichkeit, dass durch die neue Rechtesituation Fetchmail doppelt gestartet wird? Kann es sein, dass der zarafa-dagent nicht mehr funktioniert? Die Logdateien geben leider keine Hinweise, ich habe alle relevanten Pfade über einen längeren Zeitraum beobachtet. Die Emails werden still abgerufen und scheinen zu verschwinden.[/quote]
Das Fetchmail Paket bei Univention liefert afaik Mails per smtp an den lokalen Mailserver, daher gibt es nicht wirklich eine Möglichkeit wie eine Änderung auf Dateieebene am zarafa-dagent zu verschwundenen Mails führen kann (besonders wenn zarafa-dagent ansonsten Mails problemlos empfangen kann).

EDIT: das mit den doppelt unter ps gelisteten Prozessen ist normal.

Danke für die Rückmeldung. Ich habe das Problem nun weitestgehend im Griff.

Nach weiterer Beobachtung konnten zuletzt Emails ohne Anhang abgerufen und in die Zarafa-Postfächer zugestellt werden, jene mit Anhang hingegen nicht. Das brauchte mich darauf, dass offenbar die Zugriffsrechte für den Verzeichnisordner /var/lib/zarafa/attachments noch nicht in Ordnung waren. Ich habe diese dann wie folgt angepasst:

find /var/lib/zarafa/attachments -type f -exec chmod 660 {} ;
find /var/lib/zarafa/attachments -type d -exec chmod 770 {} ;

Sind diese Rechte empfehlenswert oder gebe ich hier unnötig was frei?

Seitdem funktioniert die Mailzustellung wieder, die alten Emails welche früher per Fetchmail abgerufen wurden sind jedoch nicht wieder aufgetaucht. Konkret liegt also Datenverlust vor und ich habe keine Vorstellung davon, wo solche Daten zwischengespeichert würden. Neben konkreten Nutzmails sind auch diverse Testmails in der Verarbeitung zwischen Fetchmail und dagent verschwunden.

Nach dem Anpassen der oben genannten Verzeichnis- / Dateirechte sind die Logs nun in Ordnung, neben der vorher genannten Meldung “Disconnect from LDAP because of search error …” taucht allerdings noch folgendes in der Logdatei “/var/log/mail.warn” wiederholt auf:

fetchmail[8077]: connection to localhost:smtp [::1/25] failed: Connection refused.

Wenn man dann in die “/var/log/mail.log” hineinschaut gibt es zugehörig folgende Meldung beim zyklischen Fetchmail-Abruf:

fetchmail[8077]: connection to localhost:smtp [::1/25] failed: Connection refused.
fetchmail[8077]: Trying to connect to 127.0.0.1/25…connected.

Offenbar bricht ein erster Verbindungsversuch also ab und wird dann über die konkrete localhost-Adresse 127.0.0.1 noch einmal erfolgreich durchgeführt.

In welchen Einstellungen müsste man die Parameter ändern, um dieses Verhalten abzustellen?

Hättest du vielleicht noch eine Idee, wo die verschwundenen, von Fetchmail abgerufenen aber nicht zugestellten Emails zwischengespeichert sein könnten?

Welche Version des zarafa4ucs Paketes ist denn eigentlich installiert? Kann es sein, dass das Test Appcenter zufällig aktiv ist?

ZCP 7.2.3.657
Z-Push for Zarafa 2.2.9
Zarafa WebApp 2.2.0.414

Ich habe eine Zarafa-Subscription für 15 Anwender gekauft und installiert, diese wird im Lizenzprotokoll auch als gültig erkannt.

Das ist löblich. Ich meinte aber die Ausgabe von “dpkg -l | grep zarafa4ucs”

Dann gerne auch das:

root@red2:~# dpkg -l | grep zarafa4ucs
ii zarafa4ucs 7.2.1000-8.111.201605181051 all Zarafa4ucs integration package for Univention Corporate Server
ii zarafa4ucs-lib 7.2.1000-8.111.201605181051 all Library package for common Zarafa4ucs functions
ii zarafa4ucs-schema 7.2.1000-8.111.201605181051 all LDAP schema for the Zarafa4ucs integration
ii zarafa4ucs-udm 7.2.1000-8.111.201605181051 all UDM extensions for the Zarafa4ucs integration
ii zarafa4ucs-webapp 7.2.1000-8.111.201605181051 all Zarafa4ucs zarafa-webapp integration package for Univention Corporate Server

Hi,

ich hatte gestern versucht das beschriebene Verhalten zu reproduzieren hatte dabei aber keinen Erfolg. Für mich klingt es ein wenig so, als wenn beim ursprünglichen Update dpkg unterbrochen wurde und daher das zarafa4ucs Paket nicht korrekt installiert wurde.

Sofern die entsprechenden Nachrichten nicht mehr in der Mailqueue des MTA liegen gibt es (leider) keinen Weg eine erneute Zustellung auszulösen.

Ich habe gerade gesehen, dass es nun ein neues Release “7.2.3.657-r2” gibt - leider finde ich keinen Changelog dazu.

Was sind genau die Änderungen und betreffen sie evtl. die oben genannten Punkte?

Hallo,

ein Changelog sollte angezeigt werden, wenn das App Update eingespielt wird. Hauptsächlich wird in dem Update ein Problem behoben, dass bei einer Neuinstallation von Zarafa 7.2.3.657 nicht alle Zarafa Dienste beim Systemstart gestartet wurden. Ein chown auf /var/log/zarafa hat aber ebenfalls den Weg in das Update gefunden.

Mastodon