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.

Proxmox: ISCSI aus dem System werfen (auch mit Multipath)

ProxMox macht es einem einfach, neue ISCSI Targets ins System aufzunehmen. Ein Klick im Admincenter und schon kann man los legen. Will man das Target allerdings wieder loswerden, wird es schon nicht mehr so trivial. Wurden sämtliche ISCSI Geräte von VMs befreit, sodass die Targets ungenutzt sind, lassen die sich zwar aus dem Webinterface entfernen (Storage …), aber dann sind sie nur aus dem Blick, nicht jedoch aus dem Sinn. Die ISCSI Targets sind nach wie vor verfügbar, was spätestens ein Blick mit „iscsiadm node“ bzw. statt „node“ auch „session“ zeigt. Hat man es nicht nur mit einer einzelnen Node zu tun, sondern hat einen ProxMox Cluster, wird es 1*n mal so hässlich.
Kommt man auf die böse Idee das ISCSI Target auf der ISCSI Serverseite zu entfernen, friert die Node unter Umständen ein, bzw. wirft Haufen Fehler, weil die Geräte nicht mehr verfügbar sind, besonders „multipath“ fängt kräftig an zu jammern.

Hier also mein Notizzettel (ungefiltert) , wie die „Geräte“ sauber aus dem System entfernt werden können – ohne Reboot der Node.

ISCSI Target aus Proxmox entfernen

1. Alle VMs auf anderes Gerät migrieren / local / anderes ISCSI Target
2. Alte LVs in Proxmox löschen (meist unused disk in jeweiliger VM)
3. Prüfen auf Konsole mit lvscan, ob wirklich keine VM mehr die VG verwendet
3. Wenn keine Referenz mehr in Proxmox genutzt, dann in Proxmox Webseite unter Storage
erst VG entfernen, dann ISCSI Target
4. Auf Konsole VG vollständig auf beliebiger Node löschen (vgremove)
5. Gerät aus dem LVM entfernen (pvremove)
6. Name aus Multipath -ll entnehmen:

