© bilderbox, Fotolia.com

Der KDE-Desktop und seine Programme lassen sich bis ins kleinste Detail fein konfigurieren. Doch was passiert eigentlich, wenn der Anwender bei einer Option ein Häkchen setzt? Und welche Einflussmöglichkeiten bieten sich dem fortgeschrittenen Anwender oder Deployment-Verantwortlichen ?

Das K Desktop Environment kann durchaus als Power-Werkzeug herhalten, denn die meisten seiner Anwendungen und ihre Eigenschaften lassen sich umfangreich konfigurieren. So sind Tastaturkürzel, Dateipfade oder Zugriffsprotokolle auf Dateien konfigurierbar – oft sogar bequem an zentraler Stelle, sodass der Anwender nicht für jede Anwendung erneut seinen Drucker- oder Datei-öffnen-Dialog neu konfigurieren muss.

Zur Herausforderung hingegen gerät, wenn er diese Einstellungen ohne Maus und grafische Oberfläche verwalten will. Das ist durchaus kein Widerspruch, denn einige Admins sind für die Konfiguration von Anwender-PCs verantwortlich und wünschen sich eine automatisierte Einrichtung. Die Details hinter der Fassade von KDE interessieren auch den, der seine Einstellungen von einer KDE-Installation zur anderen umziehen möchte – nach einem Distributions-Update etwa oder dem Kauf eines neuen Notebooks.

Die ersten Berührungspunkte mit Einstellungen, die das Aussehen oder das Verhalten des Desktops sowie von Anwendungen beeinflussen, haben Anwender in der Regel über die Systemeinstellungen »systemsettings« – bei KDE 3 über das Kontrollzentrum »kcontrol« – sowie das Menü »Einstellungen« in typischen KDE-Anwendungen.

Jenseits des Mausklicks

In der Regel verwenden Anwender den Desktop und seine Programme erst einmal und passen im Laufe der Zeit einige Optionen an. Was beim Ändern im Einzelnen passiert und wo das Konfigurationssystem von KDE sie speichert, interessiert den Benutzer erst dann, wenn es Probleme gibt oder er die Einstellungen sichern möchte.

Die Kernbibliotheken von KDE bieten ihren Anwendungen mit Klassen wie »KConfig« und »KSharedConfig« eine standardisierte Möglichkeit, Konfigurationsdaten einzulesen, zu verwalten, zu ändern und zu speichern [1]. Dabei unterstützt KDE via »KConfigBackend« prinzipiell mehrere Backends für den Zugriff auf Konfigurationsdaten. Ein solches Backend liest und speichert Konfigurationsdateien nach eigenem Ermessen. Offiziell ist bislang lediglich ein Backend für Konfigurationsdateien im INI-Format enthalten [2]. Versuche mit Datenbank-basierten Backends blieben bislang unvollständig ([3], [4], [5]).

Konfigurationsformate

Das INI-Format stammt ursprünglich aus der Windows-Welt, wo die Registry es mehr und mehr ersetzt. Konfigurationsdateien sind demnach einfache Textdateien mit Zuordnungen der Form Schlüssel=Wert sowie Bereichen in eckigen Klammern. Die KDE-Variante des Formats beschreibt ein Techbase-Artikel [6]. Beispielsweise enthält ».kde/share/config/oxygenrc« die Konfiguration:

[Windeco]
BlendTitlebarColors=true
ShowStripes=true
TitleAlignment=Left

Einträge oberhalb der ersten Gruppenüberschrift gehören zur Standardgruppe. Die Dateien sind in UTF-8 kodiert, Leerzeichen in Schlüsselnamen erlaubt. Kommentare beginnen mit einem »#«, bleiben jedoch beim Speichern durch KDE nicht erhalten. Mit eckigen Klammern lassen sich nach einem Gruppen- oder Schlüssel-Namen für die ganze Gruppe oder den einzelnen Schlüssel spezielle Attribute einfügen. So aktiviert »[$e]« ein einfaches Shell-Globbing, während »$i« einen Eintrag unveränderlich macht. Letzteres eignet sich vor allem dafür, bei zentral administrierten Desktops global bestimmte Einstellungen für Benutzer zu sperren. Ein einfaches Beispiel für die »mailtransports« ist:

[Transport kmail-1]
Host[$i]=mail.firma.de
[...]
storepass[$i]=false
type[$i]=smtp
User[$ie]=${USER}

