K3b – Crash unter KDE 4.5.2, Opensuse 11.3

Es ist und bleibt schwierig als normaler User an der KDE Front. Immer mal wieder geben beim Wechsel von KDE-Versionen KDE-Key-Applikationen den Geist auf. Jüngstes Beispiel KDE 4.5.2, Qt4.7 und K3b (Version 2.0.1):

K3b ist aus meiner eine Säule im KDE-Applikationskatalog. Hier ist es im Moment leider nicht mehr möglich, den Dialog für die “Einstellungen” aufzurufen. Das Programm “crasht” dann.

Ergänzung 24.10.2010 zur Präzisierung: Es erscheinen bei mir zwar keine Crash-Fehlermeldungen (DrKonqi). Die Applikation “verschwindet” einfach vom Schirm und aus der Processliste.

Aber: Eine Analyse mit gdb zeigt einen “Segmentation Fault” an. Der Genauigkeit halber sollte ich auch anmerken, dass dieser Befund für Opensuse 11.3 mit den aktuellen RPMs aus dem KDE Factory-Repository gilt. In Opensuse’s “Release”-Factory für KDE 4.5.2 ist Qt 4.6 enthalten. Möglicherweise läuft K3B dort besser.

Somit ist u.a. eine Einstellung der Qualitätsstufen für das CD-Ripping (und der zugehörigen Codecs/Kompressionsverfahren) nicht mehr möglich. Auch Spezialeinstellungen für das Brennen fallen weg. Für den Anwender ist K3b damit nicht mehr an bestimmte Situationen anpassbar.

Im Internet gibt es für ältere KDE-Versionen Meldungen, dass die Version 2.0.1 das (oder ein ähnliches) Problem beheben würde. Dies ist für KDE 4.5.2 und Qt 4.7 wohl nicht mehr der Fall. Dass Probleme mit dem Dialog für Einstellungen schon älter sind und immer wieder mal auftreten, kann man den Links weiter unten entnehmen.

Ich frage mich deshalb, wie die KDE-Entwickler – oder natürlich auch die Verantwortlichen bei den Distributoren – bei KDE-Versionssprüngen testen. Ob es Tests quer über die Anwendungen gibt, die ein User typischerweise im Einsatz hat? Für den End-User zählt ja letztlich immer das Zusammenspiel von GUI und (!) den Applikationen. Diese Binsenwahrheit scheint mir im KDE-Entwicklungsprozess oder aber beim Einbau in die Distributionen des öfteren aus dem Blickwinkel verloren zu gehen. Schade eigentlich. Denn das generiert vor allem Test-Arbeit bei denjenigen, die über Upgrades in einer Produktiv-Umgebung entscheiden müssen.

Im Moment weiche ich persönlich auf bzgl. des CD-Rippens auf Asunder (ein einfach zu bedienendes Programm) und beim Brennen auf Brasero aus. Zudem warte ich natürlich mit dem Upgrade von KDE 4.5.1 auf KDE 4.5.2 auf anderen PCs als meinem persönlichen …. Wie so oft bei KDE ….

Links

http://www.pclinuxos.com/forum/index.php/topic,78925.0/prev_next,next.html#top

https://bugs.kde.org/show_bug.cgi?id=238819
https://bugs.kde.org/show_bug.cgi?id=232691
https://bugs.kde.org/show_bug.cgi?id=253567

Nachtrag 03.12.2010 : Unter KDE 4.6 Beta geht es wieder !
Nach einem Wechsel auf KDE 4.6 Beta, Qt 4.7.1 – den ich für den produktiven Einsatz allerdings noch nicht anraten würde (s. sep. Blogbeitrag) – lässt sich K3b wieder crashfrei aufrufen. Auch das K3b Konfigurationsmenü ist wieder bedienbar. Für Opensuse 11.3 muss man sich dafür aus dem KDE-Factory-Repository bedienen. Die K3b-Version funktioniert wieder ab dem RPM “k3b-2.0.1-44.1”.
Zu erwähnen ist noch, dass das aktuelle K3b von den Packman Repositories (2.0.1-1.pm.2.26) unter Opensuse 11.3 und KDE 4.5/4.6 Beta und Qt 4.7 nicht funktioniert.

KDM, root login, KDE 4.5.1/4.5.2

