Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Opensuse 12.1 – Installationserfahrungen

Posted on by

In der letzten Zeit habe ich mehrere Systeme auf Opensuse 12.1 upgraden müssen. Zudem habe ich zwei komplette Neuinstallationen vorgenommen. Zeit mal etwas über meine Erfahrungen zu schreiben – im speziellen auch zum neuen Startup-Verfahren “systemd”. In diesem Artikel geht es um eine Neuinstallation von Opensuse 12.1 auf einem System mit folgenden Charakteristika:

Quadcore CPU Intel Q9550, 8GB RAM, 3ware Raid-Controller mit 4 2TB-Platten im Raid 10 Modus, Nvidia Grafikkarte EVGA 9800GTX+ an einem 1920×1200 Schirm.

Ich möchte hier das System nur soweit installieren, dass mindest die Grafikkarte läuft, die Anbindung ans Netz erfolgt ist und ich in der Lage bin, einen Vergleich der Startup-Zeiten zwischen “systemd” und dem konventionellen “System V Init”-Verfahren durchzuführen.

Ergänzung 04.10.2012:

Wer sich für kritische Betrachtungen zur “systemd”-Einführung interessiert, kann gerne auch meinen Beitrag

Opensuse 12.1, systemd, shutdown, apache

lesen, in dem ich meinen Eindruck nach etwa einem halben Jahr “systemd”-Nutzung unter Opensuse 12.1 zusammengefasst habe.

Potentiell problematisch sind für eine Opensuse-Installation sind an der Hardwareliste zwei Dinge:

Einerseits das Raid 10-System – das Raid-Array entspricht netto einer Platte mit einem Plattenplatz oberhalb von 3,8 TB . D.h. “fdisk” fällt als Formatierungstool aus; es wird “GPT” benötigt. Hier ist aber Optimismus angesagt, denn der Opensuse-Installer bindet mindestens seit Opensuse 11.3 automatisch GPT ein, wenn er eine entsprechend große Platte erkennt. Das Gleiche gilt natürlich auch für den “Partitionierer” unter Yast. Aber man wiss ja nie …

Schwierigkeiten kann ebenfalls die EVGA-Grafikkarte machen. Bei früheren Installationen hatte ich mit dieser Karte regelmäßig Probleme mit dem 1600×1200-Framebuffer-Modus. Dieser wird von Opensuse aber als Modus mit der maximalen Auflösung angeboten – im besonderen für die Konsolen-Darstellung. Den hochauflösenden Modus möchte man natürlich auch gerne ausnutzen – oft genug mußte ich früher aber schon auf den 1280×1024-Modus ausweichen. Hier war ich gespannt, wie sich der “Opensuse 12.1”-Installer verhält und wie man den Nvidia-Treiber zum Laufen bringt.

Positive Punkte während der Installation

Der 1600×1200 Modus wird während der Installation auch bei der EVGA-Karte weitgehend akzeptiert

Ich konnte im graphischen Installer die Auflösung 1600×1200 wählen. Dies machte bis zum Neustart des installierten Systems über “kexec” auch keine Probleme – weder in zwischenzeitlichen Konsol-Ansichten noch im grafischen Modus selbst.

Die Formatierung des netto 3.8 TB umfassenden zusammenhängenden Raid-Arrays gelang ohne jegliche Probleme

Das Raid 10-System ist bei einer Frmwareversion “FE9X 4.10.00.007” des 3ware-Raid-Controllers recht performant – die Schreibraten liegen um die 220 – 250 MB/sec, die Leseraten sind noch höher. Mehr kann man bei den eingesetzten Samsung “2TB F4 HD204UI”-Platten einfach nicht erwarten. Es wäre schade gewesen, wenn das SuSE-System damit nicht hätte umgehen können. Aber weder der Installer noch der “YAST-Partitioner” hatten damit Probleme – wie erwartet benutzen beide automatisch GPT. Ich habe meiner Standardpolitik folgend, mehrere (genauer 4) 80 GB-umfassende Standard-Partitionen am Anfang des Arrays und danach einen großen LVM-Bereich zur Aufnahme flexibel erweiterbarer
Partitionen für Daten und spätere virtuelle KVM-Maschinen anlegen können. Es gab dabei keinerlei Schwierigkeiten.

Ergänzung 13.12.2012 zur “GPT-Partitionierung”:
Das System hat ein Gigabyte Board, das noch mit einem konventionellen BIOS betrieben wird. (Es gibt inzwischen zwar EFI-Updates von Gigabyte. Ich habe die aber nicht benutzt.) Die Reaktion des SuSE-Partitioners auf die Aufgabe, einen 3.8 TB-Platte mit einem BIOS zu kombinieren, war die Anlage eines sog. “Hybrid MBR”. Ich möchte an dieser Stelle darauf aufmerksam machen, dass ein “Hybrid MBR” nicht ohne Tücken ist: So kann man ein Booten aus Partitionen jenseits der ersten 3 in der Regel komplett vergessen – sowohl mit dem herkömmlichen Grub als auch mit bestimmten Grub2-Varianten.

Falls sich jemand fragt, woher die “Politik” mit den 4 Standardpartionen stammt:

Ich bringe hier bootfähige Fallbacksysteme unter, die in Notfällen in der Lage sein müssen, auch Daten in einem bestimmten Umfang aufzunehmen. Die Fallback-Systeme bestehen meist aus Abbildern bewährter Versionen auf einem bestimmten Update-Stand in Kombination mit bewährten KDE-Versionsständen. So komme ich bei größeren Problemen – wie sie im besonderen relativ häufig bei KDE-Upgrades auftreten – oder auch bei Schwierigkeiten mit LVM-Partitionen relativ schnell wieder zu laufenden Systemen, ohne komplette Neuinstallationen oder eine vollständige Restauration von Backups durchführen zu müssen. Hat man Sicherungen seiner Datenpartitionen auf Platten separater externer Systeme untergebracht, oder sind die Datenpartitionen selbst unbeschadet, so erledigt sich die Arbeit meist schon durch Einbinden der Datenpartitionen (ggf. über NFS). Abbilder der Systeme (z.B. per dd) haben sich in der Praxis schon mehrfach bewährt, wenn ein KDE-Upgrade das aktuelle System fast in die Unbenutzbarkeit getrieben hat.

Die Installation geht relativ zügig vonstatten

Aufgrund der hohen Performance des Raid 10-Arrays wird die Installation auch beim Laden vieler Serverkomponenten etc. zügig abgewickelt. Bei der vorgenommenen Installation habe ich praktisch alle relevanten Serverkomponenten sowei eine große Zahl von Entwicklungskomponenten mit installieren lassen. Insgesamt 3,6 GByte an Paketen. Das ging wirklich schnell. Ist aber kein spezielles Verdienst von SuSE.

Probleme während der Installation

Die Weiterführung der grafischen Installation nach Ausführung von “kexec” bringt das System zum Sillstand

Nach der Installation aller Pakete versucht der Installer den neuen Kernel mit “kexec” zu laden und danach das neue System hochzufahren. Hierzu wird temporär auf die Konsolenansicht gewechselt. Danach sollte eigentlich die grafische Installationsoberfläche im aktualisierten System erneut gestartet werden; im Anschluß daran sollte die Konfiguration des neuen Systems (Geräteerkennung und Treiberimplementierung) erfolgen.

