Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Opensuse 11.1 und KDE 4.2

Posted on by

Ich bin inzwischen auf Opensuse 11.1 umgestiegen. Die Installation stellte mich vor keine Probleme. KDE 4.1.3 habe ich nach der Installation nur für etwa 30 Minuten benutzt. Nach Aktivieren der entsprechenden Repositories bin ich dann auf KDE 4.2 umgestiegen.

Ich wusste schon, dass ich mit KDE 4.1.3 nicht leben kann, weil u.a. “Kontakt und Kmail” da nur mit Macken laufen. Am übelsten finde ich nach wie vor die Fehler bei der automatischen Suche nach Kontaktadressen beim Eintippen der ersten Buchstaben eines Mailempfängers. Also verwende ich nun KDE 4.2.

Nach einigen Wochen Probiererei musste ich inzwischen feststellen, dass nur eine Kombination von Paketen aus dem KDE-Factory-Repository uns einzelnen Paketen aus dem Unstable-Repository eine stabile und produktiv einsetzbare Umgebung hergibt. Hier muss man sich leider vorsichtig vorantasten – ein Patentrezept habe ich nicht gefunden. Es ist leider nicht immer so, dass die Programme des Factory-Zweiges stabiler und besser wären als die des Unstable-Zweiges. KDE 4 und im besonderen KDE 4.2 sind immer noch Spielwiesen für experimentierfreudige Linuxer … und die Auflösung der Paket-Abhängigkeiten ist manchmal ein Geschäft für sich.

So bin ich bin zeitweise schon komplett von Factory-Versionen auf Unstable-Versionen umgestiegen. Im Moment ist es wieder umgekehrt.

Kontakt läuft inzwischen sehr gut mit meinem (veralteten) OX5 Server zusammen. Nach Installation des Nvidia-Treibers 180.22 sind auch GTK-basierte Applikationen wie Openoffice 3, Eclipse, Firefox etc. gut und ohne Artefakte auf der Plasma-Oberfläche einsetzbar. Compiz läuft in der aktuellsten Version und bereitet mir keine Probleme.

Worüber ärgere ich mich täglich ?

1) Konqueror ist und bleibt ein Sorgenkind. Die Fehler in der Behandlung von Textarea-Feldern nerven ohne Ende. Hinzu kommen erneut aufgetretene und massive Schwierigkeiten bei der Integration des Flashplayers – Konqueror rendert nur die Hintergrundsfarbe im Flashbereich. Ferner gibt es immer wieder sehr eigenwillige Interpretationen von Javascript-Code – ich stolpere stetig über Webseiten, die sowohl Firefox als auch Opera anstandslos bewältigen, während Konqueror sich dabei beinahe übergeben muss.

2) Die Soft-Cursorsteuerung von Konqueror in textarea-Feldern von Webformularen ist ein einziger Krampf. Wer sich das ausgedacht hat …

3) Die meisten angebotenen Plasmoide für die aktuelle KDE 4.2 Oberfläche sind entweder überflüssig oder unausgereift. Ich glaube, ich bin für sowas zu alt …

4) Amarok 2 ist nach meinem Geschmack ein Beispiel für eine echte Fehlentwicklung – zumindest in puncto Layout und Usability. Gimmicks statt Funktionalität, Herzchen statt Ergonomie. Ich bleibe wohl noch für eine geraume Weil bei Amarok 1.4.2 ! Da kann man wenigstens seine Playlisten durch Drag und Drop von aktuell laufenden Songs updaten.

5) Die Applikation zur Überwachung von angeschlossenen externen Geräten (USB, Firwire, etc. ) muss viel mehr Funktionalität bekommen. Es ist schon komisch, wenn man auf einer supermodernen Oberfläche wieder vieles von Hand machen muss.

6) Die problemlose Integration von Java in Browser auf einer x86_64-Architektur werde ich wohl auch unter KDE 4 nicht mehr erleben. Aber das ist ja nicht KDE 4 spezifisch.

7) Der CPU-Overhead der von ksysguard(d) bei der Überwachung von Prozessen und HW-Sensoren erzeugt wird, ist viel zu groß. Gleiches gilt für Amarok 2 – man messe mal die CPU-Belastung mit geöffnetem Amarok2-Fenster im Gegensatz zur CPU-Nutzung bei minimiertem Fenster. Dabei läuft doch unter Amarok 2 gar kein Analyzer fürs Frequenzspektrum mit.

Worüber freue ich mich ?

a) Es kehrt zunehmend Stabilität auf dem KDE 4 -Desktop ein.

b) Kontakt aus dem Factory-Bereich ist auf einem guten Weg und wirklich einsetzbar.

c) Kgpg läuft und arbeitet bisher anstandslos mit Kontact zusammen.

d) Opera wird
zunehmend zu meinem Lieblingsbrowser – aber auch das ist nicht KDE4 spezifisch.

e) Mit Vmware Workstation 6.5.1 kann man auch unter Opensuse 11.1 und KDE 4.2 ohne Probleme arbeiten. Das Zeug ist sein Geld wert.

f) Meine alte Soundblaster Audigy 2 läuft bestens, wenn man in diversen Applikationen (wie Amarok oder Kaffeine) Xine als Backend einsetzt.

Fazit:

Opensuse 11.1 ist gegenüber 11.0 kein wahnsinniger Fortschritt, wenn man bereits unter Opensuse 11.0 KDE 4.1.3 eingesetzt hatte. Aber ich arbeite zunehmend produktiv mit KDE 4 – allerdings gleich mit KDE 4.2 statt mit KDE 4.1.3. Zur Sicherheit halte ich mir aber immer noch KDE 3.5.10 in der Hinterhand.

Nvidia Beta Treiber 180.06

Posted on by

Dieser Treiber ist aus meiner Sicht (trotz Beta-Status) für KDE4-Neugierige (und nicht-produktive Linux-Umgebungen) empfehlenswert.
Es verschwinden nämlich wie von Zauberhand eine Reihe von KDE 4 – Problemen, u.a.:

  • 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.

Virtuelle Domainen

Posted on by

Beim Web-Entwickeln stößt man ab und zu auf das Problem, dass man zum Testen auf seinem Apache2-Webserver schnell mal zwei separate Domainen benötigt, um typische Situation bei Web-Providern nachzustellen:

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
  &
nbsp;  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.