Bei KDE 4.5.1 und 4.5.2 ist defaultmäßig die Möglichkeit zum graphischen Login (kdm) für root abgestellt.

Nun könnte ich mich darüber aufregen – aber ich bin inzwischen zu alt für diese laufenden Aufregungen im Zusammenhang mit einer KDE- und Linux-Philosophie, die sich immer mehr an Windows annähert und aus meiner Sicht einen falschen Weg darstellt. Deshalb nur ein paar Anmerkungen aus dem Bauch raus:

Verfolgt man die Diskussionen in diversen Foren zu dem Login-Thema, so fällt einem auf, dass immer wieder mit dem dummen User argumentiert wird, der durch sein Handeln für sein System ein Sicherheitsrisiko darstellt und dem man deshalb systematisch Möglichkeiten wegnehmen muss. Wo hatten wir diese Argumentation kürzlich auch noch? Ach ja, beim Powermanagment unter KDE. Auch da wurden etablierte Möglichkeiten zur Einstellung des CPU Freq Governors beschnitten, weil der User zu dumm ist, die Folgen seines Tuns zu verstehen. Siehe einen entsprechenden Beitrag von mir in diesem Blog (https://linux-blog.anracom.com/2010/09/09/h/).

Ja, ja, der dumme User …. ob er wohl schlauer wird, wenn man ihn immer mehr einschränkt? Ich glaube nicht. Für wahrscheinlich halte ich es aber, dass immer mehr eingeschränkte User auch mehr Unterstützung durch Profis benötigen werden – cui bono ? Red Hat, Novell ? Wer hat eigentlich wirklich einen Vorteil davon, wenn die Hemmschwellen für User, sich auch in der Systemadministration zu versuchen und dabei etwas zu lernen, defaultmäßig immer höher gesetzt werden ?

Mich ärgert diese Default-Beschneidung von Rechten und Möglichkeiten – weil hier Chancen zum Lernen verbaut werden und das Leben einseitig nur den ausgebildeten Administratoren erleichtert wird. Das hat etwas mit Kommerz zu tun – aber nichts mit “Open”.

Wohlgemerkt, ich verstehe die wachsenden Sicherheitsbedürfnisse in einer Welt mit permanenter Anbindung an das Internet sehr gut. Ich verstehe auch, dass man in professionell genutzten Umgebungen mit hohen Sicherheitsanforderungen die Möglichkeiten des Standard-Users beschränkt – z.T. massiv zum Wohle aller. Dies gilt vor allem dann, wenn ein Administrator die (oft genug schwere) Verantwortung für die Sicherheit der Linux-Arbeitsplatz-PCs und des Netzwerkes übernehmen muss. In diesen Fällen sind Einschränkungen angesagt !

Das ging ja aber alles bisher auch schon!

Der erfahrene Admin wußte/weiss, was er dicht machen musste/muss. Auch ohne Default-Beschneidung durch die KDE-Leute und Distributoren. Dafür ist der Admin ja hoffentlich ausgebildet! Umgekehrt gilt das leider nicht:
Der “dumme” User, der Linux auf seinen Privat-PCs nutzt oder ausprobiert, weiss in der Regel nicht, was er tun muss, um die verlorengegangenen Entfaltungsmöglichkeiten bei Bedarf wiederzuerlangen. Und es ist irgendwie nicht einzusehen, dass User auf privaten PCs, für die sie alleine die Verantwortung tragen, von Haus aus in ihren Möglichkeiten beschnitten werden.

Irgendwann werden wir durch den dauernden Hang zur Begrenzung der Möglichkeiten den Linux-User schließlich so eingeschränkt haben, dass Verhältnisse wie heute bei Microsoft eintreten – der User soll gar nicht mehr wissen, was sein System eigentlich macht und worauf er Einfluss nehmen könnte … Tja, das führt dann irgendwann zu Usern die all ihre Dateien in genau ein Verzeichnis legen, weil sie nichts mehr von Filesystemen wahrnehmen (sollen).

Schöne neue Welt … Verstecken statt aufklären …. Möglichkeiten wegnehmen statt mit verständlichen Erläuterungen vor den Risiken zu warnen ….Mangel statt Entfaltungsmöglichkeiten … Angst vor dem User und zu wenig Entwickler-Kapazität für Hilfetexte …. Angst vor der Dummheit der User und zu wenig Mittel, die eigentlichen Sicherheitslücken zu stopfen ? Aber Klicki-Bunti (statt echter Funktionalität) bis zum Abwinken unter KDE ….

Open Source – quo vadis ?

Leider ist die gesamte Diskussion auch technisch zu eng und ähnlich wie bei der Diskussion um Holger Machts Patch zur Reduktion der Möglichkeiten für Power-Management-Möglichkeiten werden auch hier etliche Szenarien vergessen, in denen auch eine normaler User die Chance bekommen muss, ausnahmsweise (!) mal Einstellungen als root über die graphische Oberfläche vornehmen zu können. Ein Beispiel liefern Laptops. Nicht alle Linux-Systeme befinden sich in einer problematischen Umgebung, für die ein Administrator allein die Verantwortung tragen muss.

Hinzu kommt speziell unter KDE noch folgendes: Empfohlen wird ja vielfach, sich bei Bedarf ein Terminalfenster zu öffnen, sich dort als root einzuloggen und dann die benötigten Programme aufzurufen. Gerade das ist aber im Moment unter KDE in vielen Fällen wenig angenehm.

Ein Beispiel liefert Dolphin. Dophin öffnet sich nach dem Aufruf von root zwar rasch, aber wenn man dann als root einzelne Dateien mit einem graphischen Editor öffnen will, wartet man erstmal bis zu 30 Sekunden während das Terminal mit Fehlermeldungen aus der Soprano-Nepomuk-Ecke überschüttet wird und im Hintergrund die Sicherheitslage gecheckt wird (z.B. von apparmor) weil ein Fremduser-Zugriff auf eine graphische Oberfläche erfolgt.

Und dann stolpert man ggf. über hässliche Schrifteinstellungen ohne Glättung etc. – weil halt die KDE-Einstellungen für root nur sehr rudimentär sind. Aber der dumme User weiß ja sicher, wie er von seinem Desktop aus die Desktop-Einstellungen für root verändern kann …

Ich höre schon das Gegen-Totschlag-Argument: Root braucht keine graphischen Programme, wozu gibt es denn “mc” und selbst das ist für Hartgesottene schon zu grapisch …. Außerdem gibt es ja “sudo” und “kdesudo”. Tja, das wird ja spannend, wenn der dumme User auch damit für etliche Zwecke an Grenzen stößt und dann eigentlich anfangen müsste, die sudo-Konfigurationsdatei abzuändern ….

Alles in allem ist mir dieses elitäre Getue zu blöd. Ich möchte mich manchmal (!) auch als root graphisch einloggen – vor allem wenn es wirklich schnell gehen muss. Ich bin root – ich darf das. Deshalb ein paar Hinweise zur Umgehung der Sperren für Opensuse 11.3 für die, die sich nicht einschränken lassen wollen:

Die “KDM”-Einstellungen erfolgen bei Opensuse 11.3 in 2 (!) Dateien:

/usr/share/kde4/config/kdm/kdmrc

/var/adm/kdm/kdmrc.sysconfig

In diesen Dateien muss mindestens im Abschnitt

[X-:*-Core]

folgender Eintrag erfolgen:

AllowRootLogin=true

Bis vor kurzem war das auch genug. Nun haben aber die Suse-Entwickler ein wenig mehr getan und Änderungen an der letzten der beiden genannten Dateien werden bei KDE-Starts rückgängig gemacht. Ein (längerer) Blick in die SuSE-Scripts zeigt jedoch, dass ein Eintrag in folgender Datei für KDM hilft (das habe nicht ich entdeckt sondern nur nachvollzogen – die Ehre gebührt Carlos E. R. (s. den Link zum Opensuse Forum):

Datei:         /etc/sysconfig/displaymanager

Eintrag:         DISPLAYMANAGER_ROOT_LOGIN_LOCAL=”yes”

Diese Eintragsmöglichkeit ist im Moment leider nicht im Yast-Editor für “/etc/sysconfig” enthalten. Es wäre fair von Suse, das da aufzunehmen.

Links

http://forums.opensuse.org/english/get-help-here/install-boot-login/446249-root-logins-not-allowed-2.html

Abschluss: Sicherheit entsteht
auf Dauer durch Wissen und dessen Verbreitung, aber nicht durch die systematische Beschränkung der User!

9650SE-4LPML – ein paar Einstellungen

Wenn man mit einer oder mehreren VMware-Workstation unter Linux hantiert, ist man froh über einen guten I/O. Gestern hat mich jemand in diesem Zusammenhang auf meine Erfahrungen mit 3ware-Controllern angesprochen.

Pauschal konnte und kann ich darauf nicht antworten – man müsste für eine solide Einschätzung systematische Vergleiche mit anderen Controllern durchführen. Dazu fehlen mir im Moment schlicht die Ressourcen. Es gibt aber interessaante Diskussionen im Internet. Ich empfehle den folgenden Beitrag

http://makarevitch.org/rant/raid/

Siehe auch die dortigen Links mit wirklich interessanten Statements und Erfahrungen zu 3ware-Controllern unter Linux. Hochinteressant finde ich vor allem die Vergleiche mit SW-Raid-Konfigurationen unter Linux, die mich ab und zu doch an meinen Investitionen in HW-Raid für Desktops zweifeln lassen.

Dennoch und aus dem Bauch heraus: Meine Erfahrungen sind im Mittel nicht schlecht, aber gerade mit laufenden VMware-Workstations wird der Platten I/O auf meine Opensuse Kisten bisweilen für kurze Momente zu einem echten, spürbaren Engpass. Zumindest, wenn man sich nicht ein wenig um die (begrenzten) Einstellmöglichkeiten des Controllers und auch des Linux-Systems kümmert.

Aufgefallen ist mir in der Praxis auch, dass auf meinen Opensuse-Systemen mit Quadcore-Prozessoren unter Last irgendwie immer (oder vor allem) der erste Core hohe WAIT I/O-Werte aufweist. Ich gehe mal davon aus, dass die 3ware-Treiber in Kombination mit dem Kernel den Controllerzugriff und den Datentransfer über genau einen Core handhaben. Auch dazu gibt es Hinweise in einschlägigen Diskussionen im Internet.

Der von mir auf den Desktop-Systemen verwendete Controller “9650SE-4LPML” ist ferner nicht ein System, bei dem man die Performance über große Raid-Stapel mit 12 oder 24 Platten hochziehen könnte. Mit 4 Platten sind die Möglichkeiten halt begrenzt.

Also fängt man an, ein wenig herumzuprobieren und vor ein paar Monaten habe ich tatsächlich mal ein wenig Zeit investiert, um mir mit “Bonnie++” verschiedene Konfigurationen anzusehen. Allerdings nur mit EXT3/Ext4 als Filesystem. Wenn ich auf dieser Basis Empfehlungen geben sollte, dann wären es folgende:

1) 4 Platten – Raid 10

2) Wenn man es sich leisten kann : Eher kein LVM einsetzen.

