Integration von Hardware

Übersicht

Das Dilemma mit Linux und Hardware ist, dass kaum ein Hersteller sich bislang um die Entwicklung und Auslieferung von Treibern scherte. Ja schlimmer noch, man verwehrte vielfach den freiwilligen Entwicklern Einblick in die interne Struktur. Und ohne Kenntnis der Parameter, ist ein brauchbarer Treiber nur schwerlich zu programmieren...

Auf lange Sicht ist Besserung in Sicht, die wenigsten Hardware-Lieferanten verschließen vollends die Augen vor dem wachsenden Linuxmarkt. Viele unterstützen tatkräftig die Open Source Gemeinde; andere drehen noch die Däumchen. Aber: »Wer zu spät kommt, den bestraft das Leben!«. Gute Hardware, die sich zum Zusammenspiel mit Linux überreden lässt, gibt es unterdessen zur Genüge. Notfalls sollte man vor dem Kauf einmal im Internet nach dem Status des gepriesenen Stücks Ausschau halten.

Das Wort Treiber machte schon die Runde. Hierbei handelt es sich um Software, die die Ansteuerung einer Hardwarekomponente regelt. Um einen Treiber verwenden zu können, muss der Linuxkernel für diesen vorbereitet sein. Entweder ist der Treiber fester Bestandteil des Kernels oder er liegt als so genanntes Modul bereit, um im Falle seines Einsatzes dynamisch den Kernel erweitern zu können. Auch im Fall des Modules muss der Kernel die Voraussetzungen erfüllen, um mit diesem zu Rande zu kommen. Eventuell ist also ein neuer Kernel zu generieren. Den Umgang mit Modulen erläutert der gleichnamige Abschnitt.

CD-Laufwerk & Brenner

ATAPI-CDROM

Im offiziellen Sprachgebrauch des ANSI (American National Standards Institute) bezeichnet man IDE (Integrated Drive Electronics) als ATA (Advanced Technology Attachment). ATAPI (ATA Packet Interface) ist also nichts anderes als ein Protokoll, das zum Anschluss von Massenspeichergeräten an einen IDE-Bus dient.

ATAPI-CDROM-Laufwerke - und aktuelle Nicht-SCSI-Modelle sind fast immer solche - gliedern sich analog zu Festplatten im System ein. Nach dem Einbau eines solchen Laufwerks ist schon an den Ausgaben des BIOS ersichtlich, ob das Gerät ordnungsgemäß erkannt wurde. Merken müssen Sie sich nur, ob das Laufwerk am ersten oder zweiten IDE-Kontroller hängt und ob es dort als Master oder als Slave fungiert. Beide Informationen sollten im BIOS Ihres Rechners zu finden sein.

Nach dem Start von Linux sollten Sie im Verzeichnis /dev einen Link cdrom auf das entsprechende Device, an dem Ihr CDROM-Laufwerk hängt, anlegen. Es gibt einige Programme, die diesen Namen erwarten und außerdem merkt sich dieser leichter, als es der physische Devicename tut.

Falls das CDROM-Laufwerk nicht als Slave am 2.Controller (/dev/hdd) installiert ist, dann ersetzen Sie in obiger Kommandozeile /dev/hdd durch:

Vor dem Zugriff auf die Daten, muss eine CD noch gemountet werden. Anzumerken ist noch, dass im Kernel die Unterstützung für »IDE/ATAPI CDROM« und das Dateisystem ISO9660 aktiviert sein muss; dies sollte aber in allen Standardkerneln der Fall sein.

SCSI-CDROM-Laufwerke

SCSI (Small Computer Systems Interface) erhitzt die Gemüter so mancher Computer-Enthusiasten. Wer es hat, belächelt diejenigen, die »IDE-Kinderkram« einsetzen. Im Vergleich zu IDE-Realisierungen sind SCSI-Komponenten allerdings extrem teuer und die Zeiten, da ein SCSI-Gerät entscheidend flotter die Daten übertrug, gehören spätestens seit UltraDMA der Vergangenheit an.

SCSI kann dennoch durchaus nützlich sein. Nämlich dann, wenn CD-Brenner, CDROM und mindestens drei Festplatten ins System sollen. Mit IDE-Geräten ist dies nicht ohne Weiteres zu realisieren, da heutige Mainboards nur zwei Kontroller mit je zwei Anschlüssen mit sich bringen. Über spezielle Kernelparameter kann Linux allerdings bis zu vier Kontroller ansprechen, aber wer eine solche Konfiguration benötigt, sollte dann doch besser gleich zu SCSI greifen.

Um auf SCSI-CDROM-Laufwerke zuzugreifen, muss der Kernel ein paar mehr Fähigkeiten enthalten. Und diese sind selten in den Standardkerneln integriert. Modellieren Sie also einen Kernel mit SCSI-Support, der darüber hinaus den Treiber für Ihren SCSI-Adapter, für die SCSI-CDROM-Unterstützung und das ISO9660-Dateisystem umfasst.

Wenn Sie nur ein SCSI-CDROM in Ihrem System installiert haben, erreichen Sie dieses über das Device /dev/scd0. Bei mehreren hängt die Namensvergabe zunächst vom SCSI-Bus ab, an dem das Laufwerk hängt. Jenes am ersten Bus reiht sich vor einem CDROM-LW am zweiten Bus ein usw. Sind mehrere Laufwerke an einem einzigen Bus angeschlossen, so entscheidet die SCSI-ID (am Gerät einstellbar), welches Laufwerk unter /dev/sdc0, welches unter /dev/scd1 usw. angesprochen wird. Sie sollten zur Vereinfachung wiederum einen Link unter dem Namen /dev/cdrom auf das Device des ersten CDROMs legen.

Weitere Laufwerkstypen

So genannte propriätere Laufwerke, wie sie vor einigen Jahren gern im Paket mit Soundkarten vertrieben wurden, findet man im Handel zum Glück nicht mehr. Dennoch sind derartige Exoten in dem einen oder anderen - zumeist betagteren - Rechner noch installiert. Jetzt muss man nicht gleich resigniert zum Schraubendreher greifen, denn die Chancen stehen günstig, dass ein solches Laufwerk wohlwollend von Linux behandelt wird.

In fast allen Fällen ist jedoch ein neuer Kernel - oder zumindest ein entsprechendes Modul - von Nöten. Weil es sich wirklich um seltene Hardwarekomponenten handelt, fehlt die Unterstützung solcher Laufwerke quasi in jedem Standardkernel. Basteln Sie sich in dem Fall einen neuen Kernel zusammen und wählen Sie die Option, die Ihrem Laufwerktyp am ehesten entspricht. Das Device, hinter dem sich später Ihr Laufwerk versteckt, trägt meist einen Namen, der in abkürzender Manier auf den Hersteller hinweist (/dev/aztcd (Aztek), /dev/sbpcd (Creative Labs, Soundblaster), /dev/mcd (Mitsumi), /dev/sonycd (Sony)...).

Nicht nur CDROM-Laufwerke werden häufig auch über die parallele Schnittstelle betrieben. Auch in dieser Situation wird es ohne einen neukompilierten Kernel nicht gehen. Dieser sollte den Treiber für Parallelport-IDE-Geräte als Modul ("paride") enthalten. Die Devicenamen sind /dev/pcd0, /dev/pcd1,...

Allgemeines zu CD-Brennern

Abgesehen von der Fähigkeit zum Brennen von CDs unterscheiden sich solche Geräte nicht von herkömmlichen Nur-Lese-Laufwerken. Nach einer Installation gemäß dem Vorgehen von CDROM-Laufwerken sollte das Lesen vom Laufwerk bereits funktionieren.

Um das Schreiben des Images vor dem eigentlichen Brennvorgang zu simulieren, ist es günstig, den Treiber für das Loopback-Device in den Kernel zu integrieren (wahlweise als Modul).

An dieser Stelle sollen nur die Programme genannt werden, die zum Brennen und für vorbereitende Maßnahmen verwendet werden können.

Um eine Daten-CD zu brennen, muss ein entsprechendes CD-Image erzeugt werden. Hierzu dient das Programm mkisofs. Eine Alternative ist mkhybrid. Die Tracks einer AudioCD vermögen die Programme cdparanoia oder cdda2wav auszulesen. Während die gelesenen Daten des ersteren Tools unverändert auf eine CD gebrannt werden können, muss das Ausgabeformat von cdda2wav zunächst gewandelt werden. Ein Programm, das verschiedene Audioformate in die richtige Form bringt, ist sox. Formate von VideoCDs vermag das Werkzeug mkvcdfs zu erzeugen.

Den eigentlichen Brennvorgang können Sie mit einem der Programme cdrecord oder cdrdao vornehmen.

Grafische Verpackungen für mkisofs und cdrecord bieten u.a xcdroast (X), krabber, keasycd (KDE) und gcombust (Gnome).

SCSI-CD-Brenner

Gehen Sie zur Installation analog vor, wie bei einem SCSI-CDROM-Laufwerk. Lässt sich das Gerät nachfolgend wie ein gewöhnliches CDROM-LW ansprechen, sind bereits alle Vorarbeiten geleistet.

IDE-CD-Brenner

Alle weiter oben genannten Brennprogramme setzen einen SCSI-CD-Brenner voraus. Leider hat sich noch kein Entwickler die Bürde auferlegt, die Linuxgemeinde mit Treibern für IDE-Brenner zu beglücken. Vielleicht auch deshalb, weil ein solcher Treiber niemals wirklich notwendig wurde, um auch mit einem IDE-Gerät die CD zu toasten. Denn schon seit geraumer Zeit gehört eine SCSI-Emulation zum Funktionsumfang des Kernels (ab dem Kernel 2.6 gehört ein ATAPI-CDROM-Brenner-Treiber direkt zum Kernel).

Also macht sich (in den meisten Fällen) wieder einmal eine Kernelübersetzung notwendig. Achten Sie auf die Aktivierung folgender Punkte (wenn nicht anders angegeben, kann eine Option als Modul realisiert werden):

Abbildung 1: Kerneleinstellungen: SCSI-Emulation für IDE-Brenner

Abbildung 2: Kerneleinstellungen: SCSI-Optionen für IDE-Brenner

In einem IDE-System müssen die Treiber für IDE fest in den Kernel eingebunden werden. Das würde nun dazu führen, dass beim Booten der CD-Brenner schon als IDE-Gerät initialisiert werden würde, noch bevor die SCSI-Emulation überhaupt zum Zuge kommt. Um dies zu verhindern, ist zum Zeitpunkt des Bootens dem Kernel dies mitzuteilen. Automatisieren lässt sich dies durch einen entsprechenden Eintrag in die Datei des Bootmanagers (im Beispiel handelt es sich um den Lilo):

Genau jene Geräte, die nicht vom IDE-Treiber angesprochen werden sollen, müssen durch einen append-Eintrag »<Gerät>=ide-scsi« gekennzeichnet werden. Im Beispiel handelt es sich um beide Geräte am 2. IDE-Kontroller; ein CD-ROM und ein Brenner. Ein CDROM-Laufwerk ist nicht zwingend erforderlich, da ein Brenner ebenso die Daten auslesen, das Images zunächst auf die Platte schreiben und anschließend auf den Rohling brennen kann. Für ein direktes Kopieren muss das CDROM-Laufwerk ebenso als SCSI-Gerät vorhanden sein!

Je nach Kernelkonfiguration müssen Sie nun die Module laden:

cdrom muss vor sr_mod geladen werden; die restliche Reihenfolge ist unerheblich.

Der ganze Ladevorgang reduziert sich auf einen Aufruf von modprobe ide-scsi, falls die Datei /etc/modules.conf um folgende Einträge ergänzt wird:

Falls der anschließende Aufruf von »modprobe« erfolgreich verlief, sollten CD-Brenner und - falls vorhanden - das CDROM-Laufwerk im Prozessdateisystem auftauchen:

Integrieren Sie den modprobe-Aufruf in eines der System-Startskripte, so sollte beim folgenden Booten des Rechners eine Meldung in der Art von »hdd: ... enabling SCSI emulation« erscheinen. Zudem sollten »scsi0 : SCSI host adapter emulation for IDE ATAPI devices« und eine den konkreten Brenner beschreibende Zeile zu sehen sein.

Drucker