26f35644f35736a70 dm-5 SCST_BIO,o5dO5sjpPn4ZxszR
size=3.9T features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
|- 13:0:0:0 sdh 8:112 active ready running
|- 15:0:0:0 sdi 8:128 active ready running
|- 16:0:0:0 sdj 8:144 active ready running
`- 17:0:0:0 sdk 8:160 active ready running

"o5dO5sjpPn4ZxszR" ist Name vom ISCSI Target -> verifizieren über den ISCSI Server, ob das
wirklich das zu löschende ist

"26f35644f35736a70" ist der Name des Multipath Gerätes

7. Gerät aus Multipath entfernen -> multipath -f 26f35644f35736a70
7.1 Wenn "map in use" -> dmsetup --tree prüfen
7.2 Dann entfernen: dmsetup remove jbod2--testvg-vm--121--disk--1
7.3 Bei Erfolg, nochmals multipath -f 26f35644f35736a70

8. ISCSI Sessions auflisten: iscsiadm -m session
9. Bei aktiver session, ausloggen: iscsiadm -m node -T jbod-vmdata-02-test --portal 192.168.1.100 --logout
10. Dann passendes Portal löschen: iscsiadm -m node -o delete -T jbod-vmdata-02-test --portal 192.168.1.100
11. Prüfen mittels: iscsiadm -m node | grep jbod-vmdata-02-test ob keins mehr vorhanden ist
12. Gegebenenfalls für alle weiteren Portale wiederholen

Wer es mit mehr als einer Node zu tun hat, sollte zu einem Cluster SSH greifen, um alle Kommandos parallel an allen n-Nodes auszuführen.

Splunk – wie arschig ist das dann!

Ich bin auf der Suche nach einem „hübscheren“ Webinterface für Logdaten, als PHPCon, Alias Loganalyzer (was unter Safari einfach kaputt ist) und wollte mir dann dochmal Splunk anschauen. Da lese ich was passiert, wenn die 60 Tage Testversion aufgelaufen ist und man dann auf die Free Version zurück gestuft wird:

Important: Splunk Free does not include authentication or scheduled searches/alerting. This means that any user accessing your Splunk installation (via Splunk Web or the CLI) will not have to provide credentials. Additionally, scheduled saved searches/alerts will no longer fire.

Da denke ich mir auch nur, wie arschig das ist. Hätte man es nicht bei was anderem belassen können als mal eben die Authentifizierung zu kippen?

Aficio Drucker, Cups und Restriktionen

Kurze Story, lang erzählt.

Auf Arbeit haben mich die letzten Wochen sehr viele Nerven gekostet. Die Aufgabenstellung war eigentlich trivial:

ermögliche Studenten sowohl ihre Freiquota zu nutzen, als auch ihre Mensakarte bei aufgebrauchter Quota.

Als Endgerät wird sowohl ein Ricoh Aficio 4000 als auch ein 5000 eingesetzt. Beide verfügen über einen eingebauten Dokumentenserver (oder auch locked print), der Druckdaten auf die lokale Festplatte ablegt. Diese Dateien können dann am Gerät ausgewählt und gedruckt werden. In unserem Fall muss der Student seine Mensakarte in einen altmodischen Kartenleser stecken, der mittels elektrischen Impuls vom Drucker mitgeteilt bekommt, wie viele Seiten gedruckt wurden, und den Betrag von der Karte abzieht. Beim Einstecken der Karte wird das Bedienpanel freigeschaltet.

Die Entscheidung ob Aufträge nun direkt ausgedruckt, oder auf der Festplatte des Druckers landen, wird per Treibereinstellung definiert. Der Benutzer wählt also selbstständig das Ziel im Druckmenü von seinem Betriebssystem aus.
Die Kunst bestand nun darin, genau das zu unterbinden. Ein Administrator konfiguriert Profile für unterschiedliche Anwendungszwecke und möchte ungern sehen, wie Benutzer dies umgehen.
In einem kontrolliertem Umfeld ist dies noch in Teilen zu realisieren, wobei Windows an dieser Stelle allen anderen Systemen (ich nehme da Novell mal raus) weit voraus ist (sic!). Mittels Gruppenrichtlinien etc. kann man recht viel vor dem Benutzer „schützen“, hat man auch OSX und Linux mit im Boot, sieht es da schon hoffnungsloser aus.
Noch komplizierte wird es, wenn die jeweiligen Rechner gar nicht unter der Kontrolle des Administrators stehen (Stichwort BYOD).
Der Autor hat alle Systeme ausgetestet. Von Linux (OpenSuse12), über OSX 10.9 und Windows 2012r2, bei keinem System gelang es die Druckprofile durchzusetzen. Warum? Ganz einfach: Postscript/PCL. In der Sekunde bei dem der Drucker z.B. Postscript versteht, reichen die Spooler das zu druckende Dokument 1:1 an den Drucker durch (RAW). Innerhalb des Postscript stehen auch alle notwendigen Befehle drin (A4, Schwarz/Weiß, Sortierer, Duplex…) ,aber auch das Ziel, ob Festplatte, oder direkt ausdrucken. Daher werden die definierten Profile ignoriert.

Nun gibt es theoretisch unterschiedliche Möglichkeiten, das Ziel zu erzwingen:

  • Manipulierter Treiber bereitstellen -> unrealistisch, da meist im Betriebssystem vorhanden
  • Filter für Cups schreiben und nicht gewünschte Optionen rausfiltern
  • Backend für Cups schreiben und ebenfalls Filter einbinden

Da ich als Legastheniker in Sachen Programmierung die Filter nicht selbst passend schreiben konnte, fiel mir heute eine weitere Methode ein, das Problem zu lösen: cups-pdf!

Die Idee (sogar schon ein paar Tage alt) war, die Studenten auf einen PDF Drucker drucken zu lassen und die Dateien per Script selbst mit den gewünschten Optionen an den Drucker zu senden. Auf diese Weise entzieht man den Benutzern die Möglichkeit, selbst zu bestimmen, wo und wie das Dokument zum Drucker gelangt.
Die Schlussfrage wäre nur gewesen, wie übermittelt man z.B. den Benutzernamen etc. sodass der Student am Drucker nach seinen Aufträgen suchen kann. Doch es war einfacher als gedacht. cups-pdf besitzt die Option „postprocessing“ in der /etc/cups/cups-pdf.conf. Als Parameter wird ein Script/Kommando angegeben werden, welches ausgeführt wird, nachdem die PDF erstellt wurde.

Ein Beispiel:


#!/bin/bash
CURRENT_PDF="${1}"
CURRENT_USER="${2}"

lp -U $CURRENT_USER -d mensakarte $CURRENT_PDF
rm $CURRENT_PDF

Es gibt also den Drucker „mensakarte“, auf den nur per „localhost“ Cups ACL zugegriffen werden kann. Ein Benutzer druckt auf den PDF Drucker (für den ein Generic Postscript Treiber genügt), das Script erzeugt die PDF Datei, sendet die PDF zum echten Drucker mit den Voreinstellungen von Cups und übermittelt den Benutzernamen. Im Anschluss wird die Datei gelöscht.

Auf diese Weise kann jede Voreinstellung forciert werden, und der Benutzer hat keine Möglichkeit abseits des Formats etwas anderes zu definieren, da alle Postscript Befehle bei der Umwandlung entfernt werden, die den Drucker steuern.

Warum auch immer: in unserem Fall musste ich auch die Länge der Dateinamen der PDF Dateien auf 20 Zeichen beschränken, da sonst der Aficio die Daten nicht akzeptiert hat. Es passierte sonst nichts.

Was für ein Aufwand …

Verkettung von unglücklichen Zeilen

Da wirft man mal ein paar Stunden keinen Blick auf den Server und schon ist dieser eingeschnappt. Beim Umzug von Hetzner wurden einige Zeilen nicht auf einen aktuellen Stand gebracht, die dazu führten, dass Postfix Amok lief. Der Reihe nach:

Auf meiner Dom0 läuft ein lokaler Postfix der eigentlich nicht viel zu tun hat, außer Cron Mails zu verarbeiten. Beim Umzug von Hetzner sind beim Rsync allerdings nicht alle Verzeichnisse und Dateien korrekt angepasst worden, sodass Postfix Amok lief und das Verzeichnis spool/postfix/Maildrop mit zig hunderten/tausenden Dateien befüllte. Jede nur ein paar wenige KB groß, sodass es im Monitoring nicht auffiel. Doch jede Datei benötigt auch eine Inode. Auf ext4 nach wie vor ein wichtiger Faktor.
Es waren dann irgendwann alle Inodes aufgebraucht, sodass Problem Nummer 2 zum tragen kam: LVM. Jede Nacht werden Snapshots für das Backup angelegt. Doch LVM benutzt für sein Locking ebenfalls den selben Einhängepunkt, wie Postfix (/var). Dadurch das Postfix alle Inodes aufgebraucht hat, konnte LVM keine Snapshots anlegen, ja nicht einmal LVs löschen oder sonstwie editieren. Das muss das System dermaßen aus den Tritt gebracht haben, das ein Reboot/Reset ausgelöst wurde. Booten wollte Debian allerdings auch nicht richtig, was Problem Nummer 3 zum Vorschein brachte: Mdadm. Dubioser Weise enthielt /etc/mdadm/mdadm.conf noch das falsche Raid (UUID) und somit auch die Initrd. Was seltsam daran ist, ist die Tatsache, dass das System ja schon bootete … die einzige Erklärung ist demnach, dass beim finalen Rsync die Datei überschrieben wurde uns somit in die Ramdisk gelangte.

Fazit: ein installiertes System per Rsync von A nach B zu schaufeln klappt zwar ganz gut, aber Fallstricke kommen schneller als der Admin denkt.

Veröffentlicht unter Linux

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