Der Wechsel des Installers auf die Konsole für die Durchführung von “kexec” funktionierte. Der Kernel wurde ordnungsgemäß mit “kexec” geladen. Danach werkelte das System noch fleissig im Verborgenen (aha – die erste Anzeichen von systemd – keine Meldungen mehr auf der Konsole!) – und dann wurde der erneute Start der grafischen Installer-Oberfläche eingeleitet. Bei mir endete das aber leider mit eine hübsch bunten Schirm aus Fragmenten und einem Einfrieren des Systems. Das System (besser X-Window) reagierte auch nicht mehr auf Tastatureingaben – ein “Ctrl-Alt-D” für ein geordnetes Herunterfahren blieb wirkungslos. Ich war also gezwungen, die Installation abzubrechen und einen Warmstart durchzuführen.

Ich möchte an dieser Stelle klarstellen, dass dieses Problem meiner Meinung nach vor allem durch
die EVGA Grafikkarte meines Testsystems bedingt ist. Denn auf anderen Systemen mit moderneren Nvidia-Karten trat das hier beschriebene Problem bei einer Neuinstallation vom Opensuse 12.1 nicht auf. Je nach Treibermodul (nouveau) hat die Karte halt doch immer mal wieder Probleme beim Wechseln zwischen dem 1600×1200-Framebuffermodus für die Konsole und dem grafischen Installationsmodus.

Warmstart und erneutes Booten nach System V-Manier ermöglichen nach ein paar Maßnahmen die Fortführung der grafischen Installation

Was macht man in einer solchen Situation, in der man zu Beginn der automatischen Konfiguration zum Warmstart gezwungen wird? Das danach möglicherweise inkonsistente Filesystem macht einem wenig Sorge; das schafft ext4 schon. Ein fsck-Vorgang geht auf dem Raid-System zudem sehr, sehr schnell. Aber wie geht man mit dem dem offenbar problematischen Standard-Grafiktreiber (Nouveau) für die Grafikkarte um?

Meine Schritte waren folgende:

Schritt 1:
Nach dem Warmstart boote ich nur in den Runlevel 3 und zur Elimination von Unwägbarkeiten zusätzlich auf “systemd” verzichten. Ersteres erreicht man durch Eingabe des Parameters “linux 3” in die Parameterzeile des Grub-Startup-Schirms. Und für das zweite hat SuSE dankenswerterweise eine Option angeboten. Man kann auf dem Startbildschirm “F5” betätigen und danach “System V” auswählen. Alternativ gibt man als Parameteroption

init=/sbin/sysvinit

ein. Dann wird der Startvorgang nach alter “System V”-Manier durchgeführt.

Der “System V”-Bootvorgang in den Runlevel 3 erfolgte dann problemlos. Das war auch fast zu erwarten, da die Darstellung der Konsole schon während des ersten Installationsanlaufes keine echten Probleme bereitet hatte. Der grafische Installationsvorgang wurde aber nicht sofort fortgesetzt.

Schritt 2:
Im nun erreichten Runlevel 3 habe ich als ersten geprüft, welches Grafikkartenmodul geladen war. Es war – wie vermutet – das “nouveau”-Treiber-Modul, das SuSE ja seit 11.4 als Default einsetzt. Dieses Treibermodul ließ sich auch nicht entladen – es wurde bei einem “rmmod”-Versuch als “in use” deklariert. Mit einer solchen Situation kann auch der Nvidia-Treiber-Installer nicht umgehen. Deshalb war ein erneuter Bootvorgang von vornherein unausweichlich. Als beste Methode, das System von einer Fortführung der Installation zu überzeugen, erschien es mir nach früheren Erfahrungen, KMS abzuschalten und auch die Pakete für den “Nouveau”-Treiber zu entfernen. Also habe ich mit

“Yast >> /ect/sysconfig-Editor >> System >> Kernel”

den SuSE-Konfigurationsparameter

“NO_KMS_IN_INITRD” auf “Yes”

gesetzt. Ferner habe ich über das Yast-Softwaremanagement das Paket

xorg-x11-driver-video-nouveau”

deinstalliert. Alles in der Hoffnung, dass das System nun erkennen würde, dass die automatische Konfiguration noch nicht durchgeführt oder abgeschlossen wurde. Typischerweise erkennt das SuSE-System das nämlich (wo immer SuSE diese Info hinterlegt wird).

Schritt 3:
Ich habe dann neu gebootet – wiederum mit den Parametern “linx 3 init=/sbin/sysvinit”. Und tatsächlich: Diesmal wurde direkt nach dem Hochfahren eine Meldung angezeigt, dass der Installationsvorgang wegen eines Fehlers nicht abgeschlossen wurde. Danach erfolgte direkt der Wechsel in den grafischen Modus zur Fortsetzung der automatischen Konfiguration. Die wurde auch ohne Fehlermeldungen abgeschlossen. Ein weiterer Bootvorgang in den Runlevel 3 verlief dann ohne Fehler.

Auf diese Weise hatte ich wenigstes die Installation ordnungsgemäß abgeschlossen. Ein “lsmod | grep nouveau” zeigte aber, dass nun immer noch (oder erneut?) der “nouveau”-Treiber geladen war. Dies war insofern überraschend als wir ja
zumindest einen entsprechenden Kernelparameter gesetzt hatten, der zu einer Deaktivierung von KMS führen sollte. Ich habe die Einstellungen erneut mit dem sysconfig-Editor geprüft. Auch “/sbin/mkinitrd” wurde am Ende der Einstellungen im sysconfig-Editor korrekt aufgerufen.

Dennoch wird also der Nouveau-Treiber geladen. Diese Ungereimtheiten kannte ich schon von Opensuse 11.4; siehe auch:

http://www.linuxforen.de/forums/archive/index.php/t-269600.html
und
http://de.opensuse.org/SDB:Probleml%C3%B6sungen-Grafiktreiber

Aus meiner Sicht reicht das Abstellen von KMS nicht; man muss den Treiber zusätzlich “blacklisten”. Dafür gibt es mehrere Möglichkeiten – man findet einige in den Beiträgen unter folgendem Link :

http://www.linuxforen.de/forums/showthread.php?t=269600

Man kann das “Blackliste” aber auch der Nvidia-Installationsroutine für den proprietären Treiber überlassen. Die setzt nämlich bei entdecktem “Nouveau”-Treiber auf Rückfrage beim User ebenfalls einen Blacklisting-Eintrag.

Das nächste größere Ziel war nun die Ersetzung des “nouveau”-Treibers durch den proprietären Treiber. Hierzu musste das neu installierte System erst einmal netzwerkfähg werden. In meinem Fall wollte ich den benötigten Treiber nämlich einfach per “scp” von einem anderen System kopieren. Hierzu muss man neben den Netzwerkeinstellungen auch den sshd-Daemon zum Laufen bringen. (Ein Treiberdownload per Browser kam erstmal nicht in Frage, da ja nicht klar war, ob der Nouveau nicht erneut Probleme machen würde.)

Netzwerk, sshd, IPV6 und Probleme mit dem dsa-key

In meiner Testinstallation schlägt die standardmäßige DHCP-Konfiguration fehl, weil sowohl auf unserem Router als auch dem Standard-DHCP-Server des Netzes unsere “iptables”-basierten Firewalls nur uns bekannte MAC-Adressen zulassen. Für den Nvidia-Test trage ich deshalb die IP(V4)-Adresse auf dem neuen System zunächst von Hand, und zwar mittels “Yast >> Netzwerkeinstellungen” ein – und gleich auch noch das Standardgateway sowie einen DNS-Server. Alles wie von früheren Opensuse-Installationen her gewohnt – das Setzen der Parameter funktionierte einwandfrei. (Nach der Freigabe der MAC-Adresse der Netzwerkkarte auf dem Router (Standard-Gateway) kann der PC dann auch auf das Internet zugreifen.)

