• Artefakte auf den Taskbars beim Einsatz von GTK-Applikationen
• Fehler bei der Darstellung von transparenten Objekten auf Webseiten in Konqueror

Geschwindigkeitseinbußen oder Instabilitäten habe ich unter KDE 4.2 Beta mit Compiz auf einem Opensuse 11.0-System (x86_64) bislang nicht feststellen können.

Auf den gehosteten Servern findet man regelmäßig Verhältnisse vor, bei denen einem in einer abgekapselten “chroot”-Umgebung zwei oder mehr Verzeichnisse bereitgestellt werden, denen dann unterschiedliche Domainen zugeordnet sid oder zugeordnet werden können. Und als Entwickler möchte man gerne domainenübergreifende PHP-Klassenbibliotheken in Verzeichnissen außerhalb der eigentlichen Domainen installieren und testen, ob die Klassen auch ordentlich in allen Domainen gezogen werden …. oder man hat mit ähnlichen domainübergreifenden Problemstellungen zu tun …..(Dass man Bibliotheken in domainunabhängigen, übergeordneten Verzeichnissen des Webservers installiert, hat seinen Grund übrigens nicht nur in der Vermeidung von Doppelpflege, sondern es dient u.U. auch der Sicherheit.)

Möchte man ähnliche Situationen auf einem eigenen Apache-Server nachstellen, greift man am besten - wie der Webprovider auch - zu namensbasierten virtuellen Domainen.
Das folgende einfache Beispiel zeigt, wie man zwei solcher zusätzlicher Domainen auf einem Opensuse-System einrichten kann und wie man dafür sorgt, dass der ursprüngliche Zugriff auf den Server erhalten bleibt. Wir gehen von folgendem Szenario aus: Es laufe ein Webserver unter der beispielhaften Adresse “server.mydomain.de”. Ihm sei die IP-Adresse “192.168.0.10″ zugeordnet. Die DNS-Einstellungen im Netzwerk seien so, dass man den Webserver unter “http://server.mydomain.de” oder “http.//server” erreicht. Der Web-Server selbst sei im Moment so eingerichtet, dass in der Haupt-Konfigurations-Datei

/etc/apache2/http.conf

über eine inkludierte Datei die erforderlichen Port- und SSL-Einstellungen des Webservers vorgegeben werden. Das entsprechende Include-Statement in der httpd.conf findet sich meist an deren Anfang

Include /etc/apache2/listen.conf

Später werde auch die Default-Konfiguration des Servers über eine weitere Konfigurationsdatei (globale Einstellungen für den Defaultserver) in die “httpd.conf” geladen. Dies geschieht z.B. über den Eintrag

Include /etc/apache2/default-server.conf

Ein nachfolgender Eintrag in der httpd.conf sorge dafür, dass Definitionen für virtuelle Domainen aus dem Verzeichnis “/etc/apache2/vhosts.d” geladen werden, sobald wir (s.u.) solche Definitionen angelegt haben:

Include /etc/apache2/vhosts.d/*.conf

Auf andere Einträge in der Datei “httpd.conf” gehen wir im Moment nicht ein, da sie hier nicht von direkter Bedeutung sind.
Folgende Einträge in der “default-server.conf” sorgen vor der Umstellung auf virtuelle Domainen für den reibungslosen Betrieb.

DocumentRoot “/srv/www/htdocs”
<Directory “/srv/www/htdocs”>
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>

Alias /icons/ “/usr/share/apache2/icons/”

<Directory “/usr/share/apache2/icons”>
     Options Indexes MultiViews
     AllowOverride None
     Order allow,deny
     Allow from all
</Directory>
ScriptAlias /cgi-bin/ “/srv/www/cgi-bin/”
<Directory “/srv/www/cgi-bin”>
     AllowOverride None
     Options +ExecCGI -Includes
     Order allow,deny
     Allow from all
</Directory>
<IfModule mod_userdir.c>
     UserDir public_html
     Include /etc/apache2/mod_userdir.conf
</IfModule>
Include /etc/apache2/conf.d/*.conf
Include /etc/apache2/conf.d/apache2-manual?conf

Diese Einstellungen können später pro virtueller Domaine überschrieben werden. Das Apache2-Konzept ist hier sehr modular.

Einrichtung der virtuellen Domainen
Nun richten wir uns 3 virtuelle Domainen ein. Zwei davon werden zwei speziellen Verzeichnissen zugeordnet; die dritte ersetzt den bisherigen “Default-Server”. Die dritte virtuelle Default-Domaine ist deshalb wichtig und notwendig,

• weil bei einem “namebased virtual server” zunächst keine Default-Domaine existiert und der Standard-Default-Server keine Wirkung mehr hat und
• weil man die bisherigen User des Servers nicht dazu zwingen will, ihre Lesezeichen in Ihren Browsern grundlegend zu ändern.

Diese dritte Domaine darf in einer professionell genutzten Umgebung bei der Umstellung nicht vergessen werden.

Für die Umstellung ist zunächst ein Eintrag in der Datei “/etc/apache2/listen.conf” essentiell:

NameVirtualHost 192.168.0.10:80

Nachdem wir das erledigt haben, erstellen wir im Verzeichnis “/etc/apache2/vhosts.d” eine Datei “virtu.conf” für eine virtuelle Domaine “virtu.mydomain.de” mit folgendem Inhalt :

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtu.mydomain.de
     ServerAlias virtu
     DocumentRoot /srv/www/vitualdomains/virtu
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtu”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Beachten Sie den Eintrag zum “DirectoryIndex” und “ServerAlias”. Letzterer macht die neue Domaine auch über eine Abkürzung (http://virtu) anstelle des voll qualifizierten Domainnamens ansprechbar. Der “DirectoryIndex” spezifiziert, welche Dateien aufgerufen werden sollen, wenn als Http-Adresse nur die Domaine (also das Verzeichnis) angesprochen wird. Diese Vorgabe gilt aber auch für Subverzeichnisse. Einträge aus der Datei “default-server.conf” bleiben weiterhin gültig, soweit sie nicht überschrieben wurden. Eine weitere Domaine kann etwas so aussehen:

<VirtualHost 192.168.0.10:80>
     ServerAdmin your_admin_name@mydomain.de
     ServerName virtual.mydomain.de
     ServerAlias virtual
     DocumentRoot /srv/www/vitualdomains/virtual
     HostnameLookups Off
     UseCanonicalName Off
     ServerSignature On
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/virtualdomains/virtual”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Abschließend möchten wir noch den Server mit einer Default-Domaine ausstatten, die für alle sonstigen Zwecke aufgerufen wird, und die der ursprünglichen Serverkonfiguration entspricht:

<VirtualHost 192.168.0.10:80>
     DocumentRoot /srv/www/htdocs
     DirectoryIndex index.html index.html.var index.htm index.php index.php5
     <Directory “/srv/www/htdocs”>
         Options Indexes FollowSymLinks
         AllowOverride None
         Order allow,deny
         Allow from all
     </Directory>
</VirtualHost>

Man erkennt, dass hier der “ServerName”-Eintrag fehlt !
Bleibt nur noch, auf unserem DNS-Server (oder auf dem Client-Rechner in der “/etc/hosts”-Datei) dafür zu sorgen, dass “virtu.mydomain.de” und “virtual.mydomain.de” im Netzwerk auch unter der Adresse “192.168.0.10″ gefunden werden. Danach können wir den Webserver neu starten und erreichen in einem Browser über “http://virtu.mydomain.de” bzw. “http://virtual.mydomain.de” die neuen Domainen. Rufen wir nur “server.mydomain.de” oder “http://192.168.0.10″ auf, so erhalten wir diejenigen Seiten, die auch auf dem urssprünglichen Server schon angezeigt wurden.
Viel Spaß mit den neuen Domainen!
Wenn es funktioniert, dann ist es an der Zeit, sich mit weiteren Varianten und Möglichkeiten von virtuellen Domainen auf einem Apache-Server auseinanderzusetzen. Das obige Beispiel war nur eine sehr einfache Lösung zu fester IP-Adresse und einheitlichem Port.

Problembereich Konqueror
Konqueror unter KDE 4 erscheint mir in vielerlei Hinsicht unausgereift. Die nervigsten Punkte, die ein produktives Arbeiten verhindern, sind:

• Regelmäßige Abstürze bei Multimedia-lastigen Seiten (u.a. mit Flash-Elementen, man gehe nur mal auf die Nvidia-Seiten oder die Seiten der Telekom oder von Vodafone und probiere dort alle Optionen aus),
• Falsche Behandlung und Darstellung von Seiten mit halb-opaquen Designelementen (wie halbtransparenten Menüpunkten); die Darstellung ist z.T. katastrophal bei dynamischen halbtransparenten Objekten. Man sollte solche Elemente lieber noch eine Weile völlig intransparent darstellen als den experimentellen Murks anzubieten, der im Moment vorhanden ist.
• Fehler oder Unsauberkeiten in der Javascript-Engine - im Besonderen bei Querbeziehungen zwischen mehreren geöffneten Fenstern einer Applikation (so kann man PhpMyAdmin z.B. wegen dieser Probleme nicht in vollem Umfang benutzen - wahnsinnig nervig)
• Eine falsche und z.T. chaotische Behandlung von “textarea”-Elementen auf Formularseiten im Zusammenhang mit Mausinteraktionen (falsche Cursordarstellung bei scrollbaren Feldern über dem Scrollbar, falsches Einsprungverhalten bei Maus-Klick auf den Text - vermutlich wg. Fehlberechnung der Scrollposition, etc.) Das macht den Einsatz im Zusammenhang mit formularlastigen Datenbankapplikationen zur Nervensache ….)
• Falsche Breitenberechnung von Input-Elementen bei der Inhaltsdarstellung - zuminest bei verwendung des Oxygen-Designs für die KDE-Oberfläche - auch dies wieder nervig bei formularlastigen Web-Applikationen

All diese Schwierigkeiten tauchen in anderen Browsern (Firefox, Opera) nicht oder nicht in dem Ausmaß auf wie in KDE4’s Konqueror.

Problembereich CPU-Belastung
Generell erscheint mir die CPU-Belastung im Schnitt deutlich höher zu sein als unter KDE 3.5.10.
Ich muss aber dazu sagen, dass ich Compiz im Einsatz habe und hier spielen evtl. auch die Nvidia-Treiber eine Rolle. Auffällig ist z.B., dass aktive, geöffnete Amarok-Fenster zu einem Anstieg der CPU-Belastung von über 10% führen im Gegensatz zu einer Situation, in der das Amarok-Fenster minimiert ist. Die laufenden Bildschirmupdates kosten unter KDE4 scheinbar erhebliche CPU-Zeit.
Dieses Problem gab es früher auch schon mal unter KDE 3.5, war dann aber eine ganze Weile beseitigt.
Aber auch Applikationen wie das neue Ksysguard sind wahre Ressourcenfresser - reale Messungen der CPU-Belastung sind damit fast nicht mehr möglich, weil Ksysguard oft selbst mehr Ressourcen als andere Applikationen schluckt.

Problembereich GTK-basierte Applikationen (Openoffice, VMware Wokstation, etc. )
Es ist wirklich nervig, dass das Arbeiten in und mit GTK-Applikationen zu störenden Nebeneffekten auf der KDE4-Oberfläche führt - u.a. Überdeckung der KDE4 Kontroll-Leiste durch Artefakte. Diese verschwinden wieder, wenn man die Maus in den gestörten Bildschirmbereich bewegt - ärgerlich ist das aber trotzdem. Zumal durch die Artefakte auch Bereiche überdeckt werden, die Informationen beinhalten.
Ob auch dies mit Nvidia-Treibern zusammenhängt konnte ich nicht prüfen; es hängt aber sicher nicht mit Compiz zusammen, sondern ist ein reines Problem zwischen der KDE-Oberfläche und GTK-Applikationen. Das haben auch andere bestätigt.

Probleme mit Notizbüchern unter Kontact
Leider muss ich sagen, dass das Arbeiten mit Notizbüchern unter Kontact ein Glücksspiel ist. Mir sind bereits mehrfach Einträge verlorengegangen. Es fehlt eindeutig eine Option zum Zwischenspeichern eines erarbeiteten Eintrags. Notizbücher sind ein schönes Feature, aber leider noch viel zu unsicher für den produktiven Einsatz.

Als Anwender kann man nur hoffen, dass die Konqueror-Probleme und das generelle Problem mit GTK-Applikationen unter KDE 4 umgehend gelöst werden.

Ich beschränke mich nachfolgend auf die Situation eines Raid 1- Verbundes aus 2 gespiegeltem Platten ohne Hot-Swap-Umgebung.

Zunächst ist interessant, wie man überhaupt erkennt, dass ein Problem vorliegt.

Achte bereits beim Booten des Systems auf Störmeldungen

Bzgl. der Statusüberprüfung eines Raid-Systems möchte ich zunächst auf die 3ware BIOS-Meldungen beim Hochfahren eines Systems hinweisen. Dies betrifft vielleicht weniger Server in Dauerbetrieb; es ist aber dennoch ein interessanter Punkt für Arbeitsstationen. Mir ist selbst schon passiert, dass sich mal ein Kabel gelöst hatte und dass eine Platte im Verbund nicht zur Verfügung stand. Merkt man dies bereits beim Hochfahren und bevor neue Daten auf die noch verfügbare Platte des Arrays geschrieben wurden, so umgeht man ein zeitintensives Rebuild des gesamten Systems.

Ein Array wird beim Booten als “Degraded” gemeldet. Was tun ?

Eine Störungsmeldung wird beim Booten rechts neben der Auflistung der vorhandenen 3ware-Raid-Arrays angezeigt.

Ein ausgefallenes und nicht mehr Fault-tolerantes Raid-Array wird in den BIOS-Status-Meldungen es als “Degraded” beschrieben. Die betroffene defekte oder ggf. abgetrennte Platte erhält im Fehlerfall das Attribut “not in use”.

Je nach Bios-Einstellungen stellt der Controller das defekte Array immer noch als “Exportable” für das darauf enthaltene Betriebssystem zur Verfügung. Solange nicht auch die zweite Platte ausfällt, ist das auch kein Problem.

Ist ein Raid-Array nicht in Ordnung, so sollte man als erstes alle Kabelverbindungen prüfen. Gibt sich das Problem dann, so hat man Glück gehabt.

War die Platte jedoch bereits in der vorhergehenden laufenden Sitzung ausgefallen, so ist ein “Rebuild” des Arrays unvermeidbar - weil bereits Daten im nicht gespiegelten Zustand auf die noch verfügbare Platte geschrieben wurden. Die Platten sind dann also in keinem Fall mehr in einem konsistenten Zustand. Geht man mit ‘Alt-3′ in das Bedienungsmenü des Controllers (3ware-Bios-Manger, 3BM), so erhält man auch eine entsprechende Meldung zur Notwendigkeit des “Rebuilds”.

Bei einem “Rebuild” baut der Controller auf einer neu eingebauten Austausch-Platte ( oder auf der alten Platte, falls nur ein Kabeldefekt zum Ausfall führte ) die Spiegelinformationen von Grund auf neu auf - und zwar auf Basis der noch laufenden Platten des Arrays. Das gilt neben Raid 1 auch für Raid5 oder Raid10 - Systeme.

In einem produktiven Umfeld ist es fast unmöglich, sich nach dem Ausfall zuerst um die Ursachen des Plattendefekts im Detail zu kümmern. Ich persönlich nehme in einem solchen Fall lieber gleich eine Austauschplatte, checke und sichere (!) die Kabelverbindungen und untersuche erst im Nachhinein und in Ruhe, ob und welche Schäden die ausgefallene Platte aufweist. Dann kann man immer noch entscheiden, ob man die wieder einsetzen kann und will.

Also, falls kein “Hot-Swap” vorhanden: Rechner runterfahren, Platte austauschen und beim Booten erneut in das 3BM BIOS-Management-Systems des 3ware-Controllers gehen. An den Fehlermeldungen ändert sich durch den Plattenaustausch übrigens nichts. Dann das Rebuild-Verfahren durch Auswahl des Arrays (Pfeiltasten oder Tab-Taste und Enter im 3BM) und Bedienung der entsprechenden Menüpunkte (Button “Maintain Unit” -> “Rebuild”) einleiten. F8 drücken und dann das vorhandene (oder ein anderes; s.u.) Linux-System booten.

Der Rebuild-Vorgang findet nun im Hintergrund des laufenden Betriebssystems und evtl. über mehrere Stunden hinweg statt. Hierzu erhält man übrigens in den Hinweis-Texten des 3BM Menüs keine Information - der Prozess beeinträchtigt die Systemperformance u.U. in so geringem Maße, dass man davon fast nichts merkt. Das verwirrt Anfänger regelmäßig und man braucht tatsächlich Zusatztools, um etwas über den Status der Restaurierung zu erfahren.

Sicherungen nicht vergessen

Je nach Umgebung und verfügbaren Tools sollte man in die Reparaturarbeiten eine außerplanmäßige Sicherung einplanen. Ist auch die zweite Platte nicht mehr die jüngste, zählt evtl. jede Minute.

Ich habe aus diesem Grund immer zwei gespiegelte Raid-Systeme am Laufen. Auf beiden steht mir jeweils ein bootfähiges Linux-System zur Verfügung. Um die Schreibbelastung während der Restaurierung auf dem defekten Array so gering wie möglich zu halten, boote ich meist das System auf dem anderen Raid-Verbund und führe eine Sicherung der Partitionen des defekten Arrays durch, die ich der Reihe nach mounte. Sicherung und Restaurierung behindern sich gegenseitig - aber ohne Sicherung finde ich das Risiko nach einem Plattenausfall zu hoch.

Hat man nicht den Luxus eines Ersatz-Operativsystems, so meine ich, dass man noch während der Restaurierung mit der Sicherung unverzichtbarer Daten im laufenden System auf externe Medien beginnen sollte. Hierüber kann man sich aber vielleicht streiten.

Statusinformationen zu den 3ware Raid-Systemen im laufenden Betrieb

Spätestens im Fall der Restaurierung eines Raid-Arrays möchte man über den Stand des Rebuilds im laufenden Betrieb informiert werden.
Aber auch sonst liegt es ja nahe, unter Linux immer mal wieder Informationen zu den Raid-Arrays oder Platten anzufragen. (Bzgl. des “Smart”-Tools zur Überwachung des Zustands einzelner Platten an einem 3ware-Controller siehe einen früheren Blogbeitrag.)

Im laufenden Betrieb kann man mit folgenden Tools von 3ware einen Blick auf den Zustand des Raid-Systems werfen:

• tw_cli (Command Line Interface)
• 3DM2 (Daemon mit Java und Browser - Interface)

Beide Tools kann man sich von der 3ware-Website (www.3ware.com) herunterladen und problemlos nach dem Entpacken der Tar-Dateien installieren.

Im Fall von 3DM2 durchläuft man dabei eine Installationsroutine, die die notwendigen Dinge abfragt. Alle notwendigen Informationen zur Installation findet man auf den 3ware Dokumentations-Seiten. Die Tar-Verzeichnisse enthalten zudem umfängliche Info-Dateien im HTML-Format. 3DM2 installiert übrigens auch “tw_cli” mit. Die 3DM2- Installation landet standardmäßig im Verzeichnis “/opt/AMCC“.

Alle Einstellungen von 3DM2 kann man später auch über entsprechende Menüpunkte vornehmen oder verändern.

Zugriff auf 3DM2, Anfangspasswörter und Konfiguration für Benachrichtigungen

Den Zugriff auf die Oberfläche von 3DM2 erhält man bei Standardeinstellungen über einen Browser und die Adresse

https://localhost:888

- also über Port 888.

Hinweis: Die Anfangspasswörter für 3DM2 sind für User und Administrator “3ware”. Die 3DM2 Accounts haben übrigens nichts mit den normalen Linux-User-Accounts zu tun!

Ich habe mir 3DM2 so konfiguriert, dass ich per Mail über Probleme des 3ware-Controllers informiert werde. Dazu beantwortet man am besten schon die entsprechenden Fragen zum entsprechenden Mailserver und zum Mailaccount während der Installation. Später kann man das Benachrichtigungsverhalten unter dem Menüpunkt “3DM2-Settings” einstellen.

So ausgerüstet bekommt man den Ausfall einer Platte in einem Raid-Verbund im laufenden Betrieb automatisch mit.

Informationen zu den 3ware-Raidsystemen mit tw_cli

Mit tw_cli kann man sich als root praktisch alle Statusinformationen zum Raidverbund anzeigen lassen und Maintenance-Maßnahmen einleiten.

Nach dem Starten von tw_cli landet man an einem eigenen Prompt. Dort lässt man sich zunächst mit “show” die Kurzbezeichnung “cX” des Controllers anzeigen und erhält anschließend mit

“/cX show”, in meinem Fall mit “/c6 show”

mehr Informationen. “X” steht dabei für die Nummer - in meinem Fall eine 6.

U.a. erhält man hier Informationen zum Status eines “Rebuild-Prozesses”.

Erste Informationen mit 3DM2

Unter 3DM2 sieht die Statusinformation wie folgt aus

Hier habe ich die Seite “Management->Maintenance” aufgerufen. Man erkennt auch hier den aktuellen Stand eines “Rebuild-Prozesses”.

Für weitere Informationen und mögliche Kommandos zu beiden Tools sei auf die umfängliche Information verwiesen, die unter “/opt/AMCC/Documentation” mit installiert wird.

Plattenausfall im laufenden Betrieb

Das Vorgehen nach einem Plattenausfall im laufenden Betrieb ist übrigens das gleiche wie oben beschrieben: Hat man kein “Hot-Swap” so muss man das System ordentlich herunterfahren, Platte austauschen und den Rebuild nach dem erneuten Booten über 3BM oder die anderen Tools (3DM2 und tw_cli) starten.

Mit “kryptischen” Plattenbezeichnungen waren etwa nachfolgende Einträge im Sensor-Bereich von Ksysguard unter dem Punkt Festplattendurchsatz gemeint :

Ksysguard - Ausschnitt aus dem Sensor-Browser

Festplattendurchsatz

+ 2:0 + 7:0 … … + 7:7 + 8:0 + 8:1 … … + 8:28 + 11:0 + 11:1 (s. Abbdg.)

Nun, hinter den Nummern verbergen sich die “major” und “minor” device numbers. Dieses Wissen allein hilft aber auch nicht direkt weiter. Wichtig war Michael ja die Zuordnung dieser Device-Nummern zu den Plattenpartitionen. Letzere sind dem Administrator natürlich besser geläufig.

Auf einem meiner Systeme gibt es z.B. 11 reguläre Linux-Partitionen (Ext3 und ReiserFS) und 3 NTFS-Partitionen in relativ harmonischer Eintracht. Auf die NTFS-Partitionen wird u.a. von VMware-Instanzen aus zugegriffen. Ist man auf einem solchen System an einer partitionsspezifischen Beobachtung des Plattendurchsatzes interessiert, muss man bei Ksysguard schon wissen, wohin genau man schauen sollte.

Zusatz-Informationen aus dem /proc-FS : /proc/diskstats

Woher bekomme ich nun also die Informationen zum Zusammenhang zwischen “device number” und Partition?

Antwort: Aus dem Kernel, oder besser dem /proc - File-System. Moderne Kernel schreiben nämlich statistische Werte für den Plattendurchsatz mit. (Solche Werte werden z.B. von “sar” ausgewertet.) Harddisk-relevante Informationen findet man unter “/proc/diskstats”.

Nachfolgend ein typischer Auszug des Ergebnisses von “cat diskstats” oder “cat /proc/diskstats”:

user@machine:/proc> cat diskstats
8 0 sda 354415 43112 7631712 3704336 269025 782582 8477712 65951972 0 2135876 69736240
8 1 sda1 784 799 0 0
8 2 sda2 4 8 0 0
8 5 sda5 84 520 0 0
8 6 sda6 515 4114 21 168
8 7 sda7 4225 101288 6085 48624
8 8 sda8 826 841 0 0
8 9 sda9 384 778 0 0
8 10 sda10 390174 7518090 1046963 8375680
8 16 sdb 98498 45267 3730694 1115992 194344 559016 6057920 8996952 0 1112700 10123120
8 17 sdb1 2111 2622 0 0
8 18 sdb2 4 8 0 0
8 21 sdb5 36929 293990 72507 580056
8 22 sdb6 384 778 0 0
8 23 sdb7 1078 1093 0 0
8 24 sdb8 436 780 9 16
8 25 sdb9 814 3450 3 16
8 26 sdb10 1877 2374 0 0
8 27 sdb11 95005 3414382 682211 5457664
8 28 sdb12 4309 5184 0 0

Und nun eine Beschreibung der Felder (die ich übrigens großteils dem ersten unten angegebenen Link entnommen habe):

Feld 1 — major device number
Feld 2 — minor device number
Feld 3 — device name (partition)
Feld 4 — # of reads issued
Feld 5 — # of reads merged,
Feld 6 — # of sectors read
Feld 7 — # of milliseconds spent reading
Feld 8 — # of writes completed
Feld 9 — # of writes merged
Feld 10 — # of sectors written
Feld 11 — # of milliseconds spent writing
Feld 12 — # of I/Os currently in progress
Feld 13 — # of milliseconds spent doing I/Os
Feld 14 — weighted # of milliseconds spent doing I/Os

Man sieht:
Hier ist eine Menge Information enthalten - im besonderen eben auch die Zuordnung der Device-Nummern zu den Partitionen.

Datenaufbereitung in Ksysguard

Das Schöne ist, dass Ksysguard einen Teil dieser Informationen in netter Weise aufbereitet. Im besonderen wird einem die Umrechnung in Bytes/s abgenommen. Man kann nun gezielt Ksysguard-Datenblätter für die Parttionen anlegen, die einen besonders interessieren (s. die Abbildung). Zusammenfassende Informationen liefert übrigens auch das Tool “gkrellm”.

Viel Spaß beim Analysieren des Plattenzugriffs !

Links

http://ubuntuforums.org/showthread.php?t=31213
http://www.meinews.net/festplattenbenutzung-t17640.html
http://utcc.utoronto.ca/~cks/space/blog/linux/DiskIOStats
http://en.opensuse.org/Monitor_your_hard_disk_activity_with_KSysGuard

Generell zum “procfs”:
http://en.wikipedia.org/wiki/Procfs

Da es bei Operationen mit größeren Mailmengen in der Vergangenheit immer wieder Probleme mit einer direkten IMAP-Verbindung von Kmail gab, setzen wir im produktiven Alltag Kontact/Kmail mit einer sogenannten “disconnected imap” - Verbindung ein.

Operationen über viele Mails sind z.B. Suchvorgänge oder Aktionen, die mit konfigurierten Mailfiltern im System zusammenhängen. Klassische Beispiele für Kmail-Filter ergeben sich aus der Einbindung lokaler Virenscanner und von Spamfiltern auf dem Mail-Client.

Die disconnected Imap-Struktur führt zu Replikationen zwischen Server und Client.

• Vorteil: Operationen auf vielen Dateien (wie z.B. Virus Scans) laufen absturzfrei. Es gibt eine lokale Kopie der Inhalte abonnierter Folder. man kann auch “disconnected” arbeiten.
• Nachteil: Lange Ladezeiten und intensive Plattenzugriffe beim Start von Kmail, um unsere vielen Mailverzeichnisse zu aktivieren und in temp. Zwischenspeiche rzu laden. Das ist aber ein einmaliger Vorgang - danach geht das Arbeiten flüssig.

Wo liegen die replizierten Mails lokal auf dem Client ?

Ein Systemadministrator wird regelmäßig auch die Mails in Replikationsverzeichnissen der Clients nach Mails untersuchen lassen wollen - und zwar ohne, dass er Kontact/Kmail überhaupt startet. Ferner ist er evtl. an speziellen und ausführlichen Scans ganz bestimmter Verzeichnisse interessiert und möchte für solche Verzeichnisse also “clamscan” oder andere Werkzeuge mit spezifischen Optionen starten. Für ihn ergibt sich dann die interessante Frage:

Wo legt Kmail eigentlich die Kopien der abonnierten Mailverzeichnisse ab? Antwort:
Unter

• /home/USER/.kde/share/apps/kmail/dimap
• /home/USER/.kde4/share/apps/kmail/dimap

Wie sieht die Verzeichnisstruktur aus ?

In diesen Verzeichnissen findet man (versteckte) “.”-Ordner für sämtliche “disconnected” IMAP-Verbindungen und deren abonnierte Ordner und Subordner. Die Namensgebung der Folder auf dem IMAP-Server spiegelt sich hierbei in der lokalen Namensgebung trotz bestimmter Zusätze von Kmail wieder. Zu Subordnern führen jeweils die Dot-Verzeichnisse, also die mit dem vorangestellten “.”. Der direkte Mail-Inhalt eines Ordners liegt jedoch immer in den dreigliedrigen Subverzeichnissen des Folders ohne (!) den Dot.

Beispiel: Der Ordner “Ralph” sei unter dem Ordner “Freunde” eingehängt. Zum Mailinhalt von “Ralph” führen dann beispielsweise die Pfade:

• /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/cur
• /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/new
• /home/USER/.kde4/share/apps/kmail/dimap/.30585553.directory/.FREUNDE.directory/Ralph/tmp

Trotz der kryptischen Namensgebung für die Mailfiles kann man dort die einzelnen Mails gezielt mit Kmail öffnen. Warum es diese komplizierte Struktur gibt und wozu sie verwendet wird, kann man leicht erraten. Wir gehen hierauf an dieser Stelle nicht weiter ein.

Wichtiger aber ist, dass man mit dieser Verzeichnisstruktur im Kopf lokale Virenscanner regelmäßig und gezielt auf bestimmte Ordner dieses Baums loslassen kann, ohne Kmail überhaupt zu aktivieren und dessen interne Klamav/Clamav-Filter zu bemühen.

Viel Spaß bei der periodischen Mail-Hygiene!

Der Controlbar wird bei der Mausbewegung nicht schnell genug upgedated - im Ergebnis treten Verfälschungen der Icon-Farben oder schwarze Rechtecke auf. Manchmal wird das aktive Bild des Desktop im Hintergrund für einen Augenblick schwarz.

Andere User habend den Bug bestätigt. Er scheint generell bei GTK-Applikationen aufzutreten. Ferner scheint er spezifisch für Nvidia Karten und deren proprietäre Treiber zu sein.

Schade eigentlich - das ist manchmal schon störend. Speziell, wenn Entwickler mit Eclipse (auch GTK abhängig) arbeiten, irritiert so was schon gewaltig …..

Fehlermeldung: Keine CD
Das Programm meldet nach Umstellung des Flags “Digitale Wiedergabe nutzen” unter dem Konfigurationspunkt “Extras”, dass keine CD vorhanden sei. Und dies obwohl einen Augenblick zuvor die CD bei analoger Wiedergabe im gleichen Laufwerk noch erkannt worden war! Man stellt sich unwillkürlich die Frage, ob man überhaupt Audio CDs mit digitaler Datenübertragung abspielen kann.

Beruhigt werde ich dadurch, dass ich man einfach mal “xmms”, “amorak” oder “kaffeine” ausprobiere - dort funktioniert die Wiedergabe nämlich, wenn als zugehöriges Backend “xine” eingestellt ist. (Das ist mein persönlicher Default.)

Lösung: Xine als Backend für KDE 4.1 “Phonon”
Also interessiere ich mich dafür, welches Backend eigentlich für den Sound unter dem aktuellen KDE4.1 verwendet wird. Die zugehörige Info finde ich nach etwas Forschungsarbeit unter dem KDE-Hauptmenüpunkt:

“Configure Desktop->Systemverwaltung->Sound->Backend”.

Dort ist das aktuelle Backend für das vielgerühmte “Phonon”-System eingetragen. Phonon wird standardmäßig von allen KDE-Applikationen - so auch KsCD - genutzt. Das Default-Backend ist “Gstreamer”. Leider hat das aktuelle Gstreamer ein Problem mit der digitalen Extraktion, wie einem eine entspr. Recherche im Internet zeigt.

Auf der Suche nach anderen Backends wird man aber schnell fündig: Es gibt bereits ein “phonon-xine”-Backend ! Das zugehörige rpm ist bei Opensuse schon dabei. Nach der Installation taucht dann tatsächlich “Xine” in der Liste der mögl. Backends für Phonon auf.

Wählt man nun “Xine”, so funktioniert danach auch die die digitale Extraktion aus Audio CDs mit KsCD ! Ich wünsche viel Spaß beim Musikhören unter Linux und KDE 4.1!

P.S.: Ich verwende dazu in der Regel “amarok” - auch für Audio CDs ! Das Erlebnis mit KsCD kam nur vom Herumprobieren !

Mein Fazit ist:

Trotz immer noch vorhandener Fehler, Ungereimtheiten und Unzulänglichkeiten können Neugierige den Umstieg langsam wagen. Funktional bringt es zwar nichts und spürbar schneller scheint mir KDE4 auch nicht zu sein. Aber das Design ist sehr ansprechend, und man spürt an allen Ecken und Enden, dass sich KDE 4 zu etwas Großem mausern wird - ganz im Gegensatz zu MS Vista.

Richtig gut finde ich die neue Version von Kontact und die erweiterten Möglicheiten bzgl. des Journals, der Notizbücher und der Popup Notes. Das Teil macht jetzt richtig Freude und die neuen Tools sind wirklich nützlich. Allein deswegen lohnt sich der Umstieg - zumal die aktuelle 3.5.10-Version richtige Bugs im Zusammenspiel mit OX5 hat.

Aber es läuft bei weiten noch nicht alles so oder vergleichbar, wie man das von KDE 3.5.10 gewohnt war.

Daher auch der Rat : Installiert KDE 4.1 lieber parallel zu KDE 3.5. Die SUSE RPMs machen einem das grundsätzlich leicht - auch wenn man bei der einen oder anderen Applikation dann auch unter KDE 4.1 letztlich doch wieder zur KDE 3-Version zurückgeht. Schön ist an KDE 4.1 nämlich auch, dass man bei vielen Applikationen die Möglichkeit hat, auch die alte Version von KDE 3.5 zu starten.

Bei allen vorher existierenden User-Accounts waren plötzlich die privaten Adresseinträge nicht mehr zugänglich. So etwas ist trotz Sicherung mehr als ärgerlich. Nur die OX-Entwickler wissen vermutlich, wie es zu diesem Missstand kommen konnte. In einer Produktivumgebung ist sowas ein kleines Desaster.

Andererseits lieferte es in unserem Fall auch ein Beispiel dafür, dass man in einer Open Source-Umgebung solche Fehler mit ein wenig Geschick selbst beheben kann. Als nützlichen Nebeneffekt lernten wir dabei auch noch etwas über die Datenstrukturen von OX5, die auf unserem Server in einer Postgres-Datenbank mit der Bezeichnung “openexchange” abgelegt sind.

Der Fehler wurde auf unserem System dadurch sichtbar, dass ein Klick auf das Kontakt-Icon in der Bedienungsleiste des OX-Portals zur Meldung führte, dass man keine Berechtigung für den Zugriff besäße:

Kontakte
“Keine Berechtigung. Für den gewünschten Bereich fehlt Ihnen die Berechtigung.. “.

Daran änderte auch eine explizite neue Rechtevergabe für die betroffenen Accounts über die OX-Administrationsoberfläche leider gar nichts. Dann fiel uns auf, dass der bisher existente Default-Ordner “Kontakte” auch nicht mehr im persönlichen Ordnerbereich angezeigt wurde. Waren die privaten Adressdaten der verschiedenen User-Accounts also überhaupt noch vorhanden?

Kontakte Ordner, Datenbank und LDAP

Adressdaten werden im OX-System in sog. “Kontakte-Ordnern” abgelegt:

• einem speziellen privaten Kontaktordner, der beim Anlegen eines Accounts automatisch erstellt wird (zusammen mit einem Kalender- und Aufgaben-Ordner)
• selbst erstellten weiteren privaten Kontaktordnern,
• einem “globalen Adressbuch”, das firmenweit gültige Adressen bereitstellt,
• und in einem LDAP-Verzeichnisdienst.

Alle angelegten Kontakte tauchen dabei sowohl in der Openexchange Datenbank als auch im LDAP-Verzeichnis auf. Auf beide Quellen kann man unter KDE übrigens mit dem Informationsmanager “KDE Kontact” zugreifen.

In einem ersten Schritt bemühten wir den LDAP-Browser “gq”, um uns ein Bild davon zu verschaffen, welche Adresseinträge eigentlich auf dem LDAP-Server noch vorhanden waren. Mit Erleichterung konnte ich die Vollständigkeit privater Adresseinträge im Zweig

ou=addr,uid=MYSELF,ou=people,dc=MYDOMAIN,dc=de

des LDAP-Baumes feststellen. Meine eingepflegten Adressen war also zumindest dort noch vorhanden. Als nächsten Schritt legte ich dann einen neuen OX-Useraccount an, um herauszufinden, ob durch das Upgrade irgendwelche persönlichen Einstellungen verpfuscht worden waren. Zunächst konnte ich feststellen, dass der Vergleichsaccount
a) bis auf den Namen zu genau den gleichen Basiseinträge im LDAP führte, die auch mein Originalaccount aufwies,
b) und dass der Fehler mit dem Kontakte-Ordner für den neuen Account gar nicht auftauchte !

Die Ursachen für den Fehler waren also wirklich im Upgrade und irgendwelchen irregulären Datenbanktransaktionen für die vorhandenen Accounts zu verdanken.

Tabellen für Kontakte, Defaultordner und Zugriffsrechte in der Datenbank “openexchange”

Also: SSH-Zugriff auf den OX-Server. “su postgres” absetzen und danach mit “psql openexchange” auf die Postgres-Datenbank zugreifen. Ein “\dt” verschafft einem dann einen Überblick über die vorhandenen Tabellen. Nach etlichen Selects und ein wenig Kombinationsvermögen erkennt man schließlich Folgendes:

1. Die “Standardordner” eines Benutzeraccounts sind u.a. in der Tabelle “oxfolder_standardfolders” über Referenzschlüssel eingetragen.
2. Die eigentlichen Ordnereinträge findet man in der Tabelle oxfolder_tree. Der dortige Primary Key entspricht dann für die Defaultordner (u.a. “Kontakte”) eines Users den Referenzschlüsseln in der Tabelle “oxfolder_standardfolders”.
3. Adressdatensätze sind in der Tabelle “prg_contacts” eingetragen. Dort tauchen in entsprechenden Spalten dann natürlich auch Referenzschlüssel zum jeweiligen Ordner und zum User auf. (In dieser Tabelle fand ich dann in schöner Übereinstimmung zum LDAP auch meine privaten Adresseinträge wieder).
4. Die Rechte zu den Ordnern sind in der Tabelle “oxfolder_permissions” eingetragen. (Details der numerischen Rechtekammstruktur lassen sich durch Beispieleinträge mit unterschiedlich vergebenen Rechten analysieren und ermitteln).

Durch Vergleich der Einträge zu meinem Originalaccount in den verschiedenen Tabellen mit entsprechenden Einträgen zu einem frisch angelegten Useraccount konnte ich dann folgende, durch das Upgrade entstandene Defizite ermitteln:

• In der Tabelle “oxfolder_tree” fehlte in der Spalte “owner” der Eintrag des User-Kürzels. Dies war durchgängig für alle Accounts der Fall, die bereits vor dem Upgrade existierten.
• In der Tabelle “oxfolder_permissions” fehlten die Einträge für die Default-Kontakteordner der User völlig.

Nach einem Vergleich mit den Daten eines neuen Accounts konnte wir mit Hilfe von Update- und Insert-Statements die erforderlichen Sätze letztlich recht einfach rekonstruieren. Und siehe da: Danach führte dann auch der Klick auf das “Kontakte”-Ordner-Icon wieder zum gewünschten Ergebnis!

Fazit:

Auch bei einem rel. umfassenden System wie “Open-Xchange” hat man im Fehlerfall (manchmal) eine Chance, diesen selbst zu beheben. Ein echter Vorteil von Open Source-Produkten! Das Auftreten des beschriebenen Problems im Zuge eines Upgrades ist aber dennoch in höchstem Maße ärgerlich!