3) Controller-Parameter: Read-Cache auf “Intelligent” setzen und Write-Cache aktivieren (Battery Unit zur Vermeidung von Datenverlusten/Inkonsistenzen einkalkulieren). StorSave auf “Balance” oder “Performance” setzen. Verwendung von “Queuing” (NTQ Feature der Platten, wenn vorhanden) anschalten.
(Zum Einstellen von Controller-Eigenschaften kann man übrigens gut das übersichtliche “3DM2” benutzen.)

4) Linux-Einstellungen – z.B. für ein Raid-Device, das unter “/dev/sda” anzusprechen ist:

echo “512” > /sys/block/sda/queue/nr_requests

und danach (!):

blockdev   −−setra 16384 /dev/sda

5) VMware-Workstation (konfiguriert für 2 CPU-Cores eines Quad-Core-Systems):
Zuweisung des “vmware-vmx”-Prozesses an zwei andere Prozessor-Cores als den ersten, auf dem zumeist der I/O kontrolliert wird. Also z.B.:

taskset -pc 2,3 <pid des vmware-vmx-Prozesses>

Testet man die Performance unter diesen Bedingungen etwa mit zwei Raid 1 Units, die bei mir unter Linux als “/dev/sda” und “/dev/sdb” erscheinen, so erhält man mit Bonnie++ recht gute Werte für sequentielles Lesen und Schreiben (ca. 10% unter den theroretischen Maximalwerten der Platten). Aber es lohnt sich, auch andere Parameter-Werte – vor allem für blockdev – unter Linux auszuprobieren. Hier konnte ich durchaus messbare Unterschiede feststellen. Hat man gute Werte gefunden, hinterlegt man sich die Einstellungen in einem kleine Startup-Script.
Der Wechsel auf Raid 10 führt dann nochmals zu einer signifikanten Steigerung der I/O-Werte.

