Von Zarafa zu Kopano klappt nicht

Hallo,
ich versuche gerade den Umstieg von Zarafa auf Kopano.
Das entsprechende Wiki habe ich mir durchgelesen.

Ich habe über den Appstore alle Zarafa-Komponenten deinstalliert.
Die Installation von Kopano bricht allerdings immer (ich habe es jetzt 3x probiert) mit folgender Meldung ab:

2 Fehler sind aufgetreten:

/var/cache/apt/archives/python-kopano_8.1.1.10-8.1_all.deb: Versuch, »/usr/share/pyshared/zarafa/__init__.py« zu überschreiben, welches auch in Paket python-zarafa 7.2.5.106-127.1 ist
kopano4ucs: Installation fehlgeschlagen

Kann mir jemand weiterhelfen?

Gruß
Stephan

Hallo StephanT,

in diesem Falle musst du das Paket python-zarafa noch deinstallieren. Danach wird die Installation der App gelingen.

Danke für den Hinweis.
Die Deinstallation hatte ich schon angestoßen, aber sie lief nicht richtig durch. Jetzt hat die Deinstallation von phyton-zarafa aber geklappt.
Die Installation von Kopano lief durch.

Allerdings habe ich jetzt, das Problem, dass man sich als Nutzer an der WebApp nicht anmelden kann:
Fehlermeldung: Logon failed. Please verify your credentials and try again.

Im Server-Log ist folgende Fehlermeldung:

Sun Feb 5 19:52:53 2017: [crit ] Cannot instantiate user plugin: Disallowing NULL password for user cn=server,cn=dc,cn=computers,dc=zuhause,dc=xx
Sun Feb 5 19:52:53 2017: [crit ] Unable to instantiate user plugin
Sun Feb 5 19:52:53 2017: [warning] Failed to authenticate user “Stephan” from “192.168.1.10” using program “apache2”

Kann mir hierzu jemand weiterhelfen?

VG StephanT

Hallo StephanT,

ist das direkt nach der Installation der App, oder nach Abschluss des Migrationsskriptes?

Das sieht ein wenig so aus, als wenn die ldap.cfg nicht korrekt geschrieben wurde (also dort zumindest das Passwort für den LDAP Nutzer fehlt). Kann es zufällig sein, dass du das Test Appcenter aktiv hast?

Hallo,

die Probleme ergeben sich, nachdem das Migrationsskript durchlaufen wurde.
Ich wüsste nicht, dass ich das Test-Appcenter aktiviert habe; ich habe das ganze in meiner Standardumgebung migriert.

Lass dir doch nicht alle Informationen aus der Nase ziehen :wink:

Was sagt den das Migrations Logfile? Wie sieht die ldap.cfg aus?

Das Migrations-Log sieht aus, als ob alles funktioniert hat:
kopano4ucs-migrate.log (206 KB)

Die ldap.cfg ist hier:
ldap.txt (16.9 KB)

Merkwürdig. Eigentlich sollte das Passwort im postinst des kopano4ucs Paketes gesetzt werden. Kannst du einmal das folgende Skript ausführen? Falls das Passwort danach nicht gesetzt ist, bitte dann einmal die Ausgabe mittels “bash -x” posten.

/usr/lib/univention-server/server_password_change.d/70kopano postchange

Hallo,

auch nach ausführen des Scripts ist ein Anmelden unmöglich.
Folgende Ausgabe:

root@server:~# /usr/lib/univention-server/server_password_change.d/70kopano postchange
Setting kopano/cfg/ldap/ldap_bind_passwd
Module: kopano-cfg
Module: zarafa-cfg
dpkg-query: Kein Paket gefunden, das auf kopano4ucs-multiserver passt
[ ok ] Stopping server: kopano-server.
[ ok ] Starting server: kopano-server.

bash-x ergibt folgende Ausgabe:
bash-Ausgabe.txt (63.8 KB)

Nein, nicht die Ausgabe von “bash -x”, sondern die Ausgabe des Skriptes mittels “bash -x”, also “bash -x /usr/lib/univention-server/server_password_change.d/70kopano postchange”

Laut der bisherigen Ausgabe scheint er ja etwas in kopano/cfg/ldap/ldap_bind_passwd ui schreiben, ist die Fehlermeldung im server.log wirklich immer noch die selbe?

Was steht denn in der UCR Variablen kopano/cfg/ldap/ldap_bind_passwd ?

ucr get kopano/cfg/ldap/ldap_bind_passwd

Das sollte normalerweise @&@/etc/kopano-ldap.secret@&@ sein, ansonsten mal auf den Wert setzen

ucr set kopano/cfg/ldap/ldap_bind_passwd='@&@/etc/kopano-ldap.secret@&@'

Kann man sich mit dem Passwort in der Datei auch am LDAP authentifizieren und etwas ausgeben, oder kommt ein Fehler?

ldapsearch -D $(ucr get ldap/hostdn) -y /etc/kopano-ldap.secret

@fbartels:

Die Ausgabe des bash-Befehls ergibt folgendes:
bash.txt (143 Bytes)

Im Server.log steht folgendes:
Server.log (467 Bytes)

@damrose:

Die UCR Variable kopano/cfg/ldap/ldap_bind_passwd ist leer.
Das Setzen de Variablen bringt folgendes Ergebnis:

root@server:~# -bash: @/etc/kopano-ldap.secret@: Datei oder Verzeichnis nicht gefunden
Setting kopano/cfg/ldap/ldap_bind_passwd
Module: kopano-cfg
Module: zarafa-cfg

[1]- Fertig ucr set kopano/cfg/ldap/ldap_bind_passwd=@
[2]+ Exit 127 @/etc/kopano-ldap.secret@

Welche Art von Univention System ist das Setup? Master? Slave? Member?

Es klingt ein wenig so, als wenn es keine /etc/machine.secret gibt.

Das UCS-Sytsem läuft seit ca. 2,5 Jahren problemlos als Master.
Das /etc/machine.secret ist vorhanden.

VG StephanT

Dann bitte einmal das folgende ausführen (das hätte eigentlich das Change Password Skript machen sollen, mangels bash -x Output kann ich aber nicht sehen, warum das nicht geschehen ist):

cp /etc/machine.secret /etc/kopano-ldap.secret
ucr set kopano/cfg/ldap/ldap_bind_passwd='@&@/etc/kopano-ldap.secret@&@'

Ich habe mir gerade mal noch das var/log/kopano/monitor.log angesehen.
Dort bekomme ich folgende Fehlermeldungen:

Sun Feb 5 18:15:00 2017: [crit ] Unable to open an admin session. Error 0x80040115
Sun Feb 5 18:30:00 2017: [error ] M4LMsgServiceAdmin::ConfigureMsgService() MSGServiceEntry failed 80040115: network error
Sun Feb 5 18:30:00 2017: [crit ] CreateProfileTemp(): ConfigureMsgService failed 80040115: network error
Sun Feb 5 18:30:00 2017: [warning] CreateProfileTemp failed: 80040115: network error
Sun Feb 5 18:30:00 2017: [crit ] Unable to open an admin session. Error 0x80040115
Sun Feb 5 18:30:45 2017: [ notice] Starting kopano-monitor version 8,1,1,10 (10), pid 15439
Sun Feb 5 18:30:50 2017: [crit ] Unable to get userlist for company Default, error code 0x8004010F
Sun Feb 5 18:58:13 2017: [ notice] Starting kopano-monitor version 8,1,1,10 (10), pid 28958
Sun Feb 5 19:00:03 2017: [crit ] Unable to get userlist for company Default, error code 0x8004010F
Sun Feb 5 19:09:07 2017: [ notice] Starting kopano-monitor version 8,1,1,10 (10), pid 5945
Sun Feb 5 19:15:02 2017: [crit ] Unable to get userlist for company Default, error code 0x8004010F
Mon Feb 6 20:15:01 2017: [crit ] Previous message logged 100 times
Mon Feb 6 20:15:01 2017: [crit ] Unable to get userlist for company Default, error code 0x8004010F
Mon Feb 6 21:45:16 2017: Previous message logged 6 times

VIelleicht hilft das ja noch weiter.

Wenn es keine machine.secret gäbe, hätte das password change script einen Fehler ausgeben. Irgendwie ist der Inhalt der UCR Variablen kopano/cfg/ldap/ldap_bind_passwd verloren gegangen. Zusätzlich hatte ich oben einen Fehler in meinen ucr set Befehl eingebaut (jetzt korrigiert), es fehlen die einfachen Anführungszeichen, deshalb klappte es nicht. Bitte noch einmal

ucr set kopano/cfg/ldap/ldap_bind_passwd='@&@/etc/kopano-ldap.secret@&@' service kopano-server restart
ausführen, dann müsste die LDAP Verbindung des servers wieder funktionieren. Falls es nicht klappt, bitte noch einmal den ldapsearch Befehl aus meinem letzten Post absetzen.

Nach dem ucr set-Befehl von damrose kann ich mich bei Kopano anmelden.
Jetzt muss nur noch durch die alten Einstellungen von fetchmail und postfix das Abholen der Mails und zustellen funktionieren.
Das läuft aber noch nicht.

ich habe im server.log noch folgenden Fehler:

Wed Feb 8 10:46:03 2017: [ notice] Starting server version 8,1,1,10, pid 26348
Wed Feb 8 10:47:58 2017: [error ] Error while connecting to search on “file:///var/run/kopano/search.sock”
Wed Feb 8 11:01:30 2017: [error ] Previous message logged 100 times
Wed Feb 8 11:01:30 2017: [error ] Error while connecting to search on “file:///var/run/kopano/search.sock”

Der Server verbindet sich scheinbar noch nicht mit der Datenbank.

Die Meldungungen über den Search Socket sind mit hoher Wahrscheinlichkeit normal, siehe dafür den Notizkasten im Kopano Handbuch: documentation.kopano.io/kopanoc … ch-service

For alles andere braucht es fürchte ich eine ausführlichere Beschreibung und Logfiles.

Bisher wurden die Mail von einem externen Mailserver abgerufen.
Die entsprechenden Einstellungen hierzu finden sich in der UCS-Benutzerverwaltung unter “Mailabruf von externen Mailservern”.
Die Einstellungen in der fetchmailrc sind noch unverändert vorhanden.
Nach der Migration werden allerdings keine Mails an die entpsrechenden Postfächer bei Kopano weitergeleitet.

Ich habe den Server inzwischen auch einmal neu gebootet.

VG

Mastodon