Knoppix: Keine Internetverbindung mit DSL?

Hatte heute wieder ein kleines Knoppix/Debian-Erlebnis mit meinem Freund Michael:

Er wollte unter Knoppix /Debian sein DSL-Modem testen. Trotz scheinbar erfolgreicher DSL-Konfiguration konnte er aber (scheinbar) keine Verbindungen ins Internet aufbauen. (Zum schon bekannten eventuelle auftretenden Debian-Problem mit der resolv.conf s. den früheren Eintrag zu diesem Thema.) Die Lösung war am Schluss ganz einfach – man muss nur die Vollständigkeit der Netzwerkkonfiguration im Auge behalten. Aber der Reihe nach:

Das Knoppix-System wie das Debian-System benötigen zur DSL-Konfiguration das Programm “pppoeconf”. Hier bearbeitet man brav die gestellten Fragen zum Useraccount und Passwort ab. Diese Daten werden übrigens in die Datei

/etc/ppp/pap-secrets

und

/etc/ppp/peers/dsl-provider

eingetragen. Für den Fall des manuellen Editierens der Dateien: Die Userkennung beim Provider muss in beiden Dateien identisch sein. Weitere Informationen zur grundlegenden Konfiguration liefert die Datei “/usr/share/doc/pppoe/README.Debian.gz” (Zur direkten Ansicht kann man das Kommando “zless” verwenden).

Die nächste Frage, die sich stellt, ist die des Verbindungs-Auf- und Abbaus. Zum Aufbau der Verbindung verwendet man (im einfachsten Fall) den Befehl “pon”:

pon dsl-provider

Der Abbau wird durch das Kommando “poff” erledigt. (Natürlich kann man hier nach entsprechender Konfiguration auch mit anderen Programmen wie “kinternet” arbeiten.)

Ist die Konfiguration erfolgreich verlaufen, so erhält man als Ergebnis von “/sbin/ifconfig” einen Eintrag zu der Schnittstelle “ppp0”. Dieser sollte nach dem Verbindungsaufbau dann auch bereits automatisch eine IP-Adresse zugeordnet worden sein.

Soweit war Michael auch schon gelangt. Dennoch konnte er im Internet keine einzige Webseite aufrufen. Das Problem konnte nach der erfolgreichen Zuordnung einer externen IP-Adresse durch den Provider nur noch an zwei Stellen vorhanden sein – auf der Ebene der IP-Konfiguration oder der Ebene der DNS-Server. Als erstes probierten wir deshalb mehrere “ping”-Abfragen auf bekannte Server (194.25.2.129 – Telekom DNS-Server). Es schlugen bereits die Pings auf vorgegebene IP-Adressen fehl. Also musste das Problem ein Elementares ein. Nach einem Nachdenken bleibt da nur noch eine fehlende oder falsche Konfiguration der Routen übrig. Also haben wir den Befehl

“route” oder “route -v”

abgesetzt. Hier tauchte dann prompt auch kein Eintrag für die Default-Route auf. (Mögl. Grund: ein vorkonfigurierte eth0-Schnittstelle. Jedenfalls mochte Knoppix hier nix selbständig konfigurieren.) Das Routing musste Michael also von Hand erledigen:

route del default
route add default ppp0

Der erste Befehl dient zur Sicherheit zum Löschen der bisherigen Route – falls doch ein (falscher) Default-Routen-Eintrag vorhanden gewesen sein sollte. Der letzte Befehl legt die Route auf ein Device – und nicht auf eine IP-Adresse! Das ist für ein (DSL-) Modem natürlich sinnvoll:

Die IP-Adresse wird ja beim Verbindungsaufbau zugeteilt und kann sich bei jedem Neuaufbau der Verbindung nach außen ändern! ( Arbeitet man dagegen nicht mit einem direkt angeschlossen DSL-Modem sondern mit einem zwischengeschalteten (Firewall-) Router, so ist natürlich dessen statische IP-Adresse für die Default-Route von Interesse.)