Mit unterschiedlichen Schedulern habe ich auch rumgespielt. Irgendwie erschienen mir die Unterschiede aber nicht so signifikant zu sein.

Ich hoffe, ein paar von den Hinweisen helfen auch anderen weiter.

KDE Power Management – so bitte nicht ….

Es gibt Dinge, da enden das Verständnis und die Nachvollziehbarkeit. Und man fragt sich, wie der Open Source Betrieb inzwischen eigentlich funktioniert.

Offenbar immer mehr nach dem Motto: Der User ist zu doof …. und deshalb nehmen wir ihm nützliche Dinge weg, weil einige Leute ihre Vorurteile und ihren Einfluss geltend machen.

Bis KDE 4.4 gab es ein nettes ansprechendes Feature in den KDE Systemeinstellungen – nämlich eine hinreichend umfassende Möglichkeit, sich Profile für das “power management” (hier CPU governor) zusammenzuklicken. Eigentlich genau das, was man sich als Normal-User, aber auch als Entwickler so wünscht, wenn man auf einem Desktop oder Laptop unter wechselnden Bedingungen arbeitet und nicht jede Einstellung zum “power management” über die Konsole eingeben will. Eine runde und wie ich finde auch durchdachte Sache rund um HAL und power-devil …

Aber H. mag das nicht … und H. findet anscheinend, dass die Anwender zu blöd sind, die Folgen ihres Tuns abzuschätzen. Also dringt H. darauf, dass ein halbwegs komfortables Tool zur Einstellung des CPU-Frequenzverhaltens und andere Schrauben für das Energieverhalten eines Systems aus KDE entfernt wird. H. weiss: Das ist nix für eine GUI, denn der GUI-Benutzer ist einfach zu dumm. Und weil H. die KDE-Anwender und moderne CPUs kennt, weiss er auch, dass solche Features zu 99,8% überflüssig ist. So ein Laptop weiss schon, wann er sich drosseln muss ….und überhaupt die Energieveschwendung ….und die Wunder einer effizienten “On Demand” Welt ….

