Kolab 3.4 – Debian und der Wunsch nach Flexibilität

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:

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 Pyhton 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:

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.

Puppet 3.x unter Debian Squeeze mit LDAP und Dashboard

Da ich mich gerade mit Puppet beschäftige, musste ich mir mal meinen Zeilen zusammenschreiben, um bei der nächsten Installation nicht wieder ewig die Teile zusammen suchen zu müssen. Die Dokumentation ist manchmal so löchrig, was Puppet 3.x angeht, dass ein Großteil der Anleitungen überhaupt nicht funktionieren. Bis alles lief, sind mal locker 2 1/2 Arbeitstage draufgegangen, da jede Fehlerzeile wieder ewiges Suchen nach sich zog. Wie auch immer, die Zeilen sind eine Kombination aus der Bash History und meinem Kopf entsprungen, aber hoffe inständig, dass es weitestgehend vollständig ist.

https://www.pug.org/mediawiki/index.php/Puppet

Notiz: Linux + Acer + EDID + 640×480 + Nvidia

Es gibt Firmen, denen sollte man den Zugang zu wertvollen Rohstoffen und Arbeitskräften verweigern. Ganz klar oben auf der Liste steht Acer. Grund sind die ~105 (+ einer in Reparatur, wegen exakt diesem Problem) Acer Monitore, mit Namen H243HX, die scheinbar nach und nach sich selbst, bzw. ihre EDID Informationen verstümmeln, sodass sich Nvidia weigert, die Monitore mit ihrer normalen Auflösung anzusprechen. Stattdessen erhält man nur 640×480. Um es dem Support noch spannender zu gestalten, tritt das Problem natürlich häufiger unter Linux auf, als unter Windows. Wie auch immer, heute fand ich einen sehr schönen Blogeintrag, der sich dem Problem annimmt.

In meinem Fall ist die Lösung etwas einfacher:

An einen Rechner setzen, bei dem das Problem noch nicht auftritt:

  1. sudo nvidia-settings unter X starten
  2. DFP-0/1 anklicken
  3. „Acquire EDID“
  4. Datei passend ablegen, z.B. /etc/X11/acer_h243hx.edid

/etc/xorg.conf anpassen


Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 9300 / nForce 730i"
Option "DynamicTwinView" "0"
Option "CustomEDID" "DFP-1:/etc/X11/acer_h243hx.edid
EndSection

Da wir ein einziges Image ausrollen, muss ich das nur am Masterimage anpassen und es dann ausrollen lassen. Damit bekommen auch all die anderen Rechner die neue Information verpasst und es dürfte nun egal sein, wenn ein weiterer Acer sich selbst verstümmelt. Allerdings habe ich ein Exemplar, da stimmt noch nochmal die Auflösung auf Biosebene, somit erkennt auch der Kernel nicht mehr, was er für den VESA Mode verwenden kann und fragt entsprechend nach.

Solaris Jumpstart von Linux (Debian) aus

Damit ich das nochmal hinbekomme, habe ich mir einen kleinen Notizzettel geschrieben, wie man Jumpstart von einer Linux Kiste aus initiieren kann, ohne dass man sich von Hand erstmal eine Solaris Kiste installieren muss.

https://www.pug.org/mediawiki/index.php/Solaris_Jumpstart_von_Linux

Haut mich nicht wegen dem Finish Script, das ist nur zusammen gestückelt.

Phu, Lenny Upgrade

So, der Webserver läuft nun unter der Lenny Flagge. Ich denke, den Jabber Server ziehe ich als nächstes um. Eventuell schaffe ich den Mailserver heute auch noch, aber da wird es prickelnd.

Update:

So, Jabber und Mailserver laufen nun ebenfalls unter Lenny. Die LVM Snapshots werde ich zur Sicherheit mal belassen, man weiß ja nie, was der nächste Morgen bringt.

LVM unter Etch, irgendwie kaputt

Ich werde den Verdacht nicht los, dass das Konstrukt LVM, Device-Mapper und Udev unter Echt kaputt ist. Schon seit einiger Zeit bin ich nicht mehr in der Lage, LVM Snapshots sicher zu erstellen. Mal klappt es, mal nicht. Schuld ist angeblich eine Udev Regel. Ändert man wie beschrieben den ACTION von „add“ nach „change“ um, klappt es wieder. Dafür hat dann meine Xen DomU ein Problem. Sie kann dann nicht mehr auf das Volume zugreifen. Ein Input/Output Fehler meldet sich dazu. … ich schätze, ich muss dochmal ein Upgrade auf Lenny testen …