Gleichermaßen in eckigen Klammern geschriebene Länderkürzel definieren für einen Schlüssel unterschiedliche Werte abhängig von der Sprache. Davon machen Dateien mit der Endung ».desktop« häufig Gebrauch (siehe Abbildung 1). Eine solche Desktop-Datei legt fest, mit welchen Parametern ein Programm oder ein Dienst zu starten ist oder in einem Menü auftaucht. Mit ».directory« am Namensende bestimmt sie die Anzeigeoptionen für ein Verzeichnis. Das ist ein unter dem Dach von Freedesktop.org entwickelter Standard, den unter anderem auch Gnome verwendet [7].

Abbildung 1: Lokalisierte Programmnamen mit Länderkürzeln in einer Desktop-Datei.

Anwender – aber noch mehr Admins beim Debuggen von Einstellungen – fragen sich, wo die Konfigurations- und Desktop-Dateien landen. KDE legt Daten, die nicht im Quelltext eines Programms enthalten sind, via Ressourcen ab [8]. So brauchen Anwendungen nicht den vollen Pfad anzugeben, was es erlaubt, Ressourcen auch an anderer Stelle abzulegen.

Gewusst wo

Über die Pfade für die unterschiedlichen Ressourcentypen der Klasse »KStandardDirs« gibt der Befehl »kde-config« Auskunft [9]. So zeigt »kde-config –prefix« den Ort für die systemweiten KDE-Dateien an. Üblicherweise ist das »/usr«, Open Suse verwendet dafür »/opt/kde3« oder neuerdings »/opt/kde4«.

Das Kommando »kde-config –localprefix« verrät den Ort für benutzerspezifische Dateien. Die meisten Distributionen haben sich für »~/.kde« entschieden, manche auch für »~/.kde3« oder »~/.kde4«. Welche Ressourcentypen es gibt, zeigt »kde-config –types«. Die Pfade für einen solchen Typ zeigt »kde-config –path Ressourcenname«, dessen Ausgabe wie die Umgebungsvariable »PATH« zu lesen ist. Listing 1 zeigt, wie sich die Pfade auslesen lassen, Abbildung 2 demonstriert das Ergebnis.

Abbildung 2: KDE kennt viele Ressourcentypen und verrät auf Nachfrage auch die Pfade, wo es sie sucht. Das nebenstehende Bash-Skript zeigt die tatsächlich existierenden an.

01 #!/bin/bash
02 kde-config --types | while read t dummy desc; do
03     echo; echo "Pfad für $desc:"
04     echo "$(kde-config --path $t):" |
05     while read -d: p; do
06         if [ -d $p ]; then
07             echo ">>> $p"
08         fi
09     done
10 done | egrep "$USER|^Pfad"

Drei Ebenen konfigurieren

Der zuerst angegebene Pfad hat Vorrang. Das Konfigurationssystem fügt Dateien für die gleiche Ressource wie etwa die Konfiguration von Kmail auf Basis einzelner Schlüssel zusammen. So ist es möglich, systemweite Standardwerte festzulegen, die jeder Benutzer an seine eigenen Bedürfnisse anpassen darf. Der Aufruf von

kde-config --path config|tr : "n"|grep usr

zeigt die Standards des KDE-Projekts oder des Distributors. Sie lassen sich in »/etc/kde*« system- und in »~/.kde/share/config« benutzerweit anpassen.

Speichert ein Benutzer eine Konfiguration, landen nur Schlüssel in der Konfigurationsdatei im Heimverzeichnis, die sich von den systemweiten Standardwerten unterscheiden. Anders als via »/etc/skel/« kommt der Anwender so in den Genuss geänderter systemweiter Standardwerte, insoweit er die nicht selbst angepasst hat. Das ist meist sehr angenehm, kann aber auch zu Problemen führen, wenn neue Standardwerte mit den Anpassungen des Benutzers bei anderen Optionen nicht harmonieren.

Anwendungsspezifische Daten landen in Unterverzeichnissen, die »kde-config –path data« ausgibt, beispielsweise in »/home/martin/.kde/share/apps/:/usr/share/apps/«. Während im systemweiten Verzeichnis in der Regel nur kleine Dateien für Standards von Menü-Einträgen, Themes und Symbolen oder Syntaxbeschreibungen für Kate liegen, wächst das benutzerspezifische Gegenstück im Homeverzeichnis mitunter zu beachtlicher Größe heran. So landen Mail-Indexe von in Kmail konfigurierten IMAP-Zugängen, Kontakte, Kalender, Journaleinträge, Lesezeichen, RSS-Newsfeed-Indexe, die Amarok-Musikdatenbank und Ähnliches in diesem Verzeichnis, das auf dem Rechner des Autors fast 450 MByte umfasst. Speicherfresser unter den Anwendungen zeigt:

du -sch ~/.kde/share/apps/* | egrep "(M|G)"

Die Ressourcentypen »exe« und »lib« offenbaren die Pfade für die ausführbaren KDE-Programme und die KDE-Bibliotheken. So lassen sich solche auch in »~/.kde/bin« und »~/.kde/lib« installieren, um etwa eine neuere Version eines KDE-Programms auszuprobieren.

Neben KDE-spezifischen Ressourcen gibt es auch Desktop-übergreifende Gegenstücke. Sie beginnen mit dem Präfix »xdg« und betreffen vor allem das vom Freedesktop.org-Projekt standardisierte Menüsystem, das etwa KDE, Gnome oder XFCE nutzen.

Auf fremden Pfaden wandeln

Diese Standardpfade lassen sich durch das Setzen bestimmter Umgebungsvariablen anpassen oder ergänzen. Die Umgebungsvariable »KDEHOME« verweist abweichend vom via »kde-config« ermittelbaren Standard wie »~/.kde« auf einen anderen Ordner für benutzerspezifische Dateien. Wer etwa prüfen möchte, ob ein Programm mit Standardwerten das gleiche Fehlerverhalten zeigt wie mit einer angepassten Konfiguration, darf sich auf diese Weise ein Verzeichnis für Testzwecke anlegen, um dort Programme neue Dateien anlegen zu lassen:

mkdir ~/.kdetest; export KDEHOME=~/.kdetest

Damit ermittelt er außerdem, welche Konfigurationsdateien ein KDE-Programm rausschreibt (siehe Abbildung 3). Der Dateimanager Dolphin reagiert allerdings nicht auf ein geändertes »KDEHOME«. Um etwa herauszufinden, welche Dateien ein Programm schreibt, hilft auch die Folge:

Abbildung 3: Der Start einer KDE-Anwendung mit leerem Konfigurationsverzeichnis eignet sich für Tests und offenbart deren Konfigurationsdateien.

strace -e open Programm 2>&1 | grep "/home"

Sie schneidet mit, welche Dateien der Systemaufruf »open()« im Homeverzeichnis öffnet. Überblick über systemweite Konfigurationsdateien verschafft das Paketmanagement, beispielsweise via »dpkg -L Paket | egrep “(rc|desktop)$”« oder entsprechend mit »rpm -ql«.

Die Variablen »KDEDIR«, »KDEDIRS«, »KDETMP« und »KDEVARTMP« geben dagegen systemweite Verzeichnisse für KDE-Daten an (siehe Tabelle 1, [10]). Diese Flexibilität erlaubt es, eine neuere Version von KDE 4 in einem eigenen Verzeichnis im Homeverzeichnis zu kompilieren und zu installieren oder via NFS zentral von einer Admin-Workstation eigene Anpassungen an KDE bereitzustellen ([11], [12]).

Konfigurationskatalysator

Würde jede KDE-Anwendung beim Start ihre Konfiguration aus allen möglichen Quellen zusammensammeln, müssten Anwender über Gebühr warten. Daher verfügt KDE über einen Cache für die Konfiguration. Der KDE System Configuration Cache, kurz Ksycoca, ist eine leichtgewichtige Datenbank für schnelle Lesezugriffe vieler Clients [13]. Für KDE 2 und 3 baut der Befehl »kbuildsycoca«, für KDE 4 »kbuildsycoca4« den binären Cache aus dem Klartext der Konfigurationsdateien auf [14].

Der Daemon »kded«, bei KDE 4 »kded4«, überwacht die Dateien und ruft bei Bedarf den Befehl auf, um den Cache zu aktualisieren. Die Dateien des Cache landeten auf dem Debian-Thinkpad des Autors in »/var/tmp/kdecache-martin/ksycoca4«, während die Manpage zu »kbuildsycoca« den Pfad »/tmp/kdecache-$USER/ksycoca« angibt. Der Vorteil von »/var/tmp« ist offensichtlich: Auch nach einem Reboot ist der Cache noch vorhanden. Alternativ beschleunigt ein Tmpfs das Aufbauen des Cache deutlich.

Mit der Ksyscoca-Option »–incremental« liest der Befehl nur geänderte Dateien ein. An dem laufenden KDE-Desktop vorbei baut »–nosignal« den Cache auf, indem es die Anwendungen nicht über Änderungen informiert.

Updates

Startet ein aktualisiertes KDE-Programm mit einer älteren Konfigurationsdatei, aktualisiert es diese bei Bedarf. Erfordert die neue Datei eine besondere Behandlung, so markiert es das Update entsprechend, wie die ersten Zeilen aus »~/.kde/share/config/plasmarc« veranschaulichen:

[$Version]
update_info=plasma_popupapplet_fix_groups
.upd:PlasmaPopupAppletFixGroups2

Der Befehl »grep “$Version” ~/.kde/share/config/*rc« findet alle aktualisierten Dateien (siehe Abbildung 4).

Abbildung 4: Eine Kmail-Konfigurationsdatei mit langer Geschichte, der Befehl Grep ermittelt Konfigurationsdateien mit Update-Markierungen.

Nicht immer klappt ein Update problemlos. So zeigte K3b nach dem Update von der KDE-3-Version 1.0.3 auf die KDE-4-Testversion 1.69.0alpha4 bei funktionierender Oberfläche ständig einen wartenden Mauszeiger. Zeigt ein aktualisiertes Programm ein ungewöhnliches Verhalten, ist ein guter Test, temporär dessen Konfigurationsdatei aus dem Weg zu schieben, damit es eine neue anlegt. Funktioniert das Programm dann wieder einwandfrei, hilft eventuell ein Vergleich zwischen alter und neuer Konfigurationsdatei weiter. Ein Fehlerbericht hilft den KDE-Entwicklern dabei, das Problem zu beheben [15].

Für Aktualisierungen insbesondere bei größeren Versionssprüngen wie von KDE 3 auf 4 gibt es immer diese beiden Ansätze, entweder die alten Konfigurationsdateien zu aktualisieren oder mit einer neuen Konfiguration anzufangen. Für das Update von KDE 3 auf 4 wählte der Autor eine Zwischenlösung. Er ließ KDE 4 nach einem Backup von »~/.kde« mit den Konfigurationsdateien von KDE 3 starten und klickte in den Systemeinstellungen auf jeder Seite auf »Voreinstellungen«, wo er die KDE-4-Standardwerte vorzog. Das war insbesondere bei Einstellungen zum Erscheinungsbild der Fall.

Ein Update-Problem entzog sich bislang allerdings wirksam der Ursachenforschung: Der Anwendungsstarter Krunner weigert sich auf einem aktualisieren Benutzerkonto beharrlich, Konqueror-Webkürzel zu akzeptieren, während er sie auf einem anderen aktualisieren Benutzerkonto akzeptiert. In Konqueror selbst funktionierten die Kürzel jedoch.

Krunner und Konqueror fügen die mit einem Webkürzel angegebenen Schlüsselwörter in eine definierte URL ein, um auf dem kürzesten Wege Suchmaschinen, Übersetzungsdienste und Bugtracker zu bedienen. So sucht »gg: Linux-Magazin« bei Google nach »Linux-Magazin«, zeigt »leo: file« die deutschen Bedeutung für das englische Wort »file« oder »bug: 218272« den KDE-Bug mit der entsprechenden Nummer.

Das probeweise Löschen der Datei »krunnerc« half nicht. Die systematische Fehleranalyse mit in diesem Artikel erwähnten Methoden brachte die Ursache ans Licht. Nach dem Umstellen des Trennzeichens zwischen Webkürzel und Stichwort in den Einstellungen von Konqueror unter »Webkürzel«, mit dem Ziel, die Konfigurationsdatei neu zu schreiben, funktionierten die Webkürzel in Krunner plötzlich. Ein Vergleich der »konquerorrc« mit einem Backup ergab jedoch kein Ergebnis.

Beim Test mit einem leeren Konfigurationsverzeichnis legte Konqueror beim Umstellen dieser Option indes eine Datei mit dem obskuren Namen »kuriikwsfilterrc« an. Ein Vergleich mit »diff -u« dieser Datei mit einem Backup zeigte den entscheidenden Unterschied (Abbildung 5):

-KeywordDelimiter=58
+KeywordDelimiter=:

Nach einem probeweisen, manuellen Rückändern des Trennzeichens auf »58«, den dezimalen Ascii-Wert für den Doppelpunkt, funktionierten die Webkürzel in Krunner wieder nicht mehr. Also unterstützt Konqueror offenbar dezimale Werte in diesem Schlüssel, während Krunner ein Ascii-Zeichen erwartet. Im anderen Benutzerkonto blieb die Konfiguration der Webkürzel hingegen unangetastet und es stand kein Trennzeichen in der Konfigurationsdatei.

Abbildung 5: Gezielte Recherche bringt die Fehlerursache ans Licht. Der Test mit leerem KDE-Benutzerverzeichnis zeigt die betroffene Konfigurationsdatei und ein Vergleich den entscheidenden Unterschied.

Skriptgesteuert

Für das skriptgesteuerte Auswerten und Ändern von KDE-Konfigurationsdateien gibt es in »KDECore« die beiden undokumentierten Befehle »kreadconfig« und »kwriteconfig«. Zum Glück liefert die Option »–help« genügend Hinweise, um den Befehl zu nutzen. So liest

kreadconfig --file mailtransports 
--group "Transport kmail-1" --key "port"

im Mailtransport »kmail-1«, der in der Gruppe »Transport kmail-1« abgelegt ist, den Schlüssel »port« aus, der bei SMTP mit oder ohne TLS-Verschlüsselung auf 25 und bei SMTPS mit SSL auf 465 stehen sollte. Der Befehl

kwriteconfig --file mailtransports 
--group "Transport kmail-1" --key "port" 999

schreibt in den Schlüssel einen anderen Wert rein (siehe Abbildung 6). Das Programm Kmail bekommt das sofort mit, während »kreadconfig« augenblicklich von in Kmail geänderten Werten erfährt. Für Verwirrung sorgten dabei alte Mailtransporte in der »kmailrc«, die Relikte aus alten Zeiten sind, wie Kmail-Entwickler Thomas McGuire rechtzeitig zum Redaktionsschluss via IRC-Chat mitteilte. Aus irgendeinem Grund hatte ein Update-Skript diese nicht gelöscht.

Abbildung 6: Undokumentierte Befehle lesen im Handumdrehen einzelne Konfigurationsparameter aus oder setzen sie. Dbus-Nachrichten veranlassen eine Anwendung unter anderem die Konfiguration neu einzulesen.

Sollte ein Programm eine Änderung nicht automatisch mitbekommen, hilft es vielleicht, es via Dbus-Nachricht die Konfiguration neu auswerten zu lassen:

qdbus org.kde.kmail /MainApplication 
 org.kde.KApplication.reparseConfiguration

Ohne Parameter zeigt der Befehl alle Dbus-Dienstnamen, mit Dienstname all seine Pfade sowie mit Dienstname und Pfad all seine Methoden. Jedes KDE-Programm bietet in der Regel mindestens einen Dbus-Dienst und über unterschiedliche Pfade verschiedene Schnittstellen zu Methoden. Für KDE 3 gibt es mit DCOP ähnliche Möglichkeiten.

Wer seinen KDE-Desktop intensiv nutzt und dessen Konfiguration anpasst, ist gut damit beraten, das Verzeichnis mit den benutzerspezifischen Daten regelmäßig zu sichern. Dafür bietet sich das Werkzeug »rdiff-backup« an, das via »librsync« inkrementelle Sicherungen fährt. Mit

rdiff-backup ~/.kde/ ~/Backup/KDE

sichert der Admin und räumt mit

rdiff-backup --remove-older-than 2M 
 --force ~/Backup/KDE«

Stände, die älter sind als zwei Monate, auf (Abbildung 7). Wer bereits – mit guter Backup-Strategie – Btrfs testet, greift alternativ auf dessen Snapshot-Funktionalität für Verzeichnisse zurück.

Abbildung 7: Fcron-Jobs sichern via Rdiff-Backup alle zwei Tage die KDE- und Iceweasel-Konfiguration und räumen alle zwei Monate auf.

KDE speichert eine neue Konfigurationsdatei in der Regel zuerst als neue Datei und benennt diese dann um. Es verwendet hierfür standardmäßig den Systemaufruf »fsync()« nicht, da Ext 3 bei ihm alle Daten rausschreibt – langsam. Das kann mit Dateisystemen wie XFS und Ext 4, die Datenblöcke verzögert belegen, zu Problemen führen.

Spätes Schreiben

Solche mit Delayed Allocation arbeitenden Dateisysteme benennen die neu geschriebene Datei mitunter in die alte Datei um, bevor die eigentlichen Daten geschrieben sind. Abhilfe schafft hier ein Ext 4 ab Kernel 2.6.30, das Datenblöcke vor dem Umbenennen belegt. Zudem sollen aktuelle KDE-4-Versionen über das Setzen einer Umgebungsvariablen mit »export KDE_EXTRA_FSYNC=1« doch »fsync()« verwenden, wie dies Dateisystem-Entwickler wie Theodore Ts’o fordern [16]. Linux-Vater Linus Torvalds will dagegen die eigentlichen Daten vor den Metadaten wie Dateinamen-Änderungen schreiben [17]. (mg)