Es ist schon ein wenig erschreckend und es wundert mich mittlerweile auch nicht mehr, warum OpenSource Groupware kaum voran kommt.
Ich gebe zu: ich mag meine Apple Cloud. Sie bringt im wesentlichen alles mit, was man so im Alltag wertschätzt. Da wäre die Synchronisation von Kontakten, über Kalendereinträge Musik und Co. Meine Frau und ich teilen uns sogar einen, damit wichtige Themen nicht durchrutschen.
Alles über mehrere Clients (natürlich alles Apple) hinweg. Naja, hier und da klappt es vielleicht mal nicht ganz so schnell, aber im Großen und Ganzen dann doch.
Als Admin bleibt es aber nicht aus, hier und da mal über den Tellerrand zu schauen. Es schadet nichts zu schauen, was sich so neues im Groupware Bereich getan hat. Früher mal Zimbra ausgetestet (viele Kinderkrankheiten), OpenGroupware (tot) und auch das Monster von Owncloud, was ja auch irgendwie in diesen Bereich reinfällt. Letzteres ist zwar sehr zügig eingerichtet, aber da schon die Basiskomponenten damals so kaputt waren, habe ich es nie wieder ausprobiert. Verfolgt man hier und da die Foren und Mails zu OC, scheint sich das auch nicht wirklich geändert zu haben.
Vor kurzem erschien dann Kolab in der Version 3.4. Eigentlich nicht so meine Richtung, da es vor allem auf Cyrus und KDE-Pim setzt, aber als ich gelesen habe, dass man auch Dovecot als IMAP Speicher nutzen kann, wollte ich der Software mal eine Chance geben. … Was für ein Akt.
Nun halte ich es schon seit Jahren so, dass Web- und Maildienste auf getrennten Servern laufen. Das mag ein Spleen von mir sein, aber es ist eben eine Anforderung. So halte ich es privat, wie in der Firma.
Nun war ich der Meinung, dass das ja kein Problem sein dürfte. Kolab setzt im wesentlichen auf einen Webserver, SMTP Server, IMAP, MySQL und noch einen LDAP Dienst. Will man es sich nicht zu schwer machen, wären das Apache2, Postfix, Cyrus, MySQL und ds389. So sehen es die Paketabhängigkeiten vor.
Nun scheint es aber unter Debian so zu sein (ob das unter CentOS und Co auch so ist … keine Ahnung), dass der Paketbetreuer und/oder die Kolab Entwickler scheinbar immer erwarten, alles auf einem Server zu installieren. Irgendwie hat keiner von denen mal darüber nachgedacht bei den Abhängigkeiten zu überlegen, was wirklich sinnvoll ist.
Ein Beispiel:
Es gibt das (wichtige) Tool „setup-kolab“, welches sich im Paket „kolab-conf“ befindet. Das hat folgende Abhängigkeiten:
1
|
Depends: pykolab (= 0.7.10-0~kolab1), kolab-ldap, python (>= 2.6.6-7~), python (< 2.8), python-augeas, python-cheetah |
Klingt erst einmal nach nicht viel, hangelt man sich aber an den ganzen Paketen entlang, wird man sehr schnell überrascht, was z.B. kolab-ldap nach sich zieht. Das fängt beim ds389 an und hört beim Apachen und Java längst nicht auf. Warum das Ganze? setup-kolab ist ein Python Script, welches dazu dient die Grundkonfiguration zu erstellen. Also vom Anlegen der passenden Konfigurationsdateien, über das Befüllen der Datenbanken und Initialerzeugung des LDAP Baums. Man kann sogar die Module einzeln aufrufen:
1 2 3 4 5 6 7 8 9 10 11 |
root@kolab:~# setup-kolab help freebusy - Setup Free/Busy. help - Display this help. imap - Setup IMAP. kolabd - Setup the Kolab daemon. ldap - Setup LDAP. mta - Setup MTA. mysql - Setup MySQL. php - Setup PHP. roundcube - Setup Roundcube. syncroton - Setup Syncroton. |
Damit hört es dann aber auch schon wieder auf. Die wirklich – aus meiner Sicht – idiotischste Entscheidung ist allerdings die Konsequente Ausblendung von der Konfiguration über TCP. Damit meine ich, dass es defacto nicht möglich ist eine Datenbank über TCP zu konfigurieren. Es wird eine lokale MySQL DB erwartet, deren Socket passend liegt. Das gleiche Spiel gilt auch für den LDAP Server.
Ich kann durchaus nachvollziehen Dienste wie Apache, Postfix, Cyrus lokal konfigurieren zu wollen, aber doch nicht bei MySQL und LDAP?!
Nun könnte ich auf die Idee kommen, einfach „kolab-conf“ auf allen Hosts zu installieren und die Setup je einmal zu durchlaufen um dann die IPs überall zu ändern. Aber Hand auf’s Herz: was für ein Schwachsinn wäre das dann! Ich dürfte dann am Ende überall die überflüssigen Pakete entfernen, oder zumindest die Dienste deaktivieren … viel Spaß bei den Updates.
Wenn man nun also sieht, wie viele Dienste über setup-kolab konfiguriert werden können, wird mir ganz schummrig. Es folgt nämlich das nächste Problem: es gibt keine Anleitung die ohne „setup-kolab“ auskommt, oder zumindest ist mir keine begegnet. Das heißt nämlich, man weiß nicht, wo an welchen Stellen was gedreht werden muss, um die Dienste auf verschiedenen Hosts zu konfigurieren, ohne sich alle Systeme mit überflüssigen Paketen zu versauen.
Aktuell habe ich einen Host auf dem so ziemlich alles (gezwungener Maßen) läuft, außer Webmail …. den ich auf den vorhanden Server laufen haben möchte. Kein Spaß. Ehrlich nicht
Schaut man sich das Wiki von Kolab und die zig Anleitungen dazu an, gibt es schöne viele generierte Bilder wie die Abhängigkeiten sind, aber dass die so überhaupt nicht trivial Umsetzbar sind … davon redet keiner. Naja, stimmt nicht ganz. Man würde nur zu gern wissen, was die haben alles umschreiben müssen, damit das klappt.
Damit ich nicht gleich in die Fail Kategorie laufe: Ich weiß, man kann einen Kolab Server komplett auf einem Server installieren und dann z.B. via Puppet/Rsync (oder was auch immer) die Konfigurationen gezielt anpassen und verteilen, aber elegant und sinnvoll ist etwas anderes, wenn man auf externe Tools angewiesen ist.
Als Fazit bisher:
Ich bin kurz davor entweder die Lust zu verlieren und die VMs zu löschen, Kolab auf einer VM zu hosten oder in den sauren Apfel zu beißen und alles händisch zu erledigen. Was davon ich tun werde, zeigt sich in den nächsten Tagen.
Eins ist für mich aber jetzt schon fast klar: für die Firma wird es aus meiner Sicht erst einmal keine Option sein, wenn nicht einmal die – aus meiner Perspektive – grundlegendsten Dinge funktionieren. Über das recht komplizierte Multidomain Konstrukt will ich auch nicht reden, obwohl ich es zum Laufen bekommen habe.
Für mich ist die Art und Weise wie Kolab konfiguriert und installiert wird, einfach kaputt. Schlicht und ergreifend.
Schaut man sich auch aktuell auf den Mailinglisten um, plagen gerade die Upgrade willigen (3.3 auf 3.4) riesige Probleme. Riesig im Sinne von täglich um Gigabyte wachsende MySQL Tabellen und durchdrehenden Apache Hosts mit 100% CPU …
Was bleibt ist Resignation und ein fader Beigeschmack, dass sicherlich nicht wenige Steuergelder in diese Software geflossen sind.