Ich stelle fest…

Cluster bauen macht kein Spaß. Allein wie unterschiedlich schon die Ansätze und Umsetzungen letzten Endes sind, kann einen ganz schön verwirren.
Durch das Lesen der Doku, versteht meiner einer allerdings mehr und mehr, wo was gebraucht wird. Im Falle meines Planes, Xen Hoch verfügbar zu »konstruieren«, stellen sich da diverse Probleme. Zum einen müssen alle Dom0 Rechner auf den gleichen Storage Poolzugreifen können, und zwar sowohl lesen, als auch schreibend(!). Dies ließe sich z.B. mittels NFS bewerkstelligen, allerdings passen NFS und Geschwindigkeit nicht wirklich zusammen. Des weiteren benötigt es eine Software, die dafür sorgt, dass die nötigen Schritte eingeleitet werden, bei einem Ausfall. Im Falle von Xen bedeutet dies, das ausgefallene DomUs auf anderen Dom0s hochgefahren werden.
ein weiteres Problem besteht im Storage selbst: dieser muss ebenfalls redundant sein. Nun gibt es da eine (an für sich) tolle Software: drbd. Diese Sofware synchronisiert Blockgeräte über ein Netzwerk hinweg. Anders formuliert, wenn sich auf Rechner1 ein Bit ändert, wandert dieses Bit auch auf Rechner 2. Also im Grunde nichts anderes, als ein Spiegel. Das Problem hierbei: nur einer lässt sich zur Laufzeit verwenden. Würde man auf beiden Rechnern diesen Datenträger einhängen (welcher über ein Dateisystem verfügt), würde dieses zielsicher zerlegt werden. Um dem vorzubeugen, unterbindet »drbd« dies, und lässt es nur zu, wenn der Primäre Spiegel nicht verfügbar ist. Wir lernen also, es gibt »primary« und »secondary«.

Das hilft uns allerdings nicht viel, denn wir möchten ja, zeitgleichen Zugriff auf dieses Blockgerät. Nun gibt es ab drbd 8.0.x die Möglichkeit, beide Spiegel auf »primary« zu setzen. Das versetzt uns in die Lage, auf beides Rechnern, diesen Datenträger einzubinden. Die Problematik was das Dateisystem angeht, wurde damit allerdings nicht entschärft, und hier kommt ein Clusterdateisystem zum Einsatz. Dieses regelt den syncronen Zugriff auf ein und die selben Datenstrukturen und verhindert, dass zwei Zugriffe von unterschiedlichen Rechnern, zur selben Zeit auf die selben Daten schreiben und damit ein inkonsistentes Dateisystem produzieren. Und genau hier hänge ich nun schon seit drei Tagen. Soviel zur Theorie.

Mir gelang es zwar, »drbd« aufzusetzen, aber bei dem mounten des Oracle Cluster Filesystems Version 2, gibt es nur eine Fehlermeldung. Dabei spielt es keine Rolle, ob als Linux ein SLES10sp1 werkelt, oder ein Debian Etch. Stellt sich also die Frage: wo liegt das Problem? Was »drbd« und »ocfs« gibt es zu hauf widersprüchliche Aussagen, die sehr an Voodoo grenzen und für meinen Geschmack nichts ist, was ich produktiv einsetzen wollte (nichts desto trotz, gibt es sie). Warte ich mal die Antwort von der »drbd« Mailingliste ab. Eventuelle werde ich daraus schlauer … ansonsten bleibt nur noch ocfs durch »gfs« zu ersetzen, was in der Komplexität noch ein Stück höher liegt …

Update

Von: Florian Haas (LINBIT Information Technologies GmbH)
An: drbd-user@lists.linbit.com

OCFS2 had a bug that prevented it from working correctly with DRBD. That
filesystem bug was fixed by our own Phil Reisner and is included in kernel
version 2.6.21 and up. Etch is on 2.6.18, SLES 10 is on a patched 2.6.16;
I’m not sure whether they backported Phil’s 2.6.21 fix to that.