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.

Als IT-Mensch ist man oft unterwegs und möchte gerne die Zeit mit seinem Laptop für Entwicklungsarbeiten benutzen - in meinem Fall für LAMP-Applikationen. Für derartige Web-Applikationen benötigt man auf einem solchen lokalen Test- und Entwicklungssystem neben einem Apache-Web-Server i.d.R. auch einen lokalen Datenbankserver, den man dann eventuell mit PhpMyAdmin verwalten will. Ich gebe hier ein paar kurze Hinweise zur Installation von MySQL unter Opensuse 11.3. Wir besprechen hier nur die einfachst mögliche Installation. Sind keine speziellen Anforderungen gegeben, reicht das für Entwicklertests vieler einfacher Anwendungen schon aus.

PhpMyAdmin und vermutlich auch die zu testenden PHP-Applikationen erfordern einen bereits vorhandenen Web-Server mit PHP-Modul. Wie man sich den verschafft, habe ich in einem früheren Beitrag dargestellt.

http://linux-blog.anracom.com/2010/07/25/lokaler-apache-test-server-fur-php5/

MySQL-Installation

Die MySQL-Installation unter Opensuse 11 ist mit Yast recht einfach. Für den Server und einige nützliche Tools habe ich folgende Pakete aus dem Standard-SuSE-Repository installiert. (Für aktuellere Versionen und Varianten von MySQl werfe man bei Bedarf einen Blick in folgendes Repository: http://download.opensuse.org/repositories/server:/database/openSUSE_11.3/ )

• mysql-community-server
• mysql-community-server-client (!)
• libmysqlclient16
• libmysqlclient_r16
• libmysqld0
• libqt4-sql-mysql
• php5-mysql
• php5-mbstring
• php5-mcrypt
• php5-zlib
• php5-hash
• mysql-administrator
• mysql-gui-tools
• mysql-query-browser
• mysql-workbench
• mytop
• qt3-mysql
• perl-DBD-mysql

(Nebenbei: Man achte auf die feine Unterscheidung in der Paketbezeichnung, die mit der Übernahme von Sun durch Oracle Einzug gehalten hat. Es heißt jetzt an zwei Stellen : community. Ein Synonym für künftig eingeschränkte Funktionalität? Ich ahne schon, dass ich mich bald wieder intensiv mit Postgres auseinandersetzen werde. Überhaupt tauchen Oracle-Embleme inzwischen an jeder Ecke im Linux-System auf. Da merkt man erst, was wir möglicherweise mit Sun verloren haben. Aber das ist ein Thema für sich …. ).

Die genannten Pakete ziehen unter Yast ggf. die Installation weiterer benötigter Pakete nach sich.

Nach der Installation startet man den Datenbankserver unter Opensuse mit “rcmysql start”. Geht dies fehlerfrei, so setzt man nun ein erforderliches MySQL-Root-Passwort mit

mysqladmin - u root password ‘ein_passendes_Passwort’

(Die Anführungszeichen sind ernst zu nehmen! Der ‘root’-User für MySQL ist übrigens nicht mit dem Linux-System-Verwalter-Account zu verwechseln!).

Alle nachfolgenden Verwaltungsaufgaben - wie die Anlage neuer User und deren Zugriffsrechte von verschiedenen Arbeitsstationen aus - kann man danach mit dem Kommandozeilentool “mysqladmin” oder mit dem grafischen Tool “MySQL Administrator”

/usr/bin/mysql-administrator

durchführen. Letzteres Tool benutzt man für umfassendere Konfigurationsarbeiten bzgl. der Datenbank als (System-) root, da die Hauptkonfigurationsdateien

“/etc/my.cnf”
“/etc/mysqlaccess.conf”

aus Sicherheitsgründen nur für root schreibbar angelegt werden.

Hinweis: Will man sich den “MySQL Administrator” graphisch auf die eigene KDE-Useroberfläche oder in den “Arbeitsflächen-Ordner” legen, so gibt man in der Konfiguration des Plasma-Icons als Programmaufruf

“/usr/bin/xdg-su -c /usr/bin/mysql-administrator”

an - um den grafischen sudo-Berechtigungsdialog für die Eingabe des root-passwords auf den Schirm zu bekommen.

Das Kommandozeilentool “mysql” ruft man über

mysql -u root -p

auf und gibt dann danach das oben gesetzte MySQL-root-Passwort ein.

Für einen lokalen Testserver ist das oben Beschriebene als Ausgangsbasis für weitere Arbeiten (Anlegen und Konfiguration der benötigten Datenbanken und Tabellen) hinreichend. Für eine Produktiv-Umgebung sollte man besser eine “secure installation” durchführen. Genaueres dazu findet man unter den Links am Ende des Artikels.

Minimale PhpMyAdmin-Installation

Für unseren lokalen Testserver wollen wir nun PhpMyAdmin installieren. Auch hier besprechen wir nur die einfachst mögliche Implementierung. Hierzu laden wir uns von der Seite

http://www.phpmyadmin.net/home_page/downloads.php

phpMyAdmin-3.3.5-all-languages.tar.gz

herunter und entpacken die Dateien in einem lokalen Verzeichnis. Wir gehen davon aus, dass unser lokaler Webserver ein DocumentRoot-Verzeichnis

/srv/www/htdocs

aufweist. Wir legen nun ein Verzeichnis

/srv/www/htdocs/phpmyad

an und kopieren dorthin den Inhalt (!) des vorher aus dem tar-Archiv erzeugten Verzeichnisses “phpMyAdmin-3.3.4-all-languages”.

Danach legen wir ein Verzeichnis

/srv/www/htdocs/phpmyad/config

an und machen es temporär für die Welt schreibbar

chmod 757 /srv/www/htdocs/phpmyad/config.

Nun öffnen wir einen lokalen Browser und geben als Adresse an

http://localhost/phpmyad/setup

Auf der neuen Seite drüken wir den Button “Neuer Server”. Im folgenden Dialog “Grundeinstellungen” lassen wir alles unverändert (u.a. den Hostnamen auf “localhost” ) und wählen als Auth-Typ “cookie”. Wir wechseln nun zum Reiter “Serverkonfiguration” und erlauben dort den “root”-Login, damit wir danach Datenbanken anlegen können. Wir speichern dann die Einstellungen. Auf der folgenden Seite wählen wir ggf. “Deutsch” als voreingestellte Sprache und speichern erneut. Wir drücken nun abschließend den Knopf “Laden”.

Im nachfolgenden Schritt kopieren wir die frisch erzeugte config-Datei in das phpmyad-Verzeichnis:

  cp         /srv/www/htdocs/phpmyad/config/config.inc.php          /srv/www/htdocs/phpmyad/

Danach geben wir im Browser ein

http://localhost/phpmyad/

Im nachfolgenden Dialog authentifizieren wir uns als “root” (dies ist der mySQL-root-user) mit dem Passwort, das wir oben am Ende der MySQL-Installation vergeben hatten. Danach sollte die PhpMyAdmin-Oberfläche auftauchen. Nun können wir auf einfache Weise evtl. vorhande Datenbanken importieren, User dazu anlegen und die benötigten Rechte vergeben !

Hinweis:
Die Warnungen und Informationen zur sicheren Verbindung und zur Deaktivierung bestimmter Möglichkeiten sollten uns nachdenklich machen und zu weiteren Arbeiten anregen. Für einen lokalen Testserver ist das ggf. nicht wichtig - wohl aber in Produktivumgebungen! In diesem Beitrag sparen wir uns aber eine Vertiefung.

Abschließender Schritt: Die Schreibrechte auf dem Verzeichnis “config” entfernen wir aus Sicherheitsgründen wieder.

Links

http://de.opensuse.org/MySQL
http://de.opensuse.org/Apache/SSL,_MySQL_und_PHP
http://www.susegeek.com/internet-browser/install-configure-lamp-apachemysqlphp-in-opensuse-110/
http://dev.mysql.com/doc/refman/5.1/de/installing.html
http://dev.mysql.com/doc/refman/5.1/de/default-privileges.html
http://www.howtoforge.com/perfect-server-opensuse11-p4
http://www.unixmen.com/linux-tutorials/237-install-lamp-in-openuse-110-and-111

Ich entwickle oft “PHP 5″-Programme - auch unterwegs. Auf einem Laptop musste ich vor kurzem einen lokalen Apache-Server einrichten, um auch ohne Netzwerkanbindung Programme testen zu können. Der Server sollte natürlich PHP5 unterstützen und für eine bestimmte Testdomaine - “devdomain” - SSL-fähig sein. Hierzu muss man auf die Schnelle virtuelle Domainen einrichten. Das Ganze unter Opensuse 11.3.

Vielleicht ist die nachfolgende Vorgehensweise zur Lösung dieser Aufgabenstellung auch für andere interessant.

/etc/host-Einträge

Der Rechner soll später autonom - d.h. ohne Netzverbindung funktionieren. Ein DNS-Dienst ist für ein rein lokales System überflüssig. Für einen lokalen, autonomen Testserver kann für die notwendigen Einträge in der Datei “/etc/hosts” das Loopback-Interface verwenden. Die Einträge können dann etwa so aussehen:

127.0.0.1         localhost.localdomain         localhost

127.0.0.2         mylap.myprivatedomain.de         mylap

127.0.0.2         devdomain

Der erste Eintrag ist ein Standard Opensuse-Entrag, wie er bei einer automatischen Installation erzeugt wird. Den zweiten benötige ich für andere Programme. Interessant für unsere Problemstellung ist die dritte Zeile. Die dortige IP-Adresse ist u.a. wichtig für das spätere Aufsetzen der IP-basierten virtuellen Domaine “devdomain”.

Es gibt im Internet immer wieder Diskussionen um die Verwendung der Loopback-Adresse - ich denke, die oft angeführten Gegen-Argumente kann man im Zusammenhang mit dem beschriebenen Szenario getrost ignorieren. Ein System mit aktiven Netzwerkschnittstellen benötigt natürlich noch mehr Einträge an passender Stelle in der “/etc/hosts” und ggf. eine Adress-Systematisierung über einen DNS-Server. Aber die Funktionalität eines autonomen Entwicklungs- und Test-Systems ist mit den Loopback-Adressen wirklich in hinreichender Weise gegeben.

Für die korrekte lokale Namensauflösung sollte “files” die Reihenfolge der Ressourcen im “hosts”-Eintrag der Datei “/etc/nsswitch.conf” anführen:

hosts:       files mdns4_minimal [NOTFOUND=return] dns

Grundinstallation Apache

Apache2 kann man unter Opensuse einfach über die Yast und die dortige Paketverwaltung installieren. Folgende Pakete aus dem Opensuse 11.3 Standard-Repository habe ich installiert:

• apache2 (!)
• apache2-devel (!)
• apache2-doc
• apache2-example-pages (!)
• apache2-mod_dnssd
• apache2-mod_perl
• apache2-mod_php5 (!)
• apache2-mod_python
• apache2-prefork (!)
• apache2-utils (!)
• libapr-util1 (!)
• libapr-util1-devel (!)
• libapr1 (!)
• libapr1-devel (!)

Nach der Installation und einem “rcapache2 start” sollte ein

http://localhost

im Browser bereits eine Seite mit dem schönen Text “It works!” anzeigen. Danach trägt man mit Yast den Apache2-Server in die Run-Level-Konfiguration ein, damit er automatisch z.B. in den Levels 3 und 5 gestartet wird.

Grundinstallation PHP5

Für eine relativ umfassende PHP5-Unterstützung sind für mich in der Regel folgende Pakete/Module von Bedeutung:

apache2-mod_php5, php-doc, php5, php5-bcmath, php5-bz2, php5-ctype, php5-devel, php5-dom, php5-gd, php5-hash, php5-iconv, php5-imagick, php5-json, php5-mbstring, php5-mcrypt, php5-mysql, php5-pdo, php5-pear, php5-phar, php5-sqlite, php5-tidy, php5-tokenizer, php5-xdebug, php5-xmlreader, php5-xmlwriter, php5-zip, php5-zlib

Die Zusammenstellung kann für umfangreiche Entwicklungsszenarien natürlich komplexer aussehen.

Hinweis zur Aktualisierung der PHP-Installation:
Um eine aktuelle PHP5-Installation unter Opensuse 11.2 zu erhalten (PHP 5.3.3) muss man ggf. die passenden Repositories unter

http://download.opensuse.org/repositories/server:/php/
http://download.opensuse.org/repositories/server:/php:/extensions/

in die Paketverwaltung einbinden. Über das zweite der genannten Repositories erhält man z.B. das Xdebug-RPM.

Modifikation an der php.ini

Auf einem Entwicklungssystem will man man Fehlermeldunge zu PHP5-Programmen sehen. Evtl. hat man auch Programme, die mit der Kurzform der Script-Tags “” statt lauffähig sein sollen. Um beim Einsatz der Funktion “date()” Warnungen zu vermeiden, stellt man auch die Standardzeitzone für das PHP-Modul ein. Für all das muss man entsprechende Modifikationen an der Datei

“/etc/php5/apache2/php.ini”

vornehmen. Entsprechende Einträge (plus ein paar mehr) :

• short_open_tag = On
• error_reporting = E_ALL & ~E_DEPRECATED
• display_errors = On
• log_errors = On
• ignore_repeated_errors = Off
• ignore_repeated_source = Off
• register_globals = Off (immer gut)
• include_path = “.:/usr/share/php5:/usr/share/php5/PEAR” (PEAR soll funktionieren)
• date.timezone = Europe/Berlin

“Spiel-Zertifikat und SSL-Aktivierung unter Opensuse 11.3

Viele meiner PHP-Frameworks für Kunden erzwingen in der Regel einen HTTPS-Verbindung. Wenn ich das lokal testen will, komme ich um SSL also nicht herum. SSL geht nur über IP-basierte virtuelle Domainen. Für den Standardhost “localhost” ist dann zudem eine zweite separate virtuelle Domaine einzurichten.

SSL geht nicht ohne ein Minimal-Zertifikat. Für lokale Testzwecke reicht ein “Spiel-Zertifikat”. (Im Browser fügt man dann bei Warnungen eine Ausnahmeregel für das Zertifikat ein.)

Unter Opensuse 11.3 erreicht man die notwendige Grundausstattung des Apache-Servers unter Benutzung von Apache-Tools durch folgende Kommandos:

• a2enmod ssl
• a2enflag SSL
• /usr/bin/gensslcert (als root absetzen)
• cp /etc/apache2/vhosts.d/vhost-ssl.template /etc/apache2/vhosts.d/vhost-ssl.conf
• Anpassung der vhost-Dateien (s.u.)

Ein paralleler Blick in die “sysconfig”-Dateien des SUSE-Systems ist hier nicht verkehrt. Dafür kann man z.B. den sysconfig-Editor von Yast heranziehen. Im dortigen kategoriebaum bewegt man sich in den Zweig

“Netzwerke   >>>   WWW   >>>   Apache2″.

Unter dem Eintrag “APACHE_MODULES” sollte man folgendes finden:

authz_host actions alias auth_basic authz_groupfile authn_file authz_user autoindex cgi dir include log_config mime negotiation setenvif status userdir asis imagemap ssl php5 authz_default

Unter dem Eintrag APACHE_SERVER_FLAGS sollte SSL auftauchen:

SSL

Hinweise:

• Ein Extra-RPM für das SSL-Modul muss unter Opensuse 11.3 nicht installiert werden.
• gensslcert erzeugt nur eine Spiel-Cert. Dabei werden folgende Dateien überschrieben:

• /etc/apache2/ssl.crt/ca.crt
• /etc/apache2/ssl.key/server.key
• /etc/apache2/ssl.crt/server.crt
• /etc/apache2/ssl.csr/server.csr

• Der Virtual-Host für die SSL-Domaine muss IP-basiert (!) angelegt werden - also nicht namensbasiert. “*”-Angaben für die IP-Adressen werden mit Fehlermeldungen quittiert. In unserem Beispiel werden für das autonome Testsystem die Loopback-Adressen herangezogen.
• Man darf nicht vergessen, dass man für einen Standardzugang “http://localhost” eine eigene virtuelle Domaine einrichten muss, da es bei virtuellen Domainen ohne Vorkehrungen keinen Standard-Host (Default-Web-Server) mehr gibt.

Konfigurationsdateien

Nachfolgend gebe ich (etwas verkürzt) an, welche Grundeinträge in zwei Konfigurationsdateien unter dem Verzeichnis

/etc/apache2/vhosts.d

notwendig sind, um das Ziel zu erreichen,

• einen Standardhost ohne SSL-Verschlüsselung unter “http://localhost”
• eine Testdomaine “devdomain” für Entwicklungszwecke über “https://devdomain”

ansprechen zu können:

Inhalt der Datei “ip-based_vhosts.conf” für den Standardserver

<VirtualHost *>

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>

Hinweise:

• Der Name der Datei kann beliebig gewählt werden !
• Es wird hier kein “server-name angegeben” !!!! - Default-Server
• Das Root-Verzeichnis für den Standardhost ist hier “/srv/www/htdocs”. Dort sind die Web-Dateien und PHP-Programme anzulegen.

Inhalt der Datei “vhost-ssl.conf” für den IP-basierten, SSL-Server für die Domaine “devdomain”

<IfDefine SSL>

<IfDefine !NOSSL>

<VirtualHost 127.0.0.2:443>

DocumentRoot “/srv/www/htdocs/Entwicklung/devdomain/trunk/”

ServerName devdomain:443

ErrorLog /var/log/apache2/error_log

TransferLog /var/log/apache2/access_log

SSLEngine on

SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL

SSLCertificateFile /etc/apache2/ssl.crt/server.crt

SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

<Files ~ “\.(cgi|shtml|phtml|php3?)$”>

SSLOptions +StdEnvVars

</Files>

<Directory “/srv/www/cgi-bin”>

SSLOptions +StdEnvVars

</Directory>

SetEnvIf User-Agent “.*MSIE.*” \

nokeepalive ssl-unclean-shutdown \

downgrade-1.0 force-response-1.0

CustomLog /var/log/apache2/ssl_request_log ssl_combined

</VirtualHost>

</IfDefine>

</IfDefine>

Hinweise:

• Der Host muss eine IP-Adresse erhalten - hier die lokale Loopback-Adresse.
• Der Servername (vergl. mit /etc/hosts) wird in einer speziellen, separaten Zeile eingetragen.
• Die IP-Adresse muss mit dem angegebenen Namen des Servers auch in der Datei “/etc/hosts” eigetragen sein !
• Das DocumentRoot-Verzeichnis habe ich deshalb mit dem “trunk”-Zweig ausgestattet, um die Verzeichnisstruktur eines an Eclipse angebundenes SVN-Repositories zu berücksichtigen. Das kann man natürlich auch anders machen.

Nach dem Anlegen der Dateien kann man nun die neue Konfiguration nach einem “rcapache2 restart” testen. Dazu legt man im Verzeichnis

/srv/www/htdocs/Entwicklung/devdomain/trunk/

eine kleine Testdatei an oder kopiert die “index.html” aus dem Pfad “/srv/www/htdocs” dorthin. Firefox sollte beim Aufruf der Adresse “https://devdomain” keine SSL-bezogene Fehlermeldung anzeigen, sondern nur wegen des nicht vertrauenswürdigen Zertifikats warnen. Der Warnung begegnet man mit einer dauerhaften Ausnahme-Regel. Danach sollte die Test-Datei angezeigt werden. Taucht wieder Erwarten eine Meldung “ssl_error_rx_record_too_long” auf, so ist etwas an der Apache-Konfiguration faul und man muss nacharbeiten.

Das ist natürlich nur eine Ruck-Zuck-Installation eines lokalen Testservers für den Hausgebrauch auf einem PC oder Laptop. (Ein ordentlich aufgesetzter Apache2 sieht anders aus). Aber mit der obigen Konfiguration lassen sich schon bestens PHP-Programme testen.

Viel Spaß also beim PHP-Entwickeln unterwegs - und natürlich unter Linux !

Links

http://de.opensuse.org/Apache/SSL-Anleitung
http://de.opensuse.org/Apache
http://www.schirmacher.de/display/INFO/Apache+SSL+Zertifikat+erstellen+und+installieren
http://wiki.ubuntuusers.de/Apache/SSL
http://aktuell.de.selfhtml.org/artikel/server/apacheconf/apconf12.htm
http://de.opensuse.org/Apache/Schnellstartanleitung

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht - und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige - wenn auch rekursive - Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems - “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” - siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung

Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse

Damals konnte ich die Adressen des “Default Adressbook” (Akonadi-Ressource), aber auch die Einträge eines unter Akonadi angelegten konventionellen Open-Xchange-Adressbuches (OX-Ressource) nicht unter Kmail nutzen. So funktionierte z.B. die automatische Adress-Vervollständigung während der Erstellung einer Mail nicht mehr. Die Lösung bestand darin, unabhängig von der Ressource “Default-Adressbuch” unter Kontact/Kontakte eine weitere Ressource in Form eines “herkömmlichen” Adressbuches anzulegen. Diese wurde - wenn ich mich recht erinnere - damals als Akonadi-Ressource, aber auch als KDE-Ressource bekannt gemacht.

Gestern setzte sich der Ärger bei der Neuanlage eines Users mit KDE 4.4 erneut fort: Das Anlegen einer “herkömmlichen” Adressbuches unter Kontact/Kontakte reicht definitiv nicht, um die Adressen eines externen Open-Xchange bei der Neuanlage von Mails unter Kontact/Kmail verwenden zu können. Vielmehr ist es notwenig, die externe Adressbuch-Ressource zusätzlich und manuell als KDE-Ressource über die KDE “Systemeinstellungen” anzulegen.

Wie ein normaler Anwender das bei der Einrichtung von Kontact/Kmail erkennen soll, ist mir ein Rätsel ….. aber ich wundere mich langsam über gar nichts mehr ….. und habe den alten Artikel entsprechend abgeändert.

Kaum lässt man Frust ab (siehe den Beitrag von gestern zu Openoffice - “Ärgerliche Probleme der Openoffice Integration in KDE 4), passiert auch schon was. Spät am gestrigen Abend habe ich mir testweise die neueste verfügbare Openoffice-Version von Opensuses OO-”Unstable”-Repository installiert.

OpenOffice.org 3.2.1
OOO320m18 (Build:9502)
ooo-build 3.2.1.2

Nach ersten Tests so aus, als ob die gestern oben beschriebenen Probleme 1 und 2 behoben sind. Die KDE-Dialoge für Öffnen/Speichern kommen schnell und sind sofort bedienbar. Und die Statuszeile ist nun wieder permanent sichtbar und verschwindet nicht mehr bei Fensteränderungen oder Manipulationen am Text.

Nicht behoben ist allerdings der Punkt 3 : Die Checkboxen für die Toolbars werden beim Öffnen des Submenü-Dialogs immer noch mit falschen Flags angezeigt.

Aber: es tut sich was - was Positives ! Ich freue mich …..

Bekanntermaßen halte ich von Amarok 2 im Gegensatz zur alten 1.4 Version nicht viel. Dennoch habe ich mich schon ein wenig gefreut, als der Equalizer vor einiger Zeit wieder auftauchte und manche Leute der MP3-Generation gemerkt haben, dass man doch hin und wieder mal gerne auch eine CD unter Amarok abspielen möchte. Ja, ich fand das eigentlich richtig gut, als ab einer der letzten Versionen Amarok 2 doch tatsächlich CDs erkannte und abspielen wollte. Ich habe sogar extra einen Freund angerufen, als ich das entdeckte …

Die Freude hielt halt mal wieder nicht lange. Denn leider stürzt Amarok 2.3.0 beim Abspielen von CDs oft und unmotiviert ab, während Amarok 1.4.10 bei denselben CDs keinerlei Zicken macht.

Ein solcher Absturz geschah gerade während des Schreibens des letzten Bog-Beitrags. Lustig waren dann aber auch die Absturz-Meldungen. Zunächst erschien das übliche KDE-Absturzfenster. Das allein ist sehenswert.

Der schöne Hinweis auf Deutsch zur Nutzlosigkeit der Felermeldungen wird hier gepaart mit einer norwegischen Erläuterung dafür, was man tun muss, um bessere Fehlermeldungen zu erzeugen.

Nun frage ich mich natürlich, warum Teile des Textes in Norwegisch erscheinen. Es wird doch wohl hoffentlich nichts damit zu tun haben, dass ich mehrere Sprachen in den “System-Settings” eingerichtet habe, um automatische Fehlersuchen auch in norwegischen Texten durchführen zu können (s. den vorletzten Blog-Eintrag)? Ich mag gar nicht darüber nachdenken. Außerdem verstehe ich ja Norwegisch. Also versuche ich, durch Druck auf den Button “Debug-Symbole installieren” den Amarok-Entwicklern zu mehr Informationen zu verhelfen. Dann kam folgende Meldung:

Jetzt natürlich auf Englisch. Und irgendwie habe ich aufgrund der Meldung den berechtigten Eindruck, ich müsse nun selber herausfinden, was ich an Debug-Software für Amarok 2 aus welchem Repository dieser Welt installieren muss. Das demotiviert - und meine Zeit ist begrenzt. Und CD-Abspielen ist ja unter Amarok 1.4 auch unter KDE 4 einwandfrei möglich. Also gebe ich auf und blogge lieber ….

Dennoch: Wenn es noch etwas benötigt hätte, um das zu unterstreichen, was ich im letzten Blog-Eintrag zum generellen Status des KDE4-Anwenders als Beta-Tester gesagt habe, dann war es dieser Amarok-Absturz.

Ich habe Amarok 2 dann übrigens doch nochmal gestartet - denn ein Absturz beim CD-Abspielen läßt sich ja über kurz oder lang reproduzieren. Das Lustige war, dass der Absturz schon am Ende vom ersten ausgewählten Song auf der CD kam. Normalerweise dauert das länger. Aber diesmal kam dann auch die KDE-Absturzmeldung nur kurz - ca. 1,5 Sekunden - und verschwand dann wie von Zauberhand von selbst. Offenbar will die KDE-Welt wirklich keine Fehlermeldungen mehr von mir haben … Auch recht …

Ach, ich liebe Amarok 1.4! Zur Beruhigung meiner Nerven höre ich nun dieselbe CD, bei der Amarok 2 zusammenbricht, seit ca. 70 Minuten ohne jeden Fehler oder Absturz mit der 1.4er-Version an. Was nutzt einem die schöne neue Welt unter KDE4, wenn die zugehörigen Applikationen zwar bunt sind, aber die Funktionalität, die schon mal zur vollen Zufriedenheit da war, entweder nicht mehr vorhanden ist oder schlicht und einfach nicht funktioniert?

Und was nutzen Absturzbotschaften, mit denen ein normaler User nicht mehr umgehen kann, ohne viel Zeit zu investieren? KDE - quo vadis ?

Wieder mal was aus dem schönen, bunten Linux-Alltag. Diesmal zu Openoffice. In letzter Zeit schreibe ich nämlich mal wieder häufiger große Dokumente mit Openoffice Writer (Version 3.2). Leider hat man da unter KDE 4 nicht immer Grund zur Freude.

Hier ein paar der ärgerlichsten Problem, zu denen ich - bis auf eine Ausnahme - leider auch keine Lösung anbieten kann. Die Fehler sind z.T. schon länger bekannt, harren aber ihrer Behebung. Ob das an Problemen mit Qt-Bliotheken unter KDE liegt, kann ich nicht wirklich beurteilen. Ich meine aber, dass alle Punkte ein Zeichen für die problematische Integration von Openoffice (ggf. auch anderen GTK-Applikationen) in den KDE4-Desktop sind.

Fehler Nummer 1: Verzögerungen beim Aufruf der Speicher- und Öffnen-Dialoge

Auf meinem Opensuse 11.2 (64 Bit) mit KDE 4.4.3 ist OO aus den Opensuse-Repositories installiert. Als Standard ist in den OO-Einstellungen vorgegeben, dass für das Speichern von Dateien die KDE-Dialoge gezogen werden sollen. Die öffnen sich auch - oft allerdings erst nach mehreren Sekunden. Selbst nach dem Öffnen des KDE-Dialogs dauert es noch ein weiteres Weilchen, bis dann schließlich auch der Name der Datei editiert werden kann Dieses Problem haben auch andere beschrieben.

http://www.linux-club.de/viewtopic.php?f=24&t=108919&start=0

Was immer da abläuft, dieses Problem läßt sich noch relativ einfach durch folgenden “Trick” umgehen. Man aktiviere unter
“Extras > Optionen > Allgemein” in der Rubrik “Öffnen/Speichern-Dialoge” die Option “OpenOffice.org Dialoge verwenden”. Die Dialogfenster zum Speichern sehen nun etwas anders aus. Sie haben auch einige Nachteile - dafür arbeiten sie aber sehr schnell - wie man es als viel beschäftigter Benutzer gerne hätte. Auf meinem Laptop hat das geradezu Wunder bewirkt.

Fehler Nummer 2: Die OO Statuszeile - Elemente der Fußzeile erscheinen gar nicht oder verschwinden - z.B. bei Änderungen der Fenstergröße

Die Statuszeile im Fußbereich von Writer erscheint unter KDE seit einigen neueren KDE-Versionen 4.3X/4.4X und OO 3.2.X oft nicht mehr vollständig. Genauer: Der Fußleistenbereich ist schon da, aber von den üblichen Elementen erscheinen nur die Rahmen - kein Zoom-Tool, keine Anzeige der Seitenzahlen, keine Anzeige der Sprach etc. ….

Damit geht eine wesentlicher Teil an Information und nützlicher Funktionalität gerade für größere Dokumente verloren. Das Verhalten ist relativ irregulär: Beim Starten im Vollbildmodus ist die Leiste oft noch in voller Bestückung da - nach einigen Aktionen speziell bei Änderungen der Fenstergröße leert sie sich aber wieder. Manchmal hilft ein Klick in den Bereich der Leiste, wo man z.B. das Zoom-Tool erwartet, um es wieder zum Erscheien zu bewegen. Aber das wirkt nicht auf Dauer.

Ich habe mir das Ganze mal unter Gnome angesehen - dort gibt es keine Probleme. Also scheint es was mit der Integration in KDE 4.3/4.4 zu tun zu haben - möglicherweise mit der GTK-Unterstützung in Qt. Mir kommt es so vor, als ob Signale zum Update des entsprechenden Fensterbereichs nicht richtig umgesetzt werden. Als Benutzer finde ich das einfach nur ärgerlich - damit kann man auch keine Werbung für die Kombination KDE4.4 ud OO 3.2 machen.

Dieser Fehler erscheint unter Opensuse bislang unabhängig vom verwendeten Repository für die OO-Pakete (Stable-Zweig und Unstable-Zweig). Er ist auch unabhängig vom KDE-Theme oder den GTK-Einstellungen in den KDE “system-settings”.

Ich kenne hierfür keinen Umgehungstrick. Auch dieser Fehler ist keine neue Sache :

https://bugzilla.novell.com/show_bug.cgi?id=550979
https://bugzilla.novell.com/show_bug.cgi?id=567886

Siehe auch meinen Beitrag in einem Opensuse Forum unter

http://forums.opensuse.org/get-help-here/applications/433096-bugs-openoffice-3-2-a-3.html

Fehler Nummer 3: Checkboxen in den Untermenü-Dialogen - speziell von
“Ansicht >> Symbolleisten”

Die Checkboxen im Submenü für die Aktivierung/Deaktivierung der Toolbars erscheinen praktisch alle gesetzt, wenn man dieses Submenü öffnet. Das hat natürlich mit der Realität nichts zu tun, sondern ist ein Bug. Beim Überfahren der Submenü-Punkte mit der Maus wechseln die Checkboxen nämlich zum tatsächlichen Status. Auch hier liegt offenbar ein Problem in der Signalverarbeitung unter Qt/Gtk vor.

Ansicht beim Öffnen:

Ansicht nach Überfahren mit der Maus

Auch dieses Problem tritt unter Gnome und älteren KDE-Versionen (3.5.X) nicht auf. Es kam mit irgendeiner OO 3.2-Version. Auch hierfür kenne ich persönlich keine Lösung.

Fazit: Fehlende QS ?

Openoffice sollte aus meiner Sicht ein repräsentables Flagschiff im Opensource-Bereich sein. Das Gleiche gilt für KDE 4.4. Für den Anwender sind solche Fehler wie die oben beschriebenen deshalb nicht nur nervig - gerade wenn man von früheren Versionen was anderes gewohnt ist. Ich finde vielmehr, dass solche Dinge Zeit und Geld kosten und einer professonellen Arbeitsumgebung nicht würdig sind.

Man kann nun alles auf Schwierigkeiten mit KDE 4, Qt und auf Trolltech (bzw. inzwischen Nokia) schieben.

Aus meiner Sicht ist das aber nicht der Punkt. Ich glaube schlicht, das die Qualitätssicherung im Opensource-Bereich bei der Kombination von mehreren sich schnell entwickelnden und großen Projekten wie KDE 4 und OO 3.X nicht mehr funktioniert. Denn was ich oben beschrieben habe, ist nur die Spitze eines Eisbergs. Tatsächlich könnte ich mich Tage hinsetzen und ununterbrochen Fehler aus einer Vielzahl von Anwendungen melden. Kein Witz, leider. (Gerade stürzt z.B. Amarok beim Abspielen des vierten Stückes von einer CD aus unerfindlichen Gründen ab, … aber meine Meinung, dass Amarok 2 eh’ besch …en ist, wird sich sowieso nicht mehr ändern .. )

Es ist auch nicht so, dass man gar nicht unter Linux arbeiten könnte. Im Gegenteil. Aber mein Eindruck aus dem letzten Jahr ist zunehmend der, das der Power-User in einer Opensource-Umgebung nichts anderes als ein Beta-Tester wird - für die Einzel-Applikationen, für den Desktop insgesamt und die Integration der Anwednungen in diesen Desktop. Irgendwie fühle ich mich an unheilige Zeiten erinnert, als ich noch Microsoft-Produkte benutzt habe. Liebe Leute - es kostet einfach zuviel Zeit, sich mit solchen Fehlern herumzuschlagen !

Die große Frage ist, wer hier im Opensource-Bereich eigentlich versagt. Die Entwicklungsteams? Die Distributoren? Die Provider der Tools? Oder stößt Open Source mit seinen Tendenzen zur Selbstorganisation wegen der Komplexität der Projekte schlicht an die Grenzen?

Ich stelle nur fest, dass es die Leute am meisten trifft, die täglich mit Opensource-Produkten umgehen wollen oder müssen. Und in einer professionellen Linux-Umgebung mit mehreren hundert Anwendern möchte ich z.Z. nicht derjenige sein, der die Update-Politik für den Desktop verantworten muss.

Bei uns als sehr kleiner Firma kann man fast alles kompensieren. Bei großen Umgebungen mit vielen Benutzern geht das nicht mehr. Als Anwender bei uns stößt man auf Fehler, seufzt und denkt sich seinen Teil. Und dann sind unsere Systeme so reichhaltig bestückt, dass man zur Not immer eine komplette ältere Installation booten kann. Aber diesen Luxus, mehrere Systeme parallel auf jedem Desktop vorzuhalten, kann man sich da draußen in größeren Betrieben kaum leisten.

Aber das Thema Upgrade/Update-Politik unter Linux ist ein eigenes Thema für sich.

Meine Hoffnung ist, dass es bald mal wieder eine Kombination aus KDE 4 und OO gibt, bei der OO rundum gut funktioniert. Die Hoffnung stirbt zuletzt … und solange halte ich auch KDE die Treue. Bemerkenswert fand ich letzte Woche nur den Kommentar eines Arbeitskollegen, der auf Gnome schwört: “Das neue Ubuntu ist echt nicht gut ….” Dabei stehen doch die wirklichen Änderungen im Gnome-Bereich erst an …

Ich merke schon, ich muss mal wieder was Positives schreiben. Werde ich tun. Versprochen…..

Ergänzung 30.05.2010: Was Positives - Problem 1 und 2 sind anscheinend behoben

Kaum lässt man Frust ab, passiert auch schon was. Gestern Abend habe ich mir die neueste verfügbare Openoffice-Version von Opensuses OO-”Unstable”-Repository geholt.

OpenOffice.org 3.2.1
OOO320m18 (Build:9502)
ooo-build 3.2.1.2

Faktisch sieht es nach ersten Tests so aus, als ob die oben beschriebenen Probleme 1 und 2 behoben sind. Die KDE-Dialoge für Öffnen/Speichern kommen schnell und sind sofort bedienbar. Und die Statuszeile ist nun wieder permanent sichtbar.
Nicht behoben ist allerdings der Punkt 3 : Die Checkboxen für die Toolbars werden beim Öffnen des Submenü-Dialogs immer noch mit falschen Flags angezeigt.

Aber: es tut sich was - was Positives ! Ich freue mich …..

Wieder mal ein Beitrag aus dem bunten Linux-Alltag. Diesmal zum Thema Wörterbücher. Auch hier nimmt die Vielfalt und damit die Verwirrung des Anwenders zu, wie ich heute wieder erfahren durfte.

Das Vielfalts-Problem

Meine liebe Anne ist Norwegerin und benutzt ein Opensuse Linux mit deutschem KDE 4. Nun steht sie natürlicherweise immer mal wieder vor folgenden Aufgaben

• Verfassen von E-Mails auf Norwegisch mit Thunderbird
• Verfassen von E-Mails auf Norwegisch auch mal mit Kmail
• Verfassen von norwegischen Texten mit Openoffice

In all diesen Fällen möchte sie natürlich gerne eine Prüfung der Rechtschreibung der Wörter in norwegischer Sprache vornehmen lassen, um Tippfehler schnell korrigieren zu können.

Leider ist es nun nicht so, dass für diese Aufgabe unter Linux/KDE ein einheitlicher Spell-Checking-Mechanismus herangezogen würde, der sich auch einheitlich bedienen ließe. Und deswegen lief bei der guten Anne heute das Linux-Frustrations-Fass mal wieder über - mit der unmissverständlichen Aufforderung, ihr gefälligst ein brauchbares Arbeitsgerät bereitzustellen.

Tatsächlich muss man feststellen, dass in puncto “spell checking” zur Verzweiflung des Anwenders eine Vielfalt blüht, die nicht nur applikations- sondern auch noch versionsabhängig ist. Und in den von meiner Frau benutzten Anwendungen muss man doch recht spezielle Schritte unternehmen, um zum Erfolg zu kommen.

So wurde bei Openoffice mit dem Übergang von OO 2.4 auf OO 3.0 von “myspell” auf “hunspell” gewechselt. Gleichzeitig kam für den Anwender (oder den Admin) die Notwendigkeit, “add-ons” installieren zu müssen. So mancher Admin, der sich nicht um individuelle EInstellungen kümmern mochte, vergaß allerdings, seine Kollegen/innen auf diesen Umstand hinzuweisen.

Ähnliches gilt für Thunderbird und Firefox; auch hier wurde mit der Version 3 auf “hunspell” gewechselt. Blöd nur, dass einige der für Firefox und Thunderbird bereits etablierten “add on” Wörterbucher - leider auch die norwegischen - wegen Kleinigkeiten eine ganze Weile lang nicht mehr mit Firefox Version 3.6 und Thunderbird Version 3.x kompatibel waren.

KDE 4 setzt dagegen auf die GNU “aspell”-engine, die “ispell” ablöste und mit UTF-8 umgehen kann. Hier müssen die notwendigen Basis-Einstellungen für eine Reihe von KDE-Applikationen nicht in den Applikationen selbst, sondern in den KDE-Systemeinstellungen vorgenommen werden.

Was also muss man unter Opensuse 11.2 und KDE 4.4.3 für die oben genannten Anwendungen genau tun, um z.B. ein norwegisches Spell Checking hinzubekommen?

Maßnahmen für KDE und damit auch für Kontact/Kmail

Man installiere (z.B. über Yast) zunächst die erforderlichen “aspell”-Sprach-Pakete (myspell-Pakete nutzen hier nix!). Im Fall von Norwegisch sind das die Pakete “aspell-nb” (bokmaal) und “aspell-nn” (nynorsk). Danach kann man unter KDE4 über die Systemeinstellungen

“Systemeinstellungen >> Land/Region und Sprache >> Rechtschreibprüfung”

kontrollieren, dass die Korrekturmöglichkeiten für die neuen Sprachen zur Verfügung stehen. Die “automatische Prüfung” aktiviert man über die entsprechende Checkbox. Einzelne KDE-Applikationen haben aber wieder eigene Schalter, die die Aktivierung oder Deaktivierung einer automatischen Rechtschreib-Prüfung während der Texteingabe steuern.

Als Standardsprache haben wir in unserem Fall “Deutsch” als Einstellung belassen. (Wenn man aber eher Texte in einer anderen Sprache verfasst, lohnt sich ggf. eine andere Einstellung.)

Unter Kmail setzt man das Spell Checking für Norwegisch dann nach dem Öffnen des Mail-Editors für eine neue E-Mail wie folgt ein:

Erst einmal die “automatische Rechtschreibprüfung” über den Menüpunkt “Optionen >> automatische Rechtschreibprüfung” deaktivieren, um bei der Eingabe des norwegischen Textes nicht von vornherein durch irritierende rote Linien gestört zu werden. Danach die ersten Zeilen schreiben. Dann “Extras >> Rechtschreibung” wählen. In der Dialogbox die richtige norwegische Sprache auswählen und nach Bedarf korrigieren. Danach kann man übrigens die “Automatische Korrektur” auch wieder anschalten. Der Spell Checker merkt sich diese Einstellung für die aktuelle Mail.

Es gibt jedoch ein vereinfachtes Vorgehen: Im Kopf der zu verfassenden Mails kann man sich eine Combox anzeigen lassen, die einem eine Combox “Wörterbuch” zur Sprachauswahl für die zu erstellende Mail anbietet. Diese Anzeige steuert man im E-Mail-Editor über den Menüpunkt “Ansicht” und die dort verfügbaren Optionen.

Das vereinfacht den Einsatz des Spell Checkings pro Mail natürlich kolossal: Im Gegensatz zum oben beschriebenen “Umweg” über die Menüpunkte legt man die für die neue E-Mail geltende Sprache gleich nach dem Öffnen des Mail-Editors fest. Die automatische Korrektur kann dann immer aktiviert bleiben.

Die Combobox ist vor allem dann wirklich sehr nützlich, wenn man abwechselnd Mails in unterschiedlichen Sprachen erstellt und dabei fortlaufend den Spell Checker einsetzen will.

Maßnahmen für Openoffice (OO) 3.x

Zunächst prüft man mit Hilfe des Paketmanagers seines Vertrauens, dass “hunspell” installiert ist. Bei dieser Gelegenheit das Paket für den Openoffice-Thesaurus für “Norwegeisch-Bokmaal” installieren (Paket “OpenOffice_org-thesaurus-nb”), falls das Paket angeboten wird.

Danach ein aktuelles “Add-on” für die norwegische Sprache aus dem Fundus der OO 3 Extensions installieren. Fündig wird man auf der Webseite

http://extensions.services.openoffice.org/en/dictionaries

Von dort lädt man für das Norwegische das oxt-File

“dictionary-no-NO-1.0.oxt”

herunter und installiert es in OO 3.0 über den Menüpunkt “Extras >> Extension Manager”. Danach OO neu starten. (oxt steht für Openoffice extension).

Die Rechtschreibungprüfung steht unter OO 3 ggf. bereits über ein Symbol in der Haupt-Toolbar-Leiste zur Verfügung. Wenn nicht kann man sich die Leiste um das entsprechende Icon erweitern. Ansonsten benutzt man “F7″ und/oder die Sub-Menüpunkte unter dem Menüpunt “Extras” :

“Rechtschreibung und Grammatik, Sprache, Language Tool”

Im Dialogfenster zur “Rechtschreibung und Grammatik” kann man schließlich die Sprache für die Analyse des Dokumentes oder eines markierten Abschnittes auswählen. In unserem Fall stehen nach Installation des oben genannten oxt-Files die zwei norwegischen Sprachen “bokmaal” und “nynorsk” zur verfügung. Die Anwendung der Rechtschreibhilfe im Rahmen des Dialog ist intuitiv möglich. Auch die (begrenzte) Prüfung der Grammatik kann man aktivieren.

Für das Anschalten einer automatischen Prüfung ist ein Punkt unter “Optionen” im Dialog-Fenster zuständig. (Oder alternativ ein Icon in der Toolbar).

Erstellt man Dokumente mit Abschnitten, die in unterschiedlichen Sprachen verfasst sind, legt man die Sprache pro Abschnitt über den Menüpunkt

“Extras >> Sprache >> Für den Absatz ”

fest. Das ist aus meiner Sicht eine wirklich nützliche Funktion! OO merkt sich die Sprach- und damit auch die einzusetzenden Prüf-/Korrektur-Module für die jeweilige Sprache abschnittsweise.

Natürlich kann man aber auch die Sprache für das gesamte Dokument festlegen. Diese Einstellung oder noch globalere sind auch über

“Extras >> Optionen >> Spracheinstellungen >> Sprachen ”

und

“Extras >> Optionen >> Spracheinstellungen >> Linguistik”

möglich. Der letztere Menüpunkt gibt zudem einen interessanten Einblick in die verwendeten Sprach- und Hyphenation-Module - es lohnt sich, da mal reinzuschauen.

Maßnahmen für Thunderbird und Firefox 3.x

Der Entwickler Håvar Henriksen hat für Bokmaal und Nynorsk schon im Jahr 2008 geeignete Wörterbücher als Add-Ons zu den Mozilla-Applikationen zur Verfügung gestellt. Leider liefen diese eine Weile nicht mit den neuesten Versionen von FF und Thunderbird zusammen. In der aktuellen Form der Bereitstellung gibt es aber keine Probleme mehr. Die folgenden Schritte sind praktisch identisch für FF und Thunderbird:

Zunächst den Menüpunkt “Extras >> Add-ons ” anklicken.

Im sich öffnenden Dialog den Menüpunkt “Alle Add-ons ansehen” wählen . Auf der sich öffnenden Webseite in der rechten oberen Combobox den Punkt “Wörterbücher” für die Suche auswählen. Dann die Suche starten und in der Liste blättern. Ca. auf Seite 3 findet man dann die “Norsk Bokmaal ordliste”. Das entsprechende xpi-File

“norsk_bokm__l_ordliste-2.0.10.0-fx+tb+sm.xpi”

lädt man sich am besten auf seinen Rechner herunter (für den Fall späterer Neuinstallationen).

Danach wechselt man wieder zum immer noch offenen “Add-On”-Dialog-Fenster der Mozilla-Applikation (das Fenster hatte man mit “Extras >> Add-ons” geöffnet). Dort findet man links unten einen Button “Installieren …”, den man anklickt. Der Rest der Installation wird über Dialogboxen geführt; man sucht die eben heruntergeladene Datei und startet den Installationsvorgang.

In Thunderbird 3..0.2 bedient man sich des installierten Wörterbuchs nun über einen entsprechenden Punkt in der Toolbar. Hier verbirgt sich rechts neben dem Schalter übrigens (ähnlich wie bei Kmail) auch eine Combobox; diese erlaubt einem, das einzusetzende Wörterbuch für die jeweilige Sprache auf einfache Weise auszuwählen.

Ansonsten kommt man auch über den in diesem Zshg. missverständlich lautenden Menüpunkt “Einstellungen” zum Ziel. Dort findet man den Submenü-Punkt “Rechtschreibprüfung”, den man anklickt. Die sich öffnende Dialogbox ist einfach zu bedienen. Eine automatische Prüfung während der Texteingabe aktiviert man in Thunderbird über “Einstellungen >> Sofort-Rechtschreibprüfung”.

Fazit

Das Einstellen der Rechtschreibprüfung auf der Basis passender Wörterbücher zeichnet sich unter Linux noch durch eine wenig anwenderfreundliche Heterogenität aus, ist aber durchaus möglich. Selbst meien Anne war nach getaner Arbeit zufrieden.

In diesem Sinne wünsche ich den Linux-Usern also viel Spass in Zukunft beim Einsatz des “Spell Checkings” für unterschiedliche Sprachen unter KDE, Kontact/Kmail, Openoffice und Firefox/Thunderbird !

Von den Entwicklern wünsche ich mir dagegen eine Strategie zur Vereinigung der “Spell Checking”-Verfahren.

Anhang 1 - Tastaturlayouts nicht vergessen!

Unter KDE ist es natürlich flankierend wichtig, Tastatur-Layouts einzurichten. Das Norwegische kennt wie vele andere Sprachen auch Sonderzeichen, die auf bestimmte Tasten gelegt sind. Die Anne will beim Tippen in norwegischer Sprache natürlich so arbeiten wie auf einer norwegischen Tastatur.

Zu den Tastatur-Layout-Einstellungen gelangt amn unter KDE 4 über die “Systemeinstellungen >> Land/Region und Sprache >> Tastaturlayout”. Im Dialogfenster aktiviert man die gewünschten Tastaturbelegungen für unterschiedliche Sprachen und das Anzeigesymbol in der KDE Kontroll-Leiste. Da Leute wie die Anne mit unterschiedlichen Anwendungen in unterschiedlichen Sprachen arbeiten, habe ich ihr unter dem Reiter “Umschalt-Einstellungen” das Umschaltverfahren auf die jeweilige “Anwendung” bezogen eingestellt - statt der Einstellung “Global”, die die Sprache für die gesamte Oberfläche und alle Anwendungen umschaltet.

Anhang 2 - KDE-Koffice-Frust

In den aktuellen Koffice2-Programmen funktioniert das Spell Checking unter Opensuse 11.2 und KDE 4.4 überhaupt nicht.

Aber das ist eh’ egal, weil die Koffice-Entwickler nicht willens sind oder zu wenig Ressourcen haben, um das grauenvolle Font-Rendering unter Koffice 2 abzustellen. Die wiederholten Hinweise im Web, doch für KOffice2 bitte das Subpixel-Hinting bei der Font-Glättung abzustellen, ist einfach indiskutabel. Hier wedelt aus Anwendersicht der Schwanz mit dem Hund. KOffice2 soll sich bitte in KDE einfügen und seinen Einsatz nicht von einer Maßnahme abhängig machen, die zur Verschlechterung der Schriftendarstellung auf der gesamten Oberfläche führen würde. Tja, der User hat’s mit einigen KDE-Entwicklern nicht immer leicht. Sorry ….

Links

http://en.wikipedia.org/wiki/MySpell
http://en.wikipedia.org/wiki/Hunspell
http://en.wikipedia.org/wiki/GNU_Aspell

Hier wieder mal eine Geschichte aus dem Linux-Alltag. Gestern kam meine Frau zu mir und wollte unbedingt und kurzfristig ein kleines “KDE 4 -Problem” auf ihrem Opensuse 11.2-System gelöst bekommen.

Auftakt: Reihenfolge-Problem bei Bild-Dateien mit Gross- und Kleinbuchstaben unter Dolphin und Gwenview (KDE 4)

Mein Frau hatte diverse Bilder, die mit 2 verschiedenen Kameras und verschiedenen Chips gemacht worden waren, in einem Verzeichnis zusammengeführt. Im Nachhinein stellte sich dann heraus, dass es Dateibezeichnungen der Form “IMG_xxx.jpg” und der Form “img_xxx” gab. Insgesamt führte dies bei einer Betrachtung der Bilder über “dolphin” und “gwenview” unter KDE zu einer heillosen Verwirrung und “falschen” Reihenfolge der Bilder. Und das in der Gegenwart von Gästen, die natürlich alle Windows benutzen …

In meiner Naivität habe ich meiner lieben Frau in einem ersten Anlauf süffisant empfohlen, doch bitte unter Dolphin eine Sortierung nach dem Dateinamen durchzuführen und dann die großgeschriebenen Files, die alle an erster Stelle erscheinen würden, zu markieren und in einen separaten Ordner zu transportieren. Ganz so einfach gestaltete sich die Angelegenheit dann aber leider nicht - und die dann folgende Schelte hatte ich auch wirklich verdient.

Akt 1: Seltsame Sortierreihenfolge unter Dolphin und Konqueror

Was war das Problem? Der Punkt aus Sicht meiner Frau war der, dass bei der Sortierung in den genannten Programmen die Gross- und Kleinschreibung (scheinbar) nicht beachtet wurde. Dies führte im Fall der Bilder zu einer Vermischung von JPGs aus unterschiedlichen Aufnahme-Situationen. So führte eine Sortierung unter Dolphin nach dem Dateinamen zu einer Reihenfolge wie

img_010.jpg
IMG_010.jpg
IMG_011.jpg
img_012.jpg

wobei die “IMG_xxx” -Dateien eben zu einer anderen Aufnahme-Session gehörten als die “img_xxx”-Dateien.

Nun hatte meine bessere Hälfte natürlich selbst schon ein wenig eigene Recherche betrieben und auch alle ihr zugänglichen Einstellungsoptionen unter KDE durchgekämmt. Am Schluss beklagte sie sich dann vehement darüber, dass Dolphin, Konqueror und Gwenview unter KDE 4 zwar die Option zum Sortieren der angezeigten Dateien nach dem Dateinamen anböten, dass dabei aber eben die Groß/Klein-Schreibung vollständig ignoriert würde. Im Gegensatz zur Suche gäbe es auch keine Option, über die man die Beachtung der Groß/Kleinschreibung hätte aktivieren können. Noch schlimmer: Unter Dolphin reagierten auch Filterkriterien, die man in die zuschaltbare Filterleiste eingeben kann, nicht auf Unterschiede in der Groß/Klein-Schreibung.

Der normale User könne zudem auch unter den Systemeinstellungen keine Option finden, die einer Beachtung der Groß/Kleinschreibung bei Sortiervorgängen unter KDE geichkäme. Und nun wäre sie mit ihrem Latein am Ende und ich sei an der Reihe, was zu tun und zwar schnell - wegen der Gäste. Mein Vorschlag, die Bilder halt “händisch” umzusortieren, wurde mit ungläubigen Blicken und einem Hinweis auf die Anzahl der Bilder abgelehnt - und dann die obligatorische Frage nach dem Leistungsvermögen von Linux und dessen Administratoren, die ein zu diesem System überredet hätten ……

Intermezzo: Problembehebung über die Shell

Um das akute Problem zu beheben griff ich erstmal zu Hausmitteln: Terminalfenster, “cd” in das betroffene Verzeichnis, “mkdir gross” und “mkdir klein” abgesetzt und dann

find . -maxdepth 1 -name “img*” -exec cp -pv {} ./klein \;

sowie

find . -maxdepth 1 -name “IMG*” -exec cp -pv {} ./gross \;

und die Vorführung der Bilder war gerettet.

Akt 2: Ursachenforschung

Aber was war eigentlich mit Sortierung unter KDE los? War das Ganze überhaupt ein KDE-Problem?

Ich musste und muss zu meiner Schande gestehen, dass mir das von meiner Frau präsentierte Verhalten unter KDE noch nie bewusst aufgefallen war. Ich konnte das erst auch nicht so recht glauben. (Im Kopf hatte ich natürlich die klassische ASCII-Reihenfolge und typische Wildcardgeschichten wie “[a-z]”, etc.)

Ich wurde jedoch eines Besseren belehrt, als ich folgenden Test mit “ls” und “sort” in einem Verzeichnis mit 4 Dateien “test_1.txt, test_2.txt, TEST_1.txt, TEST_2.txt” unternahm:

… > ls
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

Das gleiche Ergebnis erschien auch mit

…> ls | sort
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

- und das Durchprobieren diverser Optionen von “sort” änderte rein gar nichts. Das konnte doch nicht wahr sein ! Zur Sicherheit habe ich dann das Gleiche mal mit dem Root-Account ausprobiert - und siehe da, die Reihenfolge war nun wie erwartet:

… # ls
.directory TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Nun wirklich misstrauisch geworden, sehe ich mir die “profile”-Einstellungen der Bash genauer an. Unter SUSE werden dabei Festlegungen unter “/etc/sysconfig” gezogen - interessant ist hier die Datei

/etc/sysconfig/language

mit dem Eintrag

RC_LANG=”de_DE.UTF-8″

Das Kommando “env | grep LANG” brachte denn unter einem normalen Useraccount auch konsistenterweise

LANG=de_DE.UTF-8

als Ergebnis. Hm, das wirkt ja eigentlich nicht so ungewöhnlich. Dann fällt einem ein, dass die LANG-Variable alle anderen “LC_….”-Variablen ersetzt also auch “LC_COLLATE”. Also Quercheck bei root:

… # env | grep LANG
LANG=POSIX

Aha - offenbar war das “Problem” an die Locale-Einstellungen gebunden. Ein Test mit “export LC_ALL=C” (C entspricht hier den Posix-Default-Einstellungen) bestätigte die Vermutung: Ab jetzt erschien auch unter dem normalen User-Acccount die gewünschte Reihenfolge.

…> export LC_ALL=C
…> echo $LC_ALL
C
…> ls | sort
TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Was also war die Konsequenz? Die Sortier-Reihenfolge der “de_DE.UTF-8″- Collation entspricht nicht der gewohnten POSIX- bzw. ASCII-Reihenfolge, die man in jedem Linux-Anfängerkurs eingebläut bekommt.

de_DE.UTF-8 entspricht der Sortierung
“aAbB …. zZ”.

POSIX entspricht dagegen der Sortierung
“AB …Zab … z”

Akt 3: Nachdenken über potentielle Gefahren ?

Nun kam ich richtig ins Grübeln - was würde z.B. beim Verwenden der Wildcardsequenz [a-z] unter der Collation “de_DE.UTF-8″ geschehen?

…> echo $LANG
de_DE.UTF-8
…> rm [a-z]*
…> ls

Tatsächlich ! Alle (!) Dateien - auch die mit großem Anfangsbuchstaben - waren gelöscht worden ! Oh, oh, … Das muss man sich wirklich merken !

Akt 4: Nachlesen unter den GNU-Definition zur Bash und LC_COLLATE

Unter folgender Quelle
http://www.gnu.org/software/bash/manual/bashref.html

liest man dementsprechend Folgendes:

“LC_COLLATE
This variable determines the collation order used when sorting the results of filename expansion, and determines the behavior of range expressions, equivalence classes, and collating sequences within filename expansion and pattern matching (see Filename Expansion). ”

Und bei “filename expansion” findet man:

“The sorting order of characters in range expressions is determined by the current locale and the value of the LC_COLLATE shell variable, if set.

For example, in the default C locale, ‘[a-dx-z]’ is equivalent to ‘[abcdxyz]’. Many locales sort characters in dictionary order, and in these locales ‘[a-dx-z]’ is typically not equivalent to ‘[abcdxyz]’; it might be equivalent to ‘[aBbCcDdxXyYz]’, for example. To obtain the traditional interpretation of ranges in bracket expressions, you can force the use of the C locale by setting the LC_COLLATE or LC_ALL environment variable to the value ‘C’. ”

Fazit und Nachspiel:

Auf neueren Linux-Systemen (wie etwa SUSE 11.2) mit deutscher Lokalisierung wird für normale User meist eine “de_DE.UTF8″-Collation verwendet. Deshalb entspricht die Sortierung und die Abhandlung von Shell-Wildcards wie [a-z] nicht mehr den erwarteten Posix-Verhältnissen ! Das schlägt natürlich auch auf die KDE-Programme durch. (Das Gleiche gilt übrigens auch für Kollationen anderer Sprachbereiche).

Das sollte und muss man natürlich im Kopf behalten!

Die eigentliche potentielle Gefahr liegt aber im Einsatz von Wildcards der Form “[a-z]” bei Dateioperationen, da dadurch keineswegs - wie eigentlich erwartet - immer nur Kleinbuchstaben erfasst werden. Tja, eigentlich weiss man das ja …. theoretisch …. aber denkt man im Alltag wirklich immer drüber nach?

Wenn nicht, lohnt es sich jedenfalls, alte Shellscripts auf eventuelle Probleme, die durch den Einsatz von collation-abhängigen Wildcards verursacht werden könnten, durchzusehen.