Selten offenbart Linux seine Abstammung von Unix so deutlich wie in der Handhabung von Druckern. Unix, das man mit gutem Gewissen Analogien zu Netzwerkbetriebssystemen bescheinigen kann, ist von Haus aus darauf getrimmt, Ressourcen im Netzwerk zu teilen. So arbeitet das Drucksystem, das in portierter Form auch auf Linux heimisch wurde, transparent im Netzwerk. Das Problem des Einrichtens eines Druckers reduziert sich auf die lokale Anbindung am Rechner, der Schritt zum Netzwerkdrucker ist trivial.

Reduziert suggeriert Einfachheit, doch mit der einen Ausnahme von Postscript-Druckern (Postscript ist eine von Adobe eingeführte Seitenbeschreibungssprache) ist die Konfiguration alles andere als ein Kinderspiel. Doch Entwarnung! Fast jede Distribution beinhaltet Administrationshilfen, die das Typenrad gängiger Druckermodelle mit geringem Aufwand in Schwung versetzen.

Nach wie vor verwaltet per Voreinstellung in nahezu allen Distributionen der Line Printer Daemon (Lpd) die Druckaufträge im System. Dessen Entstehung datiert allerdings schon um einige Jahrzehnte zurück. Anno dazumal waren Typenraddrucker das Nonplusultra, später wurden für die gehobenen Ansprüche die Postscript-Drucker verfügbar. Kein Wunder also, dass der Lpd von Haus aus nur mit diesen gut zu Rande kommt.

Der Line Printer Daemon ist nur eines der so genannten Spooling-Systeme, die unterdessen für Linux verfügbar sind. »Spooling« deshalb, weil die Druckaufträge nicht direkt von einer Anwendung zum Drucker gelangen, sondern in einer Druckerwarteschlange zwischengespeichert werden. Für jeden Drucker im System - dabei spielt es keine Rolle, ob dieser am lokalen Rechner oder irgendwo im Netzwerk angeschlossen ist - existiert mindestens eine Warteschlange. Üblich sind sogar mehrere Warteschlangen für jeden lokalen Drucker, da häufig ein bestimmter Filter einer Warteschlange zugeordnet wird. Aufgabe eines solchen »Eingabefilters« ist die Aufbereitung der zu druckenden Daten in ein für den Drucker verständliches Format. Derartige Filter existieren zuhauf, der bekannteste und verbreiteste dürfte »Apsfilter« (wird nicht bei CUPS verwendet) sein, der Dateitypen automatisch erkennt und seinerseits einen konkreten Filter aufruft. Für die Wandlung des Postscript-Formats, was die meisten Anwendungen, die das Drucken vorsehen, erzeugen, ist »Ghostscript« der relevante Filter. Er soll uns noch beschäftigen.

