Monthly Archives: August 2008

Debian – Leere resolv.conf nach Neustart

Posted on by

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

Posted on by

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.

Zur Höhe von Listen bei gefloatetem Inhalt

Posted on by

Wegen einer Nachfrage hier noch ein Kommentar zur Höhenberechnung von dynamisch (!) generierten Listen, in denen die Höhe der Listenelemente und ihrer Inhalte (also irgendwelcher Tags innerhalb der <li>-Tags) nicht vorab bekannt sind und variieren können. Dies betrifft indirekt auch den letzten Beitrag in dieser Blog-Kategorie zur Generierung dynamischer Listen aus Datenbank-Sätzen. Dort hatten wir beschrieben, wie man mit Listen und dem Floaten des Inhalts formatierten Output für Datenbank-Abfragen erzeugen kann.

Eine Kollegin hat nun auf Basis des Beitrags ausprobiert, eine solche Liste unbekannter Höhe zu erstellen, bei der innerhalb der <li> mehrere Elemente (u.a. <div>-Elemente) mit “float:left;” positioniert worden waren. Als sie sich Rahmen um die <li> und das <ul>-Tag zeichnen ließ, war sie sehr erschrocken darüber, dass im Firefox der Rahmen des <ul>-Elements auf einen Strich zusammengezogen erschien. Die Höhe des <ul>-Block-Elements erschien also völlig falsch berechnet.

Komischerweise war das Verhalten im MS IE 7 ganz anders: Hier erschien die Border des <ul>-Tags richtig gezeichnet – also die Höhe des <ul>-Elementes aus den Inhalten der <LI>-Tags richtig berechnet. Warum diese große Diskrepanz zwischen den Browsern? Hat Firefox hier eine Macke? Eine Analyse des Codes zeigt dann dagegen, dass sich der MS IE eigentlich falsch verhielt und Firefox im Wesentlichen richtig!

Ein kurzer Blick auf das <li>-Elemente und die zugehörigen CSS-Anweisungen zeigte (verkürzt) Folgendes:

<ul style="width:30.0em;………border: …… ">
    <li style="width:30.0em; clear:left; float:left; border: ….. ; line-height:1.8em; ….">
        <div style="float:left; ….&quot>graphisches Element</div>
        <div style="float:left; ….&quot><p>mehrzeiliger Text unbekannter Höhe</p></div>
    </li>
    <li style="width:30.0em; clear:left; float:left; border: ….. ; line-height:1.8em; ….">
    ……
    ……
</ul>

Die Listenzeilen wurden schön untereinander dargestellt; leider z.T. mit etwas falschen Abständen, sobald mehrzeilige Elemente auftauchten.

Der erste grundsätzliche Fehler liegt hier zunächst einmal in dem überflüssigen und falschen “float:left” für das <li>-Tag. Dass die Listenelemente überhaupt untereinander dargestellt werden, liegt hier nur an der Breitenbegrenzung des <ul>-Elementes!

Eine Elimination der “float”-Anweisung aus dem <li>-Tag ergab denn schon mal als ersten Fortschritt einen vertikal ausgedehnten Bereich für das <ul>-Element.

Leider hatte das <ul>-Element aber immer noch eine falsche Höhe und auch die Abstände zwischen den <li>-Elementen waren immer noch nicht gleichmäßig. Es hatte also den Anschein, dass die Höhe der <li>-Elemente und damit auch die resultierende Summe für das <ul>-Element nach wie vor falsch berechnet wurden – nämlich so, als ob nur die “line-height” relevant wäre.

Hier kommt nun der interessante Punkt:

Eine “float”-Anweisung hebt den gefloateten Bereich aus dem normalen Inhaltsverlauf (Kontext) des umgebenden Elementes heraus ! Man kann das näherungsweise mit dem Verhalten von absolut positionierten Elementen (z.B. DIVs) in ihrem Parent-Tag (z.B. einem mit “position:relative;” positionierten Container-DIV) vergleichen. Legt man für das umgebende Container DIV eine Höhe und Breite fest, so wird diese im Firefox exakt beachtet; die inneren DIVs ragen aber je nach Position und Größe völlig aus dem umgebenden Bereich heraus. Gleiches gilt für den Inhalt von <p>-Tags: Ist dieser zu groß
und ein Text-Umbruch nicht möglich, so ragt der Text im Firefox aus dem umgebenden Block-Element (DIV) heraus. Dies ist vollkommen CSS-konform. (Der alte MS IE 6 verhält sich hier bei P-Tags noch ganz anders – nämlich so, dass er das umgebende DIV-Tag mit dem<P>-Tag ausdehnt.)

Wo liegt also im obigen Beispiel der Fehler? Warum wird die Höhe der <li>-Elemente nicht richtig berechnet? Antwort: Weil die float-Anweisung nicht innerhalb des <li>-Tags wieder aufgehoben wird!

Das Hinzufügen eines Dummy-Elements zum “Clearen” der float-Anweisung innerhalb des <li>-Tags genügt hierfür! Im obigen Beispiel bringt ein zusätzliches <p style="clear:left; ….">-Tag im <li>-Element alles ins Lot:

<ul style="width:30.0em;………border: …… ">
    <li style="width:30.0em; border: ….. ; line-height:1.8em; ….">
        <div style="float:left; ….&quot>graphisches Element</div>
        <div style="float:left; ….&quot><p>mehrzeiliger Text unbekannter Höhe</p></div>
        <p style="clear:left; font-size:1px; line-height:1px; margin:0; "> </p>
    </li>
    ……
    ……
  </ul>

Natürlich wird dann auch die “clear”-Anweisung für das <li>-Element selbst überflüssig!

Merke also: Eine korrekte Höhenberechnungen von Elementen, die gefloateten Inhalt umschließen, setzt ein Aufheben der Float-Anweisung durch ein abschließendes (Dummy-) Element voraus.

Das gilt natürlich auch und vor allem für die im letzten Beitrag dieser Kategorie diskutierten dynamisch generierten Listen über PHP IT- oder ITX-Templates !