Anstatt aber etwas tun, um den “Dummen” die Folgen ihres Handelns z.B. in Hilfetexten oder an Beispielen in der GUI zu erläutern – nein, da nehmen wir ihnen die Möglichkeit was einzustellen lieber gleich ganz weg. Per Patch – und schon sind bewährte Einstellmöglichkeiten, die der User aber sicher ganz falsch verwenden wird, in KDE 4.5 nicht mehr drin. Am besten wäre es allerdings, auch noch die Einstellmöglichkeiten an der Konsole – sprich die “solid-powermanagement”-Optionen zu beschneiden ….. Blöd irgendwie nur, dass das im Patch beabsichtigte reine On/Off-Schalten von Energiespar-Einstellungen für die CPU-Frequenz auch nicht so recht funktioniert ….

An was erinnert mich diese Art der “Argumentation” doch noch? Wie hies doch gleich das System mit der GUI, bei der der User so wenig wie möglich mit Nachdenken belastet werden soll ? Wollte man mit Linux nicht weg von einer solchen Politik?

Die Phantasie von H. reicht offenbar nicht so weit, dass er sich vorstellen kann, dass es KDE-Nutzer gibt, die grafische Oberflächen nicht nur zum Üben von Openoffice auf einem Laptop einsetzen. Dass man z.B. bei Bedarf (und bequem) ein bestimmtes Power-Management-Profile aktivieren möchte, wenn mehrere VMware Workstations auf einer Linux-Workstation zeitweise mit konstanter Frequenz auf unterschiedlichen CPU-Cores laufen sollen und müssen – sowas kommt in in der Welt von H. nicht vor. Und dass man manchmal die Frequenz konstant auf das niedrigst mögliche Niveau setzen will, um die Performance von Programmen für solche Verhältnisse zu testen – neh’ das braucht es in der on demand Welt nicht. Und dass es einen Bedarf für Powermanagement-Profile bei Anwendern mit älteren Laptops geben mag, die sich nicht alle 2 Jahre ein neues Gerät leisten können? Egal …. Und dass man bei manchen Laptops gezielt die niedrigste CPU-Frequenz einstellen mag, weil sonst die Lüfter unter Linux und KDE laufend anspringen? Egal ….