Nach dem Setzen der Routen funktionierten bereits die pings auf vorgegebene IP-Adressen im Internet ! Natürlich gilt hier: die obige Routenkonfiguration ist der einfachste Fall für einen Standalone-Rechner mit Internet-Anbindung über ein DSL-Modem. Ansonsten muss man das Routing natürlich auf seine speziellen Netzwerkbedürfnisse hin konfigurieren.

(Die Beschreibung von Routing-Konfigurationen führen an dieser Stelle zu weit. Wie man seine Netzwerk-
und Routing-Daten in den Debian Startup-Skripten permanent hinterlegt, lese man bitte unter den letzten zwei der unten angegebenen Links und dortigen weiterführenden Adressen nach. Bzgl. des Zwischenspeicherns der Konfigurationsdaten zu einem Knoppix-Live-System auf einem USB-Stick hilft der Artikel “http://www.easylinux.de/Artikel/ausgabe/2004/08/024-knoppix/” weiter.)

Abschließend lohnt sich nun noch ein Blick in die Datei “/etc/resolv.conf”. Hier muss man prüfen, ob die DNS-Server des Service-Providers korrekt eingetragen sind.

Achtung:
Einige Service-Provider sind inzwischen dazu übergegangen, nur noch ihre eigenen DNS-Server für Abfragen auf dem Port 53 zuzulassen. Also testweise auch mal den vom Provider vorgegebenen Nameserver eintragen, wenn die Namensauflösung trotz gelungener Internet-Anbindung nicht funktionieren sollte.

Michael kann nun endlich sein DSL-Modem ausgiebig unter Knoppix testen. Er sollte aber auch nicht vergessen, seine Firewall zu starten!

http://www.easylinux.de/Artikel/ausgabe/2004/08/024-knoppix
http://channel.debian.de/faq/ch-confignet.html
http://www.linux-user.de/ausgabe/2001/08/018-rp-pppoe/rp-pppoe.html
http://wiki.debian.org/NetworkConfiguration
http://www.tldp.org/HOWTO/NET3-4-HOWTO.html
http://www.debian.org/doc/manuals/reference/ch-gateway.de.html

Vertikale <LI>-Abstände im MS IE7 und FF

Hier noch ein Nachtrag zu den letzten Beiträgen in dieser Kategorie:

Den vertikalen Abstand zwischen den LI-Elementen in vertikal orientierten Listen steuert man zumeist mit einer Vorgabe von “margin-top” und/oder “margin-bottom” für das LI-Element. Vergleicht man solche vertikal aufgebaute Listen anschließend bzgl. ihrer Darstellung im MS IE 7 und im Firefox, so fällt einem leider oftmals auf, dass der Internet Explorer um einige Pixel größere Abstände zwischen Listenelementen zeichnet als der FF.

Im Internet findet man hierzu vielfach den Tip mit

< li style =”clear:left; float:left; margin-bottom: …. ” >

zu arbeiten. Wir meinen, dass dies
1) einen künstlichen Missbrauch der float-Anweisung darstellt,
2) unerwünschte Nebenwirkungen haben kann (s. hierzu einen früheren Beitrag in dieser Kategorie)
3) keinesfalls immer hilft, das Problem zu lösen.

Wir empfehlen Ihnen dagegen, zunächst folgende Tipps auszuprobieren, um vertikale Abstände in Listen im FF und MS IE aneinander anzugleichen.

Tipp 1: Besondere Behandlung von Bildern in <LI>-Tags

Man prüfe, ob sich innerhalb der LI-Elemente <IMG>-Tags befinden. In diesem Fall dichtet der MS IE7 grundsätzlich mindestens 1 Pixel zum per CSS vorgegebenen Abstand zwischen den LI-Elementen hinzu. I.d.R. hilft es auch nichts, das <IMG>-Tag in einem <DIV>-Tag zu kapseln. Sehr wohl hilft dagegen aber eine Darstellung des <IMG>-Tags als “Block”-Element, z.B über eine CSS-Vorgabe für die IMGs der betroffenen Liste:

ul#mein_ul li img { display:block; }

Es war für uns ein regelrechtes Schlüsselerlebnis, nach diesem kleinen Trick feststellen zu dürfen, dass plötzlich die vertikalen Abstände zwischen LI-Elementen im MS IE7 und FF gleich wurden.

Tipp 2: Vorgbe von position:relative; vertical-align:top für das <LI>-Tag

Sind unabhängig von Bildern weiterhin unerklärliche Differenzen in den Abständen zwischen FF und MS IE festzustellen, so hilft sehr oft ein Hinzufügen folgender CSS-Vorgaben für das LI-Element:

li { position:relative; vertical-align:top; ….. }

In folgendem Beispiel mussten wir eine Liste mit Bildern unterschiedlicher Höhe formatieren und haben die Tipps 1 und 2 wie folgt kombiniert, um im MS IE und im FF auf gleiche Abstände zwischen den LI-Elementen zu kommen:

ul#img_list { position:relative; width:10.0em; list-style-type:none; margin-left:0.0em; margin-top:0.4em; padding:0.0em; }
ul#img_list li { position:relative; vertical-align:top; margin-top:0.0em; margin-bottom:2.0em; padding:0.0em;line-height:1.6em; min-height:8.0em; }
ul#img_list li img { display:block; }

Tipp 3: Korrekter Abschluss von float-Direktiven im <LI>-Tag

In einem der letzten Beiträge hatte ich diskutiert, dass man innerhalb eines <LI>-Tags durchaus Positionierungen mit float-Direktiven vornehmen kann. Typisch wäre etwa ein Konstruktion der Art

<li>
   <div style=”float:left; …. ” >DIV-Inhalt A</div>
   <div style=”float:left; margin-left:1.0em; … ” >DIV-Inhalt B</div>
   <div style=”float:right; … ” >DIV-Inhalt C</div>
</li>

oder noch Komplexeres. Das Manko am obigen Code ist natürlich, dass die Float-Befehle wieder aufgehoben werden müssen, damit beide Browser das umgebende und die nachfolgenden <LI>-Elemente korrekt und vor allem mit korrekter Höhe aufbauen. Zum “clear” der “float”-Anweisungen kann man folgende <P>-Tag-Anweisung verwenden:

<li>
   <div style=”float:left; …. ” >DIV-Inhalt A</div>
   <div style=”float:left; margin-left:1.0em; … ” >DIV-Inhalt B</div>
   <div style=”float:right; … ” >DIV-Inhalt C</div>
 &
nbsp; <p style=”clear:both; font-size:0px; line-height:0px; margin-top:20px; height:0px;”>&nbsp;</p>
</li>

Hierbei schließt das <P>-Tag nicht nur die “float”-Direktiven ab. Das Tag sebst soll in unserem Beispiel keine Höhe aufweisen, aber einen Abstand unterhalb der DIVs erzeugen (“margin-top” !) und damit auch die Höhe des umgebenden <LI>-Tags beeinflussen. Wir diskutieren diesen sehr allgemeinen Fall; natürlich steht es jedem frei, die margins anders zu setzen.

Essentiell ist hierbei im MS IE7 das “height:0px”. Ohne diese Anweisung wird leider unabhängig von den sonstigen Anweisungen der Schriftzug im MS IE7 mindestens 1px einnehmen.

Für den FF ist ferner die explizite Angabe von &nbsp; essentiell – im besonderen dann, wenn dass <P>-Tag auch noch die Rolle eines vertikalen Abstandshalters mit einem “margin-top:20px;” spielen soll. Die “margin-top”-Anweisung würde bei einem

<p …..> </p>

im FF schlicht ignoriert werden, während der MS IE 7 auch in diesem Fall die “margin-top”-Anweisung beachten würde !

Tipp 3: Bei verschachtelten Listen nach der inneren Liste ein <p>-Tag einfügen

Bei verschachtelten Listen der Art

<ul>
   <li>
      <ul>
      <li>