Als Alternative zum Line Printer Daemon kam in einer neu gefassten Implementierung später der LPRpn hinzu (LPRng wird hier nicht betrachtet werden), der ähnliche Eigenschaften wie der Lpd aufweist, allerdings auch die meisten seiner Schwächen. Ein gänzlich anderes Drucksystem ist PDQ (Print, don't queue), das ohne ein Spooling System auskommt. Auch dieser Variante werden wir nicht weiter folgen. Neben dem Lpd richten wir unser Augenmerk auf CUPS (Common Unix Printer System), das 1999 unter die GPL gestellt wurde und damit eine umfassende Alternative zum LPD darstellt. Vermutlich wird CUPS den Lpd eines Tages komplett verdrängen.

Der Druckeranschluss

Bevor Sie hier weiter lesen, sollten Sie im Handbuch Ihres Druckers nachsehen, ob es sich um einen so genannten GDI-Drucker handelt. In diesem Fall werden Sie mit den üblichen Methoden keine Druckergebnisse erzielen können. Wir gehen auf diese Modelle auch nicht weiter ein.

Die wohl meisten Drucker heutiger Bauart werden entweder an einer parallelen Schnittstelle des Rechners angeschlossen oder an einem USB-Port. Seltener findet man noch Modelle, die an der seriellen Schnittstelle betrieben werden.

Je nach verwendetem Druckertyp muss der Kernel die entsprechenden Treiber parat halten. Parallele und serielle Schnittstellen sind in den meisten Konfigurationen frei geschaltet, sodass eine Kernel-Neuübersetzung höchstens zur Anbindung von USB-Druckern in Frage kommt. Letzteres Vorgehen ist im Abschnitt zu USB-Unterstützung beschrieben.

Ist der entsprechende Treiber erst einmal geladen, kann ein erster Test nicht schaden. Ein rudimentäres Verfahren ist das direkte Senden eines Textes an die Schnittstelle:

Im Beispiel sollte ein Drucker an der ersten parallelen Schnittstelle loslegen. Es muss allerdings nicht zwingend einen Fehler bedeuten, wenn der Drucker sich nicht rührt. Denn einige Modelle sind nicht in der Lage, einfachen ASCII-Text aufs Papier zu bringen. In der nachfolgenden Abhandlung zu Ghostscript erfahren Sie, wie Sie Druckausgaben für derartige Drucker generieren können.

Fehlersuche

Angenommen es handelt sich um eine Fehlkonfiguration. Dann geht es an die Fehlersuche. Erster Anlaufpunkt sind die Meldungen des Bootvorgangs, die Sie mit dem Kommando dmesg nochmals auf den Bildschirm bannen. Von Interesse sind Zeilen, die einen Hinweis auf die parallele Schnittstelle geben (für serielle Drucker gelten natürlich die seriellen Schnittstellen; für USB-Drucker sind die jeweiligen Module interessant):

Die wichtigste Information enthält die mit lp beginnende Zeile. Im Beispiel ist »lp0« auf »parport0« gebunden. »parport0« selbst verwendet als IO-Adresse 0x378 und ist auf Polling eingestellt. Polling bedeutet, dass die Schnittstelle regelmäßig vom Kernel getestet wird, ob neue Daten anliegen. Ein solches Verfahren ist natürlich weniger effizient als die Steuerung via Interrupts. Falls die Schnittstelle Interrupts unterstützt, sollte sie darauf umgestellt werden:

Der eingestellte Interrupt muss mit den Einstellungen im BIOS übereinstimmen! Um zurück zum Polling-Verfahren zu wechseln, schreiben Sie »none« in obige Datei.

/proc/parport existiert bei Ihnen nicht? Dann verwenden Sie eventuell noch einen alten Kernel, der die Verwendung einer parallelen Schnittstelle durch mehrere Geräte noch nicht unterstützt. In den Bootmeldungen hätte dann etwa folgende Zeile gestanden:

Den Interruptbetrieb für eine solche Schnittstelle aktivieren Sie mit tunelp:

Wieder ist wichtig, dass Sie keinen von den BIOS-Einstellungen abweichenden Interrupt einschalten. Zum Deaktivieren verwenden Sie als Interruptnummer die »0«.

Falls aber in den Bootmeldungen keinerlei Hinweise auf die parallelen Schnittstellen auftauchen, so wurde entweder das entsprechende Treibermodul noch nicht geladen oder im Kernel fehlt die Unterstützung. In letzteren Fall müssen Sie einen neuen Kernel übersetzen. Die für die parallele Schnittstelle notwendigen Optionen (günstig als Modul) nennen sich:

• Parallel port support
• PC-style Hardware
• Parallel printer support
• PLIP (parallel support) nicht oder höchstens als Modul!

Und wenn Sie schon beim Kernelbau sind, so sollten Sie die Aktivierung von TCP/IP nicht vergessen, da der Lpd diese benötigt.

Bevor Sie sich an den Kernel wagen, sollten Sie prüfen, ob nicht vielleicht die Module bereits vorhanden sind. Wenn ja, dann liegen sie im Verzeichnis /lib/modules/Kernelversion/misc/ und heißen:

Bei einem älteren Kernel existiert einzig »lp.o«. Bei korrekter Beschreibung in der Datei module.conf genügt ein Aufruf von:

In der Ausgabe von lsmod sollten alle 4 oben genannten Module erscheinen. Klappt es nicht, können die Module auch von Hand geladen werden, wobei die Reihenfolge wichtig ist:

Führen obige Versuche nicht zum Erfolg, so können Sie die Treiber mit konkreten Vorgaben für Interrupt und IO-Adresse laden (weiter gehende Informationen enthält der Abschnitt Kernel-Module). Und bevor Sie verzweifeln... - prüfen Sie das Kabel (nicht jedes ist geeignet!) und die Verbindungen.

Das Sprachentalent Ghostscript

Ghostscript kommt immer dann ins Spiel, wenn es gilt, Postscript-Dokumente auf nicht Postscript-fähigen Druckern auszudrucken. Praktisch gibt es kaum eine verbreitete Anwendung, die nicht ihre Druckausgaben im Format Postscript erzeugt.

Die Parameter von Ghostscript sind verwirrend vielgestaltig und sollen uns hier nur insofern interessieren, wie sie zum Verständnis der Arbeitsweise des Filterprogramms erforderlich sind. Zum letzten Feinschliff kommen Sie ohnehin nicht umhin, die ausführliche Dokumentation bez. des für Ihren Drucker zuständigen Ghostscript-Treibers zu wälzen (aktuelle Distributionen bringen zum Glück brauchbare Voreinstellungen mit, sodass Sie vermutlich nicht mit Ghostscript direkt in Berührung kommen).

Der direkte Umgang mit Ghostscript ist zumindest bei der Fehlersuche während der Druckerinstallation nützlich. Generieren Sie hiermit das für einen konkreten Drucker bestimmte Ausgabeformat und senden die so aufbereiteten Daten zur Druckerschnittstelle, so können Sie zumindest den Drucker als Fehlerquelle ausschließen, wenn ein Ausdruck nicht gelingt (es sei denn, der Drucker ist defekt). Auch die Korrektur von Papierformaten, Ausrichtung, Auflösung usw. ist schnell mit Ghostscript getestet.

Gs interaktiv

Das zuständige Programm gs kann sowohl interaktiv verwendet als auch über die Kommandozeile gesteuert werden:

Wird gs ohne Angabe des Ausgabegerätes aufgerufen, verwendet das Programm das Standard-Ausgabegerät. Dabei handelt es sich um das erste Device der Liste, die der Aufruf von gs -h hervorbringt (im Beispiel ein X-Fenster; zur Konsolenausgabe muss ein entsprechender Ghostscript mit SVGA-Unterstützung installiert werden).

gs interpretiert der Reihe nach die per Kommandozeile übergebenen Postscript- oder PDF-Dateien und erzeugt die Ausgabe des eingestellten Devices. Wurde keine Datei angegeben oder wurden alle Dateien bearbeitet, geht gs in den interaktiven Modus über. In obigem Anwendungsbeispiel wird das manuelle Laden einer Datei und das abschließende Beenden des Interpreters vollzogen. Das Ausgabefenster zeigt Abbildung 3.

Abbildung 3: Ausgabefenster des Programms »gs«

Auswahl des Treibers

Um gs zu veranlassen, das für Ihren Drucker verständliche Ausgabeformat zu erzeugen, müssen sie den gewünschten Treiber angeben. Schnellste Möglichkeit geht über die Kommandozeilenoption »-sDEVICE=Devicename«.

Und welcher Devicename? Die möglichen Namen, es wurde bereits erwähnt, erhalten Sie durch Aufruf von »gs -h«. In etlichen Fällen deuten die Kürzel den unterstützten Drucker an, aber eben nicht immer. Suchen Sie in den Dateien Ihrer Ghostscript-Installation nach »Devices.htm« (manchmal auch »Devices.txt«) bzw. »catalog.devices«, die ausführlichere Listen der durch einen Treiber unterstützten Drucker enthalten. Oft können Sie für einunddenselben Drucker aus mehreren Treibern wählen. Hier sind Versuche angesagt, welcher Treiber die besten Resultate erzeugt.

Um bspw. die obige Datei »tiger.ps« für einen Epson-Drucker aufzubereiten, ist folgende Kommandozeile aufzurufen:

»-c quit« am Ende bewirkt, dass gs sich sofort beendet, nachdem die erfolgte Bearbeitung mit [Enter] bestätigt wurde. Die Ausgabe hat gs in eine temporäre Datei im Verzeichnis /tmp geschrieben. Natürlich ist das nicht das von uns erwünschte Verhalten. Deshalb sollte die Ausgabe per Option »-sOutputFile=Datei« umgeleitet werden. Um auch die Statusmeldung von gs zu unterdrücken, nutzen wir die Option »-q«. Das Warten auf Bestätigung der Auftragsabarbeitung verhindert »-dNOPAUSE«. Somit lautet die komplette Zeile zum Erzeugen wie folgt:

Zum Test sollten Sie als Root die Datei nun an die Schnittstelle des Druckers senden (das Beispiel geht wiederum von einem Drucker an der ersten parallelen Schnittstelle aus):

Drucken mit dem Lpd

Abbildung 4: Arbeitsweise des Lpd

Der Line Printer Daemon wird i.d.R. während des Bootvorgangs gestartet. Seine Aufgabe ist die Verwaltung der Druckaufträge. Einmalig während des Starts bezieht der Lpd seine Konfigurationsdaten aus der Datei /etc/printcap. Diese Datei enthält die Beschreibungen sämtlicher Druckerwarteschlagen. Initial durchsucht der Daemon alle Spoolverzeichnisse, ob diese unbearbeitete Druckaufträge enthalten. Wird ein Auftrag entdeckt, erzeugt der Lpd einen Kindprozess, übergibt diesem diesen Auftrag und begibt sich in den Wartezustand, um erneute Aufträge entgegen nehmen zu können. Der neue Lpd-Prozess bereitet die zu druckende Datei geeignet auf - wie, das steht ebenso in den Definitionen von /etc/printcap - und sendet die Datei zum Drucker. Nach Auftragserledigung beendet sich der Kindprozess von selbst. In Abbildung 4 ist das Verfahren stark vereinfacht skizziert.

Der Druckerdaemon selbst gönnt den Spoolverzeichnissen nach getaner Initialisierung aus eigenem Antrieb heraus keinen Blick mehr. Er überwacht (falls konfiguriert) den TCP-Port 512 auf neue Aufträge aus dem Netzwerk bzw. den Socket /dev/printer auf Benachrichtung über lokale Auftragseingänge.

Das Erzeugen von Druckaufträgen geschieht mit dem Kommando lpr. Selbst hinter den Druckknöpfen in den grafischen Anwendungen verbirgt sich nichts anderes als ein Aufruf von lpr mit geeigneten Parametern. Lpr schaut nun selbst in der Datei /etc/printcap nach, ob der entweder auf der Kommandozeile angegebe oder der voreingestellte Drucker ($PRINTER) existiert und ermittelt aus dem zugeordneten Eintrag das richtige Spoolverzeichnis. Lpr kopiert (oder verlinkt [Option -s]) die zu druckende Datei zusammen mit einer Statusdatei in das Spoolverzeichnis. Die Statusdatei enthält u.a. die UID, GID des den Auftrag initiierenden Benutzers sowie ggf. Drucksteueroptionen, die per Kommandozeilenoptionen angegeben wurden. Nach den Vorarbeiten informiert Lpr den Daemon über den Socket /dev/printer, dass Arbeit auf ihn wartet.

Die Kommandos lpr (Drucken), lprm (Druckauftrag löschen), lpq (Druckerwarteschlange anzeigen) und lpc (Druckersteuerung) sind im Abschnitt Nutzerkommandos, Dateien und Verzeichnisse beschrieben.

Die Datei »/etc/printcap«

Die Datei »/etc/printcap« ist das Herz der Lpd-Konfiguration. Jede Zeile, die nicht mit dem Kommantarzeichen # beginnt, beschreibt einen Drucker im System. Der erste Eintrag einer Zeile muss mindestens einen Namen für den definierten Drucker enthalten, die weiteren Parameter lassen sich, jeweils in Doppelpunkte eingeschlossen, in beliebiger Reihenfolge anordnen. Um zu lange Zeilen zu vermeiden, können diese durch einen abschließenden Backslash \ umgebrochen werden:

Zuweisungen von Zeichenketten an Variablen werden mittels des Gleichheitszeichens vorgenommen (bspw: lp=/dev/lp1). Für nummerische Werte hingegen dient # als Zuweisungsoperator (bspw: mx#0).

Bevor wir konkrete Beispieleinträge diskutieren, fasst folgende Tabelle alle gebräuchlichen Parameter zusammen (insbesondere verzichten wir auf die Erläuterung etlicher Parameter zur Konfiguration einer seriellen Schnittstelle). Ein dem Namen folgendes »=« steht für einen Zeichenkettenparameter; ein »#« kennzeichnet einen nummerischen Parameter. Ein Parameter ohne Wert steht für sich allein:

In der Manual Page zu printcap sind weitere Parameter beschrieben, die als Filter für bestimmte Dateitypen dienen. Sie sollen uns nicht interessieren.

Nachfolgend sollen kurze Beispiele die Syntax der printcap-Einträge erläutern. Den Anfang macht eine einfache Konfiguration für einen lokalen Drucker. Dass dieser als Standarddrucker dient, zeigt der Name »lp«, unter dem der Drucker u.a. im System bekannt ist (»lp« sollte genau einmal in der printcap als Druckername auftauchen!). Die optionalen weiteren Namen »brother«, »postscript« sind typische Aliasse, die zumeist auf die Fähigkeiten oder das konkrete Modell hinweisen. Alle Druckernamen werden durch ein | voneinander getrennt angegeben und jeder Druckername darf nur einmal in der printcap-Datei vergeben werden. Einer der Druckernamen muss mit dem Namen des Spoolverzeichnisses übereinstimmen.

Der lokale Drucker im Beispiel ist an der ersten parallelen Schnittstelle angeschlossen, sein Spoolverzeichnis ist /var/spool/lp/brother, worin ebenso die Protokoll- (lf=) und Abrechnungsdaten (af=) gespeichert werden. Zu druckende Daten werden durch ein Skript »/var/spool/lp/brother/mein_filter« aufbereitet.

Der nächste Eintrag beschreibt einen Netzwerkdrucker. Am entfernten Rechner wird der Standarddrucker (lp) angesprochen. Lokal wird nur die Protokollierung und Abrechnung vorgenommen; auf eine lokale Aufbereitung der Daten durch einen Eingabefilter wird verzichtet. Das ist Sache des entfernten Drucksystems.

Der Eintrag des letzten hier diskutierten Beispiels stammt aus einem typischen Setup mit »apsfilter«, dem am häufigsten eingesetzen Eingangsfilter für Lpd-basierte Druckdienste unter Linux. Bis auf die Namensgebung besteht kein Unterschied zum zuvor beschriebenen lokalen Drucker. Dass die Namensgebung einen tieferen Sinn unterliegt, erfahren Sie im anschließenden Abschnitt zu »apsfilter«.

Apsfilter - Beispiel eines Eingabefilters

Apsfilter ist der bekannteste Vertreter der so genannten »magischen Filter«. Ein solcher Filter versucht das Format der Eingabedateien anhand typischer Muster zu erkennen und präpariert die Ausgabe gemäß seiner Erkenntnisse.

So manche Distribution nimmt Ihnen das Einrichten des Drucksystems - und damit der benötigten Filter - ab; wir betrachten hier dennoch das manuelle Vorgehen zur Konfiguration des Apsfilters (die in den Abbildungen gezeigte SuSE-Version unterscheidet sich nur unwesentlich vom Original).

Abbildung 5: Hauptmenü des Apsfilter-Setups

Im Paket finden Sie eine Datei SETUP (je nach Installationsverzeichnis in /var/lib/apsfilter oder /usr/lib/apsfilter). Dieses Dialog basierte Programm ist letztlich ein komfortables Frontend zum Einrichten der printcap-Datei.

Wenn Sie SETUP als Root starten, gelangen Sie nach einem Begrüßungsbildschirm in das in Abbildung 5 gezeigte Hauptmenü:

Beginnen Sie nun mit dem Erzeugen der notwendigen printcap-Einträge, indem Sie über den Menüeintrag »ENtrY« und darin »DEVICE« anspringen. Je nach Druckertyp und Schnittstelle markieren Sie das entsprechende Gerät (»PARALLEL« bzw. »SERIAL«). Mit »PREFILTER« können Sie den erzeugten printcap-Eintrag als Vorverarbeitungsstufe einsetzen, anschließend wird das Ergebnis zur weiteren Bearbeitung/Ausdruck an die hier eingetragene Warteschlange weiter gereicht. »REMOTE« dient zum Einrichten eines Netzwerkdruckers.

Abbildung 6: Einrichten eines neuen Druckers

Nach Device-Auswahl öffnet sich die in Abbildung 6 gezeigte Maske. Der nächste Schritt wird die Festlegung des zu verwendenden (Ghostscript-)Druckertreibers betreffen. Unter »PRINTER« finden Sie hierzu eine Liste von Druckertypen. Postscript- und HP-Deskjet-Drucker sind extra aufgeführt, die meisten anderen Drucker finden Sie unter »OTHER«. Informationen zu den Druckertreibern erhalten Sie unter dem gleichnamigen Menüeintrag »INFORMATION« (siehe auch Anmerkungen zu Ghostscript weiter oben im Abschnitt); die eigentliche Auswahl geschieht in »COMMIT«, worauf Sie zur Angabe der Auflösung (in dpi) aufgefordert werden.

Die Angabe eines Treibernames unter »FREEDEF« ist erforderlich, wenn der Treiber aus einer neueren Ghostscript-Version stammt und der Name apsfilter noch nicht bekannt ist (apsfilter liegt i.d.R. die zurzeit der Kompilierung aktuellste Ghostscript-Version zu Grunde).

Des Weiteren müssen Sie die Papierdimension (PAPER) angeben und kennzeichen, ob der Drucker farbig anzusteuern ist (COLOR).

Weitere Menüpunkte müssen i.d.R. nicht bearbeitet werden, mit »ADD« sind die aktuellen Einstellen noch zu bestätigen. Es erscheint eine Ausgabe der erzeugten Warteschlangen analog zur Abbildung 7.

Abbildung 7: Liste der Druckerwarteschlangen

Anhand der Benennung der von apsfilter erzeugten Druckerwarteschlangen erkennt der Filter später die zu vollziehenden Schritte zur Aufbereitung eines Druckauftrags. Sowohl Informationen zum Treiber (»ljet4«, vergleiche Abbildung 7), zum Papierformat (»a4«), zur »Art« der Druckdaten (»ascii« - Daten werden als reiner Text interpretiert; »auto« - apsfilter versucht die Art der Daten zu erkennen; »raw« - Daten liegen in einem für den Drucker verständlichen Format vor) sind im Namen kodiert. Ggf. steuern weitere Daten wie Farbansteuerung (im Beispiel »mono«) und Auflösung (»600«) die Filterung.

Mit den bisherigen Schritten sollte ein Probeausdruck zumindest ein einigermaßen brauchbares Ergebnis zu Papier bringen. Die Feinabstimmungen der Arbeit des Ghostscript-Treibers erfolgen global in der Datei /etc/apsfilterc bzw. treiberspezifisch in /etc/apsfilterrc.Treibername. Definitionen aus der treiberspezifischen Konfigurationsdatei überschreiben die zuvor geltenden globalen Einstellungen, sodass Eingriffe nur in dieser Datei erfolgen sollten.

Genau hier deligieren manche Distributionen die Konfiguration an weitere Dateien, sodass obige Aussagen nur den originalen apsfilter betreffen. Ohne weiter ins Detail zu gehen, sollten Sie bei der Optimierung der Druckausgabe zunächst wie unter Das Sprachentalent Ghostscript beschrieben mit den Ghostscript-Parametern experimentieren. Erhalten Sie eine brauchbare Einstellung, so setzen Sie die verwendeten Parameter in die Variable(n) »GS_FEATURES« aus /etc/apsfilterrc.Treibername ein. apsfilter sollte Ghostscript dann stets mit diesen Argumenten aufrufen.

Ein eigener Filter

Anhand eines einfachen Filtes sollen abschließend die notwendigen Schritte zur Erzeugung eines eigenen printcap-Eintrags vollzogen werden. Unser Filter soll nichts weiter tun, als Postscript-Dateien mittels psnup für den zweiseitigen Druck vorzubereiten und die weitere Aufbereitung Ghostscript zu überlassen.

Im ersten Schritt erzeugen wir den Eintrag, wobei als Druckname »ps2side« dient. Beachten Sie, dass genau dieser Name als Name des Spoolverzeichnisses erneut erscheint!

Des Weiteren sind die Verzeichnisse und die Protokolldatei zu erzeugen. Vergessen Sie nicht, den Lpd zum Eigentümer zu ernennen!

Im zu schreibenden Skript verzichten wir der Einfachheit halber auf einen Test des Dateityps. Über eine Pipe senden wir die Daten zunächst durch psnup und anschließend in Ghostscript. Wenn Sie im Manual zu gs nachschlagen, werden Sie auch die Erklärung finden, was »-sOutputFile=-« zu bedeuten hat. Das Minus steht hier für die Standardausgabe als Ziel der aufbereiteten Daten. Und woher bezieht gs seine Eingabe? Von der Standardeingabe (die mit der Pipe verbunden ist), benannt durch das Minus am Zeilenende.

Nun sind nur noch Eigentümer und Rechte des Filterskripts zu setzen und der Lpd neu zu starten:

Eventuell liegt bei Ihrer Distribution das Startskript des Lpd an anderer Stelle oder existiert nicht? Dann sollten Sie den Daemon per Hand neu starten (killall lpd; lpd). Ein nachfolgender Test wird hoffentlich die Tigergrafik in halber Größe zu Papier bringen:

Erfolgte kein Ausdruck, so forschen Sie in den Dateien /var/log/messages und /var/spool/lpd/ps2side/log nach den Ursachen.

Das Beispiel eines eigenen Filters wurde bewusst einfach gehalten. Im Prinzip arbeiten alle Filterskripte - auch apsfilter - nach diesem Schema, die magischen Vertreter testen nur zu Beginn des Skripts die ankommenden Daten und beschreiten im weiteren Verlauf abhängig vom erkannten Typ alternative Schritte.

Drucken mit CUPS

Der von Berkeley stammende Lpd ist nur eine von vielen Drucklösungen in Unix-Systemen. Gewiss erlangte er nicht zuletzt durch Linux eine gewisse Bedeutung, dennoch existier(t)en neben ihm weitere abgeleitete Realisierungen (bspw. LprNG) als auch gänzlich anders geartete Drucksysteme (System V). Womit diese Systeme allesamt perfekt zurande kommen, sind textbasierte oder Postscriptdrucker. Was sie gar nicht oder nur über Umwege untrestützen, sind all die anderen Drucker, die vor allem bei Privatanwender die Druckaufgaben übernehmen. Für Druckerhersteller war der Unixmarkt zunächst kaum interessant, war die Treiberentwicklung ob der zahlreichen Systeme doch unverhältnismäßig aufwändig und der erreichte Markt recht klein. Erst Linux schickte sich an, ein Konsumentensystem mit entsprechendem Bedarf an »Konsumentendruckern« zu werden. Dennoch stellte der komplizierte Filtermechanismus gewisse Anforderungen an die Treiberentwickler, sodass die Produzenten den Aufwand zumeist scheuten.

Das Common Unix Printing System versucht, basierend auf dem Internet Printing Protocol (IPP), eine für alle Unix-Systeme einheitliches Drucksystem zu etablieren.

Die Arbeitsweise von Cups

Wenn Sie Cups auf Ihrem Rechner installieren, dann finden Sie die gebräuchlichsten von LPD-System bekannten Kommandos wieder. Cups bringt sein eigene lpr-Implementierung mit sowie seine eigenen Druckertreiber. Da Cups für die Seitenbeschreibung analog zum LPD auf Postscript zurückgreift, ist der Einsatz von Cups anstelle des LPD für Programme und Anwender letztlich unsichtbar.

Cups enthält Druckertreiber für die meisten Parallelport-, USB- und Serieller-Port-Drucker. CUPS informiert die im lokalen Netzwerk angeschlossenen Rechnern via Broadcast (bei entsprechender Konfiguration) über den/die lokal verfügbaren Drucker, sodass Netzwerkdrucker von entfernten Systemen dynamisch ermittelt werden können.

Des Weiteren bietet CUPS einen Mechanismus, um mehrere Drucker zu einer Gruppe (Klasse) zu vereinigen. Nach außen hin erscheint eine solche Klasse gegenüber Benutzern und Programmen als einzelner Drucker. Auf welchem Drucker eine Klasse ein Auftrag letztlich ausgeführt wird, entscheidet CUPS intern anhand Benutzerrechte und Verfügbarkeit.

Konfiguration von CUPS

Dieser Abschnitt wird bearbeitet...

Festplatte

Verwechslungsgefahr

Eigentlich ist nichts einfacher, als eine neue Festplatte dem System zu spendieren. Ob IDE oder SCSI, sofern Linux mit den Kontrollern umgehen kann, kann nach dem Einbau über das jeweilige Device auf die Platte zugegriffen werden.

Gliedert sich die neue Platte »hinter« den bereits im System befindlichen ein, sind Komplikationen nahezu ausgeschlossen. »Hinter« steht hier für die Reihenfolge der Platten im BIOS. In einem solchen Fall hängt die Festplatte an einem bislang nicht verwendeten Device und Linux wird keine Einsprüche erheben.

Da das neue Stück aber meist mit einer höheren Leistung aufwartet, möchte man nur allzu gern der Platte einen vorderen Platz einräumen. Wer vorschnell die Platten am Kontroller austauscht, wird beim nächsten Booten schmerzlich an seinen Fehler erinnert:

L? Die Ausgabe stammt vom Linux Loader, der sich beschwert, dass seine Daten nicht mehr dort sind, wo er sie erwartet. Lilo hat sich bei seiner Installation gemerkt, auf welcher Festplatte (und dort im Verzeichnis /boot) die von ihm benötigten Dateien stehen. Doch die Festplatte selbst ist unter dem ursprünglichen Device nicht mehr vorhanden, da sich durch die neue Platte die ganze Anordnung verschoben hat.

Denkbar ist auch, dass Sie die Festplatte mit dem Verzeichnis /boot in ihrer relativen Lage gar nicht verschoben haben, vielleicht ja aber die Platte mit der Rootpartition? Dann wird der Kernel mit Sicherheit Einwände hervorbringen:

Die Beispiele sollen verdeutlichen, dass etwas Sorgfalt beim Einbau neuer Festplatten walten sollte. Werden die Daten des Bootmanagers verschoben, kann der Schaden nur anschließend aus einem Rettungssystem heraus behoben werden. Dazu nehmen wir an, dass bislang nur eine Festplatte (als Master) im System existierte und diese zukünftig als Slave am zweiten Kontroller arbeiten soll.

Nach dem Einbau der neuen Platte müssen Sie ein Linux-Rettungssystem starten. Mounten Sie anschließend das Root-Dateisystem (befand es sich vor dem Einbau unter /dev/hda2, so heißt das Device nun /dev/hdb2):

Weisen Sie Ihr Rettungssystem an, das Verzeichnis /mnt als neues Root-Verzeichnis zu verwenden:

Bearbeiten Sie die Datei /etc/fstab und ändern Sie alle Vorkommen von /dev/hda in /dev/hdb. Modifizieren Sie ebenfalls die boot-Zeile der Datei /etc/lilo.conf in »boot=/dev/hdb«. Nehmen Sie analoge Änderungen in allen mit root, other oder table beginnenden Zeilen vor. Starten Sie abschließend Lilo neu:

Wenn Sie nun neu booten, sollte Lilo wie gewohnt arbeiten und Ihr Linux problemlos starten.

Die neue Platte nutzen

Die neue Platte allein nützt wenig, wenn die Daten noch immer auf der alten landen.

Jetzt speichert man unter Unix Daten nicht bewusst in eine Partition, sondern in ein Verzeichnis. Die einfachste Variante zur Nutzung wäre, auf der neuen Partition ein Linux -Dateisystem (ext2 oder ReiserFS) anzulegen und dieses unter einem neuen Verzeichnisnamen zu mounten:

Jede Datei, die unterhalb von /Neues_Verzeichnis abgelegt wird, landet somit in der ersten Partition auf der neuen Platte (im Beispiel ist diese /dev/hda).

Leider hilft das Vorgehen nichts, wenn eine existierende Partition aus allen Nähten zu platzen droht. Eine solche existierende Partition muss nachträglich verteilt werden. Hierzu sollten Sie zuerst nachschauen, welches Verzeichnis zu welchem Prozentsatz die betreffende Partition belegt:

Überprüfen Sie anhand der Ausgabe von df, welches der aufgeführten Verzeichnisse ggf. bereits auf einer anderen Partition liegt. Des Weiteren kommen für die Auslagerung hauptsächlich die Verzeichnisse in Frage, die tatsächlich eine größere Menge Plattenplatz benötigen. Wir demonstrieren das weitere Vorgehen anhand des Verzeichnisses /home. Dieses soll samt Inhalt in die Partition /dev/hda1 verschoben werden.

Als Erstes muss die neue Partition gemountet werden. Es bietet sich dafür das Verzeichnis /mnt an:

Zum Kopieren der Dateien bieten sich die Kommandos tar oder cp an:

Der Inhalt von /home wird nachfolgend gelöscht und /dev/hda1 auf /home gemountet:

Damit zukünftig /home auch nach dem Booten zur Verfügung steht, muss ein entsprechender Eintrag in /etc/fstab ergänzt werden:

Prinzipiell lassen sich nach diesem Schema beliebige Verzeichnisse auslagern. Vorsicht ist bei /boot geboten, da dieses Verzeichnis den Kernel und die Daten des Bootmanagers enthält. Hier muss anschließend der Bootloader neu konfiguriert und installiert werden. Aus einem laufenden System heraus dürfen Sie keine Verzeichnisse löschen, die dynamische Bibliotheken enthalten (/lib, /usr/lib...), da somit alle dynamisch gelinkten Programme (und damit Ihr System) unverzüglich unbrauchbar werden. Solche Eingriffe in das Dateisystem sind nur aus einem Rettungssystem heraus möglich.

Um mehrere Verzeichnisse in eine neue Partition umzusiedeln, muss diese zunächst auf ein neues Verzeichnis gemountet werden:

Die zu verschiebenden Verzeichnisse sind nach /Neues_Verzeichnis zu kopieren. Als Beispiele sollen /home und /usr/X11R6 dienen:

Die alten Verzeichnisse werden verschoben und als Links auf die Kopien neu erzeugt:

Wenn Sie sich vom fehlerfreien Kopieren überzeugt haben, können Sie die Sicherungskopien (home.save, X11R6.save) löschen.

Als weitere Option lässt sich auch ein komplettes Linuxsystem auf die neue Platte verschieben. Die Zielpartition muss groß genug sein, um die gesamten Daten aufnehmen zu können. Ebenso muss auf der Partition ein Linux-Dateisystem eingerichtet worden sein. Nach dem Mounten werden die Dateien beginnend im Wurzelverzeichnis rekursiv in das gemountete Verzeichnis kopiert. Wichtig ist, dass Sie das gemountete Verzeichnis selbst vom Kopieren ausschließen. Vergessen Sie dieses, beginnen Sie eine (Endlos-)Schleife, die erst abbricht, wenn kein Platz mehr auf der Zielpartition verfügbar ist.

Die obige Befehlsfolge klappt nur in der Bash, da sie bei gesetzter Shelloption extglob die Auswertung des Ausdrucks !(...) unterstützt. Nach dem Kopieren müssen Sie das Dateisystem unter /mnt zur neuen Wurzel ernennen:

Wie bereits anfangs beschrieben, sollten Sie die Dateien /etc/fstab und /etc/lilo.conf (bzw. die Konfigurationsdatei des von Ihnen bevorzugten Bootloaders) anpassen und anschließend den Bootmanager neu installieren.

Da Bewegungen von Verzeichnissen, die Systemdateien enthalten, immer mit gewissen Risiken verbunden sind (Wer behauptet von sich, keine Fehler zu machen?), sollten Sie ein vorheriges Backup in Betracht ziehen!

ISDN

Maus

Modem

Ein Modulator wandelt die Bitfolge eines Computers in analoge Signale um, die über eine herkömmliche Telefonleitung übertragen werden können. Um solche "Töne" auf der Empfängerseite wieder in die für den Computer verständliche Form zu transferieren, ist ein Demodulator erforderlich. Das MoDem beinhaltet beide Elemente. Die Digital-nach-Analog-Wandlung (und umgekehrt) kann nach mehreren Techniken erfolgen. Eine Amplitudenmodulation verwendet die Lautstärke als Kodeträger. Die Frequenzmodulation macht sich die Abweichung einer Frequenz von der Trägerfrequenz zu eigen. Eine Phasenmodulation baut in die sinusförmige Signalwelle Sprünge ein, die wiederum das kodierte Signal repräsentieren. Um die hohen Datenraten zu erzielen, wird in der Praxis die Amplitudenmodulation mit der Frequenzmodulation gekoppelt (Quadratur-Amplitudenmodulation); auch komprimieren die meisten Modems intern den Datenstrom.

Obwohl immer wieder die Bezeichnung des ISDN-Modems zu lesen ist, handelt es sich bei solchen Karten nicht in jedem Fall um Modems. ISDN-Modems unterstützen neben digitalen zusätzlich analoge Verbindungen, während häufig auch Karten, die nur digitale Verbindungen handhaben können, (fälschlich) als ISDN-Modems bezeichnet werden. ISDN-Karten und Modems ist gemeinsam, dass sie die Datenübertragung über die Telefonleitung ermöglichen. ISDN belegt aber ein Frequenzband unterhalb dem des analogen Modems (DSL belegt wiederum ein oberes Band). Um dieses Frequenzband nutzen zu können, sind sowohl auf Seiten des Teilnehmers als auch in der Vermittlungsstelle spezielle Geräte erforderlich. Ein "Analogmodem" arbeitet im Frequenzbereich der traditionellen Telefonanschlüsse. Dem Thema Integrated Services Digital Network ist ein eigener Abschnitt gewidmet.

Für USB-Modems bedarf es neben einem aktuellen Kernel (> 2.2.18) der entsprechenden Devices. Wie Sie diese ggf. erzeugen, ist im Abschnitt zum Universal Serial Bus erläutert.

Was Sie hier eventuell vermissen werden, ist eine Installationshilfe zu Winmodems. Aber deren Emulation, betrieben unter dem Projektnamen Linmodem, steckt derzeit noch in den Kinderschuhen und ist für den praktischen Einsatz nur bedingt geeignet. Diese Winmodems sind abgespeckte "richtige" Modems, wobei die fehlende Funktionalität durch Software emuliert wird. Der Name Winmodem deutet deren Zeilplattform schon an und vieles, was für Windows entwickelt wurde und wird, ist rein kommerziell. Leider lassen sich die Hersteller solcher Modems nicht in die Karten sehen, sodass die Linuxentwickler durch langwieriges Ausprobieren der Funktionsweise des jeweiligen Modells auf die Spur kommen müssen. Erste Erfolge kann das Projekt vorweisen, aber allgemein von unter Linux funktionierenden Winmodems zu sprechen, ist sicherlich verfrüht.

Der physische Anschluss eines Modems

Analoge Modems werden in den Bauformen intern und extern angeboten. Aus Sicht des Betriebssystems besteht zwischen beiden kein Unterschied, da beide an eine serielle Schnittstelle angeschlossen werden. Externe Modems bringen keine eigene Schnittstellenkarte mit und bedingen somit eine freie Schnittstelle im System. Die meisten Mainboards verfügen über zwei serielle Schnittstellen, sodass das externe Modem nach dem Einstecken des Kabels entweder am Device /dev/ttyS0 (COM1 unter DOS) oder an /dev/ttyS1 (COM2) hängt. Verwenden Sie eine serielle Maus, ist eines der Geräte bereits durch diese belegt. Für externe Modems sind somit die verwendeten Ressourcen strikt vorgegeben.

Interne Modems stecken in einem PCI- oder ISA-Slot und stellen eine eigene serielle Schnittstelle dar. Unterstützen die Modems Plug&Play, sollte ein aktueller Kernel-Treiber für die seriellen Schnittstellen (wahlweise als Modul realisiert) diese automatisch konfigurieren können.

Welche seriellen Schnittstellen der Kernel bereits während des Bootvorgangs initialisiert hat, können Sie anhand der Ausgabe des Kommando dmesg (oder mittels "setserial -g ttyS*") nachvollziehen:

16550A ist der Schnittstellenbausteins. Der aufgeführte Typ sollte eigentlich in jedem einigermaßen aktuellen Rechner stecken.

Im Falle der Nichterkennung durch den Kernel müssen Modem und Treiber von Hand eingerichtet werden. Notwendig ist hierfür das Kommando setserial, das dem Treiber die IO-Adresse und den Interrupt mitteilt, die ein serieller Port verwendet. ISA-PnP-Modems sollten Sie wie im Abschnitt zu Plug&Play beschrieben initialisieren. Für PCI-Modems sollten Sie das Kommando lspci konsultieren, um zu erfahren, ob Ihr BIOS die PCI-Karte aktiviert und welche Ressourcen es ihr zugeordnet hat:

Wenn ein PCI-Modem vom BIOS initialisiert wurde, so muss es in der Ausgabe zu sehen sein. Wenn nicht, sollten Sie die Einstellungen im BIOS kontrollieren (ggf. können Sie dort feste Ressourcen an PCI-Geräte vergeben).

Ältere ISA-Modems beherrschen nicht die Einstellungen via PnP-BIOS. Diese werden durch Jumper (kleiner Kippschalter) direkt auf der Platine auf konkrete Ressourcen eingestellt. Wie, das erklärt Ihnen das Handbuch zum Modem. Stellen Sie die Werte nicht willkürlich ein, sondern schauen Sie in /proc/interrupts und /proc/ioports nach, ob die Ressourcen nicht schon durch ein anderes Gerät belegt sind.

Kennen Sie nun die Werte für IO-Port und Interrupt, so verwenden Sie setserial, um dem Treiber den seriellen Port bekanntzugeben:

Achtung: setserial ändert nicht die Einstellungen des Modems, sondern nur die im Treiber! Verwenden Sie also die Werte, die Ihrem Modem exakt entsprechen.

Test der Konfiguration

Eine unorthodoxe Methode, um die Konfiguration zu testen, ist das direkte Senden von Hayes-Befehlen an das Modem:

Obiges Beispiel fordert ein Modem an der 3. seriellen Schnittstelle auf, die angegebene Nummer zu wählen. Falls das Modem reagiert, sollten Wählgeräusche zu vernehmen sein.

Natürlich taugt obiger Versuch nur zu einem ersten Schnelltest. Um die Reaktionen eines Modems zu erfahren, sollten Sie auf ein Terminalprogramm wie minicom oder seyon zurückgreifen.

Aber auch ohne ein installiertes Terminalprogramm kann dem Modem - falls es korrekt ins System eingebunden wurde- eine Antwort entlockt werden. Als nützlich hat sich hierfür screen erwiesen, ein Programm, das in den meisten Standardinstallationen enthalten ist. screen ist ein Bildschirmmanager, der VT100- und ASCII-Terminals emulieren kann:

Die Zeichen der mit AT beginnenden Zeile stammen aus dem Hayes-Kode, der sich quasi als Standard-Befehlssatz für Modems durchgesetzt hat. Einige der wichtigeren Befehle fasst nachfolgende Liste zusammen:

/dev/modem

Bei einigen Distributionen ist es Brauch, /dev/modem als Link auf das physische Gerät, an dem das Modem angeschlossen ist, anzulegen. Daran ist nichts auszusetzen, solange Sie das Modem nur zur Einwahl ins Internet verwenden.

Haben Sie allerdings vor, Ihren Rechner als Anrufbeantworter oder Einwahlserver zu konfigurieren, so beschwört /dev/modem rasch eine Menge Ärger herauf. Normalerweise wird eine Schnittstelle /dev/ttyS* für den Zugriff gesperrt, sobald ein Prozess sie geöffnet hat. Dieser exklusive Zugang wird durch Verwendung des Links /dev/modem ausgehebelt, da die notwendigen Dateisperren nicht gesetzt werden. Somit kann die Situation eintreten, dass eine Einwahl möglich ist, obwohl zurzeit bereits eine Verbindung durch den Einwahlserver eingegangen wurde. Die Folge wird sein, dass sich beide Anwendungen in die Quere kommen und durch die wechselseitige Kommunikation die Verbindung unbrauchbar wird.

Geschwindigkeit und Ausblick

Aktuelle Modems arbeiten nach dem V.90 Standard und werden mit einer Übertragungsrate von 56kBit/s angegeben. Nur erreicht werden solche Raten niemals. Mit etwas Glück bläst das Modem die Daten mit 35..45 kBit/s über die Leitung. Wieso diese Diskrepanz?

Auch wenn wir am Telefon uns mit unserem Gesprächspartner alleine in der Leitung wähnen, so tummeln sich in Stoßzeiten noch 50 andere kommunikationsbedürftige Menschen in derselben Strippe. Unsere Gespräche werden nicht komplett übertragen, sondern nur Bruchteile davon. Die Trägheit des menschlichen Gehörs "überhört" die fehlenden Teile. Es ist dasselbe Prinzip wie beim Bildschirm, wo erst die hohe Frequenz ein "stabiles" Bild suggeriert.

Was für das Gehör nicht wahrnehmbar ist, erweist sich in der Datenübertragung als Problem. Das Modem ist theoretisch so schnell, dass die Gesprächslücken zum Tragen kommen. Ein Modem muss nun mit gedrosselter Geschwindigkeit arbeiten, wie stark verlangsamt, hängt u.a. von der Güte der Leitung ab. Und darauf hat der Modembenutzer nunmal keinen Einfluss. Was er dennoch sichern sollte, ist die ausreichende Versorgung des Modems mit Daten. Da Modems intern den Datenstrom komprimieren, sollte die Datenrate von Rechner zu Modem um das 2-3-fache über der maximalen Übertragungsgeschwindigkeit des Modems liegen.

In den meisten Terminalanwendungen können Sie die Datenrate einstellen. Für die seltenen Fälle, wo dies nicht gelingt, sollte der Treiber mit dem Kommando setserial auf einen entsprechend hohen Wert eingestellt werden:

In diesem Abschnitt wurde das Verfahren beschrieben, mit dem Sie Ihr Modem ins System integrieren. Vermutlich möchten Sie nun auch die Vorzüge eines Browsers genießen und im großen weiten Netz auf die Pirsch gehen. Hierfür sind allerdings noch weitere Schritte erforderlich, die Sie im Netzwerkteil des Buches kennen lernen werden (Netzwerk-Grundlagen, Initialisieren der Hardware).

Netzwerkkarte

Vereinfachend gehen wir im folgenden Abschnitt davon aus, dass es sich bei der Netzwerkkarte um einen Ethernet-Adapter handelt. Ethernet ist die mit Abstand verbreitetste Netzwerktechnologie und nur selten wird man auf das in die Jahre gekommene Tokenring oder die im Forschungsbereich eingesetzten Technologien wie Scalable Coherent Interface (SCI) oder Myrinet treffen. Abgesehen von abweichender Treiberbenennung verläuft deren Grundkonfiguration analog zur folgenden Diskussion.

An dieser Stelle widmen wir uns einzig dem Ziel, dass die Netzwerkkarte vom Linuxkernel erkannt und der passende Treiber geladen wird. Die weiteren Schritte zur Konfiguration bleiben dem entsprechenden Abschnitt in Netzwerk-Grundlagen vorbehalten.

Adaptertyp

Eine Entscheidung zwischen 10MBit- und 100MBit-Karten sollte nicht mehr von nöten sein. Zwar ist ein Geschwindigkeitsunterschied wirklich nur bei häufigem Transfer umfangreicher Datenmengen zu spüren, aber der Aufpreis für den schnelleren Typ ist inzwischen so marginal, dass 10MBit-Karten in naher Zukunft aus den Händlerregalen vollends verschwinden werden. Falls in Ihrem Netzwerk noch 10MBit-Karten ihren Dienst verrichten, so sollten Sie bei der Neuanschaffung auf Karten achten, die beide Modi unterstützen. ISA-Karten sollten ebenso wie Karten mit BNC-Anschluss der Vergangenheit angehören. PCI-Adapter mit RJ-45-Anschluss sind Stand der Technik.

Ob Markenprodukt oder Noname-Karte ist schon eine schwierigere Entscheidung. Letztere versprechen zwar meist 100% Kompatibilität zum »Standard«, doch berichten verschiedenste Quellen, dass es dann doch nicht in jedem Fall problemlos mit dem Einsatz klappt. In meinem privaten Testnetzwerk verrichten billige Realtek-Chips zuverlässig ihren Dienst; die schlechten Erfahrungen anderer mit solchen Karten kann ich somit nicht bestätigen. Bevor Sie eine größere Anzahl bestimmter Karten anschaffen, sollten Sie den erwählten Typ besser anhand eines einzelnen Exemplars auf Herz und Nieren prüfen.

Kernelkonfiguration

Die den Distributionen beiliegenden Linuxkernel beinhalten die Treiber aller gängigen Kartentypen von Haus aus. I.d.R. kommen Sie um eine neue Kernelerzeugung umhin.

Wenn Sie Ihre Karte ordnungsgemäß eingesetzt haben, sollte der Kernel beim nächsten Booten diese selbsttätig erkennen und initialisieren. In den Bootmeldungen finden Sie Angaben ähnlich den folgenden (mit »dmesg« lassen sich die Meldungen später erneut anzeigen):

Finden Sie in der Ausgabe ihrer Ethernetkarte entsprechende Angaben (eindeutige Merkmale sind »eth0« am Beginn der Zeile und die enthaltene MAC-Adresse [im Beispiel: 00:00:1c:d9:4e:37]), so lesen Sie im Kapitel »Netzwerk-Grundlagen - Allgemeine Dienste, Netzwerkkarte« weiter.

Die obigen Ausgaben kommen zustande, weil alle Ethernettreiber im Kernel automatisch die Hardware testen und anhand typischer Registerwerte eine Karte zu identifizieren versuchen (»Autoprobing«). Scheitert die Erkennung, so sind im Wesentlichen drei Ursachen denkbar:

Der Kernel kennt keinen passenden Treiber für die Karte

Sie kommen um die Erzeugung eines eigenen Kernels nicht umhin. Günstig ist, wenn Sie den genauen Kartentyp kennen, dann müssen Sie nur die entsprechende Option in den Kernel einkompilieren. Informationen zum Typ erhalten Sie aus den Unterlagen zur Karte - falls sie denn der Karte beiliegen. Auch ein Blick auf den Chip der Karte kann die erforderlichen Informationen bringen oder Sie konsultieren den PCI-Bus, falls es sich um einen PCI-Ethernet-Adapter handelt:

Mit etwas Glück gewinnen Sie so gleich die anderen wichtigen Information wie Interrupt (IRQ) und die Port-Adresse.

Fehlen Ihnen dennoch die Informationen zur eingebauten Karte, so können Sie immer noch einen Kernel erzeugen, der sämtliche »in Frage kommenden« Ethernet-Treiber als Modul enthält und wie in den nächsten Punkten beschrieben, verfahren.

Das Treibermodul existiert, wurde aber nicht geladen

Hier ist wiederum die Kenntnis des Kartentyps und damit des zu verwenden Treibermoduls nützlich. So lässt sich einfach mittels:

der passende Treiber laden. »Modulname« ist eine der Objektdateien aus dem Verzeichnis »/lib/modules/Kernelversion/kernel/drivers/net/« ohne den Suffix ».o«. Vom Namen lässt sich meist einfach auf den vom Modul unterstützten Kartentyp schließen.

Ohne Kenntnis des richtigen Moduls können Sie einzig die Module durchprobieren, bis das Laden eines glückt. Ein Aufruf von

sollte genügen, um alle Module vom Typ »net« zu testen und das erst beste zu laden. Leider funktionierte in meiner Installation der Befehl nicht wie erhofft, sodass erst folgende Kommandozeile den erhofften Erfolg brachte:

Nähere Informationen zum Umgang mit Modulen finden Sie im Abschnitt Kernel-Module.

Das Laden des richtigen Treibers scheiterte

Sie sind sich sicher, den richtigen Treiber ausgewählt zu haben und dennoch scheiterte das Laden? Dann könnte ein Resourcenkonflikt die Ursache sein.

Jeder Treiber sucht seine entsprechenden Karten an typischen Portadressen. I.d.R. werden die Karten vom Hersteller tatsächlich auf die »üblichen« Werte konfiguriert, jedoch können diese entweder durch Jumper auf der Karte oder per Software modifiziert werden. In einem solchen Fall müssen dem Treiber die abweichenden Werte vermittelt werden. Angenommen, eine Karte mit Realtek-Chip reagiere auf den Interrupt 9 und ihre Basisadresse lautete e400, dann müsste das Laden des entsprechenden Treibers mit folgenden Argumenten erfolgen:

Für fest in den Kernel integrierte Treiber sind die Parameter dem Kernel am Bootprompt mitzugeben:

Ein Resourcenkonflikt wird ebenso bestehen, wenn die von der Karte erwarteten Einstellungen zum Zeitpunkt des Treiberladens bereits von einem anderen Gerät belegt sind. Hier können Sie entweder dieses Gerät entfernen (dessen Treiber entfernen, falls es sich um ein Modul handelt) oder entweder das Gerät oder die Karte auf andere Resourcen konfigurieren (PCI-Geräte lassen sich bspw. im BIOS einstellen).

PCMCIA

Plug&Play

Bei Plug&Play-Geräten handelt es sich um "modernere" ISA- bzw. PCI-Karten. Traditionell erfolgte die Konfiguration von (alten) ISA-Karten über Jumper auf der Platine, die die Karte veranlassen, bestimmte Interrupts (IRQ) und Ein/Ausgabe-Adressen (I/O-Ports) zu verwenden. Dieses Vorgehen erforderte eine gewisse Kenntnis über das Zusammenspiel der verschiedenen Hardware-Komponenten und bescherte dem Laien bei nachträglichem Einbau solcher Karten oft gravierende Unannehmlichkeiten. Wer weiß schon, dass die erste und dritte serielle Schnittstelle in der Standardkonfiguration ein und denselben Interrupt verwenden? Und wer versteht, in welcher Konstellation die gleichzeitige Verwendung beider Schnittstellen zu Konflikten führt und wann nicht?

Das Allheilmittel lautete Plug&Play. Im Idealfall sollte eine Karte nach Einbau mittels beiliegender Software selbsttätig einen freien Interrupt und IO-Port wählen und den Anwender vor allerlei Details bewahren. Leider klafft zwischen Theorie und Praxis wie so häufig eine tiefe Kluft, im Einzelfall versagte nicht selten die Konfiguration von "Geisterhand". Nicht zuletzt sind diese Probleme ein Grund, warum bei zahlreichen Karten die Plug&Play-Funktionalität per Jumper deaktiviert werden kann.

In Sachen Linux kommt es gar noch schlimmer. Kaum ein Hersteller von Hardware scherte sich (zumindest bis vor wenigen Jahren) um die Unterstützung des "Bastler-Systems"; die für Plug&Play notwendige Software wurde nie auf Linux portiert. Aber sobald einige Linuxer etwas schmerzlich vermissen, wird sich irgendwer finden, der das System um die Eigenschaft erweitert. Und so lassen sich auch die Plug&Play-Karten mit geringem Aufwand unter Linux verwenden.

Woher bekomme ich die Parameter?

Den obigen Abschnitt prägt wohl doch reichlich Optimismus - die Interrupts und Ein/Ausgabe-Adressen muss ich wissen... Aber woher?

Das nachfolgend vorgestellte Werkzeug pnpdump versucht, diese Werte aus den ROMs aller im System befindlichen Plug&Play-Karten auszulesen. Allerdings warnt das Manual davor, diesen Werten zu vertrauen, da die ROM-Programmierung allzu oft fehlerbehaftet ist. Wenn vorhanden, sollte man daher andere Quellen konsultieren.

Erster Anlaufpunkt sollte das Handbuch zur Hardwarekomponente sein. Dort sind normalerweise die gebräuchlichen Parameter angeführt. Notieren Sie sich vor allem die Werte für Interrupt- und IO-Port-Adress-Kombinationen. Verfügen Sie über eine Windows-Installation und ist die Plug&Play-Karte dort funktionsfähig, so lohnt sich auch ein Blick in die dortige Systemkonfiguration, um die Werte auszulesen.

Halten Sie sich aber mit Ihrer Freude ob der verheißungsvollen Parameter noch etwas zurück. Zuerst sollten Sie sich vergewissern, dass diese Werte unter Linux nicht schon von einer anderen Komponente reserviert sind.

Die aktuelle Interrupt-Belegung offenbart Ihnen der Blick in die Datei /etc/interrupts, reservierte IO-Ports enthält die gleichnamige Datei /proc/ioports und die DMA-Kanäle stehen in /proc/dma. Finden Sie in den Herstellerangaben nun eine Kombination aus Interrupt und IO-Port-Adresse, die in beiden Dateien nicht erscheint, so steht einer weiteren Konfiguration nichts im Wege.

Was aber, wenn in allen unterstützten Varianten bereits ein anderes Gerät die Ressourcen belegt? Dann können Sie nur versuchen, eine solche Hardwarekomponente mit anderen Parametern zu konfigurieren oder - schlimmsten Falls - ein solches entfernen. Da in heutigen Kerneln die Hardware nahezu ausschließlich per Module angesprochen wird, laufen derartige Maßnahmen auf ein Entladen und anschließendes Neuladen des Moduls mit anderen Parametern hinaus.

Das weitere Vorgehen zum Erziehen der Plug&Pray-Komponente vollziehen wir anhand eines Beispiels. Es handelt sich um eine Soundkarte Vibra 16 PnP.

Der Treiber

Um die Karte anzusprechen, wird ein Treiber benötigt. Dieser muss als Modul realisiert werden. Erzeugen Sie also einen neuen Kernel, wobei Sie die Soundunterstützung als Modul realisieren. Da es sich bei der Vibra 16 PnP um einen 100% Soundblaster-Clone handelt, muss diese Karte in der Kernelkonfiguration gewählt werden. Ebenso tragen Sie Interrupt, IO-Port-Adresse und DMA-Kanäle entsprechend der ermittelten Vorgaben ein.

Hinweis: Bei den Kerneln, die die Distributoren aktuell ausliefern, liegen die Treiber für die gängigen Hardwarekomponenten meist als Modul bei (im Falle von Soundblaster ist das Modul /lib/modules/Kernelversion/misc/sound.o), sodass der Schritt der Kernelerzeugung entfallen kann. Da Sie jedoch nicht wissen, mit welchen Voreinstellungen (Interrupt etc.) ein Modul generiert wurde, müssen Sie diese Werte beim Laden des Moduls als Parameter angeben (dazu später mehr).

Erzeugung der Konfigurationsdatei

Plug&Play-Karten müssen vor ihrer Verwendung initialisiert werden. Erst dann kennen sie den ihnen zugedachten Parameter. Die Initialisierung selbst übernimmt isapnp, das die einzustellenden Werte in einer Datei /etc/isapnp.conf erwartet.

Es gilt nun, diese Datei anzulegen. Dies geschieht durch Aufruf von pnpdump. Das Programm ermittelt anhand der Informationen aus dem ROM aller vom BIOS erkannten Plug&Play-Karten deren mögliche Konfigurationen und schreibt alle ermittelten Daten auf die Standardausgabe, wobei sämtlichen Zeilen das Kommentarzeichen voran steht:

Die für die Hardwarekomponenten zuständigen Zeilen, also die, die mit den Einstellungen im Modul korrespondieren, sind nun freizuschalten. Zuvor kann aber ein Versuch nicht schaden, pnpdump -c die endgültige Konfiguration selbst übernehmen zu lassen. Das Programm bedient sich hierzu der Informationen aus /proc/interrupts und /proc/ioports. Gelangt das Tool zu keiner zufrieden stellenden Lösung, sollten die Zeilen manuell ausgewählt werden.

Für eine Vibra16 PnP mit den Einstellungen IRQ=5, DMA 0 auf Kanal 1, DMA 1 auf Kanal 5, IO-Port 0x220 sieht der entsprechende Ausschnitt wie folgt aus:

Aktivierung der Karte und Test

Vor dem Laden des Moduls muss die Karte initialisiert werden. Das Kommando isapnp ist hierzu mit der entsprechenden Konfigurationsdatei aufzurufen:

modprobe lädt das Modul nur, wenn es zu keinen Konflikten mit anderen Treibern kommt. Auch wenn keine Fehlermeldungen erschienen, sollten Sie sich vom ordnungsgemäßen Verlauf überzeugen. Sehen Sie hierzu in einer der Dateien /proc/interrupts oder /proc/ioports nach, ob die Ressourcen von dem Modul reserviert wurden:

Wurde das Modul nicht geladen, liegt vermutlich ein Ressourcenkonflikt vor (die benötigen Ressourcen sind belegt oder die Hardwarekomponente konnte nicht gefunden werden). Sie können nun versuchen, das Modul mit verschiedenen Parametern zu laden. Diese sollten jedoch den frei geschalteten Angaben der Datei /etc/isapnp.conf entsprechen. Für den Fall obiger Vibra16 PnP müsste folgende Kommandozeile angewandt werden:

Letztlich hilft wohl nur das Ausprobieren. Aber zum Glück richtet man Hardware nicht alltäglich ein. Ist eine lauffähige Konfiguration einmal gefunden, sollten die Kommandoaufrufe in eines der Bootskripte integriert werden, um die Karte mit jedem Systemstart automatisch zu aktivieren.

Soundkarte

Die meisten Distributionen kommen mit Unterstützung der gängigen Soundkarten daher, dennoch finden sich eine Reihe von Exoten, denen es bislang nicht vergönnt wurde, in den Linuxkernel Einzug zu halten. Noch vor wenigen Jahren musste sich der Anwender gedulden, bis die Kernel-Entwickler entsprechende Treiber anboten, doch unterdessen hat sich die Situation erheblich gebessert, denn neben den Kernelbauern werkeln zumindest zwei weitere Teams an entsprechenden Projekten.

Die Treiber des Open Sound Systems (OSS) besitzen allerdings einen Schönheitsfehler: Sie sind ein kommerzielles Produkt und kosten entsprechend Geld. Wer allerdings seiner Soundkarte mit freien Mitteln partout keine Töne zu entlocken vermag, der mag auch diese Kosten auf sich nehmen. Für den Fall sollte er sich die Evaluierungsversion besorgen und zunächst testen, ob das Produkt die Probleme behebt. OSS soll für diesen Abschnitt keine Rolle spielen.

Mit gesteigertem Interesse verfolgt die Linuxgemeinde die Bemühungen um das Projekt Advanced Linux Sound Architecture (ALSA), dessen Konfigurationswerkzeug wir später noch begegnen werden.

Doch zunächst betrachten wir die "hauseigenen" Möglichkeiten, die der Linuxkernel mit sich bringt.

Kernige Klänge

Um eine Soundkarte ansprechen zu können, muss der Kernel dafür gerüstet werden. Dazu bedarf es zu aller erst der Kenntnis, welche Soundkarte denn im Rechner steckt. I.d.R. verrät Ihnen das Handbuch zur Karte deren Typ. Den billigeren Karten liegt allerdings seltener, den onboard-Soundchips gar nur in Ausnahmefällen eine Dokumentation bei. Bei Karten hilft ausbauen und ein Blick auf die Beschriftung des Chips; bei (onboard-) PCI-Karten sollte die Ausgabe von /sbin/lspci -a die notwendigen Informationen liefern.

Wissen Sie rein gar nichts über die installierte Soundkarte, so kann ein Versuch, ihr die Töne über die gängigen Standards zu blasen, nicht schaden. Denn viele Karten sind zu Soundblaster (16), Soundblaster Pro oder zum Windows Sound System kompatibel. Handelt es sich um eine onboard-Soundkarte, so könnte es sich um CMI8330 oder ES1371 handeln.

Erzeugen Sie sich einen Kernel mit Soundunterstützung (als Modul). Wenn es ob des Typs der Karte keinen Zweifel gibt, so erzeugen Sie ein entsprechendes Modul. Ansonsten realisieren Sie alle in Frage kommenden Typen als Modul. Die Einstellungen für Interrupt, IO-Ports und DMA-Kanäle sollten Sie so wählen, wie es für die Karte typisch ist. Als Option lassen sie sich aber auch beim Laden des Moduls überschreiben, sodass fehlerhafte Werte nicht weiter stören.

Haben Sie den neuen Kernel samt Modulen installiert, geht es ans Testen, welches Modul mit welchen Einstellungen nun das richtige ist.

Die Sound-Module selbst befinden sich im Verzeichnis /lib/modules/Kernel-Version/misc/, anhand deren Namensgebung müssen Sie nun auf die unterstützte Karte schließen, was in den meisten Fällen nicht weiter problematisch sein dürfte. Beispielhaft soll der Versuch, eine Soundkarte über das Soundblaster-Modul anzusprechen, skizziert werden:

modprobe brach mit einem Fehler ab und weist auf die mögliche Fehlerursache hin: "...invalid IO or IRQ parameters" (Vorsicht: Die Ausschriften sind nicht immer aussagekräftig!). Die nächsten Versuche zielen darauf ab, die Parameter für Interrupt und IO-Port zu variieren. Schauen Sie zuvor in die Dateien /proc/interrupts und /proc/ioports, um die Suche auf sinnvolle - d.h. verfügbare - Werte zu beschränken.

Läuft modprobe ohne Fehler durch, so ist es Zeit, die Tonwiedergabe zu testen. Schreiben Sie eine beliebige Wave-Datei auf das Device der Soundkarte:

Ist die Wiedergabe einigermaßen klar, so wurde die Soundkarte korrekt eingebunden. Bei stark verzerrten oder fehlendem Ton sollten Sie die obigen Konfigurationsschritte mit einem alternativen Treiber wiederholen.

sndconfig

Speziell für Soundkarten der Plug&Play-Gattung ermöglicht ein Werkzeug von RedHat eine komfortablere Konfiguration. sndconfig basiert auf der ncurses-Bibliothek und ist somit im Prinzip unter jeder Linux-Distribution nutzbar.

sndconfig stellt nur eine Verpackung für das im Abschnitt Plug&Play vorgestellte isapnp dar. Um eine Soundkarte ansprechen zu können ist somit immer noch ein entsprechender Kerneltreiber erforderlich. Bei den aktuellen Distributionen liegen eigentlich immer die gängigen Treiber bereits in Form von Modulen vor, sodass eine Kernelübersetzung selten notwendig wird.

sndconfig schickt sich sogleich an, den Kartentyp selbsttätig zu erkennen (mit der Option --noprobe lässt sich dies umgehen). Wird der Vorgang von Erfolg gekrönt., zeigt die nächste Maske den Typ des gefundenen Soundchips.

Ist die Datei /etc/isapnp.conf vorhanden (bspw. weil bereits zuvor eine Initialisierung von Plug&Play-Karten erfolgte, so wird diese nach /etc/isapnp.conf.bak verschoben (i.d.R. sollten die Einstellungen anderer Hardware in dieser Datei unverändert bleiben). Dasselbe gilt für /etc/modules.conf, deren ursprüglicher Inhalt nachfolgend unter /etc/modules.conf.bak zu finden ist.

Um den nachfolgenden Test kommen Sie nicht umhin.

Drei Situationen könnten nun eintreten:

1. Das Klangbeispiel war zu hören Die Einstellungen sind soweit i.O. Der Test wiederholt sich nun mit einer MIDI-Datei, um den Synthesizer zu überprüfen.
2. Das Klangbeispiel war nicht zu hören Der Treiber wurde zwar korrekt geladen, aber die Einstellungen (Interrupt, IO-Adressen, DMA-Kanäle) enthalten einen oder mehrere Fehler
3. Eine Fehlermeldung erschien Das Laden des Treibers scheiterte. Betrachten Sie die Ausgaben, denn sie geben Auskunft über die Ursache. Entweder steht dort, welche Ressource nicht reserviert werden konnte oder dass das Laden des Moduls scheiterte. In letzterem Fall stimmt der Typ der Soundkarte nicht.

Unabhängig vom Grund besteht im Falle einer gescheiterten Erkennung oder eines fehlgeschlagenen Tests die Möglichkeit der manuellen Konfiguration. In der Liste der Soundkartentypen sollten Sie den Eintrag auswählen, der am ehesten Ihrer Hardware entspricht. Die meisten Karten beherrschen verschiedene Soundsysteme, somit kann der Versuch eines alternativen Treibers (normalerweise steht in Ihrem Handbuch, was Ihre Soundkarte neben dem empfohlenen Soundsystem noch versteht) nicht schaden. Der im Screenshot dargestellten Karte vom Typ "CMI8330 Soundchip" konnten bspw. sowohl mit dem angegebenem Modul, als auch mit dem Windows Sound System, dem Soundblaster sowie dem Soundblaster-Pro-Treiber Töne entlockt werden, wobei die letzteren zwei Treiber eher an einen Kehlkopfschaden erinnerten. Mitunter ist eben etwas Geduld erforderlich.

Haben Sie sich für eine Karte entschieden, so erscheint eine Maske, deren Felder stark vom gewählten Kartentyp abhängen. Um die Anzahl der Experimente zu reduzieren, könnten Sie zunächst die Werte der Datei /proc/interrupts und /proc/ioports konsultieren. Ressourcen, die dort aufgeführt sind, sind in Benutzung und stehen damit der Soundkarte nicht zur Verfügung. Allerdings ist nicht gesagt, dass Ressourcen, die nicht erwähnt sind, nicht doch andersweitig in Verwendung sind. So erscheint ein Interrupt in /proc/interrupts erst, nachdem er erstmals verwendet wurde.

Nach den Einstellungen wiederholen sich die Tests mit den beiden Klangbeispielen. Erst wenn beide erfolgreich verliefen, speichert sndconfig die Konfiguration in der Datei /etc/sysconfig/soundcard. In RedHat-basierten Linuxsystemen wird isapnp automatisch beim Systemstart gerufen (verantwortlich ist die Datei /etc/rc.d/rc.sysinit), sodass die Einstellungen nach jedem Neustart zur Verfügung stehen. In anderen Systemen sollten Sie ggf. einen entsprechenden Aufruf in eines der Bootskripte einbauen.

alsaconf

Bei alsaconf handelt es sich um eine grafische Verpackung der zur Installation der Soundtreiber des ALSA-Projektes notwendigen Schritte. Mit ALSA ist es sogar möglich, einem System ohne Soundkarte eine Soundkarte zu spendieren. Natürlich werden Sie einer solchen Dummy-Karte keine Töne entlocken können, aber Programme, die partout auf einer Karte bestehen, lassen sich so zur Mitarbeit motivieren.

Voraussetzung für den Einsatz der ALSA-Treiber ist eine Sound-Unterstützung durch ein Kernel- Modul (soundcore.o). Eine Soundkarte selbst muss nicht eingebunden werden, falls sie dennoch bereits existiert, genügt es, deren Modul zu entladen. Im Falle von Plug&Play-Karten muss das Paket isapnp installiert sein.

Bei erstmaliger Verwendung von Alsa-Sound sollten Sie als Root das Skript snddevices starten, um die notwendigen Einträge unterhalb des Verzeichnisses /dev und im Prozessdateisystem anzulegen. Dieser Schritt entfällt, falls Sie ALSA als Rpm-Paket installiert haben, da hierbei die notwendigen Dateien bereits erzeugt wurden.

Nach dem Begrüßungsbildschirm schickt sich alsaconf an, die im System befindlichen Soundkarten zu erkennen. Wird alsaconf fündig, werden die erkannten Kartentypen nacheinander aufgelistet.

Nur wenn kein Soundchip erkannt wurde, listet alsaconf alle unterstützten Typen auf. Sie können nun eine Karte auswählen (die, die Ihrer Karte am "ähnlichsten" ist) und wie beschrieben fort fahren.

Im nächsten Dialog bietet alsaconf an, die Datei /etc/modules.conf zu modifizieren. Falls - wie in aktuellen Konfigurationen üblich - der Kernel-Dämon zum Laden von Modulen zum Einsatz gelangt, brauchen Sie sich zukünftig nicht mehr um das Laden der Module zu kümmern, da dies bei Bedarf vom Dämon übernommen wird. Wenn Sie diese Frage verneinen, bricht alsaconf die Konfiguration ab.

Die nächste Ausschrift beschreibt nur das weitere Vorgehen. Nützlich ist der Hinweis auf das Programm amixer, eine Möglichkeit, die Soundausgabe auf der Konsole zu konfigurieren (Lautstärke, Balance etc.).

Im abschließender Test lädt alsaconf die Treiber und spielt ein Klangbeispiel ab. Das Programm endet ohne nochmalige Rückfrage.

Tastatur

Auch wenn ein entsprechend konfiguriertes Linuxsystem prinzipiell einer Tastatur entbehren kann (wenn es bspw. über die serielle Schnittstelle gesteuert wird - und selbst dann werden die Tastatureingaben emuliert), so gehen wir nachfolgend davon aus, dass das System auf Tastatureingaben reagiert. Wenn dem nicht so ist, haben Sie ein Problem - wie sollten Sie nun die Konfiguration anpassen?

Eine Tastatur ist nur ein passives Stück Hardware, das bei Betätigung einer der vielen kleinen Knöpfe einen standardisierten Code über das Kabel an den Rechner sendet. Und alles, was mit der Hardware des Rechners zu tun hat, obliegt zunächst der Kontrolle des Kernels. Im Falle der Tastatur entscheidet der Keyboardhandler von Linux über das weitere Gebahren.

Welche Taste bewirkt was?

Der Keyboardhandler ordnet jedem Tastencode eine Bedeutung zu oder er ignoriert ihn schlicht und einfach, je nachdem, ob der Code in seiner Tastaturtabelle enthalten ist oder nicht. Eine Taste, die hier nicht aufgeführt ist, steht somit keinem Programm zur Verfügung!

Die meisten Programme verwenden jedoch nicht direkt die von der Tastatur gelieferten Codes, sondern überlassen die Interpretation der readline-Bibliothek. Wie diese die Codes handhabt, wird wiederrum in den Dateien /etc/inputrc und ~/.inputrc konfiguriert. Mehr zu diesem Teil der Konfiguration erfahren Sie im Abschnitt Bash, wo beispielhaft die Interpretation der Tasten für die Bourne Again Shell (Kommando: bind) modifziert wird. Im weiteren Verlauf dieses Abschnitts widmen wir uns einzig dem Teil der Konfiguration, der u.a. die readline-Bibliothek mit Tastencodes füttert.

Verschiedene Tastaturtabellen liegen jeder Linux-Distribution bei. Jede berücksichtigt länderspezifische Details und den Typ der Tastatur. Eine solche Tabelle wird mit dem Kommando loadkeys geladen; die Distributionen haben den Aufruf in einen ihrer Startup-Skripte eingebaut:

Dem Administrator ist es gestattet, im laufenden Betrieb eine alternative Tastaturbelegung zu wählen. Mögliche Tabellen finden sich meist unterhalb des Verzeichnisses "/usr/share/kbd/keymaps/i386/". Das dortige Unterverzeichnis qwerty beherbergt Tastaturen mit amerikanischem Layout; unter qwertz steht u.a. die deutsche Belegung.

Tipp: Wenn Sie mit den Verzeichnisnamen nichts anfangen können, dann betrachten Sie einmal die ersten sechs Tasten der oberen Buchstabenreihe Ihrer Tastatur. Alles klar?

Zurück zum Laden der Tastaturbelegung:

Obige Kommandozeile lädt die deutsche Tastaturtabelle mit "verborgenen toten Tasten" (no dead keys).

Mit loadkeys -d lässt sich ebenso eine default-Belegung laden; diese steht in einer Datei defkeymap.map, welche zunächst in "/usr/share/kbd/keymaps" gesucht wird und nur, wenn sie dort nicht gefunden wurde, in "/usr/src/linux/drivers/char".

Eine eigene Tastaturtabelle

Bei den Dateien, die die Belegungen enthalten, handelt es sich um gepackte (gzip) Textdateien. Sie können somit mit jedem Editor erstellt werden. Weniger aufwändig ist wohl die Bearbeitung einer Kopie einer existierenden Datei. Alternativ erzeugt dumpkeys ein Abbild der aktuellen Kernelbindungen, das als Ausgangsbasis für eine eigene Konfiguration dienen kann.

Der Inhalt der Datei "MyKeyMap" hängt von der aktuell vom Kernel verwendeten Tastaturtabelle ab. Wenden wir uns den möglichen Einträgen einer Beschreibungsdatei für die Tastaturbelegung zu (siehe auch "man keymaps"):

Die Beschreibung des Aufbaus der Tastaturtabelle sollte Ihnen nur einen Einblick verschaffen, wie die Struktur zu verstehen ist. Was man tatsächlich damit anfangen kann, soll anhand eines Beispiels demonstriert werden.

Ein Pinguin schaut aus dem Fenster

Es ist durchaus mit Aufwand verbunden, in deutschem Lande eine Tastatur aufzutreiben, die nicht durch Windowstasten gekennzeichnet ist. Keine Linux-Tastaturtabelle jedoch verwendet von Haus aus diese Tasten. Und dennoch lässt sich ihnen mit ein wenig Handarbeit ein Sinn auferlegen.

Zur Demonstration soll bei Betätigung der linken Windowstaste die aktuelle Uhrzeit angezeigt werden. Die rechte Windowstaste wird das Löschen des Bildschirms ermöglichen. Um allgemein zu bleiben, beschreiten wir alle Etappen der Konfiguration.

Zunächst benötigen wir die Kenntnis, welche Keycodes die beiden Tasten denn überhaupt erzeugen. showkey heißt das entsprechende Kommando:

Die Keycodes der beiden Tasten sind 125 (linke Windowstaste) und 126 (rechte Taste). Eine Überprüfung, dass die beiden Tasten nicht doch schon belegt sind, kann nicht schaden:

Die nächsten Schritte erfordern Rootrechte, denn die Tastaturtabelle ist zu bearbeiten (hier sollten Sie fest stellen, welche Datei bei Systemstart in Ihrer Distribution verwendet wird; am Anfang dieses Abschnitts finden Sie einige Hinweise). Wir arbeiten zunächst auf einer Kopie und ersetzen das Original erst nach Vollendung. Hierzu kopieren wir die Datei mit der Tastaturtabelle:

Die beiden Tasten (mit den Keycodes 125 und 126) müssen nachfolgend mit einer Funktion verbunden werden. Der Kernel unterstützt bis zu 246 solcher Funktionen, die mit F1 bis F246 bezeichnet werden. Schauen Sie nach, dass die von Ihnen zugewiesenen Werte nicht andersweitig verwendet werden (grep in der Ausgabe von dumpkeys). Wir benutzen nachfolgend F245 und F246 (die in keiner Standardtabelle Verwendung finden sollten):

Ebenso in der Datei der Tastaturtabelle muss die Belegung der Funktionen (F245,F246) erfolgen. Einleitend mit dem Schlüsselwort string definieren wir die Zeichenkette, die bei Aufruf der Funktion generiert werden soll:

"\n" ist der Zeilentrenner und simuliert quasi das [Enter] beim Abschluss einer Kommandozeile.

Nach dem Speichern der Änderungen muss die Datei wieder komprimiert werden. Anschließend lädt Root die geänderte Tastataturbelegung:

Wenn Sie jetzt die beiden Windowstasten in der Konsole (!) verwenden, sollten die Zeitanzeige bzw. das Löschen des Bildschirm erfolgen. Beachten Sie, dass X und auch einige Anwendungen eigene Tastaturbelegungen verwenden und die neue Funktionalität in diesen nicht verfügbar sein muss. Entspricht die neue Konfiguration Ihren Wünschen, sollten Sie die ursprüngliche Tastaturbelegung mit dieser überschreiben:

Das obige Szenario sollte Sie befähigen, die Tastatur nach eigenen Vorstellungen anzupassen. Natürlich lassen sich bspw. die Windowstasten in Verbindung mit [Ctrl] und/oder [Alt] koppeln, sodass weitere nützliche Kommandozeilen auf Tastendruck verfügbar werden. Ein gänzlich anderes Konzept mit ähnlicher Wirkung wird Ihnen bei der Beschreibung der Bash (bind) begegnen.

Tipps für Schnelltipper

Es soll Individuen geben, die schneller tippen, als es der Theroetiker für machbar erachtet. Dann kann es schon einmal geschehen, dass zwei flinke Anschläge auf ein und dieselbe Taste als ein einziger Druck interpretiert werden. Für solch bewanderte Chefsekretärsanwärter sollte die Verzögerungszeit zwischen zwei Tastenbetätigungen verringert werden. Mit kbdrate ist der Systemverwalter zu solch einer Maßnahme bemächtigt.

Als zweiten Parameter vermag das Kommando die Zeitspanne zu setzen, nach der eine dauergedrückte Taste einen wiederholten Tastencode aussenden wird, d.h. Sie können steuern, ob - falls Sie wegen Ermüdung ihr Haupt auf die Tastatur betteten - in den vergehenden 10 Minuten 120 Zeichen auf den Bildschirm wandern oder derer gar 18000. Aber zum Glück schlafen Sie ja nicht ein - Sie lesen ja die Linuxfibel.

Für die so genannte delay time und repeat rate wurden architekturabhängige Defaultwerte fest gelegt. Auf Intel stehen die Werte bei 250 Millisekunden (delay time) und 10.9 Zeichen pro Sekunde (repeat rate). Dieser Werte erinnert sich das Kommando, wenn es mit der Option -s aufgerufen wird.

Mit der Option -s Zeit können Sie die delay time anpassen, wobei als "Zeit" auf Intel die Werte 250, 500, 750 und 1000 zulässig sind.

-r Rate stellt ein, wie viele Anschläge maximal in der Sekunde akzeptiert werden. Für Intel-Maschinen sind die Werte 2.0, 2.1, 2.3, 2.5, 2.7, 3.0, 3.3, 3.7, 4.0, 4.3, 4.6, 5.0, 5.5, 6.0, 6.7, 7.5, 8.0, 8.6, 9.2, 10.0, 10.9, 12.0, 13.3, 15.0, 16.0, 17.1, 18.5, 20.0, 21.8, 24.0, 26.7 und 30.0 einstellbar.

USB

Jahrelang schienen serielle und parallele Schnittstellen der Standardanschluss für die Ewigkeit zu sein, bis mit PS/2 die auf Tastatur und Maus spezialisierten Adapter ihnen einen Teil ihrer Aufgaben abspenstig machten.

Doch erst der Universal Serial Bus schickt sich an, serieller und paralleler Schnittstelle ein Stiefmütterchendasein zu bescheren. Dabei schuf man ursprünglich nur eine Möglichkeit, den Anschluss von Telefonen zu vereinheitlichen (vielleicht rührt daher die Anschlussähnlichkeit zum Telefonkabel?); doch heute gibt es kaum mehr ein Gerät, das nicht auch als USB-Variante lieferbar ist.

Bez. der Konfiguration der USB-Hardware unterscheidet sie sich von traditionellen Geräten oft einzig im verwendeten Treiber. Der Abschnitt beschäftigt sich somit mit dem Aktivieren der Gerätedateien; die weiteren Schritte, um das Gerät komfortabel bedienen zu können, verlaufen analog zu den in den obigen Abschnitten besprochenen Maßnahmen.

Moderne Computer verfügen von Haus über 1-4 USB-Ports, ältere Rechner lassen sich per PCI-Karten mit integriertem USB-Kontroller nachrüsten. An einen Port kann direkt ein USB-Gerät angeschlossen werden. Mittels USB-Hubs lässt sich eine Art "Verteilerdose" anstecken. Da die Nummerierung von USB-Devices mit 8 Bit erfolgt, sind maximal 128 Geräten (inklusive Hubs) an einen Port anschließbar.

Standardmäßig ist USB-Unterstützung erst ab Kernelversion 2.2.18 verfügbar (für ältere Kernel existieren Patches). Neben dem allgemeinen USB-Support muss noch eine Motherboard-spezifische Option aktiviert werden. Für Opti-Chips (Ali, SiS...) ist dies OHCI support. In allen anderen Fällen kann UHCI support oder UHCI Alternate Driver support verwendet werden.

Das Einbinden der Option Preliminary USB device filesystem wird dringend empfohlen, da nur so bei einer fehlerhaften Kernelkonfiguration die Ursache auffindbar und behebbar ist.

Die Treiber für die USB-Geräte werden in Klassen eingeteilt. Sie müssen demzufolge ebenso die jeweiligen Klassentreiber für Ihre Geräte (als Modul) realisieren. Eingabegeräte (Tastatur, Maus, Joystick...) verbergen sich hinter Human Interface Devices (HID). Hubs werden intern behandelt und benötigen keinerlei spezifische Kernelfähigkeiten.

Nach Übersetzung und Installation des neuen Kernels muss zunächst das USB-Dateisystem gemountet werden. Günstig ist dessen Aufnahme in die Datei /etc/fstab, um in Zukunft das Mounten unmittelbar nach dem Booten zu erzwingen:

Achtung: Verschiedene Distributionen haben einen solchen Mountaufruf eventuell bereits in eines ihrer Bootskripte integriert (RedHat 7.0 bspw. in /etc/rc.sysinit).

Dieser Abschnitt wird bearbeitet...