Und selbst wenn – der typische Linux- und KDE-User kann die Folgen seines Klickens auf all die schönen bunten Features auf dem KDE-Schirm ja eh’ nicht einschätzen ….

Hinweisen wollte ich die anderen dummen 0,02% KDE-Mitbenutzer, die die früheren Möglichkeiten zum Einstellen von Powermanagement-Profilen eventuell doch vermissen, noch auf die Möglichkeit von

solid-powermanagement query cpufreq
und
solid-powermanagement set
cpufreq <value>

Ich meine für die Zeit, bis H. auch das zum Wohle der Anwender, im Sinne des Fortschritts und einer heilen “on demand” Welt eliminiert hat.

Bliebe noch die Diskussion um die Zukunft von HAL – aber auch in einer Zukunft ohne HAL sollte die Frage, ob und warum man dem User Kontroll-Möglichkeiten entzieht, vielleicht in einem anderen Stil diskutiert und evtl. auch über andere Verfahren zur Entscheidung gebracht werden.

Links

http://forum.kde.org/viewtopic.php?f=22&t=88774&p=167797#p167797
http://kubuntuforums.net/forums/index.php?topic=3113359.0
http://osdir.com/ml/kde-devel/2010-03/msg00055.html

http://dot.kde.org/2007/04/24/road-kde-4-solid-brings-hardware-configuration-and-control-kde?page=1
http://wiki.ubuntuusers.de/Solid
http://en.wikipedia.org/wiki/Solid_%28KDE%29

https://bugzilla.redhat.com/show_bug.cgi?id=550486

http://forum.kde.org/viewtopic.php?f=66&t=31708

Kontact, Kmail, Address Book – Nachtrag 2

Nachdem ich gerade auf einem PC mal wieder Opensuse 11.3, KDE 4.5, Kontact und Kmail installiert habe, eine kleine Hilfestellung dazu, wie man Kontact-Adressbücher auch unter Kmail und seiner automatischen Addressbuch-Suche/-Vervollständigung zum Laufen bekommt.

Standardmäßig ist Kontact ja mit einem Adressbuch “Persona Contacts” ausgestattet. Trägt man dort Adressen ein, so erwartet man, dass diese Adressen bei Anlage einer neuen Mail als Vorschläge auftauchen, wenn man die ersten Buchstaben der Adresse in eine Adressleiste der neuen Mail eintippt. Dies ist leider nicht der Fall. Aber ein kleiner Trick – nämlich ein Umweg über die KDE-Systemeinstellungen für Resourcen – führt zum Erfolg. Inzwischen nicht nur für die unter Kontact als “traditionelle” Adressbücher bzeichneten Ressourcen, sondern auch für reine Akonadi Adressbücher.

Vorgehen für ein traditionelles Adressbuch:

Ic beschreibe hier die Schritte beispielhaft für das Adressbuch eines Open-Xchenage-Servers. Das geht aber genauso für Adressbücher auf Ordner, File und VCF-basis.

  • Schritt 1: Man starte Kontact, wechsle dort in den Bereich Kontakte. Klick mit der rechten Maustaste in den Bereich “Address Books”. Auswahl “Add address book”. Nachfolgend Auswahl von “KDE Address Book (traditional)”.
  • Schritt 2: Im folgenden Dialog Auswahl “OpenXchange-Server”. Dann die Server-Angaben vervollständigen. Z.B.:
    URL: http://OX.meinedomaine.de (falls der Server OX heisst und über diesen Namen (DNS) ansprechbar ist).
    USer und Passwort angeben. Danach den Button “Select Folder” wählen und eines der zugänglichen persönlichen oder globalen Adressbücher auf dem Open-Xchange Server auswählen.

  • Schritt 3: Ggf. im Dialog zum OX-Adressbuch auch noch angeben, ob man immer das ganze Adressbuch laden will oder nur die Änderungen seit der letzten Synchronisation. Diese Entscheidung hängt im Besonderen von der Größe des Adressbuchs, der Frequenz der Aktualisierung und der resultierenden System- und Netz-Belastung ab.
  • Schritt 4: Name des Adressbuchs auf dem lokalen System angeben. Dieser Name legt de Bezeichnung als lokaler Folder und auch als Akonadi-Resource fest. Danach “Finish”. Nun sollten die Adressen vom Server geladen und mit dem Inhalt der eben angelegten lokalen KDE-Adsressbuch-Ressource abgeglichen werden.
  • Schritt 5: Dieser Schritt ist von besonderer Bedeutung und muss leider und unverständlicherweise manuell durchgeführt werden! Öffnen von KDE’s “Systemeinstellungen”. Unter KDE 4.5 geht man nun auf den Punkt “Persönliche Informationen / KDE Ressourcen”. Dort wählt man in der Ressourcen-Auswahl “Kontakte”. Dann “Hinzufügen”. In dem nachfolgenden Dialog “OpenXchange-Server”. Die nachfolgenden Punkte entsprechen exakt denen von Schritt 2. Danach klicken wir “Anwenden”.
  • Schritt 6: Über die “Akonadi-Einrichtung” (Startmenü -> Suchen -> “Akonadi”) prüfen, dass das Addressbuch auch als Akonadi-Resource angelegt ist.
  • Schritt 7: Systemeinstellungen schließen, Kontact schließen, ausloggen, KDE neu starten, einloggen, Kmail öffnen.
  • Schritt 8: Testen, dass beim Schreiben einer neuen Mail die automatische Adress-Completion für Adressen aus der angelegten OX-“Address Book”-Ressource funktioniert.

