Univention Bugzilla – Bug 33462
Debian Paket zarafa4ucs und zarafa4ucs-udm besser Aufbauen
Last modified: 2013-11-21 10:18:41 CET
Guten Tag Wenn man eine Zarafa-Multiserver Umgebung aufbauen möchte, sind die Pakete zarafa4ucs und zarafa4ucs-udm nicht verwendbar. Auf dem DC-Master muss das zarafa-schema und diverse Anpassungen gemacht werden damit die Administration über UMC funktioniert. Nun muss man dazu die 3 Pakete zarafa4ucs zarafa4ucs-udm zarafa4ucs-schema installieren. Das Paket zarafa4ucs will aber die ganzen Zarafa-Paket installieren und den vollumfänglichen Zarafa-Server bereitstellen. Das will man aber nicht. Das Script /usr/lib/univention-install/70zarafa4ucs.inst aus dem Paket zarafa4ucs sollte man in das Paket zarafa4ucs-udm verschieben (etwas kurz beschrieben). So wäre es möglich auf dem DC-Master zwei Pakete zu installieren zarafa4ucs-udm zarafa4ucs-schema. Danach ist das LDAP und die UMC soweit um die Zarafa-Benutzer und Gruppen Informationen im UMC zu verwalten und es muss nicht ein kompletter Zarafa Server installiert worden. Auf einem DC-Slave kann danach das Paket zarafa4ucs installiert werden mit allen Abhängigkeiten, weil man dort den eigentliche Zarafa-Server installieren möchte. Die Aufteilung in den Paketen ist wirklich nicht gut gewählt, es ist auf einen Single-Server-Lösung ausgerichtet. Wenn man so ein Setup mit DC-Master/DC-Backup und einem Zarafa-DC-Slave aufbauen möchte ist das nicht möglich. Welche Gedanken hatte man bei der Deb-Pakete Erstellung? Früher bei den Zarafa6 Paketen für UCS2.4 von linet-services.de war diese Aufteilung besser. Vielen Dank für eine baldigen Antwort/Bearbeitung. Grüsse, RolandB
Vielen Dank für das Feedback. Das Problem kann ich so nicht nachstellen, ich habe eben die Installation über das App-Center auf einem Slave noch einmal ausprobiert (mit UCS 3.2). Dadurch werden automatisch benötigte LDAP-/UDM-Erweiterungen auf Master- und Backup-Systemen installiert: Auf Master sind diese Pakete installiert: zarafa4ucs-schema zarafa4ucs-udm … und auf dem Slave diese hier: zarafa zarafa-client zarafa-common zarafa-contacts zarafa-dagent zarafa-gateway zarafa-ical zarafa-libarchiver zarafa-libs zarafa-licensed zarafa-monitor zarafa-search zarafa-server zarafa-spooler zarafa-utils zarafa-webaccess zarafa-webaccess-muc zarafa-webapp zarafa4ucs zarafa4ucs-schema zarafa4ucs-udm zarafa4ucs-webapp
Könnten Sie bitte zuerst auf dem DC-Master die Pakete installieren (Achtung, natürlich darf auf diesem System noch nie die Zarafa Pakete installiert worden sein): zarafa4ucs-schema zarafa4ucs-udm Danach melden Sie sich beim WebUMC an und werden sehen, es sind keine Zarafa Optionen vorhanden weil diese erst mit dem Paket zarafa4ucs erstellt werden. Diese einmalige Arbeit gehört in das Paket zarafa4ucs-udm weil es sich dort um die udm settings/extended_attribute handelt. Grüsse, RolandB (In reply to Alexander Kläser from comment #1) > Vielen Dank für das Feedback. > > Das Problem kann ich so nicht nachstellen, ich habe eben die Installation > über das App-Center auf einem Slave noch einmal ausprobiert (mit UCS 3.2). > Dadurch werden automatisch benötigte LDAP-/UDM-Erweiterungen auf Master- und > Backup-Systemen installiert: > > Auf Master sind diese Pakete installiert: > zarafa4ucs-schema > zarafa4ucs-udm > > … und auf dem Slave diese hier: > zarafa > zarafa-client > zarafa-common > zarafa-contacts > zarafa-dagent > zarafa-gateway > zarafa-ical > zarafa-libarchiver > zarafa-libs > zarafa-licensed > zarafa-monitor > zarafa-search > zarafa-server > zarafa-spooler > zarafa-utils > zarafa-webaccess > zarafa-webaccess-muc > zarafa-webapp > zarafa4ucs > zarafa4ucs-schema > zarafa4ucs-udm > zarafa4ucs-webapp
(In reply to rolandb from comment #2) > Könnten Sie bitte zuerst auf dem DC-Master die Pakete installieren (Achtung, > natürlich darf auf diesem System noch nie die Zarafa Pakete installiert > worden sein): > zarafa4ucs-schema > zarafa4ucs-udm > > Danach melden Sie sich beim WebUMC an und werden sehen, es sind keine Zarafa > Optionen vorhanden weil diese erst mit dem Paket zarafa4ucs erstellt werden. > Diese einmalige Arbeit gehört in das Paket zarafa4ucs-udm weil es sich dort > um die udm settings/extended_attribute handelt. Ja, das ist richtig, wenn ich mich direkt am Master anmelde, sind keine Zarafa-Optionen zu sehen. Werden allerdings die noch ausstehenden Zarafa-Join-Skripte auf dem Slave ausgeführt, sind nach einem (Logout +) Login auf dem Master die Optionen zu sehen.
Ich habe einen neuen Bug angelegt, damit ggf. Join-Skripte direkt ausgeführt werden nach einer App-Installation. Ich würde damit diesen Bug als Duplikat schließen. Bitte Bescheid geben, wenn ein anderer Grund diesem Problem zugrunde lag. Vielen Dank und beste Grüße! *** This bug has been marked as a duplicate of bug 33496 ***
(In reply to Alexander Kläser from comment #4) > Ich habe einen neuen Bug angelegt, damit ggf. Join-Skripte direkt ausgeführt > werden nach einer App-Installation. Ich würde damit diesen Bug als Duplikat > schließen. Bitte Bescheid geben, wenn ein anderer Grund diesem Problem > zugrunde lag. > > Vielen Dank und beste Grüße! > > *** This bug has been marked as a duplicate of bug 33496 *** Ich möchte hier nochmals eine Erklärung abliefern. Wenn man Univention als Benutzer/Gruppen Backend für Zarafa verwendet und der Zarafa-Groupware Server nicht auf einem Univention installiert ist, also auf einer Distrubition. Dann gibt es mit dieser Paketierung Probleme. Diese Situation haben wir momentan, weil eine Windows-AD als Zarafa-Backend geben Univention-LDAP-Backend getauscht wird, aber der Zarafa Server ist auf Debian installiert. Bei dieser Situation wollten wir die 2 Pakete zarafa4ucs-udm zarafa4ucs-schema installieren und wir haben danach gemerkt, dass die UDM Erweiterungen nur mit dem Paket zarafa4ucs komplett installiert sind. Das Paket zarafa4ucs zieht aber mit den Abhängigkeiten den kompletten Zarafa-Groupware Server mit sich. Diese Situation würde sich korrekt lösen, wenn man das Script /usr/lib/univention-install/70zarafa4ucs.inst in das Paket zarafa4ucs-udm verlagern würde. Nun sollte allen klar sein, warum ich eine Anpassung der Paket vorschlage. Für alle anderen Installation Varianten spielt eine solche Anpassung keine Role. Vielen Dank für ein kurze Antwort.
(In reply to rolandb from comment #5) > (In reply to Alexander Kläser from comment #4) > > Ich habe einen neuen Bug angelegt, damit ggf. Join-Skripte direkt ausgeführt > > werden nach einer App-Installation. Ich würde damit diesen Bug als Duplikat > > schließen. Bitte Bescheid geben, wenn ein anderer Grund diesem Problem > > zugrunde lag. > > > > Vielen Dank und beste Grüße! > > > > *** This bug has been marked as a duplicate of bug 33496 *** > > Ich möchte hier nochmals eine Erklärung abliefern. Wenn man Univention als > Benutzer/Gruppen Backend für Zarafa verwendet und der Zarafa-Groupware > Server nicht auf einem Univention installiert ist, also auf einer > Distrubition. > Dann gibt es mit dieser Paketierung Probleme. Diese Situation haben wir > momentan, weil eine Windows-AD als Zarafa-Backend geben > Univention-LDAP-Backend getauscht wird, aber der Zarafa Server ist auf > Debian installiert. Dann am besten UCS als Zarafa Server verwenden oder die Extended Attributes manuell anlegen. Ganz langfristig werden wir die Pakete vermutlich auf ucs_registerLDAPExtension umstellen. Dadurch wird man bei einer Slave Installation keine Pakete mehr auf dem Master installieren: http://docs.univention.de/developer-reference-3.2.html#settings:ldapschema http://docs.univention.de/developer-reference-3.2.html#settings:udm_module
(In reply to Stefan Gohmann from comment #6) > Dann am besten UCS als Zarafa Server verwenden oder die Extended Attributes > manuell anlegen. > > Ganz langfristig werden wir die Pakete vermutlich auf > ucs_registerLDAPExtension umstellen. Dadurch wird man bei einer Slave > Installation keine Pakete mehr auf dem Master installieren: > http://docs.univention.de/developer-reference-3.2.html#settings:ldapschema > http://docs.univention.de/developer-reference-3.2.html#settings:udm_module Vielen Dank für die Antwort, doch leider bestimmt immer noch der Kunde was als Distribution verwendet werden muss. Und damit Univention als Backend attraktiv bleibt, würde ich meine Hinweise beherzigen. Sie können somit den Umfang von Univention Installation mit Zarafa vergrössern. Das sollte doch Schlussendlich das Ziel sein. Vielen Dank für Ihr Verständnis.
(In reply to rolandb from comment #7) > Vielen Dank für die Antwort, doch leider bestimmt immer noch der Kunde was > als Distribution verwendet werden muss. Und damit Univention als Backend > attraktiv bleibt, würde ich meine Hinweise beherzigen. Sie können somit den > Umfang von Univention Installation mit Zarafa vergrössern. Das sollte doch > Schlussendlich das Ziel sein. > > Vielen Dank für Ihr Verständnis. Ja, klar ist es das Ziel. Man kann ja ohne Probleme die Extended Attributes manuell anlegen und kann dann wie gewünscht administrieren. Das verhindern wir nicht. Ein Feature Request könnte dann sein, dass wir ein Integrationspaket speziell für dieses Szenario bauen. Das wäre denkbar, bislang fehlt uns aber die Nachfrage. Rein technisch hat die vorhandene Aufteilung mehrere Gründe. Der wichtigste ist, dass die Deinstallation sauber funktionieren muss und die Einträge auch wieder aus dem Verzeichnisdienst entfernt werden, wenn man bspw. Zarafa auf einem Slave installiert hat. Eine einfachste Möglichkeit für das konkrete Projekt könnte sein, die Zarafa Pakete auf dem Master zu installieren und über ein paar einfache Befehle ala 'dpkg-divert' und 'ucr set */autostart' dafür zu sorgen, dass die Dienste nicht gestartet werden. Damit sollte die Anforderung ja eigentlich umgesetzt werden können. Alternativ einfach ein Fake-Zarafa Paket erstellen, welches dann anstatt den echten Zarafa Paketen auf dem Master installiert wird. Falls das nicht so einfach geht, dann einfach wieder melden.