Noch ein wichtiger Hinweis zu IPV6:

Man sollte beim Einstellen der Netzwerkparameter im ersten Anlauf IPV6 nicht deaktivieren (dies wäre bei “Yast >> Netzwerkeinstellungen” unter “Globale Optionen” möglich). Man läuft sonst in Schwierigkeiten beim Einsatz von “ssh -X” von Remotesystemen aus. Ferner entsteht ein kleines Problem bei Postfix, dass sich ggf. nicht mehr ordnungsgemäß starten läßt.

Zur Lösung des ssh/sshd-Problems siehe einen früheren Blog-Beitrag :

https://linux-blog.anracom.com/2012/01/03/opensuse-114121-problem-mit-ssh-x/

Dort wird auch einen Fehlermeldung beim Starten des “sshd”-Daemons bzgl. eines nicht gesetzten bzw. nicht ladbaren “DSA keys” behandelt.

Zum Postfix-Problem bei deaktiviertem IPV6 siehe dagegen die Kommentare unter

http://www.linux-club.de/viewtopic.php?f=5&t=114733

Nun starte ich schließlich nach den im anderen Blogbeitrag beschriebenen Maßnahmen zu ssh den sshd-Daemon “rcsshd start”. Von einem Remotesystem aus kopiere ich mir nun die Nvidia-Treiberdatei mittels

scp QUELL_PFAD_NVIDIA_TREIBER_DATEI UID@12.1_HOST:/ZIEL_PFAD_NVIDIA_TREIBER_DATEI

auf mein Opensuse 12.1-System. (Die groß geschriebenen Parameter sind natürlich an die jweiligen lokalen Verhältnisse anzupassen.)

Installation des Nvidia-Treibers

Welcher Treiber ist der
richtige? Hier ist nach einem Fehlversuch meinerseits darauf hinzuweisen, dass mit dem 3.1.0-Kernel von Opensuse 12.1 für neuere Grafikkarten nur der proprietäre Treiber ab der Version 290 kompatibel ist.

Dann teste ich im Runlevel 3 mal mit

sh NVIDIA-Linux-x86_64-290.10.run

ob eine Installation möglich ist. Natürlich nicht, da der Nouveau-Treiber ja noch geladen ist. Den Vorschlag des Nvidia-Installers, einen entspechend notwendigen Eintrag in Startup-Dateien vorzunehmen (Blacklisting des nouveau-Moduls), bestätige ich. Dann starte ich das System neu – nun auch noch zusätzlich mit dem Parameter “nomodeset”, also

linux 3 nomodeset init=/sbin/sysvinit

Danach probiere ich die Nvidia-Installation nochmals. Das funktioniert nun, der Nouveau-Treiber wird nicht mehr geladen. Ggf. zeigt der Nvidia-Installer während des Installationsvorgangs eine Warnmeldung wegen eines Symbolic-Links. Dies passiert oft, wenn zuvor ein anderer Nvidia-Treiber – aus einer anderen Quelle – geladen war. Der Nvidia-installer korrigiert selbständig den bemängelten Link. Dann ggf. zur Sicherheit die Treiber-Installation nochmals durchführen. Die Warnmeldung sollte dabei nicht mehr auftauchen. Auf meinem System musste ich nach Abschluß des Nvidias-Installers das Modul “nvidia.ko” übrigens per

modprobe nvidia

selbst laden. Der 290-Installer hatte dabei Probleme – und zwar auf mehreren Systemen – auch mit anderen Grakas. Das “modprobe”-Kommando läuft dann aber ohne Probleme.

Ein abschließendes “init 5” befördert uns danach vom Runlevel 3 in den Runlevel 5 – und dort wie erwartet endlich in den grafischen Login-Screen von kdm. Auch der nächste Reboot sowohl mit

nomodeset init=/sbin/sysvinit [>>> konventioneller System V Start]

als auch

nomodeset [>>> systemd – Start]

als Parametern läuft dann fehlerfrei bis auf den Runlevel 5 durch.

Bis auf die oben schon genannten Themen mit der Deaktivierung von IPV6 verhält sich das Opensuse-System dann im wesentlichen wie von Opensuse 11.4 her gewohnt.

Zeitvergleich zwischen Bootvorgängen mit “Systemd” und “System V init”