Vorgehen für ein Akonadi-Adressbuch:

Wir können die Beschreibung hier auf die unter Opensuse bereits angelegte Akonadi-Adressbuch-Ressource beschränken. Andere Akonadi-Ressourcen muss man halt vorher anlegen (u.a. über Kontact). Angelegt ist unter OPensuse das Akonadi-Adressbuch “Personal Contacts”.

  • Schritt 1: Verifizieren, das das zu verwendende Akonadi-Adressbuch “Personal Contacts” bereits als Akonadie-Ressource existiert. Hierfür kann man erneut die “Akonadi-Einrichtung” benutzen.
  • Schritt 2: Öffnen von KDE’s “Systemeinstellungen”. Unter KDE 4.5 geht man nun erneut auf den Punkt “Persönliche Informationen / KDE Ressourcen”. Dort wählt man in der Ressourcen-Auswahl “Kontakte”. Dann “Hinzufügen”. Im folgenden Dialog “Akonadi-Adressbücher” wählen. Danach erscheinen in einem weiteren Dialogfenster dann die bereits als Akonadi-Ressourcen erfassten reine Akonadi-Adressbücher, aber auch die traditionellen Adressbücher, die inzwischen als Akonadi Ressourcen erfasst und verfügbar gemacht wurden. Hier wählen wir natürlich die Akonadi-Resource “Personal Contacts”. Abschließend klicken wir auf “Anwenden”.
  • Schritt 3: Systemeinstellungen schließen, Kontact schließen, ausloggen, KDE neu starten, einloggen, Kmail öffnen.
  • Schritt 4: Testen, dass beim Schreiben einer neuen Mail die automatische Adress-Vervollständigung mit Adressen aus der neuen Akonadi-Adressbuch-Resource “Personal Contacts” funktioniert.

Die Akonadi Ressource “Personal Contacts” lässt sich übrigens weiter in verschiedene Unterrordner untergliedern. Auch diese Unterordner kann man als aeparate Adressbuch-Ressourcen ansprechen.

Fazit

Unter Opensuse 11.3 und KDE 4.5 kann man traditionelle Adressbücher und Akonadi-Adressbücher nebeneinander mit Kmail verwenden. Schade nur, dass es nicht mit dem Anlegen der jeweiligen Adressbücher unter Kontact getan ist, sondern dass der User zusätzlich manuell “Ressourcen”-Einstellungen in den “Systemeinstellungen” vornehmen muss.

Man versteht, dass die Ressourcenverwaltung unter den KDE-Systemeinstellungen künftig eine sehr weitgehende Flexibilität und sehr feine Anpassungen bzgl. der von den KDE-Programmen tatsächlich einzusetzenden Ressourcen bieten wird. Im Moment ist dies für Kontact-Anwender aber nicht ersichtlich – zumal im Falle von OX-Kalendern tatsächlich ein automatischer Eintrag als KDE-Ressource erfolgt. Hier sollten die KDE-Entwickler die Usability verbessern und weitere Hinweise und Dialoge in Kontacts Adrssbuc-Bereich einbauen.