…..
…..
      </li>
   </ul>
<ul>

behandelt der MS IE 7 z.B. die Kombination von “margin-bottom”-Anweisungen für das letzte innere <LI> mit “margin-bottom”-Anweisungen für das äußere <LI> anders als der FF. Um den Firefox dazu zu zwingen, die LI-Elemente nicht zusammenzuschieben, kann es nützlich sein, im Anschluß an das innere </ul> ein künstliches <P>-Tag mit 0 Ausdehnung einzuführen (ähnlich wie in Tipp 3).

<ul>
   <li>
      <ul>
      <li>
…..
…..
      </li>
   </ul>
   <p style=”font-size:0px; line-height:0px; margin-top:20px; height:0px;”>&nbsp;</p>
<ul>

Tipp 4: Kapseln von Formularelementen in DIVs passender Höhe innerhalb von LI-Elementen mit ausreichender Höhe

Hat man die Abstände zwischen den LI-Elementen standardisiert, so kann es bei Listen mit Formularelementen auch innerhalb eines LI-Elementes zu Höhenunterschieden zwischen dem FF und dem MS IE kommen. Gerade der MS IE dichtet zu Formular-Elementen wie dem INPUT- und dem TEXTAREA-Feld gerne eigene Außenabstände hinzu, die im Ergebnis zu größeren Höhen des LI-Elementes im MS IE 7 im Gegensatz zum Firefox führen können.

Bei Formularelementen innerhalb von Listenelementen lohnt es sich deshalb, die Höhe des LI-Elementes so vorzugeben, dass das Formularelement inkl. einiger Pixel Außenabstand sicher in das LI-Element hineinpasst und das Textarea-Feld oder Input-Element zusätzlich in ein DIV einzubinden. Bei mit PHP dynamisch erzeugten Textarea oder Input-Feldern ist es also notwendig, die Höhe der LI-Elemente beim Generieren der Liste bereits passend zu berechnen und dem LI-Element danach eine hinreichende Höhe per “height”-Anweisung in einem “style”-Attribut mitzugeben.

Ausgangsbasis ist dabei aber immer eine “height”-Vorgabe für die Formularfelder selbst!

Bei Textarea-Elementen sollte man bei der Höhenformatierung eher mit einer CSS-height-Vorgabe anstelle des “row”-Attributs arbeiten, um Höhenwerte im MS IE 7 zu bekommen, die mit denen des FF identisch sind.

Mit Hilfe der Tipps 1 bis 3 haben wir es praktisch immer geschafft, vertikal orientierte Listen so hinzubekommen, dass sie im MS IE und FF bzgl. des (vertikalen) Zwischenraums zwischen den Listenelementen und auch bzgl. der Höhe der Listenelemente identisch aussahen.

Smartd und 3ware Raid

Vor kurzem bin ich über eine Kleinigkeit gestolpert, die mich auf meiner Linux-Arbeitsstation schon lange nervt, die ich bis jetzt aber nie behoben habe. Der PC ist mit einem 3ware Raid-Controller ausgestattet, der 2 mit RAID 1 Subsysteme (also insgesamt 4 Festplatten, von Samsung) verwaltet. Da die Platten in die Jahre kommen, dachte ich mir, dass ich mit Smart und dem smartd-Dämon doch mal den Zustand der Platten verifizieren könnte.

Ein Blick in die Dateien “/var/log/boot.msg” und “/var/log/messages” meines Opensuse 10.3-Linux Systems belehrt mich darüber,

1) dass auf meinem System der smartd-Dämon bereits vorhanden ist (Smart ist also vorinstalliert)

2) dass der Start von “smartd” bisher mit Fehlermeldungen abbrach.

Pkt. 1 wird durch einen Blick ins Paketmanagement bestätigt. Das Paket “smartmontools” liegt in der aktuellen Version vor. Die Ursache für das Versagen gem. Pkt. 2 ist das Raid-System, mit dem Smart ohne Zusatzbefehle nicht klarkommt. Für den 3ware-Controller müssen Zusatzoptionen verwendet werden. Nach Studieren der Man-Seiten probieren wir:

smartctl -a -d 3ware,0 -F samsung /dev/twa0

Dabei steht “-d 3ware,N” für die N-te Platte am Raidcontroller (gezählt wird ab 0!) und “/dev/twa0” für das Raiddevice. Die Option “-F samsung” berücksichtigt spezifische Samsung Vorgaben für die Platten, die sich in meinem Fall auch im Katalog von smartd befinden (s. smartctl -P show …. bzw. smartctl -P showall).

Um die richtigen Einstallungen für den smartd-Dämon im System für den nächsten Startup zu hinterlegen, füge ich der Datei “/etc/smartd.conf” folgende Zeilen hinzu:

/dev/twa0 -d 3ware,0 -a -F samsung
/dev/twa0 -d 3ware,1 -a -F samsung
/dev/twa0 -d 3ware,2 -a -F samsung
/dev/twa0 -d 3ware,3 -a -F samsung

Nun startet der Dämon korrekt (wie auch ein “rcsmartd restart” zeigt).

Bei nächster Gelegenheit (keine User, runlevel 1) führe ich dann mit Hilfe von smartctl dann auch einen ausführlichen Selbsttest der Platten durch. Gott sei Dank mit gutem Ergebnis. Hierzu lese man in den man-pages nach. Auf die Möglichkeit eines Kurztestes, z.B. mittels

smartctl -a -d 3ware,2 -F samsung /dev/twa0 -t short

sei hingewiesen. Die Ergebnisse kann man z.B. im 2 Minuten Takt mit

smartctl -a -d 3ware,2 -F samsung2 /dev/twa0 -l selftest

abfragen. Dabei erhält man im oberen Ausgabebereich auch Informationen dazu, wie weit der Test bereits vorangeschritten ist.

Debian – Leere resolv.conf nach Neustart

Gerade hatte ich ein denkwürdiges Erlebnis zusammen mit meinem Freund Michael, das uns beide etliche Nerven gekostet hat. Es ging dabei um eine WLAN-Konfiguration auf einem Laptop. Interessanterweise scheiterten wir dabei nicht an der WLAN-Karte, sondern an elementaren Schwierigkeiten mit der lokalen Konfiguration der “/etc/resolv.conf” – also etwas sehr Trivialem.

Michaels Begeisterung für Debian hat bei dem nachfolgend geschilderten Erlebnis doch einen kleinen Knacks bekommen. (Ich persönlich stehe ja eh’ mehr auf SuSE – eine Vergleichsinstallation auf einem Laptop mit einer Intel 3945 WLAN Karte lief auf Anhieb. Für Debian muss man halt doch immer deutlich mehr Zeit haben und strapazierfähige Nerven mitbringen …. )

WLAN-Karte erfordert Firmware

Michael wollte Debian Lenny auf einem etwas älteren Laptop für seine Tochter installieren – in der begründeten Hoffnung, dass dann auch Debian mit der Hardware zurechtkommen würde … ) Alles verlief denn auch ganz gut, bis es an die Netzwerkkonfiguration seiner WLAN-Karte ging. Es handelte sich um einen schon betagten Intel-Chip, der vom Modul “ipw2200” unterstützt wird. Obwohl das Modul anstandslos geladen wurde, lief dann aber erstmal gar nichts. Vom System wurde kein entsprechendes Netzwerkinterface für die IP-Konfiguration angeboten. Nach einigem Forschen im Internet stellte sich dann heraus, dass man unter Debian auch noch Firmware von der Adresse

http://ipw2200.sourceforge.net/firmware.php

