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

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:

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.

  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
  4. Wenn keine Referenz mehr in Proxmox genutzt, dann in Proxmox Webseite unter Storage erst VG entfernen, dann ISCSI Target
  5. Auf Konsole VG vollständig auf beliebiger Node löschen (vgremove)
  6. Gerät aus dem LVM entfernen (pvremove)
  7. Name aus multipath -ll entnehmen
  8. 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.
  9. Gerät aus Multipath entfernen
    • multipath -f 26f35644f35736a70
  10. Wenn “map in use”
    • dmsetup --tree prüfen
  11. Dann entfernen: -dmsetup remove jbod2--testvg-vm--121--disk--1
  12. Bei Erfolg, nochmals: -multipath -f 26f35644f35736a70
  13. ISCSI Sessions auflisten:
    • iscsiadm -m session
  14. Bei aktiver session, ausloggen:
    • iscsiadm -m node -T jbod-vmdata-02-test --portal 192.168.1.100 --logout
  15. Dann passendes Portal löschen:
    • iscsiadm -m node -o delete -T jbod-vmdata-02-test --portal 192.168.1.100
  16. Prüfen mittels: iscsiadm -m node | grep jbod-vmdata-02-test ob keins mehr vorhanden ist

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?

Doveadm expunge

Weil ich es mir nicht merken kann:

doveadm expunge -u linuxmail@4lin.net mailbox INBOX/debian savedbefore 1d

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.

Abkehr von Hetzner

Durch meinen Nachfolger Admin (CS&T iT-Systemhaus) bin ich zu Hetzner gekommen und das ist jetzt bestimmt rund 5-6 Jahre her. Heutzutage eine relativ lange Zeit, wie ich meine und es hätten noch mehr werden können. Was war passiert? Kurz: Erstens Hetzner will ungenutzte IP Adressen zurück und zweitens wollen sie mehr Geld. Für ersteres habe ich absolut Verständnis, aber für das zweite nicht. Sie wollen nämlich nicht einfach nur für neue IPs und Netze mehr Geld, sondern sie wollen es auch für bestehende, ja selbst für jene, die Anfangs als Dreingabe zum Server dazu gab.

Ich finde die Art und Weise, wie Hetzner da mit seinen Kunden umgegeht eine absolute Frechheit. Für mich hätten dies im Monat 11€ mehr bedeutet und das ohne irgendeinen zusätzlichen Nutzen. Man hat natürlich dann die Wahl gehabt die Netze od. IP Addressen zurück zugeben, die Mehrkosten zu zahlen oder vom Sonderkündigungsrecht von 14 Tagen gebrauch zu machen. Wer da nur ein paar Dinste laufen hat, mag das können, wer mehrere VMs am Start hat etc. pp. dem fällt es dann schon nicht mehr leicht, mal eben einen neuen Hostdienstleister zu finden. Ganz zu schweigen benötigt auch der Domain Registrar Umzug (sofern man wie ich den DNS Robot genutzt hat) einiges an Zeit. Der Umzug von jhell.org kann bis zu 5 Tage benötigen …, aktuell sind schon drei Tage vergangen und sie liegt immer noch bei Hetzner. Fein raus ist der, wer seine Domains eh bei einem externen Registrar hat (so wie ich nun bei InterNetX.de)

Schützenhilfe bekam ich für den neuen Rootserver von Johannes Maus von () (durch meine Anfrage an die Liste der Pug.org), der noch in seinem RZ Ressourcen übrig hatte. Ein verdammt guter Support und völlig unkompliziert. Ich denke, da werde ich ein paar Jahre bleiben.

Moneyplex: Beta und die Schmarotzer

Ich vermute mal, dass ich mit einer der ersten Kunden von Matrica war, der Moneyplex für Linux gekauft (nutzen konnte ich sie nicht, da die Feducia (VB) kein HBCI unterstützte). Damals™, als alles noch besser war. Seither hab ich Versionen für Windows, Linux und seit 2 Jahren auch für OSX. Auch meine andere Hälfte nutzt die OSX Version. Nun liegt es in meiner Natur mir Sorgen zu machen, dass Firmen nicht genügend Geld bekommen, um das Produkt langfristig weiterzuentwickeln. Was macht man als treuer Kunde also? Klar, nachfragen ob man für die aus dem Betastatus gekommene Software auch kaufen darf, obwohl das nicht notwendig wäre, da der hinterlegte Lizenzschlüssel wohl ewig gültig ist.

Die Antwort von Matrica:

Das würde uns natürlich freuen. Denn damit unterstützen Sie uns und

natürlich auch die Weiterentwicklung.

Da Sie moneyplex bereits haben, können Sie natürlich die

Updatekonditionen auf unserer Webseite nutzen.

Tatsächlich sind Sie aber die absolute und löbliche Ausnahme.

Andere Anwender der Beta Version, wehren sich nach zwei Jahren

kostenfreier Nutzung der Software mit Händen und Füssen

und sind der Meinung, dass Sie als Nutzer der Beta Version Anspruch auf eine

kostenlose Vollversion hätten.

Auf solche Leute bekomme ich ja einen Hass. Nur weil sie Betatester waren, die Vollversion nicht kaufen wollen. Ich würde es verstehen, wenn sie geholfen haben Bugs zu finden sowie zu melden und dann nur z.B. den Ppgrade Preis bezahlen möchten, aber so überhaupt nix … Da kann ich nur mit dem Kopf schütteln.

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 12 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