Nun trage ich noch die Parameter “nomodeset init=/sbin/sysvinit” mit Hilfe von “Yast >> bootloader >> Weitere >> Konfigurationsdateien bearbeiten” permanent für den Opensuse 12.1-Eintrag des Boot-Menüs in die Datei “/boot/grub(menu.lst” ein. Will ich künftihg ein wenig mit “systemd” herumexperimentieren, kann ich den Parameter auf dem initialen Bootscreen immer noch manuell löschen.

Diese Wahlmöglichkeit nutze ich als erstes für einen Zeitvergleich. Ich möchte gerne wissen, was mir “systemd” außer der Tatsache, dass ich keine Meldungen während des Bootvorgangs mehr sehe, an Performance beim Booten bringt. Als erstes sehe ich mir die Zeit an, die vergeht bis nach dem Start aus dem Grub-Menü heraus der KDM-Login-Schirm erscheint. Das ernüchternde, etwas subjektive und handgestoppte Ergebnis ist:

  • Booten in den Runlevel 5 mit konventioneller Methode: 20 Sek
  • Booten in den Runlevel 5 mit “systemd”: zw. 15 und 16 Sekunden

Im besten Fall !

Fairerweise muss man sagen, das beim Starten des X-Window-Systems Zeit vergeht, die nicht allein von systemd sondern von der Grafikkarte, dem Treiber und dem angeschlossenen Schirm abhängt : wir sprechen hier von ca. 4 Sekunden. Das passt zum Eintrag in “/var/log/messages”:

Jan 8 13:15:59 xen systemd[1]: Startup finished in 4s 211ms 950us (kernel) + 6s 583ms 110us (userspace) = 10s 795ms 60us.

Deshalb dachte ich, dass man einen faireren Vergleich dann bekommt, wenn man mit den
unterschiedlichen Startvarianten nur in den Runlevel 3 hochfährt. Also habe ich die Vergleichsläufe erneut mit “linux 3” als Startparameter durchgeführt. Und da erhielt ich dann ein wahrhaft schockierendes und für mich überhaupt nicht mehr nachvollziehbares (aber reproduzierbares) Ergebnis:

  • Booten in den Runlevel 3 mit konventioneller Methode: 13 Sek
  • Booten in den Runlevel 3 mit “systemd”: > 38 Sek

Tatsächlich finde ich in “/var/log/messages” folgenden Eintrag:

Jan 8 13:40:27 xen systemd[1]: Startup finished in 4s 163ms 726us (kernel) + 34s 824ms 357us (userspace) = 38s 988ms 83us.

Damit hatte ich erstmal genug von “systemd”! Was immer die Opensuse-Entwickler da fabriziert haben. Das wirkt nicht ganz ausgreift- trotz schöner Artikel wie etwa unter folgender Adresse:

http://news.opensuse.org/2011/12/22/systemd-%e2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/

Man lese aber auch mal die anschließenden Kommentare!

Hinzu kommen richtig ernsthafte Probleme mit systemd beim Upgrade von komplexeren Opensuse 11.4-Systemen auf Opensuse 12.1. Dazu aber mehr in künftigen Beiträgen.

Erstes Fazit

Bei Schwierigkeiten während der Installation hilft es ggf. mit “F5” und auf konventionelle Weise zu booten.

Der Nouveau-Treiber kann während der Installation im Zusammenspeil mit bestimmten Grafikkarten erhebliche Probleme bereiten. Für Nvidia-Karten muss man nach der Installation von Opensuse 12.1 den neuesten proprietären Treiber der Version 290 installieren. Frühere Treiber laufen nicht mit dem neue Kernel.

Die größte Neuerung von Opensuse 12.1, nämlich “systemd” verbessert den Startvorgang -auf einem elementaren System, auf dem keine Serverkomponenten geladen werden. Der sowieso schon schnelle Startup wird beschleunigt – allerdings nicht um weltbewegende Faktoren. Die Verbesserung wird zudem auf einem frisch installierten System nur dann wirksam, wenn in den Runlevel 5 gebootet wird.

Bei einem Start in den Runlevel 3 verhält sich “systemd” unter Opensue 12.1 unerklärlich schlecht; der Startvorgang dauert dann um einen Faktor 3 länger als ein konventionelles Hochfahren des Systems nach bewährter “System V”-Manier.

Kontact 4.7 und OX 6 unter Opensuse 11.4 – Teil II

Posted on by

Einleitung und Inhalte dieses 2-ten Beitrags zu einer OX 6 Testinstallation

Im ersten Teil dieses Beitrages zu einer OX6-Testinstallation haben wir eine OX6-Grundinstallation auf einem “Opensuse 11.4”-Server vorgenommen. Siehe auch:
https://linux-blog.anracom.com/2011/08/21/kontact-47-und-ox-6-unter-opensuse-114-teil-i/ .

Es stand noch aus, einen ersten OX-Kontext und zugehörige OX6-User anzulegen.

Letztere sollen unter der OX-eigenen Web-Oberfläche auf den externen IMAP-Server zugreifen können. Der IMAP-Server, mit dem der OX6-Server kooperieren soll, läuft in unserer Testkonfiguration auf einem separaten Server. Wir werden uns nachfolgend daher damit auseinander müssen, wie sich diese Trennung der Serversysteme auf die Einrichtung von OX6-Usern auswirkt.

In einem nachfolgenden dritten Blog-Beitrag wollen wir abschließend testen, ob und wie der Zugriff von Kontact auf den OX6-Server funktioniert.

Anlegen eines Default-Kontextes

Im ersten Teil sind wir bereits auf Kontexte eingegangen. Wir legen nun als “oxadminmaster” den sog. Default-Kontext an und kreieren dabei gleichzeitig den zugehörigen Default-Kontext-Administrator, dem wir hier willkürlich den Usernamen “oxadmin” geben. Das Ganze geschieht wieder durch ein Skript:

#   /opt/open-xchange/sbin/createcontext  −oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 1  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −L defaultcontext  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Ein paar Hinweise zu den Optionen (s. auch die Befehlsbeschreibung im OX6-Manual “OX6-Provisioning.pdf”):

  • Das “-c 1” definiert die Kontext-Id,
  • das “-u” die User-ID,
  • das “-d” den Displaynamen für den Kontext-Admin,
  • das “-g” den “Given Name” (Vorname),
  • das “-s” den Nachnamen,
  • das “-L” das sog. Login-Mapping (hier eben auf den Defaultkontext),
  • das “-e” die E-Mail-Adresse des Kontext-Admins,
  • das “-q” den kontext-weiten Quota-Betrag in MByte (!),
  • ein “-N” einen Kontext-Namen.

Ein Kontext kann auch einen Namen erhalten – hierzu ist der Parameter “-N” einzusetzen. Dieser Name kann z.B. beim Login-Mapping verwendet werden (s.u.).

Als Email-Adresse sind wir von einem IMAP-Account “oxadmin@mydomain.de” ausgegangen, der über unseren IMAP-Server versorgt wird. Unser IMAP-Server ist dabei wie gesagt nicht identisch mit dem Server des OX6-Systems.

Obwohl die Kommandos für die spätere Anlage normaler OX6-Anwender ähnlich sind, ist die Anlage des “Kontext-Administrators” ein besonderer Akt, der initial die Berechtigung des OX6-Adminmasters erfordert.

Hinweis zu mehreren Kontexten und zum kontextspezifischen Login-Namen eines Users

Legt man später mehrere Kontexte an, so geschieht dies für den zweiten Kontext etwa über

#   /opt/open-xchange/sbin/
createcontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −u oxadmin  −d “Context Admin”  −g Admin  −s User  −p MY_OX_CONTEXT_ADMIN_PWD  −e oxadmin@mydomain.de  −q 1024  −−access-combination-name=all

Man beachte 2 Dinge:

  • Für das Anlegen des Kontextes und gleichzeitig des Kontext Admin ist die Autorisierung als “oxadminmaster” erforderlich. Die weitere Gestaltung des jeweiligen Kontextes und auch die Pflege der zugehörigen User obliegt danach aber dem jeweiligen Kontext-Admin!
  • Jeder User-Account ist kontextspezifisch. Auch der “oxadmin”-User für den Kontext 2 ist keineswegs identisch mit dem “oxadmin”-user für den Kontext 1 !
  • In der Praxis sollten die Kontext-Administratoren natürlich besser unterschiedliche Bezeichnungen bekommen.

Der Login in einen spezifischen Kontext durch Angabe der Kontextnummer nach dem Usernamen, also z.B. durch “oxadmin@1” für den Kontext mit der Nummer 1 oder “oxadmin@2” für den Kontext 2, falls – wie im obigen Beispiel – in jedem Kontext ein User “oxadmin” angelegt wurde. Möchte man statt mit Kontext-ID-Nummern lieber mit “Kontextnamen” operieren, so kann man ein entsprechendes “Login-Mapping” durch folgende “Kontextänderung” bewirken:

#   /opt/open-xchange/sbin/changecontext  −A oxadminmaster  −P MY_OX_MASTER_ADMIN_PWD  −c 2  −N verwaltung  −L 2,verwaltung

Dieser Befehl ordnet dem Kontext 2 den Namen “verwaltung” zu. Ein Login in diesen Kontext würde für den User “oxadmin” danach also auch mit der Eingabe der Userbezeichnung “oxadmin@verwaltung” in einer Login-Maske möglich sein.

Hinweis zu einem typischen Fehler aufgrund bestimmter anfänglich zu viel installierter OX6-Pakete

Bei mir schlug das Kommando zur Kontextanlage trotz Variationsversuchen zunächst zig-fach fehl, weil ich unvorsichtigerweise das Paket “open-xchange-admin-plugin-autocontextid” installiert hatte (s. hierzu auch die Warnung in Teil 1).

Ich wurde dann mit Fehlermeldungen der Art

Error: Unrecognized options on the command line: Unknown option “-c’

oder

com.openexchange.admin.plugins.PluginException: com.openexchange.admin.rmi.exceptions.StorageException: Table ‘configdb.sequence_context’ doesn’t exist

konfrontiert. Letzteres wenn ich testweise das “-c” weggelassen habe. Das Paket “open-xchange-admin-plugin-autocontextid” setzt nämlich Zusatztabellen voraus, die bei unserer Grundinstallation nicht implementiert wurden.

Siehe zu diesen Fehlern
https://forum.open-xchange.com/showthread.php?5935-Error-option-c-not-recognized-when-running-createcontext

Ich habe in meinem Fall dann eine Neuinstallation mit genau den Paketen durchgeführt, die in der Referenz-Installationsanleitung (s. Teil 1) aufgeführt sind. Danach lief das Kommando einwandfrei durch.

Unzureichende Default-Einträge für den IMAP-Mail-Account des Kontext-Administrators

An dieser Stelle lohnt sich nun ein Blick mit PhpMyAdmin in das lokale MySQL-RDBMS, Datenbank “oxdatabase_{ID}”, Tabelle “user“. Es zeigt sich, dass nun für den Kontext 1, der bislang auch unser
Defaultkontext ist, ein Eintrag mit folgender Feldbelegung existiert:

  • cid = 1
  • id = 2
  • imapServer = imap://localhost:143
  • mail = oxadmin@anracona.de
  • smtpServer = smtp://localhost:25
  • etc.

Einen korrespondierenden Eintrag findet man in der Tabelle “user_mail_account“. Man beachte dort auch das Feld “default-flag”, das für diesen ersten Maileintrag zum User “oxadmin” auf “1” gesetzt ist. Für weitere Maileinträge, die man später über die Web-Oberfläche des OX6-Systems erzeugen kann, ist das nicht der Fall. Dort findet man dann eine “0”.

Das obige Kommando für die Kontexterzeugung geht für den User “oxadmin” im jeweiligen Kontext also von der Existenz eines Default-Email-Accounts auf dem lokalen OX6-Server nach dem Muster “imap://localhost:143” aus.

Der würde in unserem Fall aber unglücklicherweise nicht funktionieren, da unser IMAP-System ja auf einem anderen Server vorausgesetzt wurde. Login-Versuche des eben angelegten Users “oxadmin” über die Web-Oberfläche des OX6 würden mit nachaltigen Fehlermeldungen und einer Abschaltung des E-Mail-Subsystems für diesen User quittiert werden. Also müssen wir die Angaben für den User ändern (s.u.).

Dabei gilt es zu beachten, dass dem Default-Email-Account eines OX6-Users eine besondere Bedeutung zukommt.

Behandlung des Default-Mail-Accounts für OX6-User auf einem separaten IMAP-Server

Durch etwas Lesen und Herumprobieren findet man folgenden, eigentlich logischen Punkt heraus:

Jeder User auf dem OX-Server erhält eine Default-Mail-Adresse zugeordnet. Die implizite Annahme ist dabei wohl die, dass dieser Default-Mailaccount ein fester Bestandteil der OX6-Einrichtung ist und auf dem gleichen Server wie das OX-System selbst eingerichtet sein sollte. Alle anderen IMAP-Accounts eines Users sind davon externe unabhängige Dinge. Aber der Anspruch einer OX6-Einrichtung ist der, dass das OX6-System jedem seiner User einen eigenen Mail-Account anbietet. Nun habe ich aber bereits einen separaten IMAP-Server im Netz. Und dort will ich natürlich auch die Default-Accounts des OX6-Systems betreiben!

Wichtig für das erfolgreiche Zusammenspiel des OX-Servers mit unserem separaten IMAP-Server im Netz ist nun, dass der User-Name z.B. des “oxadmin”-Users auf dem OX6-Server identisch mit dem Login-Namen des Useraccounts auf dem Linux-IMAP-Server ist – auf Betriebssystemebene wie auf IMAP-Ebene.

Auch das verwendete Passwort muss auf beiden Servern (zunächst) identisch sein ( – wiederum auf Betriebssystemebene wie auf IMAP-Ebene).

Das gilt nicht nur für den “oxadmin”-Account sondern auch für alle anderen OX6-User-Accounts, die problemfrei auf ihren jeweiligen Default-IMAP-Account zugreifen sollen. Man sollte also einen eigenen, im Netz vorhandenen IMAP-Server von vornherein als eine dem OX6-System fest zugeordnete Einheit begreifen.

Das halte ich nebenbei gesagt für einen kleinen Nachteil der OX 6 Grund-Installation. Denn dies setzt vorab eine aufgeräumte Netzwerkumgebung mit “Single Sign On”-Charakteristik voraus. Was ja keineswegs verkehrt ist, aber dennoch nicht überall gegeben ist. Das Dumme ist dann, dass der OX6-Anwender bei Problemen mit der Default-Mail-Account-Einrichtung spürbare Schwierigkeiten beim Öffnen seiner OX6-Weboberfläche bekommt. Er erhält dann regelmäßig Fehlermeldungen, die das Abschalten des Email-Moduls der Groupware-Oberfläche ankündigen. Und dann ist man als Admin gefordert.

Ich habe übrigens nicht explizit geprüft, ob die Linux UID-Nummern auf den unterschiedlichen Servern auch identisch sein müssen; ich gleiche die aus anderen
Gründen aber sowieso immer ab. Hier hilft natürlich ein zentrales LDAP-System als universales Backend enorm, aber dessen Einrichtung würde hier wirklich zu weit führen.

Nebenbei:
Man kann durch Eingriffe jenseits der verfügbaren OX6-Verwaltungskommandos auch unterschiedliche Passwörter auf dem IMAP-Server und dem OX6-System verwenden. Dazu muss man das abweichende IMAP-Passwort direkt in die Tabelle “user_mail_account” eintragen. Natürlich ist das Passwort verschlüsselt – also ist die spezifische Hash-Methode Crypt in der Tabelle “user_mail_account” zu beachten! (In der Tabelle “users” wird für das OX6-Passwort dagegen SHA1 als Hashverfahren verwendet). Da mir dabei das von OX6 verwendete Salt zur Crypt-Hash-Generierung nicht bekannt ist, behelfe ich mir hier regelmäßig, indem ich gezielt Dummy-User mit dem von mir gewünschten Mail-Passwort anlege, den erzeugten Hash dann in den zu ändernden User-Record kopiere und danach den Dummy-User mit “deleteuser” wieder entferne.

Weitere IMAP-Accounts jenseits des Default-Accounts?

Nach diesen Hinweisen zum Default-Mail-Account eines OX6-Users stellt sich die Frage, wie es um weitere IMAP- oder POP-Accounts bestellt ist und ob man die in der OX6-Web-Oberfläche auch nutzen und die zugehörigen Mailordner einsehen kann.

Ja, das geht natürlich! Jeder User kann später auf beliebige weitere IMAP- oder POP-Accounts auf externen Mail-Servern zugreifen – selbst dann, wenn es mit dem Default-Account des OX6-Systems Probleme geben sollte. Für das Anlegen von Mail-Accounts gibt es in der OX6-Web-Oberfläche einen entsprechenden Menüpunkt unter

“Einstellungen >> E-Mail >> Accounts”.

Nur seinen Default-Account kann der User dort weder löschen noch in seinen Grunddaten ändern. Dies kann nur der Kontext Administrator. Das unterstreicht die besondere Rolle des Default-Mail-Accounts als Teil der OX6-Services.

Beim Anlegen weiterer Accounts kann man die auf dem jeweiligen IMAP-Server gültigen Login-Daten anstandslos verwenden – und die müssen dann natürlich auch nicht identisch mit den Account-Daten auf dem OX-Server sein. Die zusätzlichen Mail-Accounts werden nahtlos in die Struktur der Web-Oberfläche integriert; man kann auf die entsprechenden Mail-Ordner-Inhalte zugreifen sowie eigene Mails mit spezifischen SMTP-Einstellungen versenden. Siehe hierzu auch die Abbildungen weiter unten.

Anpassen der Einträge auf dem OX6-Server für einen Default-Email-Account auf einem separaten IMAP-Server

Nehmen wir an, der von uns betriebene IMAP-Server habe die IP-Adresse “192.168.0.10”. Gehen wir weiter davon aus, dass es auf dem IMAP-Server 192.168.0.10 in unserem Netz einen Account und Postfach für den User “oxadmin” gibt. Dieser soll per E-Mail unter der Adresse “oxadmin@mydomain.de” erreichbar sei. Dann können wir unseren OX6 “oxadmin”-Account für den Kontext 1 wie folgt abändern, damit er mit diesem Postfach verbunden wird:

#   /opt/open-xchange/sbin/changeuser  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u oxadmin  −e oxadmin@mydomain.de  −−imaplogin oxadmin  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Man beachte, dass wir uns hier bzgl. der Authorisierung auf den “Kontext Administrator” und nicht auf den OX6-Admin-Master “oxadminmaster” beziehen !!! Innerhalb eines Kontextes ist es – wie gesagt – der Kontext Administrator, der die Useraccounts ändert – auch seinen eigenen! Wir überprüfen das Ergebnis der Maildatenänderung wieder durch einen Blick in die Datenbank.

Hinweis: Der Zugriff auf den Default-Email-Account per OX6-GUI
muss für Kontext Administratoren explizit freigeben werden !

Theoretisch könnten wir uns als User “oxadmin” nun über einen Browser bereits auf unserem OX6-Server einloggen. Das würde aber immer noch zu Fehlermeldungen führen, denn aus Sicherheitsgründen ist der Zugriff der Kontextadministratoren auf ihre IMAP-Default-Postfächer per OX6-Browser-Oberfläche defaultmäßig abgeschaltet. Diesen Umstand kann man aber durch Änderung eines Eintrags in den Konfigurationsdateien unter “/opt/open-xchange” ändern:

In der Datei “/opt/open-xchange/etc/groupware/mail.properties” muss man dazu den Wert des Parameters “com.openexchange.mail.adminMailLoginEnabled=true” auf true statt false setzen.

Man sollte das Flag in der Konfigurationsdatei wirklich kennen. Sonst wundert man sich – wie ich – evtl. stundenlang, warum die E-Mail-Anzeige in der OX6-Oberfläche für alle normalen User auf Anhieb funktioniert, nur nicht für den Kontext-Administrator – und das obwohl man über Kmail auf den E-Mail-Account des Kontextadmin ebenfalls problemlos zugreifen kann. Noch verwirrender wird die Angelegenheit, wenn man für den “oxadmin” über den Default-Mailaccount hinaus testweise weitere IMAP-Mailaccounts anlegt und sich mit denen auch sofort verbinden kann! Die Ursache für evtl. Probleme mit dem Default-Mail-Account des Kontext-Administrators liegt nur in besagtem Konfigurations-Flag!

Nebenbei:

Als Admin (root) des OX 6 Servers wird man sich neben dem Zugang zu seinem ureigenen Mail-Account ggf. auch einen Zugang zu dem “oxadmin”-IMAP-Account z.B. unter Kontact/Kmail/Akonadi anlegen, falls man die Groupware-Verwaltung nicht deligieren kann. Hierbei sollte man wie immer natürlich wegen des serverseitigen Abonnements von weiteren Ordnern als den Account-Standardordnern des IMAP-Servers aufpassen. Man will ja als Admin nicht alle möglichen Ordner des IMAP-Servers doppelt und dreifach synchronisiert bekommen.

Anlegen eines ersten normalen Users im Kontext 1

Wir legen nun einen ersten “normalen” User im Kontext 1 an. Dieser User muss natürlich bereits einen passenden E-Mail-Account auf dem IMAP-Server besitzen – mit auf beiden Servern gleicher UID und Passwort. Das Passwort heiße USER_PWD. Auf meinem Cyrus-Server sind die IMAP-User-Namen identisch mit den Linux-User-Namen – unser erster User habe den Login-Namen “rlu” (Ralf Lustig). Sein Mailaccount sei “rlu@mydomain.de”.

#   /opt/open-xchange/sbin/createuser c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −d “RLU”  −g Ralf  −s Lustig  −p USER_PWD  −e rlu@mydomain.de  −−imaplogin rlu  −−imapserver 192.168.0.10  −−smtpserver 192.168.0.10

Änderungen an diesen Daten führt man im nachinein wieder mit Hilfe des Scripts “changeuser” durch, wie wir das bereits weiter oben für den “oxadmin” vorgeführt haben. Will man dem User z.B. den Zugriff auf das Adressbuch des OX6-Systems gestatten ( in dem die User des OX6-Systems aufgeführt sind), so erreicht man dies durch :

#   /opt/open-xchange/sbin/changeuser  −c 1  −A oxadmin  −P MY_OX_CONTEXT_ADMIN_PWD  −u rlu  −−access-global-address-book-disabled true

Spätestens jetzt sollte man sich als Admin für weitere Optionen und Einstellungen mit dem Dokument OX6-Manual “OX6-Provisioning.pdf”
https://linux-blog.anracom.com/category/open-xchange/ox6/(http://software.open-xchange.com/OX6/doc/OX6-Provisioning.pdf]
vertraut machen.

Login in die Web-Oberfläche des OX6-Servers

Hat man den OX6-Server wie im ersten Teil dieser Serie beschrieben angelegt, so wäre er jetzt im eigenen Netz unter der Adresse “http://oxs3” erreichbar. Wir probieren dies zum Abschluss unserer Anstrenugungen nun abschließend für den User “oxadmin” aus.

OX6 Login-Maske

Danach erhalten wir – wenn wir alles richtig gemacht haben – die aufgeräumte Web-Anwender-Oberfläche für das OX6-System:

OX6 Benutzer Oberflaeche

Man erkennt hier – etwas mühsam – dass neben dem geöffneten Default-Email-Account noch ein zweiter IMAP-Account auf einem IMAP-Server “oxs2” eingerichtet worden ist. Man kann einen solchen Account einrichten, indem man auf das Zahnradsysmbol in der Icon-Leiste oben links klickt. Man erreicht dann das Menü “Einstellungen” und seine Unterpunkte. Hiermit sollte man sich auch als Admin vertraut machen.

ox6 Menue Einstellungen

Die Einstellung eines zusätzlichen Email-Accounts erfolgt dann über den Menüpunkt “Einstellungen >> E-Mail >> Accounts”:

Ox6 zusaetzlicher Mail Account

Nach diesem ersten Erfolg wünsche ich viel Spass beim Einrichten weiterer User und beim Vertrautmachen mit den Möglichkeiten der OX6 GUI! Man lese hierzu auch das User-Manual

http://software.open-xchange.com/OX6/doc/OX6-User-Guide-German.pdf

Im nächsten Beitrag zum OX6 sehen wir uns dann den Zugriff auf den OX6-Server von KDE Kontact aus an.

Kann man KDE professionell nutzen ?

Posted on by

Kann man ein aktuell gehaltenes KDE als professionelle Arbeitsumgebung einsetzen? Diese Frage stelle ich mir vor allem seit der Einführung von KDE 4 immer wieder.

Meine Antwort:

Ja, schon – wenn man denn viel Zeit zum Testen und Spass am Basteln hat – und man immer eine Rückversicherung in Form älterer KDE-Versionen auf anderen Linuxinstallationen im Arbeitsumfeld vorrätig hält.

Ich möchte in diesem Beitrag auf ein aktuelles Beispiel eingehen – nämlich Veränderungen an KJots. An diesem Beispiel kann man, glaube ich, sehr deutlich festmachen, wo die Probleme liegen.

Zuvor aber ein kleiner Exkurs zu einer der wichtigsten Voraussetzungen für einen professionell einsetzbaren Desktop:

Exkurs: Stabilität der Desktop-Umgebung und ihrer Standard-Anwendungen – gibt es das unter einem sich rasend schnell entwickelnden KDE?

Die obige Antwort deutet das Nein fast schon an. Dann wäre der professionelle Einsatz eines KDE4-Desktops aber wirklich ein Problem. Denn in einer professionellen Arbeitsumgebung gibt es wenig oder gar keine Zeit für Basteleien.

Nun könnte man sagen, dass sich Fehler und zugehörige Basteleien durch eine konservative Upgrade-Politik für den Desktop vermeiden ließen. Damit ist gemeint, dass man halt nur Releases einführt, die man als durch und durch stabil verifiziert hat.

Aus meiner Erfahrung muss ich aber leider sagen: Das kann man bei der enormen Frequenz an Änderungen und der Vielfalt an Applikationen als Administrator nicht wirklich durchhalten. Soviel testen und zurechtbiegen kann man gar nicht – das ist bei dem Umfang und der Vielzahl allein an KDE-Applikationen und der Wechselwirkung mit vielen anderen Open Source Applikationen (Browser, Office-Pakete, etc.) viel zu zeit- und personalaufwändig. Zudem gleicht das Fehlerverhalten unter KDE eher einer Hydra – man muss zum Beleg dieser These nur mal regelmäßig in die KDE-Bugliste reinschauen. Interessant wäre in diesem Zusammenhang eine Statistik von Regressionsfehlern …

Fehler gibt es in der IT immer wieder. An was mache ich die Frage nach dem professionellen Einsatz also fest?

Letztlich an vielen Beispielen, bei denen “Verbesserungen” der Desktopbasis oder aber bestimmter Applikationen immer wieder zu Defiziten im Vergleich zum bisherigen Leistungsumfang des KDE-Desktops oder bestimmter Applikationen führten.

Es geht also eigentlich nicht um “Fehler” sondern um immer wieder auftretende Probleme in Bezug auf die Funktionalität des Desktops oder seiner Applikationen. Solche Probleme können ja auch durch andere Faktoren als durch echte Programm-Fehler induziert sein – z.B. technischen Innovationsdrang, der zum Einsatz neuer zentraler Komponenten führt, die langfristig echte Vorteile versprechen, aber kurzfristig ganze Applikationen an den Rand der Unbrauchbarkeit führen können, weil die Anpassung zu komplex ist. Als Beispiel verweise ich auf die Akonadi-Einführung als zentrales Element der KDE-Umgebung ….

Leider und oft genug bedeuten “Modernisierungen” deshalb für den Anwender plötzlich (mit einem Releasewechsel) auftretende Einschränkungen der Funktionalität und damit der täglichen Arbeit. In einer professionellen Arbeitsumgebung muss man sich jedoch auf die Stabilität seiner Tools verlassen können.

Liebe KDE-Entwickler und/oder Distributoren:

Stabilität bedeutet wesentlich mehr als keine Fehler im Code-Ablauf. Stabilität bedeutet u.a. auch, dass ich mich als Anwender in der täglichen Arbeit auf ein Basis-Set an Applikationen und deren Funktionalitäten verlassen können muss. Das schließt Innovation und Modernisierung nicht aus. Aber es schließt u.a. aus, dass wichtige Funktionalitäten plötzlich ersatzlos verschwinden. Sprich:

Führe substanziell geänderte Applikationen erst dann in ein Release ein, wenn neben der
Fehlerfreiheit auch der alte Funktionsumfang der Applikationen sichergestellt ist oder es einen adäquaten Ersatz gibt.

Nun ist aber eine wiederkehrende Standardsituation bei KDE-Updates folgende:

Release 4.x.y weist endlich einen Fortschritt oder eine Fehlerbehebung in der Applikation A auf, auf die man schon lange gewartet hat. Mit dem gleichen Release wurden aber andere Applikationen B oder der Desktop selbst so stark modifiziert, dass sich die angeblichen “Verbesserungen oder Modernisierungen” dort zunächst eher als substanzielle “Verschlechterungen” erweisen.

Ein kleines Beispiel aus der jüngeren Vergangenheit von Kmail:

Ab einem bestimmten Qt-Upgrade war es über 1,5 Jahre hinweg nicht mehr möglich, unter aktuellen Kmail-Versionen ein “Drag und Drop” von Mails in Richtung Folderhierarchie so durchzuführen, dass sich die Sub-Folderhierarchie beim Überfahren eines Mailordners mit der Maus automatisch öffnete. Alle Umwege, die man als User nutzen konnte, waren unpraktisch und kosteten in der täglichen Arbeit erheblich Zeit. Dabei ging das alles schon mal ganz wunderbar unter KDE 3.x und den ersten KDE 4-Versionen. Unter KDE 4.7 ist dieses Problem dann endlich behoben worden.

Nun lässt sich dafür aber die Reihenfolge von Mailordnern in der Folderhierarchie nicht mehr einstellen. Man hat also in einem Release endlich eine funktionale Einschränkung beseitigt – aber über die Hintertür an anderer Stelle eine neue Funktionalitätseinschränkung eingeführt. Das neu Problem wird nun möglicherweise zur Version KDE 4.7.4 behoben. Frage: Was geht dann nicht mehr ? Und das war nur die Situation innerhalb einer Applikation.

Noch viel öfter tritt der Fall der Verbesserung an einer Stelle und der gleichzeitigen Verschlimmbesserung oder gar Funktionalitätsverlust an einer anderen Stelle auf, wenn man sich KDE applikationsübergreifend von Release zu Release ansieht.

Was sollst du als Admin mit dieser Situation vernünftig umgehen? Eine Umfrage unter den Usern durchführen, ob sie lieber den Teufel in Applikation A oder Beelzebub in Applikation B wollen? Oder eben unter erheblichem Testaufwand auf den eher immer unwahrscheinlicheren Zustand warten, dass mal alle wichtigen Applikationen des Desktops gleichzeitig hinreichend gut funktionieren? Oder sich gleich eine eigene Desktopdistribution zusammencompilieren?

Man versucht halt sein Bestes – bastelt, so gut es geht – und schließt auch als User manchmal erhebliche Kompromisse.

Eine Schlussfolgerung wäre :

Die Planung für KDE-Änderungen oder KDE-Applikationsänderungen muss viel stärker user- und funktions-orientiert erfolgen als bisher und nicht allein technik-orientiert. Und: Es muss eine Qualitätssicherungsinstanz eingeführt (und bezahlt) werden, die die Autorität hat, manche Verschlimmbesserung aus Releases trotz allem berechtigten Innovationsdruck der Entwickler schlicht und einfach fern zu halten.

Aber wem soll man das in einer “Community”, in der der Spaß am Experimentieren und der Innovation der stärkste Motivationsfaktor ist, als Aufgabe mit auf den Weg geben? Müssen die Distributoren hier besser werden? Bei der Effizienzoptimierung, die auch dort unter Kostendruck betrieben wird?

Ich weiss es nicht – am besten wäre aus meiner Sicht eine von der Community selbst organisierte und anwender- und nicht entwickler-dominierte Qualitätssicherung und Release-Politik. Wahrscheinlich gibt es so was schon – ich kenne mich da ehrlich gesagt viel zu wenig aus ….. ich kann nur sagen, es funktioniert irgendwie nicht hinreichend …. man muss in diesem Bereich vielleicht ein paar Aspekte von Open Source neu überdenken – besser die Offenheit und den bisherigen Innovations- und Qualitätsicherungsprozess neu überdenken und um ein paar Komponenten ergänzen.

Die Distributoren haben ja versucht, eine Qualitätsverbesserung über die kostenpflichtigen “Enterprise Desktops” zu erreichen. Ich hatte eine solche
Desktopversion mal ein Jahr von Suse – es bringt ehrlich gesagt nicht viel.

Und es erscheint mir eher eine grundsätzliche Frage zu sein:

Soll oder muss die “Qualität” für den professionellen Einsatz eines Open Source Desktops erst durch kostenpflichtige und z.T. intransparente Leistungen von Distributoren gewährleistet werden? Ist das nicht vielleicht die falsche Stelle in der “Produktionskette”? Das würde ja letztlich eine Drei-Klassen-Gesellschaft” an Anwendern bedeuten:

  • die Kaste an superfitten Freaks, die sich in jeder Situation selbst zu helfen wissen.
  • Otto-Normal-Anwender, der gerne von Microsoft, Apple, etc. unabhängig werden möchte, dabei aber leider zum laufenden Beta-Tester mutiert, wenn er denn nicht irgendwann entnervt aufgibt?
  • Den Besserverdienenden oder Unternehmen, die sich die Gebühren für einen Enterprise-Desktop leisten können?

Irgendwie kann es das doch nicht sein!

Was gar nicht geht – das aktuelle Beispiel KJots

Ich habe mich vor ca. einem halben Jahr mal intensiv nach einem Tool umgesehen, mit dem ich schnell und einfach Notizen und Einfälle strukturiert und formatiert festhalten und sie danach in “Büchern” und “Kapiteln” organisieren konnte. Zudem wollte ich die Möglichkeit für einen Backup sowie einen Export in XHTML-Dateien haben.

Nach einigen Tests von etwa 5 Open Source Produkten bin ich bei KJots hängen geblieben. U.a. auch wegen der Integration in Kontact. Besonders gefallen haben mir aber die Möglichkeiten zur Strukturierung in Büchern, die Formatierungsmöglichkeiten und die Exportmöglichkeiten.

Also habe ich angefangen, das Tool in einer kreativen Phase im Juni und Juli dieses Jahres wirklich intensiv zu nutzen. Damals lief bei mir irgendeine KDE 4.5.x-Version. Vorgestern – also nur 3 Monate später – und mit einem KDE 4.7.2 ausgestattet, wollte ich mich mit den Ergebnissen meiner früheren Arbeit, die ich in Form von “*.book”-Dateien abgelegt und gesichert hatte, mal wieder befassen. Genauer gesagt: ich brauchte die alten Kjots-Dateien dringend als Ausgangspunt für eine Auftragsarbeit.

Man muss dazu sagen, dass ich mir wegen vieler Änderungen auf dem Weg von KDE 4.6 zu KDE 4.7 und der schon gewohnten Probleme mit Akonadi-Ressourcen und Kontakt etliche Teil des Desktops neu aufgebaut hatte. Dabei ging auch die frühere Verzeichnissstruktur (der KDE 4.5-Installation) für KJots unter .kde4 bzw. unter anderen Dateien des Desktops den Weg alles Irdischen.

Na und, denkt der Leser sicher – was solls – daür hattest du ja deine Kjots Dateien ordentlich exportiert und gesichert – importier sie halt einfach. Tja, dachte ich auch … .

Nur hat sich halt inzwischen KJots bzgl. der Datenhaltung und -organisation – vielleicht auch aus sehr guten Gründen – neu aufgestellt. Dummerweise haben die Entwickler dabei offenbar nicht die Zeit gefunden, eine geeignete Importfunktionalität für die alten Kjots-Export-Formate bereitzustellen – nicht einmal für das frühere “native” “.book”-Format.

Nein, nicht nur das – im aktuellen Kjots gibt es gleich gar keine Import-Funktionalität mehr! Siehe

https://bugs.kde.org/show_bug.cgi?id=277378

http://forum.kde.org/viewtopic.php?f=22&t=97304
http://forum.kde.org/viewtopic.php?f=20&t=95898
http://chakra-project.org/bbs/viewtopic.php?pid=37139
http://forums.gentoo.org/viewtopic-t-880151-start-0-postdays-0-postorder-asc-highlight-.html?sid=6e53049575aa553e582f6a2f24bcdd86

und weitere mehr ….

Nun waren die Ergebnisse meiner früheren Arbeit aber wirklich wichtig und Geld wert, und ich brauchte sie dringend. Der erste Ansatz zu einer Problemlösung führte ins Internet – aber dort fand ich im Laufe einer Stunde auch nur arme, ebenfalls ratlose Betroffene und leider keine für mich brauchbare Lösung – zumindest nicht innerhalb eines Zeitraums von einer weiteren Stunde. Dann habe ich – wenig optimistisch – versucht herauszufinden, ob sich nicht eine ältere Version von Kjots installieren lassen würde. Nein ging nicht, die Änderungen an den KDE-Basisbibliotheken auf dem Weg zu KDE 4.7.2 waren einfach zu massiv. Unter Zeitdruck und bei hinreichendem Wert der alten Kjots-Dateien bleibt als nächste Option für einen normalen Benutzer nun nur der Weg zurück zu einer alten KDE-Version.

Ich konnte glücklicherweise einen anderen Ausweg wählen:

Ich kenne den Entwicklungsverlauf und die Fallen von KDE nun schon so viele Jahre, dass ich weiss, wie gut man daran tut, immer auch ein KDE zur Verfügung zu haben, das mindestens ein halbes Jahr alt ist – entweder auf einem anderen PC/Laptop oder aber – wie bei uns – auf einer virtuellen Maschine. Die konnte ich hochfahren – und dort temporär unter KDE 4.5 im VMware-Fenster eines viel “moderneren” KDE 4.7 dann endlich meine alten Kjots-Dateien laden und bearbeiten, die ich vor gerade mal einem Vierteljahr erzeugt hatte – mit einem von mir selbst “evaluierten” KDE-Produkt.

Wie ich den bearbeiteten Stand meiner Kjots-Bücher jetzt in die KDE 4.7-Welt bringe, ist dabei nach wie vor unklar. Über eine anderes Produkt, das evtl. mit KJot-Dateien umgehen kann? Mit einem aktuellen “KBasket” klappte es jedenfalls nicht. Am einfachsten ist am Ende vielleicht wirklich der Export aller meiner Kjots-Bücher in eine umfassende HTML-Datei mit Hilfe der alten Kjots-Version, danach der Import nach Openoffice sowie das dortige zeitaufwändige Nachbearbeiten.

Und der künftige Verzicht auf Experimente bei wichtigen Dingen eines professionellen Umfeldes mit illustren KDE-Applikationen, auch wenn sie einen zunächst mit einem brauchbaren Funktionsumfang verführen mögen ??!

Professionelles Arbeiten?

Offenbar setzt das bei KDE eine Rückversicherung in Form virtueller oder physikalischer Maschinen mit älteren KDE-Versionen voraus, bei denen irgendein Tool oder eine Applikation noch den gewünschten Funktionsumfang hat.

Das alles für den offenbar wahrscheinlichen Fall, dass dieser für das Arbeiten notwendige Funktionsumfang in späteren KDE-Versionen mal wieder nebenbei der heiligen “Innovation” oder aber irgendeiner Verschlimmbesserung geopfert wird …. und man trotzdem upgraden muss, weil das Upgrade an anderer Ecke wirklich Verbesserungen bringt ….

Liebe KDE-Entwickler: Bei allem Respekt, den ihr wirklich verdient – das kann es einfach nicht sein! Das geht so nicht! Das ist zumindest Otto-Normalverbraucher nicht zumutbar.