herunterladen muss – ohne diese Firmware läuft die Karte nicht (vergl. mit “http://faq.pathfinderteam.org/index.php/Ipw2200”).

Wichtig ist hierbei übrigens auch, dass zum Einspielen der Firmware ein voller Restart des Systems erforderlich ist. Erst danach wird die Firmware geladen und dass WLAN-Device umfassend über das Kernelmodul angesprochen. Im Anschluss war die Karte denn auch mit “iwconfig” konfigurierbar. Wir kamen nach den üblichen Netzwerkeinstellungen und mit einer manuell konfigurierten “/etc/resolv.conf” schließlich auch anstandslos ins Internet. So weit , so gut …..

Dauerhafte Netzwerkkonfiguration mit “network-admin”

Nun möchte man aber auch unter Debian alle Netzwerkeinstellungen persistent machen. Damit die Netzwerkkonfiguration einen System-Neustart überlebt, müssen natürlich Vorgaben für Startup-Skripte gesetzt und gespeichert werden. Ein zugehöriges graphisches Programm für diese Aufgabe stellt unter Debian “network-admin” dar (siehe etwa http://www.debianadmin.com/debian-networking-for-basic-and-advanced-users.html).

Wohlgemut gingen wir an die Arbeit. Die Default-Einträge für den Rechner und die zugehörigen Domaine muss man natürlich an seine Bedürfnisse anpassen. Gleiches gilt für die Default-Gateway-Adresse. Wir wiesen dem Netzwerk-Interface anfänglich eine statische Adresse zu, die mit dem WLAN-Router kompatibel war. Abschließend legten wir über “network-admin” die Adressen der DNS-Server fest. Ein kurzer Test der Internetverbindung nach einem “/etc/init.d/networking restart” verlief denn auch erfolgreich.

Leere /etc/resolv.conf nach Neustart des Debian-Systems

Dann tauchte aber ein Problem auf, dass wir nur nach stundenlangem Rätseln und herumprobieren lösen konnten: Ein Restart des Systems führte jedesmal zu einer leeren Datei “/etc/resolv.conf” ! Und wer hat schon Lust, nach einem Systemstart immer wieder die DNS-Adressen manuell zu setzen ……

Dass das Netzwerk wegen einer evtl. falschen Runlevel-Konfiguration nicht richtig gestartet wurde, konnten wir nach kurzer Zeit ausschließen. Alles war OK und keine (andere) netzwerkrelevante Konfigurationsdatei wurde beim Systemstart geändert – außer eben der “resolv.conf”. (Die “/etc/network/interfaces” etwa enthält genau die gewünschten Einträge.) Nun
ging das Rätseln los:

  • Lief etwa ungewollt “bind9/named” und überschrieb aus dieser Ecke irgendwas die resolv.conf? Antwort: Nein.
  • Lief “dhcp” und überschrieb evtl. ein DHCP-Server die Einträge? Antwort auch hier wieder: Nein. Der einzige DHCP-Serve im Netz wurde deaktiviert und das dhcp-client-Paket haben wir schließlich explizit vom Laptop deinstalliert. Einen Eintrag “iface ethX …. dhcp” gab es in der Datei “/etc/network/interfaces” auch nicht – sondern korrekterweise “iface ethX inet static”.
  • Wurde etwa beim Starten der der graphischen Oberfläche ein Programm gestartet, dass sich an der resolv.conf zu schaffen machte? Auch das konnten wir ausschließen.

 

Bösewicht “resolvconf”

Später fiel uns dann bei einem Suchlauf auf, dass es auch ein Programm “/etc/resolvconf” und ein zugehöriges Package gab. Bei genauem Hinsehen erkannten wir zusätzlich, dass die Datei “/etc/resolv.conf” eigentlich einen Link zu einer Datei “/etc/resolvconf/run/resolv.conf” darstellte. Das machte uns dann doch sehr misstrauisch. Testhalber haben wir dann das zugrundeliegende Package komplett entfernt:

“apt-get –purge remove resolvconf”.

Und man glaubt es kaum: Danach blieb bei einem Systemneustart die /etc/resolv.conf erhalten !!!!
Resolvconf überschrieb uns beim Systemstart immer unsere DNS-Server-Adressen mit Leereinträgen!

Das muss man erstmal wissen ! Auf meinen SUSE-Systemen gibt es keine Spur eines resolvconf-Paketes. Das Programm “resolvconf” dient unter Debian wohl zur Anpassung von DNS-Einträgen durch verschiedene Programme zur Laufzeit. Die Standard-Datei “/etc/resolv.conf” wird dabei in den angebenen Link verwandelt. Die Zieldatei ist dabei nicht für manuelle Einträge gedacht.

Lösungsmöglichkeiten

Für einfach Systeme, die keinen dynamischen Update der Nameserver-Konfiguration während der Laufzeit benötigen, kann man auf das optionale “resolvconf”-Paket anscheinend verzichten. Wir sind diesen Weg gegangen. Erste Hinweise, was man bei Problemen mit einem laufenden “resolvconf” tun kann, liefert übrigens der Abschnitt zu “resolvconf” unter folgender Adresse:

http://wiki.debian.org/NetworkConfiguration

In unserem Fall hätten wir das Problem wohl auch durch einen zusätzlichen Eintrag in der “/etc/network/interfaces” folgender Art

dns-nameservers ip-adr1 ip-adr2

lösen können. Diesen Eintrag muss man eingerückt hinter dem Gateway-Eintrag platzieren.
(Weitere Hinweise gibt die Datei “/usr/share/doc/resolvconf/README”)

Fazit
Wie gesagt: Das muss man alles erstmal wissen. Ist halt Debian …. nix für einfach gestrickte Gemüter, die an schnelle Lösungen mit Linux glauben wollen …. (sorry, Michael!)

Links:
http://wiki.debian.org/NetworkConfiguration
http://www.debianadmin.com/debian-networking-for-basic-and-advanced-users.html”
http://www.debian.org/doc/manuals/reference/ch-gateway.de.html
http://www.technovelty.de/debian-nameserver-mit-resolvconf-eintragen/

Openoffice – Fremdsprachen-Dictionaries

Meine Frau und ich müssen ab und zu diverse Texte in Norwegisch verfassen. Dabei ist es durchaus sinnvoll, eine entsprechende Rechtschreibkorrektur einzusetzen. Die aktuellen Erfahrung meiner Frau beim Versuch, sich eine norwegische Rechtschreibhilfe unter MS Word 2003 (Windows) und unter Openoffice (Windows und Linux) verfügbar zu machen, gaben Anlass für den nachfolgenden Beitrag.

Die Erfahrung mit dem MS Produkt war folgende:

Es war ein Dokument eines Kunden zu bearbeiten, das mit Word 2003 verfasst worden war und etliche komplexe Tabellen enthielt. Nun wollten wir zusätzlich zur deutschen und englichen Rechtschreibung in aller Naivität norwegische Wörterbücher aktivieren. Fehlanzeige: Für das dt. Office 2003 muss man da (nach Internet-Recherchen) wohl ein Zusatzprodukt (“Proof-Tools”) käuflich erwerben. Das fanden wir ziemlich unerträglich – nach dem Kauf einer teueren Office-Lizenz nachträglich Geschäft durch Erweiterungen für zusätzliche Sprachen zu generieren, halten wir gerade im Zeitalter der sogenannten Globalisierung für wenig einsichtig und eher diskriminierend. Für meine Frau war dies dann wirklich eine weitere Motivation, sich von den Microsoft-Produkten systematisch zu entfernen. Sie fand sich als Norwegerin mit deutscher Office-Version zu Recht benachteiligt.

Also das Experiment: Öffnen des mit Word 2003 verfassten Dokumentes in Openoffice 2.4.1 unter Windows und Linux – sah gut aus ! Nach dem testweisen Speichern unter einem anderen Namen im doc-Format und einem erneuten Öffenen mit Word 2003 war trotz der Tabellen kein Unterschied im Layout erkennbar.

Also weiter mit der Suche nach der norwegischen Rechtschreibung für Openoffice. Erwartungsgemäß gab es keine Option für eine der offiziellen norwegischen Sprachen unter dem Openoffice Menüpunkt “Extras->Optionen->Spracheinstellungen”. Die benötigten Wörterbücher waren weder unter Windows noch unter Linux installiert. Also: Nachforschen im Internet auf der Extensions-Seite für Openoffice – Fehlanzeige. Eine Suche mit “Openoffice norwegian dictionary” führte dann jedoch zum Openoffice Wiki “http://wiki.services.openoffice.org/wiki/Dictionaries”.

Installation und Benutzung unter der Windows Version
Im Wiki gab es denn auch eine brauchbare Installationsanleitung für die aktuelle Windows Version von OpenOffice: Man benutze z.B. unter Openoffice Writer Menüpunkt “Datei->Assistenten->Weitere Wörterbücher installieren”. Dort findet man dann nach einigem Suchen auch eine deutsche Version für die Installation der Wörterbücher. Man kann dann dem Dialog folgen und sich die Wörterbücher direkt aus dem Internet herunterladen und installieren lassen. Danach ist nur ein kompletter Neustart von Openoffice inkl. des Schnellstarters erforderlich, und die norwegische Rechtschreibung steht einem dann zur Verfügung. Mein Frau konnte damit dann die erstellten Dateien inkl. norwegischer Rechtschreibprüfung verarbeiten. Der Kunde hat übrigens den Umweg über Openoffice nicht bemerkt. (Wir haben ihm das aber natürlich mitgeteilt).

Installation und Benutzung unter der Linux Version
Den oben für Windows genannten Menüpunkt für den Installationsassistenten gab es leider unter unserer Openoffice Installation unter Opensuse nicht. Die oben genannte Wiki-Seite erwähnt diesen Punkt leider überhaupt nicht. Die Seite ist insgesamt wenig hilfreich für Linuxer, wenn man nicht gerade Ubuntu verwendet.
Mehr Informationen liefern dagegen die Seiten

http://lingucomponent.openoffice.org/
http://lingucomponent.openoffice.org/auto_instal.html

Die letzte Seite verweist auch auf ein Auto-Installer-Tool, das man sich implementieren kann. Da es aber mit der anstehenden Openoffice Version 3 wieder Änderungen bei der Dictionary Installation geben wird, haben wir das Tool nicht getestet.

Wichtiger erschien uns Folgendes: Die aktuellen OO-Versionen binden über “hunspell” vorhandene “myspell” Dictionaries
ein. Das ist das übliche modulare Konzept für Linux-Applikationen.

Also: rpm-Sprachpakete für myspell suchen und installieren. (Unter Suse bieten Yast/Yum direkt eine sehr große Auswahl an). Interessant für Norwegisch sind die Pakete myspell-norsk-bokmaal-20060428-53.noarch.rpm und myspell-norsk-nynorsk-20060428-53.noarch.rpm. Nach einer Installation mit dem rpm-Paketmanager seiner Wahl und einem Neustart von Openoffice standen diese Wörterbücher dann auch direkt zur Verfügung.

Hinweise zum konkreten (ggf. abschnittsweisen) Einsatz
Grundeinstellungen der Sprache für das Dokument nimmt man über “Extras->Optionen->Spracheinstellungen” vor. Im Dokument selbst benutze man für Absätze oder markierte Abschnitte die Auswahlmöglichkeiten unter dem Menüpunkt “Extras->Sprache->…”, um die Sprachen für gewählte Textbereiche festzulegen. Danach verwendet man F7 oder einen Klick auf das entspr. Icon der Standard-Iconleiste oder den Menüpunkt “Extras->Rechtschreibung”, um die Rechtschreibhilfe zu aktivieren. Für die Aktivierung der Rechtschreibprüfung während der Texteingabe klickt man auf das entsprechende Icon oder legt die Grundeinstellung über “Extras->Optionen->Spracheinstellungen->Linguistik->Optionen” und die dortige entsprechende Checkbox fest. Den Menüpunkt “Automatisch Prüfen” kann man sich über “Extras->Anpassen” auch zum Hauptmenüpunktliste “Extras” dazufügen. Standardmäßig ist er dort nicht vorhanden.