Linux. Wegweiser für Netzwerker

Linux - Wegweiser für Netzwerker Olaf Kirch and Terry Dawson 2. Auflage Juni 2001 ISBN 3-89721-135-1 848 Seiten, DM 74,-

Inhaltsverzeichnis Einleitung Informationsquellen Dateisystem-Standards Linux Standard Base Über dieses Buch Die offizielle gedruckte Version Übersicht Typografische Konventionen Änderungen mitteilen Danksagungen Kapitel 1 Einführung in das Arbeiten mit Netzwerken Historisches TCP/IP-Netzwerke UUCP-Netzwerke Netzwerke unter Linux Wie Sie Ihr System verwalten Kapitel 2

Aspekte der Netzwerkarbeit mit TCP/IP Netzwerkschnittstellen IP-Adressen Auflösung von IP-Adressen IP-Routing Das Internet Control Message Protocol Auflösung von Hostnamen Kapitel 3 Konfiguration der Netzwerkhardware Kernel-Konfiguration Ein Überblick über die Netzwerkgeräte Ethernet-Installation Der PLIP-Treiber Die SLIP- und PPP-Treiber Andere Netzwerktypen Kapitel 4 Konfiguration der seriellen Hardware Software für Modemverbindungen Einführung in serielle Geräte Auf serielle Geräte zugreifen Serielle Hardware Hilfsmittel zur Konfiguration Serielle Geräte und die Eingabeaufforderung login: Kapitel 5 TCP/IP-Konfiguration Einrichten des /proc-Dateisystems Installation der Programme Setzen des Hostnamens IP-Adressen zuweisen Einrichten von Subnetzen Erzeugen von Host- und Netzwerkdateien Schnittstellenkonfiguration für IP Alles über ifconfig Der Befehl netstat

Die ARP-Tabelle Kapitel 6 Name-Server- und Resolver-Konfiguration Die Resolver-Bibliothek Wie DNS funktioniert Der Einsatz von named Kapitel 7 Serial Line IP Allgemeine Anforderungen SLIP-Betrieb Handhabung privater IP-Netzwerke Verwendung von dip Der Servermodus Kapitel 8 Das Point-to-Point-Protokoll PPP auf Linux Arbeiten mit pppd Arbeiten mit Optionsdateien Anwählen mit Chat IP-Konfigurationsoptionen Link-Kontrolloptionen Allgemeine Sicherheitsaspekte Authentifizierung mit PPP Debuggen Ihres PPP-Setups Erweiterte PPP-Konfigurationen Kapitel 9 TCP/IP-Firewall Angriffsmethoden Was ist eine Firewall? Was ist IP-Filterung? Linux für Firewalling vorbereiten Die drei Wege der Filterung Die ursprüngliche IP-Firewall (2.0er Kernel)

IP Firewall Chains (2.2-Kernel) Netfilter und IP tables (2.4-Kernel) TOS-Bit-Manipulation Testen einer Firewall-Konfiguration Beispiel einer Firewall-Konfiguration Kapitel 10 IP-Accounting Kernel für IP-Accounting konfigurieren IP-Accounting konfigurieren IP-Accounting-Resultate Zähler zurücksetzen Verwerfen des Regelsatzes Passive Sammlung von Accounting-Daten Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen Nebeneffekte und zusätzliche Vorteile Konfiguration des Kernels für IP-Masquerade Konfiguration von IP-Masquerade Name-Server-Lookups verarbeiten Mehr über Netzwerk-Adressenumsetzung Kapitel 12 Wichtige Netzwerk-Features Der Super-Server inetd Die tcpd-Zugriffs-Kontrolleinrichtung Die Dateien services und protocols Aufruf entfernter Prozeduren (Remote Procedure Call) Konfiguration von Remote-Logins und Ausführen von Befehlen Kapitel 13 Das Network Information System Mit NIS vertraut werden NIS verglichen mit NIS+ Die Client-Seite von NIS Betrieb eines NIS-Servers

Sicherheit von NIS-Servern Mit GNU libc einen NIS-Client einrichten Die Wahl der richtigen Maps Verwendung von passwd- und group-Maps NIS mit Shadow-Paßwörtern verwenden Kapitel 14 Das Network File System NFS vorbereiten NFS-Volume mounten Die NFS-Dämonen Die exports-Datei Kernel-basierte Unterstützung von NFSv2-Servern Kernel-basierte Unterstützung von NFSv3-Servern Kapitel 15 IPX und das NCP-Dateisystem Die Geschichte von Xerox und Novell IPX und Linux Konfiguration des Kernels für IPX und NCPFS IPX-Schnittstellen konfigurieren IPX-Router konfigurieren Mounten eines Remote-NetWare-Volumes Einige weitere IPX-Tools Drucken in eine NetWare-Druckerwarteschlange Emulation von NetWare-Servern Kapitel 16 Taylor UUCP verwalten UUCP-Transfer und Remote-Befehle UUCP-Konfigurationsdateien Wer darf was bei UUCP — Zugriffsrechte bestimmen Das Einwählen in Ihr System einrichten Low-Level-Protokolle unter UUCP Fehlersuche Logdateien und Debugging Kapitel 17

Elektronische Post Was ist überhaupt eine Mail? Wie wird Mail transportiert? E-Mail-Adressen Wie funktioniert Mail-Routing? Die Konfiguration von elm Kapitel 18 Sendmail Eine Einführung in sendmail sendmail installieren Übersicht der Konfigurationsdateien Die Dateien sendmail.cf und sendmail.mc Datei sendmail.cf erzeugen Rewrite-Regeln interpretieren und schreiben sendmail-Optionen konfigurieren Nützliche sendmail-Konfigurationen Testen Ihrer Konfiguration sendmail-Betrieb Tips und Tricks Kapitel 19 Inbetriebnahme von Exim Betrieb von Exim Wenn Ihre Mail nicht durchkommt Exim kompilieren Mail-Zustellungsarten Verschiedene Konfigurationsoptionen Routing und die Zustellung von Nachrichten Schutz vor Mail Spam UUCP einrichten Kapitel 20 Netnews Die Geschichte von Usenet Und was ist nun das Usenet? Wie behandelt Usenet die News?

Kapitel 21 C News News ausliefern Installation Die Datei sys Die Datei active Stapelverarbeitung von Artikeln (Batching) News und Expiring Weitere Dateien Steuermeldungen C News in einer NFS-Umgebung Verwaltungsaufgaben und -Tools Kapitel 22 NNTP und der NNTPD-Dämon Das NNTP-Protokoll Installation des NNTP-Servers NNTP-Zugriff beschränken NNTP-Autorisierung Interaktion von nntpd und C News Kapitel 23 Internet News Aufbau von INN Newsreader und INN Installation von INN Konfiguration von INN: Grundlegende Einrichtung Die Konfigurationsdateien von INN Betrieb von INN Verwaltung von INN: Der Befehl ctlinnd Kapitel 24 Newsreader-Konfiguration Konfiguration von tin Konfiguration von trn Konfiguration von nn

Anhang A Beispielnetzwerk: Die virtuelle Brauerei Anhang B Nützliche Kabel-Konfigurationen Anhang C Linux – Wegweiser für Netzwerker, Copyright-Hinweise zur zweiten Auflage Anhang D SAGE: Die System Administrators Guild Index

Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag



Suchen

Linux - Wegweiser für Netzwerker

Suche Bücher A-Z Neuerscheinungen

Olaf Kirch & Terry Dawson Deutsche Übersetzung von Ingo Marks 2. Auflage Juni 2001 ISBN 3-89721-135-1 Seiten 520 EUR38.00, SFR64.90 Englischsprachige Ausgabe: Linux Network Administrator's Guide, 2nd Edition

Buchreihen Special Offer Programmbereiche Bioinformatik C/C++ Programmierung Design & Grafik

Titel dem Warenkorb hinzufügen

Java

Warenkorb anzeigen

Linux Macintosh .Net Open Source Oracle Perl Python Sicherheit System- & Netzwerkadministration

Ausführliche Beschreibung Über den Autor Über den Übersetzer Kolophon Bestellinformationen

Die vollständig aktualisierte 2. Auflage dieser umfassenden Einführung in die Netzwerkarbeit mit Linux behandelt nun auch Firewalls, Masquerading und Accounting, einschließlich der Nutzung von ipchains und iptables (netfilter). Weitere neue Themen sind INN (News-Administration) und die Unterstützung von Novell (NCP/IPX). Die Informationen über serielle Verbindungen, UUCP, Routing und DNS, Mail und News, SLIP und PPP sowie NFS und NIS wurden gründlich überarbeitet und auf den neuesten Stand gebracht.

Unix Visual Basic

Ergänzende O'Reilly Titel:

Web & Internet Windows XML

Linux in a Nutshell, 3. Auflage Linux - Wegweiser zur Installation & Konfiguration, 3. Auflage Linux Wegweiser für Onliner

Weitere Infos Katalog bestellen Mailinglisten abonnieren Archiv

O'Reilly Home | O'Reilly Partnerbuchhandlungen | Bestellinformationen Kontakt | Über O'Reilly | Datenschutz © 2002, O'Reilly Verlag GmbH & Co.KG [email protected]

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Einleitung Nachdem das Internet ein richtiges Modewort geworden ist, und auch sonst eher ernste Menschen eine Spritztour auf dem Information-Superhighway wagen, scheint die Vernetzung von Computern immer mehr den Status von Fernsehern und Mikrowellenherden anzunehmen. Dem Internet wird momentan eine ungewohnt hohe Aufmerksamkeit der Medien zuteil, und Soziologiestudenten fallen über Usenet-News-Gruppen, Virtual-Reality-Umgebungen und das ganze Web her, um Forschungen über die neue “Internet-Kultur” anzustellen. Natürlich gibt es Computernetze schon eine ganze Weile. Der Zusammenschluß mehrerer Computer zu einem lokalen Netzwerk ist selbst bei kleinen Installationen gängige Praxis, ebenso wie Verbindungen über längere Strecken mit Hilfe von Modems und Telefonleitungen. Das rapide wachsende Konglomerat weltweiter Netzwerke hat dazu geführt, daß der Einstieg in das globale Dorf auch für kleinere gemeinnützige Organisationen und Privatpersonen realisierbar ist. Die Einrichtung eines Internet-Host mit Mail und News, der Zugriff über Wählleitungen und ISDN bietet, ist bezahlbar geworden, und mit der Einführung von DSL (Digital Subscriber Line) und Kabelmodems wird sich dieser Trend zweifelsohne noch beschleunigen. Über Computernetzwerke zu sprechen, bedeutet häufig, über UNIX zu sprechen. Natürlich ist UNIX weder das einzige Betriebssystem mit Netzwerkfähigkeiten, noch wird es für ewig seine Vorreiterstellung behalten. Allerdings ist es schon seit einiger Zeit im Netzwerkgeschäft vertreten,

und es sieht so aus, als würde das auch noch einige Zeit so bleiben. Was UNIX für den privaten Benutzer so attraktiv macht ist die Tatsache, daß es zahlreiche Bemühungen gibt, freie (nahezu kostenlose) UNIX-kompatible Betriebssysteme für PCs anzubieten. Beispiele hierfür sind 386BSD, FreeBSD – und natürlich Linux. Linux ist ein frei verfügbarer UNIX-Klon für Personal Computer, der frei verteilt werden kann. Momentan läuft es auf vielen Maschinen mit Intel-Prozessoren, aber auch auf anderen Architekturen wie Motorola 680x0 (wie Commodore Amiga und Apple Macintosh), Sun SPARC und Ultra-SPARC, Compaq Alphas, MIPS, PowerPCs (die neue Generation der Apple Macintosh-Rechner), StrongARM (z.B. Netwinder von rebel.com) und 3Com Palm. Linux wurde auch auf einige relativ obskure Plattformen portiert, wie z.B. Fujitsu AP-1000 und IBM System 3/90. Portierungen auf weitere interessante Architekturen befinden sich gerade in der Entwicklung, und der aktuelle Trend von Linux in Richtung Embedded-Controller-Systeme erscheint vielversprechend. Linux wurde von einer großen Anzahl Freiwilliger über das Internet entwickelt. Das Projekt wurde 1990 von Linus Torvalds begonnen, einem finnischen Studenten, der im Rahmen einer Vorlesung über Betriebssysteme damit anfing. Seit dieser Zeit ist Linux zu einem voll ausgestatteten UNIX-Klon herangewachsen, auf dem so verschiedene Anwendungen wie Simulations- und Modellierungssoftware, Textverarbeitungen, Sprach-erkennungssysteme, WWW-Browser und eine ganze Reihe anderer Anwendungen laufen, wozu auch exzellente Spiele gehören. Ein weites Spektrum an Hardware wird unterstützt, und Linux enthält eine vollständige Implementierung von TCP/IP, einschließlich SLIP, PPP, Firewalls und IPX, dazu noch eine Menge anderer Features und Netzwerk-Protokolle, die man in keinem anderen Betriebssystem findet. Linux ist mächtig, schnell und frei verfügbar, und seine Popularität nimmt auch außerhalb der Internet-Gemeinde rapide zu. Das Linux-Betriebssystem selbst wird nach den Bestimmungen der “GNU General Public License” geschützt. Das ist dieselbe Copyright-Lizenz, wie sie für Software benutzt wird, die von der Free Software Foundation entwickelt wurde. Diese Lizenz erlaubt es jedem, die Software (kostenlos oder gegen eine Entlohnung) weiterzugeben und zu modifizieren, solange alle Modifikationen und Distributionen ebenfalls frei verteilt werden dürfen. Der Begriff “freie Software” steht hier für Freiheit, nicht nur für den Preis.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Informationsquellen Wenn Sie ein Neuling in der Linux-Welt sind, gibt es eine ganze Reihe von Ressourcen, die Sie sich ansehen sollten. Ein Internet-Anschluß ist zwar hilfreich, aber nicht unbedingt notwendig. Handbücher des Linux-Dokumentationsprojekts Das Linux-Dokumentationsprojekt (“Linux Documentation Project”, oder kurz LDP) ist eine Gruppe Freiwilliger, die eine Reihe von Handbüchern und Dokumenten zu Linux produzieren. Die Themen reichen dabei von der Installation bis hin zur Kernel-Programmierung. Folgende Handbücher sind vorhanden und können z.B. unter http://www.unituebingen.de/zdv/zriinfo/linux/books/books.html heruntergeladen werden: Linux Installation and Getting Started von Matt Welsh. Das Buch beschreibt, wo Sie die Linux-Software bekommen und wie Sie sie installieren und benutzen können. Enthalten sind auch eine Einführung zu UNIX sowie Informationen zur Systemadministration, dem X-Window-System und zur Vernetzung. Linux System Administrators Guide

von Lars Wirzenius und Joanna Oja. Dieses Buch enthält eine Einführung in die allgemeine Linux-Systemadministration und behandelt Themen wie die Erzeugung und Konfiguration von Benutzerkonten, die Durchführung von Systemdaten-Sicherungen, die Konfiguration größerer Softwarepakete sowie die Installation und Aktualisierung von Programmen. Linux System Adminstration Made Easy von Steve Frampton. Dieses Buch geht auf die alltäglichen Administrations- und Verwaltungsfragen ein, die den normalen Linux-Anwender beschäftigen. Linux Programmers Guide von B. Scott Burkett, Sven Goldt, John D. Harper, Sven van der Meer und Matt Welsh. Dieses Buch behandelt Themenbereiche, die insbesondere für alle interessant sind, die Anwendungsprogramme für Linux entwickeln wollen. The Linux Kernel von David A. Rusling. Dieses Buch enthält eine Einführung in den Linux-Kernel, wie es aufgebaut ist und wie es arbeitet. Machen Sie eine Reise durch Ihren Linux-Kernel. The Linux Kernel Module Programming Guide von Ori Pomerantz. Diese Anleitung erklärt, wie man Kernel-Module schreibt. Weitere Handbücher werden gerade entwickelt. Für weitere Informationen zum LDP können Sie sich mit Ihrem Web-Browser in http://www.linuxdoc.org/ oder einem der vielen Spiegel-Sites ansehen. Deutsche Linuxliteratur finden Sie unter anderem unter http://www.64-bit.de. HOWTO-Dokumente Die Linux-HOWTOs sind eine Reihe von Dokumenten, die sich mit verschiedenen Aspekten des Systems beschäftigen, beispielsweise mit der Installation und Konfiguration des X-WindowSystems oder wie man Assemblerprogramme in Linux schreibt. Im allgemeinen sind sie im HOWTO-Unterverzeichnis der nachfolgend aufgeführten FTP-Sites oder im World Wide Web auf einer der vielen Spiegel-Sites des Linux Documentation Projects zu finden. Im Literaturverzeichnis am Ende dieses Buches oder in der Datei HOWTO-INDEX finden Sie einen Überblick der vorhandenen HOWTOs. Einige der HOWTOs wurden mittlerweile auch ins Deutsche übersetzt und sind online erhältlich, z.B. unter http://www.fokus.gmd.de/linux/ -german/linux-doc-howto-aktuell.html. Sie können sich das Installation HOWTO besorgen, das beschreibt, wie Sie Linux auf Ihrem System installieren können. Das Hardware Compatibility HOWTO enthält eine Liste aller

Hardware-Komponenten, mit denen Linux arbeitet, und das Distribution HOWTO enthält eine Liste mit Software-Anbietern, die Linux auf Diskette oder CD-ROM verkaufen. Linux Frequently Asked Questions Die Linux Frequently Asked Questions (FAQ) enthält eine große Sammlung von Fragen zum System sowie die dazugehörigen Antworten. Dieses Dokument ist Pflichtlektüre für alle Einsteiger. Auch die FAQs gibt es zum Teil auf deutsch, z.B. unter http://www.linux-doku.de

Linux-Dokumentation über FTP Wenn Sie Zugriff über “anonymous FTP” haben, können Sie die gesamte Linux-Dokumentation über verschiedene Sites herunterladen, darunter metalab.unc.edu:/pub/Linux/docs und tsx11.mit.edu:/pub/linux/docs. Diese Sites werden von einer Reihe von Sites auf der ganzen Welt gespiegelt.

Linux-Dokumentation über WWW Viele Linux-basierte WWW-Sites sind vorhanden. Die Heimat-Site des Linux Documentation Project ist http://www.linuxdoc.org. Deutsche Seiten sind z.B. http://www. -linux.de, http://www.linux-ag.de, http://www.linuxinfo.de und http://www.heise.de/ix/linux/docs. Die Open Source Writers Guild (OSWG) ist ein Projekt, dessen Umfang über Linux hinausgeht. Die OSWG hat sich (wie dieses Buch auch) der Aufgabe verschrieben, die Werbung und Durchführung der Produktion von OpenSource-Dokumenten zu vereinfachen. Die Homesite der OSWG ist http://www.oswg.org:8080/oswg. Beide Sites enthalten Hypertext-Versionen vieler Linux-HOWTOs und anderer Dokumente.

Kommerziell erhältliche Dokumentation Eine Reihe von Verlagen und Software-Anbietern vertreiben Linux-Software und die entsprechende Dokumentation im Versand. Zwei dieser Anbieter sind: Specialized Systems Consultants, Inc. (SSC) http://www.ssc.com/ P.O. Box 55549 Seattle, WA 981550549 1-206-782-7733 1-206-782-7191 (FAX) [email protected] und: Linux Systems Labs http://www.lsl.com/ 18300 Tara Drive Clinton Township, MI 48036 1-810-9878807 1-810-987-3562 (FAX) [email protected]

Beide Unternehmen bieten Linux-HOWTO-Dokumente und andere Linux-Dokumente in gedruckter und gebundener Form an. O'Reilly & Associates veröffentlicht eine ganze Serie von Linux-Büchern. Das vorliegende Buch entstammt dem Linux Documentation Projects, aber die meisten anderen Bücher wurden von unabhängigen Autoren geschrieben. Ein Auszug: Linux – Wegweiser zur Installation und Konfiguration Ein Installations- und Benutzer-Handbuch für das Linux-System, das Ihnen zeigt, wie Sie das meiste aus Ihrem Linux-System herausholen. Learning Debian GNU/Linux Learning Red Hat Linux Diese Bücher sind etwas grundlegender als Running Linux und enthalten populäre LinuxDistributionen auf CD-ROM sowie Anleitungen zu deren Installation und Gebrauch. Linux in a Nutshell Ein weiteres Buch der erfolgreichen “in a Nutshell”-Serie — ein umfangreiches Nachshlagewerk für Linux.

Linux-Zeitschriften Linux Magazin (http://www.linux-magazin.de) und Linux User (http://www.linux-user.de) sind monatlich erscheinende Magazine für die Linux-Gemeinde. Sie werden von einer Anzahl von LinuxAktivisten geschrieben und veröffentlicht. Die Themen der enthaltenen Artikel reichen von Fragen und Antworten für Einsteiger bis hin zu Interna der Kernel-Programmierung. Selbst wenn Sie Zugriff auf das Usenet haben, sind diese Magazine eine gute Möglichkeit, mit der Linux-Gemeinde in Kontakt zu bleiben. Weitere deutschsprachige Zeitschriften sind Linux Enterprise (http://www.linuxenterprise.de) und Linux computing. Wichtige englischsprachige Zeitschriften sind Linux Journal und Linux Magazine. Linux Journal ist das älteste Magazin und wird von SSC, Inc. herausgegeben. Sie finden es auch im World Wide Web bei http://www.linuxjournal.com/. Linux Magazine ist eine neuere, unabhängige Publikation. Die Homepage des Magazin ist http://www. linuxmagazine.com/.

Linux Usenet Newsgroups Wenn Sie Zugriff auf Usenet-News haben, stehen Ihnen die folgenden Linux-Newsgroups zur Verfügung: comp.os.linux.announce

Eine moderierte Newsgroup, die Ankündigungen neuer Software, Distributionen, Bug-Reports und Fortschritte in der Linux-Gemeinde enthält. Diese Newsgroup sollte eigentlich jeder lesen, der sich für Linux interessiert. Beiträge können an [email protected] gesandt werden. comp.os.linux.help Allgemeine Fragen und Antworten zur Installation und Anwendung von Linux. comp.os.linux.admin Diskussionen über die Systemadministration von Linux. comp.os.linux.networking Diskussionen über das Netzwerken mit Linux. comp.os.linux.development Diskussionen über die Weiterentwicklung des Linux-Kernels und des Systems an sich. comp.os.linux.misc Ein Sammelbecken für alle Fragen, die nicht in die oben genannten Kategorien passen. Nicht ganz so zahlreich sind die deutschsprachigen Linux-Newsgroups, hier gibt es zum Beispiel de.comp.os.linux und de.comp.os.unix.linux.infos.

Linux Mailing-Listen Es gibt sehr viele spezielle Linux-Mailing-Listen, in denen Sie viele hilfsbereite Menschen finden, die Ihnen gerne Rede und Antwort stehen. Die bekanntesten Mailing-Listen werden von der Rutgers University verwaltet. Sie können diese Listen abonnieren, indem Sie eine Mail wie folgt abschicken: To: [email protected] Subject: anything at all Body:

subscribe listname

Dabei bezeichnet listname die gewünschte Mailing-Liste. Einige Mailing-Listen über Linux-Netzwerke sind: linux-net Diskussionen über das Netzwerken mit Linux. linux-ppp Diskussionen über die PPP-Implementationen von Linux. linux-kernel Diskussionen über die Kernel-Entwicklung von Linux. Eine umfassende Übersicht über Mailing-Listen zu Linux finden Sie unter http://www. 123tk.de.

Online-Unterstützung für Linux Es gibt viele Möglichkeiten, von Freiwilligen aus aller Welt online Hilfe zu erhalten. Sie stellen Ihnen ihr Expertenwissen und ihre Dienste zur Verfügung, um Sie bei Ihren Fragen und Problemen zu unterstützen. Das OpenProjects IRC Network ist ein IRC-Netzwerk, das sich ausschließlich offenen Projekten (Open Projects), wie Open Source und Open Hardware, verschrieben hat. Einige ihrer Kanäle sind nur dafür vorgesehen, Linux-Support-Dienste online zur Verfügung zu stellen. IRC steht für Internet Relay Chat und ist ein Netzwerkdienst, der es Ihnen ermöglicht, im Internet mit anderen Anwendern interaktiv zu kommunzieren. IRC-Netzwerke unterstützen multiple Kanäle, in denen jeweils einzelne Gruppen von Leuten miteinander über irgendwelche Themen diskutieren. Was immer Sie auch in einem Kanal eintippen, wird sofort von den anderen in diesem Kanal gelesen. In einigen aktiven Kanälen des OpenProjects IRC Networks finden Sie sogar Leute, die Sie 24 Stunden am Tag, sieben Tag in der Woche, also rund um die Uhr ansprechen können. Sie sind gerne bereit, Ihnen bei der Lösung beliebiger Linux-Probleme zu helfen, oder auch nur einfach nur so mit Ihnen zu reden. Sie können diesen Dienst nutzen, indem Sie einen IRC-Client wie zum Beispiel irc-II installieren, eine Verbindung zum Server irc.openprojects.org:6667 herstellen und am Kanal #linpeople teilnehmen. Deutschsprachige Kanäle sind z.B. #linux.de oder #linuxger.

Linux User Groups Viele Linux User Groups in der ganzen Welt bieten Anwendern direkten Support an. Viele davon engagieren sich in besonderen Aktivitäten wie Linux-Installations-Partys, Gesprächsrunden und Seminaren, Demonstrations-Nächten und anderen gesellschaftlichen Ereignissen. Linux User Groups

bieten die ideale Möglichkeit, andere Linux-Anwender in Ihrer Gegend kennenzulernen. Es gibt eine Anzahl veröffentlichter Listen von Linux User Groups. Ein umfassendes Verzeichnis mit mehr als 270 deutschen User Groups finden Sie unter http://www.linux.de/groups.

Linux beziehen Es gibt nicht eine einzelne Distribution der Linux-Software, sondern verschiedene, wie beispielsweise Debian, RedHat, Caldera, Corel, SuSE, und Slackware. Jede Distribution enthält alles, was Sie für den Betrieb eines kompletten Linux-Systems brauchen: den Kernel, grundlegende Dienstprogramme, Libraries, Support-Dateien und Anwendungsprogramme. Linux-Distributionen können kostenlos über eine Reihe von Online-Quellen bezogen werden, z.B. aus dem Internet. Jede der größeren Distributionen hat ihre eigene FTP- und Web-Site. Einige dieser Sites sind: Caldera http://www.caldera.com/ ftp://ftp.caldera.com/ deutsche Website: http://www.caldera.de Corel http://www.corel.com/ ftp://ftp.corel.com/ deutsche Website: http://www.corel.de Debian http://www.debian.org/ ftp://ftp.debian.org/ deutsche Website: http://www.debian.de Download unter http://www.debian.de/distrib/ftplist

RedHat http://www.redhat.com/ftp://ftp.redhat.com/ deutsche Website: http://www.redhat.de Slackware http://www.slackware.com/ftp://ftp.slackware.com/ oder gespiegelt z.B. unter ftp.fu-berlin.de/mirror/linux-slackware.html SuSE http://www.suse.com/ ftp://ftp.suse.com/ deutsche Website: http://www.suse.de Download unter http://www.suse.de/de/support/download/ftp/inland.html Viele populäre allgemeine FTP-Archiv-Sites spiegeln auch verschiedene Linux-Distributionen. Die bekanntesten Sites sind: metalab.unc.edu:/pub/Linux/distributions/ ftp.funet.fi:/pub/Linux/mirrors/ tsx11.mit.edu:/pub/linux/distributions/ mirror.aarnet.edu.au:/pub/linux/distributions/ Viele der modernen Distributionen können direkt aus dem Internet heraus installiert werden. Es existiert zwar eine Menge Software, die Sie für eine typische Installation herunterladen können, allerdings werden Sie diese Möglichkeit wohl nur wahrnehmen wollen, wenn Sie über eine permanente Hochgeschwindigkeits-Verbindung verfügen, oder wenn Sie nur ein Update einer bestehenden Installation durchführen wollen.1 Immer mehr Software-Händler nehmen Linux in ihr Angebot auf und verkaufen Linux-Distributionen auf CD-ROM. Wenn Ihr lokaler Computer-Händler immer noch kein Linux anbietet, sollten Sie vielleicht mal nachfragen, ob er es in sein Angebot aufnehmen könnte. Einige Händler verkaufen auch

Produkte, denen CD-ROMs mit verschiedenen Linux-Distributionen beiliegen. Das ist eine ideale Möglichkeit, verschiedene Distributionen erst einmal auszuprobieren, bevor Sie sich für eine bestimmte entscheiden.

1.

… oder Sie sind äußerst ungeduldig und der Meinung, daß die 24 Stunden Downloadzeit immer noch kürzer sind als die 72 Stunden, die Sie eventuell auf eine bestellte CD-ROM warten müßten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Dateisystem-Standards Ein großes Problem, das in der Vergangenheit Linux-Distributionen und separate Software-Pakete gleichermaßen betraf, war, daß es kein einheitlich akzeptiertes Layout des Dateisystems gab. Dies führte zu Inkompatibilitäten zwischen verschiedenen Paketen und konfrontierte Benutzer und Administratoren mit dem Problem, verschiedene Dateien und Programme finden zu müssen. Um diese Situation zu verbessern, bildeten im August 1993 verschiedene Leute die “Linux File System Standard Group”, oder kurz FSSTND-Gruppe. Nach sechsmonatiger Diskussion präsentierte die Gruppe einen Entwurf, der eine in sich schlüssige Struktur des Dateisystems darstellt und die Pfadnamen für die grundlegendsten Programme und Konfigurations-Dateien festlegt. Scheinbar ist dieser Standard bereits von den meisten der wichtigen Linux-Distributionen und -Pakete übernommen worden. Leider halten sich aber nur wenige davon vollständig an den FSSTND. In diesem Buch gehen wir davon aus, daß alle besprochenen Dateien sich an den Stellen befinden, die vom Standard vorgegeben werden. Nur wenn eine lange Tradition existiert, die im Widerspruch zu dieser Spezifikation steht, werden Alternativen erwähnt. Der Linux FSSTND wurde zwar weiterentwickelt, jedoch 1997 vom Linux File Hierarchy Standard (FHS) abgelöst. Das FHS geht auf die wichtigen Multi-Architektur-Aspekte ein, die der FSSTND nicht behandelt. Er kann vom Linux Documentationsverzeichnis in http://www.pathname.com/fhs/

bezogen werden. Daniel Quinlan, der Koordinator der FHS-Gruppe, ist unter [email protected] zu erreichen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Linux Standard Base Der größte Teil der verschiedenen Linux-Distributionen hat sich für die Linux-Anwender zweifellos als sehr nützlich erwiesen, dennoch bereitet gerade diese Vielfalt den Software-Entwicklern (bei sonders den Entwicklern freier Software) Kopfschmerzen. Zwar enthält jede Distribution bestimmte Libraries, Konfigurationstools, Systemprogramme und Konfigurationsdateien. Jedoch machen es die Unterschiede in ihren Versionen, Namen und Dateiverzeichnisses sehr schwierig, genau zu bestimmen, wo was in welcher Distribution vorhanden ist. Das erschwert den Vertrieb direkt ausführbarer Binär-Programme, die auf allen LinuxDistributionen stabil laufen sollen. Um dieses Problem aus der Welt zu schaffen, wurde ein neues Projekt gegründet, genannt die “Linux Standard Base” (LSB). Es hat das Ziel, eine standardisierte Basis-Distribution zu beschreiben, an die sich alle Distributionen halten sollen, die mit ihr konform sein wollen. Wenn dann ein Entwickler eine Applikation entwirft, die zur LSB kompatibel ist, wird sie sowohl auf der LSB als auch auf allen anderen mit der LSB konformen Distribution funktionieren. Informationen über den aktuellen Entwicklungsstand der Linux Standard Base finden Sie auf der LSB Homepage http://www.linuxbase.org/.

Wenn Sie an Interoperabilität interessiert sind, besonders bei Software von kommerziellen Anbietern, sollten Sie sich auf jeden Fall vergewissern, daß Ihre Linux-Distribution sich um eine Teilnahme am Standardisierungsprojekt der LSB bemüht.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Über dieses Buch Als Olaf Kirch im Jahr 1992 dem Linux Documentation Project beitrat, schrieb er zwei kleine Kapitel über UUCP und smail, die er dem System Administrator's Guide beisteuern wollte. Die Entwicklung von TCP/IP steckte noch in den Kinderschuhen, und als die “kleinen Kapitel” zu wachsen begannen, dachte Olaf laut darüber nach, daß es doch schön wäre, ein Netzwerk-Handbuch zu haben. “Großartig!” sagte jeder, “Setz dich dran!” Also setzte er sich dran und schrieb die erste Version des “Netzwerk-Handbuchs”, die er im September 1993 veröffentlichte. Olaf setzte seine Arbeit am Netzwerk-Handbuch zu einer jetzt erheblich erweiterten Auflage fort. Der Original-Artikel von Vince Skahan über das sendmail-Programm wurde in dieser Auflage vollständig ersetzt, da die sendmail-Konfiguration mittlerweile völlig neu gestaltet wurde. Das neue Netzwerk-Handbuch, das Sie gerade lesen, ist eine von Terry Dawson revidierte Auflage, herausgegeben von O'Reilly & Associates.1 Terry war über 20 Jahre lang Amateur Radio Operator und arbeitete über 15 Jahre in der Telekommunikations-Industrie. Er war Co-Autor des NET-FAQOriginals und hat seitdem viele Netzwerk-bezogene HOWTO-Dokumente verfaßt und verwaltet. Terry hat das Network Administrators Guide Project immer mit Begeisterung unterstützt. Er hat diesem Buch auch einige neue Kapitel hinzugefügt, die die neuen Linux Netzwerk-Features beschreiben, die seit der ersten Auflage hinzukommen sind. Außerdem hat eine Menge Änderungen im Text vorgenommen, um das Buch auf den neuesten Stand zu bringen.

Das Kapitel zu exim wurde von Philip Hazel2, einem der führenden Entwickler, geschrieben. Das Buch ist im großen und ganzen so organisiert, daß die von Ihnen durchzuführenden Schritte in der Netzwerk-Konfiguration Ihres Systems nacheinander durchlaufen werden. Es beginnt mit einer Diskussion grundlegender Netzwerk-Konzepte, wobei besonders auf TCP/IP-basierte Netzwerke eingegangen wird. Wir bahnen uns dann langsam unseren Weg von der TCP/IP-Konfiguration auf Geräteebene über Firewall-, Accounting- und Masquerading-Konfiguration bis hin zum Setup gängiger Anwendungen wie rlogin und seiner Freunde, dem “Network File System” (NFS) und dem “Network Information System” (NIS). Dem folgt ein Kapitel darüber, wie Sie Ihre Maschine als UUCP-Knoten einrichten können. Der Rest des Buches widmet sich dann zwei Hauptanwendungen, die über TCP/IP und UUCP laufen: Elektronische Post und News. Ein gesondertes Kapitel widmet sich dem IPX-Protokoll und dem NCP-Dateisystem, da beide in vielen Firmenbereichen benutzt werden, in denen Linux ein neues Zuhause gefunden hat. Der E-Mail-Teil enthält eine detaillierte Einführung in die Aspekte des Nachrichtentrans-ports und Routings sowie der zahllosen Adressierungs-Schemata, mit denen Sie konfrontiert werden könnten. Er beschreibt die Konfiguration und die Verwaltung von exim, einem Nachrichten-Transportsystem, das sich ideal für Anwendungen ohne UUCP eignet. Besprochen wird auch sendmail, das für Leute gedacht ist, die ein komplizierteres Routing mit UUCP verwenden. Der News-Teil gibt einen Überblick darüber, wie Usenet-News funktionieren. Er behandelt INN und C-News, die im Moment am weitesten verbreitete News-Transportsoftware. Besprochen wird auch die Verwendung von NNTP, über das News in lokalen Netzwerken gelesen werden können. Das Buch endet mit einem Kapitel über die Pflege und “Fütterung” der bekanntesten Linux-Newsreader. Natürlich kann ein Buch niemals alle Fragen beantworten, die Sie möglicherweise haben. Haben Sie also etwas Geduld, wenn Sie den Anweisungen dieses Buches folgen und dennoch nicht alles so funktioniert, wie Sie es erwarten. Einige Ihrer Probleme könnten durch dumme Fehler unsererseits entstanden sein (siehe X-087-2-submitchanges später in diesem Vorwort), der Grund kann aber auch darin liegen, daß sich die Netzwerk-Software geändert hat. Daher sollten Sie zuerst einen Blick auf die aufgeführten Informationsquellen werfen. Die Chancen sind groß, daß Sie mit Ihrem Problem nicht alleine dastehen, so daß eine Korrektur oder zumindest eine Möglichkeit, den Fehler zu umgehen, bekannt ist. Wenn Sie die Möglichkeit haben, sollten Sie sich auch immer die aktuellste Kernel- und Netzwerk-Release von einer der Linux-FTP-Sites oder einem BBS in Ihrer Nähe besorgen. Viele Probleme rühren von der Verwendung von Software aus verschiedenen Entwicklungsstadien her, die ein reibungsloses Zusammenspiel verhindern. Schließlich befindet sich Linux ja immer noch “in Arbeit”.

1.

Terry Dawson ist erreichbar unter [email protected].

2.

Philip Hazel ist unter [email protected] erreichbar.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die offizielle gedruckte Version Im Herbst 1993 fragte Andy Oram, der sich so ziemlich von Anfang an in der LDP-Mailingliste tummelte, Olaf Kirch, ob er sein Buch nicht bei O'Reilly & Associates veröffentlichen lassen wollte. Darüber war er sehr erfreut, denn er hatte niemals erwartet, daß sein Buch so erfolgreich wird. Andy und Olaf kamen schließlich überein, daß O'Reilly eine erweiterte offizielle gedruckte Version des Netzwerk-Handbuchs mit ihm herausbringt, während er das eigentliche Copyright behalte, so daß die Quellen dieses Buches frei verteilt werden können. Das bedeutet, daß Sie frei wählen können: Sie können die über das Netz vertriebenen LaTeX-Quellen (bzw. die vorformatierten DVI- oder PostScript-Versionen) herunterladen und ausdrucken, oder Sie können die offizielle gedruckte Version von O'Reilly kaufen. Warum sollten Sie dann aber Geld für etwas ausgeben, was Sie anderswo umsonst bekommen können? Ist Tim O'Reilly von Sinnen, etwas zu veröffentlichen, was jeder andere ausdrucken oder sogar selbst weiterverkaufen darf?1 Oder gibt es einen Unterschied zwischen diesen Versionen? Die Antworten lauten “Es kommt darauf an”, “Nein, sicher nicht” und “Ja und Nein”. O'Reilly & Associates nimmt das Risiko der Veröffentlichung dieses Buches auf sich, aber es scheint sich für den Verlag ausgezahlt zu haben (sie haben uns jedenfalls gebeten, es nochmal zu tun). Dieses Projekt dient als Paradebeispiel dafür, wie die Welt der freien Software mit Unternehmen kooperieren kann, um etwas zu produzieren, was für beide Seiten vorteilhaft ist. Aus unserer Sicht ist der große Dienst,

den O'Reilly der Linux-Gemeinde erweist (neben der Tatsache, daß dieses Buch nun in Ihrem lokalen Buchladen zu finden ist), daß Linux damit geholfen wurde, in der Öffentlichkeit ernstgenommen zu werden als eine mögliche und nützliche Alternative zu kommerziellen UNIX-Betriebssystemen für PCs. Es ist mittlerweile beschämend für einen Buchhändler, wenn er nicht wenigstens ein Regal mit Büchern von O'Reilly gefüllt hat. Warum veröffentlichen sie es? Weil sie es als ihre Art von Buch ansehen. Es ist das, was sie erhoffen würden zu produzieren, wenn sie mit einem normalen Autor darüber verhandeln würden, ein Buch über Linux zu schreiben. Der Inhalt, die Details und der Stil passen einfach gut zu ihren anderen Angeboten. Der Sinn der LDP-Lizenz ist sicherzustellen, daß niemand ausgeschlossen wird. Jeder kann sich eine Kopie dieses Buches ausdrucken, und niemand wird sich daran stören, wenn Sie sich eine dieser Kopien besorgen. Wenn Sie bislang aber keine Chance hatten, sich die O'Reilly-Version anzusehen, sollten Sie sich einmal in einer Buchhandlung oder bei Ihren Freunden umsehen. Wir denken, daß das, was Sie sehen werden, Ihnen gefallen wird und daß Sie sich ein persönliches Exemplar kaufen werden. Wo sind nun die Unterschiede zwischen der gedruckten und der Online-Version? Andy Oram hat große Anstrengungen unternommen, unser erstes Geschwafel in etwas zu verwandeln, was es wert ist, gedruckt zu werden. (Er hat sich auch alle anderen Bücher angesehen, die vom Linux Documentation Project herausgebracht wurden, und versorgte die Linux-Gemeinde, wo er konnte, mit seinem professionellen Rat.) Seit Andy damit begann, das Netzwerk-Handbuch korrekturzulesen und die Kopien zu bearbeiten, die ich ihm schickte, verbesserte es sich zusehends gegenüber dem, was es ursprünglich einmal war, und mit jedem neuen Austausch neuer Entwürfe und dem Feedback wird es immer besser. Die Gelegenheit, die Fähigkeiten eines professionellen Editors nutzen zu können, darf man einfach nicht ungenutzt lassen. In vieler Hinsicht war Andys Beitrag ebenso wichtig wie der des Autors. Das gilt auch für die Co-Editoren, die das Buch in die nun vorliegende Fassung brachten. Alle Änderungen wurden wieder in die Online-Version übernommen, so daß es inhaltlich keine Unterschiede gibt. Dennoch ist die O'Reilly-Version anders. Erstens ist das Buch professionell gebunden, und wenn Sie sich auch die Mühe machten, die Online-Version auszudrucken, würden Sie kaum die gleiche Qualität erreichen und schon gar nicht für denselben günstigen Preis. Die professionellen Grafiker bei O'Reilly haben auf großartige Weise das visualisiert, was wir mit unseren amateurhaften Zeichnungen ursprünglich erreicht zu haben glaubten. Der Index ist besser strukturiert, so daß Sie das Gesuchte im Buch schneller finden. Wenn Sie beabsichtigen, dieses Buch von Anfang bis Ende komplett durchzulesen, sollten Sie sich auf jeden Fall die offizielle gedruckte Ausgabe zulegen.

1.

Denken Sie daran, daß Sie die Online-Version zwar ausdrucken dürfen, aber das O'Reilly-Buch nicht durch den Fotokopierer jagen, geschweige denn diese (hypothetischen) Kopien verkaufen dürfen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Übersicht Das Kapitel 1 Einführung in das Arbeiten mit Netzwerken, diskutiert die Geschichte von Linux und enthält grundlegende Informationen zu UUCP, TCP/IP, verschiedenen Protokollen, Hardware und Sicherheit. Die nächsten Kapitel behandeln die TCP/IP-Konfiguration von Linux sowie die Ausführung einiger wichtiger Hauptanwendungen. IP wird im Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, noch genauer behandelt, bevor wir uns die Hände beim Editieren von Dateien und ähnlichem dreckig machen. Wenn Sie bereits wissen, wie IP-Routing funktioniert und wie die Adreßauflösung durchgeführt wird, können Sie dieses Kapitel überspringen. Das Kapitel 3 Konfiguration der Netzwerkhardware, bespricht die grundlegendsten KonfigurationsAspekte wie die Compilierung des Kernels und das Einrichten Ihrer Ethernet-Karte. Die Konfiguration Ihrer seriellen Schnittstellen wird separat im Kapitel 4 Konfiguration der seriellen Hardware, besprochen, weil sie nicht nur für TCP/IP-Netzwerke, sondern auch für UUCP-Systeme von Bedeutung ist. Das Kapitel 5 TCP/IP-Konfiguration, hilft Ihnen dabei, Ihre Maschine für TCP/IP einzurichten. Es enthält Installations-Hinweise für alleinstehende Hosts, bei denen nur das Loopback aktiviert ist, aber auch für an ein Ethernet angeschlossene Hosts. Es werden auch einige nützliche Tools vorgestellt, mit denen Sie Ihr Setup testen und debuggen können. Das Kapitel 6 Name-Server- und ResolverKonfiguration, diskutiert die Konfiguration der Hostnamen-Auflösung und beschreibt die Einrichtung

eines Name-Servers. Das Kapitel 7 Serial Line IP, erklärt, wie eine SLIP-Verbindung hergestellt wird, und enthält einen ausführlichen Referenzteil zu dip, einem Tool, mit dem Sie den größten Teil der nötigen Schritte automatisieren können. Das Kapitel 8 Das Point-to-Point-Protokoll, behandelt PPP und pppd, den PPPDaemon. Kapitel 9 TCP/IP-Firewall, ergänzt unsere Diskussion über die Sicherheit von Netzwerken und enthält eine Beschreibung des Linux TCP/IP-Firewalls und seiner Konfigurations-Tools ipfwadm, ipchains und iptables. Mit IP Firewalls können Sie sehr genau kontrollieren, wer auf Ihr Netzwerk und Ihre Hosts zugreifen darf und wer nicht. Das Kapitel 10 IP-Accounting, erläutert, wie sie IP Accounting in Linux konfigurieren, damit Sie genau verfolgen können, wieviel Datenverkehr in ihrem Netz vorliegt und von wem er verursacht wird. Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen, behandelt ein Feature der LinuxNetzwerksoftware, das ale IP Masquerade bezeichnet wird. Damit sind ganze IP-Netzwerke unter einer einzigen IP-Adresse erreichbar. Außenstehenden bleibt somit der Einblick in die internen Systeme Ihrer Netzwerke verborgen. Das Kapitel 12 Wichtige Netzwerk-Features, enthält eine kurze Einführung zum Setup einiger der wichtigsten Netzwerk-Anwendungen wie rlogin, ssh etc. Dieses Kapitel beschreibt auch, wie Dienste vom inetd-Superuser verwaltet werden und wie Sie den Zugriff auf bestimmte sicherheitsrelevante Dienste auf eine bestimmte Gruppe von Hosts beschränken können. Die Kapitel 13 Das Network Information System, und Kapitel 14 Das Network File System, diskutieren NIS und NFS. NIS ist ein nützliches Tool zur Verteilung administrativer Informationen, wie beispielsweise den Benutzer-Paßwörtern in einem lokalen Netzwerk. NFS erlaubt die gemeinsame Nutzung von Dateisystemen zwischen verschiedenen Hosts in Ihrem Netzwerk. In Kapitel 15 IPX und das NCP-Dateisystem, reden wir über das IPX-Protokoll und das NCPDateisystem. Damit kann Linux in Novell Netware-Umgebungen integriert werden und gemeinsame Dateien und Drucker mit Nicht-Linux-Maschinen nutzen. Das Kapitel 16 Taylor UUCP verwalten, gibt Ihnen eine ausführliche Einleitung in die Administration von Taylor-UUCP, einer freien Implementierung des UUCP-Pakets. Der Rest des Buches befaßt sich ausführlich mit elektronischer Post und Usenet-News. Das Kapitel 17 Elektronische Post, führt Sie in die zentralen Konzepte elektronischer Post ein. Dazu gehört beispielsweise, wie eine Postadresse aussieht und wie es ein Mail-System geregelt bekommt, Ihre Nachrichten an den Empfänger weiterzuleiten. Die Kapitel 18 Sendmail, und Kapitel 19 Inbetriebnahme von Exim, decken das Setup von sendmail

und exim ab, zwei Mail-Transportsysteme, die Sie in Linux verwenden können. Das Buch behandelt beide Systeme, weil exim für den Anfänger leichter zu installieren ist, wohingegen sendmail UUCPUnterstützung bietet. Die Kapitel 20 Netnews, bis Kapitel 23 Internet News, beschreiben, auf welche Weise News im Usenet verwaltet werden, und wie Sie drei besonders populäre Softwarepakete zur Verwaltung von Usenet-News, nämlich C-News, nntpd und INN installieren und verwenden können. Nach einer kurzen Einführung in Kapitel 20 Netnews, können Sie mit dem Lesen von Kapitel 21 C News, fortfahren, wenn Sie Ihre News mit C News, einem traditionellen UUCP-Dienst, versenden wollen. Die nachfolgenden Kapitel diskutieren mehrere moderne Alternativen zu C News, das mit dem Internetbasierten Protokoll NNTP (Network News Transfer Protocol) arbeitet. Kapitel 22 NNTP und der NNTPD-Dämon, beschreibt, wie Sie einen einfachen NNTP-Daemon, nntpd, einrichten, damit in Ihrem lokalen Netzwerk auf News zugegriffen werden kann. Kapitel 23 Internet News, stellt einen etwas solideren Server vor, den InterNet News daemon (INN), der für umfangreichere NetNewsTransfers eingesetzt wird. Zum Schluß zeigt Ihnen das Kapitel 24 Newsreader-Konfiguration, wie Sie verschiedene Newsreader konfigurieren und verwalten können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Typografische Konventionen Alle in diesem Buch vorgestellten Beispiele gehen davon aus, daß Sie eine zu sh kompatible Shell benutzen. bash ist eine solche sh-kompatible Shell und zugleich Standard in allen Linux-Systemen. Wenn Sie dagegen csh verwenden, müssen Sie bei der Anwendung der Beispiele gegebenenfalls angemessene Änderungen vornehmen. Im vorliegenden Buch werden folgende Auszeichnungen benutzt: Kursivschrift benutzen wir für Datei- und Verzeichnisnamen, für die Namen von Programmen und Befehlen, für Befehlszeilenoptionen, E-Mail-Adressen, Pfadnamen, URLs sowie zur Hervorhebung von neuen Begriffen. Fettschrift wird für die Namen von Rechnern, für die Benutzernamen und -IDs sowie gelegentlich zur Hervorhebung von Text benutzt. Nichtproportionalschrift

wird in Beispielen verwendet, um den Inhalt von Code-Dateien und die Ausgabe von Befehlen anzuzeigen und um im Code enthaltene Umgebungsvariablen und Schlüsselwörtern zu kennzeichnen. Nichtproportionalschrift kursiv kennzeichnet Variablenoptionen, Schlüsselwörter oder Text, die der Anwender mit konkreten Werten ausfüllen muß. Nichtproportionalschrift fett wird in Beispielen benutzt, um Befehle oder sonstige Texte anzuzeigen, die vom Anwender genau in der angegebenen Form eingegeben werden sollten. Achtung Dieses Icon zeigt eine ernste Warnung an. Hier können Ihnen Fehler passieren, die Ihr System massiv schädigen können und die Sie unter Umständen kaum beheben können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Änderungen mitteilen Wir haben die Informationen in diesem Buch nach bestem Wissen getestet und überprüft. Es kann aber sein, daß Sie an manchen Stellen feststellen, daß sich die dort beschriebenen Features schon wieder geändert haben (oder daß wir sogar Fehler gemacht haben!). Bitte informieren Sie uns über jeden Fehler, den Sie finden, und machen Sie uns Vorschlage für zukünftige Ausgaben. Schreiben Sie an: O'Reilly Verlag Balthasarstr. 81 50670 Köln Tel. 0221/973160-0 Für technische Fragen oder Kommentaren zu diesem Buch mailen Sie: [email protected] Wir haben für dieses Buch eine spezielle Website eingerichtet, wo wir Beispiele auflisten werden, auf Druckfehler hinweisen und alle unsere Pläne für zukünftige Ausgaben vorstellen. Sie erreichen die Site zur englischen Originalausgabe unter: http://www.oreilly.com/catalog/linag2 Für weitere Informationen über dieses und andere Bücher verweisen wir Sie auf die Homepage von

O'Reilly: http://www.oreilly.de

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Danksagungen Für die vorliegende Ausgabe des Netzwerk-Handbuches gebührt Olaf Kirch und Terry Dawson in nahezu jeder Ansicht Dank für ihre hervorragende Arbeit. Man kann sich nur schwer vorstellen, wieviel Mühe und Arbeit darin steckt, ein solches Buch zu entwerfen und zu schreiben, wenn man nicht selbst einmal die Gelegenheit dazu hatte. Allein die Aktualisierung der ersten Auflage war schon eine Herausforderung — allerdings eine besonders erfreuliche, da diesmal eine hervorragende Ausgangsbasis zur Verfügung stand. Vieles verdankt dieses Buch auch den zahlreichen Menschen, die sich die Zeit genommen haben, es korrekturzulesen und viele technische und grammatikalische Fehler auszubügeln (nie gewußt, daß es sowas wie hängende Partizipien gibt :-). Phil Hughes, John Macdonald und Erik Ratcliffe gaben sehr hilfreiche (im großen und ganzen sogar ziemlich übereinstimmende) Feedbacks zum Inhalt dieses Buches ab. Wir schulden auch den Leuten bei O'Reilly vielen Dank, mit denen wir das Vergnügen hatten zu arbeiten: Sarah Jane Shangraw, die das Buch in die nun vorliegende Fassung brachte, Maureen Dempsey, die das Buch sprachlich redigierte; Rob Romano, Rhon Porter und Chris Reilley, die sich um die ganzen Abbildungen kümmerten; Hanna Dyer, die das Cover entwarf; Alicia Cech, David Futato und Jennifer Niedherst, die für das Innenlayout zuständig waren; Lars Kaufman, der alte Holzschnitte als visuelles Thema vorschlug, Judy Hoer für ihren Index, und zum Schluß natürlich Tim

O'Reilly für seine Courage, ein solches Projekt durchzuziehen. Zutiefst verpflichtet sind wir auch Andres Sepúlveda, Wolfgang Michaelis, Michael K. Johnson und all den anderen Entwicklern, die ihre knappe Zeit geopfert haben, die im Netzwerk-Handbuch stehenden Informationen zu prüfen. Phil Hughes, John MacDonald und Eric Ratcliffe gaben unschätzbare Kommentare zur zweiten Auflage. Wir möchten auch all jenen danken, die die erste Version dieses Buchtextes gelesen und mir Vorschläge und Korrekturen zugeschickt haben. Eine hoffentlich vollständige Liste aller Beteiligten ist in der Datei Thanks der Online-Distribution zu finden. Letztendlich wäre dieses Buch nicht ohne die Unterstützung von Holger Grothe möglich gewesen, der Olaf mit der kritischen Internet-Connectivity versorgt hat, die die erste Auflage erst möglich machte. Olaf möchte auch den folgenden Gruppen und Unternehmen danken, die die erste Ausgabe seines Buches gedruckt und entweder ihm oder dem Linux Documentation Project als Ganzem Geld gespendet haben: Linux Support Team, Erlangen; S.u.S.E. GmbH, Nürnberg und Linux System Labs, Inc., Clinton Twp., USA. Terry dankt seiner Frau Maggie, die ihn geduldig bei seiner Teilnahme an diesem Projekt unterstützte, trotz der Umstände, die die Geburt ihres ersten Kindes Jack mit sich brachten. Außerdem dankt er den vielen Leuten in der Linux-Gemeinde, die ihn bis zu dem Punkt hin quälten, an dem er in das Projekt einsteigen und aktiv seinen Beitrag leisten konnte. “Ich helfe Dir, wenn Du mir versprichst, daß Du dafür jemand anderem hilfst.”

Die Ruhmeshalle Außer den bereits genannten Leuten, gibt es eine große Anzahl von Leuten, die etwas zum NetzwerkHandbuch beigesteuert haben. Wir sind ihnen sehr dankbar. Nachfolgend eine Liste derer, deren Beiträge eine Spur in unseren Mail-Ordnern hinterließen. Al Longyear, Alan Cox, Andres Sepúlveda, Ben Cooper, Cameron Spitzer, Colin McCormack, D. J. Roberts, Emilio Lopes, Fred N. van Kempen, Gert Doering, Greg Hankins, Heiko Eissfeldt, J. P. Szikora, Johannes Stille, Karl Eichwalder, Les Johnson, Ludger Kunz, Marc van Diest, Michael K. Johnson, Michael Nebel, Michael Wing, Mitch D'Souza, Paul Gortmaker, Peter Brouwer, Peter Eriksson, Phil Hughes, Raul Deluth Miller, Rich Braun, Rick Sladkey, Ronald Aarts, Swen Thüemmler, Terry Dawson, Thomas Quinot und Yury Shevchuk.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 1 Einführung in das Arbeiten mit Netzwerken

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Historisches Die Idee der Vernetzung ist wahrscheinlich so alt wie die Telekommunikation selbst. Denken Sie an die Menschen, die in der Steinzeit gelebt haben, als Trommeln verwendet wurden, um Nachrichten auszutauschen. Stellen Sie sich vor, Höhlenmensch A möchte Höhlenmensch B einladen, sich gegenseitig mit Steinen zu bewerfen. Nun leben die beiden zu weit voneinander entfernt, als daß B hören könnte, was A trommelt. Welche Möglichkeiten hat A nun? Er kann 1. zu B hinübergehen, 2. sich eine größere Trommel besorgen oder 3. C bitten, der auf halber Strecke zwischen A und B wohnt, die Nachricht weiterzuleiten. Die letzte Variante wird Netzwerk genannt. Natürlich haben die Geräte und Hilfsmittel unserer Vorfahren eine lange Entwicklung durchgemacht. Heute unterhalten sich Computer über gigantische Kabelstränge, Lichtwellenleiter, Mikrowellen und ähnliches, damit wir uns für das samstägliche Fußballspiel verabreden können.1 In der folgenden Beschreibung wollen wir uns damit befassen, mit welchen Mitteln und auf welchen Wegen dies erreicht wird. Dabei lassen wir den Teil mit den Kabeln ebenso weg wie den mit dem Fußball. In diesem Buch behandeln wir drei verschiedene Arten von Netzwerken. Der Schwerpunkt liegt dabei eindeutig bei TCP/IP, da es sowohl in den lokalen Netzwerken (Local Area Networks, LANs) als auch in den globalen Netzwerken (Wide Area Networks, WANs) wie etwa dem Internet die Hauptrolle spielt. Außerdem werden wir uns mit UUCP und IPX beschäftigen. UUCP wurde früher häufig verwendet, um News und Mail-Nachrichten über Telefonverbindungen zu übertragen. Es ist

heute nicht mehr so weit verbreitet, aber in manchen Anwendungen immer noch nützlich. Das IPXProtokoll kommt hauptsächlich aus der Novell-NetWare-Welt. Wir befassen uns damit, wie Sie dieses Protokoll dazu benutzen können, Ihren Linux-Rechner an ein Novell-Netz anzuschließen. Alle diese Protokolle haben gemeinsam, daß sie Daten zwischen Hostrechnern übertragen. Wir befassen uns damit, wie sie benutzt werden, und stellen Ihnen die zugrundeliegenden Prinzipien vor. Wir definieren ein Netzwerk als eine Ansammlung von Hosts, die in der Lage sind, miteinander zu kommunizieren. Häufig sind diese Rechner von den Diensten einer Reihe von dedizierten Hosts abhängig, die Daten zwischen den Teilnehmern übertragen. Hosts sind häufig Computer, müssen es aber nicht unbedingt sein. Auch X-Terminals oder intelligente Drucker können Hosts sein. Kleinere Ansammlungen von Hosts werden auch Sites genannt. Kommunikation ist ohne so etwas wie eine Sprache oder einen Code nicht möglich. In Computernetzwerken werden diese »Sprachen« kollektiv als Protokolle bezeichnet. Nun sollten Sie dabei nicht an geschriebene Protokolle denken, sondern vielmehr an eine sehr formalisierte Art des Verhaltens, wie sie beispielsweise bei Staatsempfängen zu beobachten ist. In ähnlicher Weise sind auch die in Computernetzwerken verwendeten Protokolle nichts anderes als sehr strenge Regeln für den Austausch von Nachrichten zwischen zwei oder mehreren Computern.

1.

Dessen ursprünglicher Geist (siehe oben) ist auch heute noch manchmal erkennbar.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

TCP/IP-Netzwerke Modernen Netzwerkanwendungen liegt ein sehr hochentwickeltes und durchdachtes Konzept zugrunde, um Daten von einer Maschine zu einer anderen zu übertragen. Wenn Sie ein Linux-System mit vielen Anwendern verwalten, die gleichzeitig Verbindungen zu entfernten Hosts aufnehmen wollen, müssen Sie dafür sorgen, daß Ihre Netzwerkverbindung so aufgeteilt wird, daß alle Anwender bedient werden können und sich dabei nicht gegenseitig in die Quere kommen. Das Konzept, das von vielen modernen Netzwerkprotokollen genutzt wird, wird als paketorientierte Datenübertragung (packet-switching) bezeichnet. Ein Paket ist ein kleines Datenbündel, das über ein Netzwerk von einer Maschine auf eine andere übertragen wird. Ein paketorientiertes Netzwerk nutzt einzelne Netzwerkleitungen, indem es die zu übertragenden Daten aller Hosts in Pakete zerteilt, sie abwechselnd nacheinander überträgt. Auf diese Weise hat jeder Anwender den Eindruck, er würde sofort bedient und die Netzleitung stünde ihm exklusiv zur Verfügung. Die Lösung, die von UNIX-Systemen — und vielen Nicht-UNIX-Sites — übernommen wurde, ist als TCP/IP bekannt. Wenn es um TCP/IP geht, wird Ihnen der Begriff Datagramm begegnen, der oft als Synonym für Paket verwendet wird, in technischen Zusammenhängen aber eigentlich eine andere Bedeutung hat. In diesem Abschnitt werden wir die zugrundeliegenden Konzepte betrachten.

Einführung in TCP/IP-Netzwerke

Die Wurzeln von TCP/IP liegen in einem Forschungsprojekt, das von der amerikanischen Defense Advanced Research Projects Agency (DARPA) im Jahre 1969 finanziert wurde. Was unter dem Namen ARPANET als experimentelles Netzwerk begann, wurde im Jahre 1975 in den normalen Betrieb übernommen, nachdem es sich als erfolgreich erwiesen hatte. Im Jahre 1983 wurde die neue TCP/IP-Protokoll-Familie als Standard übernommen, und alle Hosts im Netzwerk mußten es von nun an einsetzen. Während ARPANET langsam zum Internet heranwuchs (wobei das ARPANET im Jahre 1990 aufhörte zu existieren), hatte sich TCP/IP schon auf Netzwerken außerhalb des Internet ausgebreitet. Viele Firmen verfügen mittlerweile über Unternehmens-Netzwerke auf der Basis von TCP/IP, und das Internet ist mittlerweile so groß geworden, daß man es durchaus als Main-stream-Verbrauchertechnologie auffassen kann. Man findet kaum noch eine Zeitung oder ein Magazin, in dem nicht irgendein Verweis auf das Internet enthalten ist. Fast jeder kann es heutzutage nutzen. Als konkretes Beispiel zur Erläuterung von TCP/IP in den folgenden Abschnitten führen wir die irgendwo in Fredland ansässige Groucho-Marx-Universität (GMU) ein. Die meisten Institute betreiben ihr eigenes lokales Netzwerk, während andere eines gemeinsam nutzen und wieder andere gleich mehrere betreiben. Alle sind miteinander verbunden und haben über eine gemeinsame Hochgeschwindigkeitsleitung Zugang zum Internet. Stellen Sie sich vor, Ihre Linux-Kiste ist mit einem LAN von UNIX-Hosts im mathematischen Institut verbunden (nennen wir sie einfach mal erdos). Um nun auf einen Host im physikalischen Institut, sagen wir auf quark, zugreifen zu können, müssen Sie den folgenden Befehl eingeben: $ rlogin quark.physics Welcome to the Physics Department at GMU (ttyq2) login:

Wenn die Eingabeaufforderung erscheint, müssen Sie Ihren Login-Namen, z.B. andres, und Ihr Paßwort eingeben. Nach der korrekten Eingabe wird auf quark eine Shell1 gestartet, in der Sie arbeiten können, als würden Sie an der Konsole des Systems sitzen. Sobald Sie die Shell verlassen, erscheint wieder der Prompt Ihrer eigenen Maschine. Sie haben damit gerade eine der grundlegenden, interaktiven Anwendungen verwendet, die TCP/IP zur Verfügung stellt: Remote Login, das Einloggen auf einem entfernten Rechner. Während Sie in quark eingeloggt sind, möchten Sie vielleicht eine X11-basierte Anwendung, beispielsweise eine Textverarbeitung, ein Grafikprogramm oder einen WWW-Browser, ausführen. Das X Window System ist eine vollständig netzwerkorientierte grafische Benutzeroberfläche und für viele verschiedene Computersysteme erhältlich. Um nun der Anwendung mitzuteilen, daß ihre Ausgaben auf dem Bildschirm Ihres Rechners erscheinen sollen, müssen Sie die Umgebungsvariable DISPLAY setzen: $ DISPLAY=erdos.maths:0.0 $ export DISPLAY

Wenn Sie nun die Anwendung starten, erscheinen die Ausgaben nicht mehr auf quark, sondern auf Ihrem Rechner, d.h., die Fenster der Anwendung erscheinen auf dem Bildschirm Ihres Rechners (vorausgesetzt, daß X11 auf erdos läuft). Der entscheidende Punkt ist hier, daß TCP/IP es quark und

erdos erlaubt, X11-Pakete hin und her zu schicken, und Ihnen so vorgaukelt, daß Sie auf einem einzigen System arbeiten. Das Netzwerk ist hier fast transparent. Eine weitere sehr wichtige Anwendung in TCP/IP-Netzwerken ist NFS, was für Network File System steht. NFS ist eine weitere Möglichkeit, Netzwerke transparent zu machen, weil es Ihnen erlaubt, Verzeichnishierarchien von anderen Hosts zu mounten. Diese erscheinen dann auf Ihrem Rechner so, als wären es lokale Dateisysteme. Beispielsweise könnten die Home-Verzeichnisse aller Benutzer auf einer zentralen Maschine gehalten werden, von der aus alle anderen Hosts im LAN die Verzeichnisse mounten können. Das bedeutet, daß sich Benutzer auf jeder beliebigen Maschine einloggen können und sich dennoch immer in ihrem jeweiligen Home-Verzeichnis wiederfinden. Auf die gleiche Weise können Sie Anwendungen, die einen großen Platzbedarf haben (wie Datenbanken, Dokumentationen oder Anwendungsprogramme), auf nur einem Rechner installieren und vielen Hosts Zugriff darauf gestatten. Wir kommen in Kapitel 14 Das Network File System, noch auf NFS zurück. Das sind natürlich nur einige Beispiele für das, was Sie mit TCP/IP-Netzwerken alles machen können. Die Möglichkeiten sind nahezu unbeschränkt. Einige davon werden wir Ihnen im Laufe des Buches vorstellen. Wir werfen nun einen genaueren Blick darauf, wie TCP/IP funktioniert. Diese Informationen helfen Ihnen zu verstehen, wie und warum Sie Ihre Maschine konfigurieren müssen. Wir beginnen mit einer Untersuchung der Hardware und arbeiten uns dann langsam vor.

Ethernet Die in LANs am weitesten verbreitete Hardware wird Ethernet genannt. In ihrer einfachsten Form besteht sie aus einem einzigen Kabel, das zwei Hosts über spezielle Stecker, Taps oder Transceiver miteinander verbindet. Einfache Ethernets sind in der Installation relativ günstig, was — zusammen mit den möglichen Übertragungsraten von 10, 100 oder sogar 1000 Megabit pro Sekunde — sicherlich für ihre große Popularität gesorgt hat. Ethernet gibt es in drei Varianten: Thick, Thin und Zweidraht (“Twisted Pair”). Thin- und ThickEthernet verwenden beide ein Koaxialkabel, das sich aber jeweils in der Dicke und in der Art unterscheidet, wie ein Host an dieses Kabel angeschlossen wird. Thin-Ethernet arbeitet mit einem Tförmigen “BNC”-Steckverbinder, den Sie in das Kabel einfügen und auf einen entsprechenden Stecker auf der Rückseite Ihres Computers aufstecken. Bei Thick-Ethernet müssen Sie ein kleines Loch in das Kabel drillen und einen Transceiver mit Hilfe eines sogenannten “Vampire Taps” einsetzen. Ein oder mehrere Hosts können dann mit diesem Transceiver verbunden werden. Die Kabel für Thin- und Thick-Ethernets dürfen eine maximale Länge von 200 bzw. 500 Metern nicht überschreiten. Es wird daher auch 10Base-2 oder 10Base-5 genannt. Das Wort “Base” bezieht sich auf “Basisband-Modulation” und bedeutet einfach nur, daß die Daten ohne irgendein Modem direkt in das Kabel geleitet werden. Die linke Zahl gibt die Geschwindigkeit in Megabits pro Sekunde an und die rechte Zahl die maximale Länge des Kabels als Vielfaches von Hundert (in Metern). “Twisted Pair” verwendet ein zweiadriges Kupferkabel und üblicherweise zusätzliche Hardware, die als aktiver Hub bekannt ist. Twisted Pair wird auch 10Base-T genannt, wobei das »T« für die verdrillten Kabelpaare steht. Die Version mit 100 MBits pro Sekunde ist allgemein als 100Base-T bekannt.

Auch wenn das Hinzufügen eines weiteren Hosts bei einem Thick-Ethernet eine etwas haarige Angelegenheit ist, bringt es doch das Netzwerk nicht zum Absturz. Fügen Sie einen Host in ein ThinEthernet ein, legen Sie dagegen das Netzwerk zumindest für ein paar Minuten lahm, weil Sie das Kabel durchschneiden müssen, um den Verbinder einzufügen. Twisted-Pair-Netzwerke sind noch einfacher aufgebaut. Als Verbindungsknoten verwenden Sie einen sogenannten “Hub”. Sie können an diesen weitere Hosts anschließen oder angeschlossene Hosts entfernen, ohne andere Benutzer zu stören. fungiert, können Sie bedenkenlos Hosts in einen Hub einfügen oder aus ihm entfernen, ohne die anderen Anwender auch nur im geringsten zu stören. Die meisten Leute ziehen Thin-Ethernet vor, weil es sehr billig ist. Steckkarten für den PC werden für deutlich unter DM 100 angeboten. Der Preis für Kabel liegt bei ein bis zwei Mark pro Meter. Bei größeren Installationen ist Thick-Ethernet oder Twisted Pair die bessere Wahl. Beispielsweise wird am mathematischen Institut der GMU ein Thick-Ethernet verwendet, damit das Netzwerk nicht immer heruntergefahren werden muß, wenn ein neuer Rechner hinzugefügt wird. Mittlerweile werden häufig auch Twisted-Pair-Installationen durchgeführt, in diversen Varianten. Die Hub-Hardware wird immer billiger, und kleine Geräte sind inzwischen auf ein Preisniveau gefallen, das sie auch für kleine häusliche Netzwerke interessant macht. Twisted-Pair-Verkabelung kann vor allem bei großen Installationen enorme Kosten einsparen, und das Kabel selbst ist obendrein noch wesentlich flexibler als das Koaxialkabel, das man in den anderen Ethernet-Systemen verwendet. Die Netzwerkadministratoren des mathematischen Instituts der GMU beabsichtigen, im kommenden Jahr das komplette Netzwerk durch ein Twisted-Pair-Netzwerk zu ersetzen, weil es sie zum einen auf den aktuellen Stand der Technik bringt und zum anderen eine deutliche Zeitersparnis darstellt, wenn es darum geht, neue Hostrechner zu installieren bzw. vorhandene Hosts an andere Standorte zu verlegen. Ein Nachteil der Ethernet-Technologie ist die begrenzte Länge der Kabel, was die Verwendung auf LANs beschränkt. Auf der anderen Seite können Sie aber mehrere Ethernet-Segmente miteinander verbinden, indem Sie sogenannte Repeater, Bridges oder Router verwenden. Repeater kopieren einfach die Signale zwischen zwei oder mehreren Segmenten, was bedeutet, daß alle Segmente zusammenarbeiten, als wäre es ein einzelnes Ethernet. Aufgrund der Timing-Anforderungen dürfen zwischen zwei Hosts im Netzwerk nicht mehr als vier Repeater verwendet werden. Bridges und Router sind da schon etwas aufwendiger. Sie analysieren die eingehenden Daten und leiten sie nur dann weiter, wenn sich der empfangende Host nicht im lokalen Ethernet befindet. Ethernet arbeitet wie ein Bus-System, bei dem ein Host Pakete (oder Frames) mit einer Größe von bis zu 1.500 Byte an einen anderen Host in demselben Ethernet übertragen kann. Ein Host wird dabei über eine sechs Byte lange Adresse angesprochen, die in die Firmware der Ethernet-Karte fest eingetragen ist. Diese Adressen werden üblicherweise als eine Sequenz von zweistelligen Hexadezimalzahlen geschrieben, die jeweils durch Doppelpunkte voneinander getrennt werden (beispielsweise aa:bb:cc:dd:ee:ff). Ein von einem Rechner ausgesandter Frame wird von allen angeschlossenen Rechnern registriert, aber nur der Ziel-Host liest das Paket und verarbeitet es. Versuchen zwei Stationen zur gleichen Zeit zu senden, tritt eine sogenannte Kollision auf. Diese Kollision wird allerdings schnell von der Elektronik auf den Netzwerkkarten erkannt und aufgelöst, indem beide Stationen den Sendevorgang abbrechen, eine zufällige Zeitspanne warten und dann erneut versuchen, Daten zu übertragen. Sie haben vielleicht

schon viele Geschichten über die Problematik solcher Kollisionen gehört und daß das Ethernet dadurch nur etwa ein Drittel seiner eigentlichen Kapazität ausnutzen kann. Kollisionen sind im Ethernet ein normales Phänomen, und in stark ausgelasteten Ethernets brauchen Sie sich nicht zu wundern, wenn dort Kollisionsraten von ca. 30 Prozent auftreten. Sie müssen sich also erst ab einer Auslastung von etwa 60 Prozent Sorgen machen, da das die realistischere Grenze der praktisch möglichen Übertragungskapazität eines Ethernet ist. 2

Andere Arten von Hardware Bei größeren Installationen wie an der Groucho-Marx-Universität wird üblicherweise nicht nur Ethernet benutzt. Dort stehen auch viele andere Datenkommunikations-Protokolle zur Verfügung. Sie werden auch von Linux unterstützt, aber wir gehen hier aus Platzgründen nur kurz darauf ein. Für tiefgreifendere Ausführungen sei auf die existierenden HOWTO-Dokumente der Protokolle verwiesen. An der GMU sind die LANs aller Institute mit dem Universitäts-Backbone verbunden, einem Glasfaserkabel, über das FDDI (Fiber Distributed Data Interface) läuft. FDDI verwendet einen anderen Ansatz zur Datenübertragung, bei dem eine Reihe sogenannter Tokens ausgesandt werden. Eine Station darf nur dann ein Paket übertragen, wenn sie eines dieser Tokens auffangen konnte. Die Hauptvorteile von FDDI liegen vor allem in der deutlich geringeren Anzahl der Kollisionen, weshalb dieses Protokoll die Kapazität des Transportmediums fast vollständig ausschöpfen kann. Daraus resultieren Geschwindigkeiten von bis zu 100 Mbps. Auch die Kabellänge einer Glasfaser kann deutlich größer sein als bei den drahtbasierenden Technologien. Die Grenze liegt erst bei etwa 200 Kilometern — ideal für die Vernetzung vieler Gebäude in Städten oder — im Fall der GMU — der vielen Gebäude des Campus. Installationen von IBM-Token-Ring-Netzwerken findet man vor allem dort, wo Teile der technischen Ausstattung von IBM stammen. Token Ring wird in manchen LAN-Umgebungen als Alternative zu Ethernet eingesetzt und bietet in etwa dieselben Vorteile wie FDDI, was die Ausnutzung der vollen Übertragungskapazität des Transportmediums betrifft. Auf den verwendeten Drahtkabeln erreichen Token-Ring-Netzwerke nur Übertragungsraten von bis zu 4 Mbps oder 16 Mbps; dafür sind die Kabel aber deutlich billiger als Glasfaserkabel. In Linux wird die Token-Ring-Netzwerkunterstützung praktisch genauso konfiguriert wie Ethernet, so daß wir hier nicht näher darauf eingehen. Obwohl es heutzutage weit weniger üblich ist, können auch andere LAN-Technologien wie ArcNet oder DECNet installiert werden. Linux unterstützt diese auch, allerdings gehen wir hier nicht darauf ein. Viele nationale Netzwerke, die von Telekommunikationsfirmen verwaltet werden, unterstützen sogenannte paketvermittelnde Protokolle (Packet Switching Protocols). Das populärste unter ihnen ist X.25. Viele der sogenannten öffentlichen Datennetze — wie Tymnet in den USA, Austpack in Australien oder Datex-P in Deutschland — bieten diesen Service an. X.25 definiert selbst eine Reihe von Netzwerkprotokollen, die beschreiben, wie Datenterminals (z.B. ein Hostrechner) mit einer Datenkommunikations-Ausrüstung (X.25-Switch) kommunizieren. X.25 erfordert eine synchrone Datenverbindung und daher spezielle synchrone serielle Schnittstellen. Es ist aber auch möglich,

normale serielle Schnittstellen zu verwenden, wenn man eine spezielle Hardware namens PAD (Packet Assembler/Disassembler) zur Verfügung hat. Ein PAD ist ein Gerät mit einer synchronen seriellen Schnittstelle und einer oder mehreren asynchronen seriellen Schnittstellen. Es verwaltet das X.25-Protokoll so, daß auch einfache Terminals X.25-Verbindungen etablieren und akzeptieren können. X.25 wird häufig als Transportmittel für andere Netzwerkprotokolle wie z.B. TCP/IP benutzt. Weil IP-Pakete nicht einfach auf X.25-Pakete umgesetzt werden können (umgekehrt übrigens auch nicht), werden sie einfach in X.25-Pakete “eingepackt” und über das Netzwerk geschickt. In Linux wird das X.25-Protokoll zur Zeit nur experimentell unterstützt. Ein neueres Protokoll, das häufig von Telekommunikationsfirmen angeboten wird, ist das sogenannte Frame Relay. Dieses Protokoll hat einige Gemeinsamkeiten mit dem X.25-Protokoll, verhält sich aber fast so wie das IP-Protokoll. Wie X.25 erfordert auch Frame Relay spezielle synchrone serielle Hardware. Aufgrund ihrer Gemeinsamkeiten unterstützen viele Netzwerkkarten beide Protokolle zugleich. Es sind allerdings auch Varianten erhältlich, die ohne interne Hardware auskommen. Sie basieren auf einem externen Gerät, das als Frame Relay Access Device (FRAD) bezeichnet wird und bei der Datenübertragung für die “Kapselung” von IP-Paketen in Frame-Relay-Pakete zuständig ist. Frame Relay eignet sich vorzüglich zur Übertragung von TCP/IP-Paketen zwischen Sites. Linux bietet Unterstützung für einige interne Frame-Relay-Karten. Wenn Sie ein Hochgeschwindigkeits-Netzwerk benötigen, das außer Ihren normalen Daten auch verschiedene Medien wie digitalisierte Sprache und Videos übertragen kann, ist vielleicht ATM (Asynchronous Transfer Mode) genau das richtige für Sie. ATM ist eine neue Netzwerktechnologie, die speziell dafür ausgelegt wurde, Daten mit hoher Geschwindigkeit und geringer Verzögerung zu übertragen und dabei die Qualitätskontrolle (Quality of Service [Q.S.]) zu behalten. Viele Telekommunikationsfirmen errichten ganze Infrastrukturen aus ATM-Netzwerken, da sie damit eine Zusammenführung einer Vielzahl verschiedener Netzwerkdienste in einer einzigen Plattform erreichen und sich dadurch eine Reduzierung der Verwaltungs- und Support-Kosten erhoffen. ATM wird meistens zum Transport von TCP/IP-Daten benutzt. Das Networking-HOWTO enthält Informationen über die Unterstützung von ATM in Linux. Häufig benutzen Amateurfunker ihre Funkgeräte, um ihre Computer zu vernetzen. Diese Technik wird Paket-Radio (oder Ham-Radio) genannt. Eines der von Amateurfunkern verwendeten Protokolle wird AX.25 genannt und ist in gewisser Weise von X.25 abgeleitet. Es wird auch zur Übertragung von TCP/IP und anderen Protokollen benutzt. AX.25 benötigt wie X.25 synchrone serielle Hardware oder ein besonderes Gerät, das als “Terminal Node Controller” bezeichnet wird. Damit werden Datenpakete, die über eine asynchrone serielle Verbindung hereinkommen, in Datenpakete konvertiert, die synchron übertragen werden. Es gibt eine Vielzahl verschiedener Interface-Karten, die im Paket-Radio-Modus arbeiten können; sie werden als “Z8530 SCC”-basiert bezeichnet (nach dem am häufigsten verwendeten Kommunikations-Controller). Zwei andere häufig mit AX.25 übertragene (Netzwerkschicht-)Protokolle sind NetRom und Rose. Da beide Protokolle über AX.25 laufen, haben sie dieselben Hardwareanforderungen. Linux bietet eine vollständige Unterstützung von AX.25, NetRom und Rose. Das AX25-HOWTO ist eine gute Informationsquelle über die LinuxImplementierungen dieser Protokolle. Andere Techniken verwenden langsame, aber billige serielle Leitungen für den Internetzugriff über Wählleitungen (per Telefon, ISDN etc.). Das erfordert wieder ein anderes Protokoll für die

Datenübertragung, zum Beispiel SLIP oder PPP, die wir später beschreiben werden.

Das Internet-Protokoll Natürlich wollen Sie nicht, daß Ihr Netzwerk auf ein Ethernet oder eine Punkt-zu-Punkt-Verbindung beschränkt ist. Idealerweise sollten Sie mit einem Hostrechner kommunizieren können, ohne Rücksicht darauf nehmen zu müssen, mit welchem Netzwerktyp er verbunden ist. Beispielsweise finden Sie bei einer größeren Installation wie an der Groucho-Marx-Universität üblicherweise eine ganze Reihe separater Netzwerke, die auf irgendeine Art und Weise miteinander verbunden werden müssen. Am mathematischen Institut der GMU wird mit zwei Ethernets gearbeitet: ein Netzwerk mit schnellen Maschinen für Professoren und wissenschaftliche Mitarbeiter und eines mit langsamen Maschinen für die Studenten. Beide Netze hängen am universitätseigenen FDDI-Backbone. Die Verbindung wird von einem speziellen Host, einem sogenannten Gateway, verwaltet, der ein- und ausgehende Pakete zwischen den beiden Ethernets und der Glasfaserleitung kopiert. Nehmen wir beispielsweise einmal an, Sie sitzen im mathematischen Institut und wollen von Ihrem Linux-Rechner aus auf quark im LAN des physikalischen Instituts zugreifen. Die Netzwerksoftware kann die Pakete nicht direkt an quark schicken, weil es sich nicht in demselben Ethernet befindet. Die Software muß sich nun also auf ein Gateway verlassen, das das Paket entsprechend weiterleitet. Das Gateway (nennen wir es sophus) leitet die Pakete an das Gateway niels weiter, das diese Funktion für das physikalische Institut übernimmt. Die Übertragung erfolgt über den Backbone, und niels liefert die Daten dann an den Zielrechner aus. Der Datenfluß zwischen erdos und quark ist in Abbildung 1.1 dargestellt. Abbildung 1.1: Die drei Schritte beim Senden eines Datagramms von erdos an quark

Dieses Schema der Weiterleitung von Daten an einen entfernten Host wird Routing genannt. Die Datenpakete werden in diesem Zusammenhang häufig als Datagramme bezeichnet. Um die Dinge etwas zu vereinfachen, werden Datagramme über ein einziges Protokoll ausgetauscht, das von der verwendeten Hardware völlig unabhängig ist: IP oder Internet Protocol. In Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, werden wir IP und Routing detaillierter behandeln. Der Hauptvorteil von IP besteht darin, daß es physikalisch verschiedene Netzwerke zu einem scheinbar homogenen Netzwerk zusammenfaßt. Das wird als “Internetworking” bezeichnet, und das daraus resultierende “Meta-Netzwerk” wird Internet genannt. Beachten Sie an dieser Stelle den feinen Unterschied zwischen einem Internet und dem Internet. Das Internet ist der offizielle Name eines bestimmten globalen Internets. Natürlich benötigt IP auch ein hardwareunabhängiges Adressierungsschema. Dies wird dadurch erreicht, daß jedem Host eine eindeutige 32-Bit-Zahl zugewiesen wird, die sogenannte IP-Adresse. Dargestellt wird eine IP-Adresse üblicherweise durch vier Dezimalzahlen, eine für jeden 8-Bit-Anteil, die durch Punkte voneinander getrennt sind. Zum Beispiel könnte quark die IP-Adresse 0x954C0C04 besitzen, die Sie dann als 149.76.12.4 schreiben würden. Dieses Format wird auch Dotted Decimal Notation oder Dotted Quad Notation genannt und tritt neuerdings unter der Bezeichnung IPv4 (Internet Protocol, Version 4) in Erscheinung. Mittlerweile wird ein neuer Standard namens IPv6 entwickelt, dem ein wesentlich flexibleres Adressierungsschema zugrundeliegt und der weitere moderne Features zu bieten hat. Es wird aber nach Erscheinen dieses Buches noch mindestens ein Jahr dauern, bis IPv6 in größerem Maßstab eingesetzt wird.

Sie werden bemerkt haben, daß wir nun drei verschiedene Arten von Adressen haben: Zum einen haben wir Hostnamen wie z.B. quark, dann gibt es IP-Adressen, und zum Schluß gibt es noch Hardwareadressen wie die 6-Byte-Ethernet-Adresse. Das alles muß irgendwie so zusammenpassen, daß, wenn Sie rlogin quark eingeben, der Netzwerksoftware die IP-Adresse von quark übergeben werden kann. Liefert IP irgendwelche Daten an das physikalische Institut, muß es irgendwie herausfinden, welche Ethernet-Adresse zu welcher IP-Adresse gehört. Mit dieser Thematik werden wir uns in Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, ausführlicher befassen. Im Moment reicht es, sich zu merken, daß die für das Finden einer Adresse benötigten Schritte als Auflösen des Hostnamens, oder Hostname Resolution, bezeichnet werden, mit dem Ziel der Abbildung von Hostnamen auf IP-Adressen. Address Resolution ist dagegen der Prozeß, bei dem IP-Adressen auf Hardwareadressen abgebildet werden.

IP über serielle Leitungen Bei seriellen Leitungen gibt es einen als SLIP (Serial Line IP) bekannten “De facto”-Standard. Eine modifizierte Version von SLIP ist CSLIP, oder Compressed SLIP, bei der die IP-Header komprimiert werden, um die relativ geringe Bandbreite von seriellen Links besser auszunutzen. Ein anderes serielles Protokoll ist PPP (Point-to-Point Protocol). PPP bietet gegenüber SLIP eine ganze Reihe weiterer Features, die es etwas attraktiver machen. Der Hauptvorteil gegenüber SLIP liegt darin, daß es nicht auf den Transport von IP-Datagrammen beschränkt ist, sondern mit beliebigen DatagrammArten zurechtkommt.

Transmission Control Protocol Mit dem Übertragen von Datagrammen von einem Host zum anderen ist es nicht getan. Wenn Sie sich auf quark einloggen, wollen Sie eine zuverlässige Verbindung zwischen Ihrem rlogin-Prozeß auf erdos und dem Shell-Prozeß auf quark. Das bedeutet aber, daß die übertragenen Informationen vom Sender in Pakete aufgeteilt und vom Empfänger wieder zu einem richtigen Datenstrom zusammengesetzt werden müssen. So trivial Ihnen das auch vorkommen mag, so beinhaltet dieses Vorgehen jedoch eine Reihe komplizierter Aufgaben. Eine sehr wichtige Tatsache, die Sie über IP wissen sollten, ist, daß es prinzipiell unzuverlässig ist, und das mit Absicht! Stellen Sie sich vor, daß zehn Leute in Ihrem Ethernet gleichzeitig anfangen, die neueste Ausgabe des Webbrowsers von Netscape vom FTP-Server der GMU herunterzuladen. Die Menge der zu übertragenden Daten könnte für das Gateway zuviel sein, weil es zu langsam oder nicht ausreichend mit Speicher bestückt ist. Wollen Sie nun ein Paket an quark übertragen, könnten die Puffer von sophus gerade voll sein, und der Rechner wäre in diesem Fall nicht in der Lage, das Paket weiterzuleiten. IP löst dieses Problem, indem es dieses Paket einfach “vergißt” — das Paket geht unwiderbringlich verloren. Die Verantwortung für die Integritätsprüfung und die Vollständigkeit der Daten liegt daher bei den kommunizierenden Hosts, die entsprechend Sorge dafür tragen müssen, im Fehlerfall Datenpakete erneut zu senden.

Dies wird von wieder einem anderen Protokoll namens TCP, oder Transmission Control Protocol, erledigt, das einen zuverlässigen Dienst auf IP aufbaut. Das Hauptmerkmal von TCP ist, daß es IP verwendet, um bei Ihnen den Eindruck zu erwecken, daß eine einfache Verbindung zwischen den beiden Prozessen auf Ihrem Host und auf der entfernten Maschine existiert. Sie müssen sich also nicht darum kümmern, wie und auf welcher Route die Daten tatsächlich reisen. Eine TCP-Verbindung arbeitet grundsätzlich wie eine Zwei-Wege-Pipe, bei der beide Prozesse schreiben und lesen können. Stellen Sie es sich wie ein einfaches Telefonat vor. TCP identifiziert die Endpunkte einer solchen Verbindung anhand der IP-Adressen der beiden Hosts und der Nummer eines sogenannten Ports auf jedem Host. Ports können Sie sich als eine Art Zugangspunkt für Netzwerkverbindungen vorstellen. Wenn wir bei unserem Telefonbeispiel bleiben, können Sie IP-Adressen mit Vorwahlnummern (Nummern für bestimmte Städte) und Portnummern mit dem lokalen Code (Nummern der individuellen Teilnehmer) vergleichen. Ein einziger Host kann viele verschiedene Dienste bieten, die anhand ihrer Portnummern unterschieden werden. In unserem rlogin-Beispiel öffnet die Client-Anwendung (rlogin) einen Port auf erdos und stellt eine Verbindung mit Port 513 auf quark her, den der rlogind-Server verwendet. Auf diese Weise wird eine TCP-Verbindung hergestellt. Über diese Verbindung führt rlogind zuerst die Autorisierung durch und startet (“spawnt”) eine Shell. Die Standardeingabe und -ausgabe der Shell wird in die TCPVerbindung umgeleitet (“redirection”). Das bedeutet, daß alles, was Sie unter rlogin auf Ihrer Maschine eingeben, über den TCP-Stream geleitet und als Standardeingabe für die Shell verwendet wird.

User Datagram Protocol Natürlich ist TCP nicht das einzige bei TCP/IP-Netzwerken verwendete Protokoll. Obwohl für Anwendungen wie rlogin geeignet, verbietet sich der Einsatz von TCP wegen des zu verwaltenden Overheads für manche Anwendungen von selbst. Eine solche Anwendung ist NFS, die das mit TCP verwandte UDP-Protokoll oder User Datagram Protocol) benutzt. Genau wie TCP erlaubt auch UDP einer Anwendung, mit einem Dienst auf einem entfernten Rechner über einen bestimmten Port in Kontakt zu treten. Es wird aber keine Verbindung aufgebaut, sondern es werden nur einzelne Pakete an den entsprechenden Dienst gesandt — daher der Name. Angenommen, Sie wollen eine kleinere Datenmenge von einem Datenbankserver abfragen. Dafür werden mit TCP mindestens drei Datagramme zum Verbindungsaufbau, weitere drei Datagramme zum Senden jedes Datenpakets (in jede Richtung) und nochmals drei Datagramme zum Schließen der Verbindung benötigt. Dasselbe Resultat erreicht UDP mit nur zwei Datagrammen. UDP wird als “verbindungslos” bezeichnet, denn es benötigt keinen Verbindungsaufbau und -abbau. Wir brauchen unsere Daten nur in ein Datagramm zu packen und es zum Server zu senden. Auf dieselbe Weise schickt der Server seine Antwort zurück. Dieses Verfahren ist zwar deutlich schneller als TCP, aber nur für sehr einfache Transaktionen geeignet. UDP kommt im Gegensatz zu TCP nicht mit Datenverlusten zurecht. Es obliegt daher der Anwendung (z.B. Name-Server), darauf zu achten.

Mehr zu Ports

Sie können sich Ports als Zugangspunkte für Netzwerkverbindungen vorstellen. Will eine Anwendung einen Dienst anbieten, verwendet sie einen bestimmten Port und wartet auf Clients. (Dieses Warten ist auch als “Horchen” oder Listening am Port bekannt.) Möchte ein Client den Dienst nutzen, bestimmt er einen Port auf seinem lokalen Rechner und baut eine Verbindung zu dem Port des Servers auf dem entfernten Host auf. Derselbe Port kann auf vielen verschiedenen Maschinen geöffnet sein, aber auf jeder Maschine kann immer nur ein Prozeß zur Zeit einen Port öffnen. Eine wichtige Eigenschaft von Ports ist, daß, wenn erst einmal eine Verbindung zwischen dem Client und dem Server aufgebaut wurde, sich eine weitere Kopie des Servers an den Server-Port anhängen und nach weiteren Clients horchen kann. Das ermöglicht beispielsweise, daß mehrere externe Logins gleichzeitig den Port 513 auf demselben Host verwenden. TCP ist in der Lage, die verschiedenen Verbindungen zu unterscheiden, weil sie alle von unterschiedlichen Ports oder Hosts kommen. Wenn Sie sich zum Beispiel zweimal von erdos aus in quark einloggen, verwendet der erste rlogin-Client den lokalen Port 1023 und der zweite Port 1022. Beide stellen aber eine Verbindung zu Port 513 auf quark her. Die beiden Verbindungen werden anhand der verwendeten Portnummern in erdos unterschieden. Dieses Beispiel zeigt die Verwendung von Ports als Treffpunkt, der von Clients angelaufen wird, wenn ein bestimmter Dienst in Anspruch genommen werden soll. Damit ein Client auch die richtige Portnummer anspricht, muß über diese Nummern eine Vereinbarung zwischen den Administratoren beider Systeme getroffen werden. Bei Diensten, die so weit verbreitet sind wie rlogin, werden die Nummern zentral verwaltet. Dies wird von der IETF (Internet Engineering Task Force) erledigt, die in regelmäßigen Abständen ein RFC namens Assigned Numbers (RFC-1700) veröffentlicht. Dieses Dokument beschreibt unter anderem die Portnummern der bekannten Dienste. Linux verwendet eine Datei namens /etc/services, die Servicenamen mit Portnummern verbindet. Anzumerken wäre noch, daß TCP und UDP zwar beide auf Ports aufbauen, diese Nummern aber nicht zu Konflikten führen. Das bedeutet, daß beispielsweise TCP-Port 513 mit UDP-Port 513 nicht identisch ist. Tatsächlich dienen diese Ports als Zugriffspunkte auf zwei verschiedene Dienste, nämlich rlogin (TCP) und rwho (UDP), um genau zu sein.

Die Socket Library Beim UNIX-Betriebssystem ist die Software, die all diese Aufgaben und Protokolle durchführt, üblicherweise direkt in den Kernel integriert, und so ist es auch bei Linux. Die gängigste Programmierschnittstelle in der UNIX-Welt ist die Berkeley Socket Library. Der Name stammt von einer bekannten Analogie, die Ports als Steckdosen (Sockets) und den Verbindungsaufbau zu einem Port als»Einstecken« beschreibt. Die Bibliothek stellt die bind-Funktion bereit, mit der Sie einen entfernten Host, ein Transportprotokoll und einen Dienst spezifizieren können, zu dem ein Programm eine Verbindung herstellen oder an dem es horchen kann. Zu diesem Zweck stehen die Funktionen connect, listenund accept bereit. Die Socket-Bibliothek ist noch etwas allgemeiner gehalten, denn sie bietet nicht nur eine Klasse von TCP/IP-basierten Sockets (die AF_INET-Sockets), sondern auch eine Klasse (die AF_UNIX-Klasse), die Verbindungen verwaltet, die auf dem lokalen Rechner stattfinden. Einige Implementierungen können auch mit anderen Klassen wie dem XNS-Protokoll (Xerox Networking System) oder X.25 umgehen.

In Linux ist die Socket Library Teil der Standard C Library (libc). Sie unterstützt die Sockets AF_INET und AF_INET6 für TCP/IP und AF_UNIX für Unix Domain Sockets, außerdem AF_IPX für Novell-Netzwerkprotokolle, AF_X25 für das X.25-Netzwerkprotokoll, AF_ATMPVC und AF_ATMSVC für das ATM-Netzwerkprotokoll sowie AF_AX25-, AF_NETROM- und AF_ROSESockets für Amateurfunk-Protokolle. Andere Protokoll-familien werden gerade entwickelt und im Laufe der Zeit hinzugefügt.

1.

Eine Shell ist eine Kommandozeilen-Schnittstelle zum Unix-Betriebssystem. Sie ist dem DOSPrompt in Microsoft Windows sehr ähnlich, allerdings erheblich leistungsfähiger.

2.

Die Ethernet-FAQ unter http://www.faqs.org/faqs/LANs/ethernet-faq/ beschäftigt sich mit dieser Angelegenheit. Eine Menge detaillierter historischer und technischer Informationen finden Sie auf der Website von Charles Spurgeon unter http://wwwhost.ots.utexas.edu/ethernet/.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

UUCP-Netzwerke UUCP ist die Abkürzung für “Unix-to-Unix Copy”. Es begann als Programmpaket zur Übertragung von Dateien über serielle Leitungen, zur Steuerung dieser Transfers und zur Ausführung von Programmen auf entfernten (remote) Sites. Seit seiner ersten Im-plementierung in den späten siebziger Jahren hat das System viele schwerwiegende Änderungen erfahren, dennoch sind die angebotenen Dienste eher spartanisch. Das Haupteinsatzgebiet liegt nach wie vor bei Wide-AreaNetzwerken, die auf Telefon-Wählleitungen basieren. UUCP wurde 1977 zuerst von den Bell Laboratories für die Kommunikation zwischen deren UNIXEntwicklungs-Sites entworfen. Mitte 1978 verband dieses Netzwerk bereits über 80 Sites. An Anwendungen bot es hauptsächlich E-Mail und Weiterleitungen von Druckaufträgen, allerdings lag die Hauptaufgabe des Systems im Verteilen neuer Software und Bugfixes. Heutzutage ist UUCP nicht mehr nur auf die UNIX-Umgebung beschränkt. Es existieren sowohl freie als auch kommerzielle Portierungen für eine ganze Reihe unterschiedlicher Plattformen wie AmigaOS, DOS, Atari TOS usw. Einer der großen Nachteile von UUCP-Netzwerken ist deren geringe Bandbreite. Auf der einen Seite schränken die Telefoneinrichtungen die maximale Übertragungsrate stark ein. Andererseits arbeiten UUCP-Links selten mit permanenten Verbindungen, statt dessen rufen sich die Hosts in regelmäßigen Intervallen über Wählleitungen an. Daher verbringt eine Nachricht, die über ein UUCP-Netz verschickt wird, die meiste Zeit damit, auf der Festplatte eines Host herumzuliegen und darauf zu

warten, daß wieder eine Verbindung hergestellt wird. UUCP eignet sich zwar gut zur Verteilung von E-Mails, für Dienste wie rlogin ist es aber völlig ungeeignet. Trotz dieser Einschränkungen gibt es immer noch viele UUCP-Netzwerke, die die ganze Welt umspannen. Betrieben werden sie meistens von Hobbyisten, die privaten Benutzern Netzwerkzugänge zu vernünftigen Preisen anbieten. Der Hauptgrund für die Beliebtheit von UUCP liegt sicher darin, daß es, im Vergleich zum Internet, spottbillig ist. Um Ihren Computer in einen UUCP-Knoten zu verwandeln, benötigen Sie nur ein Modem, eine funktionierende UUCP-Implementierung und einen weiteren UUCP-Knoten, der bereit ist, Sie mit Mail und News zu versorgen. Die Konfiguration von UUCP behandeln wir später in einem eigenen Kapitel. Allerdings werden wir uns nicht zu sehr damit beschäftigen, da UUCP mittlerweile immer mehr von TCP/IP verdrängt wird, zumal nun fast auf der ganzen Welt billige Internetzugänge angeboten werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Netzwerke unter Linux Als Ergebnis der Bemühungen von Programmierern aus aller Welt wäre Linux ohne das globale Internet nicht denkbar gewesen. Es ist also nicht weiter überraschend, daß bereits in den frühen Entwicklungsphasen verschiedene Leute damit begannen, es um Netzwerkfähigkeiten zu erweitern. Eine UUCP-Implementierung lief nahezu von Anfang an unter Linux. Die Arbeit an TCP/IP-basierter Netzwerktechnik begann ungefähr im Herbst 1992, als Ross Biro und andere das entwickelten, was später unter dem Namen Net-1 bekannt wurde. Nachdem Ross im Mai 1993 mit der aktiven Entwicklung aufhörte, begann Fred van Kempen mit der Arbeit an einer neuen Implementierung, wobei größere Teile des Codes neu geschrieben wurden. Diese Implementierung war unter dem Namen Net-2 bekannt. Die erste öffentliche Release, Net-2d, war im Sommer 1993 (als Teil des 0.99.10-Kernel) verfügbar und wurde seitdem von verschiedenen Leuten (besonders von Alan Cox1) verwaltet und erweitert und ist nun als Net-2Debugged bekannt. Nach Behebung vieler Fehler und nach zahlreichen Verbesserungen des Codes wurde es in Net-3 umbenannt, nachdem Linux 1.0 verfügbar war. Diese Version des Netzwerkcodes wurde für Linux 1.2 und Linux 2.0 weiterentwickelt. Die Kernel der Version 2.2 und später verwenden den Net-4Code, der zur Zeit als offizieller Standard gilt. Net-4 bietet Gerätetreiber (device driver) für eine große Anzahl unterschiedlicher Ethernet-Karten, aber auch SLIP (zur Übertragung von Daten über serielle Leitungen) und PLIP (für parallele

Leitungen), IPX (für Novell-kompatible Netzwerke; diese behandeln wir in Kapitel 15 IPX und das NCP-Dateisystem), Appletalk (für Apple-Netzwerke) und AX.25, NetRom und Rose (für Amateurfunk-Netzwerke). Außerdem unterstützt Net-4 Features wie IP-Firewalls (Kapitel 9 TCP/IPFirewall), IP Accounting (Kapitel 10 IP-Accounting) und IP Masquerading (Kapitel 11 IPMasquerade und die Umsetzung von Netzwerkadressen). Auch IP Tunnelling und Routing werden in verschiedenen Varianten unterstützt. Schließlich ist Net-4 nicht nur für Ethernets ausgelegt, sondern auch für Netzwerke wie FDDI, Token Ring, Frame Relay, ISDN und ATM. Es existiert eine Vielzahl weiterer Features, die die Flexibilität von Linux noch deutlich steigern. Dazu gehören unter anderem das Novell NCP (NetWare Core Protocol) sowie das SMB-Protokoll “Samba”, das von Andrew Tridgell geschrieben wurde und mit Anwendungen wie Microsoft Windows und dem lanmanager zusammenarbeiten kann.2

Verschiedene Streiflichter der Entwicklung Es gab in der Vergangenheit immer wieder aktive Bemühungen, Linux mit den neuesten Netzwerktechnologien auszustatten. Nachdem Net-2Debugged die offizielle Netzwerkimplementierung wurde, setzte Fred van Kempen die Entwicklung zu Net-2e fort, das sich durch ein stark überarbeitetes Design der Netzwerkschicht auszeichnete. Fred arbeitete auf eine standardisierte Gerätetreiber-Schnittstelle (Device Driver Interface, DDI) hin, aber die Arbeit an Net-2e ist mittlerweile beendet. Eine weitere Implementierung von TCP/IP stammt aus der Feder von Matthias Urlichs. Er schrieb einen ISDN-Treiber für Linux und FreeBSD und integrierte dafür einen Teil des BSD-Netzwerkcodes in den Linux-Kernel. Dieses Projekt wird mittlerweile auch nicht mehr fortgeführt. Im Laufe der Zeit gab es viele kurzfristige Änderungen in den Netzwerk-Implementierungen des Linux-Kernels. Solange die Entwicklung fortschreitet, ist auch heute noch stete Weiterentwicklung oberstes Gebot. Manchmal erfordert diese Weiterentwicklung auch Änderungen in der Anwendungssoftware, wie etwa den Netzwerk-Konfigurations-Tools. Obwohl dieses nicht mehr ein ganz so großes Problem darstellt wie früher einmal, erfordert ein Kernel-Upgrade gegebenenfalls auch immer noch ein Upgrade der Netzwerk-Konfigurations-Tools. Zum Glück sind heute viele verschiedene Linux-Distributionen erhältlich, so daß dieses Problem mittlerweile schnell erledigt ist. Die Net-4-Netzwerksoftware ist mittlerweile recht ausgereift und wird auf sehr vielen Sites auf der ganzen Welt verwendet. Viel Arbeit und Mühe wurde besonders in die Geschwindigkeitsoptimierung des Net-4-Codes investiert, und es verwundert daher nicht, daß er nun mit den besten Netzwerkimplementierungen mithalten kann. Linux “wuchert” besonders im Bereich der InternetService-Provider und wird dort häufig zum Aufbau billiger und zuverlässiger WWW-Server, MailServer und News-Server benutzt. Linux hat bei den Entwicklern so viel Interesse geweckt, daß es stets mit den neuesten Netzwerktechnologien Schritt hält. So bieten die aktuellen Versionen des LinuxKernels bereits standardmäßig Unterstützung für das Internet-Protokoll von morgen namens IPv6.

Wo Sie den Code herbekommen Es hört sich nun komisch an, wenn man sich so daran erinnert, daß man in den frühen Tagen des Linux-Netzwerkcodes den Standard-Kernel erst durch riesige Patches ergänzen mußte, um ihn netzwerkfähig zu machen. Heute ist die Pflege des Netzwerkcodes nur noch ein ganz normaler Bestandteil der weiteren Kernel-Entwicklung. Die neuesten stabilen Kernel sind erhältlich von ftp.kernel.org im Verzeichnis /pub/linux/kernel/v2.x/, wobei das x immer eine gerade Zahl ist. Die neuesten Entwickler-Kernel findet man ebenfalls bei ftp.kernel.org im Verzeichnis /pub/linux/kernel/v2.y/, wobei y immer eine ungerade Zahl ist. Außerdem gibt es auf der ganzen Welt Spiegel-Sites der Linux-Kernel-Quellen. Linux ohne Netzwerkunterstützung kann man sich mittlerweile kaum noch vorstellen.

1.

Alan ist erreichbar unter [email protected].

2.

NCP ist das Protokoll, auf dem die Novell-Datei- und -Druckdienste basieren.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie Sie Ihr System verwalten In diesem Buch befassen wir uns hauptsächlich mit Installations- und Konfigurationsfragen. Administration bedeutet aber wesentlich mehr als das — nachdem Sie einen Dienst eingerichtet haben, müssen Sie ihn auch am Laufen halten. Den meisten Diensten müssen Sie nicht besonders viel Aufmerksamkeit schenken, während andere wie Mail und News die Erledigung von Routineaufgaben von Ihnen verlangen, um Ihr System auf dem neuesten Stand zu halten. Diese Aufgaben werden wir in späteren Kapiteln behandeln. Das absolute Verwaltungsminimum ist die regelmäßige Prüfung der System- und der einzelnen Anwendungs-Logdateien auf Fehler und ungewöhnliche Ereignisse. In der Regel erledigen Sie dies durch das Schreiben einer Reihe administrativer Shell-Skripten, die periodisch von cron aus ausgeführt werden. Die Source-Distributionen einiger bedeutender Anwendungen wie inn oder C News enthalten solche Skripten. Sie müssen diese entsprechend Ihren Anforderungen und Bedürfnissen anpassen. Die Ausgabe von jedem Ihrer cron-Jobs sollte per E-Mail an einen administrativen Account gesandt werden. Per Voreinstellung senden viele Anwendungen Fehlermeldungen, Benutzungsstatistiken oder Zusammenfassungen von Logdateien an den root-Account. Das macht nur Sinn, wenn Sie sich häufig als root einloggen; besser ist es dagegen, die Mail von root an Ihren persönlichen Account weiterzuleiten, indem Sie einen Mail-Alias einrichten, wie dies in den Kapiteln Kapitel 19

Inbetriebnahme von Exim, und Kapitel 18 Sendmail, beschrieben ist. Gleichgültig, wie sorgfältig Sie Ihre Site konfiguriert haben, Murphys Gesetz garantiert, daß ein Problem auftauchen wird. Darum bedeutet die Verwaltung eines Systems auch, daß Sie für Beschwerden erreichbar sein müssen. Normalerweise erwarten die Leute, daß der Systemadministrator zumindest als root per E-Mail erreichbar ist, es existieren aber auch andere Adressen, die häufig verwendet werden, um eine Person zu erreichen, die für einen bestimmten Aspekt der Verwaltung zuständig ist. Beispielsweise werden Beschwerden über eine fehlerhafte MailKonfiguration üblicherweise an postmaster adressiert. Probleme mit dem News-System werden dem Benutzer, newsmaster oder usenet, mitgeteilt. Mail an hostmaster sollte an die Person weitergeleitet werden, die sich um die grundlegenden Netzwerkdienste und den DNS-Service kümmert (falls vorhanden).

Systemsicherheit Ein anderer wichtiger Aspekt der Systemadministration in einer Netzwerkumgebung ist der Schutz Ihres Systems vor Eindringlingen. Nachlässig verwaltete Systeme bieten böswilligen Zeitgenossen viele Ziele. Die Angriffe reichen von geknackten Paßwörtern bis hin zum Ethernet-Snooping, und die verursachten Schäden reichen von gefälschten Mails über Datenverlust bis hin zur Verletzung Ihrer Privatsphäre. Wir werden auf die Probleme im einzelnen dort eingehen, wo die Probleme auch wirklich auftreten. Gleichzeitig stellen wir Ihnen einige gängige Schutzmaßnahmen vor. Dieser Abschnitt beschreibt einige Beispiele und grundlegende Techniken zur System-sicherheit. Natürlich können die behandelten Aspekte nicht alle Sicherheitsthemen im Detail erläutern, denen Sie begegnen könnten; sie dienen bloß dazu, die möglichen Probleme zu verdeutlichen, die auftreten könnten. Aus diesem Grund ist das Lesen eines guten Buches über Systemsicherheit ein absolutes Muß, besonders bei einem vernetzten System. Die Systemsicherheit beginnt mit guter Systemadministration. Das beinhaltet die Überprüfung von Eigentums- und Zugriffsrechten aller aktiven Dateien und Verzeichnisse, die Überwachung privilegierter Accounts etc. Dafür eignet sich zum Beispiel das Programm COPS. Es überprüft Ihr Dateisystem und gängige Systemdateien auf ungewöhnliche Rechte und andere Anomalien. Es ist auch klug, ein Paßwort-Paket zu verwenden, das verschiedene Vorschriften zur Wahl eines BenutzerPaßwortes durchsetzt, um es so schwer wie möglich zu machen, es zu erraten. Das Shadow-PaßwortPaket beispielsweise verlangt, daß ein Paßwort aus mindestens fünf Zeichen besteht und sowohl großals auch kleingeschriebene Buchstaben (und Sonderzeichen) enthält. Wenn Sie einen Dienst über das Netzwerk verfügbar machen, sollten Sie sicherstellen, daß Sie ihm die “geringsten Privilegien” zuweisen, d.h. ihm keine Dinge erlauben, die für seine Arbeit nicht benötigt werden. Zum Beispiel sollten Programme die UID nur, wenn unbedingt nötig, auf root oder einen anderen privilegierten Account einstellen dürfen. Zum Beispiel sollten Programme nur dann unter root-Berechtigung laufen, wenn unbedingt nötig. Wenn ein Dienst nur für eine sehr eingeschränkte Anwendung eingesetzt werden soll, sollten Sie nicht zögern, ihn so restriktiv zu konfigurieren, wie es diese spezielle Anwendung zuläßt. Sollen andere beispielsweise direkt von Ihrer Maschine booten können, müssen Sie TFTP (Trivial File Transfer Protocol) installieren, damit

Benutzer grundlegende Konfigurationsdateien aus Ihrem /boot-Verzeichnis herunterladen können. Wird es nun aber ohne Beschränkungen verwendet, erlaubt TFTP jedem Benutzer überall auf der Welt jede allgemein lesbare Datei von Ihrem System herunterzuladen. Sollte dies nicht in Ihrem Sinne sein, warum also nicht den TFTP-Dienst auf das /boot-Verzeichnis beschränken?1 Diesen Gedanken fortführend, könnten Sie verschiedene Dienste auch auf die Benutzer bestimmter Hosts, wie beispielsweise Ihres lokalen Netzwerks, einschränken. In Kapitel 12 Wichtige NetzwerkFeatures, stellen wir tcpd vor, das dies für eine ganze Reihe von Netzwerkanwendungen tut. Weiterentwickelte Methoden der Zugriffsbeschränkung auf ausgewählte Hosts oder Dienste erforschen wir in Kapitel 9 TCP/IP-Firewall. Ein weiterer wichtiger Punkt ist die Vermeidung “gefährlicher” Software. Natürlich ist jede Software potentiell gefährlich, weil sie fehlerhaft sein kann, was clevere Leute ausnutzen könnten, um sich Zugang zu Ihrem System zu verschaffen. Solche Dinge kommen vor, und es gibt einfach keinen vollständigen Schutz davor. Dieses Problem betrifft freie und kommerzielle Software gleichermaßen.2 Programme, die besondere Privilegien benötigen, sind naturgemäß gefährlicher als andere, weil jedes Schlupfloch dramatische Konsequenzen nach sich ziehen kann.3 Wenn Sie einen Netzwerkdienst anbieten, der ein setuid-Programm benötigt, müssen Sie doppelt vorsichtig sein, nichts in der Dokumentation zu übersehen, damit Sie nicht versehentlich ein Sicherheitsloch öffnen. Einen weiteren Grund zur Sorge sollten Ihnen Programme bereiten, die Logins oder die Ausführung von Kommandos mit begrenzter Authentifizierung ermöglichen. Die Befehle rlogin, rsh und rexec sind zweifellos alle nützlich, bieten allerdings nur sehr eingeschränkte Authentifizierungsprüfungen der Gegenstellen an. Die Authentifizierung verläßt sich auf die Korrektheit des Hostnamens der Gegenstelle, der von einem Name-Server abgefragt wird (darauf gehen wir später näher ein) und abgefangen werden kann. Heutzutage sollte es die Standardvorgehensweise sein, alle r-Kommandos komplett aus dem System zu entfernen und durch ssh-Tools zu ersetzen. Diese benutzen ein wesentlich zuverlässigeres Authentifizierungsverfahren und stellen obendrein weitere Dienste zur Verfügung, wie z.B. Verschlüsselung und Komprimierung. Sie können niemals ausschließen, daß Ihre Sicherheitsvorkehrungen nicht doch fehlschlagen, egal, wie sorgfältig Sie waren. Sie sollten daher sicherstellen, daß Sie Eindringlinge frühzeitig erkennen. Die Überprüfung der Logdateien ist ein guter Ansatzpunkt, aber der Eindringling ist möglicherweise so clever und entfernt alle Spuren. Andererseits existieren Tools wie tripwire, geschrieben von Gene Kim und Gene Spafford, mit denen Sie überprüfen können, ob bei lebenswichtigen Systemdateien der Inhalt oder die Zugriffsrechte verändert wurden. tripwire berechnet verschiedene Checksummen dieser Dateien und speichert sie in einer Datenbank. Bei nachfolgenden Läufen werden die Checksummen erneut berechnet und mit den gespeicherten verglichen, um Veränderungen zu erkennen.

1.

Wir kommen darauf noch in Kapitel 12 Wichtige Netzwerk-Features, zurück.

2.

Es gab tatsächlich kommerzielle Unix-Systeme (für die man übrigens sehr viel Geld hinlegen mußte), die mit einem setuid-root-Shell-Skript auf den Markt kamen. Das ermöglichte Anwendern, mit einem ganz einfachen Trick root-Privilegien zu ergattern.

3.

1988 brachte der RTM-Wurm einen großen Teil des Internet zum Teil dadurch zum Erliegen, daß er eine Lücke in einigen sendmail-Programmen ausnutzte. Diese Lücke wurde schon seit langem geschlossen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP

Wir wenden uns nun den Details zu, mit denen Sie es beim Anschluß Ihrer Linux-Maschine an ein TCP/IP-Netzwerk zu tun bekommen, darunter fallen der Umgang mit IP-Adressen, Hostnamen und manchmal auch Routing-Aufgaben. Dieses Kapitel gibt Ihnen das erforderliche Hintergrundwissen an die Hand, das Sie benötigen, um die Anforderungen Ihres Setups zu verstehen. Die nächsten Kapitel

behandeln die Tools, die Sie dabei verwenden werden. Wenn Sie mehr über TCP/IP und dessen Hintergründe erfahren wollen, sollten Sie sich das aus drei Bänden bestehende Internetworking with TCP/IP von Douglas R. Comer (erschienen bei Prentice Hall) ansehen. Eine etwas detailliertere Anleitung zur Verwaltung eines TCP/IP-Netzwerks finden Sie in TCP/IP Netzwerk Administration von Craig Hunt (erschienen bei O'Reilly).

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Netzwerkschnittstellen Um den Anwender nicht mit den vielfältigen technischen Details der Ausrüstung zu belas-ten, die in einem Netzwerk eingesetzt werden kann, definiert TCP/IP eine abstrakte Schnittstelle, über die auf die Hardware zugegriffen wird. Dieses Interface bietet eine Reihe von Operationen an, die für jede Hardware gleich sind und sich im wesentlichen mit dem Senden und Empfangen von Paketen beschäftigen. Für jedes periphere Gerät, das Sie für das Netzwerk verwenden wollen, muß ein entsprechendes Interface im Kernel präsent sein. Zum Beispiel werden Ethernet-Interfaces unter Linux eth0 und eth1 genannt. Die Schnittstellen für PPP (beschrieben in Kapitel 8 Das Point-to-Point-Protokoll) haben die Bezeichnungen ppp0 und ppp1, während FDDI-Interfaces mit fddi0 und fddi1 angesprochen werden. Die Namen dieser Schnittstellen werden zu Konfigurationszwecken verwendet, wenn Sie eine bestimmte physische Einheit für den Kernel benennen wollen. Darüber hinaus besitzen sie keine Bedeutung. Um in einem TCP/IP-Netzwerk eingesetzt werden zu können, muß dem Interface eine IP-Adresse zugewiesen werden, die als Identifizierung dient, wenn mit dem Rest der Welt kommuniziert wird. Diese Adresse ist nicht mit dem oben erwähnten Interface-Namen identisch. Vergleicht man ein solches Interface mit einer Tür, dann gleicht die Adresse dem an ihr befestigten Namensschild.

Natürlich können noch weitere Parameter des Geräts eingestellt werden. Einer dieser Parameter ist die maximale Größe der Datagramme, die von der Hardware verarbeitet werden können. Diese Größe wird auch als Maximum Transfer Unit oder MTU bezeichnet. Andere Attribute werden später eingeführt. Zum Glück haben die meisten Attribute sinnvolle Vorgabewerte.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Adressen Wie bereits in Kapitel 1 Einführung in das Arbeiten mit Netzwerken, erwähnt, bestehen die vom IPNetzwerkprotokoll verstandenen Adressen aus 32-Bit-Zahlen. Jeder Maschine muß eine für die Netzwerkumgebung eindeutige Adresse zugewiesen werden.1 Wenn Sie ein lokales Netzwerk betreiben, das keine Verbindung zu anderen Netzwerken unterhält, können Sie diese Adressen nach Ihren Wünschen frei vergeben. Einige IP-Adressen sind nur für private Netzwerke reserviert. Die Nummern sind in Tabelle 2.1 angegeben. Für Sites im Internet werden die Nummern dagegen von einer zentralen Stelle, dem Network Information Center (NIC), vergeben.2 Zur einfacheren Lesbarkeit werden IP-Adressen in vier 8-Bit-Zahlen aufgeteilt, die man Oktette nennt. Beispielsweise hat quark.physics.groucho.edu die IP-Adresse 0x954C0C04, was als 149.76.12.4 geschrieben wird. Diese Schreibweise wird häufig als Dotted Quad Notation bezeichnet. Ein weiterer Grund für diese Notation ist, daß sich IP-Adressen aus einer Netzwerknummer in den führenden Oktetten und aus einer Hostnummer dahinter zusammensetzen. Wenn Sie beim NIC IPAdressen beantragen, wird Ihnen nicht einfach eine bestimmte Adresse für jeden einzelnen Host zugewiesen, den Sie einbinden wollen, sondern Sie erhalten eine Netzwerknummer und dürfen innerhalb dieser Grenzen jede gültige IP-Adresse verwenden. Die Länge des Hostanteils hängt von der Größe des Netzwerkes ab. Um diesen unterschiedlichen

Bedürfnissen entgegenzukommen, gibt es unterschiedliche Netzwerk-klassen, die unterschiedliche Aufteilungen von IP-Adressen definieren. Die Netzwerkklassen werden im folgenden beschrieben: Klasse A Klasse A umfaßt Netzwerke von 1.0.0.0 bis 127.0.0.0. Die Netzwerknummer ist im ersten Oktett enthalten. Es steht also ein 24 Bit langer Hostanteil zur Verfügung, was für ca. 16 Millionen Hosts ausreicht. Klasse B Klasse B umfaßt die Netzwerke 128.0.0.0 bis 191.255.0.0. Die Netzwerknummer ist in den ersten beiden Oktetten enthalten. Das ermöglicht 16.384 Netze mit jeweils 64.516 Hosts. Klasse C Klasse C umfaßt die Netzwerke 192.0.0.0 bis 223.255.255.0. Die Netzwerknummer steht in den ersten drei Oktetten. Das gestattet mehr als 2 Millionen Netzwerke mit bis zu 254 Hosts. Klassen D, E und F Adressen, die im Bereich von 224.0.0.0 bis 254.0.0.0 liegen, sind entweder experimenteller Natur oder für zukünftige Verwendungen reserviert und spezifizieren kein Netzwerk. In diesen Bereich fällt IP-Multicast. Dabei handelt es sich um ein Internet-Protokoll, das es ermöglicht, Informationen an mehrere Stellen gleichzeitig zu übertragen. Wenn Sie zu unserem Beispiel in Kapitel 1 zurückkehren, sehen Sie, daß 149.76.12.4, die Adresse von quark, auf den Hostrechner 12.4 im Klasse-B-Netzwerk 149.76.0.0 -verweist. Sie werden vielleicht bemerkt haben, daß in der obigen Liste nicht alle möglichen Werte für jedes Oktett des Hostanteils verwendet werden dürfen. Der Grund dafür liegt darin, daß die Oktetts 0 und 255 für spezielle Zwecke reserviert sind. Eine Adresse, bei der der Hostanteil nur aus Nullen besteht, steht für das Netzwerk. Sind alle Bits des Hostanteils auf 1 gesetzt, spricht man von einer BroadcastAdresse. Daten, die an diese Adresse geschickt werden, werden gleichzeitig von allen Hosts in dem angegebenen Netzwerk empfangen. 149.76.255.255 ist also keine gültige Hostadresse, sondern steht für alle Hosts im Netzwerk 149.76.0.0. Manche Netzwerkadressen sind für besondere Zwecke reserviert, zum Beispiel 0.0.0.0 und 127.0.0.0. Die erste Adresse ist die sogenannte Default-Route, die zweite die Loopback-Adresse. Die DefaultRoute hat etwas damit zu tun, wie IP Datagramme routet. Das Netzwerk 127.0.0.0 ist für den IP-Verkehr reserviert, der lokal auf Ihrem Host stattfindet. Üblicherweise wird die Adresse 127.0.0.1 einem speziellen Interface auf Ihrem Host, dem sogenannten Loopback-Interface, zugewiesen, das wie ein geschlossener Kreis funktioniert. Jedes von TCP oder UDP dorthin übergebene Paket wird direkt von dort zurückgegeben, als wäre es gerade von

einem anderen Netzwerk angekommen. Auf diese Weise können Sie Netzwerksoftware entwickeln und testen, ohne jemals ein “echtes” Netzwerk verwenden zu müssen. Eine andere sinnvolle Anwendung ergibt sich beim Einsatz von Netzwerksoftware auf einem Host, der nicht vernetzt ist. Das ist gar nicht so ungewöhnlich, wie es klingt. Beispielsweise verfügen viele UUCP-Sites gar nicht über IP-Connectivity, wollen aber trotzdem das INN-News-System einsetzen. Für den korrekten Betrieb unter Linux benötigt INN das Loopback-Interface. Einige Adressenbereiche jeder Netzwerkklassen gelten als “reserviert” oder “privat”. Diese Adressen sind für die Anwendung in privaten Netzwerken bestimmt und werden im Internet nicht geroutet. In der Regel werden sie von Organisationen benutzt, die ihr eigenes Intranet aufbauen. Aber sie werden häufig auch für kleinere Netzwerke verwendet. Die reservierten Netzwerkadressen können Tabelle 2.1 entnommen werden. Tabelle 2.1: Für private Zwecke reservierte IP-Adressenbereiche Klasse Netzwerke A

10.0.0.0 bis 10.255.255.255

B

172.16.0.0 bis 172.31.0.0

C

192.168.0.0 bis 192.168.255.0

1.

Im Internet wird am häufigsten die Version 4 des IP-Protokolls eingesetzt. Mit großem Aufwand wurde kürzlich die Entwicklung eines Nachfolgeprotokolls vorangetrieben, das als IP, Version 6, bezeichnet wird. IPv6 verwendet ein etwas anderes Adressierungsschema und längere Adressen. Linux besitzt bereits eine Implementierung von IPv6. Sie ist jedoch noch unvollständig dokumentiert und wird daher in diesem Buch nicht näher erläutert. Der Linux-Kernel-Support für IPv6 ist gut, aber eine Vielzahl von Netzwerkapplikationen muß noch darauf angepaßt werden. Haben Sie also noch etwas Geduld!

2.

Häufig werden Ihnen die IP-Adressen auch vom Provider zugewiesen, von dem Sie die IPConnectivity einkaufen. Sie können sich aber auch direkt an das NIC wenden, um eine IP-Adresse für Ihr Netzwerk zu beantragen. Senden Sie dazu einfach eine Mail an [email protected], oder füllen Sie das Formular unter http://www.internic.net/ aus.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Auflösung von IP-Adressen Nachdem Sie nun gesehen haben, wie IP-Adressen aufgebaut sind, werden Sie sich vielleicht fragen, wie diese Adressen in einem Ethernet oder Token Ring benutzt werden, um unterschiedliche Hosts anzusprechen. Schließlich verwenden diese Protokolle ja ihre eigenen Adressen, um Hosts zu identifizieren, die absolut nichts mit einer IP-Adresse gemeinsam haben, nicht wahr? Richtig. Darum benötigen wir auch einen Mechanismus, der IP-Adressen auf die Adressen des zugrundeliegenden Netzwerks abbildet. Der eingesetzte Mechanismus heißt Address Resolution Protocol (ARP). Tatsächlich ist ARP nicht allein auf Ethernet oder Token Ring beschränkt, sondern wird auch bei anderen Netzwerkarten wie dem Amateurfunk-AX.25-Protokoll (kurz Ham-Radio) verwendet. Die ARP zugrundeliegende Idee entspricht genau dem, was die meisten Leute tun, wenn sie einen ihnen unbekannten Menschen, nennen wir ihn einfach mal Mister X, in einer Gruppe von 150 Menschen herausfinden müssen: Sie gehen herum und rufen laut den Namen, in der Hoffnung, daß er sich meldet. Wenn ARP die Ethernet-Adresse ermitteln möchte, die zu einer IP-Adresse gehört, verwendet es eine Ethernet-Eigenschaft, die als Broadcasting bekannt ist. Dabei wird ein Datagramm gleichzeitig an alle Stationen im Netzwerk geschickt. Das von ARP gesendete Broadcast-Datagramm enthält eine Anfrage zur IP-Adresse. Jeder empfangende Host überprüft daraufhin seine eigene Adresse. Stimmt diese mit der empfangenen Adresse überein, wird eine ARP-Antwort an den anfragenden Host

zurückgeschickt. Der empfangende Host kann nun aus dieser Antwort die Ethernet-Adresse des Senders extrahieren. Sie werden sich nun vielleicht wundern, wie ein Host eine Internetadresse ansprechen kann, die sich in einem anderen Netzwerk am Ende der Welt befindet bzw. woher der Host überhaupt weiß, daß die Adresse in einem bestimmten Netzwerk liegt. All diese Fragen führe Diese Frage führt uns zum sogenannten Routing, also dem Ermitteln des physikalischen Standorts eines Host im Netzwerk. Das ist das Thema des folgenden Abschnitts. Lassen Sie uns aber zuvor noch etwas mehr über ARP reden. Hat ein Host erst einmal eine EthernetAdresse herausgefunden, speichert er diese im ARP-Cache. Auf diese Weise muß keine erneute Anfrage gestartet werden, wenn beim nächsten Mal ein Datagramm an den fraglichen Host geschickt werden soll. Nun wäre es aber nicht besonders klug, diese Information für immer zu speichern. Zum Beispiel könnte die Ethernet-Karte des anderen Host aufgrund technischer Probleme ausgetauscht werden müssen, und somit wäre der ARP-Eintrag ungültig. Darum werden die Einträge im ARPCache nach einiger Zeit gelöscht, um eine erneute Anfrage nach der IP-Adresse zu erzwingen. Manchmal ist es auch notwendig, die IP-Adresse zu einer bestimmten Ethernet-Adresse zu ermitteln. Das passiert beispielsweise, wenn ein Rechner ohne eigenes Diskettenlaufwerk von einem Server über das Netzwerk gebootet werden soll, eine sehr häufige Situation in lokalen Netzwerken. Ein solcher Client verfügt über nahezu keine Informationen über sich selbst — mit Ausnahme seiner EthernetAdresse! Also sendet er eine Broadcast-Nachricht mit der Bitte an alle Boot-Server, ihm seine IPAdresse mitzuteilen. Dazu existiert ein weiteres Protokoll namens Reverse Address Resolution Protocol (RARP). Zusammen mit dem BOOTP-Protokoll dient es dem Booten von Clients ohne Laufwerk über das Netz.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Routing Wir greifen nun noch einmal die Frage auf, wie der Host, an den Pakete geschickt werden sollen, anhand der IP-Adresse gefunden wird. Verschiedene Teile der Adresse werden auf unterschiedliche Weise gehandhabt; es ist Ihre Aufgabe, entsprechende Dateien einzurichten, die angeben, wie die unterschiedlichen Teile zu handhaben sind.

IP-Netzwerke Wenn Sie einen Brief an jemanden schreiben, versehen Sie den Briefumschlag üblicherweise mit der kompletten Adresse (Land, Postleitzahl, Straße etc.). Dann werfen Sie ihn in den Briefkasten, und die Post liefert ihn ans Ziel, d.h., er wird in das angegebene Land geschickt, wo die nationale Post ihn an die angegebene Adresse zustellt. Der Vorteil dieses hierarchischen Schemas ist offensichtlich: An welchem Ort auch immer Sie den Brief aufgeben, der lokale Postangestellte weiß ungefähr, in welche Richtung er den Brief weiterleiten soll, muß sich aber nicht darum kümmern, welchen Weg der Brief nimmt, wenn dieser erstmal das Zielland erreicht hat. IP-Netzwerke sind auf dieselbe Art und Weise strukturiert. Das gesamte Internet besteht aus einer Reihe von Netzwerken, die als autonome Systeme bezeichnet werden. Jedes System führt das Routing zwischen den teilnehmenden Hosts intern durch, d.h., die Aufgabe der Auslieferung eines Datagramms wird auf die Suche nach einem Pfad zum Netzwerk des Zielhosts reduziert. Sobald ein

Datagramm an einen beliebigen Host innerhalb eines Netzwerks übergeben ist, wird die weitere Verarbeitung ausschließlich von diesem Netz übernommen.

Subnetze Diese Struktur spiegelt sich darin wieder, daß IP-Adressen, wie oben erwähnt, in einen Host- und einen Netzwerkteil aufgeteilt werden. Per Voreinstellung wird das Zielnetzwerk aus dem Netzwerkteil der IP-Adresse gewonnen. Hosts mit identischen IP-Netzwerknummern sollten innerhalb desselben Netzwerks zu finden sein, und alle Hosts innerhalb eines Netzwerks sollten dieselbe Netzwerknummer besitzen.1 Es macht Sinn, innerhalb des Netzwerks dasselbe Schema zu verwenden, weil es selbst wieder aus Hunderten kleinerer Netzwerke bestehen kann, bei denen die kleinsten Einheiten physische Netzwerke wie Ethernets sind. Aus diesem Grund erlaubt IP die Unterteilung eines IP-Netzwerks in mehrere Subnetze. Ein Subnetz übernimmt die Verantwortung für die Übertragung von Datagrammen innerhalb eines bestimmten Bereichs von IP-Adressen des IP-Netzes, dem es angehört. Genau wie bei den Klassen A, B und C wird es über den Netzwerkteil der IP-Adressen identifiziert. Allerdings wird der Netzwerkteil etwas erweitert und enthält nun einige Bits aus dem Hostteil. Die Anzahl der Bits, die als Subnetznummer interpretiert werden, wird durch die sogenannte Subnetzmaske, oder kurz Netzmaske, bestimmt. Diese ist ebenfalls eine 32-Bit-Zahl, die die Bitmaske für den Netzwerkteil der IP-Adresse festlegt. Das Netzwerk an der Groucho-Marx-Universität ist ein Beispiel für ein solches Netzwerk. Es verwendet die Klasse-B-Netzwerknummer 149.76.0.0, und die Netzmaske lautet somit 255.255.0.0. Intern besteht das Universitätsnetz aus verschiedenen kleineren Netzwerken, wie beispielsweise den LANs der verschiedenen Institute. Also werden die IP-Adressen noch einmal in 254 Subnetze, von 149.76.1.0 bis 149.76.254.0, unterteilt. Dem Institut für theoretische Physik wurde beispielsweise die Nummer 149.76.12.0 zugeteilt. Der Universitäts-Backbone ist ein eigenständiges Netzwerk und besitzt die Nummer 149.76.1.0. Diese Subnetze verwenden dieselbe IP-Netzwerknummer, während gleichzeitig das dritte Oktett verwendet wird, um sie unterscheiden zu können. Sie verwenden also die Subnetzmaske 255.255.255.0. Abbildung 2.1 zeigt, wie 149.76.12.4, die Adresse von quark, verschieden interpretiert wird, wenn ein normales Klasse-B-Netzwerk vorliegt bzw. Subnetze verwendet werden. Abbildung 2.1: Subnetz bei Klasse-B-Netzwerk

Es ist wichtig, festzuhalten, daß die Unterteilung in Subnetze nur eine interne Aufteilung des Netzwerks ist. Subnetze werden vom Besitzer (oder Administrator) des Netzwerks aufgebaut. Häufig werden Subnetze gebildet, um bestehende Grenzen widerzuspiegeln. Diese Grenzen können physischer (zwei Ethernet-Netze), administrativer (zwei Institute) oder geographischer Natur sein. Die Verantwortung für ein Subnetz wird an eine Kontaktperson delegiert. Diese Struktur wirkt sich allerdings nur auf das interne Verhalten des Netzwerks aus und ist nach außen hin völlig unsichtbar.

Gateways Das Anlegen von Subnetzen ist nicht nur organisatorisch von Vorteil, es ist häufig auch die natürliche Konsequenz aus bestehenden Hardwaregrenzen. Die Sichtweise eines Hosts in einem bestehenden Netzwerk, beispielsweise einem Ethernet, ist sehr eingeschränkt: Die einzigen Hosts, mit denen er sich unterhalten kann, sind die Hosts, die sich in dem gleichen Netz befinden wie er selbst. Alle anderen Hosts können nur über sogenannte Gateways erreicht werden. Ein Gateway ist ein Host, der an zwei oder mehr physische Netze gleichzeitig angeschlossen ist. Er ist so konfiguriert, daß er Pakete zwischen diesen Netzen übertragen kann. Abbildung 2.2 zeigt einen Ausschnitt der Netzwerk-Topologie an der Groucho-Marx-Universität (GMU). Hosts, die auf zwei Subnetzen zur gleichen Zeit präsent sind, sind mit beiden Adressen aufgeführt. Damit IP feststellen kann, ob ein Host in einem lokalen Netzwerk präsent ist, müssen verschiedene physikalische Netzwerke verschiedenen IP-Netzwerken angehören. Beispielsweise ist die Netzwerknummer 149.76.4.0 für die Hosts des LANs des mathematischen Instituts reserviert. Wird ein Datagramm an quark geschickt, erkennt die Netzwerksoftware auf erdos sofort anhand der IPAdresse 149.76.12.4, daß der Zielhost sich in einem anderen physikalischen Netzwerk befindet und daher nur durch ein Gateway erreicht werden kann (sophus per Voreinstellung). sophus selbst ist mit zwei verschiedenen Subnetzen verbunden: mit dem des mathematischen Instituts und dem des Universitäts-Backbones. Jedes wird über ein eigenes Interface (eth0 bzw. fddi0) erreicht. Nun, welche IP-Adresse sollen wir ihm zuweisen? Sollen wir ihm eine auf dem Subnetz 149.76.1.0

oder auf 149.76.4.0 zuweisen? Abbildung 2.2: Ausschnitt der Netzwerk-Topologie an der Groucho-Marx-Universität

Die Antwort lautet: auf beiden. sophus wurde die Adresse 149.76.1.1 für das Netzwerk 149.76.1.0 und die Adresse 149.76.4.1 für das Netzwerk 149.76.4.0 zugewiesen. Einem Gateway wird also für jedes Netzwerk, dem es angehört, eine IP-Adresse zugewiesen. Diese Adressen — zusammen mit der entsprechenden Netzmaske — ergeben gemeinsam die Schnittstelle, über die auf das Subnetz zugegriffen wird. Die Abbildung von Schnittstellen auf Adressen für sophus würde also wie folgt aussehen:

Schnittstelle Adresse

Netzmaske

eth0

149.76.4.1 255.255.255.0

fddi0

149.76.1.1 255.255.255.0

lo

127.0.0.1 255.0.0.0

Der letzte Eintrag beschreibt das Loopback-Interface lo, das bereits vorgestellt wurde. Im allgemeinen können Sie den feinen Unterschied zwischen der Zuweisung einer Adresse an einen Host oder an sein Interface ignorieren. Bei Hosts wie erdos, die nur zu einem Netz gehören, spricht man im allgemeinen immer von dem Host mit dieser oder jener IP-Adresse, obwohl es genaugenommen die Ethernet-Schnittstelle ist, der diese IP-Adresse zugewiesen wurde. Andererseits ist diese Unterscheidung nur bei Gateways wirklich von Bedeutung.

Die Routing-Tabelle Wir richten nun unsere Aufmerksamkeit darauf, wie IP ein Gateway auswählt, wenn es ein Datagramm an ein entferntes Netzwerk ausliefert. Wir haben bereits gesehen, daß erdos bei einem Datagramm für quark die Zieladresse überprüft und entdeckt, daß sich diese nicht im lokalen Netz befindet. Aus diesem Grund sendet erdos das Datagramm an das Default-Gateway (sophus), das sich nun vor die gleiche Aufgabe gestellt sieht. sophus erkennt, daß sich quark nicht in einem der Netzwerke befindet, mit denen es direkt verbunden ist. Es muß also ein weiteres Gateway finden, an das es das Datagramm weiterleiten kann. Die richtige Wahl wäre niels, das Gateway des physikalischen Instituts. Daher benötigt sophus einige Informationen, um zu wissen, welche Zielnetze über welche Gateways zu erreichen sind. Die Routing-Informationen, die IP dabei verwendet, sind in einer Tabelle zu finden, die Netzwerke mit Gateways verbindet, über die sie zu erreichen sind. Ein sogenannter Catch-All-Eintrag (die Default-Route) muß ebenfalls vorhanden sein. Dieses Gateway wird mit dem Netzwerk 0.0.0.0 assoziiert. Alle möglichen Zieladressen stimmen mit diesem Adreßmuster überein, da keines der 32 Bits passen muß. Deshalb werden alle Pakete, die an ein unbekanntes Netzwerk gehen, über dieses Gateway verschickt. Auf sophus würde die Tabelle also wie folgt aussehen: Netzwerk Netzmaske

Gateway Schnittstelle

149.76.1.0 255.255.255.0 -

fddi0

149.76.2.0 255.255.255.0 149.76.1.2 fddi0 149.76.3.0 255.255.255.0 149.76.1.3 fddi0 149.76.4.0 255.255.255.0 -

eth0

149.76.5.0 255.255.255.0 149.76.1.5 fddi0 …

…

…

…

0.0.0.0

0.0.0.0

149.76.1.2 fddi0

Routen zu einem Netzwerk, mit dem sophus direkt verbunden ist, benötigen kein Gateway. In der Gateway-Spalte steht an dieser Stelle ein Bindestrich. Der Test, ob eine bestimmte Zieladresse zu einer gegebenen Route paßt, ist eine mathematische Operation. Der Vorgang ist zwar relativ einfach, erfordert jedoch Grundkenntnisse in binärer Arithmetik und Logik. Zunächst wird aus der Netzadresse und der Netzmaske eine logische UNDVerknüpfung gebildet. Auf dieselbe Weise wird dann eine logische UND-Verknüpfung der Zieladresse mit der Netzmaske vollzogen. Die Route paßt genau dann zur Zieladresse, wenn beide Resultate identisch sind. Mit anderen Worten: Die Route paßt, wenn diejenigen Bits der Netzadresse, die durch die Netzmaske angegeben werden (beginnend mit dem am weitesten links stehenden Bit, also dem höchstwertigen Bit im ersten Byte der Adresse), mit den gleichen Bits in der Zieladresse übereinstimmen. Wenn die IP-Implementierung nach der besten Route zu einem Ziel sucht, kann es -vorkommen, daß sie mehrere passende Routen findet. Wir wissen z.B., daß die Default-Route zu jeder Zieladresse paßt, während die Adressen von Datagrammen für Netzwerke, an die der Host direkt angeschlossen ist, auch auf lokale Routing-Einträge passen. Wie stellt IP nun fest, welche Route verwendet werden soll? Hier spielt die Netzmaske eine wichtige Rolle. Zwar passen beide Routen zur Zieladresse, jedoch hat die eine Route eine größere Netzmaske als die andere. Wir hatten bereits erwähnt, daß die Netzmaske dazu dient, unseren Adreßraum in kleinere Netzwerke aufzuspalten. Je größer eine Netzmaske ist, desto genauer wird die Zieladresse durch sie bestimmt. Werden Datagramme geroutet, sollte immer die Route mit der größten Netzmaske gewählt werden. Die Netzmaske der Default-Route besteht immer aus Nullbits, während die lokalen Netzwerke in der oben präsentierten Konfiguration eine 24Bit-Netzmaske haben. Ein Datagramm, das sowohl zu einem lokalen Netzwerk als auch zur DefaultRoute paßt, wird immer bevorzugt an das zuständige lokale Device weitergeleitet, da eine lokale Netzwerk-Route immer eine größere Netzmaske hat als die Default-Route. Die Datagramme, die über die Default-Route weitergeleitet werden, sind immer diejenigen, die nicht zu den anderen Routen passen. Routing-Tabellen können auf unterschiedliche Weise aufgebaut werden. Bei kleineren LANs ist es wahrscheinlich am effektivsten, die Tabelle von Hand zu erstellen und sie dann während der BootPhase mit Hilfe des route-Befehls (siehe Kapitel 5 TCP/IP-Konfiguration) an IP zu übergeben. Bei größeren Netzwerken werden sie zur Laufzeit von sogenannten Routing-Dämonen erzeugt und eingerichtet. Diese Dämonen laufen auf zentralen Hosts des Netzwerks und tauschen untereinander Routing-Informationen aus, um die “optimalen” Routen zwischen den teilnehmenden Netzwerken zu berechnen. Abhängig von der Größe des Netzwerks werden verschiedene Routing-Protokolle -verwendet. Für das Routing innerhalb autonomer Systeme (wie der Groucho-Marx-Universität) werden die internen Routing-Protokolle verwendet. Das bekannteste dieser Protokolle ist RIP, oder Routing Information Protocol, das im BSD-routed-Dämon implementiert ist. Das Routing zwischen autonomen Systemen muß durch externe Routing-Protokolle wie EGP (External Gateway Protocol) oder BGP (Border

Gateway Protocol) erledigt werden. Diese wurden (ebenso wie RIP) im gated-Dämon der University of Cornell implementiert.

Metrische Werte Beim auf RIP basierenden dynamischen Routing wird der beste Weg zu einem Zielhost oder Netzwerk anhand der Anzahl der “Hops” gewählt, d.h. anhand der Anzahl von Gateways, die ein Datagramm passieren muß, bevor es sein Ziel erreicht hat. Je kürzer die Route ist, desto besser wird sie von RIP bewertet. Sehr lange Routen von 16 oder mehr Hops werden als unbrauchbar betrachtet und verworfen. Soll RIP verwendet werden, um die für Ihr lokales Netzwerk anfallenden Routing-Informationen zu verwalten, muß auf allen Hosts gated laufen. Während des Bootens prüft gated alle aktiven NetzwerkInterfaces. Existiert mehr als eine aktive Schnittstelle (das Loopback-Interface nicht mitgezählt), nimmt es an, daß der Host als Gateway fungiert, und gated verteilt aktiv Routing-Informationen. Andernfalls verhält es sich passiv und empfängt nur eingehende RIP-Updates, um die lokale RoutingTabelle zu aktualisieren. Wenn gated die Daten aus der lokalen Routing-Tabelle verteilt, berechnet es die Länge der Route anhand einer sogenannten Metrik, die Teil des Eintrags in der Routing-Tabelle ist. Dieser Wert wird vom Systemadministrator während der Konfiguration der Route eingetragen und sollte die Kosten bezüglich der Verwendung dieser Route widerspiegeln.2 Die Metrik einer Route zu einem Subnetz, mit dem der Host direkt verbunden ist, sollte also immer null sein, während ein Weg, der über zwei Gateways führt, einen Wert von zwei haben sollte. Andererseits müssen Sie sich um diese Werte keine Gedanken machen, wenn Sie RIP oder gated nicht verwenden.

1.

Autonome Systeme sind noch etwas allgemeiner. Sie können mehr als ein Netzwerk umfassen.

2.

Im einfachsten Fall ergeben sich die Kosten z.B. aus der Anzahl der Hops, die bis zum Ziel übersprungen werden müssen. Eine gründliche Kostenanalyse in komplexen Netzwerkarchitekturen ist dagegen schon eine Wissenschaft für sich.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Das Internet Control Message Protocol IP hat noch ein verwandtes Protokoll, über das wir bisher noch nicht gesprochen haben. Dieses Internet Control Message Protocol (ICMP) wird vom Netzwerkcode des Kernel verwendet, um Fehlermeldungen und ähnliches an andere Hosts weiterzugeben. Nehmen wir beispielsweise an, daß Sie mal wieder vor erdos sitzen und über telnet auf Port 12345 auf quark zugreifen wollen. Leider existiert dort kein Prozeß, der an diesem Port horcht. Wenn das erste TCP-Paket für diesen Port bei quark ankommt, erkennt die Netzwerkschicht dies sofort und sendet umgehend eine ICMP-Nachricht an erdos zurück, um mitzuteilen, daß der Port nicht erreichbar ist (“Port Unreachable”). ICMP stellt verschiedene Nachrichten zur Verfügung, von denen viele Fehlerbedingungen behandeln. Darunter befindet sich auch eine sehr interessante Nachricht namens “Redirect”. Diese wird vom Routing-Modul erzeugt, wenn es erkennt, daß es von einem anderen Host als Gateway verwendet wird, obwohl es einen wesentlich kürzeren Weg gibt. Beispielsweise könnte die Routing-Tabelle von sophus nach dem Booten unvollständig sein. Die Tabelle könnte die Routen zum Mathe-Netzwerk, dem FDDI-Backbone und die Default-Route enthalten, die auf das Gateway gcc1 des UniversitätsRechenzentrums weist. Alle Pakete, die für quark bestimmt sind, würden also an gcc1 geschickt werden und nicht an niels, das Gateway des physikalischen Instituts. Empfängt es ein solches Datagramm, bemerkt gcc1, daß dies eine ungünstige Route ist, und leitet das Paket an niels weiter, während gleichzeitig eine ICMP-Redirect-Nachricht an sophus gesandt wird, die dem Rechner die bessere Route mitteilt.

Nun sieht das vielleicht nach einer sehr cleveren Methode aus, mit der Sie es vermeiden können, alle außer den grundlegenden Routen von Hand einzutragen. Seien Sie aber gewarnt, daß es nicht immer eine gute Idee ist, sich auf dynamische Routing-Schemata zu verlassen – egal, ob RIP oder ICMPRedirects. ICMP-Redirect und RIP bieten Ihnen gar keine oder nur geringe Möglichkeiten, die Authentizität der empfangenen Routing-Informationen zu überprüfen. Auf diese Weise könnten bösartige Taugenichtse Ihr -gesamtes Netz lahmlegen oder noch schlimmeres tun. Aus diesem Grund behandelt der Netzwerkcode des Linux-Kernels Redirect-Messages für Netzwerkrouten so, als wären es nur Redirects für Hostrouten.Dies verringert die Zerstörungsgefahr bei einem Angriff, indem es ihn auf einen einzigen Host beschränkt und dadurch der Rest des Netzwerks verschont bleibt. Auf der anderen Seite bedeutet dies aber, daß durch die Sicherheitsüberprüfung, die jeden Host zur Erzeugung eines ICMP-Redirects veranlaßt, der Netzwerkverkehr umfangreicher wird. In Anbetracht der heutigen Datenflut ist es daher nicht ratsam, für jeden denkbaren Anwendungsfall ICMP-Redirects einzusetzen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Auflösung von Hostnamen Wie bereits beschrieben, dreht sich bei der Adressierung von TCP/IP-Netzwerken alles um 32-BitZahlen. Es wird Ihnen aber wahrscheinlich schwerfallen, sich mehr als ein paar dieser Nummern zu merken. Aus diesem Grund sind Hosts im allgemeinen unter einem “normalen” Namen wie gauss oder strange bekannt. Es gehört zu den Aufgaben der Anwendung, die zu diesem Namen gehörende IP-Adresse zu ermitteln. Dieser Prozeß wird als »Auflösung des Hostnamens« oder Hostname Resolution bezeichnet. Muß ein Programm die IP-Adresse eines bestimmten Host ermitteln, ist es auf die Bibliotheksfunktionen gethostbyname(3) und gethostbyaddr(3) angewiesen. Diese und eine Reihe verwandter Funktionen werden traditionell in einer separaten Bibliothek (der sog. Resolver Library) gespeichert, unter Linux sind sie aber Teil der Standard-libc-Bibliothek. Im allgemeinen Sprachgebrauch wird diese Sammlung von Funktionen “der Resolver” genannt. Ihre Konfiguration wird in Kapitel 6 Name-Server- und Resolver-Konfiguration, näher beschrieben. Nun ist es bei einem kleinen Netzwerk wie einem Ethernet, ja selbst bei einem Cluster solcher Netze, nicht besonders schwer, die Tabellen zu verwalten, mit denen die Hostnamen auf Adressen abgebildet werden. Diese Informationen werden üblicherweise in einer Datei namens /etc/hosts gespeichert. Wenn Sie einen Host hinzufügen oder entfernen, müssen Sie nur die hosts-Dateien auf allen Hosts entsprechend korrigieren. Das wird natürlich sehr mühsam in Netzwerken, die sich aus mehr als einer

Handvoll Rechnern zusammensetzen. Eine Lösung für dieses Problem ist das von Sun Microsystems entwickelte NIS, oder Network Information System, das im allgemeinen Sprachgebrauch auch YP oder Yellow Pages (also “Gelbe Seiten”) genannt wird. NIS speichert die hosts-Datei (und andere Informationen) in einer Datenbank auf einem Masterhost, von dem Clients die Informationen bei Bedarf abrufen. Dennoch ist diese Lösung nur bei Netzwerken mittlerer Größe, z.B. LANs, anwendbar, weil sie die Verwaltung der gesamten hosts-Datenbank durch eine zentrale Instanz erfordert, von der aus die Daten dann an alle Server verteilt werden müssen. Die Installation und Konfiguration von NIS ist in Kapitel 13 Das Network Information System, detailliert beschrieben. Auch im Internet wurden zu Beginn alle Adreß-Informationen in einer einzigen Datenbank namens HOSTS.TXT gespeichert. Diese Datei wurde vom Network Information Center (NIC) verwaltet und mußte von allen teilnehmenden Sites heruntergeladen und installiert werden. Als das Netz wuchs, machten sich die Nachteile dieses Schemas bemerkbar. Neben dem administrativen Aufwand, der mit der regelmäßigen Installation von HOSTS.TXT verbunden war, wurde die Last auf den diese Datei verteilenden Servern zu hoch. Noch schwerwiegender war das Problem, daß alle Namen beim NIC registriert werden mußten, um sicherzustellen, daß Namen nicht doppelt verwendet wurden. Aus diesen Gründen wurde im Jahr 1984 ein neues Schema für die Auflösung von Adreß-Namen eingeführt, das sogenannte Domain Name System. DNS wurde von Paul Mockapetris entwickelt und widmete sich beiden Problemen zur gleichen Zeit. Es wird ausführlich in Kapitel 6 Name-Server- und Resolver-Konfiguration, beschrieben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 3 Konfiguration der Netzwerkhardware

Bis jetzt haben wir uns ziemlich ausführlich mit Netzwerkschnittstellen und allgemeinen Fragen der TCP/IP-Protokolle befaßt, ohne uns groß darum zu kümmern, was eigentlich genau passiert, wenn “der Netzwerkcode” im Kernel ein Stück Hardware anspricht. Bevor wir das jetzt nachholen, müssen wir noch ein wenig über das Konzept der Schnittstellen und Treiber sprechen. Zuallererst ist da natürlich die Hardware selbst, zum Beispiel eine Ethernet-, FDDI- oder Token-Ring-Karte. Das ist eine Leiterplatte voller kleiner Chips mit komischen Nummern drauf, das in einem Steckplatz Ihres PC sitzt. Das ist, was wir allgemein ein physisches Gerät nennen (device). Um eine Netzwerkkarte benutzen zu können, müssen in Ihrem Linux-Kernel spezielle Funktionen vorhanden sein, die in der Lage sind, das Gerät anzusprechen. Diese Gruppe von Funktionen nennt man Gerätetreiber (device driver). Linux besitzt viele Treiber für unterschiedliche Typen von Netzwerkkarten: ISA, PCI, MCA, EISA, Parallelport, PCMCIA und neuerdings auch USB. Aber was meinen wir eigentlich, wenn wir sagen, ein Treiber “bedient” ein Gerät? Nehmen wir doch mal eine Ethernet-Karte. Der Treiber muß in der Lage sein, mit den Logikbausteinen auf der Karte zu kommunizieren, während die Karte umgekehrt

alle empfangenen Daten irgendwie beim Treiber abliefern muß. In IBM-kompatiblen PCs findet diese Kommunikation durch einen speziellen Speicherbereich, der auf I/O-Register auf der Karte abgebildet wird, und/oder über gemeinsam genutze Speicherbereiche oder durch direkten Speichertransfer (direct memory access, kurz DMA) statt. Alle Befehle und Daten, die der Kernel an die Karte schickt, müssen an diese Adressen übermittelt werden. I/O- und Speicheradressen werden im allgemeinen mit ihrer Start- oder Basisadresse angegeben. Typische Basisadressen für Ethernet-Karten am ISA-Bus sind 0x280 oder 0x300. Netzwerkkarten am PCI-Bus erhalten ihre I/OAdressen automatisch zugewiesen. Normalerweise brauchen Sie sich über solche Details wie Basisadressen nicht den Kopf zu zerbrechen, da der Kernel beim Booten versucht, die Position der Karte selbst herauszufinden. Dieser Vorgang heißt Autoprobing, was bedeutet, daß der Kernel verschiedene Speicheradressen ausliest und mit dem vergleicht, was herauskommen sollte, wenn eine bestimmte Ethernet-Karte installiert wäre. Allerdings kann es Ethernet-Karten geben, die der Kernel nicht automatisch erkennt; das ist bei manchen billigen Netzwerkkarten der Fall, die unvollständige Nachbildungen von Netzwerkkarten anderer Hersteller sind. Außerdem gibt sich der Kernel beim Booten schon zufrieden, wenn er nur eine Karte gefunden hat; wenn Sie mehr als eine verwenden wollen, müssen Sie diese Karten von Hand konfigurieren. Ein anderer Parameter, den Sie dem Kernel unter Umständen mitteilen müssen, ist der Interrupt-Kanal. Hardwarekomponenten schicken dem Kernel gewöhnlich eine Unterbrechungsanforderung, wenn sie seine Aufmerksamkeit benötigen, z.B. wenn Daten angekommen sind oder ein besonderer Zustand auftritt. In ISA-Bus-PCs können solche Unterbrechungen auf einem von 15 Interrupt-Kanälen signalisiert werden, die die Nummern 0, 1 und 3 bis 15 haben. Die einem Interrupt zugeordnete Nummer wird im Englischen interrupt request number oder kurz IRQ genannt.1 Wie in Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, beschrieben, spricht der Kernel ein Gerät über eine sogenannte Schnittstelle oder Interface an. Interfaces bieten einen Satz abstrakter Funktionen, der für alle Arten von Hardware gleich ist, wie zum Beispiel das Senden oder Empfangen eines Datagramms. Jede Schnittstelle wird durch einen Namen bezeichnet. In vielen Unix-ähnlichen Betriebssystemen wird ein NetzwerkInterface in Form einer speziellen Gerätedatei im Verzeichnis /dev/ implementiert. Wenn Sie das Kommando ls -las /dev/ ausführen, erkennen Sie, wie diese Gerätedateien aussehen. In der (zweiten) Spalte der Dateiattribute fällt auf, daß Gerätedateien immer mit einem Buchstaben statt mit einem Minuszeichen beginnen, wie es bei den normalen Dateien der Fall ist. Dieses Zeichen markiert den Gerätetyp. Meistens ist das ein b, was auf ein Block-Device hinweist, das bei jeder Lese- und Schreibopera-tionen immer ganze Blöcke von Daten verarbeitet, oder ein c, was bedeutet, daß es sich hierbei um ein Character-Device handelt, das immer nur ein Zeichen zur Zeit verarbeitet. Wo man in der Ausgabe des ls-Befehls die Dateilänge zu Gesicht bekommt, erscheinen bei Gerätedateien zwei Zahlen, die sogenannten Major und Minor Numbers. Sie bezeichnen immer das eigentliche Gerät, mit dem die Gerätedatei verknüpft ist. Jeder Gerätetreiber erhält eine eindeutige Major Number vom Kernel. Jede Instanz eines solchen Geräts erhält außerdem eine eindeutige Minor Number. Die tty-Interfaces, /dev/tty*, sind zeichenorientierte Geräte, wie das “c” im Dateiattribut anzeigt, und besitzen die Major Number 4. /dev/tty1 hat die Minor Number 1, während /dev/tty2 die Minor Number 2 besitzt. Gerätedateien sind bei vielen Gerätetypen eine sehr nützliche Sache, allerdings etwas schwerfällig in der Handhabung, wenn es darum geht, ein Gerät zu ermitteln, das gerade frei ist. In Linux sind die Namen der Interfaces keine Gerätedateien im Verzeichnis /dev, sondern werden intern vom Kernel vergeben. Einige typische Gerätenamen werden später in Ein Überblick über die Netzwerkgeräte aufgelistet. Die Zuordnung von Schnittstellen und Geräten hängt gewöhnlich von der Reihenfolge ab, in der die Geräte konfiguriert werden. Zum Beispiel wird die erste installierte Ethernet-Karte zu eth0, die nächste zu eth1 und so weiter. Eine Ausnahme von dieser Regel sind unter anderem die SLIP-Schnittstellen, die dynamisch zugewiesen werden; das heißt, sobald eine SLIP-Verbindung hergestellt wurde, wird dem seriellen Port ein Interface zugewiesen. Abbildung 3.1 versucht, den Zusammenhang zwischen den Hardwarekomponenten, Gerätetreibern und Schnittstellen zu verdeutlichen. Abbildung 3.1: Zusammenhang zwischen den Gerätetreibern, Schnittstellen und der Hardware

Während des Boot-Vorgangs zeigt der Kernel an, welche Geräte er erkennt und welche Schnittstellen initialisiert werden. Das folgende ist ein Ausschnitt eines typischen Boot-Vorgangs: . . This processor honors the WP bit even when in supervisor mode./ Good. Swansea University Computer Society NET3.035 for Linux 2.0 NET3: Unix domain sockets 0.13 for Linux NET3.035. Swansea University Computer Society TCP/IP for NET3.034 IP Protocols: IGMP,ICMP, UDP, TCP Swansea University Computer Society IPX 0.34 for NET3.035 IPX Portions Copyright (c) 1995 Caldera, Inc. Serial driver version 4.13 with no serial options enabled tty00 at 0x03f8 (irq = 4) is a 16550A tty01 at 0x02f8 (irq = 3) is a 16550A CSLIP: code copyright 1989 Regents of the University of California PPP: Version 2.2.0 (dynamic channel allocation) PPP Dynamic channel allocation code copyright 1995 Caldera, Inc. PPP line discipline registered. eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 0e e4 e0,/ IRQ 10. 3c509.c:1.12 6/4/97 [email protected] Linux Version 2.0.32 (root@perf) (gcc Version 2.7.2.1) #1 Tue Oct 21 15:30:44 EST 1997 . .

Die Meldungen zeigen, daß der Kernel netzwerkfähig ist und Treiber für SLIP, CSLIP und PPP eingebunden wurden. Die dritte Zeile von unten besagt, daß eine Ethernet-Karte vom Typ 3C509 erkannt und als Interface eth0 installiert wurde. Wenn Sie eine Netzwerkkarte eines anderen Typs verwenden, z.B. einen D-Link-Pocket-Adapter, gibt der Kernel für gewöhnlich eine Meldung aus, die mit dem Gerätenamen beginnt, z.B. dl0, gefolgt vom Typ der erkannten Karte. Falls Sie eine Netzwerkkarte installiert haben, aber keine derartige Meldung sehen, bedeutet das, daß der Kernel nicht in der Lage war, Ihre Karte zu erkennen. Dieses Problem werden wir später im Abschnitt “Ethernet Autoprobing” behandeln.

1.

Die IRQs 2 und 9 bezeichnen denselben Kanal. Der PC besitzt zwei kaskadierte Interrupt-Bausteine mit jeweils 8 Kanälen, wobei der zweite Baustein mit IRQ2 des ersten verbunden ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kernel-Konfiguration Die meisten Linux-Distributionen werden mit Boot-Disketten ausgeliefert, die mit allen gängigen Typen von PC-Hardware funktionieren. Der dabei verwendete Standard-Kernel ist in der Regel stark modularisiert und enthält nahezu alle existierenden Treiber. Das ist sicherlich sehr vorteilhaft für Boot-Disketten, für die alltägliche Anwendung ist solch ein Kernel jedoch weit überdimensioniert. Das bedeutet, daß die Kernel auf diesen Boot-Disketten neben einer RAM-Disk auch einen ganzen Schwung Treiber enthalten, die Sie gar nicht brauchen und die nur wertvollen Speicherplatz verschwenden. Deshalb sollten Sie auf jeden Fall einen auf Ihre Situation zugeschnittenen Kernel zusammenstellen, der nur die Treiber enthält, die Sie wirklich benötigen. Dadurch machen Sie nicht nur den Kernel kompakt, sondern verringern auch den Zeitbedarf, der zur Übersetzung eines neuen Kernels benötigt wird. Wenn Sie ein Linux-System benutzen, sollten Sie bereits damit vertraut sein, wie man einen Kernel “baut”. Sehen Sie das bitte nicht als Zwang an, nach dem Motto: Au weia, ich “muß” jetzt einen Kernel übersetzen, sondern vielmehr als große Chance, die Ihnen nur freie Software bieten kann: “Ich habe den Code und kann mir endlich meinen Kernel nach meinen eigenen Wünschen zusammenstellen!” Außerdem handelt es sich bei der Kernel-Übersetzung im Grunde nur um eine Kernel-Optimierung! Die Grundlagen zur Übersetzung des Linux-Kernels werden unter anderem in dem Buch Linux – Wegweiser zur Installation und Konfiguration von Matt Welsh beschrieben, weswegen wir uns hier nur mit den Optionen befassen werden, die den Netzwerkteil betreffen. Ein wichtiger Punkt, der hier nochmals erwähnt werden sollte, ist die Art und Weise, wie das Schema der KernelVersionsnummern funktioniert. Linux-Kernel werden folgendermaßen numeriert: 2.2.14. Die erste Zahl bezeichnet die Major Number. Diese Zahl ändert sich nur, wenn umfangreiche, signifikante Änderungen im Kernel-Design vorgenommen wurden. So wurde zum Beispiel die Major Number des Kernels von 1 auf 2 heraufgesetzt, als der Linux-Kernel außer der Intel-Architektur erstmals auch andere Rechnertypen unterstützte. Die zweite Zahl ist die Minor Number. In vielfältiger -Hinsicht ist sie die eigentlich wichtige Nummer, auf die man achten sollte. Die Linux-Entwicklergemeinde hat nämlich einen Standard eingeführt, nach dem gerade Minor Numbers für (stabile) Produktions-Kernel und ungerade Minor Numbers für (instabile) EntwicklerKernel stehen. Für Ihre wichtigen Rechner sollten Sie immer nur stabile Kernel verwenden, da sie weitaus gründlicher getestet sind als die Entwickler-Kernel. Die Anwendung der neuesten Entwickler-Kernels ist nur dann angebracht, wenn Sie mit den allerneuesten Features von Linux experimentieren wollen. Bei ihnen kann es immer mal zu Problemen kommen, die analysiert und behoben werden müssen. Die dritte Nummer wird jeweils immer nur um eins hochgezählt, wenn eine neue Minor-Version des Kernels erscheint.1 Wenn Sie make menuconfig aufrufen, erscheint ein textorientiertes Auswahlmenü, das eine Liste mit diversen Konfigurationsfragen enthält. Sie werden zuerst nach allgemeinen Einstellungen gefragt, beispielsweise, ob Sie die Unterstützung zur Emulation eines mathematischen Co-Prozessors (Kernel Math Emulation)2 benötigen oder nicht. Unter anderem bietet Ihnen

das Konfigurationsskript Unterstützung für TCP/IP-Networking an. Diese Frage müssen Sie mit Ja (y) beantworten, um einen netzwerkfähigen Kernel zu erhalten. Eine weitaus komfortablere Möglichkeit zur Kernel-Konfiguration bieten die Kommandos make menuconfig bzw. make xconfig. Beim ersten Befehl erscheint ein textorientiertes Auswahlmenü, in dem man mit einem Balken-Cursor bequem durch die Menüpunkte navigieren kann. Wenn Sie die grafische Benutzeroberfläche X Window (XFree86) verwenden, können Sie auch make xconfig ausführen. Es erscheint dann ein Auswahlfenster, in dem Sie die Konfigurationsdetails sehr komfortabel durch Anklicken mit der Maus festlegen können.

Kernel-Optionen in Linux 2.0 und höher Wenn der Abschnitt mit den allgemeinen Optionen erledigt ist, wird die Konfiguration mit der Frage fortgesetzt, ob KernelUnterstützung für verschiedene Komponenten wie SCSI oder Soundkarten gewünscht ist. Der erscheinende Prompt zeigt an, welche Optionen jeweils verfügbar sind. Wenn Sie als Antwort ein ? eingeben, erhalten Sie eine Beschreibung, was die aktuelle Option so alles bietet. Sie haben immer die Wahl zwischen “yes” (y), um die Komponente statisch in den Kernel einzubinden, oder “no” (n), um die Komponente aus dem Kernel auszuschließen. Bei Komponenten, die als Modul übersetzt werden können, das zur Laufzeit in den Kernel eingebunden werden kann, erscheint eine dritte Option, die Sie mit m beantworten können. Solche Module müssen immer erst geladen werden, bevor man sie anwenden kann. Sie sind besonders nützlich als Gerätetreiber für Hardwarekomponenten, die Sie nur ab und zu verwenden wollen. Die anschließenden Fragen beschäftigen sich mit der Netzwerkunterstützung. Der Umfang und die genaue Abfolge der Konfigurationsoptionen ist nicht festgelegt, sondern variiert abhängig von der fortlaufenden Entwicklung des Linux-Kernels. Das folgende Beispiel zeigt einige typische Konfigurationsoptionen der Kernel-Versionen 2.0 und 2.1: * * Network device support * Network device support (CONFIG_NETDEVICES) [Y/n/?]

Diese Frage müssen Sie mit y beantworten, wenn Sie auch nur irgendeinen Netzwerkgerätetyp verwenden wollen, egal, ob es sich dabei um Ethernet, SLIP, PPP oder was auch immer handelt. Wenn Sie die Frage mit y beantworten, werden Ethernet-Geräte automatisch unterstützt. Wenn andere Netzwerkgerätetypen unterstützt werden sollen, sind weitere Fragen zu beantworten: PLIP (parallel port) support (CONFIG_PLIP) [N/y/m/?] y PPP (point-to-point) support (CONFIG_PPP) [N/y/m/?] y * * CCP compressors for PPP are only built as modules. * SLIP (serial line) support (CONFIG_SLIP) [N/y/m/?] m CSLIP compressed headers (CONFIG_SLIP_COMPRESSED) [N/y/?] (NEW) y Keepalive and linefill (CONFIG_SLIP_SMART) [N/y/?] (NEW) y Six bit SLIP encapsulation (CONFIG_SLIP_MODE_SLIP6) [N/y/?] (NEW) y

Diese Fragen betreffen die verschiedenen Protokolle, die von Linux auf der Verbindungsebene (link layer) bereitgestellt werden. Sowohl PPP als auch SLIP ermöglichen es Ihnen, IP-Datagramme über serielle Leitungen zu transportieren. PPP ist eigentlich eine Ansammlung von Protokollen zum Übertragen von Daten über eine serielle Verbindung. Einige dieser Protokolle regeln die Art und Weise, wie Sie sich beim Dialin-Server zu authentifizieren haben, während andere für den Transport höherer Protokolle zuständig sind. PPP ist nämlich nicht nur auf TCP/IP-Datagramme beschränkt, sondern transportiert auch andere Protokolle wie z.B. IPX. Wenn Sie die Frage nach der SLIP-Unterstützung mit y oder m beantworten, erscheinen darunter drei weitere Fragen. Die Option compressed headers stellt zusätzliche Unterstützung für CSLIP bereit, eine SLIP-Variante, die TCP/IP-Header auf bis zu drei Byte komprimieren kann. Es sei darauf hingewiesen, daß diese Kernel-Option CSLIP beim Verbindungsaufbau nicht automatisch aktiviert; sie stellt lediglich die notwendige Funktionalität zur Verfügung. Die Option Keepalive and linefill bewirkt eine periodisch wiederkehrende Aktivität in den SLIP-Verbindungen. Dadurch wird verhindert, daß laufende Verbindungen nach einer gewissen Zeit der Inaktivität automatisch abgebrochen werden. Die Option Six bit SLIP encapsulation ermöglicht es, SLIP mit Leitungen und Schaltkreisen zu verwenden, die die zu transportierenden 8-Bit-Datenpakete nicht direkt übertragen können. Das ist mit der Technik vergleichbar, die bei uuencode und binhex zur Übertragung binärer Dateien in EMails verwendet wird. PLIP bietet die Möglichkeit, IP-Datagramme über parallele Verbindungen zu übertragen. Es wird häufig zur Kommunikation mit PCs verwendet, die unter DOS laufen. Auf gewöhnlicher PC-Hardware kann PLIP gegebenenfalls sogar schneller als PPP oder SLIP sein, benötigt dabei allerdings erheblich mehr CPU-Leistung, was zur Folge haben kann, daß zwar die Transferrate gut ist, aber die anderen Prozesse im Rechner deutlich langsamer laufen.

Die folgenden Fragen befassen sich mit Netzwerkkarten verschiedener Hersteller. Da ständig neue Treiber erscheinen, wird die Liste der Fragen in diesem Abschnitt mit der Zeit immer länger. Wenn Sie einen Kernel zusammenstellen wollen, der auf mehr als einer Maschine laufen soll, oder Ihre Maschine mehrere Typen von Netzwerkkarten hat, können Sie auch mehr als einen Treiber auswählen. . . Ethernet (10 or 100Mbit) (CONFIG_NET_ETHERNET) [Y/n/?] 3COM cards (CONFIG_NET_VENDOR_3COM) [Y/n/?] 3c501 support (CONFIG_EL1) [N/y/m/?] 3c503 support (CONFIG_EL2) [N/y/m/?] 3c509/3c579 support (CONFIG_EL3) [Y/m/n/?] 3c590/3c900 series (592/595/597/900/905) "Vortex/Boomerang" support/ (CONFIG_VORTEX) [N/y/m/?] AMD LANCE and PCnet (AT1500 and NE2100) support (CONFIG_LANCE) [N/y/?] AMD PCInet32 (VLB and PCI) support (CONFIG_LANCE32) [N/y/?] (NEW) Western Digital/SMC cards (CONFIG_NET_VENDOR_SMC) [N/y/?] WD80*3 support (CONFIG_WD80x3) [N/y/m/?] (NEW) SMC Ultra support (CONFIG_ULTRA) [N/y/m/?] (NEW) SMC Ultra32 support (CONFIG_ULTRA32) [N/y/m/?] (NEW) SMC 9194 support (CONFIG_SMC9194) [N/y/m/?] (NEW) Other ISA cards (CONFIG_NET_ISA) [N/y/?] Cabletron E21xx support (CONFIG_E2100) [N/y/m/?] (NEW) DEPCA, DE10x, DE200, DE201, DE202, DE422 support (CONFIG_DEPCA) [N/y/m/?]/ (NEW) EtherWORKS 3 (DE203, DE204, DE205) support (CONFIG_EWRK3) [N/y/m/?] (NEW) EtherExpress 16 support (CONFIG_EEXPRESS) [N/y/m/?] (NEW) HP PCLAN+ (27247B and 27252A) support (CONFIG_HPLAN_PLUS) [N/y/m/?] (NEW) HP PCLAN (27245 and other 27xxx series) support (CONFIG_HPLAN) [N/y/m/?]/ (NEW) HP 10/100VG PCLAN (ISA, EISA, PCI) support (CONFIG_HP100) [N/y/m/?] (NEW) NE2000/NE1000 support (CONFIG_NE2000) [N/y/m/?] (NEW) SK_G16 support (CONFIG_SK_G16) [N/y/?] (NEW) EISA, VLB, PCI and on card controllers (CONFIG_NET_EISA) [N/y/?] Apricot Xen-II on card ethernet (CONFIG_APRICOT) [N/y/m/?] (NEW) Intel EtherExpress/Pro 100B support (CONFIG_EEXPRESS_PRO100B) [N/y/m/?]/ (NEW) DE425, DE434, DE435, DE450, DE500 support (CONFIG_DE4X5) [N/y/m/?] (NEW) DECchip Tulip (dc21x4x) PCI support (CONFIG_DEC_ELCP) [N/y/m/?] (NEW) Digi Intl. RightSwitch SE-X support (CONFIG_DGRS) [N/y/m/?] (NEW) Pocket and portable adaptors (CONFIG_NET_POCKET) [N/y/?] AT-LAN-TEC/RealTek pocket adaptor support (CONFIG_ATP) [N/y/?] (NEW) D-Link DE600 pocket adaptor support (CONFIG_DE600) [N/y/m/?] (NEW) D-Link DE620 pocket adaptor support (CONFIG_DE620) [N/y/m/?] (NEW) Token Ring driver support (CONFIG_TR) [N/y/?] IBM Tropic chipset based adaptor support (CONFIG_IBMTR) [N/y/m/?] (NEW) FDDI driver support (CONFIG_FDDI) [N/y/?] Digital DEFEA and DEFPA adapter support (CONFIG_DEFXX) [N/y/?] (NEW) ARCnet support (CONFIG_ARCNET) [N/y/m/?] Enable arc0e (ARCnet "Ether-Encap" packet format) (CONFIG_ARCNET_ETH)/ [N/y/?] (NEW) Enable arc0s (ARCnet RFC1051 packet format) (CONFIG_ARCNET_1051)/ [N/y/?] (NEW) . .

Im Abschnitt über Dateisysteme fragt das Konfigurationsskript Sie schließlich, ob Sie Unterstützung für NFS, das NetzwerkDateisystem (Network File System), wünschen. NFS ermöglicht es Ihnen, Dateisysteme an verschiedene Maschinen zu exportieren, so daß die Dateien auf diesen Rechnern erscheinen, als befänden sie sich auf einer ganz normalen lokalen Festplatte. NFS file system support (CONFIG_NFS_FS) [y]

In Kapitel 14 Das Network File System, werden wir uns ausführlich mit NFS beschäftigen.

Kernel-Netzwerkoptionen in Linux 2.0.0 und höher Linux 2.0.0 ist ein Meilenstein im Linux-Netzwerkdesign. Viele Features wie z.B. IPX, die sich bisher nur im experimentellen Stadium befanden, gehören nun standardmäßig zum Linux-Kernel. Eine Vielzahl neuer konfigurierbarer Optionen kam hinzu. Manche dieser Optionen sind so speziell, daß sie hier nicht im Detail behandelt werden; dafür sei auf die jeweils aktuellen Networking-HOWTOs verwiesen. In diesem Abschnitt beschäftigen wir uns nur mit einigen nützlichen Optionen. Grundlagen Um TCP/IP-Networking zu benutzen, müssen Sie diese Frage mit Ja (y) beantworten. Wenn Sie mit n antworten, haben Sie aber immer noch die Möglichkeit, IPX-Unterstützung einzubinden. Networking options

--->

[*] TCP/IP networking

Gateways Diese Option müssen Sie einschalten, wenn Ihr System als Gateway zwischen zwei Netzen oder einem LAN und einer SLIP-Verbindung usw. dienen soll. Obwohl es nicht schadet, IP-Forwarding grundsätzlich bereitzustellen, möchten Sie vielleicht darauf verzichten, um Ihr System als sogenannten Firewall (wörtlich: Brandschutzmauer) zu konfigurieren. Firewalls sind Rechner, die an zwei oder mehrere Netze angeschlossen sind, aber keine Pakete vom einen ins andere routen. Sie werden häufig dazu benutzt, um beispielsweise Mitarbeitern einer Firma Zugang zum Internet zu bieten, aber

gleichzeitig die Risiken für das firmeninterne Netz zu begrenzen. Benutzer können Internetdienste nutzen, aber alle anderen Maschinen im eigenen Netz sind vor Angriffen von außen geschützt, da hereinkommende Verbindungen nur bis zum Firewall gelangen (Firewalls werden ausführlich in Kapitel 9 TCP/IP-Firewall, behandelt). [*] IP: forwarding/gatewaying

Virtuelles Hosting Mit diesen Optionen kann man einer einzelnen Schnittstelle mehrere IP-Adressen zuordnen. Das ist besonders dann von Vorteil, wenn Sie ein sogenanntes “Virtual Hosting” durchführen wollen. Dabei wird eine einzelne Maschine so konfiguriert, daß man den Eindruck hat, es handelt sich dabei um mehrere separate Maschinen, die jeweils eigene Netzwerkeigenschaften haben. Auf das IP Aliasing werden wir in Kürze näher eingehen. [*] Network aliasing

<*> IP: aliasing support

Protokollführung (Accounting) Ist diese Option aktiviert, wird ein Protokoll über den Umfang aller auf Ihrer Maschine hereinkommenden und ausgehenden IP-Pakete geführt. Auf die Details wird ausführlich in Kapitel 10 IP-Accounting, eingegangen. [*] IP: accounting

PC hug Diese Option umgeht eine Inkompatibilität mit einigen Versionen von PC/TCP, einer kommerziellen TCP/IPImplementierung für DOS-basierte PCs. Wenn Sie diese Option einschalten, können Sie immer noch mit normalen UNIXMaschinen kommunizieren; allerdings kann der Durchsatz über langsame Verbindungen wie SLIP etwas darunter leiden. --- (it is safe to leave these untouched)

[*] IP: PC/TCP compatibility mode

Booten übers Netz (Diskless booting) Diese Funktion stellt RARP, das Reverse Address Resolution Protocol, bereit. RARP bedeutet soviel wie “umgekehrte Adreßauflösung” und wird von X-Terminals und ähnlichem benutzt, um beim Booten die eigene IP-Adresse herauszufinden. Sie sollten RARP nur dann einschalten, wenn Sie diese Art von Geräten bedienen wollen. Die StandardNetzwerk-Utilities enthalten ein Programm names rarp, mit dem man Systeme in die RARP-Tabelle des Kernels eintragen kann. <*> IP: Reverse ARP

MTU Wenn Sie Daten über eine TCP-Verbindung transportieren, muß der Kernel sie erst in kleinere Pakete aufteilen, bevor er sie an die IP-Schicht weiterreicht. Die Größe dieser Pakete wird als “maximale Übertragungseinheit” bzw. Maximum Transmission Unit (MTU) bezeichnet. Für Hosts, die über ein lokales Netz (z.B. Ethernet) erreichbar sind, bietet sich als MTU die für Ethernets maximal mögliche Größe von 1.500 Bytes an. Wird IP dagegen über Wide Area Networks (z.B. das Internet) geroutet, ist es angebracht, kleinere Datagramme zu verwenden, um sicherzustellen, daß sie während ihrer Übertragung mittels IP-Fragmentation nicht in noch kleinere Pakete aufgeteilt werden müssen.3 Der Kernel ist standardmäßig dazu in der Lage, die kleinste MTU einer IP-Route selbst zu ermitteln und automatisch eine passende TCPVerbindung zu konfigurieren. Wenn Sie die Frage mit Ja (y) beantworten, wird dieses Feature abgeschaltet. Wenn man es unbedingt möchte, kann man für die Daten, die an spezifische Hosts (z.B. über eine SLIP-Verbindung) verschickt werden, auch eine kleinere Paketgröße einstellen. Dies wird durch die Option mss des Kommandos route bewerkstelligt. Auf diesen Befehl wird kurz am Ende dieses Kapitels eingegangen. [ ] IP: Disable Path MTU Discovery (normally enabled)

Sicherheitseinstellung Das IP-Protokoll unterstützt eine besondere Eigenschaft namens Source Routing. Dieses Verfahren gestattet es Ihnen, die Route eines Datagramms zu spezifizieren, über die es übertragen werden soll. Dabei werden die Informationen über diese Route direkt im Datagramm selbst codiert. Das war vielleicht früher mal eine nützliche Methode, bevor sich RoutingProtokolle wie RIP und OSPF durchsetzten. Heutzutage wäre ein solches Protokoll jedoch ein Sicherheitsrisiko, da es von cleveren Hackern genutzt werden könnte, um diverse Arten von Firewalls zu durchbrechen, indem einfach die RoutingTabellen der Router umgangen werden. Sicherlich werden Sie solche Datagramme aus Ihrem System herausfiltern wollen. Deshalb ist diese Option standardmäßig aktiviert. [*] IP: Drop source routed frames

Novell-Support Diese Option stellt Unterstützung für IPX bereit, ein Protokoll, das in Novell-Netzwerken benutzt wird. Sie ist besonders nützlich, wenn Sie in Ihrem Netzwerk auch Novell-Fileserver haben, da Linux ziemlich gut als IPX-Router fungieren kann. IPX-Support wird auch für das NCP-Dateisystem benötigt. Wenn Sie Ihre Novell-Dateisysteme an LinuxDateisysteme mounten wollen (bzw. umgekehrt), muß diese Option aktiviert sein. Mit IPX und dem NCP-Dateisystem beschäftigen wir uns in Kapitel 15 IPX und das NCP-Dateisystem. <*> The IPX protocol

Amateurfunk Diese Optionen stellen die drei von Linux unterstützten Amateurfunk-Protokolle zur Verfügung: AX.25, NetRom und Rose. Wir werden hier nicht näher darauf eingehen, sondern verweisen statt dessen auf das AX25-HOWTO. <*> Amateur Radio AX.25 Level 2 (Rose)

<*> Amateur Radio NET/ROM

<*> Amateur Radio X.25 PLP

Linux unterstützt noch einen weiteren Treibertyp: den Dummy-Treiber. Die folgende Frage erscheint am Anfang des Abschnittes, in dem Sie die Treiber für die Netzwerkgeräte auswählen können: <*> Dummy net driver support

Der Dummy-Treiber tut nicht besonders viel, wie der Name auch schon ahnen läßt, ist aber auf einem Rechner ohne Netzanbindung oder mit nur einer SLIP-Verbindung sehr nützlich. Er ist im wesentlichen ein maskiertes LoopbackInterface. Der Grund, eine solche Schnittstelle zu haben, ist folgender: Auf einer Maschine, die SLIP, aber kein Ethernet hat, wünscht man sich eine Schnittstelle, die die ganze Zeit Ihre IP-Adresse trägt, und nicht nur, wenn die SLIPVerbindung aktiv ist. Wir werden auf dieses Thema noch etwas ausführlicher im Abschnitt Die Dummy-Schnittstelle in Kapitel 5 TCP/IP-Konfiguration, eingehen. Denselben Effekt erreichen Sie durch Anwendung eines IP-Alias, indem Sie Ihre IP-Adresse als Alias dem Loopback-Interface zuweisen.

1.

Die Entwickler-Kernel sollten von möglichst vielen Linux-Anwendern benutzt werden, um die auftretenden Bugs an die Entwickler zurückzumelden. Es wäre den Kernel-Entwicklern sehr geholfen, wenn Sie eine Maschine besitzen, die Sie zu solchen Testzwecken einsetzen könnten. Wie die Bugs an die Entwickler gemeldet werden, können Sie ausführlich in der Datei /usr/src/linux/REPORTING-BUGS in Ihrem Linux-Kernel-Quellcode nachlesen.

2.

Wichtig für Intel-386er Prozessoren

3.

Das IP-Protokoll kann über viele verschiedene Netzwerktypen übertragen werden, aber nicht alle können so große Datagramme übertragen wie Ethernet.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Ein Überblick über die Netzwerkgeräte Der Linux-Kernel unterstützt eine Vielzahl von Treibern für unterschiedliche Arten von Hardware. Dieser Abschnitt gibt Ihnen einen kurzen Überblick über die vorhandenen Treiber-Familien und die für sie reservierten Interface-Namen. In Linux existieren für die Schnittstellen eine Reihe von Standardbezeichnern, die im folgenden aufgeführt sind. Die meisten Treiber unterstützen mehrere Schnittstellen. In diesem Fall werden die Namen einfach durchnumeriert, z.B. eth0, eth1 usw. lo Das Loopback-Interface. Es kann einerseits zum Testen verwendet werden, wird aber auch von einigen Applikationen wie INN benutzt, um Daten darüber auszutauschen. Es funktioniert wie eine Art Schleife, die jedes empfangene Datagramm umgehend an die Netzwerkschicht Ihres Systems zurückreicht. Jeder Kernel besitzt eine solche Schnittstelle, und es ist im allgemeinen auch nicht sinnvoll, mehrere zu haben. eth0, eth1, … Ethernet-Geräte. Dies ist der generische Name für die meisten Ethernet-Karten, auch für

solche, die an den Parallelport angeschlossen werden. tr0, tr1, … Token-Ring-Geräte. Sie werden für die meisten Token-Ring-Karten benutzt, auch für solche, die nicht von IBM stammen. sl0, sl1, … SLIP-Schnittstellen. Die Namen werden in der Reihenfolge vergeben, in der die seriellen Ports für die SLIP-Nutzung belegt werden. ppp0, ppp1, … PPP-Schnittstellen. Sie werden wie SLIP-Kanäle auch erst dann zugeteilt, wenn ein serieller Port in den PPP-Modus geschaltet wird. plip0, plip1, … PLIP-Schnittstellen. PLIP überträgt IP-Pakete über den Parallelport. Die Schnittstellen werden vom PLIP-Treiber während des Bootens reserviert und den einzelnen Parallelports statisch zugeordnet. In den Kerneln der Version 2.0.x waren die Gerätenamen den I/O-Adressen der Parallelports noch fest zugeordnet. In den neueren Kerneln werden die Gerätenamen der Reihe nach zugeordnet, wie es bei den SLIP- und PPP-Geräten der Fall ist. ax0, ax1, … AX.25-Schnittstellen. AX.25 wird zumeist von Amateur-Radio-Operatoren verwendet. Die Reservierung und Zuordnung von AX.25-Schnittstellen geschieht auf ähnliche Weise wie bei den SLIP-Geräten. Es gibt noch viele andere Schnittstellenarten für andere Netzwerktreiber. Hier haben wir nur die am häufigsten benutzten aufgelistet. In den folgenden Abschnitten werden wir uns im einzelnen mit den oben aufgeführten Treibern beschäftigen. Das Networking-HOWTO enthält genaue Informationen, wie die meisten anderen Treiber konfiguriert werden. Das AX.25-HOWTO erläutert dies für Amateur-Radio-Netzwerkgeräte.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Ethernet-Installation Wie bereits mehrfach erwähnt, stellt Linux Ethernet-Treiber für Karten diverser Hersteller bereit. Die meisten Treiber stammen von Donald Becker, der eine Treiber-Familie für Karten geschrieben hat, die auf dem Chip NSC 8390 von National Semiconductor basieren. Sie werden auch als Treiber der “BeckerSerie” bezeichnet. Viele andere Entwickler haben ebenfalls Treiber beigesteuert. Heute gibt es nur noch sehr wenige Ethernet-Karten, die nicht von Linux unterstützt werden. Die Liste aller unterstützten Ethernet-Karten wächst ständig, so daß Sie davon ausgehen können, daß Ihre nagelneue Netzwerkkarte demnächst auch unterstützt wird. Früher hätten wir vielleicht noch den Versuch unternommen, sämtliche von Linux unterstützten EthernetKarten aufzulisten. Aber da die Liste mittlerweile einfach zu umfangreich geworden ist, würde dies jetzt zuviel Zeit und Platz in Anspruch nehmen. Glücklicherweise hat sich Paul Gortmaker dieser Sache angenommen und in seinem Ethernet-HOWTO alle unterstützten Karten aufgelistet und diese sogar noch mit nützlichen Zusatzinformationen über ihre Anwendung in Linux versehen.1 Es erscheint monatlich in der Newsgruppe comp.os.linux.answers und kann außerdem von jedem Spiegelserver des Linux Documentation Projects heruntergeladen werden. Auch wenn Sie überzeugt sind, genau zu wissen, wie Sie eine bestimmte Netzwerkkarte in Ihrem System installieren müssen, sollten Sie trotzdem unbedingt einen Blick ins Ethernet-HOWTO werfen. Denn dort finden Sie Informationen, die über das allgemeine Wissen über Netzwerkkonfiguration hinausgehen. So ersparen Sie sich Kopfschmerzen, wenn Sie sich z.B. über das Verhalten mancher DMA-basierter Ethernet-Karten klarwerden, die standardmäßig denselben DMA-Kanal wie der SCSI-Controller Adaptec-

1542 verwenden. Wenn Sie eine der beiden Karten nicht auf einen anderen DMA-Kanal verlegen, werden Sie damit rechnen müssen, daß die Netzwerkkarte IP-Pakete auf irgendwelche Sektoren Ihrer Festplatte schreibt! Um eine dieser Karten mit Linux zu verwenden, können Sie einen fertigen Kernel aus einer der vielen Linux-Distributionen verwenden. Diese Kernel haben im allgemeinen Treiber für alle Karten eingebunden. Bei der Installation können Sie in der Regel angeben, welche Treiber geladen werden sollen. Auf lange Sicht ist es allerdings besser, wenn Sie sich Ihren eigenen Kernel bauen und nur diejenigen Treiber verwenden, die Sie tatsächlich brauchen; das spart Festplatten- und Hauptspeicher.

Ethernet-Autoprobing Viele der Ethernet-Treiber von Linux sind intelligent genug, um die Einstellungen Ihrer Netzwerkkarte automatisch herauszufinden. Das erspart Ihnen die manuelle Eingabe dieser Daten. Im Ethernet-HOWTO ist angegeben, ob ein bestimmter Treiber ein Autoprobing durchführt und in welcher Reihenfolge er nach den I/O-Adressen der Karte sucht. Der Autoprobing-Code hat drei Einschränkungen: Erstens ist es möglich, daß eine Karte nicht korrekt erkannt wird. Das ist zwar recht selten, kommt aber gelegentlich bei billigeren Nachbildungen gängiger Marken vor. Zweitens erkennt der Kernel nur eine Netzwerkkarte automatisch, es sein denn, Sie haben explizit angegeben, daß er weitere Karten suchen soll. Das ist durchaus beabsichtigt, da davon ausgegangen wird, daß Sie die Kontrolle darüber haben wollen, welches Interface welcher Karte zugewiesen wird. Am zuverlässigsten erreichen Sie dies, indem Sie die Ethernet-Karten manuell konfigurieren. Die dritte Einschränkung besteht darin, daß der Treiber nicht unbedingt die Adresse ausprobiert, für die Ihre Karte konfiguriert ist. Im allgemeinen führen die Treiber zwar ein Autoprobing an Adressen durch, für die ein bestimmtes Gerät konfiguriert werden kann, jedoch werden dabei manchmal bestimmte Adressen ausgeklammert, um Hardwarekonflikte mit anderen Kartentypen zu vermeiden, die dieselben Adressen für sich beanspruchen. PCI-Netzwerkkarten sollten eigentlich immer zuverlässig erkannt werden. Wenn Sie allerdings mehrere Karten verwenden oder die Erkennung Ihrer Karte durch Autoprobing fehlschlägt, haben Sie die Möglichkeit, dem Kernel die Basisadresse und den Namen der Netzwerkkarte explizit mitzuteilen. Beim Booten können Sie dem Kernel explizit Argumente übergeben, die jede Kernel-Komponente auslesen kann. Dieser Mechanismus gestattet Ihnen die Übergabe von Informationen an den Kernel, die die Netzwerktreiber dazu verwenden können, Ihre Netzwerkhardware auch ohne Autoprobing zu erkennen. Wenn Sie lilo als Boot-Lader einsetzen, können Sie dem Kernel verschiedene Parameter direkt beim Booten oder durch die append-Option in der Datei lilo.conf übergeben. Der ether-Parameter beschreibt ein Ethernet-Gerät und hat folgendes Format: ether=irq,base_addr,[param1,][param2,]name

Die ersten vier Parameter sind Zahlen, während der letzte der Name des zuzuordnenden Interfaces ist. Die Parameter irq, base_addr und name sind immer anzugeben, die param-Parameter dagegen optional. Für numerische Werte, die auf null gesetzt werden, versucht der Kernel, den Wert automatisch

herauszufinden, bzw. verwendet eine Voreinstellung. Der erste Parameter legt den IRQ des Gerätes fest. Ist kein Wert angegeben, versucht der Kernel, den IRQKanal selbst festzustellen. Der 3c503-Treiber hat ein spezielles Feature das einen freien IRQ aus der Liste 5, 9, 3 und 4 auswählt und die Karte so konfiguriert, daß sie diesen Interrupt verwendet. Der Parameter base_addr gibt die I/O-Adresse der Karte an; ein Wert von null veranlaßt den Kernel, sie über den üblichen Autoprobing-Mechanismus zu suchen. Die verbleibenden zwei Parameter werden von verschiedenen Treibern unterschiedlich interpretiert. Für Karten wie die WD80x3, die auf Shared Memory basieren, geben sie die Anfangs- und Endadresse des Shared Memory-Bereichs an. Die meisten anderen Karten interpretieren param1 als den Umfang, in dem Debugging-Informationen ausgegeben werden. Werte von 1 bis 7 bezeichnen zunehmende “Geschwätzigkeit”, während 8 diese Informationen völlig unterdrückt. Null wählt einen Voreinstellungswert aus, der von Karte zu Karte verschieden sein kann. Der 3c503-Treiber verwendet param2, um zwischen dem internen Transceiver (Voreinstellung) und einem externen Transceiver (Wert von 1) zu unterscheiden. Die erste Variante stellt die BNC-Buchse der Karte ein, die zweite den AUI-Port. Die param-Argumente brauchen Sie allerdings nicht anzugeben, wenn Sie nichts Spezielles zu konfigurieren brauchen. Das erste nicht-numerische Argument wird vom Kernel als Gerätename interpretiert. Für jede Netzwerkkarte, die Sie beschreiben, müssen Sie einen Gerätenamen angeben. Wenn Sie zwei Karten verwenden, können Sie Linux die erste Karte automatisch erkennen lassen und die Parameter der zweiten mit lilo übergeben (Sie können aber auch Parameter für beide Karten angeben). Dabei müssen Sie allerdings sicherstellen, daß der Treiber die zweite Karte nicht aus Versehen zuerst findet, da sonst die andere überhaupt nicht konfiguriert wird. Das erreichen Sie, indem Sie lilo eine reserve-Option übergeben, die den Kernel ausdrücklich anweist, den von der zweiten Karte belegten I/OBereich nicht zu testen. Wenn Sie zum Beispiel Ihre zweite Karte auf die Adresse 0x300 konfiguriert haben, übergeben Sie dem Kernel folgende Parameter: reserve=0x300,32 ether=0,0x300,eth1

Die reserve-Option stellt sicher, daß kein Treiber auf den angegebenen I/O-Bereich von 0x300 bis 0x31F zugreift, wenn er das Vorhandensein eines Geräts prüft. Diesen Parameter können Sie auch benutzen, um bei der Konfiguration Ihrer ersten Karte den Autoprobing-Mechanismus zu umgehen: reserve=0x340,32 ether=0,0x340,eth0

Sie können das Autoprobing für Ihre Ethernet-Karte auch vollständig abschalten. Das ist zum Beispiel dann angebracht, wenn eine Ethernet-Karte temporär entfernt wurde und der Kernel deswegen kein Autoprobing durchführen soll. Um das Autoprobing für Ihre Ethernet-Karte vollständig auszuschalten, können Sie eine Basisadresse von -1 angeben: ether=0,-1,eth0

Damit diese Parameter beim Boot-Vorgang an den Kernel übergeben werden können, sind sie am LiloPrompt einzugeben. Damit der Prompt “boot:” auf Ihrem Bildschirm erscheint, drücken Sie eine der

Tasten Strg, Alt oder Shift. Wenn Sie an diesem Prompt Tab drücken, wird Ihnen eine Liste der Kernel angezeigt, die Sie booten können. Um einen Kernel mit den oben genannten Parametern zu booten, geben Sie den Namen des gewünschten Kernels ein, gefolgt von einem Leerzeichen und den Parametern. Wenn Sie danach die Enter-Taste betätigen, bootet lilo den gewählten Kernel mit den angegebenen Parametern. Damit diese Änderung bei jedem Neustart automatisch durchgeführt wird, tragen Sie die Parameter mit der Anweisung append= in die Datei /etc/lilo.conf ein. Das kann zum Beispiel so aussehen: boot=/dev/hda root=/dev/hda2 install=/boot/boot.b map=/boot/map vga=normal delay=20 append="ether=10,300,eth0" image=/boot/vmlinuz-2.2.14 label=2.2.14 read-only

Nach Änderungen in der Datei lilo.conf muß das Kommando lilo ausgeführt werden, um sie wirksam zu machen.

1.

Paul ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der PLIP-Treiber PLIP bedeutet Parallel Line IP und ist eine kostengünstige Art, zwei Maschinen miteinander zu vernetzen. Es verwendet den Parallelport sowie ein spezielles Kabel und erreicht Übertragungsgeschwindigkeiten von 10 bis 20 Kilobyte pro Sekunde. PLIP wurde ursprünglich von der Firma Crynwr, Inc. entwickelt. Das Design ist ziemlich clever (oder, wenn Sie so wollen, hackermäßig): Lange Zeit waren die parallelen Ports des PC nur unidirektionale Druckerschnittstellen, das heißt, über die 8 Datenleitungen konnten Daten an das Peripheriegerät ausgegeben werden, aber nicht umgekehrt. PLIP umgeht das Problem, indem es die fünf Statusleitungen der Schnittstelle für die Eingabe verwendet. Dadurch ist es allerdings gezwungen, alle Daten in Nibbles (halben Bytes) zu übertragen. Diese Arbeitsweise wird PLIPModus 0 genannt. Heutzutage werden diese unidirektionalen Schnittstellen allerdings immer seltener. Aus diesem Grunde gibt es eine zweite PLIP-Variante namens Modus 1, die die vollen 8 Bit des Ports nutzt.1 Linux unterstützt bis zur Kernel-Version 2.0 nur den PLIP-Modus 0. Seit Kernel 2.2 wird auch Modus 1 standardmäßig unterstützt. Bei Linux 2.0 wurde dafür ein erweiterter Parallelport-Treiber entwickelt, der als Patch in den Kernel eingebunden wird.2 Während dies bei älteren Versionen nicht der Fall gewesen ist, ist der Treiber heute mit der ursprünglichen Implementierung von Crynwr und dem Treiber im NCSA telnet kompatibel.3 Um zwei Maschinen mit PLIP zu verbinden, benötigen Sie

ein spezielles Kabel, das unter anderem unter der Bezeichnung “Null-Printer” oder “Turbo Laplink” verkauft wird. Sie können es allerdings auch mit relativ geringem Aufwand selbst zusammenlöten, die Steckerbelegung finden Sie in Anhang 2 Nützliche Kabel-Konfigurationen. Der PLIP-Treiber für Linux ist das geistige Kind beinahe zahlloser Personen und wird zur Zeit von Niibe Yutaka gepflegt.4 In den Kernel eingebunden, reserviert er eine Netzwerkschnittstelle für jeden der möglichen Druckerports, wobei plip0 dem Port lp0 (LPT1) entspricht, plip1 dem Port lp1 usw.Die Abbildung von Schnittstellen auf Ports wird in den Kerneln 2.0 und 2.2. unterschiedlich gehandhabt. In den 2.0er Kerneln war die Zuordnung in der Datei drivers/net/Spacd.c fest verdrahtet. Die standardmäßigen Zuordnungen sind folgende: Schnittstelle I/O-Port IRQ plip0

0x3BC

7

plip1

0x378

7

plip2

0x278

5

Wenn Sie Ihren Parallelport anders konfiguriert haben, müssen Sie diese Werte in -drivers/net/Space.c ändern und den Kernel neu übersetzen. Der Kernel 2.2 verwendet für PLIP den von Philip Blundell entwickelten “parport”-Treiber. Dieser ordnet den Parallelport nicht nur einem Gerätetreiber fest zu, sondern kann den Port gleichzeitig auch anderen Treibern zur Verfügung stellen.5 Der neue Treiber reserviert die PLIP-Netzwerkgeräte der Reihe nach, so wie das bei den Ethernet- und PPP-Treibern geschieht. Das erste PLIP-Device heißt plip0, das zweite plip1 und so weiter. Auf dieselbe Weise wird die Hardware am Parallelport registriert. Standardmäßig versucht der Parallelport-Treiber, die Hardware mit Hilfe einer AutoprobeRoutine automatisch zu erkennen und die Informationen über gefundene Hardwarekomponenten der Reihe nach auszulesen. Besser ist es jedoch, den Kernel explizit über die physikalischen I/OParameter zu informieren. Das machen Sie, indem Sie sie beim Laden des Kernel-Moduls parport_pc.o als Argumente angeben. Falls Sie den Treiber fest in den Kernel integriert haben, können Sie die Parameter dem Boot-Lader lilo mitteilen. Die IRQ-Einstellungen jedes Geräts können später geändert werden, indem der neue IRQ-Wert direkt in die zugehörige Datei /proc/parport/*/irq geschrieben wird. In den 2.2er Kerneln ist die Konfiguration physischer I/O-Parameter beim Laden von Modulen recht einfach. Um zum Beispiel dem Parallelport-Treiber mitzuteilen, daß Sie zwei PC-Schnittstellen an den I/O-Adressen 0x278 bzw. 0c378 haben und diese die Interrupts 5 bzw. 7 verwenden, laden Sie das zugehörige Kernel-Modul mit den folgenden Argumenten: modprobe parport_pc io=0x278,0x378 irq=5,7

Für einen im Kernel fest eingebauten Treiber verwenden Sie folgendes Format: parport=0x278,5 parport=0x378,7

Es kann so direkt in eine append-Anweisung für lilo übernommen werden. Beim Booten werden diese Angaben dann automatisch an den Kernel übergeben. Sobald der PLIP-Treiber initialisiert ist (beim Booten, wenn er im Kernel integriert ist, bzw. beim Laden des Kernel-Moduls plip.o), wird mit jedem der Parallelports jeweils ein plip-Device assoziiert. plip0 wird dem ersten Parallelport-Device zugewiesen, plip1 dem zweiten und so weiter. Diese automatische Zuweisung können Sie allerdings manuell außer Kraft setzen, indem Sie weitere KernelArgumente angeben. Um zum Beispiel parport0 an das Netzwerk-Device plip0 und parport1 an das Device plip1 zu binden, geben Sie folgende Kernel-Argumente an: plip=parport1 plip=parport0

Natürlich bedeutet diese Zuordnung nicht, daß Sie die verwendeten Parallelports nun nicht mehr zum Drucken oder für andere Zwecke einsetzen können. Die physische Parallelschnittstelle wird immer nur dann vom PLIP-Treiber verwendet, wenn das zugehörige Interface gerade als aktiv (up) konfiguriert ist.

1.

Helfen Sie mit, die wahre Bedeutung des Begriffs “Hacker” publik zu machen! Sie sollten immer nur die (negative) Bezeichnung “Cracker” verwenden, wenn Sie sich auf subversive Elemente beziehen, die mit voller Absicht die Sicherheitsbarrieren von Systemen zu sprengen versuchen. Der (positive) Begriff “Hacker” steht dagegen für Leute, die keinen Schaden anrichten, sondern im Gegenteil clevere Lösungen für schwierige Probleme parat haben. Sicherlich können Hacker auch Cracker sein, aber die beiden Begriffe sollte man nie verwechseln. Konsultieren Sie das “New Hackers Dictionary” (oft auch als Jargon-Datei bezeichnet), um einen besseren Einblick in die ganze Problematik zu bekommen.

2.

Dieser erweiterte Parallelport-Adapter-Patch für den Kernel 2.0 ist erhältlich unter http://www.cyberelk. demon.co.uk/parport.html.

3.

NCSA telnet ist ein beliebtes Programm für DOS-PCs, das TCP/IP über Ethernet oder PLIP bietet und telnet sowie FTP unterstützt.

4.

Niibe ist erreichbar unter [email protected].

5.

Sie erreichen Philip unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die SLIP- und PPP-Treiber SLIP (Serial Line IP) und PPP (Point-to-Point Protocol) sind weitverbreitete Protokolle, mit denen IPPakete über serielle Verbindungen übertragen werden können. Eine ganze Reihe von Institutionen bieten Internetzugang über SLIP- und PPP-Verbindungen und machen so IP-basierte Dienste auch für Privatpersonen erschwinglich. Um SLIP oder PPP einzusetzen, sind keinerlei Manipulationen am Kernel vonnöten; Sie können dafür einen ganz gewöhnlichen seriellen Port benutzen. Da die Konfiguration der seriellen Schnittstelle aber nicht unmittelbar mit TCP/IP zu tun hat, wird sie in einem eigenen Kapitel behandelt. Weitergehende Informationen schlagen Sie deshalb bitte in Kapitel 4 Konfiguration der seriellen Hardware, nach. PPP behandeln wir ausführlich in Kapitel 8 Das Point-to-Point-Protokoll, und SLIP in Kapitel 7 Serial Line IP.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Andere Netzwerktypen Die meisten anderen Netzwerktypen werden ähnlich wie bei Ethernet konfiguriert. Die an die ladbaren Kernel-Module übergebenen Argumente sind ein wenig anders gestaltet, und manche Treiber unterstützen nicht mehr als eine Karte zur Zeit. Der Rest ist aber wie gehabt. Die Dokumentation zu diesem Themenbereich können Sie dem Verzeichnis /usr/src/linux/Documentation/networking/ im Linux-Kernel-Quellcode entnehmen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 4 Konfiguration der seriellen Hardware

Das Internet wächst mit geradezu unglaublicher Geschwindigkeit. Das liegt wohl hauptsächlich an den vielen Internet-Benutzern, die nicht das nötige Kleingeld haben, um sich einen 2-MegabitAnschluß ans Internet zu leisten, sondern Netzwerkverbindungen auf der Basis von SLIP, PPP und UUCP benutzen, um über ganz gewöhnliche Telefonleitungen an ihre täglichen Mails und News

heranzukommen. Dieses Kapitel soll all den Leuten helfen, die ihre Netzverbindung mit Hilfe von Modems realisieren. Wir gehen allerdings nicht auf die technischen Details ein, wie Ihr Modem dazu konfiguriert werden muß (das kann Ihr Modem-Handbuch bestimmt besser), sondern behandeln nur die wesentlichen Linux-spezifischen Aspekte, die die Steuerung von Geräten an den seriellen Ports betreffen. Dazu gehören serielle Kommunikationssoftware, Erzeugung der seriellen Gerätedateien, serielle Hardware sowie die Konfiguration der seriellen Geräte mit den dafür vorgesehenen Kommandos setserial und stty. Viele andere Themenbereiche werden im Serial-HOWTO von David Lawyer behandelt.1

1.

David ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Software für Modemverbindungen Unter Linux gibt es eine ganze Reihe von Kommunikationsprogrammen. Viele von ihnen sind einfache Terminal-Programme, die es dem Benutzer bzw. der Benutzerin ermöglichen, sich in ein anderes System einzuwählen, als säße er bzw. sie vor einem ganz gewöhnlichen Terminal. Das traditionelle Terminal-Programm unter UNIX ist kermit, es ist allerdings etwas spartanisch. Es gibt wesentlich komfortablere Programme, die Nummernverzeichnisse, Skriptsprachen zum automatischen Anwählen und Einloggen in andere Systeme usw. unterstützen. Eines von ihnen ist minicom, dessen Oberfläche und Bedienung dem sehr ähnlich ist, was ehemalige DOS-Benutzer gewohnt sind. Außerdem existieren noch X-basierte Terminal-Programme wie seyon. Abgesehen von Terminal-Programmen gibt es auch Software, die Daten ohne Ihr Eingreifen auf Ihren oder von Ihrem Rechner überträgt. Vorteilhaft daran ist, daß es wesentlich weniger Zeit kostet (und daher eventuell auch viel kostengünstiger ist), einige Dutzend Kilobytes automatisch herunterzuladen, als Ihre Mail online zu lesen oder eine Mailbox nach interessanten Artikeln zu durchforsten. Das Lesen und Beantworten der Mails können Sie in Ruhe offline erledigen, und Sie brauchen erst dann wieder online zu gehen, wenn Sie Ihre Antworten fertig haben und sie auf einmal (als Ganzes) absenden wollen. Allerdings erfordert dies auch mehr Plattenplatz, da dabei auch jede Menge Informationen übertragen werden, die Sie vielleicht gar nicht interessieren. Bei den großen Speicherkapazitäten und niedrigen Preisen der heutigen Festplatten spielt das allerdings kaum noch eine Rolle.

Der Inbegriff dieser Art von Kommunikationssoftware ist UUCP. Das ist ein Programmpaket, das Dateien von einem Host auf einen anderen übertragen und Befehle auf einem entfernten Rechner ausführen kann. Es wird häufig benutzt, um Mail und News in kleineren Netzen zu übertragen. Ian Taylors UUCP-Paket, das auch unter Linux läuft, wird ausführlich in Kapitel 16 Taylor UUCP verwalten, beschrieben. Andere, nicht-interaktive Software wird beispielsweise im Fido-Netz eingesetzt. Portierungen von Fido-Netzapplikationen, wie z.B. ifmail, sind unter Linux auch verfügbar, werden allerdings kaum noch verwendet. PPP und SLIP liegen irgendwo dazwischen, sie können sowohl interaktiv als auch nicht interaktiv verwendet werden. Viele Anwender benutzen PPP oder SLIP zur Einwahl in ihr Universitätsnetzwerk oder zu ihrem Internet Service Provider, um dort FTP-Transfers zu machen oder Webseiten zu lesen. Beide Protokolle werden gewöhnlich auch dazu verwendet, um permanente oder semi-permanente Verbindungen zur LAN-LAN-Kopplung aufzubauen. Das ist allerdings nur für ISDN und andere Hochgeschwindigkeits-Netzwerkverbindungen interessant.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Einführung in serielle Geräte Die von einem UNIX-Kernel für die Kommunikation mit seriellen Geräten bereitgestellten Schnittstellen werden im allgemeinen ttys (sprich: ti-ti-wai) genannt. Das ist eine Abkürzung für Teletype, den wichtigsten Hersteller von Terminals in den Anfangstagen von UNIX. Dieser Begriff wird heutzutage allgemein für zeichenorientierte Ein- und Ausgabegeräte benutzt. In diesem Kapitel werden wir ihn ausschließlich verwenden, um uns auf die Geräteschnittstellen des Kernels zu beziehen. Linux unterscheidet drei Arten von ttys: serielle Geräte, virtuelle Terminals und Pseudo-Terminals (ähnlich einer bidirektionalen Pipe; wird von X11-Applikationen wie xterm benutzt), die alle durch Drücken der Tastenkombinationen Alt-F1 bis Alt-Fnn an der lokalen Konsole erreichbar sind. Bei ersteren handelt es sich um tty-Geräte, da die ursprünglichen, zeichenbasierten Terminals über serielle Verbindungen oder über das Telefonnetz und ein Modem mit den Unix-Maschinen verbunden waren. Die beiden letzten zählen ebenfalls zu den tty-Geräten, da sie sich von Standpunkt eines Programmierers aus betrachtet, ähnlich wie diese verhalten. SLIP und PPP sind für gewöhnlich im Kernel implementiert. Der Kernel behandelt tty-Geräte nicht wie gewöhnliche Netzwerkgeräte, die man z.B. mit dem Befehl ifconfig wie eine Ethernet-Karte ansprechen kann. Er sieht sie vielmehr als Plätze an, an die Netzwerkgeräte gebunden werden können. Die Arbeitsweise solcher Verbindungen legt der Kernel über den sogenannten Verbindungsmodus

(line discipline) fest. SLIP und PPP sind zwei typische Verbindungsmodi, die für ein tty-Gerät eingestellt werden können. Der Zweck der Verbindungsmodi liegt darin, daß ein Gerätetreiber die empfangenen Daten unterschiedlich handhaben soll, je nachdem, welcher Verbindungsmodus gerade aktiv ist. Im normalen Verbindungsmodus reicht der Treiber die empfangenen Bytes einfach weiter. Im SLIP- oder PPP-Verbindungsmodus wird dagegen immer erst ein Datenblock gelesen und dieser mit einem speziellen Header versehen, damit die Gegenseite diesen Block im Datenstrom identifizieren kann. Der so zusammengestellte Datenblock wird dann übertragen. Sie brauchen sich über die Details jetzt keine weiteren Gedanken zu machen, da wir SLIP und PPP in späteren Kapiteln noch ausführlich behandeln werden und dieser Vorgang normalerweise vollkommen automatisch abläuft.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Auf serielle Geräte zugreifen Wie auf alle Geräte in einem UNIX-System greifen Sie auch auf serielle Geräte über spezielle Dateien im Verzeichnis /dev zu. Es gibt zwei Arten von Gerätedateien, die mit seriellen Treibern zu tun haben, und für jeden Port gibt es jeweils eine Gerätedatei von jedem Typ. Abhängig von der Datei, über die Sie darauf zugreifen, wird sich das Gerät unterschiedlich verhalten. Wir gehen auf die Unterschiede etwas ausführlicher ein, damit Sie einige besondere Konfigurationsdetails serieller Geräte besser verstehen. In der Praxis werden Sie es allerdings nur mit einer Art von Gerätedateien zu tun bekommen, und in Zukunft könnte eine der beiden Grätedateien sogar komplett verschwinden. Die wichtigste der beiden Arten serieller Geräte hat die Major Number (Major Number) 4. Ihre Gerätedateien haben die Bezeichnung ttyS0, ttyS1 usw. Die zweite Art hat die Major Number 5, ist für Dialout-Anwendungen über die Ports vorgesehen und verwendet die Gerätedateien cua0, cua1 etc. In der Unix-Welt beginnt jede Zählung immer mit null, während Laien dazu tendieren, mit eins zu beginnen. Diese Zählweise verwirrt einige Leute, weil COM1: nicht etwa der Gerätedatei /dev/ttyS1 entspricht, sondern /dev/ttyS0! Die Schnittstelle COM2: entspricht /dev/ttyS1 usw. Jeder, der sich etwas mit PCHardware auskennt, weiß, daß die anderen Schnittstellen wie COM3: und höher nie richtig standardisiert wurden. Serielle Ports, an denen Modems angeschlossen sind, müssen in der Lage sein, sowohl Daten empfangen als auch senden zu können. Damit es dabei nicht zu Konflikten kommt, wurden besondere Gerätedateien eingeführt, die sogenannten cua- bzw. -“callout”-Geräte. Unglücklicherweise haben sich diese mittlerweile selbst als problematisch erwiesen und werden vermutlich nicht mehr weiterentwickelt. Das Problem ist folgendes: Linux gestattet es (wie Unix auch), eine (Geräte-)Datei von mehreren Prozessen gleichzeitig zu öffnen. Diese an sich sehr nützliche Sache ist für tty-Geräte allerdings überhaupt nicht sinnvoll, da es passieren kann, daß sich dort mehrere Prozesse gegenseitig in die Quere kommen. Zum Glück hat sich jemand einen Mechanismus ausgedacht, der es einem Prozeß ermöglicht, vor dem Öffnen einer Gerätedatei festzustellen, ob diese Datei schon von einem anderen Prozeß belegt wurde. Dieser Mechanismus verwendet sogenannte Sperrdateien (lock files) und funktioniert so: Will ein Prozeß ein tty-Gerät öffnen, prüft er zunächst, ob es eine besondere Datei (die Sperrdatei) gibt, die dem Namen der Gerätedatei ähnlich ist. Existiert eine solche Datei, nimmt der Prozeß an, daß das gewünschte Gerät von einem anderen Prozeß benutzt wird. Wenn die Datei dagegen nicht existiert, geht der Prozeß davon aus, daß das Gerät frei ist, erzeugt dann selbst eine Sperrdatei und reserviert das tty-Gerät für sich. Es gibt noch einen letzten cleverer Trick, damit die Verwaltung von Sperrdateien funktioniert. Die PID des Prozesses, der diese Datei angelegt hat, wird in die Datei selbst geschrieben. Darauf gehen wir gleich näher ein. Der Sperrdatei-Mechanismus funktioniert perfekt in Systemumgebungen, in denen es ein eindeutiges Verzeichnis für alle

Sperrdateien gibt und alle Programme wissen, wo sich dieses Verzeichnis befindet. Bei Linux war das lange Zeit nicht so. Erst seit der -offiziellen Einführung des Linux Filesystem Standards (FSSTND) funktioniert der Sperrdatei-Mechanismus für ttyGeräte in Linux störungsfrei. Vorher gab es in manchen Linux-Distributionen phasenweise sogar vier (wenn nicht noch mehr) verschiedene Verzeichnisse für Sperrdateien:/usr/spool/locks/, /var/spool/locks/, /var/lock/ und /usr/lock/. Es ist klar, daß bei einer solchen Konfusion nur Chaos entstehen konnte. Verschiedene Prozesse öffneten an verschiedenen Stellen gleichzeitig Sperrdateien, die eigentlich zur exklusiven Kontrolle einzelner tty-Geräte gedacht waren. Solche Sperrdateien waren dann natürlich nutzlos. Um einen Ausweg aus diesem Dilemma zu finden, wurden die cua-Geräte eingeführt. Diese Gerätedateien verwendeten keine Sperrdateien mehr, um die Konflikte zwischen Programmen beim Zugriff auf serielle Geräte zu lösen, sondern überließen die Entscheidung über die Freigabe der Geräte dem Kernel. Immer wenn ein ttyS-Gerät bereits geöffnet war, sollte ein Versuch, das zugehörige cua-Gerät zu öffnen, einen Fehler produzieren, der das öffnende Programm darauf hinwies, daß das Gerät bereits belegt war. Im umgekehrten Fall, wenn also das Gerät cua bereits geöffnet war und ein Versuch unternommen wurde, das Gerät ttyS zu öffnen, sollte kein Fehler produziert werden, sondern lediglich die Anfrage blockiert werden, d.h., der öffnende Prozeß mußte dann so lange warten, bis das cua vom anderen Prozeß wieder geschlossen wurde. Dieses Verfahren funktioniert ganz gut, wenn man nur ein einzelnes Modem hat, das die meiste Zeit im Dialin-Modus arbeitet und nur ab und zu ein Dialout über das gleichen Gerät ausführt. In Umgebungen, in denen mehrere Programme gleichzeitig ablaufen, die dasselbe Gerät zum Dialout nutzen wollen, funktioniert die Sache leider nicht. Dazu müßten wieder Sperrdateien verwendet werden, und wir wären genauso schlau wie vorher! Erst mit der Einführung des Linux Filesystem Standards kam das rettende Ufer in Sicht. Er legt fest, daß grundsätzlich Sperrdateien verwendet werden und diese in einem eindeutigen Verzeichnis abgelegt werden sollten, nämlich /var/lock. Per Konvention haben die Namen aller Sperrdateien ein ganz besonderes Format. So hat z.B. die Sperrdatei für das ttyS1-Gerät den Namen LCK..ttyS1. Die Sperrdateien für cua-Geräte sollten auch in diesem Verzeichnis abgelegt werden, jedoch wird von der Verwendung dieser Geräte abgeraten. Die cua-Geräte werden eventuell noch eine Zeitlang unterstützt, um Rückwärtskompatibilität zu gewährleisten, mit der Zeit werden sie jedoch an Bedeutung verlieren. Falls Sie unsicher sind, verwenden Sie grundsätzlich nur ttyS-Geräte und stellen Sie sicher, daß Ihr System auch wirklich den Linux-FSSTND verwendet. Zumindest sollten alle Programme, die serielle Geräte verwenden, ihre Sperrdateien in einem einzigen besonderen -Verzeichnis ablegen. Die meisten Programme, die mit ttyGeräten zu tun haben, bieten die Möglichkeit, bei der Übersetzung ihrer Quelldateien das Sperrverzeichnis mit einer speziellen Compiler-Option festzulegen. In manchen Fällen kann man dieses Verzeichnis auch in einer Variablen namens LOCKDIR im Makefile oder in einer Konfigura-tions- -Header-Datei angeben. Wenn Sie Ihre Software selbst übersetzen, ist es am besten, wenn Sie sich genau an den FSSTND halten. Bei vorkompilierten Binärpaketen, von denen Sie nicht wissen, wo sie die Sperrdateien ablegen, können Sie das wie folgt herausfinden: strings binaryfile | grep lock

Stimmt das angezeigte Verzeichnis nicht mit dem Rest Ihres Systems überein, können Sie sich immer noch mit einem Trick behelfen. Versuchen Sie einfach, einen symbolischen Link vom Verzeichnis, das vom Binärprogramm favorisiert wird, zum Standardverzeichnis /var/lock/ anzulegen. Das ist zwar nicht besonders elegant, aber es funktioniert.

Spezialdateien für serielle Geräte Die Minor Numbers sind für beide seriellen Geräteklassen gleich. Wenn Sie an einem der Ports COM1 bis COM4 ein Modem angeschlossen haben, ist seine Minor Number die Nummer des COM-Ports plus 63. Wenn Sie eine andere Art von Hardware verwenden, zum Beispiel eine leistungsfähige Multiport-Karte, kann es passieren, daß sie nicht mit den vorhandenen Standardtreibern funktioniert, sondern spezielle Gerätedateien benötigt. Wie man solche Gerätedateien prinzipiell erzeugt, können Sie im Serial-HOWTO nachlesen. Nehmen wir an, Ihr Modem sei an COM2 angeschlossen. Dann ist seine Minor Number 65, und die Major Number ist 4. Sie sollten in /dev eine Datei namens ttyS1 finden, die diese Gerätenummern trägt. Wenn Sie die seriellen ttys in /dev auflisten, finden Sie die Major und Minor Numbers in den Spalten 5 und 6: $ ls -l /dev/ttyS* 0 crw-rw---1 uucp dialout 4, 64 Oct 13 1997 /dev/ttyS0 0 crw-rw---1 uucp dialout 4, 65 Jan 26 21:55 /dev/ttyS1 0 crw-rw---1 uucp dialout 4, 66 Oct 13 1997 /dev/ttyS2 0 crw-rw---1 uucp dialout 4, 67 Oct 13 1997 /dev/ttyS3

Wenn keine solche Gerätedatei existiert, müssen Sie sie einrichten, indem Sie sich als Superuser anmelden und folgende Befehle eingeben: # mknod -m 666 /dev/ttyS1 c 4 65 # chown uucp.dialout /dev/ttyS1

In den verschiedenen Linux-Distributionen werden die Eigentumsrechte an den seriellen Geräten leicht unterschiedlich gehandhabt. In einigen Distributionen ist root als Eigentümer vorgesehen, in anderen dagegen uucp (wie in unserem Beispiel). Die modernen Varianten gehen noch einen Schritt weiter und ordnen die Dialout-Geräte einer speziellen Gruppe zu. Nur Anwender, die in dieser Gruppe eingetragen sind, dürfen diese Geräte benutzen. Manche Leute empfehlen, einen symbolischen Link namens /dev/modem einzurichten, der auf Ihr Modem zeigt, damit ungeübte Benutzer sich nicht den wenig einprägsamen Namen cua1 merken müssen. Sie sollten dann allerdings nicht in einem Programm modem und in einem anderen Programm den echten Gerätenamen verwenden, da sonst die Sperrdateien unterschiedliche Namen bekommen und der Sperrmechanismus nicht mehr funktioniert.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Serielle Hardware RS-232 ist der derzeit am weitesten verbreitete Standard für serielle Geräte in der PC-Welt. Er verwendet eine Reihe von Schaltkreisen zur Übertragung der einzelnen Bits und zur Synchronisation. Weitere Leitungen können dafür benutzt werden, um das Anliegen eines Trägersignals zu signalisieren (bei Modems), sowie für den Handshake. Linux unterstützt eine breite Palette an seriellen Karten, die nach dem Standard RS-232 funktionieren. Obwohl der Hardware-Handshake vom Standard nicht vorgeschrieben wird, ist er doch sehr nützlich. Er erlaubt jeder der beiden Stationen, der jeweils anderen mitzuteilen, ob weitere Daten empfangen werden können oder ob die Gegenstelle eine Pause einlegen sollte, bis der Empfänger die vorliegenden Daten verarbeitet hat. Die hierfür verwendeten Steuerleitungen heißen “Clear to Send” (CTS) und “Ready to Send” (RTS), woraus sich auch der umgangssprachliche Name RTS/CTS für den Hardware-Handshake ableitet. Die andere Art von Handshake, die vermutlich geläufig sein wird, ist “XON/XOFF”. Dabei werden zwei besondere Zeichen, üblicherweise Strg-S bzw. Strg-Q, dazu verwendet, der Gegenstelle mitzuteilen, daß sie ihre Datenübertragung beenden bzw. fortsetzen soll. Während diese Methode sehr einfach zu implementieren und für einfache -Terminals recht nützlich ist, erweist sie sich für die Übertragung binärer Daten als sehr problematisch, da die beiden Sonderzeichen bei der Übertragung nicht als gewöhnliche Bytes aufgefaßt, sondern immer als Steuerzeichen interpretiert werden. Außerdem ist es langsamer als der saubere und schnelle HardwareHandshake, weshalb letzterer gegenüber XON/XOFF immer den Vorzug bekommen sollte.

Im ursprünglichen IBM-PC wurde die RS-232-Schnittstelle üblicherweise durch einen UART-Chip vom Typ 8250 angesteuert. Seit den Zeiten der 486er Prozessoren verwendeten die PCs zumeist einen 16450, der etwas schneller als der 8250 war. Fast alle Pentium-Maschinen wurden mit einer noch moderneren Variante, dem 16550, ausgestattet. Einige Marken (besonders interne Modems mit Rockwell-Chips) verwenden dagegen völlig andere Chips, die aber das Verhalten der 16550er emulieren und daher fast genauso behandelt werden können. All diese Chips werden von Linux in dessen Standard-Serial-Port-Treiber unterstützt.1 Gegenüber dem 8250er und dem 16450er stellt der 16550er eine deutliche Verbesserung dar, da er über einen 16 Byte großen FIFO-Puffer verfügt. Beim 16550 handelt es sich eigentlich um eine ganze Familie von UART-Geräten. Dazu gehören unter anderem der 16650, 16550A und 16550AFN (später als PC16550DN bezeichnet). Die Unterschiede zwischen diesen Chips liegen darin, ob die eingesetzten FIFOs tatsächlich funktionierten. Unter den genannten Chips ist der 16550AFN die sicherste Variante. Es gab auch mal einen NS16550; dessen FIFO hat nie wirklich funktioniert. Die UARTs 8250 und 16450 besaßen nur einen einfachen 1-Byte-Puffer. Ein 16450 löste daher für jedes zu übertragende Zeichen eine Unterbrechung (interrupt) aus. Jeder Interrupt benötigt eine gewisse Zeit, in der er verarbeitet wird. Diese kurze Verzögerung begrenzt die maximale, zuverlässige Datentransferrate des 16450 auf einem ISA-Bus-Rechner auf ungefähr 9.600 bps. In der voreingestellten Konfiguration überprüft der Kernel die Standartports COM1 bis COM4. Der Kernel ist auch in der Lage, die UARTs an den Standardports automatisch zu erkennen. Wird dabei ein 16550 erkannt, macht Linux vom erweiterten FIFO-Puffer Gebrauch.

1.

Beachten Sie bitte, daß wir hier nicht von WinModem™ reden! WinModems haben eine sehr einfache Hardware und nehmen dafür den Hauptprozessor Ihres Computers stark in Anspruch. Wenn Sie sich ein Modem kaufen wollen, empfehlen wir Ihnen dringend, auf keinen Fall ein WinModem zu nehmen. Kaufen Sie sich ein “echtes” Modem! Mittlerweile werden WinModems von Linux zwar auch unterstützt; sie werden dadurch aber auch nicht wesentlich attraktiver.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Hilfsmittel zur Konfiguration Nun befassen wir uns eine Weile mit den beiden nützlichsten Konfigurations-Hilfsmitteln für serielle Geräte: setserial und stty.

Der Befehl setserial Der Kernel gibt sich alle Mühe, selbst herauszufinden, wie Ihre serielle Hardware für einen reibungslosen Betrieb konfiguriert werden muß. Das ist wegen der Vielzahl unterschiedlicher Konfigurationen serieller Geräte aber ein schwieriges Unterfangen. Wo die Probleme liegen, hatten wir bereits bei den internen Modems kurz besprochen. Sie verwenden zwar einen UART mit 16-Byte-Puffer, der Gerätetreiber im Kernel meint aber, er hätte es nur mit einem 16450 zu tun. Wenn er nicht ausdrücklich darüber informiert wird, daß es sich um einen 16550 handelt, wird der Kernel vom erweiterten Puffer keinen Gebrauch machen. Ein anderes Beispiel sind die einfachen 4-Port-Karten, die IRQ-Sharing unterstützen, d.h., alle seriellen Geräte können sich einen Interrupt teilen. In diesem Fall muß der Kernel ausdrücklich darüber informiert werden, welcher Interrupt genutzt werden soll und daß Interrupts mehrfach genutzt werden können. Mit dem Befehl setserial können serielle Treiber zur Laufzeit des Systems konfiguriert werden. Normalerweise wird er während des Bootens von einem Skript aus gestartet. In einigen Distributionen hat das Skript den Namen 0setserial, in anderen rc.serial. Es ist verantwortlich dafür, den seriellen Gerätetreiber so zu initialisieren, daß er mit allen angeschlossenen seriellen Geräten zurechtkommt, die nicht dem üblichen Standard entsprechen. Die allgemeine Syntax von setserial ist: setserial device [parameters]

Dabei bezeichnet “device” ein serielles Gerät wie z.B. ttyS0. Der setserial-Befehl verfügt über eine große Anzahl von Parametern. Die gebräuchlichsten sind in Tabelle 4.1 beschrieben. Informationen zu den anderen Parametern finden Sie in der Manpage von setserial. Tabelle 4.1: setserial-Kommandozeilenparameter

Parameter

Beschreibung

Gibt die I/O-Portadresse des seriellen Geräts an. Portnummern sollten in hexadezimaler Notation port port_number angegeben werden, z.B. 0x2f8.

irq num

Gibt die Nummer des IRQs an, den das serielle Gerät verwendet.

uart uart_type

Gibt den UART-Typ des seriellen Geräts an. Übliche Werte sind 16450, 16550 usw. Ein Wert von none schaltet dieses serielle Gerät ab.

fourport

Die Angabe dieses Parameters teilt dem seriellen Kernel-Treiber mit, daß sich dieser Port an einer AST-Fourport-Karte befindet.

spd_hi

Programmiert den UART auf eine Geschwindigkeit von 57,6 Kbps, wenn ein Prozeß 38,4 Kbps verlangt.

spd_vhi

Programmiert den UART auf eine Geschwindigkeit von 115 Kbps, wenn ein Prozeß 38,4 Kbps verlangt.

spd_normal

auto_irq

autoconfig

skip_test

Programmiert den UART auf die Standardgeschwindigkeit von 38,4 Kbps, wenn eine Anfrage vorliegt. Dieser Parameter bewirkt die Umkehrung des Effekts eines spd_hi oder spd_vhi, das auf dem angegebenen seriellen Gerät vollzogen wird. Dieser Parameter veranlaßt den Kernel, den IRQ des angegebenen Geräts automatisch zu ermitteln. Dieser Versuch kann auch fehlschlagen, weshalb es sich bei der automatischen Ermittlung eher um ein Raten handelt. Ist Ihnen der IRQ des seriellen Geräts bekannt, sollten Sie besser den Befehl irq verwenden. Dieser Parameter muß immer in Verbindung mit dem port-Parameter angegeben werden und veranlaßt den Kernel, den UART-Typ an der angegebenen Portadresse automatisch herauszufinden. Ist auch auto_irq angegeben, versucht der Kernel, auch den IRQ automatisch zu ermitteln. Dieser Parameter veranlaßt den Kernel, auf den UART-Typ-Test während der automatischen Konfiguration zu verzichten. Das ist insbesondere dann notwendig, wenn der UART vom Kernel nicht korrekt erkannt wird.

Tabelle 4.1 zeigt, wie ein typisches, einfaches Beispiel einer rc-Datei zur Konfiguration Ihrer seriellen Ports zur Boot-Zeit aussehen könnte. Bei den meisten Linux-Distributionen wird ein solches Beispiel noch etwas ausführlicher gestaltet sein. Beispiel 4.1: rc.serial-Datei mit setserial-Anweisungen # /etc/rc.serial - serial line configuration script. # # Configure serial devices /sbin/setserial /dev/ttyS0 auto_irq skip_test autoconfig /sbin/setserial /dev/ttyS1 auto_irq skip_test autoconfig /sbin/setserial /dev/ttyS2 auto_irq skip_test autoconfig /sbin/setserial /dev/ttyS3 auto_irq skip_test autoconfig # # Display serial device configuration /sbin/setserial -bg /dev/ttyS*

Das Argument -bg /dev/ttyS* in der letzten Anweisung gibt eine hübsch formatierte Zusammenstellung der Hardwarekonfiguration aller aktiven seriellen Geräte aus. Die Ausgabe sieht etwa wie in Tabelle 4.2 aus. Beispiel 4.2: Ausgabe des Befehls setserial -bg /dev/ttyS /dev/ttyS0 at 0x03f8 (irq = 4) is a 16550A /dev/ttyS1 at 0x02f8 (irq = 3) is a 16550A

Der Befehl stty Der Name stty bedeutet wahrscheinlich “set tty” (“Setze tty”); dieser Befehl kann aber auch dazu benutzt werden, um eine Terminal-Konfiguration anzuzeigen. Verglichen mit setserial, bietet stty vielleicht eine noch verwirrendere Fülle an Konfigurationsmöglichkeiten. Die wichtigsten davon werden wir gleich behandeln, die anderen können Sie in der Manpage zu stty nachlesen. Der stty-Befehl wird meistens dazu verwendet, um Terminal-Parameter zu konfigurieren, z.B. ob Zeichen zurückgesendet (echo) werden sollen oder welche Taste ein Abbruchsignal erzeugen soll. Wir hatten bereits früher erwähnt, daß serielle Geräte tty-Geräte sind und der stty-Befehl daher auch für sie geeignet ist. Eine der wichtigeren Anwendungen von stty ist die Aktivierung des Hardware-Hand-shakes serieller Geräte. Über HardwareHandshakes hatten wir schon vorher kurz gesprochen. Standardmäßig ist der Hardware-Handshake serieller Geräte nichtaktiviert, so daß man mit dieser Voreinstellung mit dreiadrigen seriellen Kabeln arbeiten kann. Mit solche Kabeln läßt sich kein Hardware-Handshake realisieren; wäre er standardmäßig aktiviert, könnte auf dem Kabel nicht ein einziges Zeichen übertragen werden. Wenn Ihr Modem den Hardware-Handshake unterstützt, sollten Sie sicherstellen, daß dieser auch aktiviert ist (sehen Sie in Ihrem Modem-Handbuch nach, welche Kommandos Sie dafür brauchen). Überraschenderweise versuchen die wenigsten Kommunika-tionsprogramme dies einzustellen, weshalb Sie es unter Umständen per Hand tun -müssen. Auch Ihren seriellen Port müssen Sie auf Hardware-Handshake umstellen. Im stty-Befehl verwenden Sie dafür das crtscts-Flag. Diesen Befehl führen Sie am besten während des Bootens in der Datei rc.serial (oder einer vergleichbaren) aus, indem Sie Befehle, wie die in Tabelle 4.3 gezeigten, verwenden. Beispiel 4.3: stty-Befehle in der Datei rc.serial # stty crtscts < /dev/ttyS0 stty crtscts < /dev/ttyS1 stty crtscts < /dev/ttyS2 stty crtscts < /dev/ttyS3 #

Das stty-Kommando arbeitet standardmäßig immer mit dem aktuellen Terminal. Durch Eingabeumleitung (“<”) kann man aber jedes tty-Gerät mit dem stty-Befehl manipulieren. Es kommt häufig vor, daß man vergißt, wann man “<” oder “>” anzuwenden hat. Modernere Varianten des stty-Befehls haben in dieser Hinsicht eine viel übersichtlichere Syntax. Um das zu zeigen, formulieren wir unser Konfigurationsbeispiel etwas um. Das Ergebnis zeigt Tabelle 4.4. Beispiel 4.4: stty-Befehle mit moderner Syntax in der Datei rc.serial # stty crtscts -F /dev/ttyS0 stty crtscts -F /dev/ttyS1 stty crtscts -F /dev/ttyS2 stty crtscts -F /dev/ttyS3 #

Wir erwähnten bereits, daß stty auch dazu verwendet werden kann, die aktuelle Terminal-Konfiguration eines tty-Geräts anzuzeigen. Um sich alle aktiven Einstellungen eines tty-Geräts anzusehen, gehen Sie wie folgt vor: $ stty -a -F /dev/ttyS1

Die Ausgabe des Befehls (siehe Tabelle 4.5) zeigt den Status aller Flags für das angegebene Gerät an. Ein Flag mit einem Minuszeichen (wie in –crtscts) bedeutet, daß dieses Flag abgeschaltet ist. Beispiel 4.5: Ausgabe von stty -a speed 19200 baud; rows 0; columns 0; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Eine Beschreibung der wichtigsten Flags ist in Tabelle 4.2 enthalten. Ohne Minuszeichen wird ein Flag in einer sttyAnweisung immer aktiviert, mit Minuszeichen deak-tiviert. Um z.B. den Hardware-Handshake am ttyS0-Gerät abzuschalten, geben Sie -folgendes ein: $ stty -crtscts -F /dev/ttyS0

Tabelle 4.2: Die wichtigsten stty-Flags zur Konfiguration serieller Geräte Flags N crtsdts ixon

clocal

cs5 cs6 cs7 cs8 parodd parenb

cstopb

echo

Beschreibung Setzt die Übertragungsgeschwindigkeit auf N Bits pro Sekunde. Aktiviert bzw. deaktiviert das Hardware-Handshaking. Aktiviert bzw. deaktiviert XON/XOFF. Aktiviert bzw. deaktiviert Modem-Kontrollsignale wie DTR/DTS und DCD. Wichtig für dreiadrige serielle Kabel, da sie diese Signale nicht bereitstellen. Setzt die Anzahl der Datenbits auf 5, 6, 7 bzw. 8. Aktiviert ungerade Parität. Ein negiertes Flag bedeutet gerade Parität. Aktiviert Paritätstest. Ist dieses Flag negiert, wird keine Parität verwendet. Aktiviert die Verwendung von zwei Stopbits pro Zeichen. Bei negiertem Flag wird ein Stopbit pro Zeichen verwendet. Aktiviert bzw. deaktiviert die Rücksendung (Echo) des empfangenen Zeichens zum Sender.

Im folgenden Beispiel werden einige dieser Flags kombiniert, um das serielle Gerät ttyS0 auf 19.200 bps, 8 Datenbits, keine Parität, Hardware-Handshaking und deaktiviertes Echo einzustellen: $ stty 19200 cs8 -parenb crtscts -echo -F /dev/ttyS0

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Serielle Geräte und die Eingabeaufforderung login: Früher war es üblich, daß eine Unix-Installation aus einem einzigen Server mit vielen zeichenbasierten, “dummen” Terminals oder Dialup-Modems bestand. Solche Konstellationen wählt man heutzutage allerdings kaum noch. Da diese “dummen” Terminals mittlerweile zu Spottpreisen erhältlich sind, macht das die Sache gerade für solche Leute interessant, die sich ein Unix-System in der genannten Konstellation zusammenstellen wollen. Konfigurationen von Dialup-Modems sind heute nicht weniger verbreitet, allerdings werden sie heutzutage eher zum Einloggen in SLIP- oder PPP-Systeme verwendet (siehe Kapitel 7 Serial Line IP, und Kapitel 8 Das Point-to-Point-Protokoll) als für einfache Logins. Nichtsdestotrotz kann man in beiden Konfigurationen ein einfaches getty-Programm verwenden. Das Wort getty setzt sich vermutlich aus “get tty” zusammen. Ein getty-Programm öffnet ein serielles Gerät, führt an ihm (und am eventuell vorhandenen Modem) eine passende Konfiguration durch und wartet schließlich, bis eine Verbindung zustandekommt. Eine aktive Verbindung am seriellen Gerät wird normalerweise am “Data Carrier Detect Pin” (DCD) erkannt. Unmittelbar nach Verbindungsaufbau gibt das getty-Programm eine login:-Eingabeaufforderung aus, ruft das LoginProgramm des Systems auf und übergibt ihm die Kontrolle In Linux ist für jede virtuelle Konsole (z.B. /dev/tty1) jeweils ein eigener getty-Prozeß zuständig. Es gibt eine ganze Reihe unterschiedlicher Implementierungen von getty. Jede hat gegenüber einer anderen gewisse Vorzüge. Der getty-Befehl, den wir hier näher betrachten, wird mgetty genannt. Er ist relativ populär, da er gerade für Modems eine ganze Menge von Features enthält, z.B. Unterstützung von automatischen Faxprogrammen und Voice-Modems. Wir konzentrieren uns hier nur darauf, wie man mgetty für gewöhnliche Datenabrufe konfiguriert. Die Betrachtung weiterer Details überlassen wir gerne Ihrem Forscherdrang.

Konfiguration des mgetty-Dämons Der Quellcode des mgetty-Dämons ist unter ftp://alpha.greenie.net/pub/mgetty/source/ erhältlich und auch in den meisten LinuxDistributionen enthalten. Der mgetty-Dämon unterscheidet sich von den meisten anderen getty-Implementierungen dadurch, daß er speziell für Hayes-kompatible Modems ausgelegt ist. Er unterstützt zwar auch direkte Terminal-Verbindungen, ist aber für Dialup-Anwendungen am besten geeignet. Er verwendet zur Erkennung eines eingehenden Anrufs nicht die DCD-Leitung, sondern achtet auf die RING-Nachricht moderner Modems, die bei eingehenden Anrufen ausgelöst wird, sofern sie nicht auf automatische Anrufbeantwortung eingestellt sind. Das ausführbare Hauptprogramm ist /usr/sbin/mgetty, und seine Konfigurationsdatei ist /etc/mgetty/mgetty.config. Es gibt noch

eine Reihe weiterer Programme und Konfigura-tionsdateien für die anderen Features von mgetty. Um mgetty automatisch zu starten, braucht man in den meisten Installationen für die Konfiguration nur einige Änderungen in der Datei /etc/mgetty/mgetty.config vorzunehmen und einige passende Einträge in der Datei /etc/inittab hinzuzufügen. Tabelle 4.6 zeigt eine sehr einfache mgetty-Konfigurationsdatei. In diesem Beispiel werden zwei serielle Geräte konfiguriert. Das erste, /dev/ttyS0, unterstützt ein Hayes-kompatibles Modem mit 38.400 bps, das zweite, /dev/ttyS1, ein direkt angeschlossenes Terminal mit 19.200 bps. Beispiel 4.6: /etc/mgetty/mgetty.config # # mgetty configuration file # # this is a sample configuration file, see mgetty.info for details # # comment lines start with a "#", empty lines are ignored # # ----- global section ----- # # In this section, you put the global defaults, per-port stuff is below # # access the modem(s) with 38400 bps speed 38400 # # set the global debug level to "4" (default from policy.h) debug 4 # # ---- port specific section ----- # # Here you can put things that are valid only for one line, not the others # # # Hayes modem connected to ttyS0: don't do fax, less logging # port ttyS0 debug 3 data-only y # # direct connection of a VT100 terminal which doesn't like DTR drops # port ttyS1 direct y speed 19200 toggle-dtr n #

Die Konfigurationsdatei unterstützt sowohl globale als auch portspezifische Optionen. In unserem Beispiel verwenden wir eine globale Option, um die Übertragungsgeschwindigkeit auf 38.400 bps einzustellen. Dieser Wert wird an das Gerät ttyS0 “vererbt”. Alle Ports, auf die mgetty angewendet wird, verwenden diese Geschwindigkeit, wenn für sie nicht ausdrücklich eine andere portspezifische Geschwindigkeit angegeben ist — in etwa so, wie wir es bei der Konfiguration von ttyS1 getan haben. Das Schlüsselwort debug stellt die “Gesprächigkeit” der mgetty-Protokollausgaben ein. Das Schlüsselwort data-only in der ttyS0-Konfiguration veranlaßt mgetty, alle Faxmodem-Features zu ignorieren, so daß das Modem sich wie ein gewöhnliches Datenmodem verhält. Das Schlüsselwort direct in der ttyS1-Konfiguration weist mgetty an, das Modem am Port nicht zu initialisieren. Schließlich bewirkt das Schlüsselwort toggle-dtr, daß mgetty keinen Versuch unternimmt, die laufende Verbindung durch Absenken des DTR-Signals (Data Terminal Ready) an der seriellen Schnittstelle abzubrechen; manche Terminals mögen das einfach nicht. Wenn Sie wollen, können Sie die Datei mgetty.config auch leer lassen und dafür Kommandozeilenparameter verwenden, um die meisten der genannten Konfigurationsoptionen einzustellen. Die dem Programm beiliegende Dokumentation enthält eine vollständige Beschreibung der mgetty-Konfigurationsparameter und Kommandozeilenargumente. Siehe das folgende Beispiel. Um diese Konfiguration zu aktivieren, fügen wir zwei Einträge in die Datei /etc/inittab ein. Bei dieser Datei handelt es sich um die Konfigurationsdatei des init-Kommandos in Unix System V. Dieser Befehl ist verantwortlich für die Systeminitialisierung und enthält eine ganze Reihe von Anweisungen zum automatischen Start von Programmen während des Boot-Vorgangs bzw. zum Neustart von Programmen, die im laufenden Systembetrieb beendet werden. Das ist ideal für die Aufgaben, die ein gettyProgramm erfüllen soll. T0:23:respawn:/sbin/mgetty ttyS0 T1:23:respawn:/sbin/mgetty ttyS1

Jede Zeile der Datei /etc/inittab besteht aus vier Feldern, die durch Doppelpunkte voneinander getrennt sind. Das erste Feld enthält eine eindeutige Kurzbezeichnung und besteht traditionell aus zwei Zeichen, in modernen Systemen aus bis zu vier Zeichen. Das zweite Feld enthält eine Liste von Runleveln, in denen dieser Eintrag aktiv sein soll. Runlevel stellen gewissermaßen verschiedene Maschinenkonfigurationen dar. Sie werden in Form hierarchischer Baumstrukturen aus Startskripten implementiert, die in den Verzeichnissen /etc/rc1.d, /etc/rc2.d usw. abgelegt sind. Dieses Feature ist meistens sehr einfach implementiert. Sie sollten Ihre eigenen Einträge nach dem Vorbild der anderen Dateieinträge gestalten und für weitere Informationen auf Ihre Systemdokumentation zurückgreifen. Das dritte Feld beschreibt, wann eine Aktion ausgelöst werden soll. Für die Anwendung von getty sollte in dieses Feld ein respawn eingetragen werden, was bedeutet, daß das Programm automatisch neu gestartet wird, sobald es aus irgendeinem Grund endet. Es gibt noch viele andere Optionen, sie sind aber für unsere Zwecke hier nicht weiter interessant. Das vierte Feld zeigt an, welcher Befehl ausgeführt werden soll. Dies ist der Ort, an dem wir das mgetty-Kommando mit den gewünschten Argumenten angeben. In unserem einfachen Beispiel starten wir mgetty immer dann (neu), wenn das System im Runlevel 2 oder 3 operiert. Als Argument geben wir nur das serielle Gerät an, das wir benutzen wollen. mgetty geht automatisch vom Verzeichnis /dev/ aus, so daß wir es nicht einzugeben brauchen.

So, das war eine schnelle Einführung in die Anwendung von mgetty und wie man seriellen Geräten LoginEingabeaufforderungen zur Verfügung stellt. Weiterführende Informationen finden Sie im Serial-HOWTO. Nachdem Sie die Konfigurationsdateien geändert haben, müssen Sie dafür sorgen, daß init die geänderte Konfiguration neu einliest, damit die Änderungen wirksam werden. Senden Sie dazu einfach nur ein Hangup-Signal (HUP) an den init-Prozeß. Er hat grundsätzlich eine Prozeß-ID von 1, so daß Sie bedenkenlos immer folgenden Befehl ausführen können: # kill -HUP 1

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 5 TCP/IP-Konfiguration

In diesem Kapitel befassen wir uns mit den Schritten, die nötig sind, um Ihr Linux-System für TCP/IP einzurichten. Angefangen mit der Zuordnung von IP-Adressen, arbeiten wir uns langsam durch die Konfiguration der Netzwerkschnittstellen und stellen einige Werkzeuge vor, die recht nützlich sind, um eventuellen Problemen mit Ihrer Netzwerkinstallation nachzuspüren. Den Großteil der Tätigkeiten, die dieses Kapitel behandelt, werden Sie nur einmal erledigen müssen.

Danach müssen Sie sich mit den meisten Konfigurationsdateien nur noch dann beschäftigen, wenn Sie eine neue Maschine zu Ihrem Netz hinzufügen oder wenn Sie Ihr System völlig neu konfigurieren. Einige der Befehle, die zur Initialisierung von TCP/IP dienen, müssen allerdings jedesmal ausgeführt werden, wenn Ihr System bootet. Dies geschieht normalerweise durch die /etc/rc*-Skripten. Für gewöhnlich ist der netzwerkspezifische Teil der Boot-Prozedur in einem Skript enthalten. Der Name dieses Skripts variiert in den verschiedenen Linux-Distributionen. In vielen älteren LinuxDistributionen ist es unter dem Namen /etc/rc.net oder /etc/rc.inet bekannt. Manchmal werden Sie auch zwei Skripten namens rc.inet1 und rc.inet2 vorfinden, wobei ersteres den Kernel-Teil des Netzwerkcodes initialisiert und letzteres die wichtigsten Netzwerkdienste und -applikationen startet. In den modernen Distributionen sind die rc-Dateien etwas besser organisiert. Hier finden Sie im Verzeichnis /etc/init.d/ (oder /etc/rc.d/init.d/) neben den Skripten, die die Netzwerkschnittstellen erzeugen, auch die Skripte, die die Netzwerk-Applikationsprogramme starten. Die Beispiele in diesem Buch beziehen sich auf letztere Anordnung. Dieses Kapitel befaßt sich mit einigen Teilen des Skripts, das Ihre Netzwerkschnittstellen konfiguriert. Die Applikationen werden erst später behandelt. Am Ende dieses Kapitels werden Sie eine Reihe von Befehlen kennengelernt haben, die das TCP/IP-Netzwerk Ihres Computers ordnungsgemäß konfigurieren. Die Beispielanweisungen müssen Sie für Ihre eigenen Skripten entsprechend anpassen. Stellen Sie sicher, daß das Startskript Ihres Rechners vom Ausgangsskript rc aus gestartet wird, und booten Sie dann den Rechner neu. Die rc-Netzwerkskripten Ihrer LinuxDistribution sollten einige aussagekräftige Beispiele enthalten, die Sie als Ausgangsbasis für Ihre eigene Netzwerkkonfiguration übernehmen können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Einrichten des /proc-Dateisystems Einige der Konfigurationswerkzeuge der NET-2- und NET-3-Ausgaben für Linux benutzen das /procDateisystem als Basis ihrer Kommunikation mit dem Kernel. Diese Schnittstelle stellt einen dateisystemähnlichen Mechanisms als Zugang zu den Laufzeitinformationen des Kernels zur Verfügung. Sobald dieses Dateisystem angebunden ist, können Sie die in ihr enthaltenen Dateien wie in jedem anderen Dateisystem ganz normal auflisten oder ihren Inhalt anzeigen. Typische Dateien sind z.B. loadavg, die die durchschnittliche Systemauslastung (load average) enthält, und meminfo, die ein Abbild des gesamten Kernspeichers enthält und Auskünfte über den aktuellen Bedarf an Swap-Speicher gibt. Dem fügt der Netzwerkcode das Verzeichnis net hinzu. Es enthält eine Reihe von Dateien, die Dinge wie die ARP-Tabellen, den Zustand aller TCP-Verbindungen und die Routing-Tabellen enthalten. Die meisten Administrations-Werkzeuge aus dem Netzwerkbereich erhalten ihre Informationen aus diesen Dateien. Das proc-Dateisystem (auch als procfs bekannt) wird normalerweise während des Systemstarts an das Verzeichnis /proc gebunden. Am besten machen Sie das, indem Sie die folgende Zeile in /etc/fstab einfügen: # procfs mount point: none

/proc

proc

defaults

Anschließend müssen Sie nur noch den Befehl mount /proc von Ihrer /etc/rc-Datei aus aufrufen. Heutzutage ist procfs in den meisten vorkompilierten Kerneln bereits eingebunden. Wenn Ihr Kernel

procfs wider Erwarten nicht enthalten sollte, sehen Sie eine Meldung wie mount: fs type procfs not supported by kernel. In diesem Fall müssen Sie einen neuen Kernel bauen und mit “y” antworten, wenn Sie nach Unterstützung für procfs gefragt werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Installation der Programme Wenn Sie eine der vorkonfigurierten Linux-Distributionen benutzen, enthält sie sehr wahrscheinlich die größeren Netzwerkapplikationen und Dienstprogramme mitsamt einem Satz von Konfigurationsbeispielen. Die einzige Gelegenheit, bei der Sie diese Programme unter Umständen durch neuere ersetzen müssen, ergibt sich bei der Installation eines neuen Kernels. Da neue KernelVersionen manchmal auch Veränderungen der Netzwerkschnittstelle mit sich bringen, kann es passieren, daß die alten Programme seltsame Fehlermeldungen bringen, nur halb funktionieren oder im harmlosesten Fall einfach die neuesten Funktionen noch nicht unterstützen. Das bedeutet auf jeden Fall, daß Sie die wichtigsten Programme wie ifconfig, route usw. neu kompilieren müssen, manchmal benötigen Sie aber auch eine ganz neue Version. Sie finden diese Programme unter ftp.inka.de/pub/comp/Linux/networking/NetTools/ in einem Archiv namens net-tools-XXX.tar.gz, wobei XXX die Versionsnummer des frühesten Kernels ist, ab dem sie gültig sind. Für Linux 2.0 eignen sich die Versionen ab net-tools-1.45. Wenn Sie bestimmte Standard-TCP/IP-Netzwerkapplikationen selbst kompilieren und installieren wollen, finden Sie die Quellen dafür auf den meisten Linux-FTP-Servern. Alle modernen LinuxDistributionen enthalten eine ziemlich umfassende Sammlung von TCP/IP-Netzwerkprogrammen wie WWW-Browser, telnet- und ftp-Programme sowie andere Netzwerkprogramme wie talk. Wenn Sie etwas finden, das sie nicht direkt installieren können, sondern erst kompilieren müssen, stehen die Chancen gut, daß es sich unter Linux recht einfach kompilieren läßt, wenn Sie sich an die

Anweisungen zur Software halten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Setzen des Hostnamens Die meisten, wenn nicht gar alle Netzwerkapplikationen verlassen sich darauf, daß der Name Ihrer Maschine einen sinnvollen Wert hat. Er wird im Normalfall während der Boot-Prozedur mit dem Befehl hostname gesetzt. Um den Hostnamen auf name zu setzen, geben Sie folgendes ein: # hostname name

Es ist üblich, den unqualifizierten Namen ohne jede Domain-Angabe zu verwenden. Die Rechner der in Anhang 1 Beispielnetzwerk: Die virtuelle Brauerei, beschriebenen virtuellen Brauerei könnten beispielsweise vlager.vbrew.com, vale.vbrew.com usw. heißen. Das sind ihre offiziellen, voll qualifizierten Hostnamen. Die jeweils erste Komponente wird nun oft für den lokalen Hostnamen benutzt, wie z.B. vlager. Da dieser lokale Name aber häufig dann verwendet wird, wenn eine Applikation die IP-Adresse des Rechners, auf dem sie läuft, herausfinden will, müssen Sie sicherstellen, daß der Resolver diesen Namen kennt. Das bedeutet im allgemeinen, daß Sie diesen Namen in der Datei /etc/hosts eintragen müssen. Manche Leute schlagen vor, mit dem Befehl domainname dem Kernel die Domain-Komponente des Hostnamens mitzuteilen, so daß man anschließend die Ausgabe von hostname und domainname einfach nur kombinieren müßte, um wieder den vollständigen Namen zu erhalten. Das ist bestenfalls zur Hälfte richtig, da der Befehl domainname eigentlich nur die NIS-Domain Ihres Systems festlegt,

die mit der DNS-Domain, der Ihr Rechner angehört, nicht viel zu tun haben muß. (NIS wird in Kapitel 13 Das Network Information System, behandelt.) Um sicherzustellen, daß die Kurzform Ihres Hostnamens von allen aktuellen Versionen des hostname-Programms aufgelöst werden kann, tragen Sie sie in Ihren lokalen Domain Name Server ein oder schreiben Sie den voll qualifizierten Domainnamen in die Datei /etc/hosts. Sie können dann den hostname-Befehl mit dem Argument fqdn aufrufen, um den voll qualifizierten Domainnamen auszugeben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Adressen zuweisen Wenn Sie Ihren Rechner für den Standalone-Betrieb konfigurieren (zum Beispiel, um nur das Newssystem INN laufen zu lassen), können Sie diesen Abschnitt getrost überspringen. In diesem Fall brauchen Sie nur eine einzige IP-Adresse für das Loopback-Interface, die immer 127.0.0.1 lautet. In echten Netzen wie einem Ethernet liegen die Dinge ein wenig komplizierter. Wenn Sie sich an ein existierendes Netz anschließen wollen, müssen Sie dessen Administratoren bitten, Ihnen eine IPAdresse zuzuweisen. Wenn Sie aber Ihr eigenes Netz aufbauen, müssen Sie selbst die Adressen verteilen, wie im folgenden näher beschrieben wird. Alle Hosts innerhalb eines lokalen Netzes sollten üblicherweise Adressen aus demselben logischen IPNetz verwenden. Daher müssen Sie Ihrem Netz zuerst eine IP-Netzwerkadresse zuweisen. Wenn Ihre Installation aus mehreren physikalisch unabhängigen Teilnetzen besteht, benötigen Sie für jedes Teilnetz eine eigene Adresse. In den allermeisten Fällen werden Sie zu diesem Zweck den zur Verfügung stehenden Adreßbereich in mehrere Subnetze unterteilen. Wie man das macht, beschreibt Einrichten von Subnetzen. Was für eine IP-Adresse Sie wählen, hängt stark davon ab, ob Sie in naher Zukunft den Sprung ins Internet planen oder nicht. Wenn ja, sollten Sie bereits jetzt eine offizielle Internetadresse beantragen, da Ihnen das später eine mühselige Neueinrichtung Ihres Netzes erspart. Der beste Weg ist, Ihren

Service-Anbieter dabei um Hilfe zu bitten. Wenn Sie eine IP-Adresse nur für den Fall beantragen wollen, daß Sie Ihr Netz irgendwann einmal ans Internet anschließen werden, sollten Sie sich einen IPAdreßantrag von Ihrem Netzwerk-Provider oder von [email protected] besorgen. Ist Ihr Netz nicht mit dem Internet verbunden und wird es auch in Zukunft nicht sein, können Sie sich theoretisch eine völlig beliebige Adresse aussuchen. Sie müssen nur sicherstellen, daß keine Pakete aus Ihrem internen Netz ins Internet entkommen können. Um völlig sicherzugehen, daß kein Schaden entsteht, selbst wenn dies einmal passieren sollte, sollten Sie eines der IP-Netze verwenden, die für die private Nutzung reserviert sind. Die Internet Assigned Numbers Authority (IANA — so etwas wie die Zulassungsstelle für die Datenautobahn) hat mehrere Netzwerknummern der Kategorien A, B und C reserviert, die Sie benutzen können, ohne sie registrieren zu müssen. Diese Adressen sind nur innerhalb Ihres privaten Netzes gültig und werden nicht zwischen echten Internetsystemen geroutet. Die Adressen sind in RFC 1597 definiert und in Tabelle 2.1 in Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, aufgelistet. Beachten Sie bitte, daß der zweite und dritte Block 16 bzw. 256 Netzwerke enthält. Allerdings ist es nicht nur dann sinnvoll, eine Adresse aus diesem Bereich zu wählen, wenn Ihr Netz völlig vom Internet abgeschnitten ist; ein solches Netz hilft Ihnen auch, den Zugriff von außen auf Maschinen in Ihrem Netz auf ein einzelnes Gateway zu beschränken. Innerhalb Ihres Netzes wäre das Gateway über seine interne Adresse von allen Maschinen aus erreichbar, während es der Außenwelt unter seiner offiziellen Adresse (wie vom Provider vergeben) bekannt wäre. Fremde Systeme könnten aber im allgemeinen Rechner innerhalb Ihres Netzes nicht erreichen, da deren Adressen im Internet nicht geroutet werden. Auf dieses Konzept kommen wir noch in Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen, zurück, wenn wir uns mit dem IP-Masquerading beschäftigen. Im folgenden werden wir annehmen, daß die Netzwerkadministratorin der Brauerei eine IP-Adresse der Kategorie B verwendet, z.B. 172.16.0.0. Natürlich würde ein Netz der Klasse C für alle Systeme der Brauerei und der Kellerei vollkommen ausreichen. Wir verwenden hier nur der Einfachheit halber ein Klasse-B-Netz, da es die Bildung der Subnetze leichter verständlich macht.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Einrichten von Subnetzen Um mehrere Ethernets (oder andere Netzwerke, je nach verfügbarem Treiber) in einem IP-Netz zu betreiben, müssen Sie Ihren Adreßbereich in Subnetze unterteilen (subnettieren). Bitte beachten Sie, daß eine Unterteilung in Subnetze nur notwendig wird, wenn Sie mehr als ein Broadcast-Netz haben; Punkt-zu-Punkt-Verbindungen wie SLIP und PPP zählen hier nicht. Wenn Sie beispielsweise ein Ethernet und eine oder mehrere SLIP-Verbindungen in die weite Welt unterhalten, besteht kein Bedarf an mehreren Subnetzen. Warum das so ist, werden wir später in Kapitel 7 Serial Line IP, erläutern. Um zwei Ethernets bedienen zu können, entscheidet sich die Netzadministratorin der Brauerei, 8 Bits des Hostteils der Adresse als zusätzliche Subnetz-Bits zu verwenden. Damit bleiben weitere 8 Bit für den Hostteil, womit pro Subnetz 254 Adressen möglich sind. Der Brauerei teilt sie das Subnetz 1 zu und der Kellerei Subnetz 2. Die jeweiligen Netzwerkadressen sind dann 172.16.1.0 und 172.16.2.0, und die Netzmaske ist 255.255.255.0. vlager, das als Gateway zwischen den zwei Netzen fungiert, erhält auf beiden jeweils die Hostnummer 1, was eine IP-Adresse von 172.16.1.1 bzw. 172.16.2.1 ergibt. Beachten Sie, daß wir in diesem Beispiel der Einfachheit halber ein Klasse-B-Netzwerk verwenden, obwohl ein Klasse-C-Netzwerk realistischer wäre. Im neuen Netzwerkcode ist Subnetting nicht mehr

durch Bytegrenzen eingeschränkt, so daß sogar Klasse-C-Netzwerke in diverse Subnetze aufgeteilt werden können. Somit können Sie zum Beispiel zwei Bits des Hostteils für die Netzmaske verwenden, um so bis zu vier Subnetze mit jeweils bis zu 64 Hosts zu erhalten.1

1.

Die erste Nummer jedes Subnetzes ist die Subnetzadresse, während die letzte Nummer jedes Subnetzes für die Broadcast-Adresse reserviert wird. Daher sind es eigentlich nur 62 Hosts pro Subnetz.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Erzeugen von Host- und Netzwerkdateien Nachdem Sie Ihr Netz in Subnetze unterteilt haben, sollten Sie eine einfache Art der Namensauflösung konfigurieren, die auf der Datei /etc/hosts basiert. Wenn Sie nicht vorhaben, DNS oder NIS zu benutzen, müssen Sie sogar sämtliche Maschinen in Ihrem Netz in dieser Datei eintragen. Aber auch, wenn Sie im normalen Betrieb DNS oder NIS einsetzen, ist es empfehlens-wert, einen Teil der Rechnernamen in /etc/hosts zu haben. Oft möchte man nämlich auch während des Bootens, wenn noch keine Netzwerkschnittstellen aktiv sind, symbolische Namen verwenden, beispielsweise in den rc-Skripten.Sollten Sie einmal gezwungen sein, IP-Adressen zu ändern, müssen Sie nur noch die modifizierte hosts-Datei auf allen Rechnern installieren und die Systeme neu starten, anstatt sämtliche rc-Dateien von Hand zu editieren. Normalerweise werden Sie alle lokalen Rechner in /etc/hosts eintragen, zusammen mit eventuell vorhandenen Gateways und NIS-Servern.1 Außerdem sollten Sie während der anfänglichen Testphase nur Informationen aus der hosts-Datei verwenden. In manchen Distributionen enthalten die Konfigurationsdateien für NIS und DNS Beispiele, die für seltsame Effekte sorgen können, wenn sie verwendet werden. Um sicherzustellen, daß alle Applikationen ausschließlich /etc/hosts verwenden, um die Adresse eines Systems zu suchen, müssen Sie die Datei /etc/host.conf editieren. Kommentieren Sie alle Zeilen aus, die mit dem Schlüsselwort order beginnen, indem Sie ein Doppelkreuz voranstellen, und fügen Sie folgende Zeile ein: order hosts

Die Konfiguration der Resolver-Bibliothek wird ausführlich in Kapitel 6 Name-Server- und Resolver-Konfiguration, behandelt. Die Datei hosts enthält einen Eintrag pro Zeile, bestehend aus der IP-Adresse, dem Hostnamen und einer optionalen Liste von Aliasen für den Hostnamen. Die Felder sind durch Leerzeichen oder Tabulatoren voneinander getrennt, und das Adreßfeld muß in Spalte eins beginnen. Ein Doppelkreuz (#) leitet immer einen Kommentar ein. Namen können entweder voll qualifiziert oder relativ zur lokalen Domain sein. Für vale würden Sie beispielsweise sowohl den vollständigen Namen vale.vbrew.com eintragen als auch vale ohne Domain-Angabe, so daß das System sowohl unter seinem offiziellen als auch unter dem kürzeren lokalen Namen bekannt ist. Das folgende Beispiel zeigt, wie die Datei hosts in der virtuellen Brauerei aussehen könnte. Neben den normalen Namen sehen

Sie zwei spezielle Einträge, vlager-if1 und vlager-if2, die die Adressen für die beiden Schnittstellen des Gateway-Systems vlager festlegen. # # Hostdatei fuer die virtuelle Brauerei und die virtuelle Kellerei # # IP FQDN Aliase # 127.0.0.1 localhost # 172.16.1.1 vlager.vbrew.com vlager vlager-if1 172.16.1.2 vstout.vbrew.com vstout 172.16.1.3 vale.vbrew.com vale # 172.16.2.1 vlager-if2 172.16.2.2 vbeaujolais.vbrew.com vbeaujolais 172.16.2.3 vbardolino.vbrew.com vbardolino 172.16.2.4 vchianti.vbrew.com vchianti

Genau wie für IP-Adressen möchte man manchmal auch symbolische Namen für Netzwerknummern verwenden. Aus diesem Grunde gibt es parallel zu /etc/hosts die Datei /etc/networks, um Netzwerknamen auf Netzwerknummern abzubilden und umgekehrt. In der virtuellen Brauerei würden wir etwa folgende networks-Datei installieren:2 # /etc/networks fuer die virtuelle Brauerei und die virtuelle Kellerei brew-net wine-net 172.16.2.0

172.16.1.0

1.

Die Adresse eines NIS-Servers brauchen Sie nur, wenn Sie das NYS von Peter Eriksson verwenden. Andere NISImplementierungen lokalisieren ihre Server zur Startzeit mit Hilfe des Programms ypbind.

2.

Beachten Sie, daß die Namen in networks nicht mit den Hostnamen in der Datei hosts übereinstimmen und kollidieren, da manche Programme ansonsten merkwürdige Resultate produzieren können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Schnittstellenkonfiguration für IP Nachdem Sie Ihre Hardware, wie in Kapitel 4 Konfiguration der seriellen Hardware, beschrieben, eingerichtet haben, müssen Sie sie der Netzwerkebene des Kernels bekanntmachen. Zur Konfiguration der Schnittstellen und Initialisierung der RoutingTabelle sind zwei Befehle von besonderer Bedeutung, nämlich ifconfig (wobei “if” für Interface steht) und route. Sie werden normalerweise bei jedem Systemstart aus den Netzwerk-Startskripten heraus aufgerufen. ifconfig dient dazu, eine Schnittstelle für die Netzwerkschicht des Kernels sichtbar zu machen. Das beinhaltet die Zuweisung einer IP-Adresse und verschiedener anderer Parameter sowie die Aktivierung (“bringing up”) der Schnittstelle, damit der Kernel die IP-Pakete über diese Schnittstelle senden und empfangen kann. Die einfachste Art, es aufzurufen, ist: ifconfig interface ip-address

Das weist interface die Adresse ip-adresse zu und aktiviert es. Alle anderen Parameter werden auf Standardwerte gesetzt. Die Netzmaske zum Beispiel wird aus der Netzwerkklasse der Adresse abgeleitet; für ein Klasse-B-Netz wäre das 255.255.0.0. Wir werden uns in Alles über ifconfig noch ausführlicher mit ifconfig befassen. route erlaubt es Ihnen, Routen in die Routing-Tabelle des Kernels einzutragen oder aus ihr zu entfernen. Es kann aufgerufen werden als: route [add|del] [-net|-host] target [if]

Dabei bestimmen die Argumente add bzw. del, ob die Route zu target eingetragen bzw. aus target entfernt wird. Die Optionen -net und -host teilen dem route-Kommando mit, ob target ein Netzwerk oder ein Hostrechner ist (letzteres wird angenommen, wenn Sie hier nichts angeben). Das Argument if ist optional und erlaubt Ihnen die Angabe einer Netzwerkschnittstelle, an die die Route gerichtet werden soll. Wenn Sie dem Kernel keine Informationen darüber geben, versucht er selbst, ein sinnvolles Argument herauszufinden. Damit beschäftigen wir uns ausführlicher in den nachfolgenden Abschnitten.

Das Loopback-Interface Die allererste Schnittstelle, die aktiviert werden muß, ist das Loopback-Interface:

# ifconfig lo 127.0.0.1

Manchmal wird anstelle der IP-Adresse auch der Name localhost verwendet. Der Befehl ifconfig sucht diesen Namen in der Datei hosts, wo er als Hostname für 127.0.0.1 definiert sein sollte: # Sample /etc/hosts-Eintrag fuer localhost localhost

127.0.0.1

Um die Konfiguration einer Schnittstelle anzuzeigen, rufen Sie ifconfig nur mit dem Namen der Schnittstelle auf: $ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 Collisions:0

Hier wird der Loopback-Schnittstelle die Netzmaske 255.0.0.0 zugewiesen, weil 127.0.0.1 eine Klasse-A-Adresse ist. Jetzt können Sie fast schon anfangen, mit Ihrem “Mini-Netz” herumzuspielen. Was noch fehlt, ist ein Eintrag in der RoutingTabelle, der festlegt, daß diese Schnittstelle als Route für das Zielsystem 127.0.0.1 dient. Dazu geben Sie folgendes ein: # route add 127.0.0.1

Natürlich können Sie auch hier wieder anstelle der IP-Adresse den Namen localhost verwenden, sofern Sie ihn in /etc/hosts eingetragen haben. Als nächstes sollten Sie sich mit dem Programm ping davon überzeugen, daß alles einwandfrei funktioniert. ping ist das netztechnische Äquivalent eines Sonars1 und wird benutzt, um festzustellen, ob ein System überhaupt erreichbar ist und wie lange ein Paket zu diesem System und zurück benötigt. Diese Zeit wird auch oft als round-trip time bezeichnet. # ping localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.4 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.4 ms ^C --- localhost ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 0.4/0.4/0.4 ms #

Wenn Sie ping wie hier gezeigt aufrufen, sendet es fortwährend Pakete aus, bis Sie es unterbrechen. Das ^C markiert die Stelle, an der wir Strg-C gedrückt haben. Das obige Beispiel zeigt, daß Pakete an 127.0.0.1 korrekt ausgeliefert werden und nahezu augenblicklich eine Antwort an ping zurückgeschickt wird. Das beweist, daß Sie Ihre erste Netzwerkschnittstelle erfolgreich konfiguriert haben. Wenn ping eine völlig andere Ausgabe produziert, als hier dargestellt, haben Sie ein echtes Problem. Prüfen Sie, ob irgendwelche Fehlermeldungen nahelegen, daß eine Datei nicht korrekt installiert worden ist. Prüfen Sie außerdem, ob die verwendeten Programme ifconfig und route mit Ihrer Kernel-Version kompatibel sind, und vor allem, ob der Kernel mit Netzwerkunterstützung übersetzt wurde (letzteres erkennen Sie an der Existenz des Verzeichnisses /proc/net). Wenn Sie eine Fehlermeldung bekommen, die sinngemäß “Network Unreachable” lautet, haben Sie sich wahrscheinlich beim routeKommando vertippt. Sie müssen hier auf jeden Fall dieselbe Adresse angeben wie bei ifconfig. Die bisher beschriebenen Schritte reichen aus, um Netzwerkapplikationen auf einem alleinstehenden Rechner zu benutzen. Nachdem Sie die oben angegebenen Zeilen in Ihr Netzwerk-Initialisierungsskript eingetragen und sichergestellt haben, daß es beim Systemstart ausgeführt wird, können Sie Ihre Maschine neu booten und einige Applikationen ausprobieren. Zum Beispiel sollte telnet localhost eine telnet-Verbindung aufbauen und Ihnen den Login-Prompt Ihres Systems geben. Das Loopback-Interface ist allerdings nicht nur als Beispiel in Netzwerkbüchern oder als Testumgebung während der Softwareentwicklung nützlich, sondern wird auch von einigen Applikationen während des normalen Betriebs benutzt.2 Deshalb müssen Sie es auf jeden Fall konfigurieren, unabhängig davon, ob Ihre Maschine an ein Netz angeschlossen ist oder nicht.

Ethernet-Schnittstellen

Die Konfiguration von Ethernet-Schnittstellen geht fast genauso vonstatten wie bei den Loopback-Schnittstellen. Sie brauchen nur ein paar Parameter mehr, um Subnetze verwenden zu können. In der virtuellen Brauerei haben wir das IP-Netz, das ursprünglich ein Klasse-B-Netz war, in C-Subnetze unterteilt. Um das dem Interface mitzuteilen, sieht der ifconfig-Aufruf so aus: # ifconfig eth0 vstout netmask 255.255.255.0

Dies weist der Schnittstelle eth0 die IP-Adresse von vstout zu (172.16.1.2). Hätten wir die Netzmaske weggelassen, hätte ifconfig sie aus der Netzklasse der Adresse abgeleitet, was den inkorrekten Wert von 255.255.0.0 ergeben hätte. Ein schneller Test ergibt jetzt: # ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0

Wie Sie sehen, hat ifconfig die Broadcast-Adresse (im Bcast-Feld angezeigt) automatisch auf den üblichen Wert gesetzt, nämlich die Netzwerknummer mit einem Hostteil, bei dem alle Bits auf eins gesetzt sind. Außerdem wurde die maximale Übertragungseinheit (MTU — Maximum Transmission Unit, die maximale Größe der IP-Pakete, die der Kernel auf dieser Schnittstelle ausgibt) auf das Ethernet-spezifische Maximum von 1.500 Bytes eingestellt. Das sind die Werte, die Sie üblicherweise auch benutzen. Sie können aber über spezielle Optionen auch mit anderen Werten besetzt werden; diese Optionen beschreiben wir in Alles über ifconfig. Wie es bereits bei der Loopback-Schnittstelle der Fall war, müssen Sie jetzt eine Route eintragen, die dem Kernel mitteilt, welches Netz durch eth0 erreicht werden kann. Für die virtuelle Brauerei würden Sie route so aufrufen: # route add -net 172.16.1.0

Auf den ersten Blick sieht das ein wenig wie Schwarze Magie aus, da nicht ohne weiteres klar ist, wie route eigentlich wissen soll, daß wir hiermit die Ethernet-Schnittstelle meinen. Der Trick ist aber relativ simpel: Der Kernel prüft alle bisher konfigurierten Interfaces und vergleicht das Zielnetz (in unserem Fall 172.16.1.0) mit der Netznummer der Interface-Adresse, d.h. dem bitweisen UND der Interface-Adresse und der Netzmaske. Die einzige Schnittstelle, bei der diese beiden Werte übereinstimmen, ist eth0. Aber was soll dann die Option –net? Sie wird nötig, da route sowohl Routen zu Netzwerken als auch zu einzelnen Hosts einrichten kann, wie Sie bereits am Beispiel der local-host-Route gesehen haben. Wenn Sie route eine IP-Adresse in Dezimalnotation übergeben, versucht es zu erraten, ob es sich dabei um eine Host- oder Netzadresse handelt, indem es den Hostteil betrachtet. Ist der Hostteil null, nimmt es an, daß die Adresse ein Netz bezeichnet, andernfalls behandelt es sie als Hostadresse. Deshalb würde route in unserem Beispiel davon ausgehen, daß 172.16.1.0 eine Hostadresse ist, denn es kann ja nicht wissen, daß wir Subnetze verwenden. Darum müssen Sie ihm ausdrücklich mitteilen, daß sie ein Netzwerk bezeichnet, indem Sie –net verwenden. Natürlich können Sie es auch einfacher haben, indem Sie zum Beispiel die Netzwerknamen benutzen, die wir oben in /etc/networks definiert haben. Das hat nicht nur die bekannten Vorteile bei einer Umstrukturierung Ihres Netzes, sondern macht den Befehl auch wesentlich lesbarer. Sie können nun sogar die Option –net weglassen, da route jetzt weiß, daß brewnet ein Netzwerk bezeichnet. # route add brew-net

Nachdem Sie die grundlegenden Konfigurationsschritte hinter sich gebracht haben, sollten Sie überprüfen, ob Ihr Ethernet tatsächlich fröhlich vor sich hinarbeitet. Wählen Sie irgendeine Maschine auf Ihrem lokalen Ethernet, z.B. vlager, und geben Sie folgenden Befehl ein: # ping vlager PING vlager: 64 byte bytes from 172.16.1.1: icmp_seq=1. bytes from 172.16.1.1: icmp_seq=3. transmitted, 4 packets received, 0

packets 64 time=7. ms time=3. ms round-trip

bytes from 172.16.1.1: icmp_seq=0. time=11. ms 64 64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms 64 ^C ----vstout.vbrew.com PING Statistics---- 4 packets (ms) min/avg/max = 3/8/12

Wenn sich die Ausgabe auf Ihrem Bildschirm deutlich von dem unterscheidet, was Sie hier sehen, ist offensichtlich irgend etwas schiefgelaufen. Ungewöhnlich hoher Datenverlust weist auf ein Hardwareproblem hin, wie beispielsweise ungenügende oder fehlende Terminierung. Wenn ping keinerlei Pakete zurückempfängt, sollten Sie die Schnittstellenkonfiguration mit netstat überprüfen, das später in Der Befehl netstat beschrieben wird. Die Paketstatistiken, die ifconfig ausgibt, sagen Ihnen, ob überhaupt Pakete über das Interface übertragen wurden.Wenn Sie außerdem Zugang zum Zielrechner Ihres ping-Versuchs haben, sollten Sie auch auf diesem die Paketstatistiken der Maschine prüfen. So können Sie genau feststellen, wo die Pakete verlorengegangen sind. Zusätzlich sollten Sie auf beiden Maschinen mit route die Routing-Informationen überprüfen, um festzustellen, ob beide Maschinen über den richtigen Routeeintrag verfügen. Wenn Sie route ohne weitere Parameter aufrufen, gibt es die Routing-Tabellen des Kernels aus. Die Option –n sorgt dafür, daß es Adressen in Dezimalnotation anstelle der symbolischen Hostnamen darstellt: # route -n Kernel routing table Destination Gateway 127.0.0.1 * 255.255.255.255 UH 1 0 255.255.255.0 U 1 0 10 eth0

Genmask Flags Metric Ref Use 112 lo 172.16.1.0 *

Iface

Die genaue Bedeutung der einzelnen Felder wird weiter unten im Abschnitt Der Befehl netstat erklärt. Die mit Flags betitelte Spalte enthält eine Liste von Flags für jedes Interface. U ist für aktive Schnittstellen immer gesetzt. Ein Flag H in dieser Spalte besagt, daß die Zieladresse einen einzelnen Host bezeichnet.Falls das H-Flag für eine Route gesetzt ist, die Sie als Netzwerkroute vorgesehen haben, müssen Sie den Befehl route wiederholt ausführen, zusammen mit der Option –net. Um festzustellen, ob eine von Ihnen eingetragene Route überhaupt benutzt wird, sehen Sie nach, ob sich der Wert im Use-Feld in der vorletzten Spalte zwischen zwei ping-Aufrufen erhöht.

Routing durch ein Gateway Im vorigen Abschnitt hatten wir uns nur damit beschäftigt, wie Sie eine Maschine auf einem isolierten Ethernet einrichten. Der Regelfall ist allerdings, daß mehrere Netze durch Gateways miteinander verbunden sind. Diese Gateways können einfach zwei oder mehrere Ethernets miteinander verbinden, aber auch das Tor zur Außenwelt (z.B. das Internet) bereitstellen. Um den Dienst eines Gateways zu nutzen, müssen Sie der Netzwerkschicht zusätzliche Routing-Informationen zur Verfügung stellen. Zum Beispiel sind die Ethernets der virtuellen Brauerei und der virtuellen Kellerei durch solch ein Gateway miteinander verbunden, nämlich vlager. Angenommen, vlager sei bereits konfiguriert, dann müssen wir auf Maschinen wie vstout nur noch eine weitere Route eintragen, die angibt, daß alle Maschinen im Netzwerk der Kellerei über vlager erreichbar sind. Der entsprechende Aufruf von route sieht so aus: # route add wine-net gw vlager

Dabei gibt gw an, daß das folgende Argument ein Gateway bezeichnet. Natürlich muß jedes System im Kellerei-Netz, zu dem Sie Verbindung aufnehmen wollen, einen analogen Routing-Eintrag für das Brauerei-Netz haben. Ansonsten könnten Sie nur Daten vom Brauerei-Netz an das Kellerei-Netz senden, die Rechner im Kellerei-Netz wären aber zu keiner Antwort fähig. Dieses Beispiel beschreibt nur ein Gateway, das Pakete zwischen zwei isolierten Ethernets befördert. Nehmen Sie nun an, daß vlager außerdem eine Verbindung ins Internet hat, beispielsweise durch einen SLIP-Link. Dann wäre es natürlich wünschenswert, daß Pakete für beliebige Zieladressen, die nicht im Brauerei-Netz liegen, an vlager weitergereicht werden. Das können Sie erreichen, indem Sie vlager zum Default-Gateway für vstout machen: # route add default gw vlager

Die Netzwerkadresse default ist eine Abkürzung für 0.0.0.0, die Default-Route. Sie paßt zu jeder Zieladresse und wird immer dann benutzt, wenn keine andere, näher spezifizierte Route paßt. Diesen Namen müssen Sie nicht in /etc/networks eintragen, er ist in route fest eingebaut. Sollten Sie hohe Verlustraten beobachten, wenn Sie eine Maschine hinter einem Gateway mit ping ansprechen, könnte das ein Hinweis auf ein verstopftes Netz sein. In diesem Fall sind Paketverluste nicht so sehr die Folge technischer Probleme, sondern rühren von einer kurzzeitigen Überlastung der routenden Maschinen her, die dazu führt, daß ankommende Pakete verzögert oder gar verworfen werden.

Konfiguration eines Gateways Es ist ziemlich einfach, eine Maschine dafür einzurichten, Pakete zwischen zwei Ethernets auszutauschen. Nehmen wir an, wir befänden uns wieder auf vlager, das mit zwei Ethernet-Karten ausgestattet ist, die jeweils mit einem der beiden Netze verbunden sind. Alles, was Sie tun müssen, ist, beide Schnittstellen getrennt zu konfigurieren und ihnen eine Adresse auf dem jeweiligen Subnetz zuzuweisen — das war's. Dabei ist es recht nützlich, zusätzlich zum offiziellen Hostnamen vlager zwei Namen für die beiden Schnittstellen in /etc/hosts zu definieren: 172.16.1.1

vlager.vbrew.com

vlager vlager-if1 172.16.2.1

vlager-if2

Mit diesen Einträgen lautet die Befehlsreihenfolge für die Einrichtung der beiden Schnittstellen so: # ifconfig eth0 vlager-if1 # route add brew-net # ifconfig eth1 vlager-if2 # route add wine-net

Wenn sie so nicht funktioniert, überprüfen Sie, ob Ihr Kernel überhaupt mit Unterstützung für IP-Forwarding übersetzt wurde. Das ist dann der Fall, wenn die erste Zahl der zweiten Zeile von /proc/net/snmp auf 1 gesetzt ist.

Die PLIP-Schnittstelle Wenn Sie PLIP verwenden, um zwei Maschinen miteinander zu vernetzen, liegen die Dinge etwas anders als bei einem Ethernet. PLIP stellt im Gegensatz zu Ethernet, das viele Hosts unterstützt und daher als Broadcast-Netzwerk bezeichnet wird, nur eine sogenannte Punkt-zu-Punkt-Verbindung her, d.h., es sind nur zwei Hosts involviert. Da hier keine eigenen Netzwerke verwaltet werden müssen, unterscheidet sich die Konfiguration von Punkt-zu-Punkt-Verbindungen von der Konfiguration von Broadcast-Netzwerken. PLIP stellt sehr kostengünstige und portable Verbindungen zwischen Computern her. Als Beispiel betrachten wir den Laptop einer Angestellten der virtuellen Brauerei, der mittels PLIP mit vlager verbunden wird. Der Laptop selbst heißt vlite und hat nur einen parallelen Port. Beim Booten wird dieser als plip1 registriert. Um die Verbindung zu aktivieren, muß die Schnittstelle plip1mit den folgenden Befehlen konfiguriert werden:3 # ifconfig plip1 vlite pointopoint vlager # route add default gw vlager

Der erste Befehl richtet das Interface ein und teilt dem Kernel mit, daß es sich dabei um eine Punkt-zu-Punkt-Verbindung handelt, deren anderes Ende die Adresse vlager hat. Der zweite Befehl installiert die Default-Route (mit vlager als Gateway). Auf vlager ist eine ähnliche ifconfig-Anweisung erforderlich, um die Verbindung zu etablieren (ein Aufruf von route ist hier nicht nötig): # ifconfig plip1 vlager pointopoint vlite

Das Besondere an diesem Fall ist, daß die Schnittstelle plip1 auf vlager keine eigene IP-Adresse haben muß, sondern Sie ihr auch die Adresse 172.16.1.1 zuweisen können. Dies ist eine wichtige Eigenschaft von Punkt-zu-Punkt-Verbindungen. Punktzu-Punkt-Netzwerke unterstützen Netzwerke nicht direkt, so daß die Schnittstellen auf den unterstützten Netzwerken keine eigenen Adressen benötigen. Um hier mögliche Konfusionen zu vermeiden, greift der Kernel auf die SchnittstellenInformationen in der Routing-Tabelle zurück.4 Bis jetzt haben wir das Routing vom Laptop zu den Netzen der virtuellen Brauerei eingerichtet. Jetzt fehlt noch die Möglichkeit, vlite von jedem Rechner der virtuellen Brauerei aus zu erreichen. Besonders mühselig ist es, auf jedem System eine spezielle Route einzutragen, die vlager als Gateway für vlite angibt: # route add vlite gw vlager

Eine viel bessere Methode, mit solchen temporären Routen zurechtzukommen, ist dynamisches Routing. Das können Sie beispielsweise mit gated, einem sogenannten Routing-Dämon, verwirklichen, der die Routing-Informationen von vlager an

alle anderen Maschinen im Netz verteilt. Dazu muß gated allerdings auf jeder Maschine im Netz installiert und konfiguriert werden, womit wir auch nicht viel gewonnen hätten. Die einfachste Variante überhaupt ist in einem solchen Fall Proxy-ARP (Address Resolution Protocol). Bei dieser Methode tut vlager gegenüber allen Maschinen auf dem Brauerei-Netz so, als sei es vlite, indem es alle ARP-Anfragen mit seiner eigenen Ethernet-Adresse beantwortet. Die Folge davon ist, daß alle Pakete für vlite auf vlager landen, das sie dann an den Laptop weiterreicht. Wir werden im Abschnitt Die ARP-Tabelle auf Proxy-ARP zurückkommen. Aktuelle Versionen von net-tools enthalten ein Tool namens plipconfig. Dieses Programm ermöglicht es Ihnen, eine Reihe besonderer Zeitparameter für PLIP einzustellen. Die IRQ, die für den Druckerport verwendet werden soll, können Sie mit dem Befehl ifconfig definieren.

Die SLIP- und PPP-Schnittstellen Obwohl SLIP und PPP genau wie PLIP auch nur einfache Punkt-zu-Punkt-Verbindungen darstellen, ist deren Konfiguration wesentlich komplizierter. Zum Verbindungsaufbau über SLIP gehört meist das Einwählen ins fremde System und die Umschaltung der seriellen Leitung auf SLIP-Betrieb. Für PPP gilt in etwa dasselbe. SLIP und PPP behandeln wir ausführlich in Kapitel 7 Serial Line IP, und in Kapitel 8 Das Point-to-Point-Protokoll.

Die Dummy-Schnittstelle Die Dummy-Schnittstelle ist ein wenig exotisch, aber trotzdem unter gewissen Umständen gut zu gebrauchen. Ihre wichtigste Anwendung findet sich auf isolierten Maschinen und solchen, deren einzige IP-Verbindung zur Außenwelt eine Wählverbindung, zum Beispiel über SLIP oder PPP, ist. Genaugenommen sind letztere die meiste Zeit auch isoliert (im Englischen verwendet man hier den Ausdruck standalone). Das Dilemma mit solchen “alleinstehenden” Maschinen ist, daß ihre einzige aktive Schnittstelle das Loopback-Interface ist, das immer die Adresse 127.0.0.1 trägt. Manchmal müssen Sie aber auch Daten an die “offizielle” IP-Adresse Ihres Rechners schicken können. Betrachten Sie den Laptop vlite, der für die Dauer dieses Beispiels mal vom Netz getrennt wurde. Eine Applikation auf vlite möchte nun Daten an eine andere Applikation auf vlite senden. Dazu sucht sie die Adresse von vlite in /etc/hosts heraus, erhält 172.16.1.65 und schickt das Paket an diese Adresse. Da aber zur Zeit das Loopback-Interface als einziges aktiv ist, kann der Kernel gar nicht wissen, daß sich diese Adresse auf den lokalen Host bezieht! Die Folge davon ist, daß er das Paket als unzustellbar wegwirft und der Applikation eine Fehlermeldung zurückliefert. An dieser Stelle tritt nun die Dummy-Schnittstelle in Erscheinung. Sie löst das Dilemma, indem sie als Alter ego der LoopbackSchnittstelle auftritt, sozusagen als Halter einer zweiten IP-Adresse. In unserem Fall würden Sie ihr einfach die Adresse 172.16.1.65 geben und eine Route eintragen, die auf dieses Interface verweist. Jedes Paket an 172.16.1.65 wird daraufhin lokal ausgeliefert. Die vollständige Sequenz der Befehle ist:5 # ifconfig dummy vlite # route add vlite

IP-Alias Neuere Kernel unterstützen ein Feature, das die Dummy-Schnittstelle völlig ersetzen kann und darüber hinaus weitere nützliche Funktionen bietet. Das sogenannte IP-Alias gestattet Ihnen, einzelnen physikalischen Schnittstellen mehrere IPAdressen zuzuordnen. Im einfachsten Fall können Sie das Verhalten einer Dummy-Schnittstelle nachbilden, indem Sie die Hostadresse Ihres Rechners als Alias zur Loopback-Schnittstelle konfigurieren und dann völlig auf die Dummy-Schnittstelle verzichten. In komplexeren Anwendungen können Sie Ihren Host so konfigurieren, daß er wie viele verschiedene Hosts wirkt, die jeweils eine eigene IP-Adresse haben. Dieses Vorgehen wird manchmal “Virtual Hosting” genannt, obwohl dieser Begiff genau genommen auch für eine Reihe anderer Verfahren benutzt wird.6 Um für eine Schnittstelle einen Alias zu konfigurieren, müssen Sie zunächst sichergehen, daß Ihr Kernel IP-Alias unterstützt. Das erkennen Sie an der Existenz der Datei /proc/net/ip_alias. Die Konfiguration eines IP-Alias geschieht im Grunde genauso wie die Konfiguration einer realen Netzwerkschnittstelle. Sie benutzen dabei einen speziellen Namen, um anzuzeigen, daß Sie einen Alias wollen. Beispiel:

# ifconfig lo:0 172.16.1.1

Dieser Befehl erzeugt einen Alias für die Loopback-Schnittstelle mit der IP-Adresse 172.16.1.1. Auf den IP-Alias einer Netzwerkschnittstelle greifen Sie zu, indem Sie an den Namen der Schnittstelle ein :n anhängen, wobei n eine Ganzzahl ist. In unserem Beispiel legen wir einen Alias für die Schnittstelle lo an, und wir weisen dem Alias die Nummer null zu. Auf diese Weise kann eine physikalische Schnittstelle eine Vielzahl von Aliases zur Verfügung stellen. Jeder Alias kann nun wie eine eigenständige Schnittstelle behandelt werden, und soweit es die IP-Software des Kernels betrifft, geschieht das auch so. Allerdings müssen sich alle diese virtuellen Schnittstellen die zugrundeliegende Hardware teilen.

1.

Erinnert sich noch jemand an Pink Floyds “Echoes”?

2.

Zum Beispiel verwenden alle RPC-basierten Applikationen die Loopback-Schnittstelle, um sich während des Systemstarts beim portmapper zu registrieren. Zu diese Applikationen gehören NIS und NFS.

3.

Die Schreibweise pointopoint ist wirklich kein Tippfehler. :-)

4.

Vorsichtshalber sollten Sie allerdings Ihren PLIP- oder SLIP-Link erst dann einrichten, wenn Sie bereits alle Routen für andere Netze eingetragen haben. Bei einigen älteren Kernels könnte eine falsche Reihenfolge dazu führen, daß Ihre Netzwerkroute statt aufs Ethernet plötzlich auf die PLIP-Schnittstelle zeigt.

5.

Die Dummy-Schnittstelle wird mit dummy0 bezeichnet, wenn sie als Modul geladen wird und nicht als fester Bestandteil im Kernel integriert ist. Der Grund dafür ist, daß mehrere Module gleichzeitig geladen werden können und dann mehr als nur eine Dummy-Schnittstelle zur Verfügung steht.

6.

Genauer gesagt, ist die Anwendung von IP-Aliasing allgemein als Virtual Hosting auf Netzwerkebene bekannt. In der Welt des WWW und SMTP ist dagegen Virtual Hosting auf Applikationsebene üblich. Dabei wird für jeden virtuellen Host zwar dieselbe IP-Adresse verwendet, aber mit jeder Anfrage auf Applikationsebene wird ein anderer Hostname mitgeliefert. Services wie z.B. FTP sind nicht in der Lage, auf diese Weise zu funktionieren. Sie kommen nur mit Virtual Hosting auf Netzwerkebene zurecht.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Alles über ifconfig ifconfig kennt neben den bisher vorgestellten noch eine ganze Reihe weiterer Optionen, die wir nun im einzelnen besprechen werden. ifconfig wird normalerweise so aufgerufen: ifconfig interface [address [parameters]]

interface ist der Name der zu konfigurierenden Schnittstelle, und address ist die IP-Adresse, die ihr zugewiesen werden soll. Sie kann entweder in Dezimalnotation angegeben werden oder als Name, den ifconfig in /etc/hosts nachschlägt. Wenn ifconfig nur mit dem Interface-Namen aufgerufen wird, gibt es die Konfiguration der Schnittstelle aus. Wird es ganz ohne Parameter aufgerufen, zeigt es alle bisher konfigurierten Schnittstellen an; die Option -a erzwingt zusätzlich die Anzeige der inaktiven. Ein Aufruf für die Ethernet-Schnittstelle eth0 könnte beispielsweise so aussehen: # ifconfig eth0 eth0 Link encap 10Mbps Ethernet 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 RX packets 3136 errors 217 dropped 7 overrun 26 overrun 0

HWaddr 00:00:C0:90:B3:42 inet addr UP BROADCAST RUNNING MTU 1500 Metric 0 TX packets 1752 errors 25 dropped 0

Die Felder MTU und Metric zeigen die aktuellen Werte für die MTU und die Metrik der Schnittstelle an. Die Metrik wird von einigen Betriebssystemen verwendet, um die Kosten einer Route zu berechnen. Linux benutzt diesen Wert bisher nicht, definiert ihn aber trotzdem aus Gründen der Kompatibilität. Die Zeilen RX und TX zeigen an, wie viele Pakete empfangen (RX — receive) bzw. gesendet wurden (TX — transmit), wie viele Fehler dabei auftraten, wie viele Pakete (beispielsweise aufgrund von Speichermangel) verworfen wurden und wie viele wegen eines Überlaufs verlorengingen. Ein Überlauf beim Empfänger (overrun) tritt dann auf, wenn Pakete schneller hereinkommen, als der Kernel die Interrupts bedienen kann. Die von ifconfig angezeigten Flags entsprechen mehr oder weniger den Namen der Befehlsparameter und werden später behandelt. Die folgende Liste zeigt die Parameter, die ifconfig versteht; die Namen der zugehörigen Flags stehen in Klammern. Optionen, die eine bestimmte Eigenschaft der Schnittstelle aktivieren, können mit vorangestelltem Minuszeichen (–) auch benutzt werden, um ihn wieder auszuschalten. up

Diese Option aktiviert ein Interface für die IP-Schicht des Kernels. Sie wird impliziert, wenn auf der Kommandozeile eine Adresse angegeben ist. Sie kann auch dazu benutzt werden, ein Interface zu reaktivieren, wenn es mit der downOption temporär deaktiviert wurde. Diese Option entspricht den Flags UP und RUNNING. down Diese Option markiert eine Schnittstelle als inaktiv, d.h. unzugänglich für die Netzwerkschicht. Dadurch wird jeglicher IP-Transport durch die Schnittstelle unterbunden. Beachten Sie, daß dadurch automatisch alle Routing-Einträge gelöscht werden, die diese Schnittstelle verwenden. Netzmaske Maske Diese Option weist der Schnittstelle eine Subnetzmaske zu. Sie kann entweder als eine 32-Bit-Hexadezimalzahl (mit führender 0x) oder in Dezimaldarstellung (Beispiel: 255.255.255.0) angegeben werden. Während diese als “dotted quad” bezeichnete Notation häufiger benutzt wird, ist die hexadezimale Darstellung oft einfacher zu handhaben. Netzmasken sind grundsätzlich binär, und es ist bequemer, eine Binär-zu-Hexadezimal- als eine Binär-zu-DezimalKonvertierung durchzuführen. Pointopoint Adresse Diese Option wird für Punkt-zu-Punkt-Verbindungen benutzt, die nur zwei Hosts miteinander verbinden. Sie wird beispielsweise für die Konfiguration von SLIP- und PLIP-Schnittstellen benötigt und teilt dem Kernel die IP-Adresse des anderen Systems mit. Falls eine Punkt-zu-Punkt-Adresse gesetzt wurde, zeigt ifconfig das POINTOPOINT-Flag an. broadcast Adresse Die Broadcast-Adresse wird normalerweise aus der Netzwerknummer gebildet, indem alle Bits des Hostteils auf eins gesetzt werden. Einige IP-Implementierungen (zum Beispiel von BSD 4.2 abstammende Systeme) verwenden dagegen eine Broadcast-Adresse, bei der die Bits des Hostteils auf null gesetzt sind. Die Option broadcast dient dazu, Ihre Konfiguration an solch eine seltsame Umgebung -anzupassen. Wenn dem Interface eine Broadcast-Adresse zugeordnet wurde, gibt ifconfig das Flag Broadcast aus. irq Mit dieser Option definieren Sie die Interrupt-Leitung, die von bestimmten Schnittstellen benutzt werden soll. Das ist insbesondere für PLIP nützlich, aber auch für bestimmte Ethernet-Karten. metric Wert Mit dieser Option können Sie dem Routing-Tabellen-Eintrag der Schnittstelle einen Metrikwert zuordnen. Dieser Wert wird beispielsweise vom Routing Information Protocol (RIP) berücksichtigt, wenn es Routing-Tabellen für Ihr Netz erstellt.1 Die Default-Metrik, die ifconfig einem Interface zuweist, ist null. Wenn Sie das Routing in Ihrem Netz nicht mit RIP regeln, benötigen Sie diese Option überhaupt nicht; aber selbst wenn Sie einen RIP-Dämon einsetzen, werden Sie nur äußerst selten Verwendung dafür haben. mtu Bytes Dies setzt die Maximum Transmission Unit (MTU), d.h. die maximale Anzahl von Bytes, die das Interface in einer Transaktion behandeln kann. Für Ethernets liegt der Defaultwert bei 1500; für SLIP beträgt er 296. Für die MTU von SLIP-Verbindungen gibt es keine Obergrenze; der Standardwert ist lediglich ein guter Kompromiß.

arp Diese Option kann nur für Broadcast-fähige Netz wie Ethernet oder Ham-Radio verwendet werden. Sie ermöglicht die Benutzung von ARP, dem Address Resolution Protocol, zur Zuordnung von IP-Adressen zu physikalischen Adressen. Für Broadcast-Netze wird sie per Voreinstellung eingeschaltet. Ist ARP abgeschaltet, zeigt ifconfig das NOARP-Flag an. –arp Schaltet ARP explizit aus. promisc Versetzt die Schnittstelle in den sogenannten “promiskuösen” Modus. Auf Broadcast-Netzen hat das zur Folge, daß die Schnittstelle alle Pakete unabhängig davon empfängt, ob sie für einen anderen Host bestimmt sind oder nicht. Dadurch kann man den Netzwerkverkehr mit Paketfiltern wie tcpdump analysieren, um Netzwerkproblemen nachzuspüren, denen anders nur schwer beizukommen ist. Dieses sogenannte Packet Snooping (d.h. Schnüffeln) hat aber auch seine problematische Seite. Mit ziemlich einfachen Mitteln können potentielle Angreifer den Datenverkehr Ihres Netzes nach Paßwörtern durchsuchen oder noch viel bösartigere Dinge tun. Dagegen können Sie sich kaum schützen, es sei denn, Sie verbieten es anderen ausdrücklich, ihre Rechner ans Netz anzuschließen, und lassen auch niemand in die Nähe Ihres Ethernet-Kabels. Beides ist nicht sehr realistisch. Eine andere Möglichkeit besteht darin, ein sicheres Authentifizierungsprotokoll zu benutzen, wie es Kerberos oder die Secure Shell Login-Suite bietet.2 Diese Option entspricht dem PROMISC-Flag. –promisc Schaltet den promiskuösen Modus ab. allmulti Multicast-Adressen sind wie Ethernet-Broadcast-Adressen, mit der Einschränkung, daß sie nicht automatisch jeden möglichen Adressaten berücksichtigen, sondern nur solche, die ausdrücklich zum Empfang vorgesehen (programmiert) sind. Sie eignen sich besonders für Anwendungen wie Ethernet-basierte Videokonferenzen oder Audioübertragungen übers Netz, die nur an Interessierte gerichtet sind. Multicast-Adressen werden von den meisten (aber nicht allen) Ethernet-Treibern unterstützt. Ist diese Option eingeschaltet, empfängt und sendet das Interface Multicast-Pakete. Diese Option entspricht dem ALLMULTI-Flag. –allmulti Schaltet Multicast-Adressen ab.

1.

RIP wählt aus mehreren zur Verfügung stehenden Routen zu einem Zielsystem die jeweils “kürzeste” aus. Die Länge eines Pfades setzt sich dabei aus den Metrikwerten der einzelnen Teilverbindungen zusammen. Per Voreinstellung hat jeder solche “Hop” die Länge 1. Zulässig sind ganzzahlige Werte zwischen 1 und 15; der Wert 16 bedeutet “unendlich” und weist auf eine unbrauchbare Route hin. Die Option metric stellt die Kosten eines solchen Hops ein. Diese wird dann über den Routing-Dämon weitergeleitet.

2.

ssh ist erhältlich von ftp.cs.hut.fi im Verzeichnis /pub/ssh.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der Befehl netstat Als nächstes wenden wir uns einem nützlichen Werkzeug zu, mit dem Sie die Konfiguration und die Aktivität Ihres Netzes überprüfen können. Es heißt netstat und ist eher eine ganze Sammlung von Werkzeugen, die in einem Programm zusammengepackt worden sind. Wir werden jede seiner Funktionen in den folgenden Abschnitten besprechen.

Anzeigen der Routing-Tabelle Wenn Sie netstat mit dem Flag –r aufrufen, gibt es die Routing-Tabellen des Kernels aus; ähnlich, wie Sie es oben bereits bei route gesehen haben. Auf vstout erzeugt es ungefähr folgende Ausgabe: # netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.1 * 255.255.255.255 UH 0 0 0 lo 172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0

Die Option –n sorgt zusätzlich dafür, daß netstat die Adressen statt als symbolische Host- und Netzwerknamen direkt in dezimaler Notation ausgibt. Das ist dann nützlich, wenn Sie verhindern wollen, daß langwierige Adreßauflösungsanfragen über das Netzwerk ausgeführt werden, zum Beispiel beim DNS- oder NIS-Server. Die zweite Spalte der netstat-Ausgabe zeigt jeweils das Ziel der Route an. Die zweite Spalte gibt das Gateway an, auf das der Routing-Eintrag zeigt. Wird kein Gateway verwendet, wird statt dessen ein Sternchen ausgegeben. Die dritte Spalte gibt Auskunft über die “Allgemeinheit” der Route, d.h. deren Netzmaske. Wenn der Kernel eine IP-Adresse erhält, für die er eine angemessene Route finden soll, dann durchsucht er alle Einträge in der Routing-Tabelle und führt eine bitweise UNDVerknüpfung mit der Adresse und der Genmask durch, bevor er sie mit dem Ziel der Route vergleicht. Die vierte Spalte zeigt verschiedene Flags, die die Route näher charakterisieren. G Die Route geht durch ein Gateway. U

Das zu verwendende Interface ist aktiv. H Die Route zeigt auf einen einzelnen Host, wie das z.B. beim Loopback-Eintrag 127.0.0.1 der Fall ist. D Diese Route wurde dynamisch erzeugt. Dieses Flag ist gesetzt, wenn der Tabelleneintrag von einem Routing-Dämon wie gated oder durch eine ICMP-Redirect-Nachricht generiert wurde (siehe Abschnitt Das Internet Control Message Protocol in Kapitel 2). M Dieses Flag ist gesetzt, wenn der entsprechende Tabelleneintrag durch eine ICMP-Redirect-Nachricht verändert wurde. Der Tabelleneintrag wurde durch einen ICMP-Redirect modifiziert. ! Alle Datagramme werden verworfen. Die nächsten drei Spalten geben Auskunft über die maximale Segmentgröße (MSS, Maximum Segment Size), das Fenster sowie über die Anfangsumlaufzeit (irtt, initial round trip time), die auf die über diese Route etablierten TCP-Verbindungen anzuwenden sind. Die MSS bezeichnet den Umfang des größten IP-Pakets, das der Kernel über diese Route verschickt. Mit dem Fenster ist die maximale Datenmenge gemeint, die von einem Remote-Host auf einmal empfangen werden kann. Das TCP-Protokoll stellt sicher, daß die Daten zwischen den Hosts zuverlässig übertragen werden. Falls Datenpakete unterwegs verlorengehen, wird die Übertragung dieser fehlenden Pakete automatisch wiederholt. Das TCP-Protokoll ermittelt am Anfang einer Übertragung, wie lange das gesendete Datenpaket zum Remote-Host braucht, und ermittelt aus der Zeit bis zur Rückantwort einen Wert, der für die weitere Datenübertragung als Maß dient, ob ein IP-Paket ggf. wiederholt werden muß. Diese Zeit wird als round trip time bezeichnet. Der Vorgabewert wird vom TCP-Protokoll beim erstmaligen Verbindungsaufbau benutzt. Für die meisten Netzwerktypen ist der Standardwert akzeptabel, für einige langsame Netzwerke, besonders Amateur-Paket-Radio-Netzwerke, ist die Zeit aber eindeutig zu kurz, so daß es hier zu unnötig häufigen Wiederholungen kommt. Der irtt-Wert kann mit dem route-Befehl eingestellt werden. Nullwerte in diesen Spalten bedeuten, daß Standardwerte benutzt werden. Schließlich gibt das letzte Feld die Netzwerkschnittstelle an, die die Route benutzt.

Anzeige der Interface-Statistiken Wenn Sie netstat mit dem Flag –i aufrufen, gibt es die Statistiken für die gerade aktiven Netzwerkschnittstellen aus. Geben Sie außerdem das Flag –a mit an, werden alle im Kernel vorhandenen Schnittstellen ausgegeben, nicht nur die konfigurierten. Auf vstout gibt netstat in etwa folgendes aus: # netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OVR Flags lo 0 0 3185 0 0 0 3185 0 0 0 972633 17 20 120 628711 217 0 0 BRU

TX-OK TX-ERR TX-DRP 0 BLRU eth0 1500

Die Spalten MTU und Met geben die aktuelle MTU und Metrik der Schnittstelle an. Die mit RX bzw. TX überschriebenen Spalten geben an, wie viele Pakete fehlerfrei empfangen bzw. gesendet wurden (RX-OK/TX-OK), wie viele beschädigt waren (RX-ERR/TX-ERR), wie viele verworfen werden mußten (RX-DRP/TX-DRP) und wie viele aufgrund eines Overruns verlorengingen (RX-OVR/TX-OVR). Die letzte Spalte zeigt wieder die Flags an, die für die Schnittstelle gesetzt sind. Das sind einbuchstabige Versionen der langen Flag-Namen, die ifconfig ausgibt:

B Eine Broadcast-Adresse wurde gesetzt. L Die Schnittstelle ist ein Loopback-Device. M Alle Pakete werden empfangen (promiskuöser Modus). O ARP ist an dieser Schnittstelle abgeschaltet. P Hier handelt es sich um eine Punkt-zu-Punkt-Verbindung. R Die Schnittstelle läuft. U Die Schnittstelle ist aktiv.

Anzeigen der Verbindungen netstat bietet eine Reihe von Optionen, mit denen Sie aktive und passive Sockets auflisten können. Die Argumente –t, –u, –w und –x zeigen aktive TCP-, UDP-, RAW- und UNIX-Sockets. Wenn Sie zusätzlich –a angeben, sehen Sie außerdem die Sockets, die gerade auf eine Verbindung warten. Auf diese Weise erhalten Sie eine Liste aller Server, die derzeit auf Ihrem System laufen. Ein Aufruf von netstat -ta ergibt auf vlager: $ netstat -ta Active Internet Connections Proto Recv-Q Send-Q Local Address Foreign Address (State) tcp 0 0 *:domain *:* LISTEN tcp 0 0 *:time *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED tcp 0 0 *:telnet *:* LISTEN tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED tcp 0 0 *:chargen *:* LISTEN tcp 0 0 *:daytime *:* LISTEN tcp 0 0 *:discard *:* LISTEN tcp 0 0 *:echo *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:login *:* LISTEN

Man sieht, daß die meisten Server einfach auf eine eingehende Verbindung warten, da sie sich im Zustand LISTEN befinden. Die vierte Zeile zeigt allerdings eine SMTP-Verbindung von vstout, und die sechste Zeile besagt, daß eine ausgehende telnetVerbindung zu vbardolino besteht.1 Wenn Sie netstat nur mit der Option –a aufrufen, zeigt es eine Liste aller Sockets aus allen Familien.

1.

Die Richtung einer Verbindung können Sie anhand der auftauchenden Portnummern erkennen. Das Ziel einer telnetVerbindung zum Beispiel ist immer der Port 23, den netstat hier mit seinem symbolischen Namen ausgibt, der in /etc/services definiert ist. Der Port auf dem Ausgangsrechner dagegen ist so gut wie nie ein bekannter Service-Port, weshalb netstat auch nur eine normale Zahl anzeigt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die ARP-Tabelle Bei einigen Netzproblemen kann es aufschlußreich sein, einen Blick auf die ARP-Tabelle des Kernels zu werfen oder sie sogar zu verändern. Zum Beispiel, wenn Sie den Verdacht haben, daß eine doppelt vergebene IP-Adresse der Grund für Ihre periodisch wiederkehrenden Netzprobleme ist. Für derartige Probleme ist das arp-Tool wie geschaffen. Seine Kommandozeilenoptionen lauten: arp [-v] [-t hwtype] -a [hostname] arp [-v] [-t hwtype] -s hostname hwaddr arp [-v] -d hostname [hostname…]

Alle hostname-Argumente können als symbolische Hostnamen oder als IP-Adressen in Dezimalnotation angegeben werden. Der erste Aufruf gibt den ARP-Eintrag für die angegebene IP-Adresse bzw. Hostnamen aus. Falls hostname nicht angegeben wird, werden Informationen über alle bekannten Hosts ausgegeben. Zum Beispiel ergibt die Ausgabe von arp auf vlager etwa folgendes: # arp -a IP address HW type HW address 172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1 172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42 172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA

Dies zeigt die Ethernet-Adressen von vlager, vstout und vale. Sie können die Ausgabe auch auf bestimmte Hardwaretypen beschränken, indem Sie die –t-Option verwenden. Als Argument geben Sie ether, ax25 oder pronet an, was für 10 Mbps Ethernet, AMPR AX.25 und IEEE 802.5 Token Ring steht. Die Option –s dient dazu, die Hardwareadresse von hostname manuell in die ARP-Tabelle einzutragen. Das Argument hwaddr spezifiziert die Hardwareadresse, die normalerweise als Ethernet-Adresse aus sechs Byte in hexadezimaler Notation angegeben ist. Sie können solche Adressen auch bei anderen Hardwaretypen verwenden, wenn Sie zusätzlich die Option –t angeben. Aus irgendwelchen Gründen kann es passieren, daß ARP-Anfragen an einen bestimmten Host nicht funktionieren — sei es, weil dessen ARP-Treiber fehlerhaft ist oder ein zweiter Host im Netz sich irrtümlich mit dessen IP-Adresse identifiziert. Dieses Problem zwingt Sie dazu, die korrekte IP-Adresse manuell in die ARP-Tabelle einzutragen. Die Festverdrahtung von Hardwareadressen im ARP-Cache ist auch eine (wenn auch drastische) Maßnahme, um Maschinen aus Ihrem Ethernet daran

zu hindern, sich als jemand anderes auszugeben. Wenn Sie arp mit der Option –d aufrufen, entfernt es alle Einträge für einen bestimmten Host. Es kann dazu benutzt werden, das Interface anzuweisen, eine bereits angeforderte Hardwareadresse einer IP-Adresse nochmals anzufordern, und ist besonders dann nützlich, wenn ein fehlerhaft konfiguriertes System falsche ARP-Informationen sendet (natürlich muß zuerst das fehlerhafte System erneut konfiguriert werden). Die Option –s kann aber auch für Proxy-ARP benutzt werden. Das ist eine spezielle Technik, bei der z.B. ein Host namens gate als Gateway zu einem anderen Host namens fnord fungiert, indem er vorgibt, daß beide Adressen auf denselben Host, nämlich gate, verweisen. Das erreicht es durch Herausgabe eines ARP-Eintrags für fnord, der auf sein eigenes EthernetInterface zeigt. Wenn nun ein Host eine ARP-Anfrage für fnord sendet, liefert gate eine Antwort, die seine eigene EthernetAdresse enthält. Der anfragende Host sendet dann alle IP-Pakete an gate, der sie seinerseits pflichtbewußt an fnord weiterleitet. Derartige Verrenkungen können durchaus notwendig sein, z.B. wenn Sie fnord von einer DOS-Maschine mit einer gestörten TCP-Implementierung erreichen wollen, die mit Routing nicht besonders viel anfangen kann. Wenn Sie Proxy-ARP benutzen, hat die DOS-Maschine den Eindruck, als befände sich fnord auf dem lokalen Subnetz, so daß sie gar nicht mehr zu wissen braucht, wie das Routing durch ein Gateway funktioniert. Eine andere nützliche Anwendung von Proxy-ARP ist, wenn einer Ihrer Hosts nur temporär als Gateway zu einem anderen Host fungiert, z.B. über eine Dialup-Verbindung. Nehmen wir den Laptop vlite aus unserem letzten Beispiel. Er war von Zeit zu Zeit über eine PLIP-Verbindung mit vlager verbunden. Diese Anwendung funktioniert natürlich nur dann, wenn sich die Adresse des Hosts, dem Sie Proxy-ARP zur Verfügung stellen wollen, im gleichen Subnetz wie Ihr Gateway befindet. vstout könnte somit jeden Host im Subnetz der Brauerei (172.16.1.0) mit Proxy-ARP versorgen, aber nicht die Hosts im Subnetz der Kellerei (172.16.2.0). Um Proxy-ARP für fnord zur Verfügung zu stellen, lautet der ordnungsgemäße Aufruf wie folgt (die angegebene Hardwareadresse gehört natürlich zu gate): # arp -s fnord 00:00:c0:a1:42:e0 pub

Entfernt wird der Proxy-ARP-Eintrag durch: # arp -d fnord

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 6 Name-Server- und Resolver-Konfiguration

In Kapitel 2 Aspekte der Netzwerkarbeit mit TCP/IP, hatten wir bereits kurz beschrieben, daß in einer TCP/IP-Umgebung verschiedene Dienste zur Verfügung stehen, die Hostnamen auf IP-Adressen abbilden. Die einfachste Variante ist, eine Liste aller Hostnamen in der Datei /etc/hosts abzulegen. Sie eignet sich allerdings nur für kleine LANs, die von einem einzelnen Administrator verwaltet werden und keinen IP-Kontakt zur Außenwelt haben. Das Format dieser Datei wurde bereits in Kapitel 5

TCP/IP-Konfiguration, beschrieben. Sie können aber auch den Berkeley Internet Name Domain Service (BIND) benutzen, um Hostnamen in IP-Adressen aufzulösen. Die Konfiguration von BIND kann in echte Arbeit ausarten, wenn Sie es allerdings einmal geschafft haben, sind Änderungen in der Netzwerktopologie schnell erledigt. Unter Linux wird der Name-Service, wie unter vielen anderen Unix-ähnlichen Systemen auch, durch ein Programm namens named zur Verfügung gestellt. Beim Systemstart lädt es einen Satz von MasterDateien in seinen internen Cache und wartet auf Anfragen von einem Remote-Host oder einem lokalen Benutzerprozeß. Es gibt verschiedene Möglichkeiten, BIND einzurichten, und nicht alle setzen voraus, daß Sie auf jedem Host einen Name-Server betreiben. In diesem Kapitel können wir Ihnen nicht viel mehr als einen groben Überblick über die Funktionsweise von DNS und den Betrieb eines Name-Servers geben. Es sollte aber auf alle Fälle genügen, wenn Sie ein kleines LAN mit einer Internet-Verbindung betreiben. Um die aktuellsten Informationen zu bekommen, sollten Sie einen Blick in die Dokumentation der BIND-Software werfen. Sie enthält außer Manpages und Release-Informationen auch den BIND Operator's Guide (BOG). Lassen Sie sich von diesem Namen nicht abschrecken, es ist wirklich eine sehr nützliche Referenz. Für eine um-fassendere Behandlung von DNS und den damit zusammenhängenden Themen sollten Sie sich ein gutes Buch über BIND besorgen, zum Beispiel den Titel DNS und BIND von Paul Albitz und Cricket Liu (O'Reilly Verlag). Schließlich gibt es noch die Newsgruppe comp.protocols.tcp-ip.domains, die ausschließlich für Fragen und Diskussionen um DNS da ist. Die technischen Details von DNS sind in den RFCs 1033, 1034 und 1035 festgelegt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Resolver-Bibliothek Der Begriff Resolver bezieht sich nicht auf eine spezielle Applikation, sondern auf die Resolver-Bibliothek. Hierbei handelt es sich um eine Sammlung von Funktionen, die bei Linux zur Standard-C-Bibliothek gehören. Ihre wichtigsten Routinen sind gethostbyname(2) und gethostbyaddr(2), die alle zu einem Namen gehörenden IP-Adressen zurückliefern und umgekehrt. Über die Datei host.conf können Sie einstellen, ob Sie die gewünschten Informationen in /etc/hosts nachschlagen, verschiedene DNS-Server befragen oder die hosts-Datenbank des Network Information Service (NIS) benutzen wollen. Die Resolver-Funktionen lesen die Konfigurationsdateien, wenn sie zum erstenmal aufgerufen werden. Anhand dieser Konfigurationsdateien ermitteln sie, welche Datenbank sie zu befragen haben, in welcher Reihenfolge dies passieren soll und welche anderen relevanten Details Sie zur Konfiguration Ihrer Systemumgebung eingestellt haben. Die ältere Standardbibliothek von Linux, libc, benutzte die Datei /etc/host.conf als Hauptkonfigurationsdatei, während die Version 2 der GNU-Standardbibliothek, glibc, die Datei /etc/nsswitch.conf verwendet. Wir werden jede für sich gesondert behandeln, da beide weit verbreitet.

Die Datei host.conf Die Datei /etc/host.conf teilt den Resolver-Funktionen der älteren Standardbibliothek von Linux mit, welche Dienste benutzt werden sollen und in welcher Reihenfolge. Optionen in host.conf müssen in separaten Zeilen erscheinen, wobei die Argumente durch Leerzeichen oder Tabulatorzeichen voneinander getrennt sein müssen. Ein Doppelkreuz bzw. Hashzeichen (#) leitet einen Kommentar ein, der sich bis zum Zeilen-ende erstreckt. Die folgenden Optionen sind verfügbar: order Dieser Befehl bestimmt die Reihenfolge, in der der Resolver die verschiedenen Dienste ausprobiert. Zulässige Optionen sind bind für die Anfragen an den Name-Server, hosts zum Nachschlagen in /etc/hosts und nis für NIS-Abfragen. Alle Optionen können einzeln oder kombiniert auftreten. Die Reihenfolge der angegebenen Optionen ist maßgeblich dafür, welche Dienste zuerst ausprobiert werden. multi

Es legt fest, ob Hosts in der Datei /etc/hosts mehrere Adressen haben dürfen. Diese Eigenschaft wird im Englischen oft als “multi-homed” bezeichnet. Gültige Argumente sind on und off. Dieses Kommando hat keinerlei Auswirkungen auf DNS- und NIS-Anfragen. nospoof Wie wir im Abschnitt Reverse Lookups noch beschreiben werden, kann DNS über die Domain in-addr.arpa IPAdressen auf den zugehörigen Hostnamen abbilden. Die Versuche von Name-Servern einen falschen Hostnamen zurückzuliefern, werden Spoofing (Reinlegen) genannt. Um sich davor zu schützen, kann der Resolver so konfiguriert werden, daß er überprüft, ob die gegebene IP-Adresse auch tatsächlich zum erhaltenen Hostnamen gehört. Wenn dies nicht der Fall ist, wird der Name verworfen und ein Fehler zurückgeliefert. Dieses Verhalten wird mit nospoof on eingestellt. alert Diese Option erwartet on oder off als Argumente. Wird diese Option aktiviert, protokolliert der Resolver jeden Spoofing-Versuch über den syslog-Dienst. trim Diese Option gibt einen Domainnamen an, den der Resolver (wenn möglich) vom Hostnamen abschneiden soll, bevor er die einzelnen Dienste befragt. Das kann für die hosts-Datei nützlich sein, wenn Sie dort nur die lokalen Hostnamen ohne Domain eintragen wollen. Übergibt eine Applikation dem Resolver nun einen Hostnamen, der auf den lokalen Domainnamen endet, wird er “getrimmt”, so daß der Resolver ihn in /etc/hosts finden kann. Der Domainname, den Sie angeben, muß mit einem Punkt (.) enden (z.B. :linux.org.au.), damit trim korrekt funktioniert. Sie können den trim-Befehl auch mehrmals angeben. Dadurch können Sie Host-namen aus mehreren Domains in /etc/hosts mischen. Beispiel 6-1 zeigt eine Beispieldatei für vlager. Beispiel 6.1: Beispieldatei host.conf # /etc/host.conf # Wir haben named, aber (bis jetzt) kein NIS order bind,hosts # Hosts können mehrere IP-Adressen haben multi on # Schutz gegen Spoofing-Versuche nospoof on # Lokale Domains abschneiden (nicht unbedingt nötig) trim vbrew.com.

Resolver-Umgebungsvariablen Die globalen Einstellungen in host.conf können von einer Reihe Umgebungsvariablen außer Kraft gesetzt werden. RESOLV_HOST_CONF Diese Variable spezifiziert eine Datei, die anstelle von /etc/host.conf eingelesen werden soll. RESOLV_SERV_ORDER Diese Variable setzt die order-Option außer Kraft. Als Dienste können hosts, bind und nis angegeben werden, die jeweils durch ein Leerzeichen, Komma, Doppelpunkt oder Semikolon getrennt werden. RESOLV_SPOOF_CHECK Diese Variable bestimmt den Grad der Spoofing-Abwehr. Bei Angabe von off werden die Spoofing-Tests komplett abgeschaltet. Die Werte warn und warn off aktivieren bzw. deaktivieren die Spoofing-Abwehr durch Ein- bzw. Abschalten des Loggings. Ein Wert von * schaltet die Spoofing-Tests ein, übernimmt für das Logging aber den Vorgabewert von host.conf.

RESOLV_MULTI Diese Variable verwendet einen Wert von on oder off, um die multi-Option von host.conf zu überschreiben. RESOLV_OVERRIDE_TRIM_DOMAINS Diese Variable spezifiziert eine Liste von “Trim”-Domains, die die in host.conf angegebenen Einträge überschreiben. Auf Trim-Domains wurde bereits im Zusammenhang mit dem Schlüsselwort trim eingegangen. RESOLV_ADD_TRIM_DOMAINS Diese Variable spezifiziert eine Liste von “Trim”-Domains, die den in host.conf angegebenen Einträgen hinzugefügt werden.

Die Datei nsswitch.conf Version 2 der GNU-Standardbibliothek zeichnet sich durch ein mächtiges und flexibles Konzept aus, das den älteren host.confMechanismus ersetzt. Das Konzept des Name-Service wurde dahingehend erweitert, daß es eine Vielzahl verschiedener Arten von Informationen aufnehmen kann. Die diversen Konfigurationsoptionen für all die verschiedenen Funktionen, die Anfragen an Datenbanken stellen, werden nun wieder an einer zentralen Stelle angegeben, nämlich in der Datei nsswitch.conf. In der Datei nsswitch.conf kann der Systemadministrator eine Vielzahl verschiedener Datenbanken konfigurieren. Wir besprechen hier nur diejenigen Optionen, die sich auf die Auflösung von Host- und Netzwerk-IP-Adressen beziehen. Weitergehende Informationen über die anderen Features erhalten Sie ganz einfach durch das Studium der Dokumentation zur GNU-Standardbibliothek. Optionen in nsswitch.conf müssen in getrennten Zeilen erscheinen, wobei die Argumente durch Leerzeichen oder Tabulatorzeichen voneinander getrennt sein müssen. Ein Hashzeichen (#) leitet einen Kommentar ein, der sich bis zum Zeilenende erstreckt. Jede Zeile beschreibt einen bestimmten Dienst, z.B. die Auflösung von Hostnamen. Das erste Feld jeder Zeile gibt den Namen der Datenbank an und endet mit einem Doppelpunkt. Die Datenbank, die für die Auflösung von Hostadressen verwendet wird, ist hosts. Eine verwandte Datenbank ist networks. Sie dient zur Auflösung von Netznamen in Netzadressen. Der Rest jeder Zeile enthält Optionen, die die Art des Zugriffs auf die betreffende Datenbank regeln. Die folgenden Optionen sind verfügbar: dns Verwendet das Domain Name System (DNS) zur Auflösung der Adresse. Das macht allerdings nur Sinn bei der Auflösung von Hostadressen, nicht von Netzadressen. Der Mechanismus benutzt die Datei /etc/resolv.conf, auf die wir später noch näher eingehen werden. files Durchsucht eine lokale Datei nach den Host- oder Netznamen und ihren zugehörigen IP-Adressen. Diese Option verwendet die traditionellen Dateien /etc/hosts und /etc/network. nis oder nisplus Verwendet das Network Information System (NIS) zur Auflösung einer Host- oder Netzadresse. NIS und NIS+ werden ausführlich in Kapitel 13 Das Network Information System, besprochen. In der Reihenfolge, in der die Dienste angegeben sind, werden sie auch abgefragt, wenn ein Name aufgelöst werden soll. Anspruch genommen, in der sie aufgelistet sind. Diese Liste befindet sich in der Datei /etc/nsswitch.conf in dem Abschnitt, in dem die Beschreibung der Dienste erfolgt. Die Dienste werden von links nach rechts abgefragt, und die Suche wird

standardmäßig beendet, wenn ein Wert (oder Name) erfolgreich aufgelöst wurde. Ein simples Beispiel einer Host- und Netzwerk-Datenbankspezifikation, die das Verhalten unserer Konfiguration mit der alten libc-Standardbibliothek nachbildet, zeigt Tabelle 6.2. Beispiel 6.2: Beispieldatei nsswitch.conf # /etc/nsswitch.conf # # Beispielkonfiguration der GNU-Name-Service-Switch-Funktionalität # Informationen über diese Datei finden Sie im Paket 'libc6-doc' hosts: dns files networks: files

Dieses Beispiel veranlaßt das System, Hosts zuerst im DNS zu suchen und wenn dort nichts gefunden wird, die Suche in der Datei /etc/hosts fortzusetzen. Um Netzwerknamen aufzulösen, wird ausschließlich die Datei /etc/networks benutzt. Sie können das Suchverhalten genauer kontrollieren, indem Sie zusätzlich Aktionen (action items) angeben, die anhand des Ergebnisses der jeweils vorhergehenden Suchanfrage ausgeführt werden. Diese geben an, welche Aktion nach dem jeweils letzten Namensauflösungsversuch durchgeführt werden soll. Handlungsanweisungen werden zwischen den Dienstangaben eingetragen und mit eckigen Klammern [ ] versehen. Die allgemeine Syntax einer Handlungsanweisung ist: [ [!] Ergebnis = Aktion ... ]

Es gibt zwei mögliche Handlungen: return Kontrolliert die Rückgabewerte an das Programm, das die Namensauflösung versuchte. War ein Auflösungsversuch erfolgreich, liefert der Resolver die zugehörigen Details als Resultat zurück, ansonsten eine Null. continue Der Resolver nimmt den nächsten Dienst in der Liste in Anspruch und versucht damit eine Namensauflösung. Das optionale Ausrufezeichen (!) gibt an, daß der Zustandswert vor dem Test invertiert werden soll; es entspricht also dem logischen Nicht (not). Die zur Verfügung stehenden Statuswerte, mit denen wir arbeiten können, sind: success Der angeforderte Eintrag wurde ohne Fehler gefunden. Die Standardaktion für diesen Zustand ist return. notfound Die Namenssuche verlief fehlerfrei, jedoch konnte der Zielhost bzw. das Zielnetzwerk nicht gefunden werden. Die Standardaktion für diesen Zustand ist continue. unavail Der angeforderte Dienst war nicht erreichbar. Das könnte bedeuten, daß die Dateien hosts oder networks für den filesDienst unlesbar waren oder daß ein Name- bzw. NIS-Server für die dns- oder nis-Dienste nicht geantwortet hat. Die Standardaktion für diesen Zustand ist continue. tryagain Dieser Zustand bedeutet, daß der Dienst zeitweise nicht verfügbar ist. Für den Dienst files weist dies normalerweise

darauf hin, daß die relevante Datei gerade von einem anderen Prozeß blockiert wurde. Bei den anderen Diensten könnte es ein Hinweis darauf sein, daß der Server zeitweise keine Verbindungen akzeptierte. Die Standardaktion für diesen Zustand ist continue. Ein simples Anwendungsbeispiel für den beschriebenen Mechanismus zeigt Tabelle 6.3. Beispiel 6.3: Beispieldatei nsswitch.conf mit einer Handlungsanweisung # /etc/nsswitch.conf # # Beispielkonfiguration der GNU-Name-Service-Switch-Funktionalität # Informationen über diese Datei finden Sie im Paket 'libc6-doc' hosts: dns [!UNAVAIL=return] files networks: files

In diesem Beispiel wird die Hostauflösung mit dem Domain Name Service versucht. Wenn sich als Resultat der Wert “nicht verfügbar” (unavailable) ergibt, versucht der Resolver eine erneute Namensauflösung mit der lokalen Datei /etc/hosts. Andernfalls wird das erhaltene Resultat zurückgeliefert. Auf die hosts-Datei wird also nur dann zurückgegriffen, wenn der Name-Server aus irgendeinem Grund nicht verfügbar ist.

Konfiguration der Name-Server-Aufrufe mit resolv.conf Wenn Sie die Resolver-Bibliothek so konfigurieren, daß sie zur Ermittlung von Hostadressen den BIND-Namensdienst verwendet, müssen Sie ihr auch mitteilen, welche Server sie benutzen soll. Dafür gibt es eine separate Datei namens resolv.conf. Fehlt diese Datei oder ist sie leer, nimmt der Resolver an, daß sich der Name-Server auf Ihrem lokalen Host befindet. Um einen Name-Server auf Ihrem lokalen Host laufen zu lassen, müssen Sie ihn separat einrichten, wie es in den folgenden Abschnitten erläutert wird. Wenn Sie sich in einem lokalen Netzwerk befinden und sich die Gelegenheit bietet, einen bereits vorhandenen Name-Server zu benutzen, sollten Sie auf jeden Fall darauf zurückgreifen. Wenn Sie eine Dialup-Verbindung ins Internet haben, werden Sie für gewöhnlich den Name-Server Ihres Providers in der Datei resolv.conf eintragen. Die wichtigste Option in resolv.conf ist nameserver, die die Adresse eines Name-Servers angibt. Wenn Sie die Option mehrmals angeben, werden die Server in der angegebenen Reihenfolge ausprobiert. Deshalb sollten Sie unbedingt den zuverlässigsten Server zuerst eintragen. Wenn Sie keinen Name-Server eintragen, nimmt der Resolver an, daß einer auf der lokalen Maschine läuft. Gegenwärtig werden bis zu drei name server-Einträge in resolv.conf unterstützt. Zwei weitere Befehle, domain und search, geben Domainnamen an, die der Resolver an einen Namen anhängt, wenn die zugehörige Adresse beim ersten Versuch nicht gefunden wird. Wenn Sie beispielsweise telnet benutzen, wollen Sie im allgemeinen nicht immer den voll qualifizierten Domainnamen eingeben, sondern lieber so etwas wie gauss angeben und den Resolver den Domainnamen mathematics.groucho.edu anhängen lassen. Genau dafür ist der Befehl domain da. Mit ihm können Sie eine Default-Domain angeben, die immer dann angehängt werden soll, wenn ein Name nicht aufgelöst werden konnte. Wird dem Resolver z.B. der Name gauss übergeben, findet dieser den Namen gauss. nicht im DNS, da es eine solche TLD nicht gibt. Wird mathematics.groucho.edu als Standarddomäne angegeben, wiederholt der Resolver seine Anfrage und hängt diese Standarddomäne an den Hostnamen gauss an. Diese Abfrage ist nun erfolgreich. Prima, werden Sie jetzt vielleicht denken, aber sobald ich die Domain verlasse, bin ich wieder bei den langen Namen und tippe mir die Finger wund. Warum kann ich nicht Namen wie quark.physics benutzen, wo wir doch schon an der Groucho-MarxUniversität sind? Hier kommt die Suchliste (search list) ins Spiel. Eine Suchliste kann mit der Option search angegeben werden und ist eine Verallgemeinerung der domain-Anweisung. Während Sie mit domain nur eine einzelne Domain angeben dürfen, akzeptiert search eine ganze Liste davon, deren Einträge alle der Reihe nach durchprobiert werden, bis ein gültiger DNS-Eintrag gefunden wird. Die einzelnen Namen der Liste müssen durch Leerzeichen oder Tabulatoren voneinander getrennt werden. Die Befehle search und domain schließen einander aus und dürfen höchstens einmal auftauchen. Wenn keiner der beiden Befehle angegeben ist, versucht der Resolver, die Default-Domain mit Hilfe der Systemfunktion getdomainname(2) aus dem

lokalen Hostnamen zu raten. Hat der Hostname keinen Domain-Teil, wird als Default-Domain die Root-Domain (.) angenommen. Wenn Sie in resolv.conf eine Suchliste definieren, sollten Sie sich genau überlegen, welche Domains Sie dort eintragen. Die Resolver-Bibliotheken vor BIND-4.9 pflegten aus dem Domainnamen eine Liste zusammenzubauen, wenn vom Administrator keine angegeben wurde. Diese Default-Liste enthielt die Default-Domain plus alle Ober-domains. Das konnte zu Problemen führen, da DNS-Anfragen manchmal bei Name- -Servern landeten, für die sie nie bestimmt waren. Angenommen, Sie sitzen in der virtuellen Brauerei und wollen sich auf foot.groucho.edu einloggen. Durch einen versehentlichen Tippfehler schreiben Sie aber foo statt foot. Der Name-Server der GMU kennt aber keine Maschine namens foo, was er Ihrem Resolver auch mitteilt. Mit der alten Suchliste würde der Resolver nun fortfahren und in den Domains vbrew.com und com fahnden. Vor allem der letzte Fall ist problematisch, da es dort durchaus eine Domain namens groucho.edu.com geben kann. Wenn diese Domain dann auch noch einen Host namens foo enthält, landet Ihr login-Programm bei einer ganz anderen Maschine, als von Ihnen beabsichtigt. Für einige Applikationen können diese fehlerhaften Zuordnungen ein Sicherheitsproblem darstellen. Aus diesem Grund sollten Sie die Suchliste auf die Unterdomains Ihrer Organisation oder etwas Vergleichbares beschränken. Im Fachbereich Mathematik der Groucho-Marx-Universität würde die Liste beispielsweise nur maths.groucho.edu und groucho.edu enthalten. Wenn Ihnen all das zu verwirrend vorkommt, werfen Sie einen Blick auf die Datei resolv.conf der virtuellen Brauerei: # /etc/resolv.conf # Unsere Domain domain Name-Server: nameserver 172.16.1.1

vbrew.com # # Wir benutzen vlager als zentralen

Wenn Sie in dieser Konfiguration die Adresse von vale suchen, wird der Resolver erst versuchen, vale nachzuschlagen, und wenn das fehlschlägt, vale.vbrew.com.

Robustheit des Resolvers Wenn Sie ein LAN innerhalb eines größeren Netzes betreiben, sollten Sie auf jeden Fall zentrale Name-Server benutzen (falls verfügbar). Die Server bauen mit der Zeit umfangreiche Caches auf, die wiederholte Anfragen beschleunigen, da alle DNSQueries im Laufe der Zeit reichhaltige Caches entwickeln, die die DNS-Anfragen beschleunigen, da alle DNS-Queries über sie abgewickelt werden. Dieses Vorgehen hat allerdings einen gravierenden Nachteil: Als ein Brand ein Backbone-Kabel an Olafs Universität zerstörte, kam alle Arbeit auf dem LAN des Fachbereichs zum Erliegen, da der Resolver keinen der Name-Server mehr erreichen konnte. Darunter litten die meisten Netzwerkdienste. So konnte man sich nicht mehr auf den X-Terminals einloggen, die Drucker waren nicht mehr ansprechbar usw. Obwohl es nun nicht gerade häufig passiert, daß Uni-Backbones in Flammen aufgehen, ist es durchaus sinnvoll, Vorsichtsmaßnahmen gegen solche Fälle zu treffen. Eine Möglichkeit ist, einen eigenen Name-Server aufzusetzen, der die lokale Domain bedient und alle Anfragen für andere Hostnamen an den zentralen Server weiterleitet. Natürlich funktioniert das nur, wenn Sie eine eigene Domain administrieren. Ebensogut können Sie aber auch Ihre lokalen Maschinen zusätzlich in /etc/hosts eintragen und in der Datei /etc/host.conf den String order bind, hosts anfügen, damit der Resolver im Notfall auf diese statischen Tabellen zurückgreifen kann. Alternativ können Sie eine Hosttabelle zur Sicherung für Ihre Domain oder ihr LAN in /etc/hosts eintragen. Das ist schnell erledigt. Sie müssen einfach nur sicherstellen, daß die Resolver-Bibliothek zuerst DNS befragt und erst danach in den Hostdateien nachschaut. Dazu tragen Sie order bind,hosts in die Datei /etc/host.conf bzw. hosts: dns files in /etc/nsswitch.conf ein. Bei diesen Einstellungen greift der Resolver immer auf die Hostdateien zurück, wenn der zentrale Name-Server nicht erreicht werden konnte.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie DNS funktioniert DNS verwaltet Hostnamen in einer Domain-Hierarchie. Eine Domain ist eine Ansammlung von Sites, die in einer bestimmten Beziehung zueinander stehen, sei es, weil sie ein gemeinsames Netzwerk bilden (z.B. alle Maschinen auf einem Universitätsgelände oder alle Hosts im BITNET), weil sie alle einer bestimmten Organisation angehören (z.B. der USRegierung) oder weil sie einfach nur geographisch dicht beieinander liegen. So sind beispielsweise amerikanische Universitäten gewöhnlich in der Domain edu zusammengefaßt, wobei jede Uni ihre eigene Subdomain hat, die alle ihre Hosts umfaßt. So hat die Groucho-Marx-Universität die Domain groucho.edu, in der das LAN des mathematischen Instituts die Subdomain maths.groucho.edu besitzt. Diese werden an die Namen aller Rechner dieses Institutsnetzwerkes angehängt, so daß z.B. erdos den voll qualifizierten Domainnamen (Fully Qualified Domain Name, FQDN) erdos.maths. groucho.edu hat. Jeder FQDN ist weltweit eindeutig. Abbildung 6.1 zeigt einen Ausschnitt des Namensraums. Der Eintrag an der Wurzel des Baums, der durch einen Punkt gekennzeichnet ist, wird dementsprechend als Root-Domain bezeichnet und umfaßt alle anderen Domains. Um zu verdeutlichen, daß ein Hostname ein voll qualifizierter Domainname ist und nicht etwa relativ zu einer (impliziten) lokalen Domain, wird er manchmal mit einem abschließenden Punkt geschrieben. Dieser Punkt zeigt an, daß die letzte Komponente des Namens die Root-Domain ist. Abbildung 6.1: Ein Ausschnitt des Domain-Namensraums

Je nach ihrer Position in der Namenshierarchie wird eine Domain als Top-Level, Second-Level oder Third-Level bezeichnet. Es gibt noch weitergehende Unterteilungen, sie kommen aber selten vor. Die folgende Liste enthält diverse Top-Level-Domains, die Ihnen öfters begegnen: Domain Beschreibung edu com org net mil gov

uucp

(Zumeist US-amerikanische) Ausbildungsstätten wie Universitäten usw. Kommerzielle Organisationen und Firmen. Nicht-kommerzielle Organisationen. Private UUCP-Netzwerke sind häufig in -dieser Domain. Gateways und andere administrative Hosts. Militärische Institutionen der USA. Institutionen der US-Regierung. Alle Site-Namen, die früher als UUCP-Namen ohne Domains benutzt wurden, befinden sich jetzt offiziell in dieser Domain.

Aus historischen Gründen wurden die ersten vier Domains der USA zugeordnet. Änderungen in der Politik führten dazu, daß diese globalen Top-Level-Domains (gTLD) nun von aller Welt genutzt werden können. Zur Zeit laufen Verhandlungen über die Einführung weiterer globaler Top-Level-Domains, die die Auswahlmöglichkeiten an Domainnamen deutlich erhöhen würden. Außerhalb der USA benutzt jedes Land eine Top-Level-Domain aus zwei Buchstaben, die nach dem Landesnamen benannt und in ISO-3166 beschrieben sind. So nutzt z.B. Finnland die Domain fi, Frankreich fr, Deutschland de und Australien au. Unterhalb dieser Top-Level-Domains kann das NIC jedes Landes die Hostnamen nach Belieben organisieren. Australiens Second-Level-Domains sind denen der internationalen Top-Level-Domains sehr ähnlich, z.B. com.au und edu.au. Andere Länder wie Deutschland benutzen diesen Extra-Level nicht, sondern verwenden dafür ziemlich lange Namen, die direkt auf

die Organisation hinweisen, die diese Domains besitzen. So sind z.B. Namen wie ftp.informatik.uni-erlangen.de durchaus gängig. Nennen Sie das deutsche Gründlichkeit, wenn Sie so wollen. Natürlich bedeuten diese nationalen Domains nicht, daß ein Host innerhalb dieser Domain im zugehörigen Land stationiert ist. Es bedeutet einfach nur, daß die Domain vom NIC des zugehörigen Landes registriert wurde. Zum Beispiel kann ein schwedischer Hersteller eine Filiale in Australien haben, deren Domain mit der Top-Level-Domain se endet. Die hierarchische Aufteilung des Namensraumes in Domänen löst auf elegante Weise das Problem der Eindeutigkeit von Namen. Mit DNS muß ein Hostname nur innerhalb seiner eigenen Domain eindeutig benannt sein; er ist damit weltweit eindeutig identifiziert. Außerdem lassen sich voll qualifizierte Namen leicht merken. Allein das sind schon sehr gute Gründe dafür, eine große Domänen in mehrere Sub-Domänen aufzuteilen. DNS kann aber noch viel mehr für Sie tun. Es ermöglicht Ihnen auch, die Verantwortung über eine Subdomain an ihre Administratoren zu delegieren. Beispielsweise könnten die Verwalter des Groucho-Rechenzentrums für jede Abteilung eine Subdomain erzeugen; den Subdomains math und physics sind wir bereits oben begegnet. Wenn sie nun der Auffassung wären, das Netzwerk im Physik-Institut wäre zu groß und chaotisch, um von außerhalb verwaltet werden zu können (schließlich sind Physiker bekanntlich ja besonders widerspenstige Typen), könnten sie die Kontrolle der Domain physics. -groucho.edu an die Administratoren dieses Netzes abgeben. Diese Administratoren könnten dann innerhalb dieser Domain nach Belieben Hostnamen und IP-Adressen aus ihrem Netzwerk vergeben, ohne sich dabei mit Außenstehenden absprechen zu müssen. Aus diesem Grund wird der Namensraum immer in einzelne Zonen aufgeteilt, deren Wurzel jeweils eine Domäne ist. Man beachte den feinen Unterschied zwischen einer Zone und einer Domain: Die Domain groucho.edu umfaßt alle Hosts an der Groucho-Marx-Universität, während die Zone groucho.edu nur die Hosts enthält, die direkt vom Rechenzentrum verwaltet werden, z.B. die im Mathematik-Institut. Die Hosts im Physik-Institut gehören dagegen einer anderen Zone an, nämlich physics.groucho.edu. In Abbildung 6.1 ist der Anfang einer Zone mit einem kleinen Kreis rechts neben dem Domainnamen markiert.

Ermittlung von Namen mit DNS Auf den ersten Blick scheint der ganze Domain- und Zonenkram die Namensauflösung zu einer unnötig komplizierten Angelegenheit zu machen. Schließlich stellt sich ja die Frage: Woher soll eine schlichte Anwendung wissen, welche Namen zu welchen Hosts gehören, wenn es keine zentrale Autorität gibt, die diese Zuordnungen kontrolliert? Jetzt kommt der wirklich geniale Teil von DNS. Wenn Sie herausfinden wollen, welche IP-Adresse zu erdos gehört, erhalten Sie von DNS die lapidare Antwort: “Fragen Sie diejenigen, die für dessen Verwaltung zuständig sind, die können es Ihnen sagen!” Tatsächlich ist DNS eine gigantische verteilte Datenbank. Implementiert ist sie mittels sogenannter Name-Server, die Informationen über eine gegebene Domain oder eine ganze Reihe von Domains bereitstellen. Für jede Zone existieren mindestens zwei (bzw. höchstens einige wenige) Name-Server, die alle maßgeblichen Informationen über Hosts in dieser Zone halten. Um die IP-Adresse von erdos zu bekommen, ist dafür lediglich der Name-Server für die Zone groucho.edu zu kontaktieren, der dann die gewünschte Information liefert. Leichter gesagt als getan, werden Sie jetzt vielleicht denken. Woher soll ich denn wissen, wie ich den Name-Server an der Groucho-Marx-Universität erreiche? Keine Sorge, auch wenn Ihr Computer nicht gerade mit einem adreßauflösenden Orakel ausgestattet ist, hilft Ihnen DNS auch in diesem Punkt aus der Patsche. Wenn Ihre Applikation Informationen über erdos haben möchte, setzt sie sich zunächst mit einem lokalen Name-Server in Verbindung, der dafür eine sogenannte iterative Anfrage startet. Zunächst sendet er eine Anfrage an einen Name-Server für die Root-Domain, in der er nach der Adresse von erdos.maths.groucho.edu fragt. Der angesprochene Root-Name-Server erkennt, daß dieser Name nicht zu den von ihm autorisierten Zonen gehört, dafür aber zu einer unterhalb der Domain edu liegenden Zone. Folglich gibt er Ihrem Name-Server die Empfehlung, sich an einen Name-Server zu wenden, der für die Zone edu zuständig ist, und präsentiert ihm dafür eine Liste aller edu-Name-Server samt ihrer Adressen. Ihr lokaler Name-Server setzt daraufhin seine Arbeit fort und fragt einen der in der Liste enthaltenen Server, z.B. a.isi.edu. Dieser verfährt ähnlich wie der Root-Name-Server; er weiß, daß die Leute von groucho.edu ihre eigene Zone verwalten, und verweist Sie daher an deren Server. Schließlich befragt Ihr lokaler Name-Server einen dieser Server nach erdos und erhält endlich die sehnlichst erwünschte Antwort, da dieser Name zur Zone des befragten Servers gehört und dieser die zugehörige IP-Adresse zurückliefern kann.

Das Ganze erweckt den Eindruck, daß ziemlich viel Datenverkehr in Gang gesetzt werden muß, nur um so eine klitzekleine IPAdresse herauszufinden. In Wirklichkeit macht dies aber nur einen winzigen Bruchteil dessen aus, was sonst über die Leitungen fließen würde, wenn wir immer noch mit HOSTS.TXT arbeiten müßten. Daß es hierbei immer noch Möglichkeiten zur Optimierung gibt, versteht sich natürlich von selbst. Um die Antwortzeiten für zukünftige Anfragen zu verringern, speichert Ihr Name-Server die ermittelten Informationen in seinem lokalen Speicher (Cache). Wenn das nächste Mal jemand in Ihrem lokalen Netz eine Hostadresse der Domain groucho.edu benötigt, schaut Ihr Name-Server in seinem Cache nach und leitet die Anfrage ohne weitere Nachforschungen sofort an den Name-Server der groucho.edu-Domain weiter.1 Natürlich behält der Name-Server diese Informationen nicht für immer und ewig; er löscht sie nach einer gewissen Zeit. Diese Zeit bis zur Löschung wird Lebensdauer (Time To Live, TTL) genannt. Der Administrator der betroffenen Zone teilt jedem Datensatz in der DNS-Datenbank eine solche TTL zu.

Typen von Name-Servern Name-Server, die sämtliche Informationen über die Hosts einer Zone verwalten, sind für diese Zone verantwortlich (authoritative) und werden manchmal auch als Master-Name-Server bezeichnet. Jede Anfrage über einen Host in dieser Zone endet schließlich bei einem solchen Master-Name-Server. Master-Name-Server müssen immer ziemlich gut synchronisiert werden. Daher macht der Netzwerkadministrator einer Zone einen der Master-Server zum primären Server und die anderen zu sekundären Servern. Der primäre Server lädt alle seine Zonen-Informationen aus Datendateien; die sekundären Server kopieren diese Informationen in regelmäßigen Abständen vom Master-Server. Wenn man mehrere Name-Server zur Verfügung hat, kann das Arbeitspensum auf sie verteilt werden; außerdem bieten sie die Möglichkeit zur redundanten Datenhaltung. Fällt einer der Name-Server mal aus, z.B. durch Crash oder Verlust der Netzwerkverbindung, werden alle Anfragen an diesen Server an die anderen weitergeleitet. Allerdings schützt Sie dieses Verfahren nicht vor Fehlfunktionen der Server, die sich in falschen DNS-Antworten bemerkbar machen. Ursachen solcher Fehler können Bugs in der Serversoftware sein. Sie können auch einen Name-Server betreiben, der für gar keine Domäne verantwortlich ist.2 Das ist durchaus nützlich, da der Name-Server weiterhin DNS-Antworten für die Applikationen im lokalen Netzwerk cachen kann. Ein solcher Server wird daher als Caching-only-Server bezeichnet.

Die DNS-Datenbank Wir haben gesehen, daß DNS nicht nur mit IP-Adressen von Hosts arbeitet, sondern auch Informationen über Name-Server austauscht. DNS-Datenbanken können in der Tat viele verschiedene Arten von Einträgen aufweisen. Jede Einzelinformation in einer DNS-Datenbank wird als Resource-Record (RR) bezeichnet. Jeder Record enthält einen Typ, der Auskunft über die Art der Information liefert, sowie eine Klasse, die Auskunft über den Netzwerktyp gibt, für den die Information bestimmt ist. Die Klassen werden für die verschiedenen Adreß-Schemata benötigt, wie IP-Adressen (die INKlasse), Hesiod-Adressen (von MITs Kerberos-System benutzt) und einige mehr. Der Prototyp eines solchen Resource-RecordTyps ist der A-Record; er assoziiert einen voll qualifizierten Domainnamen mit einer IP-Adresse. Ein Host kann unter mehreren Namen bekannt sein. Zum Beispiel könnten Sie einen Server besitzen, der sowohl FTP- als auch WWW-Dienste anbietet und unter den Namen ftp.machine.org und www.machine.org erreichbar ist. Einer dieser Namen muß als offizieller bzw. kanonischer Hostname eingetragen sein; die anderen Namen sind einfach nur Aliasnamen, die auf den offiziellen Hostnamen verweisen. Der Unterschied liegt darin, daß ein kanonischer Hostname immer mit einem A-Record assoziiert ist, während die Aliasnamen einen Record vom Typ CNAME besitzen, der auf den kanonischen Hostnamen zeigt. Wir werden hier nicht alle Record-Typen behandeln, stellen dafür aber ein kurzes Beispiel vor. Tabelle 6.4 zeigt einen Ausschnitt der Domain-Datenbank, die in die Name-Server für die Zone physics.groucho.edu geladen wird.

Beispiel 6.4: Auszug aus der Datei named.hosts für das physikalische Institut ; Autoritative Informationen über physics.groucho.edu. @ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. { 1999090200 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl } ; ; Name-Server IN NS niels IN NS gauss.maths.groucho.edu. gauss.maths.groucho.edu. IN A 149.76.4.23 ; ; Theoretische Physik (Subnetz 12) niels IN A 149.76.12.1 IN A 149.76.1.12 nameserver IN CNAME niels otto IN A 149.76.12.2 quark IN A 149.76.12.4 down IN A 149.76.12.5 strange IN A 149.76.12.6 ... ; Teilchenbeschleuniger-Labor (Subnetz 14) boson IN A 149.76.14.1 muon IN A 149.76.14.7 bogon IN A 149.76.14.12 ...

Außer den A- und CNAME-Records sehen Sie am Anfang der Datei einen speziellen Record, der sich über mehrere Zeilen erstreckt. Das ist der SOA-Resource-Record (Start of Authority); er enthält allgemeine Informationen über die Zone, für die der Server zuständig ist, so zum Beispiel über die Lebensdauer aller Records. Beachten Sie, daß alle Namen in der Beispieldatei, die nicht mit einem Punkt enden, als relativ zur Domain physics.groucho.edu aufzufassen sind. Der spezielle Name (@) im SOA-Record verweist auf den Domainnamen an sich. Wir haben bereits früher gesehen, daß die Name-Server für die Domain groucho.edu irgend etwas über die Zone physics wissen müssen, um Anfragen an deren Name-Server stellen zu können. Diese Informationen stellt üblicherweise ein Paar von Records bereit, bestehend aus dem NS-Record, der den FQDN des Servers ergibt, und einem A-Record, der eine IP-Adresse mit dem Namen assoziiert. Da diese Records sozusagen der “Kleber” sind, der den Namensraum zusammenhält, werden sie oft als glue records bezeichnet. Sie sind die einzigen Arten von Records, in denen eine Oberzone tatsächlich Informationen über Hosts der untergeordneten Zonen enthält. Die Glue Records, die auf die Name-Server für physics.groucho.edu verweisen, zeigt Tabelle 6.5. Beispiel 6.5: Auszug aus der Datei named.hosts für GMU ; Zonendaten für die Zone groucho.edu @ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. { 1999070100 ; serial no 360000 ; refresh 3600 ; retry 3600000 ; expire 3600 ; default ttl .... ; ; Glue Records für die Zone physics.groucho.edu physics IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. IN A 149.76.12.1 gauss.maths IN A 149.76.4.23 ...

} niels.physics

Reverse Lookups Die Ermittlung der IP-Adressen von Hosts ist sicherlich die häufigste Anwendung des Domain Name Systems. Manchmal möchten Sie jedoch den umgekehrten Weg gehen und den kanonischen Hostnamen zu einer gegebenen IP-Adresse wissen. Ein solches Verfahren wird Reverse Mapping genannt und von vielen Netzwerkdiensten dazu verwendet, die Identität eines Clients zu überprüfen. Bei Verwendung einer einzelnen hosts-Datei gestaltet sich die Sache recht einfach; für Reverse Lookups muß die Datei nur nach der zum Hostnamen eingetragenen IP-Adresse durchsucht werden. Bei DNS kommt eine erschöpfende Suche im gesamten Namensraum natürlich nicht in Frage. Für diesen Zweck wurde die spezielle Domain inaddr.arpa eingerichtet. Sie enthält die IP-Adressen sämtlicher Hosts in umgekehrter Dotted Quad Notation. Zum Beispiel hat sie für die IP-Adresse 149.76.12.4 einen Eintrag, der 4.12.76.149.in-addr.arpa lautet. Der Resource-Record-Typ, der diese Namen mit ihren kanonischen Hostnamen verbindet, wird PTR genannt. Eine autoritative Zone zu erzeugen bedeutet, daß ihre Administratoren volle Kontrolle darüber besitzen, wie sie Adressen und Namen zuordnen. Da sie für gewöhnlich ein oder mehrere IP-Netzwerke oder -Subnetze verwalten, existiert eine 1-zu-nBeziehung zwischen DNS-Zonen und IP-Netzwerken. Das physikalische Institut zum Beispiel umfaßt die Subnetze 149.76.8.0, 149.76.12.0 und 149.76.14.0. Daher müssen zusätzlich zur physics-Zone auch neue Einträge in der in-addr.arpa-Domäne erzeugt und an die Netzwerkadministratoren des Instituts delegiert werden: 8.76.149.in-addr.arpa, 12.76.149.in-addr.arpa und 14.76.149.in-

addr.arpa. Ansonsten müßten sie für die Installation eines neuen Hosts im Collider Lab die Oberdomain bitten, die neue Adresse in ihre in-addr.arpa-Zonendatei einzutragen. Die Zonen-Datenbank für das Subnetz 12 wird in Tabelle 6.6 gezeigt. Die zugehörigen Glue Records in der Datenbank ihrer Oberzone werden in Tabelle 6.7 gezeigt. Beispiel 6.6: Auszug aus der Datei named.rev für Subnetz 12 ; die Domain 12.76.149.in-addr.arpa @ IN SOA niels.physics.groucho.edu. janet.niels.physics.groucho.edu. { 1999090200 360000 3600 3600000 3600 } 2 IN PTR otto.physics.groucho.edu. 4 IN PTR quark.physics.groucho.edu. 5 IN PTR down.physics.groucho.edu. 6 IN PTR strange.physics.groucho.edu.

Beispiel 6.7: Auszug aus der Datei named.rev für Netzwerk 149.76 ; die Domain 76.149.in-addr.arpa @ IN SOA vax12.gcc.groucho.edu. joe.vax12.gcc.groucho.edu. { 1999070100 360000 3600 3600000 3600 } ... ; Subnetz 4: Mathematik-Institut 1.4 IN PTR sophus.maths.groucho.edu. 17.4 IN PTR erdos.maths.groucho.edu. 23.4 IN PTR gauss.maths.groucho.edu. ... ; Subnetz 12: Physik-Institut, separate Zone 12 IN NS niels.physics.groucho.edu. IN NS gauss.maths.groucho.edu. niels.physics.groucho.edu. IN A 149.76.12.1 gauss.maths.groucho.edu. IN A 149.76.4.23 ...

in-addr.arpa-Systemzonen können nur als Obermengen von IP-Netzwerken erzeugt werden. Eine noch schwerwiegendere Einschränkung ist die Bedingung, daß die Netzmasken dieser Netzwerke immer an Bytegrenzen liegen müssen. Alle Subnetze der Groucho-Marx-Universität haben eine Netzmaske von 255.255.255.0, so daß für jedes Subnetz eine in-addr.arpa-Zone erzeugt werden kann. Bei einer Netzmaske von 255.255.255.128 wäre jedoch die Erzeugung von Zonen für das Subnetz 149.76. 12.128 unmöglich, da es nun aber keine Möglichkeit gibt, DNS mitzuteilen, daß die Domain 12.76.149.in-addr.arpa in zwei Autoritätszonen aufgeteilt wurde, mit Hostnamen von 1 bis 127 sowie von 128 bis 255.

1.

Würden diese Informationen nicht in Caches gehalten, wäre DNS genauso ineffizient wie jede andere Methode, da dann jede einzelne Anfrage die Root-Name-Server beanspruchen würde.

2.

Nun ja — fast. Ein Name-Server muß zumindest Namensdienste für localhost und Reverse Lookups von 127.0.0.1 bieten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der Einsatz von named Das Programm, das auf den meisten UNIX-Maschinen den DNS-Dienst zur Verfügung stellt, heißt named. Dieser Server wurde ursprünglich für BSD entwickelt und ist für Anfragen von Klienten und eventuell anderen Name-Servern zuständig. Die Version 4 der BIND-Software war ziemlich lange aktuell und wurde in die meisten Linux-Distributionen integriert. Mittlerweile steht für fast alle Linux-Distributionen das neuere BIND Version 8 zur Verfügung. Diese Version wurde im Vergleich zur vorhergehenden stark verändert. Sie bietet eine erweiterte Funktionalität, z.B. Unterstützung für dynamische DNS-Updates und Änderungsmeldungen, ist viel leistungsfähiger und benutzt eine neue Syntax für die Konfigurationsdatei.1 Details hierzu finden Sie in der Dokumentation, die der Quelldistribution beiliegt. Dieser Abschnitt setzt voraus, daß Sie schon etwas über die Funktionsweise von DNS, dem Domain Name System, wissen. Wenn die folgende Erläuterung für Sie wie böhmische Dörfer klingt, sollten Sie sich nochmal das Wie DNS funktioniert vornehmen. named wird für gewöhnlich beim Booten des Rechners gestartet und läuft, bis die Maschine wieder heruntergefahren wird. Die BIND-Implementierungen vor Version 8 lesen zunächst die Datei /etc/named.boot, die ihre Konfiguration beschreibt, und eine Reihe weiterer Dateien, die die Zuordnung von Domainnamen zu Adressen und ähnliches festlegen. Letztere werden auch Zonendateien (zone files) genannt. Ab Version 8 benutzt BIND die Konfigurationsdatei /etc/named.conf anstelle von /etc/named.boot. Um named vom Prompt aus zu starten, geben Sie am Prompt einfach folgendes ein: # /usr/sbin/named

named wird gestartet, liest die Datei named.boot und alle darin angegebenen Zonen-Dateien. Die Prozeß-ID wird im ASCIIFormat in der Datei /var/run/named.pid abgelegt und, falls erforderlich, werden die Zonen-Dateien von primären Servern heruntergeladen. Anschließend wartet er auf Port 53 auf einkommende Anfragen.

Die Datei named.boot Vor Version 8 waren die Konfigurationsdateien von BIND sehr einfach strukturiert. In Version 8 wurde eine völlig neu gestaltete Syntax eingeführt, um den vielen neuen Features gerecht zu werden. Das fängt bereits beim Namen der Konfigurationsdatei an; sie wurde von der alten Bezeichnung /etc/named.boot in die neue Bezeichnung /etc/named.conf

geändert. Wir beziehen uns im folgenden noch auf die alte Version, da sie in den Distributionen immer noch am weitesten verbreitet ist, präsentieren dabei immer eine äquivalente named.conf, so daß Sie die Unterschiede leichter erkennen können und wissen, wie Sie das alte Format in das neue konvertieren müssen. Die Datei named.boot ist im allgemeinen sehr klein und enthält wenig mehr als Verweise auf die Master-Dateien, in denen sich Zonendaten und Verweise auf andere Name-Server befinden. Kommentare in der Boot-Datei beginnen mit einem Hashzeichen (#) oder einem Semikolon (;) und reichen bis zum Zeilenende.Bevor wir aber das Format von named.boot im Detail betrachten, werfen wir zunächst einen Blick auf die Beispieldatei für vlager in Tabelle 6.8. Beispiel 6.8: Datei named.boot für vlager ; ; Datei /etc/named.boot für vlager.vbrew.com ; directory /var/named ; ; domain file ;----------------- cache . named.ca primary vbrew.com named.hosts primary 0.0.127.in-addr.arpa named.local primary 16.172.in-addr.arpa named.rev

Lassen Sie uns einen Blick auf jede einzelne Anweisung werfen. Das Schlüsselwort directory teilt named mit, daß alle nachfolgenden Dateien, z.B. Zonendateien, aus dem angegebenen Verzeichnis /var/named geladen werden sollen. Das spart ein wenig Tipparbeit. Der im Beispiel gezeigte Befehl primary lädt Informationen in named. Diese Informationen werden jeweils der Master-Datei entnommen, die im letzten Argument angegeben wird. Diese Dateien repräsentieren DNS-Resource-Records, die wir uns später genauer ansehen werden. Im diesem Beispiel wird named als primärer Name-Server für drei Domains konfiguriert, wie die primary-Anweisungen am Ende der Datei zeigen. Die erste Zeile weist named beispielsweise an, als primärer Server für vbrew.com zu dienen und die Zonendaten der Datei named.hosts zu entnehmen. Der cache-Eintrag hat eine besondere Aufgabe und sollte auf fast allen Maschinen vorhanden sein, die einen Name-Server einsetzen. Er weist named einerseits an, einen Cache aufzubauen, und andererseits, die Adressen der Name-Server für die RootDomain aus der Cache-Datei named.ca zu laden. Diese Adressen heißen in der Fachsprache Root Name Server Hints; wir werden im folgenden noch einmal auf sie zurückkommen. Hier ist eine Liste der wichtigsten Optionen, die Sie in named.boot benutzen können: directory Diese Option gibt das Verzeichnis an, in dem sich die Zonendateien befinden. Damit können Dateinamen in anderen Optionen relativ zu diesem Verzeichnis angegeben werden. Sie können auch mehrere Verzeichnisse angeben, indem Sie den directory-Befehl mehrfach benutzen. Dem Linux File System Standard zufolge sollten Zonendaten immer in /var/named abgelegt werden. primary Diese Option benötigt einen Domainnamen und einen Dateinamen als Argumente und erklärt den lokalen Server als autoritativ für diese Domain. Als primärer Server lädt named die Zoneninformationen aus der angegebenen MasterDatei. Es gibt immer wenigstens einen primary-Eintrag in der Konfigurationsdatei, der für das Reverse Mapping (oder der Rückwärtsauflösung) der Netzwerkadresse 127.0.0.0, das Loopback-Netzwerk, zuständig ist. secondary Dieser Befehl benötigt einen Domainnamen, eine Adreßliste und einen Dateinamen als Argumente. Er erklärt den lokalen Server zum sekundären Master-Server für die angegebene Domain.

Ein sekundärer Server ist ebenfalls autoritativ für die fragliche Domain, liest aber seine Informationen nicht aus Dateien, sondern versucht, sie vom primären Server zu laden. Für named muß die Adreßliste deshalb die IP-Adresse mindestens eines primären Servers enthalten. Der lokale Server probiert diese Name-Server der Reihe nach durch, bis er die Zonendaten erfolgreich übertragen konnte. Die Daten werden anschließend in der Backup-Datei abgelegt, die im dritten Argument angegeben wurde. Wenn keiner der angegebenen Server erreichbar ist, lädt named die Zoneninformationen statt dessen aus der Backup-Datei. named versucht dann, die Zonendaten in regelmäßigen Abständen aufzufrischen. Dies wird später im Zusammenhang mit dem Resource-Typ SOA erklärt. Cache Diese Option erwartet eine Domain und einen Dateinamen als Argumente. Die Datei enthält eine Liste von Records mit den Adressen der Root-Server. named ignoriert beim Lesen dieser Datei alle Records außer A und NS. Das DomainArgument sollte der Name der Root-Domain sein, also ein einfacher Punkt (.). Diese Daten sind für named äußerst wichtig: Wenn die cache-Anweisung nicht in der Boot-Datei auftaucht, wird named überhaupt keinen lokalen Cache bereits gefundener Adressen anlegen. Das kann unter Umständen zu einer schweren Performance-Bremse werden und die Netzbelastung unnötig erhöhen, wenn der nächste Server nicht im lokalen Netz liegt. Außerdem ist named so nicht in der Lage, irgendwelche Root-Server zu erreichen, und kann somit nur solche Adressen auflösen, für die er autoritativ ist. Eine Ausnahme von dieser Regel sind sogenannte -forwarding servers (siehe die folgende Option forwarders). forwarders Dieser Anweisung folgt eine Liste von Adressen von Name-Servern, die named befragen darf, wenn er selbst nicht in der Lage war, eine Adresse mit Hilfe seines Caches aufzulösen. Diese Server werden der Reihe nach ausprobiert, bis einer von ihnen die Anfrage beantwortet. Normalerweise würden Sie hier den Name-Server Ihres Netz-Providers oder einen anderen wohlbekannten Server als Forwarder einsetzen. slave Dieser Befehl macht Ihren Name-Server zu einem Slave-Server. Das bedeutet, daß er niemals selbst rekursive Anfragen durchführt, sondern sie immer an die Server weiterleitet, die in der forwarders-Anweisung angegeben sind. Es gibt zwei Optionen, auf die wir hier nicht näher eingehen: sortlist und domain. In den Datenbankfeldern können noch zwei weitere Direktiven vorkommen: $INCLUDE und -$ORIGIN.Sie kommen eher selten vor, weswegen wir darauf auch nicht eingehen.

Die BIND-8-Konfigurationsdatei host.conf BIND Version 8 führte eine ganze Reihe neuer Features ein, dazu kam eine völlig neu gestaltete Syntax für die Konfigurationsdatei. Die Datei named.boot mit ihren simplen einzeiligen Anweisungen wurde durch die Datei named.conf ersetzt, die Anweisungen in einer Syntax enthält, die mit der von gated und C vergleichbar ist. Die neue Syntax ist komplexer; glücklicherweise wurde ein Tool bereitgestellt, mit dem die Konvertierung der alten Syntax in die neue automatisch vorgenommen wird. Im Quellpaket von BIND 8 ist ein Perl-Kommando namens named-bootconf.pl enthalten, das Ihre vorhandene named.boot von der Standardeingabe (stdin) einliest, sie in die äquivalente Syntax von named.conf konvertiert und das Resultat an die Standardausgabe (stdout) ausgibt. Um dieses Tool anwenden zu können, muß natürlich ein perl-Interpreter installiert sein. Sie sollten das Skript etwa wie folgt anwenden: # cd /etc # named-bootconf.pl named.conf

Das Skript produziert dann eine Datei named.conf, die wie in Tabelle 6.9 aussieht. Wir haben einige der ansonsten hilfreichen Kommentare entfernt, die das Skript generiert, um die direkte Verwandschaft zwischen der alten und der neuen Syntax zu verdeutlichen. Sie die Unterschiede zwischen der alten und neuen Syntax direkt vergleichen können. Beispiel 6.9: Zur named.conf äquivalente Datei im BIND-8-Format // // Datei /etc/named.boot für vlager.vbrew.com options { directory "/var/named"; }; zone "." { type hint; file "named.ca"; }; zone "vbrew.com" { type master; file "named.hosts"; }; zone "0.0.127.in-addr.arpa" { type master; file "named.local"; }; zone "16.172.in-addr.arpa" { type master; file "named.rev"; };

Wenn Sie genauer hinsehen, erkennen Sie, daß jede der einzeiligen Anweisungen von named.boot in named.conf in eine Cähnliche Anweisung konvertiert wurde, die in {}-Klammern steht. Die Kommentare, die in named.boot mit einem Semikolon (;) eingeleitet wurden, beginnen nun mit zwei Schrägstrichen (//). Die directory-Anweisung wurde in einen options-Block mit einer directory-Klausel übersetzt. Die cache- und primary-Anweisungen wurden in zone-Blöcke mit type-Klauseln vom Typ hint bzw. master konvertiert. Die Zonendateien brauchen überhaupt nicht verändert zu werden, da sich ihre Syntax nicht geändert hat. Die neue Konfigurationssyntax ermöglicht viele neue Optionen, die wir bisher noch nicht behandelt haben. Die beste Informationsquelle für diese Optionen ist die im neuen BIND-8-Quellpaket enthaltene Dokumentation.

Die Zonendateien Zu jeder Master-Datei wie named.hosts, die named bearbeitet, gehört ein Domainname, der im folgenden als Ursprung (engl. origin) bezeichnet wird. Das ist der Domainname, der beim jeweiligen primary- bzw. cache-Kommando angegeben wurde. Innerhalb einer Master-Datei können Sie Domain- und Hostnamen relativ zu dieser Domain angeben. Ein Name, der in einer Konfigurationsdatei angegeben wird, heißt absolut, wenn er auf einen Punkt endet, andernfalls ist er relativ zum Ursprung. Der Domainname @ bezieht sich auf den Ursprung selbst. Die Daten in einer Master-Datei sind in sogenannte Resource-Records (RRs) aufgeteilt. Sie stellen die kleinste durch das DNS erhältliche Informationseinheit dar. Jeder Resource-Record hat einen bestimmten Typ. Die A-Records beispielsweise bilden einen Namen auf eine Adresse ab, und ein CNAME-Record definiert einen Alias für einen anderen Domainnamen. Beispiel Tabelle 6.11 zeigt die Master-Datei named.hosts für die virtuelle Brauerei. In den Master-Dateien haben alle Resource-Records ein gemeinsames Format: [domain] [ttl] [class] type rdata

Die einzelnen Felder werden durch Leerzeichen oder Tabulatorzeichen voneinander getrennt. Manche Einträge können über mehrere Zeilen fortgesetzt werden, wenn vor dem ersten Newline-Zeichen eine öffnende Klammer steht und auf das letzte Feld eine schließende Klammer folgt.2 Alles zwischen einem Semikolon und dem Newline-Zeichen wird ignoriert. Es folgt eine Beschreibung der einzelnen Formate: domain Dies ist der Domainname, für den der Eintrag gilt. Wenn kein Name angegeben ist, bezieht sich der RR auf die Domain des vorigen RR. ttl Um andere Name-Server dazu zu veranlassen, nach einiger Zeit “gecachte” Informationen wegzuwerfen, ist für jeden

RR eine bestimmte Lebensdauer (time to live, kurz ttl) festgelegt. Das Feld ttl legt die Zeit in Sekunden fest, die der Eintrag gültig ist, nachdem er vom Server abgerufen wurde. Der Wert ist eine Dezimalzahl mit höchstens 8 Ziffern. Wenn kein ttl-Wert angegeben ist, wird der im vorhergehenden SOA-Record angegebene Minimalwert verwendet. class Dies ist eine Adreßklasse, wie IN für IP-Adressen oder HS für Objekte in der Hesiod-Klasse. Für TCP/IP-Netzwerke müssen die Einträge den Typ IN haben. Wenn keine Klasse angegeben ist, wird dafür die Klasse des vorausgehenden RR genommen. type Dies beschreibt den Typ des RR. Die häufigsten Typen sind A, SOA, PTR und NS. Im folgenden werden die verschiedenen RR-Typen im einzelnen beschrieben. rdata Dieses Feld enthält die Daten, die zum RR gehören. Das Format dieses Feldes hängt vom Typ des RR ab und wird im folgenden für jeden RR separat beschrieben. Das folgende ist eine unvollständige Liste von RRs, die in DNS-Master-Dateien benutzt werden können. Es gibt noch ein paar mehr, aber auf die gehen wir hier nicht ein. Sie sind experimentell und allgemein nicht besonders nützlich. SOA Dieser RR beschreibt eine Zone innerhalb des Verantwortungsbereiches dieses Servers (SOA bedeutet Start Of Authority). Er macht deutlich, daß die Records, die dem SOA-RR folgen, autoritative Informationen für die Domain enthalten. Jede Datei, die durch den Befehl primary eingebunden wird, muß mit einem solchen RR beginnen. Das Datenfeld enthält die folgenden Felder: origin Dies ist der kanonische Hostname des primären Name-Servers der Domain. Er wird üblicherweise als absoluter Name angegeben. contact Dies ist die E-Mail-Adresse der Person, die für diese Zone verantwortlich ist, wobei das Zeichen @ durch einen Punkt ersetzt wurde. Wenn beispielsweise janet die verantwortliche Person in der virtuellen Brauerei ist, enthält dieses Feld janet.vbrew.com. serial Dies ist die Versionsnummer der Zonendatei, geschrieben als eine einzige Dezimalzahl. Jedesmal, wenn Daten in der Zone verändert werden, sollte diese Zahl inkrementiert werden. Es ist allgemein üblich, eine Zahl zu benutzen, die das Datum der letzten Änderung mit einer daran angehängten Versionsnummer enthält; auf diese Weise werden auch mehrere Änderungen pro Tag erfaßt. Zum Beispiel weist die Zahl 2000012601 auf Update 01 am 26. Januar 2000 hin. Die Seriennummer wird von den sekundären Name-Servern verwendet, um festzustellen, ob sich die Zonendaten verändert haben. Um auf dem laufenden zu bleiben, fordern die sekundären Server den SOARecord des primären Servers in bestimmten Zeitabständen an und vergleichen die Versionsnummer mit der des “gecachten” SOA-Records. Wenn sich die Zahl verändert hat, laden sie die gesamten Zonendaten vom primären

Server neu. refresh Dies gibt die Zeit in Sekunden an, die ein sekundärer Server warten soll, bevor er den SOA-Record des primären Servers wieder überprüft. Dies ist wieder eine Dezimalzahl mit bis zu 8 Stellen. Normalerweise ändert sich die Netztopologie nicht allzu häufig, weshalb diese Zahl im Falle größerer Domains ungefähr einem Tag entsprechen sollte, bei kleineren möglicherweise auch mehr. retry Dieser Wert legt die Zeitabstände fest, in denen ein sekundärer Server versuchen soll, den primären Server zu erreichen, wenn eine Anfrage oder eine Aktualisierung der Zonendaten fehlschlägt. Der Wert sollte nicht zu klein gewählt werden, da sonst eine vorübergehende Störung des Servers oder ein Netzproblem dazu führen können, daß der sekundäre Server unnötig Netzressourcen verbraucht. Eine oder eine halbe Stunde dürften eine gute Wahl sein. expire Dieser Wert gibt die Zeit in Sekunden an, nach denen ein sekundärer Server schließlich alle Zonendaten wegwerfen sollte, falls es ihm in dieser Zeit nicht gelingt, den primären Server zu erreichen. Sie sollten diesen Wert normalerweise auf mindestens eine Woche setzen (d.h. 604.800 Sekunden), aber auch ein Monat kann durchaus sinnvoll sein. minimum Dies ist der ttl-Wert, der als Voreinstellung für RRs gewählt wird, die nicht ausdrücklich einen solchen Wert angeben. Der ttl-Wert gibt die maximale Zeit an, für die andere Name-Server einen RR in ihrem Cache halten dürfen. Dieser Wert betrifft nur gewöhnliche DNS-Abfragen und hat nichts mit der Zeit zu tun, nach der ein sekundärer Server versuchen sollte, die Zoneninformationen zu aktualisieren. Wenn sich die Topologie Ihres Netzes nicht allzu häufig ändert, dürfte eine Woche oder mehr ein guter Wert sein. Wenn sich einzelne RRs häufiger ändern, können Sie diesen jeweils kleinere TTLs individuell zuordnen. Wenn sich der Aufbau Ihres Netzes allerdings häufiger ändert, können Sie diesen Wert auch auf einen Tag (86.400 Sekunden) setzen. A Dieser Record-Typ ordnet einem Hostnamen eine Adresse zu. Das Datenfeld enthält die Adresse in Dotted Quad Notation. Für jeden Hostnamen darf es immer nur einen A-Record geben. Der in diesem RR benutzte Hostname ist der offizielle oder kanonische Hostname. Alle anderen Namen sind Aliase und müssen mittels eines CNAME-Records auf den kanonischen Hostnamen abgebildet werden. Wenn der kanonische Name unseres Hosts vlager lautete, hätten wir einen A-Record, der diesen Hostnamen mit seiner IP-Adresse assoziiert. Angenommen, wir wollten einen zweiten Namen mit dieser IP-Adresse haben, sagen wir mal news. Dann müßten wir einen CNAME-Record erzeugen, der diesen alternativen Namen mit dem kanonischen Namen assoziiert. Über CNAME-Records reden wir noch in Kürze. NS NS-Records dienen dazu, den primären und alle sekundären Name-Server einer Zone anzugeben. Ein NS-Record zeigt auf einen Master-Name-Server der angegebenen Zone; das Resource-Datenfeld enthält den Hostnamen des Servers. Sie werden NS-Records in zwei Situationen begegnen. Sie werden einmal benutzt, wenn Autorität an eine untergeordnete Zone delegiert wird, andererseits tauchen sie in den Master-Zonendateien der untergeordneten Zone

selbst auf. Die Listen der Server, die jeweils in der delegierenden und delegierten Zone aufgeführt werden, sollten übereinstimmen. Der NS-Record legt den Namen des primären Name-Servers sowie die Namen der sekundären Name-Server einer Zone fest. Diese Namen müssen zu einer IP-Adresse aufgelöst werden, um benutzt werden zu können. Manchmal gehören die Server aber zu der Domain, die sie selbst bedienen, was einem “Henne und Ei”-Problem gleichkommt. Wir können die Adressen nicht auflösen, bevor der Name-Server erreichbar ist, und wir können auch nicht den Name-Server erreichen, bevor wir seine Adresse kennen. Um uns aus diesem Dilemma zu befreien, können wir direkt in den NameServer der übergeordneten Zone spezielle A-Records eintragen, die es den Name-Servern der übergeordneten Zone ermöglichen, die IP-Adressen der Name-Server der delegierten Zone zu ermitteln. Diese Records werden für gewöhnlich Glue Records (glue = Leim) genannt, da sie gewissermaßen als “Kleber” die delegierte Zone an ihre übergeordnete Zone binden. CNAME Dieser Record-Typ ordnet einem Alias für einen Host dessen kanonischen Hostnamen zu. Er stellt einen alternativen Namen zur Verfügung, mit dem sich die Anwender an den Host wenden können, dessen kanonischer Name als Parameter angegeben ist. Der kanonische Hostname ist derjenige, für den die Zonendatei einen A-Record enthält. Aliase verweisen über einen CNAME auf diesen Hostnamen und besitzen keine weiteren RRs. PTR Dieser Record wird verwendet, um Namen in der Domain in-addr.arpa (die IP-Adressen repräsentieren) auf den zugehörigen kanonischen Hostnamen abzubilden. Das Datenfeld dieses RR enthält den kanonischen Hostnamen. MX Dieser RR legt einen sogenannten Mail Exchanger für die angegebene Domain fest. Mail Exchanger werden ausführlich in Mail-Routing im Internet beschrieben. Die Syntax eines MX-Records sieht so aus: [domain] [ttl] [class] MX preference host

Das weist host als Mail Exchanger für domain aus. Jedem Exchanger ist eine ganzzahlige Präferenz zugeordnet. Ein Mail-Transportprogramm, das eine Nachricht an domain ausliefern möchte, probiert alle Hosts, die einen MX-Record für diese Domain haben, der Reihe nach durch, bis es die Mail erfolgreich übertragen kann. Dabei beginnt es bei dem Mail Exchanger (MX) mit der niedrigsten Präferenz und arbeitet die Liste in aufsteigender Reihenfolge ab. HINFO Dieser Record enthält Informationen über die Hard- und Software des Systems. Seine Syntax ist: [domain] [ttl] [class] HINFO hardware software

Das hardware-Feld beschreibt die Hardware, auf der das System läuft, in einem bestimmten Format. Der RFC Assigned Numbers (RFC-1700) enthält eine Liste gültiger “Maschinennamen”, die Sie in diesem Feld eintragen können. Wenn das Feld Leerzeichen enthält, muß es in doppelte Anführungszeichen gesetzt werden. Das Feld software bezeichnet das Betriebssystem des Hosts. Auch hier sollten gültige Namen aus RFC-1700 gewählt werden. Ein HINFO-Record zur Beschreibung einer Intel-basierten Linux-Maschine hat etwa die Form: tao

36500

IN

HINFO

IBM-PC

LINUX2.2

HINFO-Records für Linux auf Motorola 68000-basierten Maschinen sollten etwa wie folgt aussehen: cevad 36500 IN

HINFO

ATARI-104ST LINUX2.0 jedd

36500 IN

HINFO

AMIGA-3000

LINUX2.0

Caching-Only-Konfigurationen für named Bevor wir uns auf die Konfiguration eines vollständigen Name-Servers stürzen, sollten wir kurz noch über eine ganz besondere named-Konfiguration sprechen: die Caching-only-Konfiguration. Eine solche Konfiguration stellt keinen DomainDienst an sich dar, sondern dient als Relais für alle DNS-Anfragen, die auf Ihrem Host produziert werden. Der Vorteil dieses Schemas liegt darin, daß damit ein Cache aufgebaut wird, so daß nur noch die erste Anfrage nach einem bestimmten Host tatsächlich zum Name-Server im Internet gesendet wird. Jede nachfolgende gleichlautende Anfrage wird dann direkt aus dem Cache Ihres lokalen Name-Servers heraus beantwortet. Das mag vielleich jetzt noch nicht besonders nützlich sein, macht sich aber beim Einwählen ins Internet bezahlt, wie es in Kapitel 7 Serial Line IP, und Kapitel 8 Das Point-to-Point-Protokoll, beschrieben wird. Eine named.boot-Datei für einen Caching-only-Server sieht etwa folgendermaßen aus: ; named.boot-Datei für Caching-only-Server directory 0.0.127.in-addr.arpa named.local ; localhost network cache named.ca ; root servers

/var/named primary .

Zusätzlich zu dieser named.boot-Datei müssen Sie auch die Datei named.ca mit einer gültigen Liste von Root-Name-Servern ausstatten. Zu diesem Zweck können Sie eine Kopie von Tabelle 6.10 benutzen. Es werden keine weiteren Dateien zur Konfiguration eines Caching-only-Servers benötigt.

Die Master-Dateien Tabelle 6.10, Tabelle 6.11, Tabelle 6.12 und Tabelle 6.13 enthalten Beispieldateien für den Name-Server der virtuellen Brauerei, der auf vlager läuft. Da wir hier nur ein relativ einfaches LAN betrachten, ist das Beispiel nicht allzu kompliziert. Die Datei named.ca in Beispiel Tabelle 6.10 zeigt, wie die Hints für einen Root-Name-Server aussehen könnten. Eine typische Cache-Datei enthält normalerweise ein rundes Dutzend Name-Server. Um eine aktuelle Liste der Name-Server zu bekommen, können Sie das Programm nslookup verwenden, das im nächsten Abschnitt beschrieben wird.3 Beispiel 6.10: Die Datei named.ca ; ; /var/named/named.ca Cache-Datei der virtuellen Brauerei. ; Wir sind nicht im Internet und brauchen daher ; keine Root-Server. Um diese Records zu aktivieren, sind ; die Semikolons zu entfernen. ; ;. 3600000 IN NS A.ROOT-SERVERS.NET. ;A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ;. 3600000 NS B.ROOT-SERVERS.NET. ;B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107 ;. 3600000 NS C.ROOT-SERVERS.NET. ;C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12 ;. 3600000 NS D.ROOT-SERVERS.NET. ;D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90 ;. 3600000 NS E.ROOT-SERVERS.NET. ;E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10 ;. 3600000 NS F.ROOT-SERVERS.NET. ;F.ROOT-SERVERS.NET. 3600000 A 192.5.5.241 ;. 3600000 NS G.ROOT-SERVERS.NET. ;G.ROOTSERVERS.NET. 3600000 A 192.112.36.4 ;. 3600000 NS H.ROOT-SERVERS.NET. ;H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53 ;. 3600000 NS I.ROOT-SERVERS.NET. ;I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17 ;. 3600000 NS J.ROOT-SERVERS.NET. ;J.ROOT-SERVERS.NET. 3600000 A 198.41.0.10 ;. 3600000 NS K.ROOT-SERVERS.NET. ;K.ROOTSERVERS.NET. 3600000 A 193.0.14.129 ;. 3600000 NS L.ROOT-SERVERS.NET. ;L.ROOT-SERVERS.NET. 3600000 A 198.32.64.12 ;. 3600000 NS M.ROOT-SERVERS.NET. ;M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 ;

Beispiel 6.11: Die Datei named.hosts ; ; /var/named/named.hosts Lokale Hosts in der virtuellen Brauerei ; Ursprung ist vbrew.com ; @ IN SOA vlager.vbrew.com. janet.vbrew.com. ( 2000012601 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; ; lokale Mail wird in vlager verteilt IN MX 10 vlager ; ;

Loopback-Adresse localhost. IN A 127.0.0.1 ; ; Ethernet der virtuellen Brauerei vlager IN A 172.16.1.1 vlager-if1 IN CNAME vlager ; vlager ist auch News-Server news IN CNAME vlager vstout IN A 172.16.1.2 vale IN A 172.16.1.3 ; ; Ethernet der virtuellen Weinkellerei vlager-if2 IN A 172.16.2.1 vbardolino IN A 172.16.2.2 vchianti IN A 172.16.2.3 vbeaujolais IN A 172.16.2.4 ; ; Ethernet der Tochtergesellschaft Virtuelle Spirituosen vbourbon IN A 172.16.3.1 vbourbon-if1 IN CNAME vbourbon

Beispiel 6.12: Die Datei named.local ; ; /var/named/named.local Reverse Mapping von 127.0.0 ; Ursprung ist 0.0.127.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 1 ; serial 360000 ; refresh: 100 hrs 3600 ; retry: one hour 3600000 ; expire: 42 days 360000 ; minimum: 100 hrs ) IN NS vlager.vbrew.com. 1 IN PTR localhost.

Beispiel 6.13: Die Datei named.rev ; ; /var/named/named.rev Reverse Mapping unserer IP-Adressen ; Ursprung ist 16.172.in-addr.arpa. ; @ IN SOA vlager.vbrew.com. joe.vbrew.com. ( 16 ; serial 86400 ; refresh: once per day 3600 ; retry: one hour 3600000 ; expire: 42 days 604800 ; minimum: 1 week ) IN NS vlager.vbrew.com. ; Brauerei 1.1 IN PTR vlager.vbrew.com. 2.1 IN PTR vstout.vbrew.com. 3.1 IN PTR vale.vbrew.com. ; Weinkellerei 1.2 IN PTR vlager-if2.vbrew.com. 2.2 IN PTR vbardolino.vbrew.com. 3.2 IN PTR vchianti.vbrew.com. 4.2 IN PTR vbeaujolais.vbrew.com.

Test Ihrer DNS-Konfiguration nslookup ist ein großartiges Tool zum Funktionstest Ihrer Name-Server-Konfiguration. Es kann sowohl interaktiv als auch als einfaches Kommando verwendet werden. Als Kommando rufen Sie es wie folgt auf: $ nslookup hostname

nslookup befragt dann den in resolv.conf angegebenen Name-Server nach hostname. (Wenn Sie in dieser Datei mehr als einen Server angegeben haben, wählt nslookup einen davon zufällig aus.) Der interaktive Modus ist allerdings wesentlich spannender. Sie können in diesem Modus nicht nur einzelne Hostnamen auflösen, sondern nach beliebigen DNS-Records suchen und die gesamte Zoneninformation einer Domain auflisten. Wenn Sie es ohne Argumente aufrufen, gibt nslookup den Namen des verwendeten Name-Servers aus und geht in den interaktiven Modus. Hinter dem Prompt > können Sie nun beliebige Domainnamen angeben. Per Voreinstellung fragt nslookup nach A-Records, die die zum Domainnamen gehörende IP-Adresse enthalten. Sie können sich bestimmte Record-Typen mit > set type=type

ansehen, wobei type einer der oben beschriebenen Record-Typen oder der String ANY ist. Ein Dialog mit nslookup könnte beispielsweise so aussehen: $ nslookup Default Server: tao.linux.org.au Address: 203.41.101.121 > metalab.unc.edu Server: tao.linux.org.au Address: 203.41.101.121 Name: metalab.unc.edu Address: 152.2.254.81 >

In der Ausgabe erscheint zunächst der befragte DNS-Server und danach das Ergebnis der Anfrage.

Wenn Sie einen Namen angeben, zu dem es keine A-Records gibt, aber andere Record-Typen gefunden wurden, gibt nslookup die Fehlermeldung No type A records found zurück. Mit dem Kommando set type können Sie es aber dazu bringen, auch andere Typen als A anzuzeigen. Um beispielsweise den SOA-Record für unc.edu zu bekommen, würden Sie etwa folgendes eingeben: > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 *** No address (A) records available for unc.edu > set type=SOA > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu origin = ns.unc.edu mail addr = host-reg.ns.unc.edu serial = 1998111011 refresh = 14400 (4H) retry = 3600 (1H) expire = 1209600 (2W) minimum ttl = 86400 (1D) unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net unc.edu name server = ns.unc.edu ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1 ns.unc.edu internet address = 152.2.21.1

Ganz ähnlich geht es, wenn Sie nach MX-Records fragen wollen: > set type=MX > unc.edu Server: tao.linux.org.au Address: 203.41.101.121 unc.edu preference = 0, mail exchanger = conga.oit.unc.edu unc.edu preference = 10, mail exchanger = imsety.oit.unc.edu unc.edu name server = ns.unc.edu unc.edu name server = ns2.unc.edu unc.edu name server = ncnoc.ncren.net conga.oit.unc.edu internet address = 152.2.22.21 imsety.oit.unc.edu internet address = 152.2.21.99 ns.unc.edu internet address = 152.2.21.1 ns2.unc.edu internet address = 152.2.253.100 ncnoc.ncren.net internet address = 192.101.21.1 ncnoc.ncren.net internet address = 128.109.193.1

Wenn Sie den Suchtyp auf ANY setzen, gibt nslookup alle Resource-Records aus, die zu dem angegebenen Namen gehören. Außer für das Debugging Ihrer Konfiguration können Sie nslookup aber auch noch verwenden, um die aktuelle Liste der RootName-Server zu erhalten. Sie können das tun, indem Sie nach allen NS-Records fragen, die für die Root-Domain definiert sind: > set type=NS > . Server: tao.linux.org.au Address: 203.41.101.121 Non-authoritative answer: (root) name server = A.ROOT-SERVERS.NET (root) name server = H.ROOT-SERVERS.NET (root) name server = B.ROOT-SERVERS.NET (root) name server = C.ROOT-SERVERS.NET (root) name server = D.ROOTSERVERS.NET (root) name server = E.ROOT-SERVERS.NET (root) name server = I.ROOT-SERVERS.NET (root) name server = F.ROOT-SERVERS.NET (root) name server = G.ROOT-SERVERS.NET (root) name server = J.ROOT-SERVERS.NET (root) name server = K.ROOT-SERVERS.NET (root) name server = L.ROOTSERVERS.NET (root) name server = M.ROOT-SERVERS.NET Authoritative answers can be found from: A.ROOT-SERVERS.NET internet address = 198.41.0.4 H.ROOT-SERVERS.NET internet address = 128.63.2.53 B.ROOT-SERVERS.NET internet address = 128.9.0.107 C.ROOT-SERVERS.NET internet address = 192.33.4.12 D.ROOT-SERVERS.NET internet address = 128.8.10.90 E.ROOT-SERVERS.NET internet address = 192.203.230.10 I.ROOT-SERVERS.NET internet address = 192.36.148.17 F.ROOTSERVERS.NET internet address = 192.5.5.241 G.ROOT-SERVERS.NET internet address = 192.112.36.4 J.ROOT-SERVERS.NET internet address = 198.41.0.10 K.ROOT-SERVERS.NET internet address = 193.0.14.129 L.ROOT-SERVERS.NET internet address = 198.32.64.12 M.ROOTSERVERS.NET internet address = 202.12.27.33

Um eine Übersicht über alle Befehle zu bekommen, die nslookup bietet, geben Sie am Prompt den Befehl help ein. Mit Strg-D verlassen Sie das Programm.

Andere nützliche Dinge Schließlich gibt es noch einige andere nützliche Tools, die Ihnen das Leben als BIND-Administrator leichter machen. Wir beschreiben hier zwei von ihnen ganz kurz. Wenn Sie wissen wollen, wie diese Programme bedient werden, lesen Sie bitte die Dokumentation, die den Tools beiliegt. hostcvt ist ein Programm, das Ihnen bei Ihrer anfänglichen BIND-Konfiguration behilflich ist, indem es Ihre hosts-Datei in Master-Dateien für named umsetzt. Es erzeugt sowohl A-Records (zur Vorwärtsauflösung) als auch PTR-Records (für Reverse Mapping) und achtet auf Aliase und ähnliches. Natürlich kann es Ihnen nicht alles abnehmen, zumal Sie vielleicht noch einige der Voreinstellungen im SOA-Record anpassen oder MX-Records eintragen wollen. Trotzdem ersparen Sie sich mit diesem Werkzeug einiges an Kopfschmerzen. hostcvt ist Teil der BIND-Distribution, ist aber auch als einzelnes Paket auf einigen

Linux-FTP-Servern zu finden. Nachdem Sie Ihren Name-Server aufgesetzt haben, werden Sie wahrscheinlich Ihre Konfiguration auf Herz und Nieren überprüfen wollen. Dafür stehen Ihnen einige gute Tools zur Verfügung. Dazu gehören dnswalk, ein Perl-basiertes Paket, sowie nslint. Beide durchwandern Ihre DNS-Daten, suchen nach häufigen Fehlern und stellen sicher, daß die Informationen konsistent sind. Zwei weitere nützliche Tools sind host und dig, beides universell verwendbare Abfrage-Tools für DNS-Daten. Damit können Sie die DNS-Datenbankeinträge manuell inspizieren und diagnostizieren. Diese Tools erhält man üblicherweise in Form vorgefertigter Softwarepakete. dnswalk und nslint sind im Quellcode erhältlich von http://www.visi.com/~barr/dnswalk/ und ftp://ftp.ee.lbl.gov/nslint.tar.Z. Der Quellcode von host und dig kann von ftp://ftp.nikhef.nl/pub/network/ und ftp://ftp.is.co.za/networking/ip/dns/dig/ heruntergeladen werden.

1.

BIND 4.9 wurde von Paul Vixie ([email protected]) entwickelt. Jetzt ist das Internet Software Consortium ([email protected]) für die Weiterentwicklung von BIND zuständig.

2.

Obwohl die Dokumentation besagt, daß dies für alle Records gilt, scheint dies nur beim SOA-Record der Fall zu sein und auch hier nur nach einem bestimmten Eintrag.

3.

Wie haben es hier wieder mit einem Henne-und-Ei-Problem zu tun: Sie können Ihren Name-Server nicht nach den RootServern fragen, wenn Sie ihm noch keine mitgeteilt haben. Um aus diesem Dilemma herauszukommen, müssen Sie entweder nslookup dazu bewegen, einen anderen Name-Server zu verwenden, oder Sie können die Daten aus Tabelle 6.10 als Ausgangspunkt nehmen und damit die ganze Liste der Root-Server erfragen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 7 Serial Line IP

Netzwerkprotokolle wie IP oder IPX verlassen sich darauf, daß der empfangende Hostrechner weiß, wo sich der Anfang und das Ende jedes IP-Pakets im Datenstrom befinden. Das Verfahren zur Kennzeichnung und Erkennung von Anfang und Ende von Paketen wird als Abgrenzung (delimitation) bezeichnet. Das Ethernet-Protokoll verwaltet diesen Mechanismus in lokalen Netzwerken, während die Protokolle SLIP und PPP dieses für serielle Verbindungen erledigen. Die vergleichsweise niedrigen Preise für langsame Modems haben zu einer enormen Verbreitung der

Protokolle beigetragen, die über serielle Verbindungen genutzt werden, besonders, um damit Anwendern den Zugang zum Internet zu ermöglichen. Die für SLIP oder PPP notwendige Hardware ist relativ einfach gestaltet und zudem leicht erhältlich. Alles, was man dafür benötigt, ist ein Modem und ein serieller Port mit einem FIFO-Buffer. Das SLIP-Protokoll läßt sich sehr leicht implementieren und war einige Zeit weiter verbreitet als PPP. Heutzutage verwendet fast jeder das PPP-Protokoll. Es zeichnet sich durch diverse zusätzliche Features aus, die zu seiner heutigen Dominanz beigetragen haben und auf die wir später noch näher eingehen werden. Für Linux stehen sowohl SLIP- als auch PPP-Treiber zur Verfügung. Beide sind schon seit langem verfügbar und stabil und zuverlässig. In diesem und im nächsten Kapitel besprechen wir beide Protokolle und wie sie konfiguriert werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Allgemeine Anforderungen Um SLIP oder PPP zu verwenden, müssen Sie einige grundlegende Netzwerkfunktionen installieren, die wir in den vorherigen Kapiteln besprochen haben. Als Minimum ist das Loopback-Interface einzurichten und die Auflösung von Namen zu ermöglichen. Wenn Sie sich an das Internet anbinden wollen, werden Sie natürlich auch DNS verwenden wollen. Die einfachste Möglichkeit besteht darin, die Adresse des Name-Servers Ihres Providers in Ihre resolv.conf-Datei einzutragen. Alternativ dazu können Sie einen Caching-only-Name-Server konfigurieren, wie in Abschnitt Caching-OnlyKonfigurationen für named in Kapitel 6 Name-Server- und Resolver-Konfiguration, beschrieben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

SLIP-Betrieb Dialup-IP-Server bieten SLIP häufig über spezielle Benutzer-Accounts an. Nach dem Einloggen in einen solchen Account landen Sie nicht in der üblichen Shell, sondern es wird ein Programm oder Shell-Skript ausgeführt, das den SLIP-Treiber des Servers für die serielle Leitung konfiguriert und ein entsprechendes Netzwerk-Interface aufbaut. Dasselbe muß danach an Ihrem Ende der Leitung passieren. Bei manchen Betriebssystemen ist der SLIP-Treiber ein normales Anwenderprogramm; bei Linux dagegen ist er Teil des Kernel und ist dadurch erheblich schneller. Das verlangt allerdings, daß die serielle Leitung explizit auf den SLIP-Modus umgestellt wird. Dieser Betriebsmodus ist als eine spezielle line discipline, SLIPDISC, implementiert. Wenn das TTY sich im Normalmodus (DISC0) befindet, tauscht es Daten nur mit Benutzerprozessen über die Systemaufrufe read(2) und write(2) aus, und der SLIP-Treiber ist nicht in der Lage, von diesem tty zu lesen oder darauf zu schreiben. Bei SLIPDISC sind die Rollen vertauscht: Nun werden alle Schreib- und Lesezugriffe von Benutzerprozessen blockiert, während alle über die serielle Schnittstelle eintreffenden Daten direkt an den SLIP-Treiber weitergeleitet werden. Der SLIP-Treiber versteht verschiedene Varianten des SLIP-Protokolls. Neben dem normalen SLIP versteht er auch CSLIP, das die sogenannte Van-Jacobson-Header-Komprimierung (beschrieben in RFC-1144) von ausgehenden IP-Paketen implementiert. Das verbessert den Durchsatz bei interaktiven Anwendungen merklich. Darüber hinaus gibt es 6-BitVersionen dieser Protokolle. Einen einfachen Weg zur Umstellung einer seriellen Leitung auf den SLIP-Modus bietet das slattach-Tool. Nehmen wir einmal an, Sie hätten Ihr Modem an /dev/ttyS3 angeschlossen und sich erfolgreich in den SLIP-Server eingeloggt. Nun führen Sie den folgenden Befehl aus: # slattach /dev/ttyS3 &

Das schaltet den Betriebsmodus von ttyS3 auf SLIPDISC und verbindet diese mit einer der SLIP-Netzwerkschnittstellen. Ist dies Ihr erster aktiver SLIP-Link, wird die Leitung an sl0 gebunden; die zweite an sl1 und so weiter. Die aktuellen Kernel unterstützen standardmäßig bis zu 256 simultane SLIP-Verbindungen. Per Voreinstellung verwendet slattach CSLIP. Sie können einen anderen Modus mit der Kommandozeilenoption –p einstellen. Wenn Sie mit normalem SLIP (ohne Komprimierung) arbeiten wollten, würden Sie folgendes eingeben:

# slattach -p slip /dev/ttyS3 &

Die verfügbaren Betriebsmodi sind in Tabelle 7.1 aufgelistet. Es gibt auch eine spezielle Pseudo-Betriebsart, die als adaptiv bezeichnet wird. Diese Variante überläßt es dem Kernel, herauszufinden, welchen SLIP-Modus das Gegenüber verwendet. Tabelle 7.1: Linux-Slip-Line-Betriebsmodi Betriebsmodus

slip cslip

slip6

cslip6

adaptive

Erläuterung Traditionelles SLIP. SLIP-Variante mit Van-Jacobsen-Header-Komprimierung. SLIP-Variante mit 6-Bit-Codierung. Die Codierung ähnelt der des uuencode-Befehls und bewirkt, daß SLIP-Datagramme in druckbare ASCII-Zeichen konvertiert werden. Das bietet sich für Leitungen an, die für 8-Bit-Übertragungen nicht ausgelegt sind. SLIP-Variante mit Van-Jacobsen-Header-Komprimierung und 6-Bit-Codierung. Hierbei handelt es sich um keine echte Variante. Diese Line Discipline weist lediglich den Kernel an, den Betriebsmodus von Remote-Rechnern selbst herauszufinden und den SLIP-Betrieb entsprechend anzugleichen.

Beachten Sie, daß Sie immer dieselbe Variante verwenden müssen wie Ihre Gegenstelle. Wenn beispielsweise der Host cowslip CSLIP verwendet, müssen Sie dies auch tun. Wenn Ihre SLIP-Verbindung nicht funktioniert, sollten Sie als erstes sicherstellen, daß beide Enden der Leitung sich darüber einig sind, ob Header-Komprimierung benutzt wird oder nicht. Wenn Sie sich über die Konfiguration der Gegenstelle nicht im klaren sind, konfigurieren Sie Ihren Host auf adaptives SLIP. Der Kernel sollte dann den richtigen Betriebsmodus selbst herausfinden. Mit slattach können Sie nicht nur SLIP, sondern auch andere Protokolle wie PPP oder KISS (ein von Amateurfunkern verwendetes Protokoll) aktivieren, die serielle Leitungen verwenden. Das kommt allerdings nicht so häufig vor, und es gibt bessere Tools zur Unterstützung dieser Protokolle. Details können Sie der slattach(8)-Manpage entnehmen. Nachdem die Leitung nun für den SLIP-Treiber bereitsteht, müssen Sie das Netzwerk-Interface konfigurieren. Dies erledigen Sie wieder mit den Standardbefehlen ifconfig und route. Nehmen wir einmal an, daß Sie von vlager aus einen Server namens cowslip angewählt haben. Sie würden dann auf vlager die folgenden Befehle eingeben: # ifconfig sl0 vlager-slip pointopoint cowslip # route add cowslip # route add default gw cowslip

Der erste Befehl konfiguriert das Interface als Point-to-Point-Link zu cowslip, während der zweite und dritte die Route zu cowslip und die Default-Route setzen, wobei cowslip als Gateway verwendet wird. An diesem ifconfig-Aufruf sind zwei Dinge interessant. Das erste ist die Option pointopoint, mit der die Adresse des anderen Endes der Punkt-zu-Punkt-Verbindung festgelegt wird. Das zweite ist die Verwendung von vlager-slip als Adresse für das lokale SLIP-Interface. Wir haben bereits vorher erwähnt, daß Sie dieselbe Adresse, die dem Ethernet-Interface von vlager zugewiesen wurde, auch für Ihren SLIP-Link verwenden können. In diesem Fall könnte vlager-slip ein weiterer Alias für die Adresse 172.16.1.1 sein. Andererseits kann es vorkommen, daß Sie Ihrem SLIP-Link eine völlig andere IP-Adresse zuweisen müssen. Das ist beispielsweise der Fall, wenn Sie Ihrem Netzwerk eine nicht registrierte IP-Adresse zugewiesen haben, wie im Beispiel der

virtuellen Brauerei. Wir kommen auf dieses Thema im nächsten Abschnitt ausführlicher zurück. Für den Rest dieses Kapitels werden wir immer vlager-slip verwenden, wenn wir uns auf die Adresse des lokalen SLIPInterfaces beziehen. Um den SLIP-Link herunterzufahren, sollten Sie zunächst alle Routen durch cowslip entfernen. Dazu führen Sie den Befehl route mit der Option del aus. Danach sollten Sie das Interface herunterfahren und den slattach-Prozeß beenden, indem Sie ihm das Hangup-Signal schicken. Danach veranlassen Sie Ihr Modem mit Hilfe des Terminal-Programms aufzulegen. # route del default # route del cowslip # ifconfig sl0 down # kill -HUP 516

Die 516 müssen Sie natürlich durch die richtige Prozeß-ID ersetzen, wie sie in der Ausgabe von ps ax in der Zeile mit dem slattach-Kommando angezeigt wird, das Sie gerade zur Steuerung der SLIP-Schnittstelle verwenden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Handhabung privater IP-Netzwerke Sie werden sich aus dem Kapitel 5 TCP/IP-Konfiguration, daran erinnern, daß die virtuelle Brauerei nichtregistrierte Netzwerknummern verwendet, die nur für den internen Gebrauch reserviert sind. Pakete von oder zu einem dieser Netzwerke werden im Internet nicht geroutet. Wenn wir vlager in cowslip einwählen lassen und als Router des Brauerei-Netzes arbeiten lassen würden, könnten die Hosts innerhalb des Brauerei-Netzwerks nicht mit echten Internet-Hosts kommunizieren, weil die entsprechenden Pakete vom ersten größeren Router still und leise aussortiert würden. Um dieses Problem zu umgehen, konfigurieren wir vlager so, daß er als eine Art Sprungbrett für Internetdienste agiert. Der restlichen Welt stellt er sich als normaler Internet-Host mit SLIPVerbindung und einer (üblicherweise von einem mit cowslip arbeitenden Netzwerk-Provider zugewiesenen) registrierten Internetadresse dar. Jeder Benutzer, der auf vlager eingeloggt ist, kann textbasierte Internet-Programme wie ftp, telnet oder sogar den Web-Browser lynx verwenden. Jeder im Netz der virtuellen Brauerei kann sich dazu über telnet auf vlager einloggen und die dort verfügbaren Programme für seine Zwecke einsetzen. Für einige Anwendungen existieren Lösungen, die verhindern, daß sich jeder einloggen können muß. Für WWW-User können wir dafür einen sogenannten Proxy-Server auf vlager einsetzen, der alle Anfragen der Benutzer an die jeweiligen Server verteilt. Sich auf vlager einloggen zu müssen, um das Internet benutzen zu können, ist etwas umständlich.

Aber neben der ganzen Schreibarbeit (und den Kosten), die Sie sich sparen, weil Sie keine IPAdressen registrieren müssen, hat dieses Vorgehen noch den zusätzlichen Vorteil, daß es sich ausgezeichnet in ein Firewall-Konzept einpaßt. Firewalls sind besondere Hosts, die verwendet werden, um Benutzern Ihres lokalen Netzwerks eingeschränkten Zugang zum Internet zu verschaffen, ohne die internen Hosts eventuellen Netzwerkattacken von außen auszusetzen. Eine einfache FirewallKonfiguration wird in Kapitel 9 TCP/IP-Firewall, näher beschrieben. In Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen, behandeln wir ein Linux-Feature namens IPMasquerading, das eine mächtige Alternative zu Proxyservern darstellt. Stellen Sie sich vor, der Brauerei wurde die IP-Adresse 192.168.5.74 für den SLIP-Link zugewiesen. Alles, was Sie nun tun müssen, um die oben erläuterte Konfiguration zu realisieren, ist, diese Adresse in die Datei /etc/hosts einzutragen und sie vlager-slip zu nennen. Der Vorgang, wie die SLIPVerbindung aufgebaut wird, bleibt dabei unverändert.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verwendung von dip Nun, das war ja alles ziemlich einfach. Nichtsdestotrotz wollen Sie wahrscheinlich die obigen Schritte so automatisieren, daß Sie nur einen einzigen Befehl eingeben müssen, der dann all die oben aufgeführten Befehle durchführt, wie die Einwahl in den Provider, das Einloggen, die Einstellung des richtigen SLIP-Betriebsmodus sowie die Konfiguration der Netzwerkschnittstelle. Genau das erledigt dip. dip steht für Dialup IP. Es wurde von Fred van Kempen geschrieben und von einer Vielzahl von Leuten “gepatcht”. Heute wird zumeist nur noch eine bestimmte Version benutzt: dip337p-uri, das in den meisten Linux-Distributionen enthalten ist und vom FTP-Archiv auf metalab.unc.edu heruntergeladen werden kann. dip bietet einen Interpreter für eine einfache Skriptsprache, mit der Sie Ihr Modem steuern, Leitungen in den SLIP-Modus schalten und die Schnittstellen konfigurieren können. Die Skriptsprache ist mächtig genug, um für die meisten Anwendungsfälle auszureichen. Um das SLIP-Interface konfigurieren zu können, benötigt dip Root-Privilegien. Es wäre nun sehr verlockend, das setuid-Bit von dip zu setzen, so daß alle Benutzer einen SLIP-Server anwählen können, ohne Root-Rechte zu besitzen. Das ist aber sehr gefährlich, weil die fehlerhafte Einrichtung von Interfaces und Default-Routen mit dip das Routing auf Ihrem Netzwerk zum Erliegen bringen könnte. Noch schlimmer ist aber die Tatsache, daß Sie Ihren Benutzern auf diese Weise die Möglichkeit geben, Verbindungen zu jedem SLIP-Server aufzubauen, und so gefährliche Angriffe auf Ihr Netzwerk provozieren könnten. Wenn Sie es Ihren Benutzern also erlauben wollen, SLIP-Verbindungen aufzubauen, sollten Sie kleine Programme für jeden vorgesehenen SLIP-Server schreiben, die dip dann mit dem entsprechenden Skript aufrufen, das die Verbindung sauber aufbaut. Sorgfältig geschriebene Programme können dann bedenkenlos mit Setuid auf root gesetzt werden.1 Eine alternative und flexiblere Möglichkeit, vertrauenswürdigen Benutzern Root-Rechte für dip zu gewähren, besteht in der Anwendung von Programmen wie beispielsweise sudo.

Ein Beispielskript Nehmen wir an, daß cowslip der Host ist, zu dem Sie die SLIP-Verbindung aufbauen wollen, und daß Sie für dip ein Skript namens cowslip.dip geschrieben haben, das die Verbindung herstellt. Wir starten dip und übergeben den Skriptnamen als Argument: # dip cowslip.dip DIP: Dialup IP Protocol Driver version 3.3.7 (12/13/93) Written by Fred N. van

Kempen, MicroWalt Corporation. connected to cowslip.moo.com with addr 192.168.5.74 #

Das Skript selbst ist in Tabelle 7.1 zu sehen. Beispiel 7.1: dip-Beispielskript # dip-Beispielskript zur Anwahl von cowslip # setze lokale und entfernte Namen/Adressen get $local vlager-slip get $remote cowslip port ttyS3 # wähle seriellen Port speed 38400 # Geschwindigkeit auf Maximum modem HAYES # setze Modemtyp reset # Modem und TTY zurücksetzen flush # Eingabepuffer leeren # Einwahl vorbereiten send ATQ0V1E1X1\r wait OK 2 if $errlvl != 0 goto error dial 41988 if $errlvl != 0 goto error wait CONNECT 60 if $errlvl != 0 goto error # nun sind wir verbunden sleep 3 send \r\n\r\n wait ogin: 10 if $errlvl != 0 goto error send Svlager\n wait ssword: 5 if $errlvl != 0 goto error send knockknock\n wait running 30 if $errlvl != 0 goto error # wir sind eingeloggt, und die andere Seite setzt SLIP auf print Connected to $remote with address $rmtip default # dieser Link ist die Default-Route mode SLIP # wir wechseln nun auch in den SLIP-Modus # im Fehlerfall hierhin verzweigen error: print SLIP to $remote failed.

Nachdem die Verbindung zu cowslip steht und SLIP aktiviert ist, trennt sich dip vom Terminal ab und geht in den Hintergrund. Sie können dann die normalen Netzwerkdienste über den SLIP-Link benutzen. Um die Verbindung zu beenden, rufen Sie einfach den dip-Befehl mit der Kommandozeilenoption –k auf. Dadurch wird ein Hangup-Signal an dip gesendet, wobei die Prozeß-ID verwendet wird, die dip in der Datei /etc/dip.pid eingetragen hat: # dip -k

Bei der von dip zur Verfügung gestellten Skriptsprache bezeichnen Schlüsselwörter, denen ein Dollarzeichen vorangestellt ist, immer einen Variablennamen. dip besitzt eine ganze Reihe vordefinierter Variablen, die nachfolgend noch aufgeführt werden. Beispielsweise enthalten $remote und $local die Hostnamen der für den SLIP-Link verwendeten entfernten bzw. lokalen Hosts. In den ersten beiden Befehlszeilen im Beispielskript werden get-Befehle verwendet, mit denen bei dip Variablen gesetzt werden. In diesem Fall werden der entfernte und der lokale Hostname auf vlager bzw. cowslip gesetzt. In den nächsten fünf Befehlszeilen werden die Terminalleitung und das Modem eingerichtet. reset sendet einen Reset-String an das Modem (bei Hayes-kompatiblen Modems ist dies der ATZ-Befehl).Der nächste Befehl leert den Eingabepuffer, so daß der Login-Dialog korrekt funktionieren kann. Dieser Dialog ist ziemlich simpel: dip wählt einfach 41988, die Telefonnummer von cowslip, und loggt sich unter dem Account Svlager mit dem Paßwort knockknock ein. Der wait-Befehl veranlaßt dip, auf die Zeichenkette zu warten, die als erstes Argument übergeben wurde. Das zweite Argument bestimmt die Zeit, die auf diese Zeichenkette gewartet werden soll. Die in die Login-Prozedur eingestreuten if-Befehle prüfen, ob während der Ausführung irgendwelche Fehler aufgetreten sind. Die nach dem Einloggen noch verbleibenden Befehle sind default, der den SLIP-Link als Default-Route für alle Hosts definiert, und mode, der den SLIP-Modus für diese Leitung aktiviert und das Interface und die Routing-Tabelle für Sie konfiguriert.

dip-Referenz Dieser Abschnitt enthält eine Referenz der meisten dip-Befehle. Sie erhalten eine Übersicht aller Befehle, indem Sie dip im Testmodus starten und dann den help-Befehl eingeben. Um etwas zur Syntax eines Befehls zu erfahren, geben Sie den Befehl einfach ohne weitere Argumente ein (was natürlich bei Befehlen, die keine zusätzlichen Argumente benötigen, nicht funktioniert). Das folgende Beispiel illustriert den help-Befehl: # dip -t DIP: Dialup IP Protocol Driver version 3.3.7p-uri (25 Dec 96) Written by Fred N. van Kempen, MicroWalt Corporation. Debian version 3.3.7p-2 (debian). DIP> help DIP knows about the following commands: beep bootp break chatkey config databits dec default dial echo flush get goto help if inc init mode modem netmask onexit

parity password proxyarp print psend port quit securidfixed securid send shell skey sleep stopbits term timeout wait DIP> echo Usage: echo on|off DIP>

reset speed

Im gesamten folgenden Abschnitt zeigen die Beispiele, bei denen der DIP>-Prompt auftaucht, wie Sie einen Befehl im Testmodus eingeben müssen und welche Ausgabe dieser Befehl dann erzeugt. Fehlt dieser Prompt, sollten Sie die Beispiele als Auszüge von Skripten betrachten. Modembefehle dip stellt eine ganze Reihe von Befehlen zur Verfügung, mit denen Sie Ihre serielle Leitung und Ihr Modem konfigurieren können. Die Funktion ist bei einigen Befehlen offensichtlich; beispielsweise wählt port den zu verwendenden Port aus. Weitere solche Befehle sind speed, databits, stopbits und parity, mit denen Sie die gängigen Parameter der Leitung einstellen können.Mit dem modem-Befehl können Sie den aktuellen Modemtyp wählen. Momentan ist HAYES (in Großbuchstaben!) der einzig unterstützte Typ. Sie müssen dip den Modemtyp bekanntgeben, weil es sonst die Ausführung der Befehle dial und reset verweigert. Der Befehl reset sendet einen Reset-String an das Modem. Dieser String ist vom verwendeten Modem abhängig. Bei Hayes-kompatiblen Modems lautet dieser String ATZ. Mit dem flush-Befehl werden alle noch im Eingabepuffer befindlichen Antworten des Modems verworfen. Andernfalls könnte das einem reset folgende Dialogskript verwirrt sein, weil es die OKs früherer Befehle vorfinden würde. Mit dem init-Befehl wählen Sie einen Initialisierungsstring, der an das Modem geschickt wird, bevor gewählt wird. Die Standardeinstellung für Hayes-Modems lautet ATE0 Q0 V1 X1, womit die Ausgabe (Echo) von Befehlen und langen Ergebniscodes sowie die “Blindwahl” (keine Prüfung des Wähltons) aktiviert wird. Die meisten Modems sind bereits korrekt voreingestellt, so daß diese Vorbereitungen eigentlich nicht notwendig sind, wenn sie auch nicht weiter schaden. Schließlich sendet der dial-Befehl einen Initialisierungsstring an das Modem und wählt den Remote-Rechner an. Der StandardWählbefehl für Hayes-Modems lautet ATD. Der echo-Befehl Der echo-Befehl dient als Debugging-Hilfe. Mit echo on werden von dip alle an das serielle Gerät geschickten Daten auch auf der Konsole ausgegeben. Diese Option können Sie mit dem Befehl echo off wieder abschalten. dip erlaubt Ihnen, den Skriptmodus kurzfristig zu verlassen und den Terminalmodus zu verwenden. In diesem Modus arbeitet dip wie ein normales Terminalprogramm, das Daten an die serielle Leitung schickt und von ihr liest. Mit Strg-] setzen Sie die Abarbeitung der Skripten fort. Der get-Befehl Mit dem Befehl get können Sie Variablen für dip setzen. Die einfachste Form ist, eine Variable auf einen konstanten Wert zu setzen, wie wir das bei cowslip.dip getan haben. Darüber hinaus können Sie aber auch Eingaben vom Benutzer anfordern, indem Sie das Schlüsselwort ask anstelle eines Wertes angeben: DIP> get $local ask Enter the value for $local: _

Eine dritte Möglichkeit ist der Versuch, den Wert vom entfernten Host zu erhalten. So seltsam das auf den ersten Blick auch erscheinen mag, so nützlich ist es in manchen Fällen. Manche SLIP-Server erlauben Ihnen nicht die Verwendung einer eigenen IP-Adresse für den SLIP-Link, sondern weisen Ihnen beim Einwählen eine Adresse aus einem Adreß-Pool zu, wobei Sie eine Meldung erhalten, welche Adresse Ihnen zugewiesen wurde. Wenn die Nachricht in etwa die folgende Form hat: Your address: 192.168.5.74, können Sie mit den folgenden Befehlszeilen Ihre Adresse ermitteln: # finish login wait address: 10 get $locip remote

Der print-Befehl

Mit diesem Befehl können Sie Texte auf die Konsole ausgeben, von der aus dip gestartet wurde. Die von dip verwendeten Variablen können in print-Befehlen verwendet werden: DIP> print Using port $port at speed $speed Using port ttyS3 at speed 38400

Variablennamen dip versteht nur eine Reihe vordefinierter Variablen. Ein Variablenname beginnt immer mit einem Dollarzeichen und muß in Kleinbuchstaben geschrieben werden. Die Variablen $local und $locip enthalten den lokalen Hostnamen und die IP-Adresse. Wenn Sie den kanonischen Hostnamen in $local speichern, versucht dip automatisch, diese Hostadresse zu einer IP-Adresse aufzulösen, und speichert diese in $locip. Analog geht es auch beim Setzen von $locip vonstatten. In diesem Fall versucht dip eine umgekehrte Adreßauflösung und speichert den ermittelten Hostnamen in der Variable $local. Die Variablen $remote und $rmtip speichern die entsprechenden Angaben für den entfernten Host. $mtu enthält den MTUWert dieser Verbindung. Diese fünf Variablen sind die einzigen, denen Sie mit get direkt Werte zuweisen können. Eine Reihe anderer Variablen werden nur über spezielle gleichlautende Befehle gesetzt, können aber mittels print-Befehlen ausgegeben werden: $modem, $port und $speed. $errlvl ist die Variable, mit der Sie auf das Resultat des zuletzt ausgeführten Befehls zugreifen können. Ist der Wert null, ist die Operation erfolgreich durchgeführt worden, bei einem Wert ungleich null ist ein Fehler aufgetreten. Die if- und goto-Befehle Der Befehl if verursacht lediglich eine bedingte Verzweigung und ist nicht mit dem if einer vollwertigen Programmiersprache vergleichbar. Die Syntax lautet: if var op number goto label

Der Ausdruck darf nur ein einfacher Vergleich zwischen einer der Variablen $errlvl, $locip und $rmtip sein. var muß eine ganze Zahl sein. Der Operator op steht für ==, !=, <, >, <= oder >=. Mit dem goto-Befehl wird die Ausführung des Skripts in der Zeile fortgesetzt, die dem label folgt. Ein Label muß an der ersten Stelle einer Zeile beginnen, und es muß ihm unmittelbar ein Doppelpunkt folgen. send, wait und sleep Diese Befehle helfen bei der Implementierung einfacher Dialogskripten unter dip. send überträgt seine Argumente an die serielle Leitung. Variablen werden nicht unterstützt, wohl aber C-ähnliche Backslash-Sequenzen wie \n (Newline) und \b (Backspace). Das Tildezeichen (~) wird als Abkürzung für die Zeichenkombination Wagenrücklauf/Newline verwendet. wait akzeptiert ein Wort als Argument und liest die Eingaben von der seriellen Schnittstelle, bis es dieses Wort findet. Das Wort selbst darf keine Leerzeichen enthalten. Optional können Sie wait einen Timeout-Wert (in Sekunden) als zweites Argument übergeben. Wird das gewünschte Wort nicht innerhalb dieser Zeit gefunden, bricht der Befehl ab und setzt die Variable $errlvl auf eins. Dieser Befehl wird zur Erkennung von Login- und anderen Prompts verwendet. Mit dem sleep-Befehl können Sie die weitere Befehlsausführung für eine bestimmte Zeit anhalten, beispielsweise um das Ende einer Login-Sequenz abzuwarten. Auch bei diesem Befehl wird die zu wartende Zeit in Sekunden angegeben. mode und default Diese Befehle werden verwendet, um die serielle Leitung in den SLIP-Modus zu schalten und das Interface zu konfigurieren.

mode ist der letzte Befehl, der von dip ausgeführt wird, bevor es in den Dämonmodus wechselt. Wenn kein Fehler auftritt, kehrt der Befehl nicht zurück. mode erwartet einen Protokollnamen als Argument. dip akzeptiert momentan SLIP, CSLIP, SLIP6, CSLIP6, PPP und TERM als gültige Werte. Leider kann die derzeitige Version von dip noch nicht mit adaptivem SLIP umgehen. Nachdem der SLIP-Modus für die serielle Leitung aufgesetzt wurde, führt dip den Befehl ifconfig aus, um das Interface als Punkt-zu-Punkt-Verbindung zu konfigurieren. Danach wird noch route gestartet, um die Route zum entfernten Host einzurichten. Wenn das Skript vor dem mode-Befehl noch den default-Befehl ausführt, dann erzeugt dip eine Default-Route, die auf diesen SLIP-Link zeigt.

1.

diplogin muß auch als Setuid root ausgeführt werden. Beachten Sie die Hinweise im letzten Abschnitt dieses Kapitels.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der Servermodus Den SLIP-Client einzurichten war der schwierige Teil. Das Gegenteil davon — nämlich Ihren Host so zu konfigurieren, daß er als SLIP-Server arbeitet — ist wesentlich einfacher. Es gibt zwei Wege, einen SLIP-Server einzurichten. In beiden Fällen wird erwartet, daß Sie jeweils einen Login-Account pro SLIP-Client einrichten. Nehmen wir mal an, Sie wollen Arthur Dent, der an dent.beta.com sitzt, mit SLIP-Diensten versorgen. Sie können einen Account namens dent einrichten, indem Sie die folgende Zeile in Ihre passwd-Datei aufnehmen: dent:*:501:60:Arthur Dent's SLIP account:/tmp:/usr/sbin/diplogin

Das Paßwort für dent würden Sie danach mit dem passwd-Programm einrichten. Das dip-Programm kann im Servermodus betrieben werden, indem es als diplogin aufgerufen wird. Normalerweise ist diplogin ein Link auf dip. Die Haupt-Konfigurationsdatei ist /etc/diphosts; in ihr ist angegeben, welche IP-Adresse einem SLIP-Anwender zugewiesen wird, wenn er sich einwählt. Alternativ können Sie sliplogin verwenden, ein BSD-basiertes Tool, das ein wesentlich flexibleres Konfigurationsschema unterstützt. Dank dieses Schemas können Sie beliebige Shell-Skripten ausführen, wenn ein Host die Verbindung aufbaut oder beendet.

Wenn sich unser SLIP-Benutzer dent nun einloggt, fährt dip als Server hoch. Um zu ermitteln, ob er wirklich berechtigt ist, SLIP zu verwenden, sucht das Programm den Benutzernamen in der Datei /etc/diphosts. Diese Datei enthält Angaben zu den Zugriffsrechten und Verbindungsparametern jedes SLIP-Benutzers. Das allgemeine Format für einen Eintrag in /etc/diphosts sieht wie folgt aus: # /etc/diphosts user:password:rem-addr:loc-addr:netmask:comments:protocol,MTU #

Die Bedeutung dieser Felder ist in Tabelle 7.2 beschrieben. Tabelle 7.2: /etc/diphosts (Erläuterung der Felder) Feld user

password

Beschreibung Bezeichnet den Benutzernamen des Anwenders, der den Befehl dip aufruft. Das zweite Feld in der Datei /etc/diphosts wird dazu benutzt, eine zusätzliche paßwortbezogene Sicherheitsebene über die SLIP-Verbindung zu legen. Sie können hier ein Paßwort in verschlüsselter Form angeben (so wie in /etc/passwd). Beim Aufruf von diplogin erscheint dann ein Prompt, der den Benutzer zur Eingabe des korrekten Paßwortes auffordert. Erst danach wird dem Anwender SLIP-Zugang gewährt. Beachten Sie, daß es sich hierbei um ein zusätzliches Paßwort handelt, außer dem Paßwort, das der Benutzer beim normalen login-Prompt eingibt.

Die Adresse, die der Gegenstelle zugewiesen wird. Sie kann entweder als Hostname angegeben werden, der dann automatisch zu einer IP-Adresse aufgelöst wird, oder als rem-addr IP-Adresse in Dotted Quad Notation. Die IP-Adresse, die für das lokale Ende der SLIP-Verbindung benutzt wird. Auch diese loc-addr Adresse wird in Form eines Hostnamens oder in Dotted Quad Notation angegeben.

netmask

Die Netzmaske, die für das Routing eingesetzt wird. Viele Leute kommen mit diesem Eintrag nicht zurecht. Die Netzmaske bezieht sich nicht auf die SLIP-Verbindung selbst, sondern wird in Kombination mit dem rem-addr-Feld benutzt, um eine Route zur Gegenstelle zu bilden. Sie sollte auf einen Wert gesetzt werden, der vom Netzwerk der Gegenstelle unterstützt wird.

Dieses Feld enthält formlosen Text, mit dem Sie die Datei /etc/diphosts dokumentieren comments können. Ansonsten erfüllt es keinen weiteren Zweck. Gibt das Protokoll oder die Verbindungsart (line discipline) an, das bzw. die für diese Verbindung gelten soll. Sie können dafür dieselben Werte nehmen, die als Argumente protocol für die Option –p im Befehl slattach zugelassen sind.

MTU

Die maximale Übertragungseinheit, die diese Verbindung transportieren kann. Sie beschreibt den Umfang des größten Datenpakets, das über die Leitung geschickt werden soll. Jedes noch größere Datenpaket, das die SLIP-Schnittstelle passiert, wird in kleinere Häppchen zerteilt, die nicht größer als die MTU sind. Normalerweise haben die MTUs auf beiden Seiten der Verbindung dieselbe Größe.

Ein Beispieleintrag für dent könnte wie folgt aussehen: dent::dent.beta.com:vbrew.com:255.255.255.0:Arthur Dent:CSLIP,296

In unserem Beispiel wird dem Benutzer dent SLIP-Zugang ohne zusätzliche Paßworteingabe gewährt. Er erhält die mit dent.beta.com assoziierte IP-Adresse mit einer Netzmaske von 255.255.255.0. Seine Default-Route sollte an die IP-Adresse von vbrew. com gerichtet sein, und er benutzt das CSLIPProtokoll mit einer MTU von 296 Byte. Loggt sich dent ein, extrahiert diplogin die erforderlichen Informationen über ihn aus der Datei diphosts. Ist das zweite Feld dabei nicht leer, wird nach einem “externen Sicherheitspaßwort” gefragt. Der vom Benutzer eingegebene String wird verschlüsselt und mit dem Paßwort aus diphosts verglichen. Stimmen beide nicht überein, wird das Login verweigert. Wenn das Paßwortfeld die Zeichenfolge s/key enthält und dip mit S/Key-Unterstützung kompiliert wurde, tritt eine S/KeyAuthentifizierung in Kraft. Dies ist in der Dokumentation zum dip-Quellcode beschrieben. Nach erfolgreichem Login schaltet diplogin die serielle Leitung in den CSLIP- oder SLIP-Modus und richtet das Interface und die Route ein. Die Verbindung wird so lange aufrechterhalten, bis der Benutzer seine Arbeit beendet und das Modem die Leitung unterbricht. diplogin setzt die Leitungsparameter dann wieder zurück und beendet seine Operation. diplogin benötigt Superuser-Privilegien. Läuft dip ohne Setuid root, sollte diplogin eine separate Kopie von dip und nicht nur ein einfacher Link darauf sein. Auf diplogin kann dann ohne Bedenken Setuid angewandt werden, ohne den Status von dip selbst zu beeinträchtigen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 8 Das Point-to-PointProtokoll

Genau wie SLIP ist auch PPP ein Protokoll, mit dem Sie Datagramme über eine serielle Leitung übertragen können, das aber eine Reihe von Defiziten von SLIP behebt. Zum einen ist es nicht auf das IP-Protokoll beschränkt, sondern unterstützt eine Vielzahl weiterer Protokolle. Außerdem bietet es eine Fehlerkontrolle der Verbindung — im Gegensatz zu SLIP, das auch fehlerhafte IP-Pakete verarbeitet, solange nicht der Header betroffen ist. Ebenso wichtig ist, daß PPP den kommunizierenden Rechnern ermöglicht, sich über Optionen wie IP-Adressen und die maximale Datagrammgröße während der Startphase zu verständigen, und es stellt Mechanismen zur Autorisierung des kommunizierenden Partners bereit. Mit diesem eingebauten

Verständigungsmechanismus können Verbindungsaufbauten zuverlässig automatisiert werden. Die Authentifizierungsmechanismen von PPP machen die umständlichen Benutzer-Login überflüssig, die SLIP benötigt. Für jede dieser Fähigkeiten verwendet PPP ein separates Protokoll. In diesem Kapitel behandeln wir die grundlegenden Bausteine von PPP. Die Erläuterung ist weit davon entfernt, vollständig zu sein. Wenn Sie mehr über PPP wissen wollen, sollten Sie sich die entsprechende RFCSpezifikation sowie das gute Dutzend begleitender RFCs ansehen. Außerdem gibt es ein umfangreiches Buch von O'Reilly & Associates über das Thema Using & Managing PPP von Andrew Sun. Die Basis bei PPP bildet das High-Level Data Link Control-Protokoll (HDLC). Dieses Protokoll definiert die Begrenzung der einzelnen PPP-Frames und liefert eine 16-Bit-Prüfsumme.1 Im Gegensatz zur eher primitiven SLIP-Kapselung ist ein PPP-Frame in der Lage, auch Pakete anderer Protokolle als IP zu transportieren (z.B. Novells IPX oder AppleTalk). PPP erreicht dies, indem es ein Protokollfeld in den HDLC-Frame aufnimmt, der den Typ des Pakets bestimmt, das sich in diesem Frame befindet. LCP, das Link Control Protocol, ist auf HDLC aufgesetzt und dient dazu, die Konfiguration der Leitung zwischen beiden Partnern auszuhandeln. Dazu gehört beispielsweise die Maximum Receive Unit (MRU), mit der die maximale Datagrammgröße bestimmt wird, die ein Host zu empfangen bereit ist. Ein wichtiger Schritt am Anfang der Konfiguration eines PPP-Links ist die Client-Authentifizierung. Obwohl sie nicht vorgeschrieben ist, ist sie für Wählverbindungen dennoch unbedingt zu empfehlen, um potentielle Eindringlinge fernzuhalten. Üblicherweise fordert der angerufene Host (der Server) den Client auf, sich auszuweisen, indem er beweist, daß er einen geheimen Schlüssel (z.B. ein Paßwort) kennt. Wenn der Anrufer nicht mit der richtigen Antwort aufwarten kann, wird die Verbindung unterbrochen. Bei PPP funktioniert die Authentifizierung in beiden Richtungen, d.h., der Anrufer kann auch den Server auffordern, sich auszuweisen. Diese Authentifizierungs-Prozeduren laufen völlig unabhängig voneinander ab. Es gibt zwei Protokolle für unterschiedliche Arten der Authentifizierung, die wir weiter unten noch besprechen werden. Diese Protokolle heißen Password Authentication Protocol (PAP) und Challenge Handshake Authentication Protocol (CHAP). Jedes Netzwerkprotokoll wie IP und AppleTalk, das über die Datenverbindung geroutet wird, wird mit Hilfe eines entsprechenden Network Control Protocol (NCP) dynamisch konfiguriert. Sollen zum Beispiel IP-Datagramme über einen Link geschickt werden, müssen beide Kommunikationspartner zuerst aushandeln, welche IP-Adresse von der jeweils anderen Seite verwendet wird. Das dabei benutzte Protokoll ist IPCP, das Internet Protocol Control Protocol. Neben der Übertragung normaler IP-Datagramme unterstützt PPP auch die Header-Komprimierung von IP-Datagrammen nach Van Jacobson. Bei dieser Technik werden Header von TCP-Paketen auf eine Größe von bis zu drei Bytes reduziert. Sie wird auch bei CSLIP verwendet und wird allgemein als VJ-Header-Komprimierung bezeichnet. Die Verwendung der Komprimierung kann ebenfalls während des Starts über IPCP vereinbart werden.

1.

Tatsächlich ist HDLC ein wesentlich allgemeineres Protokoll, das sich die International Standards Organization (ISO) ausgedacht hat, und auch ein wesentlicher Bestandteil der X.25-Spezifikation.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

PPP auf Linux Bei Linux ist die PPP-Funktionalität in zwei Teile untergliedert: in eine Kernel-Komponente, die die Low-Level-Protokolle verwaltet (HDLC, IPCP, IPXCP usw.), und einen Dämon (pppd), der die verschiedenen höheren Protokolle wie PAP und CHAP behandelt. Das aktuelle Release von PPP für Linux besteht aus dem PPP-Dämon pppd und einem Programm namens chat, das die Einwahl in den entfernten Rechner automatisiert. Der PPP-Kernel-Treiber wurde von Michael Callahan geschrieben und von Paul Mackerras überarbeitet. pppd stammt von einer freien PPP-Implementierung1 für Sun- und 386BSD-Maschinen ab, die von Drew Perkins und anderen geschrieben wurde und von Paul Mackerras gepflegt wird. Auf Linux wurde sie von Al Longyear portiert. chat wurde von Karl Fox geschrieben.2 Genau wie SLIP wird auch PPP über einen speziellen tty-Modus (line discipline) implementiert. Um eine serielle Leitung als PPP-Link zu verwenden, bauen Sie die Verbindung wie gewohnt über Ihr Modem auf und schalten sie danach in den PPP-Modus. In diesem Modus werden alle eingehenden Daten an den PPP-Treiber weitergeleitet, der die eingehenden HDLC-Frames auf Gültigkeit prüft (jeder HDLC-Frame enthält eine 16-Bit-Prüfsumme), sie auspackt und verteilt. Im Moment kann PPP sowohl das IP-Protokoll (optional mit Van-Jacobson-Komprimierung) als auch das IPX-Protokoll transportieren.

Der Kernel-Treiber wird von pppd unterstützt, das die gesamte Initialisierungs- und Authentifizierungsphase übernimmt, die notwendig ist, bevor die eigentlichen Daten über die Leitung geschickt werden können. Feineinstellungen am Verhalten von pppd können über eine Reihe von Optionen vorgenommen werden. kann über eine ganze Reihe von Optionen abgestimmt werden. Da PPP ziemlich komplex ist, ist es unmöglich, sie alle in einem einzigen Kapitel zu behandeln. Aus diesem Grund kann dieses Buch nicht alle Aspekte von pppd behandeln, sondern nur eine Einführung bieten. Für weitere Informationen seien Sie auf Using & Managing PPP, die Manpages und die READMEs der pppd-Quelldistribution verwiesen. Dort sollten Sie Antworten auf die meisten Fragen finden, die in diesem Kapitel nicht behandelt werden konnten. Das PPP-HOWTO kann da auch von Nutzen sein. Die womöglich beste Hilfe zur Konfiguration von PPP erhalten Sie von Leuten, die dieselbe LinuxDistribution wie Sie benutzen. Konfigurationsfragen zu PPP kommen sehr häufig vor; daher sollten Sie auch in Mailing-Listen lokaler Benutzergruppen hineinschauen oder die Leute im IRC Linux Channel fragen. Wenn Sie nach dem Lesen der Dokumentation immer noch Probleme haben, sollten Sie sich an die Newsgruppe comp.protocols.ppp wenden. In dieser Newsgruppe finden Sie die meisten der Leute, die an der Entwicklung von pppd beteiligt waren.

1.

Wenn Sie irgendwelche Fragen zu PPP im allgemeinen haben, wenden Sie sich an die Leute auf der Linux-net-Mailing-Liste unter vger.rutgers.edu

2.

Karl ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Arbeiten mit pppd Wenn Sie sich über einen PPP-Link an das Internet anschließen wollen, müssen Sie die grundlegenden Netzwerkfähigkeiten wie das Loopback Device und den Resolver eingerichtet haben. Wie das funktioniert, wurde in Kapitel 5 TCP/IP-Konfiguration, und Kapitel 6 Name-Server- und Resolver-Konfiguration, besprochen. Den Name-Server Ihres Internet Service Providers könnten Sie einfach in die Datei /etc/resolv.conf eintragen, aber das würde bedeuten, daß jede DNS-Anfrage über Ihre serielle Leitung laufen müßte. Das ist natürlich keine optimale Lösung, denn je näher Sie Ihrem Name-Server sind, desto schneller werden DNS-Anfragen beantwortet. Eine alternative Lösung besteht darin, auf einem Host in Ihrem Netzwerk einen Caching-only-Name-Server einzurichten. In der Praxis hätte dies den Effekt, daß nur die jeweils erste DNS-Anfrage nach einem bestimmten Host über die Leitung übertragen werden müßte, jede folgende würde dann von Ihrem lokalen NameServer beantwortet werden, und das erheblich schneller. Diese Konfiguration wird in Kapitel 6, in Caching-Only-Konfigurationen für named beschrieben. Um sich zur Einleitung vor Augen zu führen, wie eine PPP-Verbindung mit pppd aufgebaut wird, stellen Sie sich vor, daß Sie wieder an vlager sitzen. Sie haben bereits den PPP-Server c3po angewählt und sich in den ppp-Account eingeloggt. c3po hat seinen PPP-Treiber bereits gestartet. Nachdem Sie das Kommunikationsprogramm beendet haben, mit dem Sie die Verbindung hergestellt hatten, führen Sie den folgenden Befehl aus (wobei Sie die hier angegebene Schnittstelle ttyS3 gegebenenfalls entsprechend ändern):

# pppd /dev/ttyS3 38400 crtscts defaultroute

Mit diesem Befehl schalten Sie die serielle Leitung ttyS3 in den PPP-Modus und bauen einen IP-Link zu c3po auf. Die Übertragungsgeschwindigkeit des seriellen Ports liegt bei 38.400 bps. Mit der Option crtscts aktivieren Sie den Hardware-Handshake für diesen Port, was bei Geschwindigkeiten über 9.600 bps ein absolutes Muß ist. Nachdem pppd gestartet wurde, vereinbart es zuerst mit Hilfe von LCP verschiedene Verbindungseigenschaften mit der Gegenstelle. Üblicherweise funktionieren die Standardoptionen, die pppd auszuhandeln versucht, auf Anhieb, weshalb wir an dieser Stelle nicht weiter darauf eingehen. Sie müssen allerdings damit rechnen, daß beim Verbindungsaufbau nach den IP-Adressen der beteiligten Seiten gefragt wird. Im Moment gehen wir auch davon aus, daß c3po von uns keine Authentifizierung erwartet, so daß die Konfigurationsphase an dieser Stelle erfolgreich abgeschlossen ist. pppd vereinbart dann mit Hilfe von IPCP, dem IP-Kontrollprotokoll, die IP-Parameter mit seinem Gegenüber. Weil wir in der Befehlszeile keine bestimmte IP-Adresse an pppd übergeben haben, wird es versuchen, die Adresse zu verwenden, die der Resolver für den lokalen Hostnamen ermittelt hat. Beide geben sich dann ihre Adressen gegenseitig bekannt. Normalerweise gibt es mit diesen Voreinstellungen keine Schwierigkeiten. Selbst wenn Ihr Rechner an einem Ethernet hängt, können Sie dieselbe IP-Adresse sowohl für das Ethernet als auch für das PPP-Interface benutzen. Trotzdem ermöglicht es Ihnen pppd, eine andere Adresse zu benutzen. Sie können sogar die Gegenstelle auffordern, eine bestimmte Adresse zu verwenden. Diese Optionen werden alle im Abschnitt IP-Konfigurationsoptionen behandelt. Nachdem pppd die IPCP-Setup-Phase hinter sich gebracht hat, bereitet es die Netzwerkschicht Ihres Hosts für die Verwendung des PPP-Links vor. Zuerst konfiguriert es das PPP-Netzwerk-Interface als Point-to-Point-Link. Dabei verwendet es ppp0 für den ersten aktiven PPP-Link, ppp1 für den zweiten und so weiter. Danach richtet es einen Eintrag in der Routing-Tabelle ein, der auf den Host am anderen Ende des Links zeigt. In unserem obigen Beispiel läßt pppd die Default-Netzwerkroute auf c3po zeigen, weil wir die Option defaultroute verwendet haben.1 Die Default-Route vereinfacht Ihr Routing, indem alle IP-Datagramme, die nicht an lokale Hosts gerichtet sind, an c3po gesandt werden. Dieses Vorgehen ist sinnvoll, da das der einzige Weg ist, über den externe Hosts erreicht werden können. pppd unterstützt eine Reihe unterschiedlicher Routing-Schemata, auf die wir später in diesem Kapitel noch eingehen werden.

1.

Die Default-Netzwerkroute wird nur installiert, wenn noch keine vorhanden ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Arbeiten mit Optionsdateien Bevor pppd seine Kommandozeilenargumente bearbeitet, durchsucht es verschiedene Dateien nach Standardoptionen. Diese Dateien dürfen beliebige gültige Kommandozeilenargumente enthalten, die auch über mehrere Zeilen verteilt sein können. Kommentare werden dabei durch Doppelkreuze (Hashzeichen) eingeleitet. Die erste Optionsdatei ist /etc/ppp/options, die immer durchsucht wird, während pppd startet. Es ist eine gute Idee, diese Datei für allgemeine Standardeinstellungen zu verwenden, weil Sie auf diese Weise verhindern, daß Benutzer verschiedene Dinge tun könnten, die sich negativ auf die Systemsicherheit auswirken. Damit pppd beispielsweise irgendeine Form der Authentifizierung (PAP oder CHAP) von der Gegenseite erwartet, könnten Sie die Option auth in diese Datei aufnehmen. Diese Option kann von einem Benutzer nicht überschrieben werden, d.h., PPP kann keine Verbindung zu einem System aufbauen, das nicht in Ihrer Authentifizierungsdatei steht. Beachten Sie, daß einige andere Optionen durchaus überschrieben werden können; die Option -connect ist dafür ein gutes Beispiel. Nach /etc/ppp/options wird die Optionsdatei .ppprc im Home-Verzeichnis des Benutzers gelesen. Sie ermöglicht jedem Benutzer die individuelle Einstellung von Standardoptionen. Die Datei /etc/ppp/options könnte beispielsweise wie folgt aussehen: # Globale Optionen für pppd auf vlager.vbrew.com lock # verwende UUCP-konforme Sperrung von Gerätedateien auth # Authentifizierung notwendig usehostname # verwende lokalen Hostnamen für CHAP domain vbrew.com # unser Domainname

Wegen des Schlüsselworts lock verwendet pppd die UUCP-Standardmethode zum Sperren der Gerätedateien. Nach dieser Konvention erzeugt jeder Prozeß, der auf eine serielle Schnittstelle, beispielsweise /dev/ttyS3, zugreift, eine Lock-Datei namens LCK..ttyS3 in einem speziellen Lock-Verzeichnis, um zu signalisieren, daß dieses Gerät gerade benutzt wird. Ein solches Vorgehen ist notwendig, um sicherzustellen, daß andere Programme wie minicom oder uucico nicht auf das Gerät zugreifen, solange es von PPP verwendet wird. Die nächsten drei Optionen betreffen die Authentifizierung und damit die Systemsicherheit. Die Authentifizierungsoptionen werden am besten in der globalen Konfigurationsdatei festgelegt, da sie “privilegiert” sind und nicht von den Optionen in der Benutzer-datei ~/.ppprc überschrieben werden können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Anwählen mit Chat Eine Sache, die Sie in unserem obigen Beispiel vielleicht als unbequem betrachten könnten, ist, daß Sie die Verbindung zuerst manuell aufbauen müssen, bevor Sie pppd starten können. Leider besitzt pppd im Gegensatz zu dip keine eigene Skriptsprache, mit der Sie die Gegenstelle anwählen und sich einloggen können, sondern ist von einem externen Programm oder Shell-Skript abhängig, das diese Aufgabe übernimmt. Der entsprechende Befehl kann pppd mit der Kommandozeilenoption connect übergeben werden. pppd leitet die Standardein- und -ausgabe des Programms dann an die serielle Leitung um. Das Softwarepaket von pppd enthält ein sehr einfaches Programm namens chat, mit dem Sie Login-Sequenzen auf die eben beschriebene Weise automatisieren können. Damit beschäftigen wir uns noch etwas ausführlicher. Wenn Ihre Login-Sequenz komplex ist, brauchen Sie etwas Besseres als chat. Eine sehr interessante Alternative ist expect, das von Don Libes geschrieben wurde. Es hat eine sehr mächtige Tcl-basierte Programmiersprache und wurde genau für diese Zwecke entworfen. All diejenigen unter Ihnen, deren Login-Vorgang z.B. eine Frage/Antwort-(Challenge/Response)Authentifizierung erfordert, bei der rechenintensive Schlüsselgeneratoren zum Einsatz kommen, werden feststellen, daß expect ein Werkzeug ist, das dieser Aufgabe gewachsen ist. Nun gibt es aber dabei so viele verschiedene Varianten, daß wir in diesem Buch nicht darauf eingehen, wie man so ein Skript schreibt. Eigentlich brauchen Sie nur zu wissen, wie man ein expect-Skript startet, nämlich durch Angabe seines Namens zusammen mit der connect-Option von pppd. Wichtig ist zu beachten, daß die Standardeingabe und -ausgabe auf das Modem umgelenkt werden, solange das Skript läuft, und nicht etwa auf das Terminal, auf dem der pppd-Dämon gestartet wurde. Wenn Sie in dieser Zeit Benutzeraktivitäten gestatten wollen, müssen Sie auf ein freies virtuelles Terminal umschalten oder andere Möglichkeiten bereitstellen. Mit dem Programm chat können Sie Chat-Skripten ausführen, wie sie auch von UUCP verwendet werden. Grundsätzlich besteht ein Chat-Skript aus einer abwechselnden Folge von Zeichenketten, die wir vom entfernten System erwarten, sowie den Antworten, die auf diese Strings übertragen werden sollen. Wir nennen sie expect-Strings (die erwarteten Zeichenketten) und send-Strings (die zu übertragenden Zeichenketten). Nachfolgend ein typischer Ausschnitt aus einem Chat-Skript: ogin: b1ff ssword: s3|
Dieses Skript weist chat an, darauf zu warten, bis die andere Seite den Login-Prompt gesendet hat, und dann den Login-

Namen b1ff zurückzuschicken. Wir warten nur auf ogin:, so daß es keine Rolle spielt, ob der Login-Prompt mit einem großen oder kleinen “l” oder sonst was beginnt. Der folgende String ist eine weitere Zeichenfolge, auf die chat warten soll. Sobald sie eingeht, wird unser Paßwort als Antwort übertragen. Das ist im Grunde schon alles, was es zu Chat-Skripten zu sagen gibt. Ein vollständiges Skript, mit dem Sie einen PPPServer anwählen würden, müßte natürlich auch die entsprechenden Modembefehle enthalten. Angenommen, Ihr Modem versteht den Hayes-Befehlssatz, und die Telefonnummer des Servers lautet 318714. Die vollständige Befehlszeile, mit der chat die Verbindung zu c3po aufbaut, wäre dann: $ chat -v ’’ ATZ OK ATDT318714 CONNECT ’’ ogin: ppp word: GaGariN

Per Definition wird zuerst ein Expect-String erwartet, aber weil das Modem nichts sagen würde, wenn wir nicht ein wenig nachhelfen würden, veranlassen wir chat, den ersten Expect-String zu überspringen, indem wir einen leeren String angeben. Wir machen weiter und senden ATZ, den Reset-Befehl für Hayes-kompatible Modems, und warten auf die entsprechende Antwort (OK). Der nächste String sendet den Wählbefehl zu-sammen mit der gewünschten Telefonnummer an chat und erwartet die Nachricht -CONNECT als Antwort. Dem folgt wieder ein leerer String, weil wir nun nichts mehr senden wollen, sondern nur noch auf den Login-Prompt warten. Der Rest des Skripts arbeitet genauso, wie bereits oben beschrieben. Diese Beschreibung ist vielleicht ein wenig verwirrend, wir werden aber in Kürze sehen, daß es einen Weg gibt, Chat-Skripten leichter verständlich zu gestalten. Mit der Option –v weisen Sie chat an, alle Aktivitäten über den local2-Kanal des syslog-Dämons zu protokollieren.1 Die Angabe des Chat-Skripts auf der Kommandozeile birgt ein gewisses Risiko, weil Benutzer sich die Kommandozeilen laufender Prozesse mit dem ps-Befehl ansehen können. Sie können dieses Risiko vermeiden, indem Sie das Skript in einer Datei, z.B. dial-c3po, speichern. Mit der Option –f (gefolgt vom Dateinamen) können Sie chat dann anweisen, das Skript aus dieser Datei zu lesen. Dieses Verfahren hat zudem den Vorteil, unsere Chat-Expect-Sequenzen leichter verständlich zu machen. Auf unser Beispiel übertragen, würde unsere dial-c3po-Datei so aussehen: ’’

ATZ OK

ATDT318714 CONNECT ’’ ogin:

ppp word:

GaGariN

In einem solchen Chat-Skript stehen alle erwarteten Texte links und die darauf zu sendenden Antworten rechts davon. Es ist offensichtlich, daß Chat-Skripten in dieser Form erheblich leichter zu verstehen sind. Die vollständige pppd-Anweisung wäre nun wie folgt: # pppd connect "chat -f dial-c3po" /dev/ttyS3 38400 -detach \

crtscts modem defaultroute

Neben der Option connect, mit der das Skript bestimmt wird, haben wir noch zwei weitere Optionen in die Kommandozeile aufgenommen: zum einen -detach, mit der pppd angewiesen wird, sich nicht von der Konsole zu trennen und ein Hintergrundprozeß zu werden, zum anderen modem, wodurch modemspezifische Aktionen auf dem seriellen Gerät durchgeführt werden, beispielsweise die Unterbrechung der Leitung vor und nach jedem Anruf. Wenn Sie diese Option nicht verwenden, überwacht pppd nicht die DCD-Leitung des Ports und kann dann nicht erkennen, wenn das Gegenüber unvermittelt die Verbindung unterbricht. Die obigen Beispiele waren ziemlich einfach; mit chat können Sie jedoch auch wesentlich kompliziertere Skripten erstellen. Mit chat kann man beispielsweise einen String angeben, bei dem mit einer Fehlermeldung abgebrochen wird. Typische Strings sind Meldungen wie BUSY oder NO CARRIER, die normalerweise von Ihrem Modem erzeugt werden, wenn die gewählte Nummer besetzt ist oder nicht antwortet. Damit chat diese Nachrichten direkt erkennt und nicht erst auf den Timeout wartet, können Sie sie zusammen mit dem Schlüsselwort ABORT an den Anfang Ihres Skripts stellen: $ chat -v ABORT BUSY ABORT ’NO CARRIER’ ’’ ATZ OK ...

Auf ähnliche Weise können Sie den Timeout-Wert für Teile des Chat-Skripts ändern, indem Sie entsprechende TIMEOUTOptionen einfügen.

Manchmal sollen auch Teile des Skripts nur ausgeführt werden, wenn eine bestimmte Bedingung erfüllt ist. Wenn Sie zum Beispiel den Login-Prompt vom anderen Ende nicht empfangen können, wollen Sie möglicherweise ein BREAK oder einen Wagenrücklauf übertragen. Sie erreichen dies, indem Sie ein Subskript an einen Expect-String anhängen. Dieses besteht — genau wie bei einem normalen Skript — auch aus einer Reihe von Send- und Expect-Strings, die durch Bindestriche voneinander getrennt sind. Das Subskript wird immer dann ausgeführt, wenn der erwartete String, dem es anhängt, nicht innerhalb der vereinbarten Zeit eintrifft. Im obigen Beispiel würden Sie das Skript wie folgt modifizieren: ogin:-BREAK-ogin: ppp ssword: GaGariN

Empfängt chat nun vom entfernten System nicht den Login-Prompt, wird das Subskript ausgeführt. Dabei wird zuerst ein BREAK übertragen, und danach wird erneut auf den Login-Prompt gewartet. Erscheint der Prompt nun, läuft das Skript weiter, als wäre nichts gewesen; ansonsten wird es mit einem Fehler abgebrochen.

1.

Wenn Sie syslog.conf so editieren, daß alle Logmeldungen in eine Datei umgeleitet werden, müssen Sie darauf achten, daß diese Datei nicht von jedem gelesen werden kann, weil chat per Voreinstellung auch das gesamte Skript aufzeichnet — einschließlich aller Paßwörter etc.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Konfigurationsoptionen IPCP wird verwendet, um eine Reihe von IP-Parametern während der Verbindungsaufbauphase zu vereinbaren. Üblicherweise sendet jede Seite ein Paket mit einer IPCP-Konfigurationsanforderung, die beschreibt, welche Werte von den Defaults abweichen und auf welchen Wert sie gesetzt werden sollen. Nach dem Empfang prüft jede Seite die entsprechenden Optionen und stimmt entweder zu oder weist sie zurück. pppd gibt Ihnen Kontrolle darüber, welche IPCP-Optionen es auszuhandeln versucht und welche nicht. Sie können dies über verschiedene Kommandozeilenoptionen einstellen, die wir nachfolgend vorstellen.

Wahl von IP-Adressen Jedes IP-Interface benötigt eine ihm zugewiesene IP-Adresse; auch eine PPP-Schnittstelle hat somit eine IP-Adresse. Die diversen PPP-Protokolle bieten einen Mechanismus an, der die automatische Zuweisung von IP-Adressen an PPPSchnittstellen gestattet. Ein PPP-Programm an einem Ende einer Punkt-zu-Punkt-Verbindung kann der Gegenseite eine IPAdresse zuweisen, oder jede Seite kann ihre eigene IP-Adresse verwenden. Einige PPP-Server, die viele Client-Sites verwalten müssen, weisen Adressen dynamisch zu. Adressen werden nur an Systeme vergeben, wenn ein Anruf erfolgt, und werden anschließend recycelt, sobald die Verbindung wieder unterbrochen wird. Dieses Verfahren limitiert die Anzahl der notwendigen IP-Adressen auf die Anzahl der Einwählleitungen. Während diese Begrenzung den Verwaltern der PPP-Dialup-Server sehr entgegenkommt, ist das für die Anwender, die sich einwählen, häufig nicht der Fall. Wir -hatten uns bereits in Kapitel 6 Name-Server- und Resolver-Konfiguration, damit beschäftigt, wie Hostnamen an IPAdressen unter Verwendung einer Datenbank zugeordnet werden. Damit jemand eine Verbindung zu Ihrem Rechner herstellen kann, muß er entweder Ihre IP-Adresse oder den korrespondierenden Hostname kennen. Wenn Sie Anwender eines PPPServices sind, der Ihnen eine IP-Adresse dynamisch zuweist, wird Ihnen die Kenntnis dieser Adresse kaum nützen, wenn es kein Mittel gibt, die DNS-Daten zu aktualisieren, nachdem Sie eine IP-Adresse zugewiesen bekommen haben. Zwar existieren Systeme, die das können, jedoch gehen wir hier nicht näher darauf ein. Statt dessen betrachten wir ein zu bevorzugendes Verfahren, bei dem Sie ein und dieselbe IP-Adresse beim Verbindungsaufbau immer wieder verwenden können.1 Im obigen Beispiel haben wir pppd das System c3po anwählen lassen und einen IP-Link eingerichtet. Dabei wurden keinerlei Vorkehrungen getroffen, welche IP-Adressen an beiden Enden verwendet werden sollen. Statt dessen haben wir die Adresse von vlager als lokale IP-Adresse verwendet und c3po sich eine eigene auswählen lassen. pppd bietet dazu viele Alternativen an.

Um bestimmte Adressen anzufordern, müssen Sie pppd mit der folgenden Option aufrufen: local_addr:remote_addr

local_addr und remote_addr können dabei entweder in Dotted Quad Notation oder als Hostnamen angegeben werden.2 Diese Option bewirkt, daß pppd versucht die erste angegebene Adresse für die eigene Seite zu verwenden, während die zweite dem Gegenüber zugewiesen wird. Lehnt die Gegenseite eine der Adressen während der IPCP-Vereinbarungsphase ab, wird kein IP-Link aufgebaut.3 Wenn Sie einen Server anwählen und erwarten, daß Sie von ihm eine dynamische IP-Adresse erhalten, müssen Sie darauf achten, daß Ihr pppd-Dämon keinen Versuch unternimmt, eine IP-Adresse für sich auszuhandeln. Um das zu erreichen verwenden Sie die Option noipdefault und lassen local_addr leer. Die Option noipdefault verhindert, daß pppd versucht, die zum lokalen Hostnamen gehörende IP-Adresse zu verwenden. Wenn Sie auf jeden Fall die lokale Adresse verwenden wollen, aber bereit sind, die Remote-Adresse von der Gegenseite zu akzeptieren, lassen Sie den remote_addr-Teil leer. Um zum Beispiel vlager dazu zu bringen, die Adresse 130.83.4.27 anstelle seiner eigenen zu benutzen, fügen Sie der Kommandozeile die Option 130.83.4.27: hinzu. Für den umgekehrten Weg, nämlich um die Remote-Adresse fest vorzugeben und die lokale Adresse dynamisch auszuhandeln, lassen Sie das Feld local_addr leer. pppd benutzt dann standardmäßig die IP-Adresse Ihres Hostnamens.

Routen über einen PPP-Link Nachdem das Netzwerk-Interface eingerichtet ist, setzt pppd nur eine Hostroute zur Gegenseite. Wenn sich der entfernte Host in einem LAN befindet, wollen Sie möglicherweise auch in der Lage sein, mit Hosts “hinter” diesem Punkt zu kommunizieren. In diesem Fall muß eine Netzwerkroute eingerichtet werden. Sie haben bereits gesehen, daß Sie pppd mit der Option defaultroute anweisen können, die Default-Route einzurichten. Diese Option ist sehr nützlich, wenn der von Ihnen angewählte PPP-Server als Internet-Gateway fungiert. Der entgegengesetzte Fall, bei dem Ihr System als Gateway für einen einzelnen Host fungiert, ist relativ einfach zu erreichen. Nehmen wir zum Beispiel einen Angestellten der virtuellen Brauerei, dessen zu Hause stehende Maschine oneshot heißt, und nehmen wir an, daß wir vlager als PPP-Einwählknoten konfiguriert haben. Wenn wir vlager dabei so eingerichtet haben, daß er dynamisch eine IP-Adresse des Brauerei-Subnetzes vergibt, können wir pppd mit der Option proxyarp aufrufen, was einen sogenannten Proxy-ARP-Eintrag für oneshot installiert (Proxy bedeutet soviel wie Vollmacht). Auf diese Weise wird oneshot automatisch für alle Hosts in der Brauerei und Winzerei zugänglich gemacht. Leider sind die Dinge nicht immer so einfach. So wird zum Beispiel bei der Verbindung zweier lokaler Netzwerke zusätzlich eine bestimmte Netzwerkroute benötigt, weil beide Netzwerke ihre eigenen Default-Routen haben könnten. Würden beide Seiten den PPP-Link als Default-Route verwenden, würde das außerdem eine Schleife erzeugen, bei der Pakete mit unbekanntem Ziel so lange hin und her transportiert würden, bis deren “Time-to-live” überschritten wäre. Nehmen wir mal an, daß die virtuelle Brauerei eine Zweigstelle in einer anderen Stadt eröffnet. Dort wird ein eigenes Ethernet mit der IP-Netzwerknummer 172.16.3.0 betrieben, das als Subnetz 3 im Klasse-B-Netzwerk der Brauerei geführt wird. Die Filiale möchte sich an das Hauptnetz der Brauerei über PPP anschließen, um Kundendaten zu aktualisieren usw. Erneut dient vlager als Gateway für das Brauerei-Netz und bietet PPP-Dienste. Seine Gegenstelle im neuen Zweig verwendet den Namen vbourbon und die IP-Adresse 172.16.3.1. Eine Übersicht des Netzwerkes zeigt Abbildung 24.2 in Anhang 1 Beispielnetzwerk: Die virtuelle Brauerei. Sobald vbourbon die Verbindung zu vlager herstellt, legt es wie gewöhnlich eine Default-Route an, die auf vlager zeigt. Auf vlager haben wir jedoch nur die Punkt-zu-Punkt-Route zu vbourbon und müssen daher eine gesonderte Netzwerkroute für Subnetz 3 einrichten, die vbourbon als Gateway benutzt. Das könnten wir von Hand mit dem Befehl route erledigen, wenn die PPP-Verbindung aufgebaut ist. Allerdings ist das keine besonders praktische Lösung. Zum Glück können wir aber die Route automatisch konfigurieren, indem wir auf ein pppd-Feature zurückgreifen, das wir bisher noch nicht besprochen haben — den ip-up-Befehl. Dabei handelt es sich um ein Shell-Skript oder Programm im Verzeichnis /etc/ppp, das von pppd ausgeführt wird, nachdem das PPP-Interface konfiguriert wurde. Falls vorhanden, wird es mit den folgenden Parametern aufgerufen:

ip-up iface device speed local_addr remote_addr

Die folgende Tabelle enthält eine Übersicht über die Bedeutung der Argumente (die Nummern in der ersten Spalte repräsentieren die entsprechenden Argumente im Shell-Skript): Argument Name $1

iface

$2

device

$3

speed

$4

local_addr

$5

remote_addr

Zweck Das verwendete Netzwerk-Interface, z.B. ppp0. Der Pfadname der Gerätedatei des verwendeten seriellen Gerätes (/dev/tty, wenn stdin/stdout benutzt wird). Die Übertragungsgeschwindigkeit des seriellen Gerätes in Bits pro Sekunde. Die IP-Adresse der lokalen Seite der Verbindung in Dotted Quad Notation. Die IP-Adresse der Gegenstelle der Verbindung in Dotted Quad Notation.

In unserem Fall kann das ip-up-Skript folgendes Codefragment enthalten:4 #!/bin/sh case $5 in 172.16.3.1) 172.16.3.1;; ... esac exit 0

# das ist vbourbon

route add -net 172.16.3.0 gw

Auf gleiche Weise wird /etc/ppp/ip-down dazu verwendet, um alle Aktionen von ip-up wieder rückgängig zu machen, nachdem der PPP-Link wieder unterbrochen wurde. Dafür könnten wir in unserem /etc/ppp/ip-down-Skript einen route-Befehl angeben, der die Route, die wir im /etc/ppp/ip-up-Skript erzeugt haben, wieder entfernt. Nun, das Routing-Schema ist noch nicht vollständig. Wir haben zwar Einträge in die Routing-Tabellen der beiden Hosts aufgenommen, aber bis jetzt wissen die Hosts in beiden Netzwerken noch nichts über den PPP-Link. Das ist kein Problem, wenn alle Hosts in der Zweigstelle die Default-Route auf vbourbon zeigen lassen und alle Hosts der Brauerei standardmäßig auf vlager routen. Wenn dies nicht der Fall ist, ist die einzige Möglichkeit üblicherweise die Verwendung eines RoutingDämons wie gated. Nachdem die Netzwerkroute auf vlager eingerichtet ist, gibt der Routing-Dämon die neue Route an alle Hosts der angebundenen Subnetze weiter.

1.

Weitere Informationen über zwei Verfahren zur dynamischen Zuweisung von Hostadressen finden Sie unter http://www.dynip.com/ und http://www.justlinux.com/dynamic_dns.html.

2.

Die Verwendung von Hostnamen bei dieser Option hat Auswirkungen auf die CHAP-Authentifizierung. Mehr dazu finden Sie im Abschnitt Authentifizierung mit PPP später in diesem Kapitel.

3.

Mit den Optionen ipcp-accept-local und ipcp-accept-remote weisen Sie Ihren pppd-Dämon an, die lokale und entfernte IPAdressen, die von der Gegenstelle angeboten werden, zu akzeptieren, auch wenn Sie bereits Adressen in Ihrer Konfiguration angegeben haben. Sind die Optionen nicht konfiguriert, verweigert pppd jeden Versuch, die IP-Adressen auszuhandeln.

4.

Wollten wir auch Routen für andere Sites erzeugen lassen, wenn sie sich einwählen, würden wir weitere geeignete CaseAnweisungen für die in den ...-Stellen erwähnten Sites im Beispiel hinzufügen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Link-Kontrolloptionen LCP, das Link Control Protocol, haben wir ja bereits vorgestellt. Es wird benutzt, um die Charakteristika eines Links zu vereinbaren und den Link zu testen. Die beiden wichtigsten von LCP zu vereinbarenden Optionen sind die Maximum Receive Unit und die Asynchronous Control Character Map. Es gibt noch eine ganze Reihe weiterer LCPKonfigurationsoptionen, die aber bei weitem zu speziell sind, als daß wir sie hier besprechen könnten. Die Asynchronous Control Character Map, allgemein Async-Map genannt, wird bei asynchronen Links wie beispielsweise Telefonleitungen verwendet, um Steuerzeichen zu erkennen, die durch eine Zwei-Zeichen-Sequenz (Escape-Sequenz) ersetzt werden müssen. Dadurch wird verhindert, daß die für den Verbindungsaufbau zuständigen Geräte die Steuerzeichen fälschlicherweise selbst interpretieren. Beispielsweise möchten Sie die beim Software-Handshake verwendeten Zeichen XON und XOFF umgehen, weil einige fehlerhaft konfigurierte Modems sich beim Empfang von XOFF verabschieden. Ein weiterer Kandidat ist Strg-] (das telnet-Escape-Zeichen). PPP ermöglicht es Ihnen, solche Zeichen mit den ASCII-Codes 0 bis 31 besonders zu kennzeichnen, indem Sie sie in die AsyncMap aufnehmen. Die Async-Map ist eine 32 Bit breite hexadezimal beschriebene Bitmap, bei der das niederwertigste Bit dem ASCII-Zeichen NULL und das höchstwertige Bit dem ASCII-Wert 31 entspricht. Diese 32

ASCII-Zeichen sind die Steuerzeichen. Ist ein Bit in der Bitmap gesetzt, bedeutet das, daß das entsprechende Zeichen erst umgewandelt werden muß, bevor es über den Link transportiert werden kann. Um Ihrer Seite mitzuteilen, daß nicht alle sondern nur wenige Steuerzeichen umgewandelt werden müssen, können Sie pppd mit der Option asyncmap eine neue Async-Map übergeben. Wenn beispielsweise nur die Steuerzeichen ^S und ^Q (ASCII 17 und 19 werden häufig als XON und XOFF verwendet) umgewandelt werden müssen, können Sie die folgende Option nutzen: asyncmap 0x000A0000

Wenn Sie bereits binäre Daten nach hexadezimal umwandeln können, ist die Konvertierung auch hier recht einfach. Stellen Sie sich eine beliebige 32-Bit-Kette vor. Das Bit ganz rechts entspricht ASCII 00 (NULL), das Bit ganz links dem ASCII-Dezimalwert 32. Setzen Sie einfach diejenigen Bits auf eins, die den ASCII-Zeichen entsprechen, die Sie konvertieren wollen, und alle anderen Bits auf null. Um diese Bit-Kette dem Befehl pppd in Form einer Hexadezimalzahl zu übergeben, bilden Sie einfach Vierergruppen der 32-Bit-Zahl und konvertieren Sie diese jeweils in eine Hexadezimalziffer. Sie erhalten schließlich eine Folge aus acht Hexadezimalzeichen. Schreiben Sie sie einfach hintereinander auf, und stellen Sie dieser Zahl ein “0x” voran — das war's. Am Anfang ist die Async-Map auf 0xffffffff gesetzt, so daß alle Steuerzeichen durch EscapeSequenzen ersetzt werden. Das ist eine sichere Grundeinstellung, aber viel mehr, als Sie vielleicht wollen. Jedes Zeichen, das in der Async-Map vorkommt, wird als Folge von zwei Zeichen über die Verbindung übertragen. Das geht natürlich zu Lasten der Leitungskapazität, woraus sich eine geringere Performance ergibt. Für die meisten Anwendungsfälle reicht eine Async-Map von 0x0 allerdings völlig aus. Es werden dann überhaupt keine Escape-Sequenzen erzeugt. Mit der Maximum Receive Unit (MRU) signalisieren wir die maximale Größe eines HDLC-Frames, den wir zu empfangen bereit sind. Obwohl Sie das an den MTU-Wert (Maximum Transfer Unit) erinnern könnte, haben diese beiden doch sehr wenig gemeinsam. Die MTU ist ein Parameter der Kernel-Netzwerkeinheit und beschreibt die maximale Größe, die das Interface verarbeiten kann. Die MRU ist eher eine Empfehlung an die andere Seite, keine Frames zu generieren, die länger als die MRU sind. Das Interface muß aber dennoch in der Lage sein, Frames mit einer Größe von bis zu 1500 Byte zu empfangen. Die Wahl einer MRU ist daher also nicht so sehr eine Frage dessen, was ein Link zu übertragen in der Lage ist, sondern eher, wie der beste Durchsatz zu erzielen ist. Wenn Sie mit interaktiven Anwendungen arbeiten wollen, sollten Sie die MRU auf einen so niedrigen Wert wie 296 setzen, damit gelegentliche größere Pakete (sagen wir von einer FTP-Session) Ihren Cursor nicht zum “ruckeln” bringen. Sie weisen pppd an, eine MRU von 296 zu verwenden, indem Sie die Option mru 296 auf der Kommandozeile übergeben. Kleine MRUs sind jedoch nur sinnvoll, wenn die VJ-HeaderKomprimierung zur Verfügung steht (sie ist per Standardeinstellung aktiviert), da Sie ansonsten viel Bandbreite dafür verschwenden, nur um die IP-Header aller Datagramme zu übertragen.

pppd versteht auch eine ganze Reihe von LCP-Optionen, mit denen Sie das gesamte Verhalten der Verhandlungsphase konfigurieren können, wozu beispielsweise die maximale Anzahl von Konfigurationsanforderungen gehört, die ausgetauscht werden können, bevor die Verbindung beendet wird. Solange Sie nicht genau wissen, was Sie da tun, sollten Sie aber die Finger von diesen Optionen lassen. Schließlich gibt es noch zwei Optionen, die sich mit LCP-Echo-Nachrichten beschäftigen. PPP definiert zwei besondere Nachrichten: Echo Request und Echo Response. pppd verwendet diese, um zu prüfen, ob der Link noch funktioniert. Sie aktivieren diese Option durch lcp-echo-interval und die Angabe einer Zeit in Sekunden. Werden vom entfernten Host innerhalb dieser Zeitspanne keine Frames empfangen, erzeugt pppd einen Echo Request und erwartet, daß die Gegenseite mit einer Echo Response antwortet. Erfolgt von der Gegenstelle keine Antwort, wird die Verbindung nach einer bestimmten Anzahl von Versuchen unterbrochen. Diese Anzahl können Sie mit der Option lcp-echofailure bestimmen. Per Standardeinstellung ist dieses Feature deaktiviert.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Allgemeine Sicherheitsaspekte Ein fehlerhaft konfigurierter PPP-Dämon kann eine vernichtende Sicherheitslücke sein. Im schlimmsten Fall kann es so sein, als ob sich jeder direkt an Ihr Ethernet anschließen könnte (und das ist sehr schlecht). In diesem Abschnitt wollen wir einige Maßnahmen erläutern, die Ihre PPP-Konfiguration sicher machen sollen. Hinweis Ein Problem mit pppd ist, daß es zur Konfiguration des Netz-Interfaces und der Routing-Tabelle rootPrivilegien benötigt. Üblicherweise lösen Sie dieses Problem, indem Sie pppd mit Setuid root ausführen. Jedoch ermöglicht es pppd dem Benutzer, verschiedene sicherheitsrelevante Optionen zu setzen.

Um sich vor Angriffen zu schützen, die ein Benutzer durch Manipulation von pppd-Optionen starten könnte, wird empfohlen, eine Reihe von Voreinstellungen in der globalen Datei /etc/ppp/options einzutragen. Ein Beispiel dafür finden Sie im Abschnitt Arbeiten mit Optionsdateien in diesem Kapitel. Einige dieser Optionen, wie die zur Authentifizierung, können dann vom Benutzer nicht überschrieben werden, was eine vernünftige Sicherung gegen Manipulationen darstellt. Eine wichtige Schutzoption ist connect. Wann immer Sie beabsichtigen, Nicht-Root-Benutzern die Ausführung von pppd zu gestatten, um eine Internetverbindung zu etablieren, sollten Sie immer die Optionen connect und noauth in der globalen Datei /etc/ppp/options eintragen. Wenn Sie das nicht machen, können die Anwender beliebige Befehle mit root-Privilegien ausführen, indem sie sie als connect-Befehl in der pppd-Zeile oder in ihrer persönlichen Optionsdatei angeben. Eine weitere gute Idee ist es, den Kreis der Benutzer, die pppd ausführen dürfen, einzuschränken. Dazu

erzeugen Sie in /etc/group eine neue Gruppe und tragen darin nur diejenigen Benutzer ein, denen Sie die Ausführung des PPP-Dämons gestatten wollen. Sie sollten dann die Eigentumsrechte des pppd-Dämons auf diese Gruppe einstellen und die Ausführungsrechte für die ganze Welt entfernen. Angenommen, Ihre Gruppe heißt dialout. Dann können Sie wie folgt vorgehen: # chown root /usr/sbin/pppd # chgrp dialout /usr/sbin/pppd # chmod 4750 /usr/sbin/pppd

Natürlich müssen Sie sich auch selbst vor den Systemen schützen, mit denen Sie über PPP kommunizieren. Um zu verhindern, daß sich Hosts als jemand anderes ausgeben, sollten Sie immer irgendeine Form der Authentifizierung von der Gegenseite verlangen. Darüber hinaus sollten Sie es fremden Hosts nicht erlauben, eine beliebige, von ihnen gewählte IP-Adresse zu verwenden, sondern sie auf ein paar wenige einschränken. Der folgende Abschnitt befaßt sich ausführlich mit diesen Themen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Authentifizierung mit PPP Mit PPP kann jedes System seine Gegenseite auffordern, sich zu authentifizieren. Dazu kann eins von zwei Authentifizierungsprotokollen verwendet werden. Dies ist zum einen das Password Authentication Protocol (PAP) und zum anderen das Challenge Handshake Authentication Protocol (CHAP). Sobald eine Verbindung steht, kann jede Seite die andere auffordern, sich zu authentifizieren, gleichgültig, ob sie die rufende oder die angerufene Seite ist. Im folgenden reden wir von “Client” und “Server”, um zwischen dem sich authentifizierenden System und dem Authentifizierer zu unterscheiden. Ein PPPDämon kann von seinem Gegenüber die Authentifizierung anfordern, indem er einfach eine weitere LCPKonfigurationsanforderung sendet, die das gewünschte Authentifizierungsprotokoll angibt.

Vergleich von PAP und CHAP Das von vielen Internet-Service-Providern angebotene PAP arbeitet grundsätzlich auf dieselbe Weise wie die normale LoginProzedur. Der Client authentifiziert sich, indem er einen Benutzernamen und ein (optional verschlüsseltes) Paßwort an den Server schickt, die der Server dann beide mit seiner Secrets-Datenbank vergleicht.1 Diese Technik ist durch Lauscher angreifbar, die an der seriellen Leitung horchen. Auch Angriffe nach dem Trial-and-Error-Verfahren sind hier möglich. CHAP hat diese Defizite nicht. Bei CHAP sendet der Authentifizierer (d.h. der Server) einen zufällig erzeugten “Anforderungsstring” zusammen mit seinem Hostnamen an den Client. Der Client verwendet den Hostnamen, um das entsprechende “Secret” nachzusehen, kombiniert es mit der Anforderung und verschlüsselt den String mit Hilfe einer EinwegHashfunktion. Das Ergebnis wird zusammen mit dem Hostnamen des Client an den Server zurückgeschickt. Der Server führt nun dieselbe Berechnung durch und akzeptiert den Client, wenn er zu demselben Ergebnis kommt. Eine weitere Eigenschaft von CHAP besteht darin, daß es die Authentifizierung durch den Client nicht nur beim Start abfragt, sondern solche Anforderungen in regelmäßigen Zeitabständen sendet, um sicherzustellen, daß der Client nicht durch einen Eindringling ersetzt wurde, der beispielsweise nur die Telefonleitung umgeschaltet hat, oder daß nicht ein ModemKonfigurationsfehler vorliegt, wodurch der PPP-Dämon nicht mitbekommt, daß die bestehende Verbindung abgebrochen wurde und sich inzwischen ein anderer Benutzer eingewählt hat. pppd speichert die geheimen Schlüssel für CHAP und PAP in zwei separaten Dateien namens /etc/ppp/chap-secrets und /etc/ppp/pap-secrets. Durch Eintragen eines entfernten Hosts in die eine oder andere Datei können Sie exakt bestimmen, ob CHAP oder PAP bei der Authentifizierung verwendet wird.

pppd ist so voreingestellt, daß es von der Gegenseite keine Authentifizierung benötigt; fordert die Gegenstelle eine Authentizierung an, wird diese aber durchgeführt. Weil CHAP wesentlich strenger ist als PAP, versucht pppd, wann immer möglich, auf das erste Verfahren zurückzugreifen. Wird dies von der Gegenseite nicht unterstützt, oder kann pppd kein CHAPSecret für den anderen Rechner in seiner Datei chap-secrets finden, wechselt es zu PAP. Kann auch kein PAP-Secret für die andere Seite gefunden werden, wird die Authentifizierung vollständig abgebrochen und als Konsequenz daraus schließlich die ganze Verbindung unterbrochen. Dieses Verhalten kann auf verschiedene Weise angepaßt werden. Wird beispielsweise die Option auth verwendet, verlangt pppd von der Gegenseite eine Authentifizierung. pppd kann dabei entweder auf CHAP oder auf PAP zurückgreifen, solange das Secret der anderen Seite in der CHAP- oder PAP-Datenbank gefunden wird. Es gibt andere Optionen, mit denen auf ein bestimmtes Authentifizierungsprotokoll zurückgegriffen wird. Wir gehen an dieser Stelle aber nicht auf sie ein. Wenn alle Systeme, mit denen Sie sich über PPP unterhalten, bereit sind, sich Ihnen gegenüber zu authentifizieren, sollten Sie die Option auth in die globale Datei /etc/ppp/options aufnehmen und Paßwörter für alle Systeme in die Datei chap-secrets eintragen. Wird CHAP von einem System nicht unterstützt, fügen Sie den Eintrag in die Datei pap-secrets ein. Auf diese Weise stellen Sie sicher, daß sich keine unautorisierten Systeme in Ihren Host einklinken. Die nächsten zwei Abschnitte behandeln die beiden PPP-Secrets-Dateien pap-secrets und chap-secrets. Diese Dateien sind im Verzeichnis /etc/ppp zu finden und enthalten Dreiergruppen aus Clients, Servern und Paßwörtern, denen optional eine Liste mit IP-Adressen folgt. Die Interpretation der Client- und Serverfelder ist bei CHAP und PAP unterschiedlich und hängt auch davon ab, ob wir uns bei der Gegenseite ausweisen müssen oder ob wir den Server auffordern, sich bei uns zu authentifizieren.

Die CHAP-Secrets-Datei Wenn pppd sich über CHAP einem Server gegenüber ausweisen muß, durchsucht es die Datei chap-secrets nach einem Eintrag, bei dem das Client-Feld mit dem lokalen Hostnamen und das Serverfeld mit dem Hostnamen des Servers übereinstimmt, der bei der CHAP-Anforderung übertragen wurde. Muß sich die Gegenseite authentifizieren, sind die Rollen vertauscht: pppd sucht dann nach einem Eintrag, bei dem das Client-Feld mit dem Hostnamen des entfernten Rechners (übertragen während der CHAP-Antwort des Client) und das Serverfeld mit dem lokalen Hostnamen übereinstimmt. Nachfolgend ein einfaches Beispiel einer chap-secrets-Datei für vlager:2 # CHAP secrets für vlager.vbrew.com # # Client Server Secret Adressen #--------------------------------------------------------------------- vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com c3po.lucas.com vlager.vbrew.com "arttoo! arttoo!" c3po.lucas.com * vlager.vbrew.com "TuXdrinksVicBitter" pub.vbrew.com

Wenn vlager eine PPP-Verbindung zu c3po aufbaut, fordert c3po vlager auf, sich zu authentifizieren, indem es eine CHAPAnforderung überträgt. pppd auf vlager durchsucht dann chap-secrets nach einem Eintrag, bei dem das Client-Feld vlager.vbrew.com und das Serverfeld c3po.lucas.com enthält, und findet dabei die erste oben aufgeführte Zeile.3 Daraufhin wird eine CHAP-Antwort aus dem Anforderungsstring und dem Secret (Use The Source Luke) erzeugt und an c3po geschickt. Zur selben Zeit baut pppd eine CHAP-Anforderung für c3po auf, die einen eindeutigen Anforderungsstring und den voll qualifizierten Hostnamen vlager.vbrew.com enthält. c3po erzeugt die entsprechende CHAP-Antwort auf die oben beschriebene Art und Weise und gibt diese an vlager zurück. pppd filtert sich nun den Hostnamen des Client (c3po.lucas.com) aus der Antwort heraus und durchsucht die Datei chap-secrets nach einem Eintrag, bei dem c3po als Client und vlager als Server vorhanden sind. Das ist im zweiten Eintrag unserer Beispieldatei der Fall, und pppd kombiniert die CHAP-Anforderung und das Secret arttoo! arttoo!, verschlüsselt sie und vergleicht das Ergebnis mit der CHAP-Antwort von c3po. Das vierte Feld ist optional und enthält eine Liste der IP-Adressen, die für den im ersten Feld aufgeführten Client akzeptabel sind. Die Adressen können in Dotted Quad Notation oder als Hostnamen angegeben werden, die mit Hilfe des Resolvers aufgelöst werden. Fordert beispielsweise c3po eine bestimmte Adresse während der IPCP-Vereinbarung an, die nicht in dieser Liste steht, wird diese Anforderung abgelehnt, und IPCP wird beendet. Bei unserer oben aufgeführten Beispieldatei kann c3po also nur seine eigene IP-Adresse verwenden. Ist das Adreßfeld leer, ist jede Adresse erlaubt. Wird als Wert “-” eingetragen, wird IP für diesen Client gar nicht erst initialisiert.

Die dritte Zeile in unserer chap-secrets-Datei ermöglicht es jedem Host, einen PPP-Link mit vlager aufzubauen, weil das Sternchen (*) als Platzhalter für jeden beliebigen Hostnamen steht. Die einzige Voraussetzung ist, daß er das Secret kennt und die Adresse von pub.vbrew.com verwendet. Einträge mit solchen Platzhaltern (Wildcards) können an jeder beliebigen Stelle in der Secrets-Datei stehen, weil pppd immer den Eintrag verwendet, der am ehesten zu einem Server/Client-Paar paßt. pppd benötigt möglicherweise bei der Bildung von Hostnamen etwas Hilfe. Wie bereits erwähnt, ist der Name des anderen Host immer im CHAP-Anforderungs- oder -Antwortpaket enthalten. Der lokale Hostname wird standardmäßig durch den Aufruf der Funktion gethostname(2) ermittelt. Wenn Sie den Systemnamen auf Ihren unqualifizierten Hostnamen gesetzt haben, müssen Sie pppd mit der Option domain zusätzlich noch den Domainnamen bekanntgeben: # pppd … domain vbrew.com

Das hängt den Domainnamen der Brauerei bei allen authentifizierungsbezogenen Aktivitäten an vlager an. Andere Optionen, mit denen Sie den lokalen Hostnamen für pppd anpassen können, sind usehostname und name. Wenn Sie die lokale IPAdresse mit Hilfe von local:remote auf der Kommandozeile angeben und local einen Namen anstelle einer Dotted Quad enthält, nutzt pppd diesen als lokalen Hostnamen.

Die PAP-Secrets-Datei Die Secrets-Datei für PAP ist der von CHAP sehr ähnlich. Die ersten beiden Felder enthalten einen Benutzer- und einen Servernamen. Das dritte Feld enthält das PAP-Secret. Fordert die Gegenseite die Authentifizierung an, verwendet pppd den Eintrag, bei dem das Serverfeld mit dem lokalen Hostnamen und das Benutzerfeld mit dem in der Anforderung übertragenen Benutzernamen übereinstimmt. Wenn es sich selbst authentifizieren muß, wählt sich pppd das Secret aus dem Eintrag aus, das ein Feld mit dem lokalen Benutzernamen und ein Serverfeld mit dem Namen des entfernten Hosts enthält. Eine PAP-Secrets-Datei könnte beispielsweise wie folgt aussehen: # /etc/ppp/pap-secrets # # Benutzer Server c3po cresspahl vlager.vbrew.com c3po c3po.lucas.com

Secret vlager

Adressen vlager-pap DonaldGNUth

Die erste Zeile wird von uns zur Authentifizierung verwendet, wenn wir mit c3po kommunizieren. Die zweite Zeile beschreibt, wie ein Benutzer namens c3po sich uns gegenüber zu authentifizieren hat. Der Name vlager-pap in der ersten Spalte ist der Benutzername, den wir an c3po senden. Per Standardeinstellung wählt pppd den lokalen Hostnamen als Benutzernamen. Sie können aber auch einen anderen Namen bestimmen, indem Sie ihn mit der Option user übergeben. Wenn ein Eintrag aus der Datei pap-secrets herausgesucht werden soll, um die Authentifizierung mit der Gegenseite durchzuführen, muß pppd den Namen des anderen Hosts kennen. Weil es keine Möglichkeit hat, ihn herauszufinden, müssen Sie ihn mit Hilfe der Option remotename auf der Kommandozeile mit angeben. Soll beispielsweise der obige Eintrag für die Authentifizierung mit c3po verwendet werden, müssen wir dem pppd-Befehl folgende Option hinzufügen: # pppd ... remotename c3po user vlager-pap

Im vierten Feld (und in allen folgenden Feldern) der PAP-Secrets-Datei können Sie, genau wie bei der CHAP-Secrets-Datei auch, die IP-Adressen angeben, die für einen bestimmten Host erlaubt sind. Die Gegenstelle darf dann nur Adressen aus dieser Liste anfordern. In der Beispieldatei weist der Eintrag, den c3po für die Einwahl benutzt — die Zeile, in der c3po der Client ist —, c3po an, nur seine eigene IP-Adresse und keine andere zu benutzen. Denken Sie daran, daß PAP eine eher schwache Authentifizierungsmethode ist und daß Sie, wenn möglich, immer auf CHAP zurückgreifen sollten. Aus diesem Grund gehen wir hier nicht detaillierter auf PAP ein. Wenn Sie mehr über PAP erfahren wollen, finden Sie weitere Informationen in der pppd(8)-Manpage.

1.

“Secrets” ist lediglich die PPP-Bezeichnung für Paßwörter. PPP-Secrets können länger sein als die Login-Paßwörter bei Linux.

2.

Die Anführungszeichen sind nicht Teil des Paßworts, sondern dienen nur dazu, die Leerzeichen innerhalb des Paßworts zu schützen.

3.

Der Hostname stammt aus der CHAP-Anforderung.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Debuggen Ihres PPP-Setups Standardmäßig reicht pppd Warnungen und Fehlermeldungen immer an die daemon-Kanal von syslog weiter. Um diese Informationen in eine Datei oder auf eine Konsole umzuleiten, müssen Sie einen Eintrag in der Datei syslog.conf hinzufügen. Andernfalls verwirft syslog sie einfach. Der folgende Eintrag führt zur Umleitung aller Nachrichten in die Datei /var/log/ppp-log: daemon.*

/var/log/ppp-log

Wann immer Ihre PPP-Konfiguration nicht richtig funktioniert, sollten Sie immer einen Blick in diese Logdatei werfen. Helfen Ihnen die Logmeldungen nicht weiter, erhalten Sie weitere DebuggingAusgaben durch Anwendung der Option debug. In diesem Fall sorgt pppd dafür, daß der Inhalt sämtlicher Kontrollpakete durch syslog protokolliert wird die Logdatei ein, die von syslog gesendet oder empfangen werden. All diese Nachrichten werden dann an die daemon-Kanal weitergeleitet. Schließlich existiert für die Problemanalyse noch eine besonders drastische Methode, nämlich die Aktivierung von Debugging-Meldungen vom Kernel. Dazu geben Sie für pppd die Option kdebug an, zusammen mit einer Zahl, die die Summe folgender Werte ist: 1 für allgemeine DebuggingMeldungen, 2 zur Ausgabe aller eingehenden HDLC-Frames und 4 für die Ausgabe aller ausgehenden HDLC-Frames. Um die Kernel-Debugging-Meldungen abzufangen, starten Sie entweder einen syslogd-Dämon, der die Datei /proc/kmsg ausliest, oder den klogd-Dämon. Beide leiten die

Debugging-Meldungen des Kernels an die syslog-kernel-Kanal weiter.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Erweiterte PPP-Konfigurationen Zwar ist die Konfiguration von PPP zur Einwahl in Netzwerke wie das Internet die wohl häufigste Anwendung, jedoch gibt es auch Benutzer, die weiterreichende Anforderungen haben. In diesem Abschnitt behandeln wir einige dieser erweiterten Konfigurationen, die mit PPP unter Linux möglich sind.

PPP-Server Bei der Ausführung von pppd als Server steht man eigentlich nur vor der Aufgabe, ein serielles tty-Gerät so zu konfigurieren, daß es pppd mit angemessenen Optionen startet, sobald eine eingehende Datenabfrage vorliegt. Eine Möglichkeit, dies zu erreichen, besteht in der Einrichtung eines speziellen Accounts, z.B. ppp, dem ein Skript oder ein Programm als Login-Shell zugeordnet wird, das pppd mit diesen Optionen aufruft. Wenn Sie die Unterstützung von PAP oder CHAP beabsichtigen, können Sie alternativ das Programm mgetty verwenden, um Ihr Modem zu unterstützen und dessen “/AutoPPP/”- -Feature zu nutzen. Um einen Server aufzubauen, der die Login-Methode verwendet, fügen Sie etwa folgende Zeile in Ihre /etc/passwd-Datei ein:1 ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin

Unterstützt Ihr System Shadow-Paßwörter, müssen Sie auch einen Eintrag in die /etc/shadow-Datei hinzufügen: ppp:!:10913:0:99999:7:::

Natürlich hängen die verwendete UID und GID sowohl vom Benutzer ab, der Eigentümer einer Verbindung sein soll und davon, wie Sie ihn angelegt haben. Außerdem müssen Sie mit dem Befehl passwd noch das entsprechende Paßwort für diesen Account zuweisen. Das ppplogin-Skript könnte etwa wie folgt aussehen: #!/bin/sh # ppplogin - Skript zum Start von pppd beim Login mesg n stty -echo exec pppd -detach silent modem crtscts

Der Befehl mesg verhindert, daß andere Benutzer an den tty schreiben können (beispielsweise mit write). Der Befehl stty schaltet das Echo aus. Das ist notwendig, weil sonst alle von der Gegenseite übertragenen Daten nochmal zurückgeschickt würden. Die wichtigste der oben angegebenen pppd-Optionen ist –detach, weil sie verhindert, daß sich pppd vom kontrollierenden tty abtrennt. Wenn Sie diese Option nicht angeben, würde es in den Hintergrund treten und das Shell-Skript beenden. Das würde wiederum dazu führen, daß die serielle Leitung abgebaut würde und somit die Verbindung beendet wäre. Mit der silent-Option weisen Sie pppd an zu warten, bis ein Paket vom anrufenden System empfangen wurde, bevor Sie mit dem Senden beginnen. Auf diese Weise werden Übertragungs-Timeouts verhindert, die auftreten können, wenn das anrufende System seinen PPP-Client nur langsam hochfährt. Mit der modem-Option übernimmt pppd die Kontrolle der Modem-Steuerungsleitungen auf dem seriellen Port. Diese Option sollten Sie immer aktivieren, wenn Sie pppd mit einem Modem betreiben. Die Option crtscts schaltet den Hardware-Handshake ein. Außer diesen Optionen sollten Sie auch irgendeine Form der Authentifizierung aktivieren. Dazu können Sie die Option auch in der pppd-Kommandozeile oder in der globalen Optionsdatei setzen. Die Manpage beschreibt auch spezifischere Optionen, mit denen Sie bestimmte Authentifizierungs-Protokolle ein- und ausschalten können. Wenn Sie mgetty benutzen wollen, brauchen Sie es lediglich so zu konfigurieren, daß es das an Ihr Modem angeschlossene serielle Device benutzt (Details finden Sie im Abschnitt Konfiguration des mgetty-Dämons). Dann müssen Sie nur noch pppd mit angemessenen Optionen in der Datei options auf PAP- oder CHAP-Authentifizierung einstellen und schließlich noch einen Abschnitt in Ihre /etc/mgetty/login.config-Datei eintragen, der etwa folgendermaßen aussieht: # Konfiguration von mgetty zur automatischen Erkennung eingehender PPP-Anrufe # und Ausführung des pppd-Dämons zur Bearbeitung der Verbindung. # /AutoPPP/ ppp /usr/sbin/pppd auth -chap +pap login

Das erste Feld enthält eine “magische” Option zur Erkennung, ob ein eingehender Anruf vom Typ PPP ist. Bei diesem String müssen Sie genau auf die Schreibweise achten — Groß- und Kleinschreibung sind hier wichtig. Die dritte Spalte enthält den Benutzernamen, der immer in den who-Listings erscheint, wenn sich jemand eingeloggt hat. Der Rest der Zeile enthält den Programmaufruf. In unserem Beispiel haben wir sichergestellt, daß PAP-Authentifizierung erforderlich ist, CHAP abgeschaltet ist und daß die /etc/passwd-Datei des Systems zur Benutzer-Authentifizierung hinzugezogen werden soll. Das ist vielleicht in etwa das, was Sie möchten. Denken Sie daran, Sie können die Optionen entweder in der options-Datei oder auf der Kommandozeile angeben. Hier folgt eine kleine Checkliste, die Sie der Reihe nach abhaken sollten, wenn Sie Ihre Maschine für PPP-Einwahl fit machen wollen. Stellen Sie sicher, daß jeder Schritt korrekt funktioniert, bevor Sie mit dem nächsten Schritt fortfahren: 1. Konfigurieren Sie Ihr Modem auf automatische Antwort. Bei Hayes-kompatiblen Modems erreichen Sie das mit einem Befehl wie ATS0=3. Wenn Sie den mgetty-Dämon benutzen wollen, ist dieser Schritt nicht notwendig. 2. Konfigurieren Sie das serielle Device mit einem getty-artigen Befehl für die Beantwortung eingehender Anrufe. Eine geläufige getty-Variante ist mgetty. 3. Überlegen Sie sich die Authentifizierungsmethoden. Werden sich Ihre Anrufer mittels PAP, CHAP oder SystemLogins ausweisen? 4. Konfigurieren Sie pppd als Server, wie in diesem Abschnitt beschrieben. 5. Denken Sie über Routing nach. Müssen Sie vielleicht Ihren Anrufern eine Netzwerkroute bereitstellen? Routing kann mit dem ip-up-Skript durchgeführt werden.

Einwahl nach Bedarf Wann immer IP-Datenverkehr über die Verbindung stattfindet, bewirkt eine Einwahl nach Bedarf (demand dialing), daß das an Ihr Telefon angeschlossene Modem automatisch eine Einwahl durchführt und eine Verbindung zum entfernten Host aufbaut. Ein solches Einwahlverfahren ist besonders nützlich für Anwendungen, bei denen Sie keine dauerhafte Telefonverbindung zu Ihrem Internet-Provider wünschen. Wenn Sie zum Beispiel für zeitbegrenzte Ortsgespräche Geld

bezahlen müssen, wäre es unter Umständen günstiger, wenn Sie nur dann eine Verbindung zu Ihrem Internet-Provider aufbauen, wenn sie gerade benötigt wird, und die meiste Zeit keine Verbindung besteht. Traditionelle Linux-Lösungen verwendeten dafür den Befehl diald. Er funktioniert zwar gut, war jedoch schwierig zu konfigurieren. Die Versionen 2.3.0 und folgende des PPP-Dämons haben bereits eingebaute Unterstützung für Einwahl nach Bedarf und sind sehr leicht zu konfigurieren. Dafür brauchen Sie allerdings einen modernen Kernel. Alle Kernel ab Version 2.0 sind dafür bestens geeignet. Um pppd für Einwahl nach Bedarf zu konfigurieren, brauchen Sie lediglich einige Optionen in Ihrer options-Datei oder in der pppd-Befehlszeile anzugeben. Die folgende Tabelle enthält eine Zusammenfassung der Optionen für Einwahl nach Bedarf: Option

demand

Erläuterung Diese Option gibt an, daß die PPP-Verbindung mit Einwahl nach Bedarf aufgebaut werden soll. Das PPP-Netzwerk-Device ist bereits erzeugt, der connect-Befehl wird jedoch nicht eher ausgeführt, bis ein Datagramm durch den lokalen Host verschickt wird. Diese Option ist unbedingt erforderlich, damit Einwahl nach Bedarf funktioniert.

Mit dieser Option geben Sie an, welche Datenpakete als aktiver Datenverkehr aufgefaßt werden sollen. Jeder Datenverkehr, der die angegebene Regel erfüllt, startet den LeerlaufZeitgeber (demand idle timer) neu und stellt damit sicher, daß pppd wieder eine active-filter Ausdruck Wartepause einlegt, bevor es die Verbindung kappt. Die Filtersyntax wurde dem Befehl tcpdump entnommen. Der standardmäßig vorgegebene Filter paßt zu allen Datagrammen.

holdoff n

idle n

Diese Option gibt die minimale Zeitspanne in Sekunden an, die verstreichen soll, bevor eine beendete Verbindung wiedereröffnet wird. Falls die Verbindung abbricht, während pppd meint, sie wäre immer noch aktiv, wird sie erneut aufgebaut, sobald die Wartezeit abgelaufen ist. Diese Wartezeit wirkt sich aber nicht auf Verbindungen aus, die nach einer Leerlaufzeit (idle timeout) neu aufgebaut werden. Ist diese Option konfiguriert, unterbricht pppd eine Verbindung, sobald diese Wartezeit verstrichen ist. Die Wartezeit wird in Sekunden angegeben. Jedes neue aktive Datenpaket setzt den Zeitgeber zurück.

Eine einfache Konfiguration für Einwahl nach Bedarf könnte daher etwa so aussehen: demand holdoff 60 idle 180

Diese Konfiguration aktiviert Einwahl nach Bedarf, wartet 60 Sekunden, bevor eine unterbrochene Verbindung wiederaufgebaut wird, und beendet die Verbindung, wenn 180 Sekunden ohne irgendwelche aktiven Datentransfers über diese Verbindung verstrichen sind.

Ständige Einwahl Ständige Einwahl ist das, was Anwender benutzen, wenn sie eine permanente Netzwerkanbindung haben wollen. Zwischen Einwahl nach Bedarf und dauerhafter Einwahl besteht ein feiner Unterschied. Bei dauerhafter Einwahl wird die Verbindung automatisch aufgebaut, sobald der PPP-Dämon gestartet ist. Der dauerhafte Aspekt an der Verbindung kommt immer dann zur Geltung, wenn eine Telefonverbindung unterbrochen wird. Ständige Einwahl stellt sicher, daß die Verbindung immer verfügbar ist, indem eine unterbrochene Verbindung automatisch wieder aufgebaut wird. Vielleicht gehören Sie zu den Glücklichen, die nicht für ihre Telefonanrufe zahlen müssen, da sie kostenlose Ortsgespräche sind oder von Ihrem Arbeitgeber bezahlt werden. In einer solchen Situation ist dauerhafte Einwahl extrem nützlich. Wenn Sie Ihre Telefonanrufe allerdings selbst bezahlen müssen, sollten Sie vorsichtiger sein. Bezahlen Sie Ihre Telefonanrufe auf

Zeitbasis, ist dauerhafte Einwahl ziemlich sicher nicht das, was Sie wollen, es sei denn, Sie benutzen Ihre Verbindung nahezu rund um die Uhr. Wenn Sie für jeden Anruf einzeln bezahlen müssen, die Anrufe aber nicht auf Zeitbasis abgerechnet werden, müssen Sie Situationen vermeiden, die das Modem zu endlosen Wahlwiederholungen anregen. Der pppd-Dämon bietet eine Option, die Ihnen dabei hilft, die Auswirkungen dieses Problems zu reduzieren. Um dauerhafte Einwahl zu erreichen, müssen Sie die Option persist in einer Ihrer pppd-Optionsdateien angeben. Diese Option reicht völlig aus, um pppd dazu zu bringen, jedesmal den in der Option connect angegebenen Befehl auszuführen, um eine unterbrochene Verbindung wieder aufzubauen. Wenn Sie darüber besorgt sind, daß Ihr Modem die Wahlwiederholungen zu schnell durchführen könnte (bedingt durch einen Fehler im Modem oder beim Server am anderen Ende der Verbindung), steht Ihnen die Option holdoff zur Verfügung. Mit ihr können Sie die Mindestzeit angeben, die vor jeder neuen Verbindungsaufnahme verstreichen soll. Diese Option befreit Sie zwar nicht davon, für vergebliche Telefonanrufe bezahlen zu müssen, die durch irgendeinen Fehler zustandekommen, aber sie hilft Ihnen zumindest, die Auswirkungen des Fehlers zu reduzieren. Eine typische Konfiguration mit Optionen für dauerhafte Einwahl sieht etwa folgendermaßen aus: persist holdoff 600

Die holdoff-Zeit wird in Sekunden angegeben. In unserem Beispiel wartet pppd ganze fünf Minuten, bevor eine unterbrochene Verbindung neu aufgebaut wird. Es ist möglich, dauerhafte Einwahl mit Einwahl nach Bedarf zu kombinieren. Mit idle wird die Verbindung nach einer gewissen Zeit der Untätigkeit unterbrochen. Wir glauben zwar nicht, daß viele Benutzer dies interessant finden, aber dieses Szenario wird kurz in der Manpage von pppd beschrieben.

1.

Die Hilfsmittel useradd oder adduser vereinfachen diese Aufgabe (sofern sie verfügbar sind).

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 9 TCP/IP-Firewall

Das Thema Sicherheit wird für Firmen wie für einzelne Personen immer wichtiger. Das Internet bietet Ihnen ein mächtiges Werkzeug, mit dem Sie Informationen über sich an andere weitergeben und Informationen von anderen erhalten können. Das bringt allerdings auch ganz neue Gefahren mit sich, die bis dahin keine Rolle spielten. Zu diesen potentiellen Gefahren gehören Computerkriminalität, Informationsdiebstahl und böswillige Beschädigung. Nichtautorisierte, skrupellose Personen, die Zugriff auf ein Computersystem bekommen, können Paßwörter ausspähen oder Fehler und Eigentümlichkeiten bestimmter Programme ausnutzen, um so einen Benutzer-Account auf der Maschine zu erhalten. Wenn sie einmal in der Lage sind, sich in die

Maschine einzuloggen, erhalten sie womöglich Zugriff auf kritische Informationen, zum Beispiel kommerziell sensitive Daten wie Geschäftspläne, Informationen über neue Projekte oder Datenbanken. Die Beschädigung oder Änderung solcher Daten kann einer Firma schwer zusetzen. Der sicherste Weg, solche weitverbreiteten Schäden zu vermeiden, besteht darin, unautorisierte Personen am Zugriff auf Maschinen über das Netzwerk zu hindern. An dieser Stelle kommen Firewalls ins Spiel. Achtung Der Aufbau sicherer Firewalls ist eine Wissenschaft für sich. Es erfordert ein gutes Verständnis der zugrundeliegenden Technik. Nicht weniger wichtig ist aber auch das Verständnis der dem FirewallDesign zugrundeliegenden Philosophie. Wir behandeln in diesem Buch nicht alles, was Sie darüber wissen sollten, und empfehlen Ihnen daher dringend, selbst einige Nachforschungen anzustellen, bevor Sie einem bestimmten Firewall-Design Ihr Vertrauen schenken.

Es gibt genug Material über den Entwurf und die Konfiguration von Firewalls, um damit ein ganzes Buch zu füllen. In der Tat gibt es einige gute Quellen, die Sie für ein tieferes Verständnis der Materie heranziehen sollten. Zwei davon sind: Einrichten von Internet Firewalls von D. Chapman und E. Zwicky (O'Reilly). Eine Einführung in das Design und die Installation von Firewalls für Unix, Linux und Windows NT und wie man Internetdienste zur Zusammenarbeit mit Firewalls konfiguriert. Firewalls and Internet Security von W. Cheswick und S. Bellovin (Addison Wesley). Dieses Buch behandelt die zugrundeliegende Philosophie von Firewall-Design und -Implementierung. In diesem Kapitel befassen wir uns mit Linux-spezifischen technischen Fragen. Später präsentieren wir eine beispielhafte Firewall-Konfiguration, die Ihnen als brauchbare Vorlage für eigene Konfigurationen dienen kann. Allerdings gilt wie für alle sicherheitsbezogenen Themen auch hier: Vertrauen Sie niemandem. Klopfen Sie das Design gründlich ab, und vergewissern Sie sich, daß Sie es auch vollständig verstehen, bevor Sie es an Ihre Bedürfnisse anpassen. Gehen Sie sicher, dann sind Sie auch sicher.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Angriffsmethoden Für Sie als Netzwerkadministrator ist es von entscheidender Bedeutung, daß Sie die Natur potentieller Angriffe auf die Rechnersicherheit richtig verstehen. Wir gehen hier kurz auf die wichtigsten Arten von Rechnerangriffen ein, so daß Sie genauer begreifen, gegen welche von ihnen die Linux IPFirewall überhaupt gefeit ist. Für ein tieferes Verständnis anderer Angriffsarten sollten Sie weitere Literatur heranziehen. Dadurch werden Sie in der Lage sein, Ihr Netzwerk auch gegen andere Attacken als die hier beschriebenen zu schützen. Es folgt eine Beschreibung der wichtigeren Angriffsmethoden und Hinweise, wie Sie sich selbst dagegen schützen können: Unautorisierter Zugriff Das bedeutet schlicht und einfach, daß Leute, die eigentlich Ihre Rechnerdienste nicht nutzen dürften, sich dennoch mit ihnen verbinden und sie nutzen können. Beispielsweise könnten Leute von außerhalb Ihrer Firma versuchen, sich Zugang zu Ihrem Buchhaltungssystem oder Ihrem NFS-Server zu verschaffen. Es gibt verschiedene Möglichkeiten, solche Angriffe abzuwehren, indem Sie genau festlegen, wer auf diese Dienste zugreifen darf. Verhindern Sie dann jeden Zugriff über das Netzwerk, die ermittelten Personen ausgenommen.

Ausnutzen allgemein bekannter Programmschwächen Einige Programme und Netzwerkdienste waren ursprünglich nicht für Anwendungen mit strengen Sicherheitsanforderungen ausgelegt und enthalten inhärente Schwachstellen, die sie für Angriffe verwundbar machen. Die BSD-Remote-Dienste (rlogin, rexec usw.) sind ein Beispiel dafür. Der beste Weg, sich gegen diese Art von Angriffen zu schützen, besteht darin, alle verwundbaren Dienste abzuschalten oder Alternativen dazu zu suchen. Mit Open Source ist es manchmal möglich, die Schwachstellen in der Software zu reparieren. Denial of Service Denial-of-Service-Attacken bewirken, daß die angegriffenen Dienste oder Programme ihre Funktionsfähigkeit verlieren oder andere Benutzer daran gehindert werden, diese Dienste und Programme zu nutzen. Auf der Netzwerkebene wird dies zum Beispiel erreicht, indem sorgfältig konstruierte “bösartige” Datagramme gesendet werden, die zur Unterbrechung von Netzwerkverbindungen führen. Aber auch auf Applikationsebene können Programme durch sorgfältig zusammengestellte Befehlsfolgen dazu gebracht werden, extrem langsam oder gar funktions-untüchtig zu werden. Der beste Weg, das Risiko eines Denial-of-Service-Angriffes zu verringern, besteht darin, von vornherein zu verhindern, daß verdächtiger Netzwerkverkehr oder verdächtige ProgrammBefehlsfolgen Ihren Host überhaupt erst erreichen. Hier ist es von Vorteil, die Details der Angriffsmethoden zu kennen. Sie sollten sich daher immer wieder über die neuesten Angriffsmethoden informieren, um auf dem laufenden zu bleiben. Spoofing Bei dieser Angriffsart wird ein Host bzw. eine Anwendung dazu gebracht, das Verhalten eines anderen Hosts bzw. einer anderen Anwendung vorzutäuschen. Typisch für diese Angriffe ist, daß man den Angreifer für einen “unschuldigen” Host hält, wenn man die IP-Adressen in den Netzwerkpaketen verfolgt. So verwendet zum Beispiel ein gut dokumentiertes Angriffsprogramm diese Methode, um eine Schwäche im rlogin-Dienst von BSD auszunutzen. Es errät TCP-Sequenznummern und gibt so eine Verbindung von einem anderen Host vor. Um sich vor solchen Angriffen zu schützen, müssen Sie die Authentizität von Datagrammen und Befehlsfolgen verifizieren. Vermeiden Sie das Routen von Datagrammen mit unzulässigen Quelladressen. Machen Sie die Verbindungskontrollmechanismen unberechenbar, z.B. durch TCP-Sequenznummern und die Belegung dynamischer Port-Adressen. Lauschangriffe Das ist die einfachste Angriffsform. Dabei wird ein Host konfiguriert, um Daten “abzuhorchen”, die ihn eigentlich nichts angehen. Sorgfältig geschriebene

Lausch-angriffsprogramme können Benutzernamen und Paßwörter von Benutzer-Logins in Netzwerkverbindungen ausspähen. Besonders Broadcast-Netzwerke wie Ethernet sind für diese Art von Angriffen anfällig. Zum Schutz gegen diese Angriffsform wird empfohlen, die Anwendung von BroadcastNetzwerktechnologien zu vermeiden und besonders auf die Verschlüsselung von Daten zu achten. IP-Firewalls sind äußerst nützlich, um unautorisierte Zugriffe, Denial-of-Service-At-tacken auf Netzwerkebene und IP-Spoofing-Angriffe zu verhindern oder zumindest einzuschränken. Sie sind allerdings nicht besonders dazu geeignet, das Ausnutzen von Schwachstellen in Netzwerkdiensten oder Programmen zu verhindern, oder Lauschangriffe zu unterbinden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Was ist eine Firewall? Eine Firewall ist eine sichere und vertrauenswürdige Maschine, die zwischen einem privaten Netzwerk und einem öffentlichen Netzwerk plaziert ist.1 Der Firewall-Rechner wird mit einer Menge von Regeln konfiguriert, die bestimmen, welcher Netzwerkverkehr ihn passieren darf und welcher gegebenenfalls blockiert bzw. abgewiesen wird. In manchen großen Unternehmen finden Sie Firewalls sogar innerhalb des Unternehmensnetzwerks, um sensible Bereiche abzutrennen und diese vor dem Zugriff von Angestellten anderer Bereiche zu schützen. Viele Fälle von Computerkriminalität haben ihren Ursprung im Inneren einer Organisation und nicht außerhalb. Firewalls können auf verschiedene Art und Weise konstruiert werden. Die wohl am höchsten entwickelte Form von Firewalls umfaßt mehrere separate Maschinen und ist unter der Bezeichnung Perimeter-Netzwerk bekannt. Dabei agieren zwei Maschinen als “Filter”, die auch Drossel genannt werden, und lassen nur bestimmte Netzwerkverkehrsarten passieren. Zwischen diesen Filtern befinden sich Netzwerkserver wie Mail-Gateways oder WWW-Proxy-Server. Diese Konfiguration kann sehr große Sicherheit bieten und gestattet auf einfache Weise große Kontrolle darüber, wer sich von welcher Seite mit der jeweils anderen Seite verbinden darf. Diese Art der Konfiguration wird von großen Unternehmen eingesetzt. In den meisten Fällen sind Firewalls jedoch einzelne Maschinen, die für alle diese Funktionen zuständig sind. Sie sind natürlich etwas weniger sicher, da selbst eine kleine Schwachstelle, durch die

Leute Zugriff auf die Firewall erhalten, ausreicht, um die Sicherheit des gesamten Netzwerkes zu gefährden. Nichtsdestotrotz ist diese Art von Firewall billiger und leichter zu verwalten als die oben genannte ausgefeiltere Variante. Abbildung 9.1 illustriert die beiden häufigsten FirewallKonfigurationen. Abbildung 9.1: Die beiden häufigsten Firewall-Designs

Der Linux-Kernel bietet eine Reihe eingebauter Features, mit denen er gut als IP-Firewall funktionieren kann. Die Netzwerk-Implementierung enthält Code, der auf unterschiedliche Arten IPFiltering durchführt, und stellt einen Mechanismus zur Verfügung, mit dem Sie ziemlich genau einstellen können, welche Arten von Regeln Sie überhaupt anwenden wollen. Die Linux-Firewall ist flexibel genug, um für beide in Abbildung 9.1 gezeigten Designs angewendet werden zu können. Die Linux-Firewall-Software bietet zudem zwei weitere nützliche Features, die wir noch in gesonderten Abschnitten besprechen werden: IP Accounting (Kapitel 10 IP-Accounting) und IP-Masquerading (Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen).

1.

Der Ausdruck Firewall (“Brandschutzmauer”) stammt von einem besonderen Gerät, das Menschen vor Feuer schützt. Dabei handelt es sich um eine Mauer aus feuerfestem Material, die zwischen möglichen Feuerstellen und den davor zu schützenden Menschen aufgestellt wird.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Was ist IP-Filterung? IP-Filterung ist ein simples Verfahren, das entscheidet, welche Arten von IP-Datagrammen normal weitergeleitet und welche ausgesondert werden. Mit ausgesondert ist hier gemeint, daß die betroffenen Datagramme vollständig vernichtet und ignoriert werden, so als ob sie nie eingetroffen wären. Sie können viele verschiedene Kriterien festlegen, die entscheiden, welche Datagramme gefiltert werden sollen und welche nicht. Einige Beispiele dafür sind: ●

Protokollarten: TCP, UDP, ICMP usw.

●

Socket-Nummern (für TCP/UDP)

●

Datagramm-Arten: SYN/ACK, data, ICMP Echo Request usw.

●

Datagramm-Quelladresse: woher es kam

●

Datagramm-Zieladresse: wohin es geht

An dieser Stelle ist es wichtig zu begreifen, daß IP-Filterung eine Einrichtung auf Netzwerkebene ist. Das bedeutet, es weiß nichts über die Anwendungen, die die Netzwerkverbindungen benutzen, sondern nur etwas über die Verbindungen selbst. Sie können zum Beispiel Benutzern den Zugriff auf

Ihr internes Netzwerk über den Standard-Telnet-Port verbieten, aber wenn Sie sich dabei nur auf IPFilterung verlassen, können Sie es nicht verhindern, daß Anwender dem Telnet-Programm eine Portnummer übergeben, die Sie in Ihrer Firewall passieren lassen. Sie können derartige Probleme umgehen, indem Sie einen Proxy-Server für jeden Dienst verwenden, den Sie durch Ihre Firewall zulassen. Die Proxy-Server kennen die Interna der für sie ausgelegten Applikationen und können daher deren Mißbrauch unterbinden, wie zum Beispiel die Verwendung des Telnet-Programms, um über einen WWW-Port hinter eine Firewall zu gelangen. Wenn Ihre Firewall einen WWW-Proxy unterstützt, wird eine solche Telnet-Verbindung immer durch den Proxy beantwortet, der nur HTTPAnfragen weiterreicht. Es gibt eine ganze Reihe von Proxy-Server-Programmen. Manche davon sind freie Software und andere kommerzielle Produkte. Einige besonders populäre Produkte werden im Firewall-HOWTO besprochen. Sie würden den Rahmen dieses Buches sprengen. Die Regelsätze für IP-Filterung besteht aus vielen Kombinationen der oben beschriebenen Kriterien. Nehmen wir an, Sie wollen Webanwendern im Netzwerk der virtuellen Brauerei nur insoweit Internetzugriff ermöglichen, daß sie auf die Webserver anderer Sites zugreifen können. Dazu konfigurieren Sie Ihre Firewall so, daß folgende Weiterleitungen erlaubt wären: ●

●

Datagramme mit einer Quelladresse im Netzwerk der virtuellen Brauerei, einer beliebigen Zieladresse und dem Ziel-Port 80 (WWW). Datagramme mit einer Zieladresse im Netzwerk der virtuellen Brauerei und einer beliebigen Quelladresse vom Quell-Port 80 (WWW).

Beachten Sie, daß wir hier zwei Regeln benutzt haben. Wir müssen zum einen unseren ausgehenden Daten Zugang nach außen ermöglichen, zum anderen aber auch den eingehenden Daten Zugang nach innen. In der Praxis läßt sich das in Linux allerdings, wie wir noch sehen werden, ganz einfach mit einer einzigen Regel beschreiben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Linux für Firewalling vorbereiten Um eine Linux IP-Firewall zu bauen, ist es zunächst notwendig, einen Kernel mit IP-Firewall-Unterstützung und das entsprechende Konfigurationsprogramm zu haben. In allen stabilen Kerneln vor der Version 2.2 benutzen Sie ipfwadm. Mit den 2.2.x-Kerneln wurde die dritte Generation der IP-Firewalls für Linux eingeführt, IP Chains genannt. Diese benutzen ein ähnliches Programm zu ipfwadm namens ipchains. Kernel 2.3.15 und später unterstützen bereits die vierte Generation von Linux-IP-Firewalls (netfilter). Diese sind das Ergebnis vieler Änderungen im Umgang mit der Paketübertragung in Linux. netfilter ist ein vielgestaltiges Produkt, das sowohl vollständig abwärtskompatibel zu ipfwadm und ipchains ist und außerdem das neue Konfigurationsprogramm iptables unterstützt. Die Unterschiede dieser drei Programme besprechen wir in den nächsten Abschnitten.

Konfigurieren des Kernels mit IP Firewall Der Linux-Kernel muß für die Unterstützung von IP-Firewalling konfiguriert sein. Dafür ist nicht viel mehr zu tun, als die entsprechende Option auszuwählen, wenn Sie das make menuconfig vor der Kernel-Kompilierung ausführen.1 Wie man das macht, hatten wir bereits in Kapitel 3 Konfiguration der Netzwerkhardware, beschrieben. In 2.2er Kerneln sollten Sie folgende Optionen auswählen: Networking options IP: firewalling

---> [*] Network firewalls [*] IP: firewall packet logging

[*] TCP/IP networking

[*]

In den Kerneln ab 2.4.0 sollten Sie folgende Optionen auswählen: Networking options ---> [*] Network packet filtering (replaces ipchains) IP: Netfilter Configuration ---> . <M> Userspace queueing via NETLINK (EXPERIMENTAL) <M> IP tables support (required for filtering/masq/NAT) <M> limit match support <M> MAC address match support <M> netfilter MARK match support <M> Multiple port match support <M> TOS match support <M> Connection state match support <M> Unclean match support (EXPERIMENTAL) <M> Owner match support (EXPERIMENTAL) <M> Packet filtering <M> REJECT target support <M> MIRROR target support (EXPERIMENTAL) . <M> Packet mangling <M> TOS target support <M> MARK target support <M> LOG target support <M> ipchains (2.2-style) support <M> ipfwadm (2.0-style) support

Das ipfwadm-Programm Das Programm ipfwadm (IP Firewall Administration) ist das Hilfsmittel, mit dem Firewall-Regeln für alle Kernel vor der Version 2.2.0 gebildet werden. Seine Befehlssyntax kann sehr verwirrend sein, da es so viele komplizierte Dinge tun kann, aber wir stellen Ihnen trotzdem einige Beispiele für die wichtigsten Varianten vor. Das ipfwadm-Programm ist in den meisten modernen Linux-Distributionen enthalten, wird aber möglicherweise nicht standardmäßig installiert. Dafür mag es ein bestimmtes Softwarepaket geben, das Sie noch nachträglich installieren müssen. Enthält Ihre Linux-Distribution nichts dergleichen, können Sie den Quellcode von ftp.xos.nl aus dem Verzeichnis /pub/linux/ipfwadm/ herunterladen und selbst kompilieren.

Das Programm ipchains Wie bei ipfwadm kann auch ipchains zu Beginn sehr leicht zu Verwirrungen führen. Es bietet genauso viele Möglichkeiten wie ipfwadm mit einer vereinfachten Befehlssyntax und stellt außerdem einen “Verkettungs”-Mechanismus (Chaining) zur Verfügung, mit dem Sie viele Regelsätze verwalten und miteinander verbinden können. Rule Chaining behandeln wir in einem eigenen Abschnitt am Ende dieses Kapitels, da es für die meisten Situationen nur ein Zusatzkonzept ist. Das Programm ipchains ist Bestandteil der meisten Linux-Distributionen, die auf dem 2.2er Kernel basieren. Wenn Sie es selbst kompilieren wollen, finden Sie den Quellcode auf der Website des Entwicklers unter http://www.rustcorp.com/linux/ipchains/. Im Quellpaket ist ein Wrapper-Skript namens ipfwadm-wrapper enthalten, das sich wie -ipfwadm verhält, dabei aber in Wirklichkeit das ipchains-Kommando ausführt. Dadurch wird die Migration einer existierenden Firewall-Konfiguration ungemein erleichert.

Das Programm iptables Die Syntax des Programms iptables ist der von ipchains ziemlich ähnlich. Die Unterschiede betreffen im wesentlichen nur einige neu hinzugekommene Fähigkeiten und resultieren aus der mittels Shared Libraries ermöglichten Erweiterbarkeit des Programms. Wie bei ipchains stellen wir auch für iptables äquivalente Beispiele vor, so daß Sie die Unterschiede in der Syntax der verschiedenen Tools besser miteinander vergleichen können. Das iptables-Programm ist Bestandteil des Quellcodes von netfilter und unter http://www.samba.org/netfilter/ erhältlich. Es wird auch in jeder Linux-Distribution enthalten sein, die auf dem 2.4er Kernel basiert. Auf den großen Meilenstein, den netfilter markiert, gehen wir noch in einem eigenen Abschnitt in diesem Kapitel ein.

1.

“Firewall Packet Logging” ist ein spezielles Feature, das für jedes Datagramm, das eine bestimmte Firewall-Regel erfüllt, eine Informationszeile an ein spezielles Gerät ausgibt, die Sie dann lesen können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die drei Wege der Filterung Überlegen Sie sich einmal, wie ein Unix-Rechner oder jede Maschine, die in der Lage ist, IP-Verkehr zu routen, die IP-Datagramme verarbeitet. Die grundlegenden Schritte (siehe Abbildung 9.2) sind: Abbildung 9.2: Verarbeitungsschritte von IP-Datagrammen

●

●

●

●

●

●

●

Das IP-Datagramm wird empfangen. (1) Das eingehende IP-Datagramm wird daraufhin untersucht, ob es an einen Prozeß auf dieser Maschine gerichtet ist. Ist das Datagramm für diese Maschine bestimmt, wird es lokal verarbeitet. (2) Ist es dagegen nicht an diese Maschine gerichtet, wird in der Routing-Tabelle nach einer passenden Route gesucht und das Datagramm an das zuständige Interface weitergeleitet oder andernfalls verworfen, wenn keine Route gefunden wird. (3) Datagramme lokaler Prozesse werden zur Routing-Software gesendet, die sie an das passende Interface weiterleitet. (4) Das ausgehende IP-Datagramm wird untersucht, ob dafür eine zulässige Route existiert. Wenn nicht, wird es verworfen. Das IP-Datagramm wird übertragen. (5)

In unserem Diagramm veranschaulicht der Datenfluß 1→3→5, wie unsere Maschine die Daten von einem Host in unserem Ethernet zu einem über unsere PPP-Verbindung erreichbaren Host routet. Die Datenströme 1→2 und 4→5 repräsentieren den ein- und ausgehenden Datenfluß eines Netzwerkprogramms, das auf unserem lokalen Host läuft. Der Datenfluß 4→3→2 würde einen Datenstrom repräsentieren, der über eine Loopback-Verbindung läuft. Naturgemäß findet ein Datenfluß sowohl in Netzwerkgeräte hinein als auch wieder heraus statt. Die Fragezeichen im Diagramm markieren die Punkte, an denen die IP-Ebene die Routing-Entscheidungen trifft. Die IP-Firewall des Linux-Kernels kann eine Filterung in verschiedenen Phasen dieser Verarbeitungsprozesse durchführen. Das heißt, Sie können sowohl eingehende, ausgehende als auch direkt weitergeleitete IP-Datagramme filtern. In ipfwadm und ipchains ist eine Eingangsregel (Input) für den Datenfluß 1 im Diagramm zuständig, eine Weiterleitungsregel (Forwarding) für Datenfluß 3 und eine Ausgangsregel (Output) für Datenfluß 5. Wenn wir später auf netfilter eingehen, werden wir noch sehen, daß sich die Stellen, an denen Pakete abgefangen werden verschoben haben. Eine Eingangs-Regel wird nun auf Datenfluß 2 und eine Ausgangsregel auf Datenfluß 4 angewendet. Das hat wichtige Auswirkungen darauf, wie Sie Ihre Regelsätze strukturieren müssen. Die grundsätzlichen Prinzipien sind jedoch für alle Versionen von Linux-Firewalls dieselben. Das wirkt vielleicht am Anfang alles unnötig kompliziert, dafür bietet es aber eine Flexibilität, mit der auch äußerst komplexe und leistungsfähige Konfigurationen erstellt werden können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die ursprüngliche IP-Firewall (2.0er Kernel) Die erste Generation von IP-Firewalls wurde von Linux ab dem Kernel 1.1 unterstützt. Dabei handelte es sich um eine Portierung der ipfw-Firewall-Software von BSD nach Linux, die von Alan Cox durchgeführt wurde. Für die Erweiterungen der Firewall-Software der zweiten Generation ab Kernel 2.0 waren Jos Vos, Pauline Middelink und andere zuständig.

Benutzung von ipfwadm Der Befehl ipfwadm war das Konfigurations-Tool für die Linux-IP-Firewall der zweiten Generation. Die wohl einfachste Art, die Anwendung von ipfwadm zu beschreiben, sind Beispiele. Dazu nehmen wir uns ein bereits bekanntes Beispiel und schreiben es um. Ein einfaches Beispiel Nehmen wir an, wir haben ein Netzwerk in unserer Firma und wollen einen Linux-basierten Firewall-Rechner dazu benutzen, um unser Netzwerk mit dem Internet zu verbinden. Nehmen wir außerdem an, daß wir unseren Netzwerkbenutzern nur Zugriff auf die Webserver im Internet gestatten, aber keinen anderen Datenverkehr zulassen wollen. Dafür schreiben wir eine Weiterleitungsregel, die Datagrammen mit einer Quelladresse aus unserem Netzwerk und dem ZielPort 80 Zugang ins Internet gewährt und die von dort zurückkommenden IP-Antworten durch unsere Firewall hindurch in unser Netzwerk hereinläßt. Angenommen, unser Netzwerk hat eine 24-Bit-Netzmaske (Class C) und die IP-Adresse 172.16.1.0. Die Regeln, die wir anwenden könnten, sind: # ipfwadm -F -f # ipfwadm -F -p deny # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 # ipfwadm -F -a accept -P tcp -S 0/0 80 -D 172.16.1.0/24

Das Kommandozeilen-Argument –F teilt ipfwadm mit, daß es sich hier um eine Weiterleitungsregel handelt. Die erste Anweisung instruiert ipfwadm, alle bereits vorhandenen Weiterleitungsregeln zu löschen. Dadurch wird sichergestellt, daß wir von einem bekannten Zustand ausgehen, bevor wir irgendwelche neuen Regeln einführen. Die zweite Regel legt unsere Standard-Weiterleitungs-Richtlinie fest. Wir weisen den Kernel damit an, die Weitergabe von IP-

Datagrammen zu verweigern oder zu verbieten. Es ist sehr wichtig, diese Standardregel festzulegen, da sie für alle Datagramme, die nicht von den nachfolgenden Regeln verarbeitet werden, festlegt, wie mit ihnen verfahren werden soll. In den meisten Firewall-Konfigurationen werden Sie Ihre Standardeinstellung wie gezeigt auf “deny” festlegen, um sicherzugehen, daß wirklich nur solcher Datenverkehr Ihre Firewall passieren kann, dem Sie den Zugang erlauben wollen. Die Regeln drei und vier beschreiben unsere speziellen Anforderungen. Regel drei gestattet unseren Datagrammen Ausgang, und Regel vier legt fest, daß die Rückantworten unsere Firewall passieren dürfen. Nun sehen wir uns die Argumente einzeln an: -F Dies ist eine Weiterleitungsregel. -a accept Ergänzt diese Regel um die Einstellung, IP-Pakete grundsätzlich zu akzeptieren. Somit wird jedes IP-Paket weitergeleitet, das diese Regel erfüllt. -P tcp Diese Regel gilt nur für TCP-Datagramme (im Gegensatz zu UDP oder ICMP). -S 172.16.1.0/24 Die Quelladresse muß in den ersten 24 Bits mit der Netzwerkadresse 172.16.1.0 übereinstimmen. -D 0/0 80 Die Zieladresse muß in keinem Bit mit der Adresse 0.0.0.0 übereinstimmen. Das ist eigentlich eine Abkürzung für jede Adresse. Die 80 gibt den Ziel-Port an, in diesem Fall WWW. Sie können für den Port jeden Eintrag nehmen, der in der Datei /etc/ services vorkommt. So hätten Sie auch ebensogut -D 0/0 www verwenden können. ipfwadm akzeptiert Netzmasken in einer Form, die Ihnen vielleicht nicht so vertraut ist. Die /nn-Notation gibt an, wie viele Bits der übergebenen Adresse signifikant sind (d.h. die Länge der Maske). Die Bits werden dabei immer von links nach rechts gezählt. Einige allgemeine Beispiele sind in Tabelle 9.1 aufgelistet. Tabelle 9.1: Übliche Bitwerte für die Netzmaske Netzmaske

Bits

255.0.0.0

8

255.255.0.0

16

255.255.255.0

24

255.255.255.128 25 255.255.255.192 26 255.255.255.224 27 255.255.255.240 28 255.255.255.248 29 255.255.255.252 30 Bereits oben erwähnten wir, daß ipfwadm einen kleinen Trick benutzt, um das Hinzufügen solcher Regeln einfacher zu machen. Dabei handelt es sich um die Option –b, die aus dem Befehl eine bidirektionale Regel macht.

Das bidirektionale Flag ermöglicht es uns, unsere beiden Regeln zu einer einzigen zusammenzufassen: # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

Eine wichtige Verbesserung Betrachten Sie unseren Regelsatz mal etwas genauer. Sehen Sie, daß es immer noch eine Angriffsmethode gibt, mit der ein Außenstehender unsere Firewall durchbrechen könnte? Unseren Regelsatz gestattet allen Datagrammen von außerhalb, unser Netzwerk mit dem Quell-Port 80 zu passieren. Das gilt auch für alle Datagramme, bei denen das SYN-Bit gesetzt ist! Das SYN-Bit ist genau das, was ein TCP-Datagramm zu einer Verbindungsaufforderung macht. Wenn nun eine außenstehende Person privilegierten Zugriff auf einen Host hat, kann sie zu jedem unserer Hosts durch unsere Firewall hindurch Kontakt aufnehmen, wenn sie auch den Port 80 benutzt. So etwas hatten wir nun wirklich nicht beabsichtigt. Zum Glück gibt es aber auch dafür eine Lösung. Der Befehl ipfwadm kennt nämlich ein weiteres Flag, mit dem wir Regeln für Datagramme mit SYN-Flags bilden können. Lassen Sie uns das Beispiel verändern, indem wir eine solche Regel aufnehmen: # ipfwadm -F -a deny -P tcp -S 0/0 80 -D 172.16.10.0/24 -y # ipfwadm -F -a accept -P tcp -S 172.16.1.0/24 -D 0/0 80 -b

Das Flag -y sorgt dafür, daß die Regel nur für Datagramme mit gesetztem SYN-Flag gilt. Unsere neue Regel sagt somit folgendes aus: “Verweigere alle an unser Netzwerk gerichteten TCP-Datagramme mit dem Quell-Port 80 und gesetztem SYNBit” oder: “Verwirf alle Verbindungsanfragen von Hosts, die den Port 80 benutzen”. Warum haben wir diese spezielle Regel vor die Hauptregel gestellt? IP-Firewall-Regeln werden immer “von oben nach unten” abgearbeitet, so daß immer die erstbeste passende Regel genommen wird. Zu den Datagrammen, die wir aufhalten wollen, passen beide Regeln. Daher müssen wir die deny-Regel vor die accept-Regel stellen. Auflistung unserer Regeln Nachdem wir unsere Regeln eingegeben haben, lassen wir sie uns von ipfwadm mit folgendem Befehl anzeigen: # ipfwadm -F -l

Diese Anweisung erzeugt eine Liste aller konfigurierten Weiterleitungsregeln. Die Ausgabe sollte etwa wie folgt aussehen: # ipfwadm -F -l IP firewall forward rules, default policy: accept type prot source destination ports deny tcp anywhere 172.16.10.0/24 www -> any acc tcp 172.16.1.0/24 anywhere any -> www

Falls ein Eintrag in der Datei /etc/service existiert, gibt ipfwadm anstelle der Portnummer den zugehörigen Service-Namen direkt aus. Die Standardausgabe liefert uns nicht alle wichtigen Informationen. Wir sehen darin zum Beispiel nicht die Auswirkungen des Arguments -y. Sie erhalten aber eine ausführliche Liste, wenn Sie ipfwadm zusätzlich die Option -e (extended output) angeben. Die Liste wird dann allerdings so breit, daß wir sie hier nicht vollständig abdrucken können. In der Spalte opt (options) wird die Option -y angezeigt, die die SYN-Pakete kontrolliert: # ipfwadm -F -l -e P firewall forward rules, default policy: accept pkts bytes type prot opt tosa tosx ifname ifaddress source ... 0 0 deny tcp --y- 0xFF 0x00 any any anywhere ... 0 0 acc tcp b--- 0xFF 0x00 any any 172.16.1.0/24 ...

Ein anspruchsvolleres Beispiel Das vorige Beispiel war recht einfach. Nicht alle Netzwerkdienste sind so leicht zu konfigurieren wie der WWW-Service. In der Praxis ist eine Firewall-Konfiguration wesentlich komplizierter. Sehen wir uns dazu ein anderes gängiges Beispiel an, diesmal

FTP. Wir wollen unseren internen Netzwerkbenutzern das Einloggen in FTP-Servern im Internet gestatten, um Dateien zu lesen und zu schreiben. Den umgekehrten Weg, nämlich das Einloggen in unsere FTP-Server von außerhalb, wollen wir aber unterbinden. Wir wissen, daß FTP zwei TCP-Ports benutzt: Port 20 (ftp-data für Daten) und Port 21 (ftp zur Steuerung). Also: # ipfwadm -a deny -P tcp -S 0/0 20 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 D 0/0 20 -b # # ipfwadm -a deny -P tcp -S 0/0 21 -D 172.16.1.0/24 -y # ipfwadm -a accept -P tcp -S 172.16.1.0/24 -D 0/0 21 -b

Ist das alles? Nun, nicht unbedingt. FTP-Server können in zwei verschiedenen Betriebsmodi arbeiten: im passiven Modus und im aktiven Modus.1 Im passiven Modus wartet der FTP-Server auf eine Verbindungsaufnahme des Client. Im aktiven Modus dagegen stellt der FTP-Server selbst eine Verbindung zum Client her. Normal ist der aktive Modus. Die Unterschiede werden in Abbildung 9.3 dargestellt. Viele, aber leider nicht alle FTP-Server stellen im aktiven Modus ihre Datenverbindung über den Port 20 her, was uns die Sache etwas leichter macht.2 Abbildung 9.3: Betriebsmodi von FTP-Servern

Aber was haben wir damit zu schaffen? Werfen wir mal einen Blick auf unsere Regel für Port 20, den FTP-Daten-Port. Die Regel, wie sie dasteht, nimmt an, daß die Verbindung von unserem Client zum Server aufgebaut wird. Gut, das funktioniert für den passiven Modus. Aber wir bekommen große Probleme, wenn wir eine geeignete Regel für FTP im aktiven Modus schreiben wollen, weil wir nicht unbedingt wissen, welchen Port der Server dafür nimmt. Öffnen wir unsere Firewall für eingehende Verbindungen für alle möglichen Ports, lassen wir zu, daß alle unsere Netzwerkdienste, die für die eingehenden Verbindungen zuständig sind, angreifbar werden. Der sicherste Weg aus diesem Dilemma besteht darin, alle unsere Benutzer dazu zu verpflichten, nur passive Verbindungen herzustellen. Die meisten FTP-Server und viele FTP-Clients arbeiten ohnehin so. Der populäre ncftp-Client unterstützt auch den passiven Modus, verlangt dafür aber gegebenenfalls eine kleine Konfigurationsänderung. Viele WWW-Browser wie Netscape unterstützen auch den passiven FTP-Modus; es ist also nicht so schwer, geeignete Software zu finden. Alternativ dazu können Sie aber auch einen FTP-Proxy-Server verwenden, der Verbindungen vom internen Netzwerk akzeptiert und Verbindungen nach außen hin etabliert. Beim Aufbau Ihrer Firewall werden Ihnen vielleicht mehrere solche Probleme begegnen. Sie sollten immer sorgfältig überdenken, wie ein Netzwerkdienst überhaupt funktioniert, bevor Sie sich die Formulierung angemessener Regelsätze

vornehmen. Eine praxistaugliche Firewall-Konfiguration kann zu einer sehr komplizierten Angelegenheit werden.

Übersicht über die Argumente von ipfwadm ipfwadm kennt viele verschiedene Argumente, die die Konfiguration von IP-Firewalls beeinflussen. Die allgemeine Syntax ist: ipfwadm Kategorie Befehl Parameter [Optionen]

Sehen wir sie uns mal im einzelnen an. Kategorien Eine Kategorie teilt der Firewall mit, welche Art von Firewall-Regel Sie konfigurieren. Als Kategorie wird genau eines der nachfolgenden Argumente übergeben: -I Eingangsregel -O Ausgangsregel -F Weiterleitungsregel Befehle Ein Befehl teilt der Firewall mit, welche Aktion durchgeführt werden soll. Mindestens einer der nachfolgenden Befehle wird übergeben und wirkt sich nur auf die Regeln der angegebenen Kategorie aus: -a [policy] Fügt eine neue Regel am Ende der Liste mit bereits vorhandenen an. -i [policy] Fügt eine neue Regel in die Liste mit bereits vorhandenen ein. -d [policy] Entfernt eine vorhandene Regel -p policy Setzt eine Standardeinstellung -l Listet alle vorhandenen Regeln auf -f Löscht alle vorhandenen Regeln

Die für die IP-Firewall relevanten Einstellungen und ihre Bedeutungen sind: accept Passende Datagramme können empfangen, weitergeleitet oder übertragen werden deny Verhindert den Empfang, die Weitergabe und die Übertragung passender Datagramme reject Verhindert den Empfang, die Weitergabe und die Übertragung passender Datagramme und schickt dem Host, der das Datagramm gesendet hat, eine ICMP-Fehlermeldung. Parameter Die Parameter geben an, für welche Datagramme diese Regel gilt. Mindestens einer der folgenden Parameter muß angegeben werden: -P protocol Kann TCP, UDP, ICMP oder auch alles sein. Beispiel: -P tcp -S address[/mask] [port] Die Quell-IP-Adresse, zu der diese Regel paßt. Wenn Sie keine Netzmaske angeben, wird /32 genommen. Optional können Sie auch angeben, für welche Ports diese Regel gelten soll. Damit es funktioniert, müssen Sie mit dem Argument -P noch das Protokoll angeben. Wenn Sie keinen Port oder Port-Bereich angeben, wird “all” genommen. Für die Spezifizierung der Ports können Sie auch ihre Namen verwenden, wie sie in /etc/services angegeben sind. Im Fall des ICMP-Protokolls wird das Port-Feld benutzt, um die ICMP-Datagrammtypen anzugeben. Port-Bereiche können auch umschrieben werden. Benutzen Sie dafür folgende Syntax: Anfangs-Port:End-Port. Hier ein Beispiel: -S 172.29.16.1/24 ftp:ftp-data -D address[/mask] [port] Die Ziel-IP-Adresse, zu der diese Regel paßt. Sie wird auf dieselbe Weise angegeben wie bei den oben beschriebenen Quell-IP-Adressen. Hier ein Beispiel: -D 172.29.16.1/24 smtp -V address Die Adresse der Netzwerkschnittstelle, die das Datenpaket empfängt (-I) oder sendet (-O). Damit können wir spezielle Regeln festlegen, die nur für bestimmte Netzwerk-Interfaces in unserer Maschine gelten. Beispiel: -V 172.29.16.1 -W name Der Name der Netzwerkschnittstelle. Dieses Argument funktioniert genauso wie das Argument -V, nur daß Sie hier den

Namen anstelle der Adresse der Schnittstelle angeben. Beispiel: -W ppp0 Optionale Argumente Die folgenden Argumente sind manchmal sehr nützlich: -b Dieses Flag wird für den bidirektionalen Modus benutzt. Es akzeptiert Datenverkehr zwischen den angegebenen Quellund Zieladressen in beiden Richtungen. Das erspart Ihnen die Ausarbeitung zweier separater Regeln: eine für ausgehende Datagramme und eine für eingehende Datagramme. -o Aktiviert die Protokollierung passender Datagramme im Kernel-Log. Jedes Datagramm, das zu dieser Regel paßt, wird in Form einer Kernel-Nachricht protokolliert. Das ist nützlich zur Aufspürung nichtautorisierter Zugriffe. -y Diese Option wird für TCP-Datagramme verwendet und bewirkt, daß die Regel nur solche Datagramme behandelt, die eine TCP-Verbindung aufzubauen versuchen. Dabei handelt es sich um Datagramme, deren SYN-Bit gesetzt und deren ACK-Bit nicht gesetzt ist. Nützlich ist diese Option zur Filterung von TCP-Verbindungsversuchen. Andere Protokolle bleiben davon unberührt. -k Wird zur Erkennung von TCP-Bestätigungs-Datagrammen benutzt. Diese Option veranlaßt die Regel, nur solche Datagramme zu verarbeiten, bei denen es sich um Bestätigungen von TCP-Verbindungsversuchen handelt. Dazu gehören ausschließlich Datagramme, deren ACK-Bit gesetzt ist. Diese Option ist nur zur Filterung von TCPVerbindungsversuchen vorgesehen und für alle anderen Protokolle wirkungslos. Arten von ICMP-Datagrammen Alle Firewall-Konfigurationsbefehle ermöglichen es Ihnen, die Arten der ICMP-Datagramme festzulegen. Im Gegensatz zu den TCP- und UCP-Ports gibt es keine bequem handhabbare Konfigurationsdatei, in der die Datagramm-Arten und ihre Bedeutungen beschrieben sind. Die ICMP-Datagramm-Arten sind in RFC-1700 (Assigned Numbers RFC) definiert. Außerdem werden sie in einer der Standard-C-Bibliotheks-Header-Dateien aufgelistet. Dabei handelt es sich um die Datei /usr/include/netinet/ip_icmp.h, die zur GNU-Standardbibliothek gehört und von C-Programmierern benutzt wird, um Netzwerksoftware zu schreiben, die das ICMP-Protokoll verwendet. Für Sie haben wir die ICMP-Datagramme nochmal in Tabelle 9.2 aufgelistet. Sie finden auch die namentlichen Bezeichnungen (Mnemonics) der Datagramm-Arten, wie sie vom Befehl iptables verstanden werden. Tabelle 9.2: Arten von ICMP-Datagrammen Typ-Nummer iptables Mnemonic

Beschreibung

0

echo-reply

Antwort auf ein Echo Request

3

destination-unreachable Ziel nicht erreichbar

4

source-quench

Quelle drosseln

5

redirect

Umleitung

8

echo-request

Echo-Anforderung

11

time-exceeded

Das TTL-Feld hat den Wert 0.

12

parameter-problem

Ungültiges Header-Feld

13

timestamp-request

Anforderung eines Zeitstempels

14

timestamp-reply

Zeitantwort

15

none

Informationsanforderung

16

none

Informationsantwort

17

address-mask-request

Adreßmasken-Anforderung

18

address-mask-reply

Adreßmasken-Antwort

1.

Der aktive FTP-Modus wird nicht besonders offensichtlich mit dem Befehl PORT eingestellt. Den passiven Modus aktiviert man mit PASV.

2.

Ein Beispiel für einen FTP-Server, der das nicht macht, ist der ProFTPd-Dämon, zumindest nicht in älteren Versionen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP Firewall Chains (2.2-Kernel) Die meisten Funktionen von Linux werden weiterentwickelt, um den Anforderungen seiner Benutzer gerecht zu werden. IPFirewalls machen da keine Ausnahme. Die traditionelle Implementierung von IP-Firewalls ist für die meisten Anwendungen völlig ausreichend. In komplexen Umgebungen kann deren Konfiguration allerdings ziemlich schwerfällig und ineffizient werden. Um diesen Schwachpunkt aus dem Weg zu räumen, wurde ein neues Konfigurationsverfahren für IP-Firewalls und deren Zusatz-Features entwickelt. Diese neue Methode nennt sich “IP Firewall Chains” und wurde der Öffentlichkeit erstmals mit dem Kernel 2.2.0 zur Verfügung gestellt. Die Unterstützung von IP Firewall Chains wurde von Paul Russell und Michael Neuling entwickelt.1 Paul dokumentierte die IPFirewall-Chains-Software im IPCHAINS-HOWTO. IP Firewall Chains ermöglichen es Ihnen, Klassen von Firewall-Regeln zu entwickeln, denen Sie dann Hosts oder Netzwerke hinzufügen bzw. wieder entfernen können. Durch die Verbindung (chaining) von Firewall-Regeln kann die Performance einer Firewall besonders in solchen Konfigurationen erhöht werden, in denen besonders viele Regeln vorkommen. IP Firewall Chains werden von der Kernel-Serie 2.2 unterstützt. Sie können durch einen Patch auch mit den 2.0.*-Kerneln genutzt werden. Wo man diesen Patch erhält, wird im HOWTO beschrieben. Dort sind auch eine Menge nützlicher Tips enthalten, wie man das Konfigurations-Tool ipchains effektiv nutzen kann.

Anwendung von ipchains Es gibt zwei Möglichkeiten, das Hilfsmittel ipchains zu benutzen. Erstens kann man das Shell-Skript ipfwadm-wrapper benutzen. Dieses stellt hauptsächlich einen schnellen Ersatz für ipfwadm dar. Hinter den Kulissen steuert es das Programm ipchains. Wenn Sie so vorgehen, brauchen Sie hier nicht weiterzulesen. Lesen Sie statt dessen den vorherigen Abschnitt über den ipfwadm-Befehl, und ersetzen Sie dabei diesen Befehl durch ipfwadm-wrapper. Das funktioniert zwar, es gibt aber keine Garantie, daß dieses Skript weiterhin gepflegt wird. Außerdem können Sie die Vorteile der erweiterten Funktionalität, die IP Firewall Chains zu bieten hat, nicht nutzen. Die zweite Möglichkeit das Programm ipchains zu benutzen ist, seine neue Syntax zu erlernen und alle vorhandenen Konfigurationen, die Sie benutzen, entsprechend anzupassen. Mit ein wenig Überlegung können Sie Ihre Konfiguration dabei sogar optimieren. Da die neue Syntax von ipchains leichter zu lernen ist als die von ipfwadm, ist die Entscheidung für ipchains ohnehin eine gute Wahl.

ipfwadm bot nur drei verschiedene Regelsätze für die Konfiguration von Firewalls. Bei IP Firewall Chains können Sie dagegen beliebig viele Regelsätze einführen, die alle miteinander verbunden sind. Drei für Firewalling zuständige Regelsätze sind allerdings immer präsent. Diese Standard-Regelsätze sind äquivalent zu denen von ipfwadm, haben aber zusätzlich Namen: input, forward und output. Zunächst betrachten wir die allgemeine Syntax von ipchains. Danach sehen wir, wie wir ipchains anstelle von ipfwadm benutzen können, ohne uns zunächst irgendwelche Gedanken über die erweiterten Verkettungs-Möglichkeiten (ChainingFeatures) zu machen. Dabei greifen wir auf einige frühere Beispiele zurück.

Die Befehlssyntax von ipchains Die Befehlssyntax von ipchains ist einfach. Wir betrachten nur die wichtigsten Sprachstrukturen. Die allgemeine Syntax der meisten ipchains-Befehle ist: ipchains Befehl Regelspezifikation Optionen

Befehle Es gibt mehrere Wege, Regeln und Regelsätze mit ipchains zu modifizieren. Die für IP-Firewalling relevanten sind: -A Chain Fügt eine oder mehrere Regeln an das Ende der bezeichneten Kette an. Falls ein Hostname als Quell- oder Zieladresse angegeben ist und er zu mehr als einer IP-Adresse aufgelöst werden kann, wird für jede dieser Adressen eine eigene Regel hinzugefügt. -I Chain Regelnummer Fügt eine oder mehrere Regeln am Anfang der bezeichneten Regel ein. Falls ein Hostname als Quell- oder Zieladresse angegeben ist und er zu mehr als einer IP-Adresse aufgelöst werden kann, wird für jede dieser Adressen eine eigene Regel hinzugefügt. -D Chain Entfernt eine oder mehrere Regeln aus der angegebenen Kette, die der Regelspezifikation entsprechen. -D Chain Regelnummer Entfernt die an Position Regelnummer befindliche Regel aus der angegebenen Kette. Regelpositionen in der Kette werden beginnend mit eins numeriert. -R Chain Regelnummer Ersetzt die an Position Regelnummer befindliche Regel in der angegebenen Kette durch die angegebene Regelspezifikation. -C Chain Testet ein durch die Regelspezifikation beschriebenes Datagramm gegen die angegebene Kette. Diese Anweisung liefert eine Meldung zurück, wie das Datagramm von der Kette verarbeitet wurde. Sie ist sehr nützlich zum Testen von FirewallKonfigurationen. Darauf gehen wir später im Detail ein. -L [Chain] Listet die Regel der angegebenen Kette auf (oder die Regeln aller Ketten, falls keine bestimmte Kette angegeben ist).

-F [Chain] Aktualisiert die Regeln der angegebenen Kette (oder für alle Ketten, falls keine bestimmte angegeben ist). -Z [Chain] Setzt die Datagramm und Bytezähler aller Regeln der angegebenen Kette auf null (oder für alle Ketten, falls keine bestimmte angegeben ist). -N Chain Erzeugt eine neue Kette mit der angegebenen Bezeichnung (es darf allerdings keine Kette mit gleichem Namen existieren). Hiermit werden benutzerdefinierte Ketten erzeugt. -X [Chain] Entfernt die angegebene benutzerdefinierte Kette (oder alle benutzerdefinierten Ketten, falls keine bestimmte angegeben ist). Damit diese Anweisung tatsächlich ausgeführt wird, darf es keine Referenzen von irgendeiner anderen Regelkette auf diese Kette geben. -P Chain Standardaktion Setzt die Standardaktion der angegebenen Kette auf die angegebene Aktion. Zulässige Firewalling-Aktionen sind ACCEPT, DENY, REJECT, REDIR oder RETURN. ACCEPT, DENY und REJECT haben dieselbe Bedeutung wie in der traditionellen IP-Firewall-Implementierung. REDIR gibt an, daß das Datagramm transparent zu einem Port auf dem Firewall-Host umgeleitet werden soll. Die Aktion RETURN bewirkt, daß der IP-Firewalling-Code die Verarbeitung der aktuellen Kette beendet und an die Stelle in der ursprünglichen Kette zurückkehrt, die der Verzweigung folgt. Parameter zur Regelspezifikation Zur Bildung einer Regelspezifikation gibt es eine Reihe von ipchains-Parametern, die die zu erkennenden IP-Pakete festlegen. Wird einer dieser Parameter in einer Regel weggelassen, wird stattdessen der jeweilige Standardwert eingesetzt: -p [!]Protokoll Spezifiziert das Protokoll des Datagramms, das zu dieser Regel paßt. Zulässige Protokollnamen sind tcp, udp, icmp oder all. Sie können hier auch eine IP-Protokollnummer angeben, um andere Protokolle zuzulassen. Beispielsweise könnten Sie 4 angeben, um die jeweilige Regel auf Datagramme dieses IP-über-IP-Protokolls (ipip-EncapsulationProtokolls) anzuwenden. Wenn Sie das Zeichen ! mit angeben, wird die Regel negiert, und es wird nur gegen Datagramme anderer Protokolle getestet. Ist dieser Parameter überhaupt nicht angegeben, wird dafür all genommen. -s [!]Adresse[/Netzmaske] [!] [Port] Gibt die Quelladresse und den Quell-Port des Datagramms an, das zu dieser Regel paßt. Die Adresse kann als Hostname, Netzwerkname oder IP-Adresse angegeben werden. Die optionale Netzmaske kann entweder in traditioneller Form (z.B. /255.255.255.0) oder in moderner Form (z.B. /24) angegeben werden. Der optionale Port gibt den TCP- oder UDP-Port oder den ICMP-Datagrammtyp an, der zur Regel paßt. Den Port dürfen Sie allerdings nur dann spezifizieren, wenn Sie den Parameter -p zusammen mit einem der Protokolle tcp, udp oder icmp angegeben haben. Die Ports können auch bereichsweise angegeben werden, und zwar in Form einer Untergrenze, gefolgt von einem Doppelpunkt, gefolgt von einer Obergrenze. So beschreibt zum Beispiel der Ausdruck 20:25 alle Ports zwischen 20 und 25 (inklusive). Auch hier kann das Zeichen ! zur Negierung eingesetzt werden. -d [!]Adresse[/Netzmaske] [!] [Port] Spezifiziert die Zieladresse und den Ziel-Port des Datagramms, das zu dieser Regel paßt. Beide Größen werden wie

beim Parameter -s angegeben. -j Ziel Spezifiziert die durchzuführende Aktion, wenn diese Regel paßt. Die Regel können Sie gewissermaßen als “GOTO”Anweisung auffassen, deren Zielanweisung eine der folgenden ist: ACCEPT, DENY, REJECT, REDIR und RETURN. Die Bedeutung dieser Ziele haben wir bereits beschrieben. Sie können hier auch den Namen einer benutzerdefinierten Kette angeben, in der die Abarbeitung fortgesetzt werden soll. Fehlt der Parameter, findet für die passenden Datagramme überhaupt keine Aktion statt. Es werden lediglich der Datagramm- und der Bytezähler aktualisiert. -i [!]Schnittstelle Spezifiziert die Schnittstelle, von der ein Datagramm empfangen oder an die ein Datagramm gesendet wird. Auch hier dient ! zur Negierung des Vergleichstests. Endet der Schnittstellen-Bezeichner mit +, gilt die Regel für alle Schnittstellen, deren Namen mit der angegebenen Zeichenfolge beginnen. Beispielsweise bezeichnet der Ausdruck -i ppp+ alle PPP-Netzwerkgeräte. Der Ausdruck -i ! eth+ bezeichnet dagegen alle Schnittstellen mit Ausnahme der Ethernet-Geräte. [!] -f Gibt an, daß die Regel auf alle Fragmente eines fragmentierten Datagramms mit Ausnahme des ersten Fragments angewendet werden soll. Optionen Die folgenden ipchains-Optionen sind allgemeiner Natur. Einige von ihnen steuern ziemlich ausgefallene Features der IP Chains Software: -b Bewirkt die Erzeugung zweier Regeln. Die erste führt einen Vergleich mit den übergebenen Parametern durch, die zweite führt einen Parametervergleich in umgekehrter Richtung durch. -v Veranlaßt ipchains zur Ausgabe detaillierter Informationen. -n Bewirkt, daß ipchains IP-Adressen und Ports nur als Nummern ausgibt, ohne sie in ihre entspechenden Klartextnamen aufzulösen. -l Schaltet die Kernel-Protokollierung passender Datagramme ein. Jedes Datagramm, das zur Regel paßt, wird vom Kernel mittels seiner printk()-Funktion in eine Logdatei protokolliert, für die gewöhnlich das Programm sysklogd zuständig ist. Damit können zum Beispiel ungewöhnliche Datagramme aufgespürt werden. -o[MaxGröße] Veranlaßt die IP Chains Software, jedes zur Regel passende Datagramm zum “netlink”-Device im Benutzerbereich zu kopieren. Das Argument MaxGröße begrenzt die Anzahl der Bytes jedes Datagramms, das das netlink-Device erreicht. Diese Option ist besonders für Entwickler gedacht, könnte aber in Zukunft auch von manchen Softwarepaketen genutzt werden. -m Markierungswert

Bewirkt, daß passende Datagramme mit einem Wert markiert werden. Markierungswerte sind vorzeichenlose 32-BitWerte. Sie werden von den existierenden Implementierungen zwar noch nicht benutzt, das kann sich in Zukunft aber ändern. Man könnte damit unter anderem feststellen, wie ein Datagramm von anderen Softwarepaketen (z.B. RoutingCode) verarbeitet wird. Beginnt ein Markierungswert mit einem + bzw. -, wird er zum existierenden Markierungswert addiert bzw. von diesem subtrahiert. -t UND-Maske XOR-Maske Diese Option gestattet Ihnen die Bearbeitung der “Type of Service”-Bits im IP-Header jedes zur Regel passenden Datagramms. Die Type-of-Service-Bits werden von intelligenten Routern dazu benutzt, Datagramme vor ihrer Weitergabe nach Prioritäten zu ordnen. Die Routing-Software von Linux ist dazu fähig. Die UND-Maske und die XORMaske repräsentieren Bitmasken, die einer logischen UND- bzw. exklusiven ODER-Verknüpfung mit den Type-ofService-Bits des Datagramms unterzogen werden. Hierbei handelt es sich um ein ergänzendes Feature, das etwas ausführlicher im IPCHAINS-HOWTO behandelt wird. -x Bewirkt, daß jeder Zahlenwert in der ipchains-Ausgabe exakt, also ohne Auf- oder Abrunden angezeigt wird. -y Veranlaßt die Regel, nur solche TCP-Datagramme zu prüfen, deren SYN-Bit gesetzt und deren ACK- und FIN-Bits nicht gesetzt sind. Damit können TCP-Verbindungsanfragen gefiltert werden.

Rückblick auf unser einfaches Beispiel Nehmen wir mal wieder an, wir hätten in unserer Firma ein Netzwerk mit einem Linux-basierten Firewall-Rechner, der unseren Benutzern nur Zugriff auf Webserver im Internet ermöglicht, ansonsten aber keinen Datenverkehr zuläßt. Wenn unser Netzwerk eine Netzmaske von 24 Bit hat (Class C) und die Adresse 172.16.1.0, würden wir folgende ipchainsRegeln benutzen: # ipchains -F forward # ipchains -P forward DENY # ipchains -A forward -s 0/0 80 -d 172.16.1.0/24 p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 80 -p tcp -b -j ACCEPT

Die erste Anweisung versetzt alle Regeln der forward-Regelsätze in einen definierten Ausgangszustand. Die zweite Anweisung stellt die Standardaktion der forward-Regelsätze auf DENY. Die letzten beiden Regeln führen die eigentliche Filterung durch. Die dritte Regel wehrt eingehende TCP-Verbindungen von Port 80 ab, während die vierte Regel Datagramme von unserem Netzwerk zu Webservern der Außenwelt (bzw. umgekehrt) passieren läßt. Wollten wir zudem ausschließlich passiven Zugriff auf FTP-Server der Außenwelt ermöglichen, würden wir folgende Regeln hinzufügen: # ipchains -A forward -s 0/0 20 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 20 -p tcp -b -j ACCEPT # ipchains -A forward -s 0/0 21 -d 172.16.1.0/24 -p tcp -y -j DENY # ipchains -A forward -s 172.16.1.0/24 -d 0/0 21 -p tcp -b -j ACCEPT

Auflisten unserer Regeln mit ipchains Um eine Liste unserer Regeln mit ipchains zu erhalten, benutzen wir die Option -L. Wie bei ipfwadm gibt es Argumente, die den Umfang der Ausgaben festlegen. In seiner einfachsten Form produziert ipchains Ausgaben, die etwa wie folgt aussehen: # ipchains -L -n Chain input (policy ACCEPT): Chain forward (policy DENY): target source destination ports DENY tcp -y---- 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT tcp ------ 172.16.1.0/24 0.0.0.0/0 80 ACCEPT tcp ------ 0.0.0.0/0 172.16.1.0/24 80 -> * ACCEPT

prot opt

tcp

* -> ------

172.16.1.0/24 172.16.1.0/24 21 ACCEPT tcp ACCEPT):

0.0.0.0/0 20 -> * ACCEPT ------ 0.0.0.0/0

* -> tcp

20 ACCEPT tcp ----------- 172.16.1.0/24 172.16.1.0/24 21 ->

0.0.0.0/0 0.0.0.0/0 * -> * Chain output (policy

Wenn Sie keine Kette angeben, erzeugt ipchains eine Liste aller Regeln in allen Ketten. Die Option -n teilt ipchains mit, daß es keine Adressen oder Ports in Namen auflösen soll. Die präsentierten Informationen sollten selbsterklärend sein. Eine ausführliche Ausgabe, bewirkt durch die Option -u, liefert wesentlich detailliertere Informationen. Seine Ausgabe enthält den Datagramm- und den Bytezähler, die AND- und XOR-Type-of-Service-Flags, den Schnittstellennamen, die Markierungswerte und die Ausgabegröße. Allen mit ipchains erzeugten Regeln werden Datagramm- und Bytezähler zugeordnet. Damit wird zum Beispiel IP-Accounting realisiert (für Details siehe Kapitel 10 IP-Accounting). Standardmäßig werden Zählerstände in gerundeter Form mit angehängtem K bzw. M für Tausender- bzw. Millionen-Einheiten ausgegeben. Bei Angabe der Option -x werden die Zählerstände dagegen ungerundet in voller Länge ausgegeben.

Sinnvolle Anwendungen von Ketten Nun wissen Sie, daß ipchains ein Ersatz für ipfwadm ist, mit einer simpleren Befehlssyntax und einigen interessanten Zusatzfunktionen. Aber zweifellos sind Sie nun neugierig geworden, was es mit den benutzerdefinierten Ketten auf sich hat und wozu sie gut sind. Vermutlich wollen Sie auch wissen, wie man die Support-Skripten benutzt, die der ipchains-Software beiliegen. Mit all diesen Fragen werden wir uns im folgenden beschäftigen. Benutzerdefinierte Ketten Die drei Regelsätze des traditionellen IP-Firewall-Codes stellten einen Mechanismus zur Bildung von Firewall-Konfigurationen zur Verfügung, die relativ einfach zu verstehen waren und zur Verwaltung kleiner Netzwerke mit einfachen FirewallAnforderungen ausreichten. Sie erweisen sich allerdings als unzureichend, wenn die Anforderungen steigen. Zum einen erfordern große Netzwerke häufig wesentlich mehr Firewall-Regeln als die wenigen, die wir bisher gesehen haben. Unvermeidlich entsteht Bedarf an Regeln für spezielle Anwendungsfälle. Mit der zunehmenden Anzahl von Regeln sinkt allerdings die Performance der Firewall, da immer mehr Datagramm-Tests durchgeführt werden. Die Frage nach einer effizienten Verwaltung der Firewall drängt daher immer mehr in den Vordergrund. Zum anderen können komplette Regelsätze nicht als Einheit (“atomar”) ein- und ausgeschaltet werden. Stattdessen sind Sie in der Zeit angreifbar, in der Sie Ihre Regelsätze aufbauen. Das Design der IP Firewall Chains hilft Ihnen, diese Probleme zu lindern, indem es dem Netzwerkadministrator gestattet, beliebige Firewall-Regelsätze zu erzeugen, die wir an die drei bereits vorhandenen Regelsätze anbinden können. Mit der Option -N können wir eine neue Kette mit beliebigem Namen aus maximal acht Zeichen erzeugen (die Beschränkung auf Kleinbuchstaben ist dabei vielleicht keine schlechte Idee). Die Option -j konfiguriert die Aktion, die durchgeführt werden soll, wenn ein Datagramm die Regel erfüllt. In diesem Fall wird es gegen eine benutzerdefinierte Kette geprüft. Wie das vor sich geht, veranschaulichen wir anhand eines Diagramms. Betrachten Sie die folgenden ipchains-Anweisungen: ipchains -P input DENY ipchains -N tcpin ipchains -A tcpin -s ! 172.16.0.0/16 ipchains -A tcpin -p tcp -d 172.16.0.0/16 ssh -j ACCEPT ipchains -A tcpin -p tcp -d 172.16.0.0/16 www -j ACCEPT ipchains -A input -p tcp -j tcpin ipchains -A input -p all

In der ersten Zeile setzen wir die Standardaktion für die Eingabe auf deny. Die zweite Anweisung erzeugt eine benutzerdefinierte Kette namens “tcpin”. Die Anweisung in der dritten Zeile fügt der tcpin-Kette eine Regel hinzu, die jedes Datagramm akzeptiert, dessen Ursprung außerhalb unseres lokalen Netzwerks liegt. Die Regel führt keine weitere Aktion durch, sondern ist lediglich eine “Abrechnungs-Regel” (accounting rule); darauf gehen wir näher in Kapitel 10 IP-Accounting, ein. Die nächsten beiden Regeln lassen alle Datagramme passieren, die für unser lokales Netzwerk bestimmt sind und die Ports ssh oder www benutzen. Die nächste Regel ist die Stelle, wo der wirkliche ipchains-Zauber beginnt. Es veranlaßt die FirewallSoftware, alle Datagramme des TCP-Protokolls gegen die benutzerdefinierte Kette tcpin zu testen. Zu guter Letzt hängen wir noch eine Accounting-Regel an unsere input-Kette an, die alle verbleibenden Datagramme “verrechnet”. Die angegebenen

Regeln erzeugen die in Abbildung 9.4 gezeigten Firewall-Ketten. Abbildung 9.4: Ein einfacher IP-Chains-Regelsatz

Unsere input- und tcpin-Ketten sind mit unseren Regeln gefüllt. Die Verarbeitung der Datagramme beginnt immer in einer der fest installierten Ketten. Wie unsere benutzerdefinierte Kette hier ins Spiel kommt, werden wir noch sehen, wenn wir die Verarbeitungsschritte der verschiedenen Datagrammtypen genauer unter die Lupe nehmen. Als erstes werfen wir einen Blick darauf, was passiert, wenn ein UDP-Datagramm für einen unserer Hosts empfangen wird. Den Datenfluß durch die Regeln illustriert Abbildung 9.5. Das Datagramm wird von der input-Kette empfangen und fällt durch die ersten beiden Regeln, da diese auf ICMP- und TCPProtokolle testen. Es paßt zwar zur dritten Regel in der input-Kette, aber diese gibt kein Ziel an, so daß nur die Datagrammund Bytezähler aktualisiert werden, aber ansonsten keine Aktion stattfindet. Das Datagramm erreicht das Ende der inputKette, die Standardregel kommt zur Anwendung und das Datagramm wird abgewiesen. Abbildung 9.5: Die Reihenfolge der für ein empfangenes UDP-Datagramm getesteten Regeln

Um unsere benutzerdefinierte Kette in Aktion zu sehen, überlegen wir uns, was passiert, wenn wir ein TCP-Datagramm empfangen, das für den ssh-Port an einem unserer Hosts bestimmt ist. Abbildung 9.6 zeigt den Ablauf. Abbildung 9.6: Die Regelfolge für ein empfangenes TCP-Datagramm für ssh

Diesmal paßt das Datagramm auf die zweite Regel der input-Kette, die als Aktion (oder Ziel) unsere Kette tcpin enthält. Die Angabe einer benutzerdefinierten Kette als Ziel bewirkt, daß das Datagramm gegen die Regeln in dieser Kette getestet wird. Die nächste zu testende Regel ist somit die erste Regel der tcpin-Kette. Sie testet alle Datagramme, deren Quelladressen außerhalb unseres lokalen Netzwerks liegen und enthält keine Aktion; sie ist somit auch eine Accounting-Regel und die Prüfung wird mit der folgenden Regel fortgesetzt. Die zweite Regel in unserer tcpin-Kette trifft zu und gibt ACCEPT als Zielanweisung vor. Wir haben somit unser Ziel erreicht, es sind keine weiteren Firewall-Maßnahmen notwendig. Das Datagramm wird akzeptiert. Zum Schluß werfen wir noch einen Blick darauf, was passiert, wenn wir das Ende einer benutzerdefinierten Kette erreichen. Dazu stellen wir den Regel-Ablauf für ein TCP-Datagramm dar, das an einen Port gerichtet ist, der nicht von unseren Regeln abgedeckt wird (siehe dazu Abbildung 9.7). Abbildung 9.7: Die Regelfolge für ein empfangenes TCP-Datagramm für telnet

Benutzerdefinierte Ketten haben keine voreingestellten Standardaktionen. Wenn alle Regeln in einer benutzerdefinierten Kette durchgetestet sind und keine passende Regel gefunden wurde, agiert der Firewall-Code so, als ob eine zusätzliche RETURNRegel vorhanden wäre. Ist das aber nicht in Ihrem Sinne, sollten Sie unbedingt noch eine Regel an das Ende Ihrer benutzerdefinierten Kette anhängen, die die von Ihnen gewünschte Standardaktion durchführt. In unserem Beispiel kehrt der ganze Testvorgang wieder zu der Regel im input-Regelsatz zurück, die unmittelbar auf die Regel folgt, die uns zu unserer benutzerdefinierten Kette verzweigt hatte. Unter Umständen erreichen wir dabei das Ende der input-Kette. Diese Kette enthält eine Standardaktion und unser Datagramm wird verworfen. Dieses Beispiel ist sehr einfach gehalten, aber veranschaulicht, worauf wir hinauswollen. Eine praktikablere Anwendung von IPChains wäre wesentlich komplexer. Für ein etwas anspruchsvolleres Beispiel siehe die folgenden Anweisungen: # # Standardaktion der Weiterleitungskette auf REJECT stellen ipchains -P forward REJECT # # benutzerdefinierte Ketten erzeugen ipchains -N sshin ipchains -N sshout ipchains -N wwwin ipchains N wwwout # # Verbindungen ablehnen, die aus falscher Richtung kommen ipchains -A wwwin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A wwwout -p tcp -d 172.16.0.0/16 -y -j REJECT ipchains -A sshin -p tcp -s 172.16.0.0/16 -y -j REJECT ipchains -A sshout -p tcp -d 172.16.0.0/16 -y -j REJECT # # alles abweisen, was durch das Sieb der benutzerdefinierten Ketten fällt ipchains -A sshin -j REJECT ipchains -A sshout -j REJECT ipchains -A wwwin -j REJECT ipchains -A wwwout -j REJECT # # www- und ssh-Dienste an die zuständigen benutzerdefinierten Ketten umleiten ipchains -A forward -p tcp -d 172.16.0.0/16 ssh -b -j sshin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 ssh -b -j sshout ipchains -A forward -p tcp -d 172.16.0.0/16 www -b -j wwwin ipchains -A forward -p tcp -s 172.16.0.0/16 -d 0/0 www -b -j wwwout # # Regeln für Hosts an Position zwei in unseren benutzerdefinierten Ketten einfügen ipchains -I wwwin 2 -d 172.16.1.2 -b -j ACCEPT ipchains -I wwwout 2 -s 172.16.1.0/24 -b -j ACCEPT ipchains -I sshin 2 -d 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.4 -b -j ACCEPT ipchains -I sshout 2 -s 172.16.1.6 -b -j ACCEPT #

In diesem Beispiel verwendeten wir eine Auswahl benutzerdefinierter Ketten, die — verglichen mit Lösungen, die nur auf den fest installierten Ketten basieren — sowohl die Verwaltung unserer Firewall-Konfiguration vereinfachen als auch die Effizienz unserer Firewall erhöhen. In unserem Beispiel werden benutzerdefinierte Ketten für die ssh- und www-Dienste für beide Verbindungsrichtungen erzeugt. In die wwwout-Kette tragen wir Regeln für die Hosts ein, die WWW-Verbindungen nach draußen aufbauen dürfen. In sshin

definieren wir Regeln für Hosts, denen wir hereinkommende ssh-Verbindungen gestatten wollen. Wir haben angenommen, daß es einen Bedarf danach gibt, einzelnen Hosts in unserem Netzwerk ssh- und www-Verbindungen zu gewähren oder zu verbieten. Das vereinfacht die Sache, denn die benutzerdefinierten Ketten haben die Möglichkeit, Regeln für ein- und ausgehenden Datenverkehr der Hosts jeweils in Gruppen zusammenzufassen, anstatt sie alle zu vermischen. Die Effizienz erhöht sich, weil sich die durchschnittliche Anzahl der notwendigen Tests für die einzelnen Datagramme reduzieren, bis eine Zielaktion gefunden wird. Das macht sich um so mehr bemerkbar, je mehr Hosts wir hinzufügen. Hätten wir keine benutzerdefinierten Ketten zur Verfügung, müßten wir unter Umständen für jedes Datagramm jeweils den gesamten Regelsatz durchkämmen, um letzlich zu entscheiden, welche Aktion ausgeführt werden soll. Selbst wenn wir annehmen, daß jede Regel in unserer Liste gleichen Anteil an der Verarbeitung aller Datagramme hätte, müßte im Durchschnitt dennoch immer den halben Regelsatz durchforstet werden. Mit benutzerdefinierten Ketten ersparen wir uns eine Menge Regeltests, wenn das getestete Datagramm die einfache Regel der built-in Kette, die zu ihnen verzweigt, schlicht und einfach nicht erfüllt. Die ipchains-Support-Skripten Die ipchains-Software wird mit drei Support-Skripten ausgeliefert. Das erste davon haben wir bereits kurz beschrieben. Die verbleibenden zwei bieten eine einfache und komfortable Möglichkeit zur Sicherung und Wiederherstellung von FirewallKonfigurationen. Das ipfwadm-wrapper-Skript bildet die Kommandozeilensyntax des ipfwadm-Befehls nach, benutzt dafür aber ipchains, um die Firewall-Regeln zu erzeugen. Das ist eine bequeme Methode, Ihre existierende Firewall-Konfiguration an Ihren neuen Kernel anzupassen oder eine Alternative zum lästigen Erlernen der ipchains-Syntax. Das Verhalten des ipfwadm-wrapper-Skripts unterscheidet sich vom ipfwadm-Befehl allerdings in zwei Punkten. Da zum einen ipchains die Spezifikation von Schnittstellen mittels IP-Adressen nicht unterstützt, akzeptiert ipfwadm-wrapper zwar das Argument -V, versucht aber, es in das ipchainsÄquivalent eines -W-Arguments zu konvertieren, indem es nach dem Namen der Schnittstelle sucht, die mit der angegebenen IP-Adresse konfiguriert wurde. Um Sie daran zu erinnern, gibt ipfwadm-wrapper immer eine Warnung aus, wenn Sie die Option -V benutzen. Zum anderen werden Accounting-Regeln für IP-Fragmente nicht korrekt übersetzt. Die Skripten ipchains-save und ipchains-restore vereinfachen die Erstellung und Änderung einer Firewall-Konfiguration erheblich. Der Befehl ipchains-save liest die aktuelle Firewall-Konfiguration ein und gibt sie in vereinfachter Form an die Standardausgabe aus. ipchains-restore liest Daten im Ausgabeformat von ipchains-save ein und konfiguriert die IP-Firewall mit diesen Regeln. Wenn Sie es vorziehen, diese Skripten zu benutzen, anstatt Ihre Firewall-Konfiguration immer wieder von Hand zu ändern und zu testen, haben Sie den Vorteil, daß Sie eine einmal erstellte Konfiguration abspeichern und nach Belieben wiederherstellen, ändern und wieder abspeichern können. Zur Anwendung dieser Skripten: Um Ihre aktuelle Firewall-Konfiguration zu speichern, geben Sie etwa folgendes ein: ipchains-save >/var/state/ipchains/firewall.state

Die Konfiguration können Sie (z.B. beim Systemstart) wie folgt wiederherstellen: ipchains-restore
Beim Einlesen prüft das ipchains-restore-Skript nach, ob irgendeine benutzerdefinierte Kette bereits existiert. Wenn Sie das Argument -f angegeben haben, werden die vorhandenen benutzerdefinierten Ketten automatisch verworfen, bevor die in der Eingabe enthaltenen Ketten konfiguriert werden. Wenn nicht, fragt das Skript nach, ob die betroffenen Ketten übersprungen oder verworfen werden sollen.

1.

Paul ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Netfilter und IP tables (2.4-Kernel) Während der Entwicklung der IP Firewall Chains entschied sich Paul Russell dafür, das IP-Firewalling weiter zu vereinfachen. Er machte es sich ziemlich bald zur Aufgabe, verschiedene Aspekte der Datagramm-Verarbeitung im Kernel-Firewall-Code einfacher zu gestalten. Das Ergebnis war ein Gebilde, das sowohl erheblich einfacher gestaltet als auch wesentlich flexibler war. Paul gab seiner neuen Konstruktion die Bezeichnung -netfilter. Hinweis Während dieses Buch geschrieben wurde, war das endgültige Design von netfilter noch nicht festgelegt. Für mögliche Unzulänglichkeiten in der Beschreibung von netfilter und seiner zugehörigen Konfigurations-Tools, deren Ursache in Änderungen begründet sind, die nach Drucklegung dieses Buches zustande kamen, bitten wir vorab um Ihr Verständnis. Wir halten die Arbeit an netfilter für so wichtig, daß wir uns trotz des laufenden Entwicklungsstandes dafür entschieden haben, dieses Thema aufzunehmen. Im Zweifelsfall verweisen wir auf die zuständigen HOWTO-Dokumente, die stets die akkuratesten und aktuellsten Informationen über netfilter enthalten.

Was war denn an den IP-Chains so verkehrt? Hatten sie nicht die Effizienz und die Verwaltung von Firewall-Regeln deutlich verbessert? Nun ja, die Art und Weise, wie sie die Datagramme verarbeiten, war immer noch ziemlich komplex, besonders in Verbindung mit Firewall-bezogenen Features wie IP-Masquerading (beschrieben in Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen) und anderen Formen der Adressenumsetzung. Diese Komplexität liegt zum Teil darin begründet, daß IP-Masquerading und Netzwerkadressenumsetzung nicht von Anfang an Bestandteil des Firewall-Codes waren, sondern zunächst unabhängig davon entwickelt und erst später darin integriert wurden. Wollte ein Entwickler neue Features für die Datagramm-Verarbeitung einführen, hätte er Probleme bekommen festzustellen, an welcher Stelle er den neuen Code einfügen sollte. Unter Umständen wäre er sogar gezwungen gewesen, dafür Teile des Kernel-Codes zu modifizieren. Es traten aber auch noch ganz andere Probleme auf. So beschreibt zum Beispiel die “Input”-Kette die Eingabe in die IPNetzwerkebene als Ganzes. Die Eingabe-Kette betraf sowohl Datagramme, die für diesen Host bestimmt waren, als auch Datagramme, die von diesem Host geroutet wurden. Das führte zur Verwirrung, da es die eigentliche Funktion der EingabeKette mit der Funktion der Weitergabe-Kette durcheinanderbrachte, die nur auf weiterzuleitende Datagramme angewendet wurde, aber immer der Eingabe-Kette folgte. Wollten Sie nun Datagramme für diesen Host anders behandeln als die nur weiterzuleitenden Datagramme, mußten Sie dafür komplexe Regeln bilden, die die einen oder anderen Datagramme wechselseitig ausschlossen. Das gleiche Problem ergab sich auch für die Ausgabe-Kette.

Ein Teil dieser Komplexität wurde unvermeidlich auf die Schultern des Netzwerkadministrators abgewälzt, da sie gerade im Design der Regelsätze deutlich in Erscheinung trat. Erschwerend kam hinzu, daß neue Filtererweiterungen direkte Änderungen im Kernel-Code notwendig machten, da alle Filteraktionen dort implementiert waren und es keine transparente Schnittstelle dafür gab. netfilter nimmt sich der Komplexität und Unflexibilität der älteren Lösungen an, indem es ein allgemeines Rahmengebilde im Kernel implementiert, das die Datagrammverarbeitung rationeller gestaltet und zudem die Möglichkeit bietet, die Filtermethoden zu erweitern, ohne daß dafür Änderungen im Kernel-Code notwendig wären. Werfen wir mal einen Blick auf zwei wesentliche Unterschiede. Abbildung 9.8 zeigt, wie Datagramme in der IP-ChainsImplementierung verarbeitet werden, während Abbildung 9.9 veranschaulicht, wie die Verarbeitung in der netfilterImplementierung vor sich geht. Die entscheidenden Unterschiede liegen zum einen in der Herauslösung der MasqueradeFunktion aus dem Kern-Code und zum anderen in der Änderung der Positionen der Eingabe- und Ausgabe-Ketten. Im Zuge dieser Änderungen wurde ein neues, erweiterbares Konfigurations-Tool namens iptables entwickelt. In IP-Chains war die Eingabe-Kette für alle vom Host empfangenen Datagramme zuständig, egal ob sie für den Host bestimmt waren oder nur von ihm an andere Hosts weitergeleitet wurden. In netfilter dagegen ist die Eingangskette nur für solche Datagramme zuständig, die direkt für diesen Host bestimmt sind. Entsprechend ist die Weitergabe-Kette hier nur für die an andere Hosts zu routenden Datagramme zuständig. Auf ähnliche Weise ist in IP-Chains die Ausgabe-Kette für alle Datagramme zuständig, die den lokalen Host verlassen, egal ob sie nun auf dem lokalen Host erzeugt oder von einem anderen Host stammen und hier nur weitergeleitet wurden. In netfilter ist die Ausgabe-Kette dagegen nur für die auf diesem Host erzeugten Datagramme zuständig und wird nicht auf Datagramme angewendet, die von anderen Hosts empfangen wurden und zur Weiterleitung bestimmt sind. Diese Änderung bedeutet eine ganz erhebliche Vereinfachung vieler FirewallKonfigurationen. Abbildung 9.8: Datagrammverarbeitende Kette in IP-Chains

In Abbildung 9.8 sind die mit “demasq” bzw. “masq” bezeichneten separaten Kernel-Komponenten verantwortlich für die eingehende bzw. ausgehende Verarbeitung von Masquerade-Datagrammen. Sie wurden in Form von netfilter-Modulen reimplementiert. Wir betrachten nun eine Konfiguration, bei der die Standardaktion für die Eingabe-, Ausgabe- und Weitergabe-Kette auf deny eingestellt ist. Um nun alle Verbindungen durch unsere Firewall zuzulassen, benötigen wir in IP-Chains sechs Regeln, jeweils zwei für die eben genannten Ketten, von denen eine die Vorwärtsrichtung und die zweite die umgekehrte Richtung abdeckt. Sie können sich vorstellen, daß dieses Vorgehen schnell sehr kompliziert und schwer zu handhaben wird, wenn Sie Verbindungen, die geroutet werden sollen, mit denen vermischen, die an den lokalen Host gerichtet sind und nicht geroutet werden müssen. Sie könnten mit IP-Chains zwar Ketten erzeugen, was diese Aufgabe ein wenig vereinfacht, jedoch ist die dafür notwendige Vorgehensweise nicht offensichtlich und erfordert zudem einiges an Sachverstand oder Geschicklichkeit. In der netfilter-Implementierung mit iptables verschwindet diese Komplexität völlig. Zum Beispiel werden für einen Dienst, der durch den Firewall-Host geroutet, aber nicht am lokalen Host enden soll, nur zwei Regeln benötigt: jeweils eine für die Vorwärtsrichtung und eine für die Rückwärtsrichtung in der Weitergabe-Kette. Das ist der intuitive Weg, Firewall-Regeln zu

gestalten, und trägt dazu bei, das Design von Firewall-Konfigurationen drastisch zu vereinfachen. Abbildung 9.9: Kette für die Datagramm-Verarbeitung in netfilter

Das PACKET-FILTERING-HOWTO enthält eine detaillierte Liste der durchgeführten Änderungen. Hier beschränken wir uns auf die eher praxisorientierten Aspekte.

Abwärtskompatibilität zu ipfwadm und ipchains Die netfilter-Implementierung in Linux ist derart flexibel, daß sie sogar imstande ist, die ältere Firewall-Software ipfwadm und ipchains zu emulieren. Das erleichtert etwas den Umstieg auf diese neue Generation von Firewall-Software. Die beiden netfilter-Kernel-Module ipfwadm.o und ipchains.o stellen die Abwärtskompatibilität zu ipfwadm und ipchains zur Verfügung. Sie dürfen immer nur eines der -beiden Module zur Zeit laden, und Sie können sie nur benutzen, wenn das Modul -ip_tables.o nicht gleichzeitig geladen ist. Sobald eines der entsprechenden Module aktiv ist, verhält sich netfilter exakt wie die frühere Firewall-Implementierung. netfilter bildet das ipchains-Interface mit folgenden Befehlen nach: rmmod ip_tables modprobe ipchains ipchains ...

Anwendung von iptables Das Utility iptables wird benutzt, um netfilter-Filterregeln zu konfigurieren. Seine Syntax lehnt sich eng an die von ipchains an, unterscheidet sich aber davon in einem wesentlichen Punkt: Sie ist erweiterbar. Das heißt, die Funktionalität kann erweitert werden, ohne daß dafür eine Neukompilierung erforderlich wäre. Dieser Trick wurde mittels Shared Libraries möglich. Es gibt bereits einige Standarderweiterungen, auf die wir teilweise noch näher eingehen werden. Bevor Sie den Befehl iptables benutzen können, müssen Sie erst das netfilter-Kernel-Modul laden, das die notwendige Unterstützung dafür bietet. Der einfachste Weg hierfür ist die Anwendung des Befehls modprobe wie folgt: modprobe ip_tables

Der Befehl iptables wird sowohl für die Konfiguration der IP-Filterung als auch der Netzwerk-Adressenumsetzung benutzt. Um diese Eigenschaft nutzen zu können, gibt es zwei Regeltabellen namens filter und nat. Wenn Sie keine -t-Option angeben,

wird automatisch die filter-Tabelle genommen. Des weiteren stehen fünf fest installierte Ketten zur Verfügung. Die Ketten INPUT und FORWARD sind für die filter-Tabelle bestimmt, während die PREROUTING- und POSTROUTINGKetten für die nat-Tabelle zur Verfügung stehen. Die OUTPUT-Kette steht beiden Tabellen zur Verfügung. In diesem Kapitel beschäftigen wir uns nur mit der filter-Tabelle. Die nat-Tabelle behandeln wir in Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen. Die allgemeine Syntax der meisten iptables-Befehle ist: iptables Befehl Regelspezifikation Erweiterungen

Nun nehmen wir einige der Optionen genauer unter die Lupe. Danach betrachten wir einige Anwendungsbeispiele. Befehle Es gibt verschiedene Wege, Regeln und Regelsätze mit dem iptables-Befehl zu bearbeiten. Die für IP-Firewalling relevanten Befehle sind: -A Chain Erweitert das Ende der bezeichneten Kette um eine oder mehrere Regeln. Falls ein Hostname als Quelle oder Ziel angegeben ist, der sich zu mehr als einer IP-Adresse auflöst, wird für jede dieser Adressen eine Regel hinzugefügt. -I Chain Regel-Nummer Fügt eine oder mehrere Regeln am Anfang der bezeichneten Kette ein. Auch hier wird für jede IP-Adresse, zu der ein angegebener Hostname resolviert, eine Regel hinzugefügt. -D Chain Entfernt eine oder mehrere Regeln aus der angegebenen Kette, die die Regelspezifikation erfüllt. -D Chain Regel-Nummer Entfernt die Regel an Position Regel-Nummer aus der angegebenen Kette. Die erste Regel der Kette hat die RegelNummer 1. -R Chain Regel-Nummer Ersetzt die Regel an Position Regel-Nummer in der angegebenen Kette durch die übergebene Regelspezifikation. -C Chain Testet ein durch die Regelspezifikation beschriebenes Datagramm gegen die angegebene Kette. Diese Anweisung liefert eine Meldung zurück, wie das Datagramm von der Kette verarbeitet wurde. Sie ist sehr nützlich zum Testen von Firewall-Konfigurationen. Darauf gehen wir später im Detail ein. -L [Chain] Listet die Regeln der angegebenen Kette auf (oder die Regeln aller Ketten, falls keine Kette angegeben ist). -F [Chain] Aktualisiert die Regeln der angegebenen Kette (oder für alle Ketten, falls keine bestimmte angegeben ist). -Z [Chain]

Setzt die Datagramm- und Bytezähler aller Regeln der angegebenen Kette auf null (oder für alle Ketten, falls keine bestimmte angegeben ist). -N Chain Erzeugt eine neue Kette mit der angegebenen Bezeichnung (es darf allerdings keine Kette mit gleichem Namen existieren). Hiermit werden benutzerdefinierte Ketten erzeugt. -X [Chain] Entfernt die angegebene benutzerdefinierte Kette (oder alle benutzerdefinierten Ketten, falls keine bestimmte angegeben ist). Damit diese Anweisung tatsächlich ausgeführt wird, darf es keine Referenzen von irgendeiner anderen Regel-Kette auf diese Kette geben. -P Chain Standardaktion Setzt die Standardaktion der angegebenen Kette auf die angegebene Aktion. Zulässige Firewalling-Aktionen sind ACCEPT, DROP, QUEUE und RETURN. ACCEPT gewährt dem Datagramm Durchlaß. DROP verwirft das Datagramm. QUEUE reicht das Datagramm zur Weiterverarbeitung in den Benutzerbereich weiter. RETURN bewirkt, daß die Ausführung des Firewall-Codes direkt im Anschluß an die aufrufende Regel fortgesetzt wird, in der ersten ihr unmittelbar nachfolgenden Regel der Kette, die die Ausgangsregel aufrief. Parameter zur Regelspezifikation Zur Bildung einer Regelspezifikation gibt es eine Reihe von iptables-Parametern. Wo immer eine Regelspezifikation benötigt wird, muß jeder dieser Parameter angegeben werden, oder es wird sein jeweiliger Vorgabewert eingesetzt. -p [!]Protokoll Spezifiziert das Protokoll des Datagramms, das zu dieser Regel paßt. Zulässige Protokollnamen sind tcp, udp und icmp. Sie können hier auch eine IP-Protokollnummer angeben.1 Beispielsweise könnten Sie 4 angeben, um die jeweilige Regel auf Datagramme dieses IP-über-IP-Protokolls (ipip-Encapsulation-Protokolls) anzuwenden. Wenn Sie das Zeichen ! mit angeben, wird die Regel negiert, und es wird nur gegen Datagramme anderer Protokolle getestet. Ist dieser Parameter überhaupt nicht angegeben, sind alle Protokolle zugelassen. -s [!]Adresse[/Netzmaske] Spezifiziert die Quelladresse des Datagramms, das zu dieser Regel paßt. Die Adresse kann als Hostname, Netzwerkname oder IP-Adresse angegeben werden. Die optionale Netzmaske kann entweder in traditioneller Form (z.B. /255.255.255.0) oder in moderner Form (z.B. /24) angegeben werden. -d [!]Adresse[/Netzmaske] Spezifiziert die Zieladresse des Datagramms, das zu dieser Regel paßt. Beide Größen werden wie beim Parameter -s angegeben. -j Ziel Spezifiziert die durchzuführende Aktion, wenn diese Regel paßt. Die Regel können Sie gewissermaßen als “GOTO”Anweisung auffassen, deren Zielanweisung eine der folgenden ist: ACCEPT, DROP, QUEUE und RETURN.Die Bedeutung dieser Ziele haben wir bereits im Abschnitt “Befehle” beschrieben. Sie können hier auch den Namen einer benutzerdefinierten Kette angeben, in der die Abarbeitung fortgesetzt werden soll. Außerdem können Sie ein Ziel angeben, das von einer Erweiterung stammt. Über Erweiterungen sprechen wir noch in Kürze. Fehlt der Parameter, findet für die Datagramme überhaupt keine Aktion statt. Es werden lediglich der Datagramm- und der Bytezähler

aktualisiert. -i [!]Schnittstelle Spezifiziert die Schnittstelle, von der ein Datagramm empfangen wird. Auch hier dient ! zur Negierung des Vergleichstests. Endet der Schnittstellen-Bezeichner mit +, gilt die Regel für alle Schnittstellen, deren Name mit der angegebenen Zeichenfolge beginnt. Beispielsweise bezeichnet der Ausdruck -i ppp+ alle PPP-Netzwerkgeräte. Der Ausdruck -i ! eth+ bezeichnet dagegen alle Schnittstellen mit Ausnahme der Ethernet-Geräte. -o [!]Schnittstelle Spezifiziert die Schnittstelle, an die ein Datagramm gesendet werden soll. Die Notation ist dieselbe wie bei der Option i. [!] -f Gibt an, daß die Regel auf alle Fragmente eines fragmentierten Datagramms — mit Ausnahme des ersten Fragments — angewendet werden soll. Optionen Die folgenden iptables-Optionen sind allgemeiner Natur. Einige von ihnen steuern ziemlich ausgefallene Features der netfilterSoftware: -v Veranlaßt iptables zur Ausgabe detaillierter Informationen. -n Bewirkt, daß iptables IP-Adressen und Ports nur als Nummern ausgibt, ohne sie in ihre entsprechenden Hostnamen aufzulösen. -x Bewirkt, daß jeder Zahlenwert in der iptables-Ausgabe exakt, also ohne Auf- oder Abrunden, angezeigt wird. - -line-numbers Bewirkt die Ausgabe von Zeilennummern beim Auflisten von Regelsätzen. Die Zeilennummern geben immer die Regelpositionen innerhalb der Kette an. Erweiterungen Wir hatten bereits erwähnt, daß das Utility iptables mittels optionaler Shared-Library-Module erweiterbar ist. Es gibt einige Standarderweiterungen, die einige der Features von ipchains zur Verfügung stellen. Um eine solche Erweiterung anwenden zu können, müssen Sie ihren Namen im Argument -m name an iptables übergeben. Die folgende Liste zeigt Ihnen die Verwendung der Optionen -m und -p, die den Kontext der jeweiligen Erweiterung angeben, sowie die Optionen, die diese Erweiterung zur Verfügung stellt: TCP-Erweiterungen mit -m tcp -p tcp

- -sport [!] [Port[:Port]] Gibt den Quell-Port, den das Datagramm für diese Regel haben muß, an. Es können auch Bereiche für Ports angegeben

werden, indem die Unter- und die Obergrenze durch einen Doppelpunkt getrennt aufgeführt werden. So beschreibt zum Beispiel der Ausdruck 20:25 alle Ports zwischen 20 und 25 (inklusive). Auch hier kann das Zeichen ! zur Negierung eingesetzt werden. - -dport [!] [Port[:Port]] Gibt den Ziel-Port, den das Datagramm für diese Regel haben muß, an. Die Notation ist dieselbe wie bei der Option - sport. - -tcp-Flags [!] Maske Liste Gibt an, daß die Regel das Datagramm verarbeiten soll, wenn dessen TCP-Flags mit denen in Maske und Liste übereinstimmen. Maske ist eine Liste von Flags (die durch Kommata getrennt sind), die im Testfall geprüft werden sollen. Liste ist eine Liste von Flags (ebenfalls durch Kommata getrennt), die im Datagramm auf jeden Fall gesetzt sein müssen, damit es von der Regel verarbeitet wird. Zulässige Flags sind: SYN, ACK, FIN, RST, URG, PSH, ALL und NONE. Hierbei handelt es sich um eine erweiterte Option. Für eine Beschreibung der Bedeutung und der Auswirkungen dieser Flags sollten Sie eine gute Beschreibung des TCP-Protokolls heranziehen, zum Beispiel RFC793. Das Zeichen ! negiert die Regel. [!] - -syn Bewirkt, daß die Regel nur solche Datagramme behandelt, deren SYN-Bit gesetzt und deren ACK- und FIN-Bit nicht gesetzt ist. Hierbei handelt es sich um Datagramme, die TCP-Verbindungen aufzubauen versuchen. Daher kann diese Option zur Steuerung von Verbindungsanforderungen benutzt werden. Diese Option ist eine Abkürzung für: - -tcp-flags SYN,RST,ACK SYN

Wenn Sie den Negierungsoperator benutzen, verarbeitet die Regel nur Datagramme, bei denen nicht beide SYN- und ACK-Bits gesetzt sind. UDP-Erweiterungen mit -m udp -p udp

- -sport [!] [Port[:Port]] Spezifiziert den Quell-Port, den das Datagramm für diese Regel haben muß. Ports können hier auch bereichsweise angegeben werden, und zwar in Form einer Untergrenze, gefolgt von einem Doppelpunkt, gefolgt von einer Obergrenze. So beschreibt zum Beispiel der Ausdruck 20:25 alle Ports zwischen 20 und 25 (inklusive). Auch hier kann das Zeichen ! zur Negierung eingesetzt werden. - -dport [!] [Port[:Port]] Spezifiziert den Ziel-Port, den das Datagramm für diese Regel haben muß. Die Notation ist dieselbe wie bei der Option -sport. ICMP-Erweiterungen mit -m icmp -p icmp

- -icmp-type [!] Typname Spezifiziert die Art der ICMP-Nachricht, die diese Regel verarbeitet. Sie kann in Form einer Nummer oder als Name angegeben werden. Einige zulässige Namen sind: echo-request, echo-reply, source-quench, timeexceeded, destination-unreachable, network-unreachable, host-unreachable, protocolunreachable sowie port-unreachable. MAC-Erweiterungen mit -m mac

- -mac-source [!] Adresse

Legt die Ethernet-Adresse des Hosts fest, die das von dieser Regel zu verarbeitende Datagramm überträgt. Diese Option macht nur Sinn in einer Regel der Eingabe- oder Weitergabe-Kette, da wir grundsätzlich jedes Datagramm übertragen, das die Ausgabe-Kette passiert.

Erneuter Rückblick auf unser einfaches Beispiel Zur Implementierung unseres “naiven” Beispiels, diesmal mit netfilter, könnten Sie einfach das Kernel-Modul ipchains.o laden und so tun, als ob es eine echte ipchains-Version wäre. Aber wir gehen hier einen anderen Weg und implementieren das Beispiel direkt mit iptables, um zu zeigen, wie ähnlich es ist. Wir nehmen wieder an, daß wir ein Netzwerk in unserer Firma haben und einen Linux-basierten Firewall-Rechner benutzen, um unseren Anwendern Zugriffe auf WWW-Server im Internet zu ermöglichen, dabei aber jeglichen anderen Datenverkehr zu unterbinden. Wenn unser Netzwerk eine 24-Bit-Netzmaske (Class C) und die IP-Adresse 172.16.1.0 hat, würden wir folgende iptablesRegeln benutzen: # modprobe ip_tables # iptables -F FORWARD # iptables -P FORWARD DROP # iptables -A FORWARD -m tcp -p tcp -s 0/0 --sport 80 -d 172.16.1.0/24 \ --syn -j DROP # iptables -A FORWARD -m tcp -p tcp s 172.16.1.0/24 --sport \ 80 -d 0/0 -j ACCEPT # iptables -A FORWARD -m tcp -p tcp -d 172.16.1.0/24 --dport 80 -s 0/0 -j \ ACCEPT

In diesem Beispiel werden die iptables-Befehle exakt wie beim äquivalenten ipchains-Kommando interpretiert. Der wesentliche Unterschied besteht aber darin, daß vorher erst das Kernel-Modul ip_tables.o korrekt geladen werden muß. Beachten Sie, daß iptables die Option -b nicht unterstützt, weswegen wir für jede Richtung eine Regel angeben müssen.

1.

Werfen Sie einen Blick in die Datei /etc/protocols. Dort finden Sie einige Protokollnamen und -nummern.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

TOS-Bit-Manipulation Die Type-of-Service-Bits (TOS) sind eine Menge von vier Bit-Flags im IP-Header. Ist eines dieser Flags gesetzt, können die Datagramme von Routern durchaus anders gehandhabt werden als Datagramme, bei denen das nicht der Fall ist. Jedes Bit erfüllt seinen bestimmten Zweck, und nur eines von ihnen darf gleichzeitig gesetzt sein, Kombinationen sind also nicht erlaubt. Die Bits werden Type-of-Service-Bits genannt, da sie es der übertragenden Applikation ermöglichen, dem Netzwerk mitzuteilen, welche Art von Dienstgüte gerade benötigt wird. Die verschiedenen Klassen verfügbarer Dienstgüte sind: Minimale Verzögerung (minimum delay) Wird benutzt, wenn die Übertragungsdauer eines Datagramms vom Quell-Host zum Ziel-Host von größter Wichtigkeit ist. Ein Netzwerk-Provider könnte zum Beispiel sowohl optische Glasfaser- als auch Satelliten-Netzwerkverbindungen benutzen wollen. Da die Daten bei einer Übertragung über Satelliten eine größere Entfernung zurücklegen müssen, dauert der Transport zwischen denselben Enpunkten normalerweise länger als bei einer terrestrischen Übertragung. Der Netzwerk-Provider würde diese Option benutzen, um sicherzustellen, daß Datagramme mit diesem Type-of-Service nicht per Satellit übertragen werden.

Maximaler Durchsatz (maximum throughput) Wird benutzt, wenn der Umfang der zu übertragenden Daten zu jedem Zeitpunkt wichtig ist. Es gibt viele Arten von Netzwerkapplikationen, bei denen die Datenverzögerung nicht so sehr im Vordergrund steht, dafür aber der Netzwerkdurchsatz. Ein Beispiel dafür sind MassenDateitransfers. Ein Netzwerk-Provider könnte entscheiden, daß Datagramme mit diesem TypeOf-Service über Wege geleitet würden, die die Daten zwar stark verzögern, aber eine große Bandbreite bieten, z.B. über Satelittenverbindungen. Maximale Zuverlässigkeit (maximum reliability) Wird benutzt, wenn Daten von der Quelladresse bis zur Zieladresse möglichst zuverlässig übertragen werden sollen, so daß keine wiederholten Übertragungen einzelner Datenpakete notwendig werden. Das IP-Protokoll kann von beliebig vielen zugrundeliegenden Transportmedien übertragen werden. Während zum Beispiel SLIP und PPP als Verbindungsprotokolle ganz brauchbar sind, können sie aber mit anderen IP-fähigen Netzwerken wie X.25, was die Zuverlässigkeit angeht, nicht mithalten. Ein Netzwerk-Provider könnte für diesen Type-of-Service ein alternatives Netzwerk vorgesehen haben, um es für besonders sichere Datenübertragungen einzusetzen. Minimale Kosten (minimum cost) Wird benutzt, wenn es wichtig ist, die Kosten für die Datenübertragung so gering wie möglich zu halten. Die Miete von Bandbreite auf einem Satelliten für eine transpazifische Übertragung ist grundsätzlich günstiger als die Miete für ein Glasfaser-Kabel über dieselbe Distanz. Ein Netzwerk-Provider könnte Ihnen Zugang zu beiden Übertragungsmöglichkeiten anbieten, für die Sie dann unterschiedlich zu bezahlen hätten. In einem solchen Szenario könnte Ihr “minimum-cost”-Type-of-Service-Bit dafür sorgen, daß das Datagramm über die günstigere Satellitenverbindung geroutet wird.

Setzen der TOS-Bits mit ipfwadm oder ipchains Die Befehle ipfwadm und ipchains behandeln die TOS-Bits auf ziemlich ähnliche Weise. In beiden Fällen spezifizieren Sie eine Regel, die Datagramme mit bestimmten TOS-Bit-Einstellungen behandelt, und benutzen die Option -t, um die gewünschte Änderung durchzuführen. Die Änderungen werden mittels zwei Bit-Masken vollzogen. Die erste dieser beiden Bitmasken wird mit dem Type-Of-Service-Feld im IP-Header des Datagramms logisch UND-verknüpft. Das Ergebnis wird anschließend mit der zweiten Bitmaske logisch XOR-verknüpft. Wenn sich das für Sie kompliziert anhört, geben wir Ihnen gleich ein Rezept, wie Sie die verschiedenen Type-of-Services einstellen können. Die Bitmasken werden als 8-Bit-Hexadezimalzahlen angegeben. Sowohl ipfwadm als auch ipchains nutzen dieselbe Syntax für die Argumente:

-t UND-Maske XOR-Maske

Zum Glück können dieselben Masken-Argumente dazu benutzt werden, einen bestimmten Type-ofService einzustellen, so daß Sie darüber nicht immer wieder nachdenken müssen. Sie sind zusammen mit einigen Anwendungsempfehlungen in Tabelle 9.3 dargestellt. Tabelle 9.3: Empfohlene Anwendungen von TOS-Bitmasken TOS

UND-Maske XOR-Maske Empfohlene Anwendung

Minimum Delay

0x01

0x10

ftp, telnet, ssh

Maximum Throughput 0x01

0x08

ftp-data, www

Maximum Reliability 0x01

0x04

snmp, dns

Minimum Cost

0x02

nntp, smtp

0x01

Setzen der TOS-Bits mit iptables Das Tool iptables ermöglicht Ihnen die Spezifikation von Regeln, die nur solche Datagramme verarbeiten, deren TOS-Bits zu manchen mit der Option -m tos vorbestimmten Werten passen. Außerdem können Sie mit der Option -j TOS die TOS-Bits solcher Datagramme setzen. Sie dürfen die TOS-Bits allerdings nur in der FORWARD- und in der OUTPUT-Kette setzen. Das Testen und Setzen dieser Bits geschieht weitgehend unabhängig voneinander. Sie können damit alle möglichen interessanten Regeln konfigurieren, zum Beispiel eine Regel, die alle Datagramme mit einer bestimmten TOS-Bit-Kombination abwehrt, oder eine Regel, die die TOS-Bits nur für Datagramme von einem bestimmten Host setzt. In den meisten Fällen werden Sie Regeln benutzen, die beides machen, sowohl Testen als auch Setzen von TOS-Bits, um TOS-Bit-Übersetzungen durchzuführen, wie Sie es bei ipfwadm oder ipchains tun könnten. Im Gegensatz zur etwas komplizierten Zwei-Masken-Konfiguration von ipfwadm und ipchains benutzt iptables einen simpleren Ansatz, bei dem man ohne Umschweife direkt angeben kann, welche TOS-Bits getestet bzw. wie sie gesetzt werden sollen. Außerdem brauchen Sie sich keine hexadezimalen Werte zu merken, sondern Sie können dafür leicht zu behaltende Begriffe einsetzen, wie sie in der folgenden Tabelle aufgelistet sind. Die allgemeine Syntax zum Testen der TOS-Bits lautet: -m tos --tos Begriff [andere-Argumente] -j Ziel

Die allgemeine Syntax zum Setzen der TOS-Bits lautet: [andere-Argumente] -j TOS --set Begriff

Es sei daran erinnert, daß diese Anweisungen normalerweise zusammen benutzt werden. Sie können

sie aber auch unabhängig voneinander anwenden, falls Sie eine Konfiguration haben, die eine solche Vorgehensweise notwendig macht. Begriff

Hexadezimal

Normal-Service

0x00

Minimize-Cost

0x02

Maximize-Reliability 0x04 Maximize-Throughput 0x08 Minimize-Delay

0x10

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Testen einer Firewall-Konfiguration Nachdem Sie eine angemessene Firewall-Konfiguration entworfen haben, ist es wichtig zu prüfen, ob sie sich tatsächlich so verhält, wie Sie es beabsichtigt haben. Eine Möglichkeit dafür ist, mit einem Host außerhalb Ihres Netzwerks zu versuchen, Ihre Firewall zu durchbrechen. Das kann eine ziemlich mühselige Angelegenheit werden und erfordert zudem viel Zeit. Außerdem können Sie nur die IP-Adressen testen, die Ihnen zur Verfügung stehen. Eine schnellere und einfachere Methode bietet die Linux-Firewall-Software selbst. Sie gestattet Ihnen, Tests von Hand zu erzeugen und sie durch die Firewall-Konfiguration laufen zu lassen, als ob Sie mit echten Datagrammen arbeiten würden. Alle Firewall-Software-Varianten, sei es ipfwadm, ipchains oder iptables, bieten Unterstützung für diese Art von Tests. Die Umsetzung der Tests baut auf dem jeweiligen check-Befehl auf. Das grundsätzliche Testverfahren funktioniert so: 1. Gestalten und konfigurieren Sie Ihre Firewall mit ipfwadm, ipchains oder iptables. 2. Entwerfen Sie eine Reihe von Tests, die feststellen, ob Ihre Firewall nach Ihren Vorstellungen funktioniert. Für diese Tests können Sie beliebige Quell- und Zieladressen verwenden; wählen Sie also einige Adreßkombinationen, die akzeptiert werden sollten, und andere, die abgewiesen werden sollten. Wollen Sie bestimmte Adreßbereiche gewähren oder aussperren, ist es eine gute Idee, gerade solche Adressen zu testen, die nah an der Grenze liegen — eine Adresse knapp innerhalb des Bereichs und eine Adresse knapp außerhalb. Das hilft Ihnen sicherzustellen, daß Sie die Grenzen korrekt konfiguriert haben, da es durchaus passieren kann, daß Sie in Ihrer Konfiguration manchmal die Netzmasken falsch angeben. Führen Sie auch Filterungen nach Protokollen und Portnummern durch, sollten Sie in Ihren Tests auch alle wichtigen Kombinationsmöglichkeiten dieser Parameter durchspielen. Wollen Sie beispielsweise unter gewissen Umständen nur TCP-Pakete durchgehen lassen, testen Sie, ob die UDP-Datagramme abgewiesen werden. 3. Formulieren Sie Regeln für ipfwadm, ipchains oder iptables, um die Tests zu implementieren. Es lohnt sich vielleicht, alle diese Regeln in ein Skript zu schreiben, so daß Sie die Regeln leicht wiederholt testen können, nachdem Sie die notwendigen Korrekturen oder Änderungen durchgeführt haben. Die Tests benutzen fast

dieselbe Syntax wie die Regelspezifikationen, nur die Argumente haben eine etwas andere Bedeutung. Zum Beispiel gibt die Quelladresse in einer Regelspezifikation die Quelladresse an, die die Datagramme haben müssen, um von der Regel verarbeitet zu werden. Bei der Quelladresse in der Testsyntax hingegen handelt es sich um die Quelladresse, die für das zu testende Datagramm erzeugt wird. Bei ipfwadm müssen Sie die Option –c angeben, damit dieser Befehl zu einem Test wird. Bei ipchains und iptables dagegen müssen Sie dafür die Option –C nehmen. Wie auch immer, in allen Fällen müssen Sie immer die Quelladresse, die Zieladresse, das Protokoll sowie die Schnittstelle angeben, die für den Test benutzt werden sollen. Weitere Argumente, wie Portnummern und TOS-Bit-Einstellungen, sind optional. 4. Führen Sie jeden Testbefehl aus, und notieren Sie sich die Ausgaben. Die Ausgabe jedes Tests besteht aus einem einzigen Wort, nämlich der endgültigen Zieladresse der für das Datagramm auszuführenden Aktion, nachdem es die gesamte Firewall-Konfiguration durchlaufen hat. Bei ipchains und iptables werden außer den fest installierten Ketten auch die benutzerdefinierten Ketten getestet. 5. Vergleichen Sie die Ausgaben jedes Tests mit den gewünschten Resultaten. Gibt es da irgendwelche Diskrepanzen, müssen Sie Ihren Regelsatz nochmals analysieren, um festzustellen, wo Sie einen Fehler gemacht haben. Wenn Sie Ihre Testanweisungen in ein Skript geschrieben haben, können Sie die ganzen Testläufe nach den Korrekturen sehr leicht wiederholen. Es ist eine gute Idee, immer erst alle vorhandenen Regelsätze zu verwerfen und die benötigten Regelsätze immer wieder neu zu bilden, statt die Änderungen dynamisch durchzuführen. Das hilft Ihnen sicherzustellen, daß die aktive Konfiguration, die Sie gerade testen, tatsächlich die Befehlsmenge in Ihrem Konfigurationsskript widerspiegelt. Werfen wir einen schnellen Blick darauf, wie ein einfaches Testskript für unser simples Beispiel mit ipchains aussehen könnte. Sie erinnern sich sicher daran, daß unser lokales Beispielnetzwerk die Adresse 172.16.1.0 mit der Netzmaske 255.255.255.0 hatte und wir nur TCP-Verbindungen zu netzwerkfremden Webservern gestatten wollten. Wir beginnen unseren Test mit einer Übertragung, von der wir wissen, daß sie funktionieren sollte, und zwar mit einer Verbindung von einem lokalen Host zu einem Webserver außerhalb: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 accepted

Beachten Sie die angegebenen Argumente und die Art und Weise, wie sie benutzt werden, um ein Datagramm zu beschreiben. Die Ausgabe dieses Befehls zeigt an, daß das Datagramm zur Weitergabe akzeptiert wurde, was wir auch erwartet hatten. Versuchen Sie nun einen anderen Host, diesmal mit einer Hostadresse, die nicht zu unserem Netzwerk gehört. Dies sollte abgewiesen werden: # ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0 denied

Versuchen Sie einige weitere Tests, diesmal mit denselben Details wie beim ersten Test, aber mit anderen Protokollen. Sie sollten ebenfalls alle abgewiesen werden: # ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied # ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0 denied

Nehmen Sie einen anderen Ziel-Port, der erneut abgewiesen werden sollte: # ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0 denied

Sie haben nun vielleicht einen langen Weg mit umfassenden Tests vor sich, bis Sie sich endlich sicher fühlen. Obwohl das Ganze manchmal genauso schwierig sein kann wie das Design der Firewall-Konfiguration selbst, ist es nichtsdestotrotz der beste Weg, um festzustellen, ob Ihr Design Ihnen das Maß an Sicherheit bietet, das Sie sich versprochen haben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Beispiel einer Firewall-Konfiguration Wir haben nun ausführlich die Grundlagen der Firewall-Konfiguration besprochen. Nun sehen wir uns mal an, wie eine tatsächliche Firewall-Konfiguration aussehen könnte. Die Konfiguration in diesem Beispiel wurde so entworfen, daß sie leicht erweitert und angepaßt werden kann. Wir stellen hier drei Versionen zur Verfügung. Die erste Version wurde mit ipfwadm implementiert (oder mit dem ipfwadm-wrapper-Skript). Die zweite Version ist für ipchains geschrieben, und die dritte Version benutzt iptables. Das Beispiel versucht nicht, alle Möglichkeiten benutzerdefinierter Ketten auszuschöpfen, zeigt Ihnen aber die Ähnlichkeiten und Unterschiede zwischen den Sprachstilen der alten und neuen Firewall-Konfigurations-Tools: #!/bin/bash ########################################################################## # IPFWADMVERSION # Dieses Beispiel ist eine Firewall-Konfiguration für einen einzelnen Host. # Der FirewallRechner stellt keine Netzwerkdienste zur Verfügung. ########################################################################## # BEGINN DER BENUTZERKONFIGURATION # Der Name und Ort des ipfwadm-Programms. Verwenden Sie ipfwadm-wrapper # für 2.2.*-Kernel. IPFWADM=ipfwadm # Pfad zur ausführbaren ipfwadm-Datei. PATH="/sbin" # Unser interner Netzwerkadreßraum und die Schnittstelle dafür. OURNET="172.29.16.0/24" OURBCAST="172.29.16.255" OURDEV="eth0" # Die externe Adresse und die Schnittstelle dafür. ANYADDR="0/0" ANYDEV="eth1" # Die TCP-Dienste, die wir erlauben wollen - "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt TCPIN="smtp www" TCPOUT="smtp www ftp ftp-data irc" # Die UDP-Dienste, die wir erlauben wollen - "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt UDPIN="domain" UDPOUT="domain" # Die ICMP-Dienste, die wir erlauben wollen "" leer bedeutet: alle Typen # Siehe /usr/include/netinet/ip_icmp.h für Typnummern # Achtung: durch Leerzeichen getrennt ICMPIN="0 3 11" ICMPOUT="8 3 11" # Protokollierung. Entfernen Sie das Kommentarzeichen, um die Protokol- # lierung von Datagrammen zu aktivieren, die von der Firewall blockiert werden. # LOGGING=1 # ENDE DER BENUTZERKONFIGURATION ########################################################################### # Löschen aller Regeln in der Eingangs-Tabelle. $IPFWADM -I -f # Eingehende Zugriffe wehren wir standardmäßig ab. $IPFWADM -I -p deny # SPOOFING # Wir sollten keine Datagramme von außen akzeptieren, deren Quelladresse # zu unserem Netzwerk gehört, also blockieren wir sie. $IPFWADM -I -a deny -S $OURNET W $ANYDEV # SMURF # Wir verbieten ICMP zu unserer Broadcast-Adresse, um "Smurf"-artige # Attacken zu verhindern. $IPFWADM -I -a deny -P icmp -W $ANYDEV -D $OURBCAST # TCP # Wir akzeptieren alle TCP-Datagramme, die zu einer existierenden # Verbindung gehören (d.h. deren ACK-Bit gesetzt ist), für Ports, zu denen # wir Durchgang gewähren. # Das sollte auf mehr als 95% aller gültigen TCPPakete zutreffen. $IPFWADM -I -a accept -P tcp -D $OURNET $TCPIN -k -b # TCP - EINGEHENDE VERBINDUNGEN # Wir akzeptieren Verbindungsanfragen von der Außenwelt nur an den # erlaubten Ports. $IPFWADM -I -a accept -P tcp -W $ANYDEV -D $OURNET $TCPIN -y # TCP - AUSGEHENDE VERBINDUNGEN # Wir

gestatten alle ausgehenden TCP-Verbindungsanforderungen # an erlaubten TCP-Ports. $IPFWADM -I -a accept -P tcp -W $OURDEV -D $ANYADDR $TCPOUT -y # UDP - EINGEHEND # Wir akzeptieren eingehende UDPDatagramme an den erlaubten Ports. $IPFWADM -I -a accept -P udp -W $ANYDEV -D $OURNET $UDPIN # UDP - AUSGEHEND # Wir gestatten ausgehende UDP-Datagramme an den erlaubten Ports. $IPFWADM -I -a accept -P udp -W $OURDEV -D $ANYADDR $UDPOUT # ICMP - EINGEHEND # Wir akzeptieren eingehende ICMPDatagramme der erlaubten Typen. $IPFWADM -I -a accept -P icmp -W $ANYDEV -D $OURNET $UDPIN # ICMP AUSGEHEND # Wir gestatten ausgehende ICMP-Datagramme der erlaubten Typen. $IPFWADM -I -a accept -P icmp -W $OURDEV -D $ANYADDR $UDPOUT # DEFAULT und LOGGING # Alle verbleibenden Datagramme werden an die Standardregel durch- # gereicht und verworfen. Sie werden protokolliert, falls Sie die # oben beschriebene LOGGING-Variable entsprechend konfiguriert haben. # if [ "$LOGGING" ] then # Abgewiesenes TCP protokollieren $IPFWADM -I -a reject -P tcp -o # Abgewiesenes UDP protokollieren $IPFWADM -I -a reject -P udp -o # Abgewiesenes ICMP protokollieren $IPFWADM I -a reject -P icmp -o fi # # end.

Nun implementieren wir dieses Beispiel noch einmal mit dem ipchains-Befehl: #!/bin/bash ########################################################################## # IPCHAINSVERSION # Dieses Beispiel ist eine Firewall-Konfiguration für einen einzelnen Host. # Der FirewallRechner stellt keine Netzwerkdienste zur Verfügung. ########################################################################## # BEGINN DER BENUTZERKONFIGURATION # Name und Ort des ipchains-Programms. IPCHAINS=ipchains # Pfad zur ausführbaren ipchains-Datei. PATH="/sbin" # Unser interner Netzwerkadreßraum und die Schnittstelle dafür. OURNET="172.29.16.0/24" OURBCAST="172.29.16.255" OURDEV="eth0" # Die externe Adresse und die Schnittstelle dafür. ANYADDR="0/0" ANYDEV="eth1" # Die TCP-Dienste, die wir erlauben wollen "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt TCPIN="smtp www" TCPOUT="smtp www ftp ftp-data irc" # Die UDP-Dienste, die wir erlauben wollen - "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt UDPIN="domain" UDPOUT="domain" # Die ICMP-Dienste, die wir erlauben wollen - "" leer bedeutet: alle Typen # Siehe /usr/include/netinet/ip_icmp.h für Typnummern # Achtung: durch Leerzeichen getrennt ICMPIN="0 3 11" ICMPOUT="8 3 11" # Protokollierung. Entfernen Sie das Kommentarzeichen, um die Protokol- # lierung von Datagrammen zu aktivieren, die von der Firewall blockiert werden. # LOGGING=1 # ENDE DER BENUTZERKONFIGURATION ########################################################################## # Löschen aller Regeln in der Eingangs-Tabelle. $IPCHAINS -F input # Eingehende Zugriffe wehren wir standardmäßig ab. $IPCHAINS -P input deny # SPOOFING # Wir sollten keine Datagramme von außen akzeptieren, deren Quelladresse # zu unserem Netzwerk gehört, also blockieren wir sie. $IPCHAINS -A input -s $OURNET i $ANYDEV -j deny # SMURF # Wir verbieten ICMP zu unserer Broadcast-Adresse, um "Smurf"-artige # Attacken zu verhindern. $IPCHAINS -A input -p icmp -w $ANYDEV -d $OURBCAST -j deny # Fragmente sollten wir akzeptieren. In ipchains müssen wir das # explizit verlangen. $IPCHAINS -A input -f -j accept # TCP # Wir akzeptieren alle TCP-Datagramme, die zu einer existierenden # Verbindung gehören (d.h. deren ACK-Bit gesetzt ist), für Ports, zu denen # wir Durchgang gewähren. # Das sollte auf mehr als 95% aller gültigen TCP-Pakete zutreffen. $IPCHAINS -A input -p tcp -d $OURNET $TCPIN ! -y -b -j accept # TCP - EINGEHENDE VERBINDUNGEN # Wir akzeptieren Verbindungsanfragen von der Außenwelt nur an den # erlaubten Ports. $IPCHAINS -A input -p tcp -i $ANYDEV -d $OURNET $TCPIN y -j accept # TCP - AUSGEHENDE VERBINDUNGEN # Wir gestatten alle ausgehenden TCPVerbindungsanforderungen # an erlaubten TCP-Ports. $IPCHAINS -A input -p tcp -i $OURDEV -d $ANYADDR $TCPOUT -y -j accept # UDP - EINGEHEND # Wir akzeptieren eingehende UDP-Datagramme an den erlaubten Ports. $IPCHAINS -A input -p udp -i $ANYDEV -d $OURNET $UDPIN -j accept # UDP AUSGEHEND # Wir gestatten ausgehende UDP-Datagramme an den erlaubten Ports. $IPCHAINS -A input -p udp -i $OURDEV -d $ANYADDR $UDPOUT -j accept # ICMP - EINGEHEND # Wir akzeptieren eingehende ICMPDatagramme der erlaubten Typen. $IPCHAINS -A input -p icmp -w $ANYDEV -d $OURNET $UDPIN -j accept # ICMP - AUSGEHEND # Wir gestatten ausgehende ICMP-Datagramme der erlaubten Typen. $IPCHAINS -A input -p icmp -i $OURDEV -d $ANYADDR $UDPOUT -j accept # DEFAULT und LOGGING # Alle verbleibenden Datagramme werden an die Standardregel durch- # gereicht und verworfen. Sie werden protokolliert, falls Sie die # oben beschriebene LOGGING-Variable entsprechend konfiguriert haben. # if [ "$LOGGING" ] then # Abgewiesenes TCP protokollieren $IPCHAINS -A input -p tcp -l -j reject # Abgewiesenes UDP protokollieren $IPCHAINS -A input -p udp -l -j reject # Abgewiesenes ICMP protokollieren $IPCHAINS -A input -p icmp -l -j reject fi # # end.

Aufgrund des Unterschieds in der Bedeutung der INPUT-Regelsätze in der netfilter-Implementierung gingen wir in unserem iptables-Beispiel dazu über, FORWARD-Regelsätzen zu benutzen. Das hat Konsequenzen für uns, denn es bedeutet, daß keine der Regeln den Firewall-Host selbst schützen. Um unser ipchains-Beispiel akkurat nachzubilden, würden wir hier alle unsere Regeln in der INPUT-Kette replizieren. Um die Sache klarzustellen: Wir verwerfen statt dessen alle eingehenden Datagramme, die wir von unserer Außenschnittstelle erhalten. #!/bin/bash ########################################################################## # IPTABLESVERSION # Dieses Beispiel ist eine Firewall-Konfiguration für einen einzelnen Host. # Der Firewall-

Rechner stellt keine Netzwerkdienste zur Verfügung. ########################################################################## # BEGINN DER BENUTZERKONFIGURATION # Name und Ort des iptables-Programms. IPTABLES=iptables # Pfad zur ausführbaren iptables-Datei. PATH="/sbin" # Unser interner Netzwerkadreßraum und die Schnittstelle dafür. OURNET="172.29.16.0/24" OURBCAST="172.29.16.255" OURDEV="eth0" # Die externe Adresse und die Schnittstelle dafür. ANYADDR="0/0" ANYDEV="eth1" # Die TCP-Dienste, die wir erlauben wollen "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt TCPIN="smtp,www" TCPOUT="smtp,www,ftp,ftp-data,irc" # Die UDP-Dienste, die wir erlauben wollen - "" leer bedeutet: alle Ports # Achtung: durch Leerzeichen getrennt UDPIN="domain" UDPOUT="domain" # Die ICMPDienste, die wir erlauben wollen - "" leer bedeutet: alle Typen # Siehe /usr/include/netinet/ip_icmp.h für Typnummern # Achtung: durch Leerzeichen getrennt ICMPIN="0,3,11" ICMPOUT="8,3,11" # Protokollierung. Entfernen Sie das Kommentarzeichen, um die Protokol- # lierung von Datagrammen zu aktivieren, die von der Firewall blockiert werden. # LOGGING=1 # ENDE DER BENUTZERKONFIGURATION ########################################################################### # Löschen aller Regeln in der Eingangs-Tabelle. $IPTABLES -F FORWARD # Eingehende Zugriffe wehren wir standardmäßig ab. $IPTABLES -P FORWARD deny # Von außen kommende Datagramme für diesen Host wehren wir ab. $IPTABLES -A INPUT -i $ANYDEV -j DROP # SPOOFING # Wir sollten keine Datagramme von außen akzeptieren, deren Quelladresse # zu unserem Netzwerk gehört, also blockieren wir sie. $IPTABLES -A FORWARD -s $OURNET -i $ANYDEV -j DROP # SMURF # Wir verbieten ICMP zu unserer Broadcast-Adresse, um "Smurf"-artige # Attacken zu verhindern. $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET -j DENY # Fragmente sollten wir akzeptieren. In iptables müssen wir das # explizit verlangen. $IPTABLES -A FORWARD -f -j ACCEPT # TCP # Wir akzeptieren alle TCPDatagramme, die zu einer existierenden # Verbindung gehören (d.h. deren ACK-Bit gesetzt ist), für Ports, zu denen # wir Durchgang gewähren. # Das sollte auf mehr als 95% aller gültigen TCP-Pakete zutreffen. $IPTABLES -A FORWARD -m multiport -p tcp -d $OURNET --dports $TCPIN / ! --tcp-flags SYN,ACK ACK -j ACCEPT $IPTABLES -A FORWARD -m multiport -p tcp -s $OURNET --sports $TCPIN / ! -tcp-flags SYN,ACK ACK -j ACCEPT # TCP - EINGEHENDE VERBINDUNGEN # Wir akzeptieren Verbindungsanfragen von der Außenwelt nur an den # erlaubten Ports. $IPTABLES -A FORWARD -m multiport -p tcp -i $ANYDEV -d $OURNET $TCPIN / --syn -j ACCEPT # TCP - AUSGEHENDE VERBINDUNGEN # Wir gestatten alle ausgehenden TCP-Verbindungsanforderungen # an erlaubten TCPPorts. $IPTABLES -A FORWARD -m multiport -p tcp -i $OURDEV -d $ANYADDR / --dports $TCPOUT --syn -j ACCEPT # UDP - EINGEHEND # Wir akzeptieren eingehende UDP-Datagramme an den erlaubten # Ports und umgekehrt. $IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -d $OURNET / --dports $UDPIN -j ACCEPT $IPTABLES -A FORWARD -m multiport -p udp -i $ANYDEV -s $OURNET / --sports $UDPIN -j ACCEPT # UDP - AUSGEHEND # Wir gestatten ausgehende UDP-Datagramme an den erlaubten Ports # und umgekehrt. $IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -d $ANYADDR / --dports $UDPOUT j ACCEPT $IPTABLES -A FORWARD -m multiport -p udp -i $OURDEV -s $ANYADDR / --sports $UDPOUT -j ACCEPT # ICMP - EINGEHEND # Wir erlauben eingehende ICMP-Datagramme der erlaubten Typen. $IPTABLES -A FORWARD -m multiport -p icmp -i $ANYDEV -d $OURNET / --dports $ICMPIN -j ACCEPT # ICMP AUSGEHEND # Wir gestatten ausgehende ICMP-Datagramme der erlaubten Typen. $IPTABLES -A FORWARD -m multiport -p icmp -i $OURDEV -d $ANYADDR / --dports $ICMPOUT -j ACCEPT # DEFAULT und LOGGING # Alle verbleibenden Datagramme werden an die Standardregel durch- # gereicht und verworfen. Sie werden protokolliert, falls Sie die # oben beschriebene LOGGING-Variable entsprechend konfiguriert haben. # if [ "$LOGGING" ] then # Abgewiesenes TCP protokollieren $IPTABLES -A FORWARD -m tcp p tcp -j LOG # Abgewiesenes UDP protokollieren $IPTABLES -A FORWARD -m udp -p udp -j LOG # Abgewiesenes ICMP protokollieren $IPTABLES -A FORWARD -m udp -p icmp -j LOG fi # # end.

In vielen einfachen Situationen ist alles, was Sie zu tun haben, den oberen Abschnitt, der mit “BENUTZERKONFIGURATION” bezeichnet ist, zu editieren, um festzulegen, welche Protokolle und Datagrammtypen Sie herein- und herauslassen wollen. Für komplexere Konfigurationen müssen Sie auch den unteren Abschnitt editieren. Denken Sie daran, dies ist ein bewußt einfach gehaltenes Beispiel. Studieren Sie es also sehr sorgfältig, um sicherzugehen, daß es auch immer das macht, was Sie wollen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 10 IP-Accounting

In der heutigen Welt der kommerziellen Internetdienste wird es immer wichtiger zu wissen, wie viele Daten Sie überhaupt über Ihre Netzwerkverbindungen übertragen und empfangen. Für Internet Service Provider, die ihre Kunden nach Datenvolumen abrechnen, ist das sogar von entscheidender Bedeutung. Wenn Sie ein Kunde eines Internet Service Providers sind und Ihre Netzwerkverbindungen nach Datenvolumen abgerechnet werden, werden Sie es sicher begrüßen, wenn Sie ein Mittel in die Hand bekommen, mit dem Sie die korrekte Abrechnung Ihres

Datenverkehrs überprüfen können. Es gibt aber auch noch andere Anwendungen für Netzwerk-Accounting, die nichts mit Geld und Rechnungen zu tun haben. Wenn Sie einen Server verwalten, der verschiedene Arten von Netzwerkdiensten zur Verfügung stellt, ist es vielleicht nützlich für Sie zu wissen, wieviel Daten von den einzelnen Diensten überhaupt erzeugt werden. Solche Informationen können Ihnen bei mancher Entscheidung behilflich sein, etwa welche Hardware zu kaufen ist oder wie viele Server Sie brauchen. Der Linux-Kernel enthält eine Einrichtung, die Ihnen die Sammlung vielerlei nützlicher Informationen über den Netzwerkverkehr ermöglicht. Diese Einrichtung wird als IP-Accounting bezeichnet.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kernel für IP-Accounting konfigurieren Das IP-Accounting-Feature von Linux hängt eng mit der Linux-Firewall-Software zusammen. Die Stellen, an denen Sie Accounting-Daten sammeln wollen, sind dieselben Stellen, an denen Sie Ihre Firewall-Filter einsetzen würden: dort, wo die Daten in einen Netzwerk-Host hinein- bzw. aus ihm herauskommen, und in der Software, die die Datagramme routet. Wenn Sie das Kapitel über Firewalls noch nicht gelesen haben, sollten Sie das jetzt nachholen, da wir auf einige der in Kapitel 9 TCP/IP-Firewall, beschriebenen Konzepte zurückgreifen werden. Um das IP-Accounting-Feature von Linux zu aktivieren, sollten Sie zuerst prüfen, ob Ihr Kernel überhaupt dafür konfiguriert ist. Prüfen Sie, ob die Datei /proc/net/ip_acct in Ihrem System existiert. Wenn ja, unterstützt Ihr Kernel IP-Accounting. Wenn nicht, müssen Sie einen neuen Kernel erzeugen. Dazu müssen Sie die betreffenden Optionen im 2.0er bzw. 2.2er Kernel aktivieren: Networking options [*] IP: accounting

--->

[*] Network firewalls

[*] TCP/IP networking

Bei einem Kernel der 2.4er Serie wählen Sie dagegen: Networking options

--->

[*] Network packet filtering (replaces ipchains)

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

...

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Accounting konfigurieren Da IP-Accounting eng mit IP-Firewall zusammenhängt, kann man in beiden Fällen dieselben Tools verwenden, also ipfwadm, ipchains oder iptables. Die Befehlssyntax bei IP-Accounting ist der Syntax der Firewall-Regeln sehr ähnlich. Wir gehen daher nicht noch mal detailliert darauf ein, zeigen Ihnen aber, wie Sie damit tieferen Einblick in die Dynamik Ihres Netzwerkverkehrs bekommen. Die allgemeine Syntax für IP-Accounting mit ipfwadm ist: # ipfwadm -A [Richtung] [Befehl] [Parameter]

Das Richtungsargument ist neu. Es kann einen der folgenden Werte haben: in, out oder both codiert. Diese Richtungen sind aus der Perspektive der Linux-Maschine selbst zu sehen. in bezeichnet Daten, die über eine Netzwerkverbindung in die Maschine hineinfließen, out meint Daten, die von diesem Host über eine Netzwerkverbindung übertragen werden. Mit both sind beide Richtungen gemeint. Die allgemeine Befehlssyntax für ipchains und iptables ist: # ipchains -A Chain Regelspezifikation # iptables -A Chain Regelspezifikation

Die Befehle ipchains und iptables ermöglichen es Ihnen, die Richtungen auf eine etwas konsistentere Weise als bei den FirewallRegeln anzugeben. IP Firewall Chains gestattet es Ihnen nicht, Regeln anzugeben, die beide Richtungen betreffen. Sie können aber Regeln für die forward-Chain angeben, was bei der älteren Implementierung nicht möglich war. Die Unterschiede werden wir später noch in einigen Beispielen sehen. Die Befehle sind fast dieselben wie bei den Firewall-Regeln, mit der Ausnahme, daß die Aktionsregeln hier nicht wirksam werden. Wir können Accounting-Regeln hinzufügen, einfügen, löschen und auflisten. Bei ipchains und iptables sind alle zulässigen Regeln Accounting-Regeln. Jeder Befehl, bei dem die Option -j nicht angegeben ist, führt ausschließlich Accounting durch. Die Regelspezifikations-Parameter für IP-Accounting sind dieselben wie diejenigen für IP-Firewall. Wir benutzen sie, um genau zu definieren, welchen Netzwerkverkehr wir abrechnen und aufsummieren wollen.

Accounting anhand von Adressen Nun zeigen wir anhand eines konkreten Beispiels, wie wir IP-Accounting anwenden können. Stellen Sie sich vor, wir hätten einen Linux-basierten Router, der zwei Abteilungen in der virtuellen Brauerei bedient. Der Router hat zwei Ethernet-Geräte, nämlich eth0 und eth1, die jeweils eine Abteilung bedienen, sowie eine PPP-Schnittstelle an ppp0, die uns über eine serielle Hochgeschwindigkeitsleitung mit dem Haupt-Campus der Groucho-Marx-Universität verbindet. Stellen wir uns außerdem vor, daß wir zur Kostenberechnung den Umfang des Datenverkehrs wissen wollen, der von den beiden Abteilungen über die seriellen Leitungen übertragen wird. Für Verwaltungszwecke wollen wir außerdem wissen, wie viele Daten zwischen den beiden Abteilungen hin- und herwandern. Die folgende Tabelle zeigt die Adressen der Schnittstellen, die wir in unserem Beispiel benutzen: Schnittstelle Adresse

Netzmaske

eth0

172.16.3.0 255.255.255.0

eth1

172.16.4.0 255.255.255.0

Wie viele Daten überträgt jede Abteilung über die PPP-Verbindung? Um diese Frage zu beantworten, könnten wir etwa folgende Regel benutzen: # ipfwadm -A both -a -W ppp0 -S 172.16.3.0/24 -b # ipfwadm -A both -a -W ppp0 -S 172.16.4.0/24 -b

oder: # ipchains -A input -i ppp0 -d 172.16.3.0/24 # ipchains -A output -i ppp0 -s 172.16.3.0/24 # ipchains -A input -i ppp0 -d 172.16.4.0/24 # ipchains -A output -i ppp0 -s 172.16.4.0/24

und mit iptables: # iptables -A FORWARD -i ppp0 -d 172.16.3.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.3.0/24 # iptables -A FORWARD -i ppp0 -d 172.16.4.0/24 # iptables -A FORWARD -o ppp0 -s 172.16.4.0/24

Die erste Hälfte jeder dieser Regelsätze besagt: “Zähle alle Daten in beiden Richtungen über die Schnittstelle namens ppp0 mit Quell- oder Zieladresse 172.16.3.0/24.” (Erinnern Sie sich an die Funktion des -b-Flags in ipfwadm.) Die andere Hälfte dieser Regelsätze macht dasselbe für das zweite Ethernet-Netzwerk auf unserer Site. Zur Beantwortung der zweiten Frage “Wie viele Daten werden zwischen den beiden Abteilungen bewegt?” benötigen wir eine Regel, die etwa so aussieht: # ipfwadm -A both -a -S 172.16.3.0/24 -D 172.16.4.0/24 -b

oder: # ipchains -A forward -s 172.16.3.0/24 -d 172.16.4.0/24 -b

oder: # iptables -A FORWARD -s 172.16.3.0/24 -d 172.16.4.0/24 # iptables -A FORWARD -s 172.16.4.0/24 -d 172.16.3.0/24

Diese Regeln zählen alle Datagramme mit einer Quelladresse aus einem Netzwerk unserer Abteilungen und mit einer Zieladresse, die zum anderen Netzwerk gehört.

Accounting anhand von Service-Ports

Okay, jetzt nehmen wir mal an, wir wollten nicht nur etwas über den Umfang, sondern auch Näheres über die Art des übertragenen Datenverkehrs wissen. Wir könnten zum Beispiel wissen wollen, wieviel Leitungskapazität von FTP-, SMTP- und WWW-Diensten in Anspruch genommen wird. Dazu könnten wir ein Skript mit Regeln zusammenstellen, etwa so: #!/bin/sh # Erstellt eine Statistik des FTP-, SMTP- und WWW-Datenverkehrs # über unsere PPPVerbindung mit ipfwadm # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data ipfwadm -A both -a W ppp0 -P tcp -S 0/0 smtp ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 www

oder: #!/bin/sh # Erstellt eine Statistik des FTP-, SMTPVerbindung mit ipchains # ipchains -A input -i ppp0 i ppp0 -p tcp -d 0/0 ftp-data:ftp ipchains -A input i ppp0 -p tcp -d 0/0 smtp ipchains -A input -i ppp0 tcp -d 0/0 www

und WWW-Datenverkehrs # über unsere PPP-p tcp -s 0/0 ftp-data:ftp ipchains -A output -i ppp0 -p tcp -s 0/0 smtp ipchains -A output -p tcp -s 0/0 www ipchains -A output -i ppp0 -p

oder: #!/bin/sh # Erstellt eine Statistik des FTP-, SMTP- und WWW-Datenverkehrs # über unsere PPPVerbindung mit iptables # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp iptables A FORWARD -o ppp0 -m tcp -p tcp --dport ftp-data:ftp iptables -A FORWARD -i ppp0 -m tcp -p tcp -sport smtp iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport smtp iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www iptables -A FORWARD -o ppp0 -m tcp -p tcp --dport www

In dieser Konfiguration sind einige interessante Features enthalten. Erstens haben wir das Protokoll spezifiziert. Wenn wir in unseren Regeln Ports angeben, müssen wir auch ein Protokoll benennen, da TCP und UDP verschiedene Portmengen anbieten. Da alle diese Dienste TCP-basiert sind, haben wir es hier auch als Protokoll angegeben. Zweitens haben wir die beiden Dienste ftp und ftp-data in einer einzigen Anweisung angegeben. ipfwadm gestattet die Spezifikation einzelner Ports, von Portbereichen oder beliebigen Listen von Ports. ipchains erlaubt entweder einzelne Ports oder Portbereiche, was wir hier auch ausgenutzt haben. Die Notation ftp-data:ftp bedeutet “Ports ftp-data (20) bis ftp (21)” und ist die Art und Weise, wie wir Portbereiche sowohl in ipchains als auch iptables beschreiben. Wenn Sie in einer Accounting-Regel eine Liste von Ports angeben, bedeutet das, daß alle Daten addiert werden, die über irgendeinen dieser Ports laufen. Wir haben uns daran erinnert, daß FTP-Dienste immer zwei Ports brauchen, nämlich einen für die FTP-Befehle und einen für die Datentransfers, und daher beide Ports zusammen angegeben, um den gesamten FTP-Verkehr zu addieren. Schließlich haben wir die Quelladresse als 0/0 angegeben. Dabei handelt es sich um eine spezielle Notation, die zu allen Adressen paßt und sowohl von ipfwadm als auch von ipchains für die Spezifikation der Ports benötigt wird. Den zweiten Punkt können wir noch etwas ausweiten, um einen etwas differenzierteren Einblick in die Daten unserer Verbindung zu bekommen. Dazu klassifizieren wir FTP-, SMTP- und WWW-Daten als essentiellen Datenverkehr und alle anderen Daten als nicht essentiell. Um nun das Verhältnis von essentiellem zu nichtessentiellem Datenverkehr zu ermitteln, geben wir etwa folgendes ein: # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 ftp ftp-data smtp www # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 1:19 22:24 26:79 81:32767

Wenn Sie sich Ihre /etc/services-Datei schon mal angesehen haben, werden Sie feststellen, daß die zweite Regel alle Ports bis auf ftp, ftp-data, smtp und www abdeckt. Wie erreichen wir das nun mit ipchains oder iptables, zumal sie jeweils nur ein Argument in ihrer Portspezifikation zulassen? Nun, wir können uns benutzerdefinierte Ketten für Accounting genauso einfach zunutze machen wie bei den Firewall-Regeln. Betrachten Sie folgende Vorgehensweise: # ipchains -N a-essent # ipchains -N a-noness # ipchains -A a-essent -j ACCEPT # ipchains -A anoness -j ACCEPT # ipchains -A forward -i ppp0 -p tcp -s 0/0 ftp-data:ftp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 smtp -j a-essent # ipchains -A forward -i ppp0 -p tcp -s 0/0 www -j aessent # ipchains -A forward -j a-noness

Hier erzeugen wir zwei benutzerdefinierte Ketten, zum einen a-essent, in der wir Accounting-Daten für essentielle Dienste sammeln, und zum anderen a-noness, wo wir solche für nichtessentielle Dienste erhalten. Danach fügen wir Regeln zu unserer Weitergabe-Kette hinzu, die unsere essentiellen Dienste filtern und sie zur weiteren Verarbeitung an die a-essentKette weiterleiten. Dort haben wir nur eine Regel, die alle Datagramme akzeptiert und durchzählt. Die letzte Regel in unserer Weitergabe-Kette ist eine Regel, die zu unserer a-noness-Kette verzweigt, wo wir wiederum nur eine Regel haben, die alle Datagramme akzeptiert und durchzählt. Die Regel, die zur a-noness-Kette verzweigt, kann von keinem der essentiellen Dienste erreicht werden, da sie in ihrer eigenen Kette akzeptiert wurden. Unsere Zähler für die essentiellen und nichtessentiellen Dienste sind daher in den Regeln dieser Ketten verfügbar. Diese Vorgehensweise ist nur eine Möglichkeit; es gibt auch noch andere. Dasselbe Schema würde in einer iptables-Implementierung so aussehen: # iptables -N a-essent # iptables -N a-noness # iptables -A a-essent -j ACCEPT # iptables -A anoness -j ACCEPT # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport ftp-data:ftp -j a-essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport smtp -j a-essent # iptables -A FORWARD -i ppp0 -m tcp -p tcp --sport www -j a-essent # iptables -A FORWARD -j a-noness

Das Ganze sieht ja ziemlich einfach aus. Leider taucht ein kleines, aber unvermeidliches Problem auf, wenn man versucht, Accounting nach Service-Typen durchzuführen. In einem früheren Kapitel hatten wir ja bereits darüber gesprochen, welche Rolle die MTU in TCP/IP-Netzwerken spielt. Die MTU (Maximum Transmission Unit) definiert das größte Datagramm, das von einem Netzwerkgerät übertragen wird. Wenn ein Datagramm von einem Router empfangen wird, das größer als die MTU der Schnittstelle ist, die die Übertragung fortsetzen soll, dann führt der Router einen besonderen Trick durch, nämlich eine sogenannte Fragmentierung. Dabei zerteilt der Router das große Datagramm in leichter verdauliche Häppchen, die jeweils nicht größer als die MTU der Schnittstelle sind, und überträgt diese dann. Dabei erzeugt der Router in jedem dieser kleinen Datagramme jeweils einen neuen Header, der zur Rekonstruktion des großen Datagramms am Zielort dient. Unglücklicherweise wird bei der Zerteilung die Information über den verwendeten Port nur im ersten Fragment abgespeichert, in den nachfolgenden Fragmenten ist das nicht mehr der Fall. Das bedeutet, daß das IP-Accounting fragmentierte Datagramme natürlich nicht mehr richtig zählen kann. Es kann nur das jeweils erste Fragment eines zerteilten Datagramms sowie unzerteilte Datagramme zählen. Es gibt bei ipfwadm aber einen kleinen Trick, mit dem man die zerteilten Fragmente doch zählen kann, auch wenn man in den Fragmenten keine Angaben über den verwendeten Port vorfindet. Eine frühe Version der Linux-Accounting-Software wies den Fragmenten nämlich immer die unsinnige Portnummer 0xFFFF zu, die man dann zählen konnte, zum Beispiel mit folgender Regel: # ipfwadm -A both -a -W ppp0 -P tcp -S 0/0 0xFFFF

Die IP-Chains-Implementierung benutzt dafür eine etwas durchdachtere Lösung, das Ergebnis bleibt aber fast dasselbe. Bei ipchains könnten wir so vorgehen: # ipchains -A forward -i ppp0 -p tcp -f

und bei iptables: # iptables -A FORWARD -i ppp0 -m tcp -p tcp -f

Diese Regeln geben uns zwar keine Auskunft über den Ursprungsport, aber wir sind zumindest in der Lage festzustellen, wie viele unserer Datenpakete fragmentiert sind, und können daher Angaben über deren Datenumfang machen. Falls Ihr Linux-Rechner als einzelner Zugriffspunkt für ein Netzwerk dient, können Sie in den 2.2-Kerneln eine bestimmte Compile-Time-Option einstellen, die diese ganze Sache ganz und gar abschaltet. Wenn Sie die Option IP: always defragment aktivieren, bevor Sie Ihren Kernel kompilieren, werden alle empfangenen Datagramme vom Linux-Router erst zusammengesetzt, bevor sie dann weiter geroutet und übertragen werden. Diese Operation findet bereits statt, bevor das fertige Datagramm die Firewall- und Accounting-Software erreicht. Sie müssen sich dann nicht mehr mit IP-Fragmenten -herumschlagen. In 2.4er Kerneln kompilieren und laden Sie dafür das netfilter-Modul forward-fragment.

Accounting von ICMP-Datagrammen Das ICMP-Protokoll kann mit Portnummern nichts anfangen und ist daher etwas schwieriger zu handhaben, was die Sammlung von Informationen darüber betrifft. ICMP benutzt unterschiedliche Arten von Datagrammen. Viele von diesen sind “harmlos” und normal, während andere nur unter ganz bestimmten Umständen auftauchen sollten. Manche Zeitgenossen, die mit ihrer Zeit

nichts anzufangen wissen, versuchen absichtlich, Netzwerkverbindungen anderer Leute zu unterbrechen, indem sie eine Unmenge von ICMP-Nachrichten erzeugen. Dieses Verfahren wird allgemein als Ping Flooding bezeichnet. IP-Accounting kann nichts gegen solche Probleme unternehmen (aber IP-Firewalling kann das!), wir können aber zumindest Regeln einführen, die uns zeigen, ob irgend jemand versucht hat, uns aus diese Weise anzugreifen. ICMP benutzt keine Ports, wie es TCP und UDP tun, sondern ICMP-Nachrichtentypen. Wir können Regeln einführen, die ein Accounting dieser ICMP-Nachrichtentypen durchführen. Dazu geben wir im Portfeld des ipfwadm-Befehls die ICMP-Nachricht und die Typnummer an. Die ICMP-Nachrichtentypen sind in “Arten von ICMP-Datagrammen” aufgelistet, so daß Sie im Bedarfsfall hierauf zurückgreifen können. Eine IP-Accounting-Regel zur Sammlung von Informationen über den Umfang von Ping-Daten, die zu Ihnen gesendet werden bzw. die Sie zu anderen senden, könnte wie folgt aussehen: # ipfwadm -A both -a -P icmp -S 0/0 8 # ipfwadm -A both -a -P icmp -S 0/0 0 # ipfwadm -A both -a -P icmp -S 0/0 0xff

oder bei ipchains: # ipchains -A forward -p icmp -s 0/0 8 # ipchains -A forward -p icmp -s 0/0 0 # ipchains -A forward -p icmp -s 0/0 -f

oder bei iptables: # iptables -A FORWARD -m icmp -p icmp --sports echo-request # iptables -A FORWARD -m icmp -p icmp -sports echo-reply # iptables -A FORWARD -m icmp -p icmp -f

Die erste Regel sammelt Informationen über “ICMP Echo Request”-Datagramme (Ping-Anfragen), die zweite Regel über “ICMP Echo Reply”-Datagramme (Ping-Antworten). Die dritte Regel ist schließlich für ICMP-Datagrammfragmente zuständig. Dies ist ein Trick, der dem bereits für die fragmentierten TCP- und UDP-Datagramme beschriebenen ähnlich ist. Wenn Sie in Ihren Regeln Quell- und/oder Zieladressen angeben, können Sie verfolgen, woher die Pings kommen und ob sie ihren Ursprung innerhalb oder außerhalb Ihres Netzwerks haben. Sobald Sie festgestellt haben, woher die üblen Datagramme kommen, können Sie entscheiden, ob Sie hier Firewall-Regeln einführen wollen, um solche Attacken zu vermeiden, oder ob Sie irgend etwas anderes vorziehen, wie zum Beispiel den Eigentümer des angreifenden Netzwerks anzurufen und ihn über das Problem zu informieren, oder sogar rechtliche Schritte in Erwägung ziehen.

Accounting anhand des Protokolls Stellen wir uns nun vor, wir wollten wissen, welche Anteile TCP, UDP und ICMP am gesamten Datenverkehr in unserer Verbindung haben. Dafür würden wir etwa folgende Regeln benutzen: # ipfwadm -A both -a -W ppp0 -P tcp -D 0/0 # ipfwadm -A both -a -W ppp0 -P udp -D 0/0 # ipfwadm -A both -a -W ppp0 -P icmp -D 0/0

oder: # ipchains -A forward -i ppp0 -p tcp -d 0/0 # ipchains -A forward -i ppp0 -p udp -d 0/0 # ipchains A forward -i ppp0 -p icmp -d 0/0

oder: # iptables -A FORWARD -i ppp0 -m tcp -p tcp # iptables -A FORWARD -o ppp0 -m tcp -p tcp # iptables A FORWARD -i ppp0 -m udp -p udp # iptables -A FORWARD -o ppp0 -m udp -p udp # iptables -A FORWARD i ppp0 -m icmp -p icmp # iptables -A FORWARD -o ppp0 -m icmp -p icmp

Mit diesen Regeln wird der gesamte Datenverkehr über die ppp0-Verbindung analysiert und ermittelt, ob es sich dabei um TCP, UDP oder ICMP handelt. Für jedes dieser Protokolle wird der entsprechende Zähler aktualisiert. Der Befehl iptables trennt den eingehenden Datenverkehr vom ausgehenden, wie es seine Syntax erfordert.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IP-Accounting-Resultate Schön und gut, nun können wir diese Informationen sammeln, aber wie bekommen wir sie überhaupt zu Gesicht? Um Zugriff auf unsere Accounting-Daten und die konfigurierten Accounting-Regeln zu erhalten, benutzen wir unsere FirewallKonfigurationsbefehle. In der Ausgabe erscheinen die Paket- und Bytezähler der einzelnen Regeln. Die Befehle ipfwadm, ipchains und iptables unterscheiden sich darin, wie die Accounting-Daten verarbeitet werden. Daher behandeln wir sie getrennt.

Accounting-Daten auflisten mit ipfwadm Der Basisbefehl zur Auflistung von Accounting-Daten mit ipfwadm lautet etwa wie folgt: # ipfwadm -A -l IP accounting rules pkts bytes dir prot source ports 9833 2345K i/o all 172.16.3.0/24 anywhere 172.16.4.0/24 anywhere n/a

n/a 56527

destination 33M i/o all

Das teilt uns die Anzahl der Datagramme mit, die in jede Richtung übertragen wurden. Wenn wir das erweiterte Ausgabeformat mit der Option -e wählen (was hier aus Platzgründen nicht gezeigt wird), erhalten wir auch die Optionen und verwendbaren Schnittstellen. Die meisten Felder in der Ausgabe sind selbsterklärend, die folgenden eventuell nicht: dir Die Richtung, für die die Regel gilt. Zulässige Werte sind in, out oder i/o, was bidirektional bedeutet. prot Die Protokolle, für die die Regel gilt. opt Eine codierte Form der Optionen, die wir beim Aufruf von ipfwadm benutzen.

ifname Der Name der Schnittstelle, für die die Regel gilt. ifaddress Die Adresse der Schnittstelle, für die die Regel gilt. Normalerweise gibt ipfwadm die Datagramm- und Bytezähler in verkürzter Form aus, gerundet auf die nächsten Tausend (K) oder die nächste Million (M). Eine exakte Darstellung erhalten wir mit der folgenden erweiterten Option: # ipfwadm -A -l -e -x

Accounting-Daten auflisten mit ipchains Der Befehl ipchains gibt Accounting-Daten (Datagramm- und Bytezähler) nur aus, wenn die Option -v angegeben ist. Die einfachste Anwendungsform ist: # ipchains -L -v

Wie bei ipfwadm können wir auch hier exakte Ausgaben verlangen. Dazu benutzen wir die Option -x, etwa so: # ipchains -L -v -x

Accounting-Daten auflisten mit iptables Der Befehl iptables verhält sich fast genauso wie ipchains. Auch hier müssen wir die Option -v angeben, um die AccountingZähler zu Gesicht zu bekommen. Zur Auflistung unserer Accounting-Daten geben wir etwa folgendes ein: # iptables -L -v

Wie bei ipchains erhalten wir mit der Option -x exakte Ausgaben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Zähler zurücksetzen Nach einer bestimmten Zeit laufen die IP-Accounting-Zähler über, wenn Sie nichts dagegen unternehmen. Wenn sie einmal übergelaufen sind, haben Sie Probleme, ihre tatsächlichen Werte zu bestimmen. Sie sollten die Zählerstände daher in regelmäßigen Abständen auslesen, aufzeichnen und sie dann wieder auf null zurücksetzen, um das Accounting für das nächste Zeitintervall neu zu beginnen. Das Zurücksetzen der Zählerstände ist schnell erledigt: # ipfwadm -A -z

oder: # ipchains -Z

oder: # iptables -Z

Sie können sogar das Auflisten und das Zurücksetzen der Zähler miteinander kombinieren und so

sicherstellen, daß keine Aufzeichnungen verlorengehen: # ipfwadm -A -l -z

oder: # ipchains -L -Z

oder: # iptables -L -Z -v

Diese Anweisungen listen zuerst die Accounting-Daten auf, löschen sie unmittelbar danach und setzen das Accounting unverzüglich fort. Wenn Sie daran interessiert sind, die Sammlung und Anwendung dieser Informationen in regelmäßigen Zeitabständen automatisch zu wiederholen, werden Sie die Anweisungen wohl in ein Skript schreiben, das dann vom cron-Befehl periodisch ausgeführt wird.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verwerfen des Regelsatzes Ein Befehl ist noch übrig, der sich als besonders nützlich erweisen könnte. Er ermöglicht es Ihnen, alle von Ihnen konfigurierten Accounting-Regeln zu verwerfen. Er ist gerade dann besonders zweckmäßig, wenn Sie Ihren Regelsatz radikal ändern wollen, ohne Ihren Rechner neu starten zu müssen. Wird das Argument -f dem ipfwadm-Befehl übergeben, werden alle Regeln des angegebenen Typs verworfen. Das entsprechende Argument für ipchains lautet -F: # ipfwadm -A -f

oder: # ipchains -F

oder: # iptables -F

Das verwirft alle Ihre konfigurierten IP-Accounting-Regeln, das heißt, es entfernt sie alle und erspart

Ihnen dadurch die Mühe, die Regeln einzeln von Hand zu entfernen. Beachten Sie, daß das Verwerfen der Regeln bei ipchains nicht bedeutet, daß die benutzerdefinierten Ketten entfernt werden, sondern nur die darin enthaltenen Regeln.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Passive Sammlung von Accounting-Daten Es gibt noch einen Trick, den Sie vielleicht überdenken sollten. Wenn Ihr Linux-Rechner an ein Ethernet angeschlossen ist, können Sie Accounting-Regeln auf alle Daten des Segments anwenden, nicht nur auf die, die von Ihrer Maschine übertragen werden oder an sie gerichtet sind. Ihre Maschine hört passiv alle Daten im Segment ab und zählt sie. Sie sollten dafür zunächst IP-Forwarding in Ihrem Linux-Rechner abstellen, damit er nicht versucht, die empfangenen Datagramme zu routen.1 In 2.0.36- und 2.2-Kerneln geschieht das so: # echo 0 >/proc/sys/net/ipv4/ip_forward

Nun müssen Sie nur noch mit dem Befehl ifconfig den promiskuösen Modus Ihrer EthernetSchnittstelle aktivieren. Sie können nun Accounting-Regeln etablieren, die Ihnen die Sammlung von Informationen über Datagramme ermöglichen, die in Ihrem Ethernet umherwandern, ohne daß Ihr Linux-System überhaupt daran beteiligt ist.

1.

Das ist allerdings nicht angebracht, wenn Ihre Linux-Maschine als Router tätig ist. Wenn Sie IPForwarding abstellen, ist Schluß mit Routen! Machen Sie das also nur auf einer Maschine mit einer einzelnen physischen Netzwerkschnittstelle.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 11 IP-Masquerade und die Umsetzung von Netzwerkadressen

Sie erinnern sich sicher noch gut an die Zeiten, in denen es sich nur große Unternehmen leisten konnten, ihre Rechner in einem lokalen Netzwerk (LAN) miteinander zu vernetzen. Mittlerweile sind die Preise für die Netzwerktechnologien dermaßen ins Rutschen geraten, daß sich nun zwei Dinge bemerkbar machen: Erstens sind LANs heutzutage Alltagsgegenstände, die sich sogar bis in viele Haushalte hinein verbreitet haben. Zweifellos gibt es viele Linux-Anwender, die zwei oder mehrere Rechner über irgendein Ethernet miteinander vernetzt haben. Zweitens sind manche Netzwerkressourcen, besonders IP-Adressen, inzwischen Mangelware. Lange Zeit war es üblich, IPAdressen kostenlos zu bekommen, mittlerweile muß man dafür Geld bezahlen. Die meisten Leute mit einem LAN wollen vermutlich eine Internetverbindung haben, die jeder

Rechner in ihrem LAN nutzen kann. Die IP-Routing-Regeln sind ziemlich pingelig darin, wie sie mit dieser Situation umgehen. Traditionelle Lösungen basieren auf der Vergabe von Netzwerkadressen (z.B. Klasse C) für kleine LANs, in denen jede Maschine ihre eigene IP-Adresse erhält. Über einen klassischen Router werden dann die Verbindungen vom LAN ins Internet hergestellt. In einer kommerzialisierten Internetumgebung ist das allerdings ein teures Unterfangen. Erstens müßten Sie für die Ihnen zugewiesene Netzwerkadresse bezahlen. Außerdem müßten Sie damit rechnen, daß Ihr Internet Service Provider Sie kräftig zur Kasse bittet für das Privileg, eine angemessene Route zu Ihrem Netzwerk aufzubauen, damit der Rest des Internets weiß, wie man Sie erreichen kann. Für Firmen ist dieses Vorgehen praktikabel, aber private Netzwerke rechtfertigen die entstehenden Kosten nicht. Glücklicherweise bietet Linux auch hier einen Ausweg aus dem Dilemma. Die Antwort findet man in Form eines Sets von erweiterten Netzwerk-Features, genannt Netzwerk-Adressenumsetzung (Network Address Translation, NAT). NAT beschreibt ein Verfahren, wie die in den Datagramm-Headern enthaltenen Netzwerkadressen während der Übertragung modifiziert werden können. Das hört sich zunächst merkwürdig an, wir werden aber sehen, daß dies für viele Anwender die ideale Lösung des beschriebenen Problems ist. IP-Masquerade ist eine Form der Netzwerk-Adressenumsetzung. Sie erlaubt allen Hosts in einem privaten Netzwerk Zugriff auf das Internet, wofür nur eine einzige offizielle IP-Adresse benötigt wird. Mit IP-Masquerade können Sie eine private (reservierte) IP-Netzwerkadresse in Ihrem LAN benutzen, wobei Ihr Linux-basierter Router einige clevere Echtzeit-Übersetzungen von IP-Adressen und Ports durchführt. Wenn der Router ein Datagramm von einem Rechner im LAN erhält, ermittelt er den Typ des Datagramms (TCP, UDP, ICMP etc.) und modifiziert das Datagramm dergestalt, daß es so aussieht, als ob es vom Router selbst erzeugt worden wäre (und merkt sich das auch). Dann überträgt er das Datagramm ins Internet mit der einzelnen, oben erwähnten IP-Adresse. Wenn der Zielrechner das Datagramm erhält, glaubt er, daß das Datagramm vom routenden Host kam, und sendet alle Antworten an diesen zurück. Wenn die Antwort nun den Linux-Masquerade-Router erreicht, schaut dieser in seiner Tabelle der aufgenommenen Masquerade-Verbindungen nach, um festzustellen, ob dieses Datagramm für einen der LAN-Rechner bestimmt ist. Falls dem so ist, kehrt er die Modifikationen um, die er auf dem Hinweg durchgeführt hatte, und leitet das Datagramm an den LANRechner weiter. Ein einfaches Beispiel ist in Abbildung 11.1 dargestellt. Abbildung 11.1: Eine typische IP-Masquerade-Konfiguration

Angenommen, wir haben ein kleines Ethernet, das eine der reservierten Netzwerkadressen benutzt. Für den Zugang ins Internet benutzt das Netzwerk einen Linux-basierten Masquerade-Router. Eine der Workstations im Netzwerk (192.168.1.3) möchte nun eine Verbindung zum Remote-Host 209.1.106.178 an Port 8888 aufnehmen. Sie schickt ihr Datagramm zum Masquerade-Router, der erkennt, daß für dieses Datagramm Masquerading-Dienste benötigt werden. Er akzeptiert das Datagramm, bestimmt eine Portnummer (1035), ersetzt die IP-Adresse und Portnummer des Datagramms durch seine eigene IP-Adresse und die ermittelte Portnummer und überträgt das modifizierte Datagramm an die Zieladresse. Der Ziel-Host meint, er hätte die Verbindungsanforderung direkt vom Masquerade-Router bekommen, und sendet ein Antwort-Datagramm zurück. Sobald der Masquerade-Router diese Antwort erhält, schaut er in seiner Masquerade-Tabelle nach und kehrt die eben durchgeführte Substitution um und leitet das so modifizierte Antwort-Datagramm an die betreffende Workstation weiter. Der lokale Host hat den Eindruck, er würde direkt mit dem fernen Host kommunizieren. Dieser weiß überhaupt nichts über den lokalen Host und glaubt, er wäre nur mit dem Linux-Masquerade-Router verbunden. Der Linux-Router weiß aber, daß sich beide Hosts miteinander unterhalten und an welchen Ports sie das machen, und kann daher die notwendigen Umrechnungen von IP-Adressen und Portnummern durchführen, um die Kommunikation zwischen den beteiligten Hosts aufrechtzuerhalten. Das mag vielleicht ein wenig konfus wirken, manchmal tatsächlich sogar sein, aber es funktioniert und ist sogar recht einfach zu konfigurieren. Machen Sie sich daher keine Sorgen, wenn Sie noch nicht alle Details verstanden haben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Nebeneffekte und zusätzliche Vorteile IP-Masquerading hat auch eine Reihe von Nebeneffekten, von denen manche erwünscht sind, manche nützlich und andere lästig sind. Erstens ist keiner der Hosts im unterstützten Netzwerk hinter dem Masquerade-Router direkt von außen sichtbar. Damit alle Ihre Hosts Netzwerkverbindungen ins Internet aufbauen können, brauchen Sie folglich nur eine gültige, routbare IP-Adresse. Darin liegt ein kleiner Wermutstropfen: Hosts ist im Internet sichtbar und Sie können aus dem Internet keine direkte Verbindung zu ihnen aufbauen. Der einzige Host aus dem maskierten Netzwerk, der im Internet sichtbar ist, ist der MasqueradeRouter selbst. Das ist der einzige Rechner Ihres Netzwerks, der direkte Verbindung zum Internet hat. Das spielt eine gewichtige Rolle, wenn Sie Dienste wie Mail oder FTP betrachten. Es hilft Ihnen bei der Entscheidung, welche Dienste vom Masquerade-Host zur Verfügung gestellt werden sollen, ob Sie dafür Proxy-Mechanismen in Erwägung ziehen oder ob sie auf andere Weise angeboten werden sollen. Zweitens sind die Hosts Ihres Netzwerks relativ gut vor Angriffen aus dem Internet geschützt, da man sie von dort nicht direkt erreichen kann. Das kann die Firewall-Konfiguration auf dem MasqueradeHost wesentlich vereinfachen oder sogar ganz überflüssig machen. Darauf sollten Sie sich aber nicht zu sehr verlassen, denn Ihr Netzwerk ist immer nur so sicher wie Ihr Masquerade-Host. Wenn Sicherheit für Sie wichtig ist, sollten Sie auf einen Firewall besser nicht verzichten.

Drittens hat IP-Masquerade einen gewissen Einfluß auf die Performance Ihres Netzwerks. In üblichen Konfigurationen ist dieser Einfluß kaum meßbar. Wenn Sie jedoch eine große Anzahl aktiver Masquerade-Sessions laufen haben, kann der verminderte Durchsatz in Ihrem Netzwerk deutlich spürbar werden. Verglichen mit dem konventionellen Routing, hat ein Rechner für IP-Masquerade einiges an Mehrarbeit zu leisten. Ihr 386SX16-Rechner mag als Masquerade-Rechner für eine DialupVerbindung ins Internet ganz brauchbar sein, erwarten Sie aber nicht zuviel, wenn Sie ihn als Router für Ihr Ethernet-Firmennetzwerk einsetzen wollen. Schließlich gibt es noch Netzwerkdienste, die mit Masquerade nicht funktionieren, oder zumindest nicht, ohne daß man dabei kräftig nachhelfen müßte. Bei diesen Diensten handelt es sich in der Regel um solche, die darauf angewiesen sind, daß auch Verbindungen vom Server zum Klienten aufgebaut werden können. Dazu gehören einige Arten von direkten Kommunikationskanälen (Direct Communications Channels, DCC), Features in IRC und einige Video- und Audio-MulticastingDienste. Manche dieser Dienste funktionieren nur mit speziell abgestimmten Kernel-Modulen; darauf gehen wir noch näher ein. Es mag noch andere Dienste geben, die mit IP-Masquerade überhaupt nicht funktionieren. Achten Sie also darauf, ob Sie IP-Masquerade in Ihrem Fall überhaupt einsetzen können.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration des Kernels für IP-Masquerade Um die Möglichkeiten von IP-Masquerade zu nutzen, muß Ihr Kernel mit Masquerade-Unterstützung kompiliert werden. Bei den 2.2er Kerneln müssen Sie dafür folgende Optionen auswählen: Networking options ---> [*] Network firewalls [*] TCP/IP networking [*] IP: firewalling [*] IP: masquerading --- Protocol-specific masquerading support will be built as modules. [*] IP: ipautofw masq support [*] IP: ICMP masquerading

Beachten Sie, daß einige der Masquerade-Optionen nur als Kernel-Module implementiert sind. Sie müssen also nach der Übersetzung des Kernels mit make zImage unbedingt noch make modules zur Übersetzung der Module ausführen. In den Kerneln der 2.4er Serie wird IP-Masquerade nicht mehr als Compile-Time-Option angeboten. Dafür müssen Sie jetzt die Option “Netzwerk-Paketfilter” (Network Packet Filtering) wählen: Networking options

--->

[M] Network packet filtering (replaces ipchains)

In den Kerneln der 2.2er Serie werden während der Übersetzung eine Reihe protokollspezifischer Hilfsmodule erzeugt. Manche Protokolle beginnen zunächst mit einer ausgehenden Anfrage an einem Port und erwarten dann eine eingehende Verbindung auf einem anderen Port. Normalerweise können solche Protokolle nicht vom IP-Masquerade verarbeitet werden, da es an sich keine Möglichkeit gibt, die zweite Verbindung mit der ersten zu assoziieren, ohne die Protokolle dabei näher zu untersuchen. Genau das ist die Aufgabe der Hilfsmodule. Sie analysieren die Datagramme und ermöglichen dadurch Masquerading für einige Protokolle, die sonst überhaupt nicht verarbeitet werden könnten. Dabei handelt es sich um folgende Protokolle: Modul

Protokoll

ip_masq_ftp

FTP

ip_masq_irc

IRC

ip_masq_raudio

RealAudio

ip_masq_cuseeme CU-See-Me

ip_masq_vdolive For VDO Live ip_masq_quake

IdSoftware's Quake

Sie müssen diese Module manuell laden. Dazu benutzen Sie den Befehl insmod. Beachten Sie, daß Sie die Module nicht mit dem kerneld-Dämon laden können. Alle diese Module erwarten Angaben über die Eingabeports, an denen sie horchen sollen. Für das RealAudio-Modul könnten Sie folgende Anweisung benutzen:1 # insmod ip_masq_raudio.o ports=7070,7071,7072

Die Ports, die Sie angeben müssen, hängen vom verwendeten Protokoll ab. Ein von Ambrose Au geschriebenes MiniHOWTO über IP-Masquerade enthält nähere Informationen über die IP-Masquerade-Module und wie man sie konfiguriert.2 Das netfilter-Paket enthält Module, die ähnliche Funktionalitäten bieten. Um zum Beispiel Verbindungsprobleme von FTPSessions aufzuspüren, laden und benutzen Sie die Module ip_conntrack_ftp und ip_nat_ftp.o.

1.

RealAudio ist ein Warenzeichen der Progressive Networks Corporation.

2.

Sie können Ambrose unter [email protected] kontaktieren.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von IP-Masquerade Wenn Sie die Kapitel über Firewalls und Accounting bereits gelesen haben, überrascht es Sie wohl nicht, daß ipfwadm, ipchains und iptables auch zur Konfiguration von Regeln für IP-Masquerade benutzt werden. Masquerade-Regeln sind eine spezielle Klasse von Filterregeln. Sie können Masquerade nur für solche Datagramme durchführen, die an einem Interface empfangen und an ein anderes Interface geroutet werden. Zur Konfiguration einer Masquerade-Regel bilden Sie eine Regel, die der Weiterleitungsregel bei Firewalls sehr ähnlich ist, allerdings mit speziellen Optionen, die dem Kernel mitteilen, wie das Masquerading der Datagramme vor sich gehen soll. Der Befehl ipfwadm benutzt dafür die Option -m, ipchains nimmt statt dessen -j MASQ, und iptables erwartet -j MASQUERADE, um anzuzeigen, daß die zur Regel passenden Datagramme einer Masquerade-Operation unterzogen werden sollen. Ein kleines Beispiel: Eine Informatik-Studentin an der Groucho-Marx-Universität hat zu Hause eine Reihe von Computern herumstehen und sie zu einem kleinen Ethernet-LAN vernetzt. Als Netzwerkadresse hat sie eine der offiziell reservierten, privaten IP-Adressen genommen. Ihr Quartier teilt sie mit anderen Studentinnen, die alle an einem Zugang ins Internet interessiert sind. Da das Studentenleben nun mal oft alles andere als üppig ist, können sie sich keine dauerhafte Internetverbindung leisten. Sie könnten zwar auch getrennte einfache Dialup-PPP-Verbindungen ins Internet aufbauen, aber sie ziehen es alle vor, eine einzige gemeinsame Verbindung zu nutzen, um per IRC zu chatten, im Web zu surfen und sich Dateien per FTP direkt auf ihren Rechner herunterzuladen. Die Lösung hierfür lautet natürlich IP-Masquerade. Die Studentin konfiguriert einen Linux-Rechner für die Unterstützung der Dialup-Verbindung und zum Routing für das LAN. Die zugewiesene IP-Adresse, die sie bei der Einwahl erhält, interessiert sie kaum. Sie konfiguriert den Linux-Router für IP-Masquerade und benutzt eine private Netzwerkadresse für ihr LAN, zum Beispiel 192.168.1.0. Außerdem vergewissert sie sich, daß die Default-Route aller Hosts in ihrem LAN auf den Linux-Router verweist. Die folgenden ipfwadm-Befehle sind alles, was sie zur Aktivierung des Masquerading in ihrem Netzwerk benötigt: # ipfwadm -F -p deny # ipfwadm -F -a accept -m -S 192.168.1.0/24 -D 0/0

oder mit ipchains: # ipchains -P forward -j deny # ipchains -A forward -s 192.168.1.0/24 -d 0/0 -j MASQ

oder mit iptables: # iptables -t nat -P POSTROUTING DROP # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Wenn nun einer der Hosts im LAN eine Verbindung zu einem Dienst auf einem Remote-Host aufbauen möchte, werden seine Datagramme automatisch vom Linux-Masquerade-Router empfangen und an den Bestimmungsort weitergereicht. Die erste Regel in jedem der Beispiele erhöht die Sicherheit des LANs, denn sie verhindert, daß der Linux-Rechner andere Datagramme routet. Um die Masquerade-Regeln aufzulisten, die Sie erzeugt haben, benutzen Sie im ipfwadm-Befehl die Option -l, wie wir das schon früher beschrieben hatten, als es um Firewalls ging. Um die vorhin erzeugte Regel aufzulisten, geben wir folgendes ein: # ipfwadm -F -l -e

Das sollte folgende Ausgabe ergeben: # ipfwadm -F -l -e IP firewall forward rules, default policy: accept pkts bytes type tosa tosx ifname ifaddress … 0 0 acc/m all ---- 0xFF 0x00 any any

prot opt …

Die Option /m in der Ausgabe zeigt an, daß es sich hierbei um eine Masquerade-Regel handelt. Um die Masquerade-Regeln mit ipchains aufzulisten, benutzen Sie die Option -L. Wenn wir damit die vorhin erzeugte Regel auflisten, erhalten wir folgende Ausgabe: # ipchains -L Chain input (policy ACCEPT): Chain forward (policy ACCEPT): target prot opt source destination ports MASQ all ------ 192.168.1.0/24 anywhere n/a Chain output (policy ACCEPT):

Alle Regeln mit dem Ziel MASQ sind Masquerade-Regeln. Schließlich listen wir Regeln mit iptables so auf: # iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy DROP) target prot opt source destination MASQUERADE all -- anywhere anywhere MASQUERADE Chain OUTPUT (policy ACCEPT) target prot opt source destination

Auch hier sind Masquerade-Regeln durch das Ziel MASQUERADE gekennzeichnet.

Zeitparameter für IP-Masquerade setzen Sobald eine neue Verbindung aufgebaut ist, stellt die IP-Masquerade-Software einen Zuordnungskatalog über die beteiligten Hosts zusammen. Sie können sich die Hosts jederzeit ansehen, indem Sie die Datei /proc/net/ip_masquerade inspizieren. Nach einer gewissen Zeit der Inaktivität verlieren diese Zuordnungen allerdings ihre Gültigkeit. Die Timeout-Werte können Sie mit ipfwadm einstellen. Die allgemeine Syntax dafür ist: ipfwadm -M -s

Bei ipchains: ipchains -M -S

Die iptables-Implementierung benutzt standardmäßig erheblich größere Timeout-Werte, die Sie aber nicht verändern können. Jeder dieser Werte wird in Sekunden angegeben und entspricht einem Timer, der von der IP-Masquerade-Software benutzt wird. Die folgende Tabelle enthält eine Zusammenstellung der Timer und ihrer Bedeutungen: Name Bedeutung tcp

TCP-Session-Timeout. Wie lange eine TCP-Verbindung untätig sein kann, bevor ihre Zuordnung entfernt wird.

TCP-Timeout nach FIN. Wie lange eine Zuordnung gültig bleibt, nachdem eine TCP-Verbindung unterbrochen tcpfin wurde.

udp

UDP-Session-Timeout. Wie lange eine UDP-Verbindung untätig sein kann, bevor ihre Zuordnung entfernt wird.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Name-Server-Lookups verarbeiten Die Durchführung von DNS-Anfragen von LAN-Hosts war mit IP-Masquerading schon immer problematisch. Es gibt zwei Möglichkeiten, DNS an eine Masquerade-Umgebung anzupassen. Sie können zum einen die Hosts anweisen, denselben DNS-Server wie der Linux-Router zu benutzen, und IP-Masqerading auch auf die DNS-Anfragen anzuwenden. Zum anderen können Sie auf der LinuxMaschine einen Caching-Only-Name-Server laufen lassen und jeden Host dazu bringen, daß er ihn als DNS-Server benutzt. Obwohl diese Lösung etwas aggressiver ist, ist sie möglicherweise die bessere Option, da sie den DNS-Datenverkehr ins Internet reduziert und bei den meisten Anfragen außerdem erheblich schneller ist, da diese direkt aus dem Cache heraus bedient werden können. Nachteil dieser Lösung ist, daß sie komplizierter ist. Caching-Only-Konfigurationen für named in Kapitel 6 zeigt, wie man einen Caching-Only-Name-Server konfiguriert.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Mehr über Netzwerk-Adressenumsetzung Die netfilter-Software kann viele verschiedene Arten von Netzwerk-Adressenumsetzungen (NAT) durchführen. IP-Masquerade ist davon nur eine einfache Anwendung. Es ist zum Beispiel möglich, NAT-Regeln zu bilden, die nur bestimmte Adressen oder Adressenbereiche umsetzen und alle anderen Adressen unberührt lassen. Oder Sie können eine Adresse auch in einen ganzen Pool von Adressen umsetzen, nicht nur in eine einzige wie bei IPMasquerade. In der Tat können Sie mit iptables NAT-Regeln aufstellen, die alles mögliche umsetzen können, mit Testkombinationen, die alle möglichen Standardattribute benutzen, wie etwa Quelladressen, Zieladressen, Protokollarten, Portnummern usw. Die Umsetzung der Quelladresse eines Datagramms wird in der netfilter-Dokumentation als “Source NAT” bzw. SNAT bezeichnet. Entsprechend lautet die Umsetzung der Zieladresse “Destination NAT” oder DNAT.Umsetzungen von TCP- oder UDP-Ports sind unter der Bezeichnung REDIRECT bekannt. SNAT, DNAT und REDIRECT sind Ziele, die Sie bei iptables benutzen können, um komplexere und anspruchsvollere Regeln zu bilden. Das Thema Netzwerk-Adressenumsetzung und seine Anwendungen verlangt eigentlich nach einem eigenen umfassenden Kapitel.1 Leider müssen wir aus Platzgründen davon absehen, in diesem Buch näher darauf einzugehen. Falls Sie an weitergehenden Informationen über die Anwendung von

Netzwerk-Adressenumsetzungen interessiert sind, können Sie dazu das IPTABLES-HOWTO heranziehen.

1.

... und vielleicht sogar nach einem ganzen Buch!

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 12 Wichtige NetzwerkFeatures

Nachdem Sie IP und den Resolver erfolgreich eingerichtet haben, müssen Sie sich den Diensten zuwenden, die Sie in Ihrem Netzwerk anbieten wollen. Dieses Kapitel behandelt die Konfiguration einiger einfacher Netzwerkanwendungen, einschließlich des inetd-Servers und der Programme der rlogin-Familie. Das Remote Procedure Call Interface, auf dem Dienste wie das Network File System (NFS) und das Network Information System (NIS) basieren, wird auch kurz behandelt. Die Konfiguration von NFS und NIS nimmt aber wesentlich mehr Raum in Anspruch und wird daher in separaten Kapiteln besprochen. Das gleiche gilt auch für E-Mail und Netnews. Leider können wir in diesem Buch nicht alle Netzwerkanwendungen besprechen. Wenn Sie eine der hier nicht behandelten Anwendungen wie talk, gopher oder http installieren wollen, müssen wir Sie auf die entsprechenden Manpages verweisen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Der Super-Server inetd Häufig werden Dienste durch sogenannte Netzwerk-Dämonen bereitgestellt. Ein Dämon ist ein Programm, das einen bestimmten Port öffnet und auf eingehende Verbindungen wartet. Wird eine solche Verbindung aufgebaut, erzeugt der Dämon einen Kind-Prozeß, der die Verbindung übernimmt, während er selbst weiter nach eingehenden Anforderungen Ausschau hält. Dieses an sich gute Konzept hat den Nachteil, daß für jeden angebotenen Dienst ein entsprechender Dämon im Hauptspeicher laufen muß. Außerdem müssen in jedem einzelnen Netzwerkdämon, der für die Verbindungsüberwachung und die Verwaltung der Ports zuständig ist, immer wieder dieselben Softwareroutinen eingebunden werden. Um diesen Mangel an Effizienz zu überwinden, verwenden nahezu alle UNIX-Installationen einen speziellen Netzwerkdämon, den man als “Super-Server” auffassen kann und der Sockets für eine Reihe von Diensten erzeugt und simultan abhört. Fordert ein entfernter Host einen Dienst über einen dieser Sockets an, wird das vom Super-Server registriert, und er startet den für diesen Port zuständigen Server. Der Socket wird dann an den Kind-Prozeß übergeben, und der Super-Server fährt daraufhin mit dem Abhören der Sockets fort. Der am häufigsten verwendete Super-Server ist inetd, der “Internet Dämon”. Er wird während der Boot-Phase des Systems gestartet und liest eine Liste der Dienste, die er verwalten soll, aus der Datei /etc/inetd.conf. Außer diesen Servern gibt es eine Reihe trivialer Dienste, sogenannte interne Dienste, die inetd selbständig ausführt. Dazu gehören beispielsweise chargen, das einfach eine Zeichenkette erzeugt, und daytime, das die nach Meinung des Systems aktuelle Tageszeit zurückliefert. Ein Eintrag in dieser Datei besteht aus einer einzelnen Zeile, die sich aus den folgenden Feldern zusammensetzt: service type protocol wait user server cmdline

Die Bedeutung der einzelnen Felder wird nachfolgend erklärt: service Enthält den Namen des Dienstes. Dieser Name muß in eine Portnummer übersetzt werden, was durch Nachschlagen in der Datei /etc/services geschieht. Diese Datei wird im Abschnitt Die Dateien services und protocols beschrieben. type

Bestimmt den Socket-Typ entweder als stream (bei verbindungsorientierten Protokollen) oder als dgram (für Datagrammprotokolle). TCP-basierte Dienste sollten daher immer stream verwenden, während UDP-basierte Dienste immer dgram verwenden sollten. protocol Benennt das vom Dienst verwendete Transportprotokoll. Hier muß ein gültiger, in der (weiter unten erläuterten) Datei protocols enthaltener Name stehen. wait Diese Option gilt nur für dgram-Sockets. Sie kann entweder wait oder nowait lauten. Wird wait angegeben, führt inetd immer nur einen Server für den angegebenen Port aus. Anderenfalls beginnt inetd unverzüglich wieder an diesem Port zu horchen, sobald der Server gestartet wurde. Das ist sinnvoll bei sogenannten “Single-Threaded-Servern”, die alle eingehenden Datagramme lesen, bis keine weiteren mehr ankommen, und sich dann beenden. Die meisten RPC-Server sind von dieser Art und sollten daher immer wait verwenden. Der entgegengesetzte Typ, der “Multi-Threaded-Server”, erlaubt eine unbeschränkte Anzahl von gleichzeitig laufenden Instanzen. Dieser Servertyp sollte nowait angeben. stream-Sockets sollten immer nowait verwenden. user Hier steht die Login-ID des Benutzers, unter dem der Prozeß ausgeführt wird. Das wird häufig root sein, einige Dienste verwenden aber auch andere Benutzerkonten. Sie sollten übrigens immer das Prinzip der geringsten Privilegien anwenden, d.h., ein Befehl sollte nur mit Privilegien ausgestattet sein, die er zur fehlerfreien Ausführung unbedingt benötigt. Zum Beispiel läuft der NNTP-Newsserver als news, während Dienste, die ein Sicherheitsrisiko darstellen (z.B. tftp oder finger), häufig als nobody laufen. server Enthält den vollen Pfadnamen des auszuführenden Serverprogramms. Interne Dienste werden mit dem Schlüsselwort internal gekennzeichnet. cmdline Die an den Server zu übergebende Befehlszeile. Sie beginnt mit dem Namen des auszuführenden Servers und kann alle dafür notwendigen Argumente enthalten. Wenn Sie den TCP-Wrapper benutzen, geben Sie hier den vollen Pfadnamen zum Server an. Falls nicht, geben Sie den Server so an, wie er in der Prozeßliste erscheinen soll. Über TCP-Wrapper reden wir in Kürze. Dieses Feld ist für interne Dienste leer. Ein Beispiel für inetd.conf ist in Tabelle 12.1 zu sehen. Der finger-Service ist auskommentiert und steht daher nicht zur Verfügung. Dies wird häufig aus Sicherheitsgründen getan, weil er von Angreifern dazu verwendet werden kann, Namen und andere Details der Benutzer Ihres Systems zu ermitteln. Beispiel 12.1: /etc/inetd.conf-Beispieldatei # # inetd-Dienste ftp stream tcp nowait root /usr/sbin/ftpd in.ftpd -l telnet stream tcp nowait root /usr/sbin/telnetd in.telnetd -b/etc/issue #finger stream tcp nowait bin /usr/sbin/fingerd in.fingerd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd #tftp dgram udp wait nobody /usr/sbin/tftpd in.tftpd /boot/diskless #login stream tcp nowait root /usr/sbin/rlogind in.rlogind #shell stream tcp nowait root /usr/sbin/rshd in.rshd #exec stream tcp nowait root /usr/sbin/rexecd in.rexecd # # inetd-interne Dienste # daytime

stream tcp nowait root internal daytime root internal time dgram udp nowait echo dgram udp nowait root internal udp nowait root internal chargen stream internal

dgram udp nowait root internal time root internal echo stream tcp nowait discard stream tcp nowait root internal tcp nowait root internal chargen dgram

stream tcp nowait root internal discard dgram udp nowait root

Der tftp-Dämon ist ebenfalls auskommentiert. tftp implementiert das Trivial File Transfer Protocol (TFTP), das es einem erlaubt, allgemein lesbare Dateien ohne Paßwortprüfung von Ihrem System zu übertragen. Das ist besonders bei der Datei /etc/passwd gefährlich, um so mehr, wenn Sie keine Shadow-Paßwörter benutzen. TFTP wird üblicherweise von Clients ohne eigenes Diskettenlaufwerk und von X-Terminals genutzt, um deren Code von einem Boot-Server herunterzuladen. Muß tftpd aus diesem Grund ausgeführt werden, sollten Sie sicherstellen, daß Sie den Zugriff nur auf solche Verzeichnisse erlauben, aus denen die Clients die entsprechenden Dateien lesen. Diese Verzeichnisse können Sie in der tftpd-Kommandozeile angeben, was in der zweiten tftp-Zeile des Beispiels zu erkennen ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die tcpd-Zugriffs-Kontrolleinrichtung Da die Erweiterung eines Computers um Netzwerkfähigkeiten viele Sicherheitsrisiken in sich birgt, sind die Anwendungen so entwickelt worden, daß sie sich vor verschiedenen Arten von Angriffen schützen können. Allerdings sind einige Sicherheitsmerkmale mangelhaft (was der RTM-Internet-Wurm auf besonders drastische Weise in einer Reihe von Programmen demonstrierte, zu denen auch alte Versionen des Sendmail-Dämons gehörten), oder es wird nicht unterschieden zwischen sicheren Hosts, von denen Anforderungen nach einem bestimmten Service akzeptiert werden können, und unsicheren Hosts, deren Anforderungen abgelehnt werden müssen. Die Dienste finger und tftp hatten wir ja bereits angesprochen. Netzwerkadministratoren würden den Zugriff auf diese Dienste gerne auf “vertrauenswürdige Hosts” beschränken, was aber mit dem normalen Setup, bei dem inetd den Dienst entweder allen Clients anbietet oder überhaupt keinem, nicht möglich ist. Ein für die Verwaltung hostspezifischer Zugriffe nützliches Werkzeug ist tcpd, das oft auch als Dämon-“Wrapper” bezeichnet wird.1 Es wird für TCP-Dienste, die Sie überwachen oder schützen wollen, anstelle des normalen Server-Programms gestartet. tcpd prüft, ob der entfernte Host einen solchen Dienst überhaupt benutzen darf, und führt nur dann das eigentliche Serverprogramm aus. tcpd schickt auch eine Meldung über die Anforderungen an den syslog-Dämon. Beachten Sie, daß dies bei UDP-basierten Diensten nicht funktioniert. Um beispielsweise den finger-Dämon mit einem Wrapper zu schützen, müssen Sie die entsprechende Zeile in inetd.conf # finger-Dämon (ohne Wrapper) finger

stream

tcp

nowait

bin

/usr/sbin/fingerd in.fingerd

wie folgt ändern: # finger-Dämon (mit Wrapper) finger

stream

tcp

nowait

root

leer;/usr/sbin/tcpd

in.fingerd

Ohne eine zusätzliche Zugriffskontrolle erscheint dies für den Client wie ein ganz gewöhnliches finger-Setup, mit derAusnahme, daß alle Anforderungen im auth-Kanal von syslog aufgezeichnet werden. Die Zugriffskontrolle wird mit Hilfe der beiden Dateien /etc/hosts.allow und /etc/ -hosts.deny implementiert. Sie enthalten Einträge, die den Zugriff auf bestimmte Dienste und Hosts erlauben oder verweigern. Wenn tcpd eine Anforderung für einen Dienst wie finger von einem Client-Host namens biff.foobar.com behandelt, durchsucht es hosts.allow und hosts.deny (in dieser Reihenfolge) nach einem Eintrag, bei dem sowohl der Dienst als auch der Client übereinstimmen. Wird ein passender

Eintrag in hosts.allow gefunden, wird der Zugriff freigegeben, gleichgültig, ob es noch einen Eintrag in hosts. deny gibt. Wird keine Übereinstimmung in hosts.allow, aber eine in hosts.deny gefunden, wird die Anforderung abgewiesen, indem die Verbindung unterbrochen wird. Die Anforderung wird akzeptiert, wenn überhaupt kein passender Eintrag gefunden wird. Die Einträge in den Zugriffsdateien sehen wie folgt aus: Dienstliste: Hostliste [:Shellbefehl]

Dienstliste ist eine Liste mit Dienstbezeichnungen aus /etc/services oder das Schlüsselwort ALL. Damit der Eintrag alle Dienste außer finger und tftp betrifft, geben Sie ALL EXCEPT finger, tftp an. Hostliste ist eine Liste mit Hostnamen, IP-Adressen oder den Schlüsselwörtern ALL, LOCAL, UNKNOWN oder PARANOID. ALL steht für alle Hosts, während LOCAL nur Hostnamen vergleicht, die keinen Punkt enthalten.2 UNKNOWN gilt für jeden Host, dessen Name oder Adresse nicht durch Nachschlagen ermittelt werden konnte. PARANOID gilt für jeden Host, dessen Name sich nicht zu seiner IP-Adresse auflösen läßt.3 Ein mit einem Punkt beginnender Name gilt für alle Hosts, deren Domain mit diesem Namen übereinstimmt. Zum Beispiel paßt .foobar.com zu biff.foobar.com, nicht aber zu nurks.fredsville.com. Ein mit einem Punkt endendes Muster gilt für jeden Host, dessen IP-Adresse mit dem angegebenen Muster beginnt. So paßt 172.16. zu 172.16.32.0, aber nicht zu 172.15.9.1. Ein Muster der Form n.n.n.n/m.m.m.m wird als IP-Adresse und Netzmaske betrachtet. Wir könnten daher in unserem Beispiel von eben auch 172.16.0.0/255.255.0.0 angeben. Schließlich können Sie mit einem Muster, das mit einem “/”-Zeichen beginnt, eine Datei spezifizieren, von der angenommen wird, daß sie eine Liste von Mustern von akzeptablen Hostnamen oder IP-Adressen enthält. So würde die Angabe /var/access/trustedhosts den tcpd-Dämon dazu bringen, diese Datei auszulesen und zu prüfen, ob irgendeine der darin enthaltenen Zeilen zum verbindenden Host paßt. Um nur den lokalen Hosts Zugriff auf finger und tftp zu gestatten, lassen Sie die Datei /etc/hosts.allow leer und tragen in /etc/hosts.deny folgendes ein: in.tftpd, in.fingerd: ALL EXCEPT LOCAL, .your.domain

Das optionale Feld Shellbefehl kann einenShellbefehl enthalten, der ausgeführt wird, wenn der Eintrag paßt. Dies ist sinnvoll, wenn Sie Fallen einrichten wollen, die potentielle Angreifer enttarnen. Das folgende Beispiel erzeugt eine Logdatei, die den verbindenden Benutzer und Host anzeigt. Wenn dieser Host nicht vlager.vbrew.com ist, werden die Ausgaben einer finger-Anwendung auf diesen Host eingetragen: in.ftpd: ALL EXCEPT LOCAL, .vbrew.com : \ echo "request from %d@%h:" >> /var/log/finger.log; \ if [ %h != "vlager.vbrew.com:" ]; then \ finger -l @%h >> /var/log/finger.log \ fi

Die Argumente %h und %d werden von tcpd zum Client-Hostnamen und zum Service-Namen erweitert. Details entnehmen Sie bitte der Manpage hosts_access(5).

1.

Entwickelt von Wietse Venema, [email protected].

2.

Üblicherweise enthalten nur lokale Hostnamen, die durch Nachschlagen in /etc/hosts ermittelt wurden, keinen Punkt.

3.

Obwohl PARANOID den Eindruck erweckt, ein extremes Maß zu sein, ist es doch eine gute Standardvorgabe, da es Sie vor böswilligen Hosts schützt, die sich als jemand anderer ausgeben, als sie in Wirklichkeit sind. Nicht jedes tcpd wird standardmäßig mit einkompiliertem PARANOID geliefert. Falls das auch bei Ihnen der Fall ist, müssen Sie Ihr tcpd dafür neu kompilieren.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Dateien services und protocols Die Portnummern, über die einige der “Standarddienste” angeboten werden, sind im Assigned Numbers RFC definiert. Um Server- und Client-Programme dazu zu bringen, Service-Namen in diese Nummern umzuwandeln, ist zumindest ein Teil dieser Liste auf jedem Host vorhanden; sie ist in einer Datei namens /etc/services gespeichert. Ein Eintrag ist wie folgt zusammengesetzt: Dienst Port/Protokoll

[Aliase]

Hier gibt Dienst den Namen des Dienstes an, Port definiert, auf welchem Port dieser Dienst angeboten wird, und Protokoll definiert das zu verwendende Transportprotokoll. Im allgemeinen ist dies entweder udp oder tcp. Ein Dienst kann für mehr als ein Protokoll angeboten werden. Ebenso können verschiedene Dienste am gleichen Port angeboten werden, solange die Protokolle verschieden sind. Im Feld Aliase können Sie alternative Namen für denselben Service angeben. Normalerweise müssen Sie die Services-Datei nicht ändern, die der Netzwerksoftware für Ihr Linux-System beiliegt. Dennoch wollen wir Ihnen in Tabelle 12.2 einen kleinen Ausschnitt dieser Datei zeigen. Beispiel 12.2: Ausschnitt aus /etc/services (Beispieldatei) # Services-Datei: # # bekannte Dienste: echo 7/tcp # Echo echo 7/udp # discard 9/tcp sink null # Discard discard 9/udp sink null # daytime 13/tcp # Daytime daytime 13/udp # chargen 19/tcp ttytst source # Character Generator chargen 19/udp ttytst source # ftp-data 20/tcp # File Transfer Protocol (Data) ftp 21/tcp # File Transfer Protocol (Control) telnet 23/tcp # Virtual Terminal Protocol smtp 25/tcp # Simple Mail Transfer Protocol nntp 119/tcp readnews # Network News Transfer Protocol # # UNIX-Dienste exec 512/tcp # rexecd (BSD) biff 512/udp comsat # Mail-Benachrichtigung login 513/tcp # Login (remote) who 513/udp whod # who und uptime (remote) shell 514/tcp cmd # Befehl (remote) ohne Paßworteingabe syslog 514/udp # System-Logging (remote) printer 515/tcp spooler # Druck-Spooler (remote) route 520/udp router routed # Router-Informationsprotokoll

Beachten Sie, daß der Dienst echo sowohl für TCP als auch für UDP über Port 7 angeboten und Port 512 für zwei verschiedene Dienste verwendet wird: für die Programmausführung auf entfernten Systemen mittels rexec (TCP) und für den

COMSAT-Dämon, der Benutzer mittels UDP über neu eingegangene Post informiert (siehe xbiff(1x)). Wie die services-Datei benötigt die Netzwerkbibliothek einen Weg, um Protokollnamen — beispielsweise die in der ServicesDatei verwendeten — in Protokollnummern zu übersetzen, die vom IP-Layer auf den anderen Hosts verstanden werden. Dazu wird der Name in der Datei /etc/protocols nachgeschlagen. Jede Zeile besteht aus einem Eintrag, der den Protokollnamen und die zugewiesene Nummer enthält. Daß Sie sich mit dieser Datei auseinandersetzen müssen, ist allerdings noch unwahrscheinlicher als bei /etc/ -services. Ein Beispiel ist in Tabelle 12.3 zu sehen. Beispiel 12.3: Ausschnitt aus /etc/protocols (Beispiel) # # Internet-Protokolle (IP) # ip 0 IP # Internet-Protokoll, PseudoProtokollnummer icmp 1 ICMP # Internet Control Message Protocol igmp 2 IGMP # Internet Group Multicast Protocol tcp 6 TCP # Transmission Control Protocol udp 17 UDP # User Datagram Protocol raw 255 RAW # RAW IP-Interface

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Aufruf entfernter Prozeduren (Remote Procedure Call) Remote Procedure Call (RPC) stellt Client/Server-Anwendungen grundlegende Mechanismen zur Verfügung. Es wurde von Sun Microsystems entwickelt und ist eine Sammlung von Tools und Bibliotheksfunktionen. Wichtige Anwendungen, die auf RPC basieren, sind NFS, das Network File System (beschrieben in Kapitel 14 Das Network File System), und NIS, das Network Information System (beschrieben in Kapitel 13 Das Network Information System). Ein RPC-Server besteht aus einer Reihe von Prozeduren, die ein Client aufrufen kann, indem er eine RPC-Anforderung zusammen mit den Prozedurparametern an den Server schickt. Der Server führt die gewählte Prozedur im Namen des Client aus und liefert das Ergebniszurück, wenn es eines gibt. Um maschinenunabhängig zu sein, werden alle zwischen dem Client und dem Server ausgetauschten Daten vom Sender in das sogenannte XDR-Format (External Data Representation) umgewandelt und vom Empfänger wieder in die lokale Repräsentation der Maschine zurückgewandelt. RPC benutzt StandardUDP- und -TCP-Sockets, um die XDR-formatierten Daten zum Remote-Host zu übertragen. Sun hat RPC großzügigerweise in die Public Domain freigegeben. Es wird in einer Reihe von RFCs beschrieben. Manchmal führen Verbesserungen an einer RPC-Anwendung zu inkompatiblen Veränderungen in der Schnittstelle der Prozeduraufrufe. Natürlich würde ein einfacher Austausch des Servers alle Anwendungen zum Absturz bringen, die noch das ursprüngliche Verhalten erwarten. Deshalb werden RPC-Programmen Versionsnummern zugewiesen, die normalerweise bei 1 beginnen und mit jeder neuen RPC-Version erhöht werden. Häufig kann ein Server mehrere Versionen gleichzeitig anbieten. Die Clients geben dann in ihren Anforderungen durch die Versionsnummer an, welche Implementierung des Dienstes sie benutzen wollen. Die Kommunikation zwischen RPC-Servern und -Clients ist etwas eigenartig. Ein RPC-Server bietet eine oder mehrere Sammlungen von Prozeduren an; jede Sammlung wird als Programm bezeichnet und durch eine Programmnummer eindeutig identifiziert. Eine Liste, die Service-Namen auf Programmnummern abbildet, wird für gewöhnlich in der Datei /etc/rpc gespeichert. Ein Ausschnitt davon ist in Tabelle 12.4 gezeigt. Beispiel 12.4: Ausschnitt aus /etc/rpc # # /etc/rpc - verschiedene RPC-basierte Dienste # portmapper 100000 portmap sunrpc rstatd 100001 rstat rstat_svc rup perfmeter rusersd 100002 rusers nfs 100003 nfsprog ypserv 100004 ypprog mountd 100005 mount showmount ypbind 100007 walld 100008 rwall shutdown yppasswdd 100009 yppasswd bootparam 100026 ypupdated 100028 ypupdate

In TCP/IP-Netzwerken wurden die Autoren von RPC mit dem Problem konfrontiert, Programmnummern auf allgemeine Netzwerkdienste abzubilden. Sie gestalteten jeden Server so, daß er für jedes Programm und jede Version sowohl einen TCPals auch einen UDP-Port bereitstellt. Im allgemeinen verwenden RPC-Anwendungen UDP, um Daten zu übertragen, und greifen nur dann auf TCP zurück, wenn die zu übertragenden Daten nicht in ein einzelnes UDP-Datagramm passen. Natürlich müssen Client-Programme eine Möglichkeit haben herauszufinden, auf welchen Port eine Programmnummer abgebildet wird. Die Verwendung einer Konfigurationsdatei wäre für diesen Zweck zu unflexibel. Da RPC-Anwendungen keine reservierten Ports verwenden, gibt es keine Garantie, daß ein ursprünglich von unserer Datenbankanwendung zu benutzender Port nicht von einem anderen Prozeß besetzt wurde. Darum nimmt eine RPC-Anwendung irgendeinen Port, den sie kriegen kann, und registriert ihn mit einem speziellen Programm, dem sogenannten Portmapper-Dämon. Der Portmapper fungiert als Dienstvermittler für alle RPC-Server, die auf dieser Maschine laufen. Ein Client, der einen Dienst mit einer gegebenen Programmnummer kontaktieren möchte, fragt zuerst den Portmapper auf dem Host des Servers ab, der dann die TCP- und UDP-Portnummern zurückliefert, über die der Dienst erreicht werden kann. Diese Methode hat den Nachteil, daß sie – genau wie inetd für die normalen Berkeley-Dienste – einen “single point of failure” darstellt. Nur ist dieser Fall sogar noch schlimmer, weil alle RPC-Port-Informationen verlorengehen, wenn der Portmapper seinen Geist aufgibt. Das bedeutet üblicherweise, daß Sie alle RPC-Server manuell neu starten oder sogar die gesamte Maschine neu hochfahren müssen. Bei Linux wird der Portmapper /sbin/portmap oder manchmal auch /usr/sbin/rpc.portmap genannt. Sie müssen lediglich sicherstellen, daß er von einem Ihrer Boot-Skripten aus gestartet wird. Ansonsten braucht der Portmapper nicht konfiguriert zu werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von Remote-Logins und Ausführen von Befehlen Häufig ist es sehr nützlich, einen Befehl direkt auf einem Remote-Host ausführen zu können und diesem Befehl sogar noch Ein- und Ausgaben übers Netz zu ermöglichen. Die traditionellen Befehle für die Ausführung von Befehlen auf entfernten Hosts sind rlogin, rsh und rcp. Ein Beispiel für den rlogin-Befehl haben wir bereits in Kapitel 1 Einführung in das Arbeiten mit Netzwerken, im Abschnitt Einführung in TCP/IPNetzwerke. gesehen. In Systemsicherheit sprachen wir kurz über die damit einhergehenden Sicherheitsfragen und empfahlen ssh als Ersatz. Das ssh-Paket bietet die Ersatzbefehle slogin, ssh und scp. Jeder dieser Befehle führt eine Shell auf dem entfernten Host aus und erlaubt dem Benutzer die Ausführung von Befehlen. Natürlich benötigt der Client ein Benutzerkonto auf dem Host, auf dem der Befehl ausgeführt werden soll. Folglich führen all diese Befehle einen Authentifizierungsprozeß durch. Die r-Befehle tauschen dazu einfach die Benutzernamen und Paßwörter aus. Das geschieht ohne Verschlüsselung, so daß jeder leicht die Paßwörter abhören kann. Die ssh-Befehle dagegen bieten mehr Sicherheit. Sie benutzen dafür eine Technik, die als Public Key Cryptography bezeichnet wird. Sie bietet Authentifizierung und Verschlüsselung zwischen Hosts und stellt sicher, daß weder Paßwörter noch andere Daten von anderen Hosts leicht abgehört werden können. Es ist möglich, die Authentifizierungsprüfungen für bestimmte Benutzer noch weiter zu lockern. Wenn Sie sich beispielsweise sehr häufig auf einer anderen Maschine in Ihrem LAN einloggen müssen, wollen Sie vielleicht auch direkten Zugriff erhalten, ohne jedesmal Ihr Paßwort eingeben zu müssen. Mit den r-Befehlen war das schon immer möglich, aber die ssh-Suite macht Ihnen das noch etwas leichter. Das ist zwar immer noch keine gute Idee, denn wenn erst einmal ein Benutzerkonto geknackt wurde, kann man Zugriff auf alle anderen Benutzerkonten erlangen, die dieser Anwender für paßwortfreien Login konfiguriert hat. Trotz allem ist es eine bequeme Methode, und die Leute benutzen sie auch. Lassen Sie uns nun darüber reden, wie wir die r-Befehle über Bord werfen und die ssh-Befehle zum Laufen bekommen.

Die r-Befehle deaktivieren Als erstes entfernen wir alle r-Befehle, wenn sie installiert sind. Der einfachste Weg, die alten r-Befehle abzuschalten, ist, ihre Einträge in der Datei /etc/inetd.conf auszukommentieren (oder zu löschen). Die wichtigen Einträge dort sehen in etwa so aus: # Shell, login, exec und talk sind BSD-Protokolle. shell

stream

tcp

nowait

root

/usr/sbin/tcpd /usr/sbin/in.rshd login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind exec stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rexecd

Sie können diese Zeilen auskommentieren, indem Sie ein #-Zeichen an den Zeilenanfang schreiben oder die Zeilen komplett löschen. Denken Sie daran, daß Sie den inetd-Dämon neu starten müssen, um diese Änderungen wirksam zu machen. Am besten entfernen Sie auch die Dämonprogramme selbst aus Ihrem System.

ssh installieren und konfigurieren OpenSSH ist eine freie Version der ssh-Software. Die Linux-Portierung ist über http://violet.ibs.com.au/openssh/ und die meisten Linux-Distributionen erhältlich.1 Auf die Kompilierung gehen wir hier nicht ein. Ausreichende Anweisungen dafür sind im Quellcode enthalten. Wenn Sie es aus einem vorkompilierten Paket installieren können, ist es vielleicht klug, dies auch zu tun. Eine ssh-Session besteht aus zwei Komponenten. Zum einen gibt es einen ssh-Client, den Sie konfigurieren müssen und auf dem lokalen Host laufen lassen, zum anderen einen ssh-Dämon, der auf dem Remote-Host laufen muß. Der ssh-Dämon Der sshd-Dämon ist ein Programm, das auf Netzwerkverbindungen von ssh-Clients achtet, die Authentifizierung durchführt und den gewünschten Befehl ausführt. Es benutzt eine Haupt-Konfigurationsdatei namens /etc/ssh/sshd_config sowie eine spezielle Datei, die einen Schlüssel enthält, der von den Authentifizierungs- und Verschlüsselungsprozessen benutzt wird, um den Rechner selbst zu repräsentieren. Jeder Server und jeder Client hat seinen eigenen Schlüssel. Den Distributionen liegt ein Hilfsmittel namens ssh-keygen bei, mit dem sich zufällige Schlüssel erzeugen lassen. Das wird normalerweise nur einmal während der Installation gemacht, um den Hostschlüssel zu bilden, den der Systemadministrator für gewöhnlich in der Datei /etc/ssh/ssh_host_key abspeichert. Die Schlüssel können beliebig lang sein, ab 512 Bits und mehr. Standardmäßig erzeugt ssh-keygen Schlüssel von 1024 Bits Länge, was auch von den meisten Anwendern übernommen wird. Um einen zufälligen Schlüssel zu erzeugen, rufen Sie ssh-keygen wie folgt auf: # ssh-keygen -f /etc/ssh/ssh_host_key

Sie werden dann aufgefordert, eine Paßphrase einzugeben. Hostschlüssel benötigen jedoch keine Paßphrase, so daß Sie hier einfach die Return-Taste drücken können, ohne etwas einzugeben. Die Programmausgabe sieht dann etwa so aus: Generating RSA keys: ......oooooO...............................oooooO Key generation complete. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /etc/ssh/ssh_host_key Your public key has been saved in /etc/ssh/ssh_host_key.pub The key fingerprint is: 1024 3a:14:78:8e:5a:a3:6b:bc:b0:69:10:23:b7:d8:56:82 root@moria

Am Ende haben Sie zwei erzeugte Dateien vor sich. Der erste Schlüssel wird als privater Schlüssel bezeichnet, der geheimgehalten werden muß und in /etc/ssh/ssh_host_key aufbewahrt wird. Der zweite wird als öffentlicher Schlüssel bezeichnet und ist derjenige, den Sie mit anderen gemeinsam benutzen können; er wird in /etc/ssh/ssh_host_key.pub abgelegt. Nachdem Sie mit den Schlüsseln für die ssh-Kommunikation ausgestattet sind, müssen Sie noch eine Konfigurationsdatei erzeugen. Die ssh-Software ist sehr mächtig, und die Konfigurationsdatei kann daher viele Optionen enthalten. Zur Einführung präsentieren wir Ihnen ein kleines Beispiel. Um die anderen Features zu aktivieren, sollten Sie in der ssh-Dokumentation nachlesen. Der folgende Code zeigt eine sichere und minimale sshd-Konfigurationsdatei. Die weiteren Konfigurationsoptionen werden ausführlich in der Manpage sshd(8) beschrieben. # /etc/ssh/sshd_config # # IP-Adressen, die für Verbindungen in Frage kommen. # 0.0.0.0 bedeutet alle lokalen Adressen. ListenAddress 0.0.0.0 # Der TCP-Port, der auf Verbindungen überwacht werden soll. # Vorgabewert ist 22. Port 22 # Der Name der Hostschlüsseldatei. HostKey /etc/ssh/ssh_host_key # Die Schlüssellänge in Bits. ServerKeyBits 1024 # Erlauben wir root-Logins mittels ssh? PermitRootLogin no # Soll der ssh-Dämon die Verzeichnis- und Dateirechte des # Benutzer-Home-Verzeichnisses auf Sicherheitsrisiken überprüfen, # bevor der Login gestattet wird? StrictModes yes # Sind alte Authentifizierungsmethoden mit ~/.rhosts und /etc/hosts.equiv erlaubt? RhostsAuthentication no # Ist reine RSA-Authentifizierung zugelassen? RSAAuthentication yes # Ist

Passwort-Authentifizierung zugelassen? PasswordAuthentication yes # Ist /etc/hosts.equiv kombiniert mit RSA-Host-Authentifizierung erlaubt? RhostsRSAAuthentication no # Sollen ~/.rhostsDateien ignoriert werden? IgnoreRhosts yes # Sind Logins für Accounts mit leeren Passwörtern erlaubt? PermitEmptyPasswords no

Wichtig ist zu prüfen, ob die Zugriffsrechte der Konfigurationsdatei korrekt eingestellt sind, um sicherzustellen, daß die Systemsicherheit erhalten bleibt. Führen Sie dazu folgende Anweisungen aus: # chown -R root:root /etc/ssh # chmod 755 /etc/ssh # chmod 600 /etc/ssh/ssh_host_key # chmod 644 /etc/ssh/ssh_host_key.pub # chmod 644 /etc/ssh/sshd_config

Der letzte Schritt in der Administration des sshd-Dämons besteht nur noch darin, ihn zum Laufen zu bringen. Normalerweise erzeugen Sie dafür eine neue rc-Datei oder tragen ihn in eine bereits existierende Datei ein, um ihn beim Systemstart automatisch auszuführen. Der Dämon läuft für sich und braucht keinen Eintrag in der Datei /etc/inetd.conf. Der Dämon muß als root laufen. Die Syntax ist sehr einfach: /usr/sbin/sshd

Der sshd-Dämon versetzt sich beim Start automatisch in den Hintergrund. Nun sind Sie in der Lage, ssh-Verbindungen zu akzeptieren. Der ssh-Client Es gibt eine Reihe von ssh-Client-Programmen: slogin, scp und ssh. Sie alle lesen dieselbe Konfigurationsdatei ein, für gewöhnlich /etc/ssh/ssh_config. Außerdem lesen sie Konfigurationsdateien aus dem Verzeichnis .ssh im Home-Verzeichnis des Benutzers, der sie ausführt. Die wichtigsten dieser Dateien sind .ssh/config, die Optionen enthalten kann, die die in der Datei /etc/ssh/ssh_config enthaltenen Optionen überschreiben, außerdem .ssh/identity, die den benutzereigenen privaten Schlüssel enthält, und die entsprechende Datei .ssh/identity.pub mit dem öffentlichen Schlüssel des Benutzers. Weitere wichtige Dateien sind .ssh/known_hosts und .ssh/authorized_keys. Über sie sprechen wir später in “ssh anwenden”. Zunächst erzeugen wir die globale Konfigurationsdatei und die Schlüsseldatei des Benutzers. Die Datei /etc/ssh/ssh_config ist der Server-Konfigurationsdatei sehr ähnlich. Auch hier gibt es viele Features, die Sie konfigurieren können. Eine minimale Konfigurationsdatei hat die in Tabelle 12.5 gezeigte Form. Die restlichen Konfigurationsoptionen werden detailliert in der Manpage ssh(8) beschrieben. Sie können Abschnittehinzufügen, die zu bestimmten Hosts oder Gruppen von Hosts passen. Der Parameter für die Host-Anweisung kann entweder der vollständige Name eines Hosts oder ein Wildcard-Ausdruck sein, wie wir es in unserem Beispiel gemacht haben, um alle Hosts auszuwählen. Wir könnten zum Beispiel einen Eintrag wie Host *.vbrew.com erzeugen, der zu jedem Host in der Domain vbrew.com paßt. Beispiel 12.5: Beispiel-Konfigurationsdatei für ssh-Client # /etc/ssh/ssh_config # Standardoptionen für die Verbindung mit einem Remote-Host Host * # Session-Daten komprimieren? Compression yes # .. mit Komprimierungs-Level? (1 schnell/schwach, 9 - langsam/gut) CompressionLevel 6 # Zu rsh zurückkehren, falls die sichere Verbindung fehlschlägt? FallBackToRsh no # Keep-Alive-Nachrichten senden? Sinnvoll für IPMasquerading KeepAlive yes # RSA-Authentifizierung versuchen? RSAAuthentication yes # RSAAuthentifizierung in Kombination mit .rhosts-Authentifizierung versuchen? RhostsRSAAuthentication yes

Im Abschnitt über die Serverkonfiguration erwähnten wir, daß jeder Host und jeder Benutzer einen Schlüssel hat. Der Benutzerschlüssel wird in dessen ~/.ssh/identity-Datei gespeichert. Zur Erzeugung des Schlüssels benutzen Sie denselben sshkeygen-Befehl, den wir auch zur Erzeugung des Hostschlüssels verwendet haben; nur müssen Sie diesmal nicht den Namen der Datei angeben, in der Sie den Schlüssel aufbewahren wollen. ssh-keygen gibt dafür die richtige Voreinstellung an, fragt aber trotzdem nach, ob Sie einen anderen Dateinamen wünschen. Manchmal ist es sinnvoll, mehrere identity-Dateien zu haben, weshalb ssh dies auch gestattet. Wie vorher fordert ssh-keygen Sie auf, eine Paßphrase einzugeben. Paßphrasen tragen zur Erhöhung der Sicherheit bei und sind somit eine gute Sache. Ihre Paßphrase wird bei der Eingabe nicht auf dem Bildschirm angezeigt.

Achtung Es gibt keine Möglichkeit, eine Paßphrase wiederherzustellen, wenn Sie sie vergessen haben. Wählen Sie also eine, die Sie sich gut merken können; aber wie bei allen Paßwörtern sollten Sie auch hier nicht etwas wählen, was offensichtlich ist, zum Beispiel ein gängiges Substantiv oder Ihren Namen. Damit eine Paßphrase wirklich ihren Zweckerfüllt, sollte sie zwischen 10 und 30 Zeichen lang sein und keine einfache Prosa enthalten. Versuchen Sie, einige Sonderzeichen einzustreuen. Wenn Sie Ihre Paßphrase vergessen, kommen Sie nicht umhin, einen neuen Schlüssel zu erzeugen.

Sie sollten jeden Ihrer Anwender auffordern, den Befehl ssh-keygen nur einmal auszuführen, um sicherzustellen, daß ihre Schlüsseldatei korrekt erzeugt wird. Der Befehl erzeugt für sie ein ~/.ssh/-Verzeichnis mit den entsprechenden Zugriffsrechten und ihre privaten bzw. öffentlichen Schlüssel in .ssh/identity bzw. .ssh/identity.pub. Eine Beispielsitzung sollte so aussehen: $ ssh-keygen Generating RSA keys: .......oooooO.............................. Key generation complete. Enter file in which to save the key (/home/maggie/.ssh/identity): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/maggie/.ssh/identity. Your public key has been saved in /home/maggie/.ssh/identity.pub. The key fingerprint is: 1024 85:49:53:f4:8a:d6:d9:05:d0:1f:23:c4:d7:2a:11:67 maggie@moria $

Nun kann man mit ssh loslegen. ssh anwenden Nun sollten wir ssh und seine zugehörigen Programme installiert und betriebsfertig haben. Lassen Sie uns einen kurzenBlick darauf werfen, wie man sie anwendet. Als erstes versuchen wir uns in einen entfernten Host einzuloggen. Dazu können wir das Programm slogin benutzen, wie wir es bereits ähnlich in einem früheren Beispiel in diesem Buch mit rlogin gemacht haben. Beim ersten Versuch, eine Verbindung mit einem Host herzustellen, empfängt der ssh-Client den öffentlichen Schlüssel vom Host und fordert Sie auf, seine Identität zu bestätigen, indem er Ihnen eine Kurzform dieses Schlüssels ausgibt, die als “Fingerabdruck” bzw. Fingerprint bezeichnet wird. Der Administrator des Remote-Hosts sollte Ihnen bereits vorsorglich den Fingerprint des öffentlichen Schlüssels mitgeteilt haben. Diesen sollten Sie Ihrer Datei .ssh/known_hosts hinzufügen. Haben Sie dagegen noch keinen Fingerprint bekommen, können Sie sich trotzdem mit dem Remote-Host verbinden, jedoch warnt ssh Sie mit dem Hinweis, daß dieser einen Schlüssel hat, und fragt Sie, ob Sie den Schlüssel vom Remote-Host akzeptieren wollen. Wenn Sie sicher sind, daß niemand gerade ein DNS-Spoofing bei Ihnen durchführt und Sie tatsächlich mit dem richtigen Host kommunizieren, beantworten Sie die Frage mit “yes”. Der relevante Schlüssel wird dann automatisch in Ihrer .ssh/ known_hosts-Datei vermerkt, und Sie werden in Zukunft nicht mehr danach gefragt. Wenn Sie irgendwann wieder eine Verbindung aufbauen und der vom Host empfangene öffentliche Schlüssel nicht mit dem gespeicherten übereinstimmt, werden Sie gewarnt, da hier eine potentielle Sicherheitsverletzung vorliegt. Der erstmalige Login in einen Remote-Host geht etwa so vor sich: $ slogin vchianti.vbrew.com The authenticity of host 'vchianti.vbrew.com' can't be established. Key fingerprint is 1024 7b:d4:a8:28:c5:19:52:53:3a:fe:8d:95:dd:14:93:f5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'vchianti.vbrew.com,172.16.2.3' to the list of/ known hosts. [email protected]'s password: Last login: Tue Feb 1 23:28:58 2000 from vstout.vbrew.com $

Sie werden nach einem Paßwort gefragt. Hier sollten Sie das Paßwort für das Remote-Benutzerkonto eingeben, nicht für das lokale Benutzerkonto. Das Paßwort wird bei der Eingabe nicht angezeigt. Sind keine speziellen Argumente angegeben, versucht slogin einen Login mit derselben Benutzer-ID wie auf der lokalen Maschine. Mit der Option -l können Sie das überschreiben und einen alternativen Login-Namen für den Remote-Host angeben. Genau das machten wir bereits in unserem früheren Beispiel in diesem Buch. Dateien zum bzw. vom Remote-Host können wir mit dem Programm scp kopieren. Die Syntax gleicht der vom

konventionellen cp-Befehl mit der Ausnahme, daß Sie vor einem Dateinamen auch einen Hostnamen angeben können, was bedeutet, daß die Datei sich auf dem angegebenen Host befindet. Das folgende Beispiel veranschaulicht die Syntax von scp. Dabei wird eine lokale Datei namens /tmp/fred in das Verzeichnis /home/ -maggie/ des Remote-Hosts vchianti.vbrew.com kopiert: $ scp /tmp/fred vchianti.vbrew.com:/home/maggie/ [email protected]'s password: fred 100% |*****************************| 50165 00:01 ETA

Auch hier werden Sie nach einem Paßwort gefragt. Der Befehl scp zeigt standardmäßig nützliche Informationen über den aktuellen Stand des Dateitransfers an. Genauso einfach kopieren Sie eine Datei von einem Remote-Host. Dazu geben Sie einfach nur den Hostnamen und ein Verzeichnis als Quelle und das lokale Verzeichnis als Ziel an. Es ist sogar möglich, direkt von einem Remote-Host auf einen anderen zu kopieren. Allerdings ist das nicht sehr effizient, da die übertragenen Daten dann den Umweg über Ihren Host machen müssen. Mit ssh können Sie Befehle auf dem Remote-Host ausführen. Auch hier ist die Syntax sehr einfach. Nehmen wir an, unsere Benutzerin maggie will sich das Wurzelverzeichnis auf dem Remote-Host vchianti.vbrew.com ansehen. Das kann sie wie folgt tun: $ ssh vchianti.vbrew.com ls -CF / [email protected]'s password: bin/ console@ home/ lost+found/ pub@ tmp/ vmlinuz@ boot/ dev/ etc/ initrd/ mnt/ usr/ vmlinuz.old@ cdrom/ disk/ floppy/ lib/ proc/ sbin/ var/

dos/ root/

Sie können ssh auch in eine Befehls-Pipeline setzen und damit Ein-/Ausgabeumleitungen durchführen wie mit allen anderen Befehlen auch, mit der Ausnahme, daß die Ein- bzw. Ausgabe vom bzw. zum Remote-Host über die ssh-Verbindung erfolgt. Das folgende Beispiel zeigt, wie Sie diese Möglichkeit mit dem Befehl tar kombinieren können, um ein komplettes Verzeichnis inklusive Unterverzeichnissen von einem Remote-Host zum lokalen Host zu kopieren: $ ssh vchianti.vbrew.com "tar cf - /etc/" | tar xvf - [email protected]'s password: etc/GNUstep etc/Muttrc etc/Net etc/X11 etc/adduser.conf .. ..

In diesem Beispiel haben wir die auszuführende Anweisung in Anführungszeichen gesetzt, um festzulegen, was als Argument an ssh übergeben wird und was von der lokalen Shell verarbeitet werden soll. Die Anweisung startet das Programm tar auf dem Remote-Host, archiviert das Verzeichnis /etc/ und und gibt das Archiv auf der Standardausgabe aus. Diese Ausgabe leiten wir auf die Standardeingabe eines lokalen tar-Befehls um, der das Archiv auf der lokalen Maschine wieder entpackt. Wiederum werden wir nach dem Paßwort gefragt. Nun sehen Sie, warum wir die Empfehlung ausgesprochen haben, ssh so zu konfigurieren, daß es nicht jedesmal nach dem Paßwort fragt. Das holen wir jetzt für den Host vchianti.vbrew.com nach. Wir erwähnten früher bereits die Datei .ssh/authorized_keys — jetzt wissen Sie, wozu man sie braucht. Diese Datei enthält die öffentlichen Schlüssel für alle fernen Benutzerkonten, in die wir uns automatisch einloggen wollen. Die automatischen Logins können Sie aktivieren, indem Sie die Inhalte der Datei .ssh/identity.pub vom fernen Benutzerkonto in Ihre lokale Datei .ssh/authorized_keys kopieren. Achten Sie unbedingt darauf, daß die Zugriffsrechte von .ssh/authorized_keys so gesetzt sind, daß nur Sie darin lesen und schreiben können, damit nicht andere die Schlüssel stehlen und sich damit auf dem Remote-Host einloggen können.Um sicherzugehen, daß die Zugriffsrechte korrekt eingestellt sind, setzen Sie sie für .ssh/authorized_keys wie folgt: $ chmod 600 ~/.ssh/authorized_keys

Die öffentlichen Schlüssel bestehen aus einer einzelnen, langen Klartext-Zeile. Wenn Sie einen solchen Schlüssel mittels Copy und Paste in Ihre lokale Datei übertragen, stellen Sie sicher, daß Sie dabei nicht versehentlich irgendwelche anderen Zeichen (z.B. Zeilenwechsel) mit übernehmen. Die Datei .ssh/authorized_keys kann viele Schlüssel enthalten, jeden davon in einer eigenen Zeile. Die ssh-Software ist ein sehr mächtiges Werkzeug und bietet noch viele andere nützliche Eigenschaften und Optionen, die Sie vielleicht kennenlernen möchten. Mehr Informationen erhalten Sie in den Manpages und den anderen Dokumentationen zur ssh-Software.

1.

OpenSSH wurde vom OpenBSD-Projekt entwickelt und ist ein besonders gelungenes Beispiel dafür, was freie Software zustande bringen kann.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 13 Das Network Information System

Wenn Sie ein lokales Netzwerk betreiben, besteht Ihr Ziel normalerweise hauptsächlich darin, Ihren Benutzern eine Umgebung zur Verfügung zu stellen, die das Netzwerk transparent erscheinen läßt. Ein wichtiger Schritt in diese Richtung ist die Synchronisation wichtiger Daten wie BenutzerkontoInforma-tionen zwischen allen Hosts. Das gibt Ihren Benutzern die Freiheit, ihre vertraute Um-gebung

auf beliebigen Hosts vorzufinden, ohne sich dafür verschiedene Paßwörter -merken oder irgendwelche Dateien hin und her kopieren zu müssen. Solange es eine Möglichkeit gibt, von beliebigen netzwerkfähigen Hosts auf zentral gespeicherte Daten zuzugreifen, müssen diese Daten nicht repliziert werden. Durch eine zentrale Lagerung wichtiger administrativer Informationen kann die Konsistenz dieser Daten aufrechterhalten werden; den Anwendern kommt eine höhere Flexibilität zugute, da sie sich dann beliebig von einem Host zum anderen bewegen können. Außerdem wird dem Administrator die Arbeit erleichtert, da er sich dann nur noch um die zentral gelagerten Informationen kümmern muß. Wir sprachen bereits früher über ein wichtiges Beispiel für dieses im Internet verwendete Konzept — DNS. DNS ist für einen begrenzten Informationsbereich zuständig, von denen der wichtigste die Zuordnung von Hostnamen zu IP-Adressen ist. Einen solch spezialisierten Dienst gibt es für die anderen Informationsarten nicht. Zudem scheint die Einrichtung von DNS auf einem kleinen LAN ohne Internetanbindung kaum der Mühe wert zu sein. Aus diesem Grund entwickelte Sun NIS, das Network Information System. Die in NIS enthaltenen allgemeinen Zugriffsmechanismen für Datenbanken können beispielsweise dazu benutzt werden, um die in den Dateien passwd und groups enthaltenen Informationen an alle Hosts in Ihrem Netzwerk zu verteilen. Dadurch erscheint das Netzwerk als einzelnes System mit denselben Benutzerkonten auf allen Hosts. Auf ähnliche Weise können Sie NIS einsetzen, um die Informationen über Hostnamen aus /etc/hosts an alle Maschinen im Netzwerk zu verteilen. NIS basiert auf RPC und besteht aus einem Server, einer Bibliothek für die Client-Seite und verschiedenen administrativen Tools. Bekannt wurde NIS unter dem Namen Yellow Pages (“Gelbe Seiten”), kurz YP, der heute immer noch häufig verwendet wird. Andererseits ist “Yellow Pages” ein Warenzeichen der British Telecom, was dazu führte, daß Sun den Namen fallen ließ. Aber wie die Dinge nun einmal laufen, bleiben manche Namen einfach hängen, und so lebt YP als Präfix für die Namen der meisten NIS-Befehle wie ypserv, ypbind etc. weiter. Heutzutage ist NIS für nahezu jedes UNIX-System verfügbar. Es existieren sogar freie Implementierungen. Eine davon ist die BSD-Net-2-Ausgabe, die von einer freien Referenzimplementierung abgeleitet ist, die Sun bereitgestellt hat.Der Code der Client-Bibliothek dieser Ausgabe ist seit langer Zeit in der GNU-libc enthalten. Die administrativen Programme wurden von Swen Thümmler1 nach Linux portiert. Ein NIS-Server aus der Referenzimplementierung fehlt allerdings noch. Peter Eriksson2 entwickelte eine neue Implementierung, die unter der Bezeichnung NYS bekannt ist. Unterstützt wird dabei sowohl das einfache NIS als auch das von Sun stark verbesserte NIS+. NYS stellt nicht nur eine Reihe von NIS-Tools und einen Server zur Verfügung, sondern enthält auch einen kompletten Satz neuer Bibliotheksfunktionen. Wenn Sie diese Funktionen verwenden wollen, müssen Sie sie Ihrer libc während des Komplilierens hinzufügen. Es enthält ein neues Konfigurationsschema zur Auflösung von Hostnamen, das das aktuelle Schema ersetzt, das noch host.conf verwendet. Die GNU libc — in der Linux-Gemeinde allgemein als libc6 bekannt — enthält eine aktualisierte Version der traditionellen NIS-Unterstützung, die von Thorsten Kukuk entwickelt wurde.3 Sie

unterstützt alle Bibliotheksfunktionen von NYS und verwendet auch dessen erweitertes Konfigurationsschemata. Sie brauchen dafür zwar immer noch die Tools und den Server, aber dank GNU libc brauchen Sie sich nicht mehr mit Patches und Compiler-Läufen herumzuschlagen. In diesem Kapitel steht mehr die in der GNU libc-Bibliothek enthaltene NIS-Unterstützung als die anderen beiden Varianten im Mittelpunkt. Wenn Sie letztere Varianten ausprobieren möchten, könnten die in diesem Kapitel beschriebenen Instruktionen vielleicht nicht ausreichen. Zusätzliche Informationen finden Sie im NIS-HOWTO und in Büchern wie Managing NFS and NIS von Hal Stern (erschienen bei O'Reilly).

1.

Swen kann über [email protected] erreicht werden. Die NIS-Clients sind als yp-linux.tar.gz von metalab.unc.edu unter system/Network verfügbar.

2.

Zu erreichen unter [email protected] Die aktuelle Version von NYS ist 1.2.8.

3.

Thorsten ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Mit NIS vertraut werden NIS hält seine Datenbankinformationen in Dateien, die als Maps (etwa: Zuordnungen) bezeichnet werden und Schlüssel/WertPaare enthalten. Ein solches Paar besteht zum Beispiel aus einem Benutzernamen und einer verschlüsselten Version des Login-Paßwortes. Maps werden auf einem zentralen Host gespeichert, auf dem der NIS-Server läuft. Clients erhalten die Informationen von diesem Server über verschiedene RPC-Aufrufe. Häufig werden Maps in DBM-Dateien gespeichert.1 Die Maps selbst werden üblicherweise aus sogenannten Master-Dateien generiert. Dabei handelt es sich um Textdateien wie /etc/hosts oder /etc/passwd. Für manche Dateien werden mehrere Maps erzeugt, jeweils eine pro Suchschlüsseltyp. Zum Beispiel können Sie die hosts-Datei sowohl nach einem Hostnamen als auch nach einer IP-Adresse durchsuchen. Dementsprechend werden daraus zwei NIS-Maps erzeugt: hosts. byname und hosts.byaddr. Tabelle 13.1 enthält eine Liste der gängigen Maps und der Dateien, aus denen sie generiert werden. Tabelle 13.1: Einige Standard-NIS-Maps und die entsprechenden Dateien Master-Datei Map(s)

Erläuterung

hosts.byname, hosts.byaddr

Zuordnung von Hostnamen und IP-Adressen.

networks.byname, networks.byaddr

Zuordnung von IP-Netzwerkadressen und Netzwerk-namen.

/etc/passwd

passwd.byname, passwd.byuid

Zuordnung von verschlüsselten Paßwörtern und Benutzernamen.

/etc/group

group.byname, group.bygid

Zuordnung von Gruppen-IDs und Gruppennamen.

/etc/services

services.byname, services.bynumber

Zuordnung von Dienstbeschreibungen und Dienst-namen.

rpc.byname, rpc.bynumber

Zuordnung von Sun-RPC-Dienstnummern und RPC-Dienstnamen.

/etc/hosts /etc/ -networks

/etc/rpc

/etc/ -protocols

protocols.byname, protocols.bynumber Zuordnung von Protokollnummern und Protokollnamen.

/usr/lib/aliases mail.aliases

Zuordnung von Mail-Aliases und Mail-Alias-Namen.

In anderen NIS-Paketen könnten auch weitere Dateien und Maps unterstützt werden. Diese enthalten in der Regel Informationen zu Programmen, die in diesem Buch nicht behandelt werden. Dazu gehört beispielsweise die Map bootparams, die von Suns -bootparamd-Server verwendet wird. Für einige Maps werden normalerweise Spitznamen (Nicknames) verwendet, die kürzer und darum auch einfacher einzugeben sind. Beachten Sie, daß diese Spitznamen nur von ypcat und ypmatch verstanden werden. Das sind zwei Tools, mit denen Sie Ihre NIS-Konfiguration überprüfen können. Um eine Übersicht aller in diesen Programmen bekannten Spitznamen zu erhalten, führen Sie den folgenden Befehl aus: $ ypcat -x Use "passwd" for "passwd.byname" Use "group" for "group.byname" Use "networks" for "networks.byaddr" Use "hosts" for "hosts.byaddr" Use "protocols" for "protocols.bynumber" Use "services" for "services.byname" Use "aliases" for "mail.aliases" Use "ethers" for "ethers.byname"

Das NIS-Serverprogramm wird traditionell ypserv genannt. Für ein durchschnittliches Netzwerk reicht ein einzelner Server normalerweise aus. Große Netzwerke verwenden mehrere davon auf verschiedenen Maschinen und Segmenten des Netzwerks, um die Last der Server und Router zu verringern. Diese Server werden synchronisiert, indem einer von ihnen als Master-Server und die anderen als Slave-Server eingerichtet werden. Die Maps werden nur auf dem Host des Master-Servers erzeugt. Von dort aus werden sie an alle Slaves verteilt. Wir haben uns bisher nur sehr oberflächlich über “Netzwerke” unterhalten. Unter NIS gibt es eine eindeutige Bezeichnung für eine Gruppe aller Maschinen, die sich einen Teil ihrer Systemkonfigurationsdaten über NIS teilen: die NIS-Domain. Leider haben NIS-Domains überhaupt nichts mit den Domains gemeinsam, denen wir bei DNS begegnet sind. Um in diesem Kapitel Verwechslungen zu vermeiden, geben wir immer an, welchen Typ wir gerade meinen. NIS-Domains haben nur eine rein administrative Funktion. Sie sind zumeist unsichtbar für die Anwender, ausgenommen, es geht um die gemeinsame Nutzung von Paßwörtern zwischen allen Maschinen in der Domain. Der an eine NIS-Domain vergebene Name ist daher nur für die Administratoren von Bedeutung. Für gewöhnlich kann jeder Name genommen werden, solange er sich von den anderen NIS-Domainnamen in Ihrem LAN unterscheidet. Beispielsweise könnte die Administratorin der virtuellen Brauerei sich entschließen, zwei NIS-Domains aufzubauen, eine für die Brauerei selbst und eine für die Winzerei, für die sie die Namen brewery bzw. winery wählt. Häufig wird einfach der DNS-Domainname auch für NIS benutzt. Den NIS-Domainnamen Ihres Hosts können Sie mit dem Befehl domainname setzen. Rufen Sie ihn ohne Argumente auf, wird der aktuelle NIS-Domainname ausgegeben. Wenn Sie den Namen neu setzen wollen, müssen Sie als root folgendes eingeben: # domainname brewery

NIS-Domains bestimmen, welchen NIS-Server eine Anwendung abfragt. Zum Beispiel sollte das login-Programm auf einem Host der Winzerei natürlich nur den NIS-Server der Winzerei (oder einen davon, falls es mehrere gibt) nach den Paßwortinformationen eines Benutzers abfragen. Eine Anwendung auf einem Host der Brauerei sollte dementsprechend den Server der Brauerei verwenden. Ein Geheimnis muß allerdings noch gelüftet werden: Wie findet ein Client heraus, auf welchen Server er zugreifen muß? Die einfachste Lösung wäre eine Konfigurationsdatei, die den Namen des Hosts enthält, auf dem sich der Server befindet. Andererseits ist diese Lösung ziemlich unflexibel, weil sie es Clients nicht erlaubt, auf verschiedene Server (natürlich innerhalb derselben Domain) — abhängig von ihrer Verfügbarkeit — zuzugreifen. NIS-Implementierungen vertrauen daher einem speziellen Dämon namens ypbind, um einen geeigneten NIS-Server in ihrer NIS-Domain zu ermitteln. Bevor eine Anwendung irgendwelche NIS-Anfragen durchführt, fragt sie erst bei ypbind an, welchen Server sie dafür benutzen soll.

ypbind sucht nach Servern, indem es eine Broadcast-Anfrage an alle Stationen im lokalen IP-Netzwerk verschickt. Der erste Server, der antwortet, wird als der schnellste betrachtet und für alle weiteren NIS-Anfragen eingesetzt. Nach einer gewissen Zeit oder falls der Server nicht mehr erreichbar ist, sucht ypbind erneut nach aktiven Servern. Dynamische Bindung ist nur dann wirklich nützlich, wenn Ihr Netzwerk mehrere NIS-Server zur Verfügung stellt. Dynamische Bindung bringt allerdings auch ein Sicherheitsproblem mit sich: ypbind vertraut blindlings jedem, der antwortet, sei es ein einfacher NIS-Server oder ein böswilliger Eindringling. Müßig zu erwähnen, daß dies besonders gefährlich wird, wenn Sie Ihre Paßwortdateien über NIS verwalten. Um sich davor zu schützen, bietet Ihnen das ypbind-Programm in Linux die Option, das lokale Netzwerk nach einem lokalen NIS-Server zu durchsuchen oder den Hostnamen des NIS-Servers direkt in einer Konfigurationsdatei vorzugeben.

1.

DBM ist eine einfache Datenbankverwaltungs-Bibliothek, die eine Hashtechnik verwendet, um Suchoperationen zu beschleunigen. Vom GNU-Projekt gibt es eine freie DBM-Implementierung namens gdbm, die in den meisten LinuxDistributionen enthalten ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NIS verglichen mit NIS+ NIS und NIS+ haben nur wenig mehr als ihre Namen und dasselbe Ziel gemeinsam. NIS+ ist völlig anders strukturiert als NIS. Anstelle eines flachen Namensraums mit unzusammenhängenden NISDomains verwendet es — ähnlich wie DNS — einen hierarchischen Namensraum. Statt Maps werden sogenannte Tabellen verwendet, die aus Zeilen und Spalten bestehen. Jede Zeile repräsentiert ein Objekt in der NIS+-Datenbank, und die Spalten beschreiben die Eigenschaften der Objekte, die NIS+ kennt und verwaltet. Jede Tabelle für eine gegebene NIS+-Domain umfaßt die Tabellen ihrer ParentDomains. Darüber hinaus kann jeder Eintrag in der Tabelle einen Verweis auf eine andere Tabelle enthalten. Diese Eigenschaften machen es möglich, Informationen auf unterschiedlichste Arten zu strukturieren. NIS+ unterstützt außerdem sicheres und verschlüsseltes RPC, was erheblich dazu beiträgt, die Sicherheitsprobleme von NIS zu lösen. Das traditionelle NIS verwendet die RPC-Versionsnummer 2, während NIS+ die Versionsnummer 3 hat. Als dieses Buch geschrieben wurde, existierte noch keine ausgereifte Implementierung von NIS+ für Linux, weshalb es hier nicht weiter behandelt wird.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Client-Seite von NIS Wenn Sie mit der Erstellung oder Portierung von Netzwerkanwendungen vertraut sind, werden Sie feststellen, daß die meisten der oben aufgeführten NIS-Maps mit Bibliotheksfunktionen der CBibliothek übereinstimmen. Um beispielsweise passwd-Informationen zu bekommen, nutzen Sie im allgemeinen die Funktionen getpwnam bzw. getpwuid, die die mit einem Benutzernamen bzw. einer Benutzer-ID verknüpften Benutzerkonto-Informationen zurückliefern. Unter normalen Umständen führen die Funktionen die erforderlichen Suchvorgänge in den Standarddateien wie /etc/passwd durch. Eine Implementierung dieser Funktionen, bei der NIS berücksichtigt wird, modifiziert dieses Verhalten etwas und fügt einen RPC-Aufruf ein, damit der NIS-Server nach dem Benutzernamen oder der -ID sucht. Diese Operation verläuft transparent für die jeweilige Anwendung. Die Funktion kann die NIS-Daten so behandeln, als ob sie an die originale passwd-Datei angehängt worden wären, so daß der Applikation beide Informationsarten zur Verfügung stehen und diese auch genutzt werden, oder als ob die lokale passwd-Datei komplett ersetzt worden wäre, so daß Informationen daraus ignoriert und nur die NIS-Daten verwendet werden. Bei traditionellen NIS-Implementierungen gab es verschiedene Konventionen, die festlegten, welche Maps die Originalinformationen ersetzten und welche an sie angehängt wurden. Einige, wie beispielsweise die passwd-Maps, erforderten Modifikationen an der passwd-Datei. Wurden diese nicht korrekt durchgeführt, öffneten sich aber Sicherheitslücken. Um solchen Fallstricken zu

entgehen, verwenden NYS und die GNU libc-Bibliothek ein allgemeines Konfigurationsschema, das bestimmt, ob und in welcher Reihenfolge eine Menge von Client-Funktionen die Original-, NIS- oder NIS+-Dateien verwendet. Darauf wird später in diesem Kapitel noch eingegangen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Betrieb eines NIS-Servers Nach so viel Theorie wird es langsam Zeit, daß wir uns bei der eigentlichen Konfigurationsarbeit die Hände schmutzig machen.In diesem Abschnitt behandeln wir die Konfiguration eines NIS-Servers. Läuft bereits ein NIS-Server in Ihrem Netz, müssen Sie keinen eigenen einrichten. In dem Fall können Sie diesen Abschnitt getrost überspringen. Wenn Sie nur ein wenig mit dem Server experimentieren wollen, müssen Sie unbedingt darauf achten, keinen NIS-Domainnamen zu verwenden, der in Ihrem Netzwerk bereits eingesetzt wird. Das könnte die gesamten Netzwerkdienste zum Absturz bringen und viele Leute sehr verzweifelt und sehr ärgerlich machen. Es gibt zwei mögliche NIS-Server-Konfigurationen: Master und Slave. Sollte Ihr Master-Server mal ausfallen, stellt die Slave-Konfiguration einen Live-Backup-Rechner zur Verfügung. Hier behandeln wir nur die Konfiguration eines Master-Servers. Wenn Sie auch einen Slave-Server konfigurieren wollen, erklärt Ihnen die Serverdokumentation die Unterschiede. Für Linux existieren zur Zeit zwei freie NIS-Server-Implementierungen. Die eine ist in Tobias Rebers yps-Paket enthalten, die andere in Peter Erikssons ypserv-Paket. Welche Implementierung Sie nehmen, bleibt Ihnen überlassen.

Nach der Installation des Serverprogramms (ypserv) in /usr/sbin sollten Sie das Verzeichnis anlegen, in dem Sie die Map-Dateien speichern wollen, die Ihr Server verteilen soll. Beim Einrichten der NISDomain für die brewery-Domain würden die Maps in /var/yp/brewery untergebracht werden. Der Server prüft, ob er eine bestimmte NIS-Domain bedient, indem er nachsieht, ob ein entsprechendes Map-Verzeichnis vorhanden ist. Wenn Sie eine NIS-Domain nicht mehr versorgen wollen, müssen Sie sicherstellen, daß Sie auch das Verzeichnis löschen. Maps werden üblicherweise in DBM-Dateien gespeichert, um die Suchzeiten zu minimieren. Diese werden aus den Master-Dateien erzeugt, wobei ein Programm namens makedbm (für Tobias' Server) bzw. dbmload (für Peters Server) eingesetzt wird. Die Umwandlung einer Master-Datei in eine für dbmload verwendbare Form erfordert normalerweise ein bißchen awk oder sed-Magie. Peter Erikssons ypserv-Paket enthält daher ein Makefile (ypMakefile), das Ihnen die Konvertierung der allgemeinsten Master-Dateien abnimmt. Sie sollten es unter dem Namen Makefile in Ihrem Map-Verzeichnis installieren und es so editieren, daß alle benötigten Maps enthalten sind. Ziemlich zu Anfang der Datei finden Sie den Eintrag all, der die Dienste aufführt, die ypserv anbieten soll. Normalerweise sieht die Zeile in etwa so aus: all: ethers hosts networks protocols rpc services passwd group netid

Sollen beispielsweise keine ethers.byname- und ethers.byaddr-Maps erzeugt werden, entfernen Sie einfach die Bedingung ethers aus dieser Regel. Um Ihr Setup zu testen, können Sie zuerst mit ein oder zwei Maps wie den services.*-Maps beginnen. Nachdem Sie die entsprechenden Korrekturen am Makefile vorgenommen haben, geben Sie im MapVerzeichnis einfach make ein. Die Maps werden nun automatisch generiert und installiert. Sie müssen die Maps jedesmal aktualisieren, wenn Sie die Master-Dateien verändern, weil diese Änderungen sonst für das Netzwerk nicht sichtbar sind. Der Abschnitt “Einrichtung eines NIS-Clients mit GNU libc” beschreibt die Konfiguration des NISClient-Codes. Wenn Ihr Setup nicht funktioniert, sollten Sie prüfen, ob überhaupt Anforderungen bei Ihrem Server eingehen oder nicht. Wenn Sie ypserv mit der Kommandozeilenoption -debug starten, werden Debugging-Informationen zu allen NIS-Anforderungen und zu den zurückgelieferten Resultaten auf die Konsole ausgegeben. Dies sollte Ihnen einen Hinweis darauf geben, wo das Problem liegt. Tobias' Server verfügt über keine solche Option.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Sicherheit von NIS-Servern NIS hatte eine große Sicherheitslücke: Beinahe jeder im gesamten Internet konnte Ihre Paßwortdatei lesen, was für eine beträchtliche Anzahl möglicher Eindringlinge sorgte. Wenn ein Eindringling Ihren NIS-Domainnamen und die Adresse Ihres Servers kannte, konnte er einfach eine Anforderung an die passwd.byname-Map schicken und erhielt die gesamten verschlüsselten Paßwörter Ihres Systems. Ausgestattet mit einem schnellen Paßwort-Knackprogramm wie crack und mit einem guten Wörterbuch, ist es kaum ein Problem, die Paßwörter von zumindest einigen Benutzern zu knacken. Aus diesem Grund wurde die Option securenets eingeführt. Sie beschränkt den Zugriff auf Ihren NIS-Server anhand der IP-Adresse oder der Netzwerknummer auf bestimmte Hosts. Die neueste Version von ypserv implementiert diese Eigenschaft auf zweierlei Weise. Die erste basiert auf einer speziellen Konfigurationsdatei namens /etc/ypserv.securenets, die zweite verwendet die Dateien /etc/hosts.allow und /etc/hosts.deny, denen wir ja bereits in Kapitel 12 Wichtige Netzwerk-Features, begegnet sind.1 Um den Zugriff beispielsweise auf die Hosts innerhalb der Brauerei zu beschränken, würden deren Netzwerkmanager die folgende Zeile in hosts.allow aufnehmen: ypserv: 172.16.2.

So können alle Hosts vom IP-Netzwerk 172.16.2.0 auf den NIS-Server zugreifen. Um alle anderen Hosts auszuschließen, müßte folgender Eintrag in hosts.deny aufgenommen werden: ypserv: ALL

IP-Nummern sind nicht der einzige Weg, Hosts oder Netzwerke in hosts.allow und hosts.deny anzugeben. Details entnehmen Sie bitte der hosts_access(5)-Manpage Ihres Systems. Aber Vorsicht: Host- oder Domainnamen können bei ypserv-Einträgen nicht verwendet werden. Wenn Sie einen Hostnamen angeben, versucht der Server ihn aufzulösen — aber der Resolver ruft wiederum ypserv auf, und Sie enden in einer Endlosschleife.

Zur Konfiguration des securenets-Sicherheitsmechanismus mit der /etc/ypserv.securenets-Methode müssen Sie die Konfigurationsdatei /etc/ypserv.securenets erzeugen. Die Struktur dieser Datei ist recht einfach. Jede Zeile beschreibt einen Host oder ein Netzwerk aus Hosts, der bzw. das Zugriff auf den Server erhält. Jeder Adresse, die nicht in irgendeiner Zeile in dieser Datei angegeben ist, wird der Zugriff verweigert. Zeilen, die mit einem # beginnen, werden als Kommentare aufgefaßt. Beispiel Tabelle 13.1 zeigt, wie eine einfache /etc/ypserv.securenetsDatei aussehen könnte: Beispiel 13.1: Beispieldatei ypserv.securenets # Verbindungen zum lokalen Host gestatten -- notwendig host 127.0.0.1 # dasselbe wie 255.255.255.255 127.0.0.1 # # Verbindungen von beliebigen Hosts im virtuellen Brauerei-Netz gestatten 255.255.255.0 172.16.1.0 #

Der erste Eintrag jeder Zeile ist die Netzmaske, die für den Eintrag verwendet werden soll. host ist ein spezielles Schlüsselwort und bedeutet “netmask 255.255.255.255”. Der zweite Eintrag jeder Zeile ist die IP-Adresse, auf die die Netzmaske angewendet wird. Als dritte Option können Sie auch den sicheren Portmapper anstelle der Option securenets in ypserv verwenden. Der sichere Portmapper (portmap-5.0) verwendet ebenfalls das Schema mit hosts.allow, bietet dieses aber für alle RPC-Server an, nicht nur für ypserv.2 Aufgrund des Verwaltungsaufwands, den diese Authentifizierung mit sich bringt, sollten Sie die Option securenets und den sicheren Portmapper nicht gleichzeitig verwenden.

1.

Um die /etc/hosts.allow-Methode zu aktivieren, müssen Sie unter Umständen den Server neu kompilieren. Bitte lesen Sie die entsprechenden Anweisungen in der der Distribution beiliegenden README-Datei.

2.

Der sichere Portmapper kann per anonymous FTP von ftp.win.tue.nl unterhalb des Verzeichnisses /pub/security/ bezogen werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Mit GNU libc einen NIS-Client einrichten Wir behandeln nun die Konfiguration eines NIS-Clients, der die GNU libc-Bibliothek nutzt. Im ersten Schritt sollten Sie dem GNU libc-NIS-Client mitteilen, welcher Server für den NIS-Dienst verwendet werden soll. Wir hatten bereits früher erwähnt, daß ypbind erlaubt, den zu benutzenden NIS-Server anzugeben. Normalerweise wird immer eine Standardmäßig wird eine Anfrage an den Server im lokalen Netzwerk gestellt. Wenn der Host, den Sie konfigurieren, häufig von einer Domain in eine andere transportiert wird, wie bei einem Laptop, würden Sie die Datei /etc/yp.conf leer lassen, damit der Host, wo immer er sich auch befindet, im lokalen Netz immer erst eine Anfrage nach dem zuständigen lokalen NISServer stellt. Die meisten Hosts werden noch sicherer konfiguriert, indem der Name des Servers in die Konfigurationsdatei /etc/yp.conf eingetragen wird. Eine sehr einfache Datei für einen Host des Winzerei-Netzwerks würde wie folgt aussehen: # yp.conf - YP-Konfiguration für GNU libc-Bibliothek. # ypserver vbardolino

Die Anweisung ypserver weist Ihren Host an, den angegebenen Host als NIS-Server für die lokale Domain zu benutzen. In diesem Beispiel haben wir als NIS-Server vbardolino angegeben. Natürlich muß die zu vbardolino gehörende IP-Adresse in hosts eingetragen sein. Alternativ können Sie die IP-Adresse auch direkt in der ypserver-Anweisung angeben. In der oben aufgeführten Form weist der ypserver-Befehl ypbind an, den angegebenen Server zu verwenden, unabhängig von der aktuellen NIS-Domain. Wenn Sie sich aber mit Ihrem Rechner häufig in unterschiedlichen Domains bewegen, wollen Sie vielleicht die Informationen zu den verschiedenen Domains ebenfalls in Ihrer yp.conf festhalten. Sie können Informationen über Server verschiedener NIS-Domains in yp.conf speichern, indem Sie die Informationen im domain-Befehl angeben. Für einen Laptop könnte die obige Beispieldatei etwa wie folgt geändert werden: # yp.conf - YP-Konfiguration für GNU libc-Bibliothek. # domain winery server vbardolino domain brewery server vstout

Das fährt den Laptop in einer der beiden Domains hoch, indem Sie einfach die gewünschte NIS-Domain beim Systemstart mit dem Befehl domainname setzen. Der NIS-Client benutzt dann automatisch den für diese Domain relevanten Server. Es gibt noch eine dritte Option, die Sie anwenden können. Sie betrifft den Fall, wenn Sie nicht genau wissen, welchen Namen

oder welche IP-Adresse der Server einer bestimmten Domain hat, aber trotzdem die Möglichkeit haben wollen, den Server für ausgewählte Domains festzulegen. Stellen Sie sich vor, wir bestehen darauf, einen festgelegten Server zu benutzen, wenn wir uns im Winzerei-Netz aufhalten. Befinden wir uns jedoch im Netzwerk der Brauerei, wollen wir den zuständigen Server ermitteln. Dazu würden wir unsere yp.conf-Datei wie folgt modifizieren: # yp.conf - YP-Konfiguration für GNU libc-Bibliothek. # domain winery server vbardolino domain brewery broadcast

Das Schlüsselwort broadcast teilt ypbind mit, einen beliebigen NIS-Server für die Domain zu ermitteln. Nachdem Sie die grundlegende Konfigurationsdatei erzeugt und sichergestellt haben, daß sie allgemein lesbar ist, sollten Sie den ersten Test durchführen, um zu prüfen, ob Sie sich an Ihren Server anbinden können. Wählen Sie eine Map wie hosts.byname, von der Sie sicher sind, daß Ihr Server sie auch verteilt, und versuchen Sie, mit Hilfe des ypcat-Utilities auf sie zuzugreifen: # ypcat hosts.byname 172.16.2.2 vbeaujolais.vbrew.com vbeaujolais 172.16.2.3 vbardolino.vbrew.com vbardolino 172.16.1.1 vlager.vbrew.com vlager 172.16.2.1 vlager.vbrew.com vlager 172.16.1.2 vstout.vbrew.com vstout 172.16.1.3 vale.vbrew.com vale 172.16.2.4 vchianti.vbrew.com vchianti

Die Ausgabe sollte mit dem oben Gezeigten vergleichbar sein. Erhalten Sie statt dessen die Fehlermeldung Can't bind to server which serves domain, dann existiert für den von Ihnen gesetzten NIS-Domainnamen entweder kein passender in yp.conf definierter Server, oder der Server ist aus irgendeinem Grund nicht erreichbar. Im letzteren Fall sollten Sie mit ping prüfen, ob der Host überhaupt präsent ist. Daß auch tatsächlich ein NIS-Server auf diesem Host läuft, können Sie mit dem Befehl rpcinfo überprüfen, der Ihnen folgendes Resultat liefern sollte: # rpcinfo -u serverhost ypserv program 100004 version 1 ready and waiting program 100004 version 2 ready and waiting

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Wahl der richtigen Maps Wenn Sie sicher sind, daß Sie den NIS-Server erreichen, müssen Sie entscheiden, welche Konfigurationsdateien durch NIS-Maps ersetzt oder erweitert werden sollen. Üblicherweise wollen Sie NIS-Maps für die Host- und Paßwort-Lookup-Funktionen benutzen. Das erstere ist besonders nützlich, wenn Sie keinen BIND-Dienst haben. Durch den Paßwort-Lookup können sich alle Benutzer an jedem System innerhalb der NIS-Domain einloggen. Das geht normalerweise einher mit der Nutzung eines zentralen /home-Verzeichnisses zwischen allen Hosts über NFS. Die Paßwort-Map wird im nächsten Abschnitt ausführlich behandelt. Andere Maps wie services.byname bieten Ihnen keine solch großartigen Vorteile, sparen Ihnen aber einiges an Tipparbeit. services.byname ist besonders nützlich, wenn Sie Netzwerkanwendungen installieren, die den Namen eines Dienstes verwenden, der nicht in der standardmäßigen services-Datei angegeben ist. Normalerweise wollen Sie die Wahl haben, wann eine Lookup-Funktion die lokalen Dateien, den NIS-Server oder andere Server wie DNS verwendet. Bei GNU libc können Sie die Reihenfolge festlegen, in der eine Funktion auf diese Dienste zugreift. Gesteuert wird dies durch die Datei /etc/nsswitch.conf, die für Name Service Switch steht, aber natürlich nicht nur auf den Namensdienst beschränkt ist. Für jede der von GNU libc unterstützten Lookup-Funktionen enthält sie eine Zeile, die die Namen der zu verwendenden Dienstes enthält. Die richtige Reihenfolge der Dienste ist vom Typ der Daten abhängig, den die Dienste anbieten. Es ist unwahrscheinlich, daß die services.byname-Map Einträge enthält, die sich von der lokalen services-Datei unterscheiden; eher enthält sie zusätzliche Einträge. Es ist also durchaus sinnvoll, zuerst die lokalen Dateien abzufragen und NIS nur dann zu nutzen, wenn der Service-Name nicht gefunden werden konnte. Andererseits können sich Informationen zu Hostnamen sehr häufig verändern, so daß DNS oder NIS die genauesten Informationen enthalten sollten, während die lokale hosts-Datei nur als Backup verwendet wird, falls DNS und NIS nicht funktionieren sollten. Für Hostnamen würden Sie die lokalen Dateien also zuletzt verwenden.

Das folgende Beispiel zeigt, wie Sie gethostbyname und gethostbyaddr dazu bringen, zuerst in NIS und DNS nachzusehen, bevor auf die lokale hosts-Datei zugegriffen wird, und wie Sie getservbyname veranlassen, erst in den lokalen Dateien zu suchen und erst dann NIS zu befragen. Diese Resolver-Funktionen probieren die aufgelisteten Dienste der Reihe nach durch. Ist ein Lookup erfolgreich, wird das Ergebnis zurückgegeben, ansonsten wird der nächste Service ausprobiert. Die Prioritäten werden wie folgt definiert: # Beispieldatei /etc/nsswitch.conf # hosts:

nis dns files services:

files nis

Eine komplette Liste aller Dienste und Orte, die mit einem Eintrag in nsswitch.conf verwendet werden können, ist nachfolgend aufgeführt. Welche Maps, Dateien, Server und Objekte tatsächlich angefordert werden, ist vom Namen des Eintrags abhängig. Nach dem Doppelpunkt kann folgendes erscheinen: nis Wie der abzufragende Server erreicht werden kann, wird in der Datei yp.conf festgelegt, wie im vorhergehenden Abschnitt beschrieben. Beim hosts-Eintrag werden die Maps hosts.byname und hosts.byaddr abgefragt. nisplus oder nis+ Benutze den NIS+-Server für diese Domain. Wo der Server erreicht werden kann, wird der Datei /etc/nis.conf entnommen. dns Benutze den DNS-Name-Server. Dieser Service-Typ ist nur für den hosts-Eintrag sinnvoll. Die abzufragenden Name-Server werden weiterhin aus der Standarddatei resolv.conf ermittelt. files Benutze die lokale Datei, wie z.B. /etc/hosts für den hosts-Eintrag. compat Für Kompatibilität mit älteren Dateiformaten. Diese Option kann benutzt werden, wenn entweder NYS oder glibc 2.x für NIS- und NIS+-Lookups verwendet werden. Normalerweise können diese Versionen ältere NIS-Einträge in passwd und group nicht verarbeiten. Erst die Option compat macht es möglich. db Suche die Informationen in DBM-Dateien im Verzeichnis /var/dbm. Der für die Datei verwendete Name ist derjenige der entsprechenden NIS-Map. Momentan unterstützt NIS in GNU libc die folgenden nsswitch.conf-Einträge: aliases, ethers.group, hosts, netgroup, network, passwd, protocols, publickey, rpc, services und shadow. Weitere Einträge werden wohl folgen. Tabelle 13.2 zeigt ein vollständigeres Beispiel, das ein weiteres Feature von nsswitch. conf einführt. Das Schlüsselwort [NOTFOUND=return] im hosts-Eintrag weist den NIS-Client an, die Suche abzubrechen, wenn

der benötigte Eintrag in der NIS- oder DNS-Datenbank nicht gefunden werden konnte. Das bedeutet, daß der NISClient die Suche in lokalen Dateien nur aufnimmt, wenn Anforderungen an die NIS- oder DNS-Server aus einem anderen Grund fehlgeschlagen sind. Die lokalen Dateien werden dann nur während des Systemstarts und als Backup benutzt, wenn der NIS-Server nicht erreichbar ist. Beispiel 13.2: Beispieldatei nsswitch.conf # /etc/nsswitch.conf # hosts: [NOTFOUND=return] files services:

nis dns [NOTFOUND=return] files networks: files nis protocols: files nis rpc:

GNU libc bietet noch einige andere Aktionen, die in der Manpage nsswitch beschrieben sind.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

nis files nis

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verwendung von passwd- und group-Maps Eine der Hauptanwendungen von NIS ist die Synchronisation von Benutzer- und Accounting-Informationen auf allen Hosts in einer NIS-Domain. Daher haben Sie üblicherweise nur eine kleine lokale /etc/passwd-Datei, an die die Domainweiten Informationen aus den NIS-Maps angehängt werden. Allerdings reicht die Aktivierung von NIS-Lookups für diesen Service in nsswitch.conf bei weitem nicht aus. Wenn Sie sich auf die von NIS verteilten Paßwortinformationen verlassen, müssen Sie zuerst sicherstellen, daß die numerischen Benutzer-IDs aller in Ihrer lokalen passwd-Datei stehenden Benutzer mit den Vorstellungen des NIS-Servers von Benutzer-IDs übereinstimmen. Die Konsistenz der Benutzer-IDs ist auch wichtig für andere Zwecke, wie etwa dem Mounten von NFS-Verzeichnissen von anderen Hosts in Ihrem Netzwerk. Wenn sich numerische IDs in /etc/passwd oder /etc/group von denen in den Maps unterscheiden, müssen Sie zuerst die Besitzrechte für alle Dateien korrigieren, die diesem Benutzer gehören. Zuerst sollten Sie alle UIDs und GIDs in passwd und group auf die neuen Werte setzen, alle Dateien suchen, die den gerade geänderten Benutzern gehören, und schließlich deren Besitzrechte entsprechend ändern. Nehmen wir einfach an, news hätte die Benutzer-ID 9 und okir hätte die BenutzerID 103 gehabt, die beide durch einen anderen Wert ersetzt wurden. Sie können dann als root die folgenden Befehle eingeben: # find / -uid 9 -print >/tmp/uid.9 # find / -uid 103 -print >/tmp/uid.103 # cat /tmp/uid.9 xargs chown news # cat /tmp/uid.103 | xargs chown okir

|

Es ist wichtig, daß Sie diese Befehle mit der neu installierten passwd-Datei aufrufen und daß Sie alle Dateinamen ermitteln, bevor Sie deren Besitzrechte ändern. Zum Aktualisieren der Gruppen-Besitzerrechte verwenden Sie einen vergleichbaren Befehl mit der GID anstelle der UID und chgrp anstelle von chown. Nachdem Sie dies erledigt haben, stimmen die numerischen UIDs und GIDs auf Ihrem System mit denen auf allen anderen Hosts in Ihrer NIS-Domain überein. Der nächste Schritt ist, einige Konfigurationszeilen in nsswitch.conf einzutragen, die die NIS-Look-ups für Benutzer- und Gruppeninformationen aktivieren: # /etc/nsswitch.conf - Behandlung von passwd und group passwd: nis files group:

nis files

Dies hat Einfluß darauf, wo der login-Befehl und all seine Freunde nach Benutzerinformationen Ausschau halten. Versucht sich ein Benutzer einzuloggen, fragt login zuerst die NIS-Maps ab; erst wenn dies fehlschlägt, wird auf die lokalen Dateien zurückgegriffen. Üblicherweise entfernen Sie fast alle Benutzer aus Ihren lokalen Dateien und lassen nur Einträge für root und allgemeine Benutzerkonten wie mail stehen. Der Grund dafür liegt darin, daß einige wichtige System-Tasks UIDs auf Benutzernamen abbilden müssen und umgekehrt. Zum Beispiel könnten administrative cron-Jobs den su-Befehl ausführen, um kurzzeitig news zu werden, oder das UUCP-Subsystem könnte einen Statusreport über E-Mail übertragen. Besitzen news und uucp keinen Eintrag in der lokalen passwd-Datei, schlagen diese Jobs während eines NIS-Ausfalls kläglich fehl. Wenn Sie schließlich eine der alten NIS-Implementierungen benutzen (unterstützt vom compat-Modus für die passwd- und group-Dateien in den NYS- oder glibc-Implementierungen), müssen Sie die unhandlichen Spezialeinträge in sie einfügen. Diese Einträge geben an, wo die von NIS abgeleiteten Datensätze in die Datenbank mit den Informationen eingefügt werden. Diese Einträge können an beliebiger Stelle eingetragen werden, üblicherweise werden sie aber ans Ende angehängt. Die für /etc/passwd notwendigen Einträge sind: +::::::

und für die /etc/groups-Datei: +:::

Sowohl bei glibc 2.x als auch bei NYS können Sie die Parameter in Benutzereinträgen, die vom NIS-Server empfangen wurden, überschreiben, indem Sie neue Einträge mit Login-Namen erzeugen, denen ein “+” vorangestellt ist. Demgegenüber führt ein vorangestelltes “-” zum Ausschluß dieser Benutzer. Im Beispiel +stuart::::::/bin/jacl -jedd::::::

würde die vom NIS-Server vorgegebene Login-Shell des Benutzers stuart mit der angegebenen Shell überschrieben werden. Außerdem würde verhindert werden, daß sich der Benutzer jedd in diese Maschine einloggen kann. Für die leeren Felder werden die vom NIS-Server gelieferten Informationen übernommen. Nun gibt es an dieser Stelle aber zwei große Vorbehalte. Zum einen funktioniert das bisher beschriebene Setup nur für Login-Verfahren, die keine Shadow-Paßwörter benutzen. Die Komplikationen bei der Verwendung von ShadowPaßwörtern mit NIS werden später noch behandelt. Zum anderen sind die Login-Befehle nicht die einzigen, die auf die passwd-Datei zugreifen — sehen Sie sich den ls-Befehl an, den die meisten Leute fast dauernd benutzen. Wenn Sie ein ausführliches Inhaltsverzeichnis anfordern, gibt ls die symbolischen Namen der Benutzer und Gruppenbesitzer einer Datei aus. Das bedeutet, daß für jede UID und GID, der ls begegnet, der NIS-Server einmal abgefragt werden muß. Eine NISAbfrage dauert immer etwas länger als das Durchsuchen einer lokalen Datei. Sie werden feststellen, daß die gemeinsame Benutzung Ihrer passwd- und group-Informationen über NIS den Durchsatz einiger Programme, die regelmäßig darauf zurückgreifen, deutlich verringert. Aber das ist noch nicht alles. Stellen Sie sich vor, was passiert, wenn eine Benutzerin ihr Paßwort ändern möchte. Normalerweise würde sie passwd aufrufen, das das neue Paßwort einliest und die lokale passwd-Datei aktualisiert. Das ist bei NIS unmöglich, weil die Datei lokal nicht mehr vorhanden ist. Daß sich Benutzer in den NIS-Server einloggen, wenn sie das Paßwort ändern wollen, ist auch keine Lösung. NIS stellt aus diesem Grund ein Programm namens yppasswd als Ersatz für passwd bereit, das dieselbe Aufgabe unter NIS übernimmt. Um das Paßwort auf dem Server-Host zu ändern, ruft es den yppasswdd-Dämon auf diesem Host über RPC auf und versorgt ihn mit der aktualisierten Paßwortinformation. Normalerweise ersetzen Sie das normale Programm durch yppasswd, beispielsweise durch die nachstehende Befehlsfolge: # cd /bin # mv passwd passwd.old # ln yppasswd passwd

Gleichzeitig müssen Sie rpc.yppasswdd auf dem Server installieren und ihn von einem Netzwerkskript aus starten. Auf diese Weise werden die gesamten Klimmzüge von NIS vor den Benutzern versteckt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NIS mit Shadow-Paßwörtern verwenden NIS in Verbindung mit Shadow-Paßwortdateien ist eine etwas problematische Angelegenheit. Die schlechte Nachricht zuerst: Die Anwendung von NIS widerspricht dem ursprünglichen Zweck von Shadow-Paßwörtern. Shadow-Paßwörter wurden eingeführt, um zu verhindern, daß normale Benutzer die Paßwörter anderer Anwender, selbst im verschlüsselten Zustand, lesen können. Andererseits zwingt NIS sie dazu, daß diese Paßwörter netzwerkweit verfügbar sind, wodurch jeder Benutzer, der die Antworten des NIS-Servers im Netzwerk abhören kann, Zugriff auf sie erhält. Die Verpflichtung der Benutzer, nur “gute” Paßwörter zu verwenden, ist eine erheblich sinnvollere Maßnahme als ein Versuch, Shadow-Paßwörter in einer NIS-Umgebung zu verwalten. Werfen wir mal einen kurzen Blick darauf, wie Sie so etwas anstellen, sofern Sie sich dafür entschieden haben, hier weiterzumachen. In libc5 gibt es keine wirkliche Lösung für das Problem, Shadow-Paßwörter mit NIS zu verwalten. Der einzige Weg, Paßwort- und Benutzerinformationen über NIS zu verteilen, sind die Standardpasswd.*-Maps. Wenn Sie Shadow-Paßwörter installiert haben, besteht die einfachste Möglichkeit der gemeinsamen Nutzung darin, eine ordentliche passwd-Datei aus /etc/shadow zu erzeugen (mit Tools wie pwuncov) und aus dieser Datei die entsprechenden NIS-Maps aufzubauen. Natürlich sind einige Hacks nötig, um NIS und Shadow-Paßwörter gleichzeitig zu verwenden, beispielsweise indem Sie eine /etc/shadow-Datei auf jedem Host im Netzwerk installieren, während

die Benutzerinformationen über NIS verteilt werden. Diese Vorgehensweise ist natürlich ziemlich grobschlächtig und läuft dem Ziel von NIS, die Systemadministration zu vereinfachen, völlig entgegen. NIS in der GNU libc-Bibliothek (libc6) unterstützt Shadow-Paßwörter. Es bietet zwar keine echte Lösung, um auf Ihre Paßwörter zuzugreifen, vereinfacht aber die Paßwortverwaltung in Umgebungen, in denen Sie NIS mit Shadow-Paßwörtern verwenden wollen. Zur Anwendung müssen Sie eine shadow.byname-Datei erzeugen und die folgende Zeile in Ihre /etc/nsswitch.conf einfügen: # Unterstützung von Shadow-Paßwörtern shadow:

compat

Wenn Sie Shadow-Paßwörter zusammen mit NIS benutzen, sollten Sie auf jeden Fall versuchen, die Systemsicherheit aufrechtzuerhalten, indem Sie den Zugriff auf Ihre NIS-Dateien einschränken. Dazu wird auf Sicherheit von NIS-Servern weiter vorn in diesem Kapitel verwiesen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 14 Das Network File System

NFS, das Network File System, ist wahrscheinlich der bekannteste auf RPC basierende Netzwerkdienst. Er ermöglicht es Ihnen, auf Dateien von entfernten Hosts genauso zuzugreifen, wie Sie es mit lokalen Dateien tun. Dies wird durch eine Mischung aus Kernel-Funktionalität und Dämonen auf Benutzerebene auf der Client-Seite und einem NFS-Server auf der Serverseite realisiert. Der Dateizugriff ist für den Client völlig transparent und funktioniert bei diversen Server- und

Hostarchitekturen. NFS bietet eine Reihe nützlicher Merkmale: ●

●

●

Daten, auf die von allen Benutzern zugegriffen wird, können auf einem zentralen Host gehalten werden. Clients mounten dieses Verzeichnis beim Systemstart. Beispielsweise können Sie alle Benutzerkonten auf einem Host speichern und alle Clienten in Ihrem Netzwerk /home von diesem Host mounten lassen. In Verbindung mit NIS können sich die Benutzer dann an jedem System einloggen und arbeiten dennoch mit nur einem Satz von Dateien. Daten, die sehr viel Plattenspeicher einnehmen, können auf einem einzigen Host gehalten werden. So könnten etwa alle zu LaTeX und METAFONT gehörenden Dateien und Programme an einem Ort gespeichert und verwaltet werden. Administrative Daten können auf einem einzelnen Host aufbewahrt werden. Es gibt keinen Grund mehr, rcp zu verwenden, um ein und dieselbe Datei auf 20 verschiedene Rechner zu kopieren.

Es ist nicht besonders schwer, die grundlegenden NFS-Funktionen für den Client und den Server einzurichten. Dieses Kapitel beschreibt, wie es geht. Linux-NFS ist größtenteils die Arbeit von Rick Sladkey, der den NFS-Kernel und große Teile des NFS-Servers geschrieben hat.1 Letzterer wurde vom unfsd-NFS-Server, ursprünglich entwickelt von Mark Shand, und vom hnfs-Harris-NFS-Server, geschrieben von Donald Becker, abgeleitet. Sehen wir uns nun an, wie NFS arbeitet. Als erstes versucht ein Client, ein Verzeichnis von einem entfernten Host an ein lokales Verzeichnis zu mounten, genau wie er dies mit einem physischen Gerät machen würde. Allerdings ist die für ein entferntes Verzeichnis zu verwendende Syntax anders. Soll zum Beispiel das Verzeichnis /home vom Host vlager an /users auf vale gemountet werden, führt der Administrator auf vale den folgenden Befehl ein:2 # mount -t nfs vlager:/home /users

mount versucht, über RPC eine Verbindung mit dem Mount-Dämon (rpc.mountd) auf vlager herzustellen. Der Server überprüft, ob vale die Erlaubnis besitzt, das fragliche Verzeichnis zu mounten; wenn ja, liefert er ein Dateihandle zurück. Dieses Handle bzw. dieser Verweis wird bei allen weiteren Anfragen nach Dateien unter /users verwendet. Greift jemand über NFS auf eine Datei zu, setzt der Kernel einen RPC-Aufruf an rpc.nfsd (den NFSDämon) auf der Servermaschine ab. Dieser Aufruf enthält das Dateihandle, den Namen der gewünschten Datei und die Benutzer- und Gruppen-ID als Parameter. Diese werden verwendet, um die Zugriffsrechte auf die angegebene Datei zu ermitteln. Um das Lesen und Modifizieren von Dateien durch nichtautorisierte Benutzer zu verhindern, müssen die Benutzer- und Gruppen-IDs auf beiden Hosts identisch sein.

Bei den meisten UNIX-Implementierungen wird die NFS-Funktionalität sowohl für Clients als auch für Server durch Dämonen realisiert, die auf Kernel-Ebene angesiedelt sind und während der BootPhase vom Benutzerbereich aus gestartet werden. Dies ist auf dem Server-Host der NFS-Dämon (rpc.nfsd) und auf dem Client-Host der Block I/O Dämon (biod). Um den Durchsatz zu verbessern, arbeitet biod mit asynchroner Ein-/Ausgabe unter Gebrauch von Read-Ahead und Write-Behind. Häufig werden auch mehrere rpc.nfsd-Dämonen gleichzeitig verwendet. Die aktuelle NFS-Implementierung von Linux unterscheidet sich etwas vom klassischen NFS, da der Servercode vollständig im Benutzerbereich läuft. Die gleichzeitige Ausführung mehrerer Kopien gestaltet sich daher etwas problematisch. Die aktuelle rpc.nfsd-Implementierung bietet ein experimentelles Feature, das zumindest einen begrenzten gleichzeitigen Betrieb mehrerer Server ermöglicht. Olaf Kirch entwickelte eine Kernel-basierte NFS-Server-Unterstützung, die in den 2.2er Kernel-Versionen enthalten ist. Der Durchsatz ist erheblich besser als bei den vorhandenen Implementierungen auf Benutzerebene. Darauf gehen wir in diesem Kapitel noch näher ein.

1.

Rick ist unter [email protected] zu erreichen.

2.

Sie können das Argument –t nfs auch weglassen, weil mount anhand des Doppelpunkts erkennt, daß ein NFS-Volume gemeint ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NFS vorbereiten Bevor Sie NFS benutzen können, sei es nun als Client oder als Server, müssen Sie zuerst sicherstellen, daß die entsprechende NFS-Unterstützung in den Kernel integriert (kompiliert) ist. Neuere Kernel haben dazu ein einfaches Interface im Dateisystem proc, nämlich die Datei /proc/filesystems, die Sie einfach mit cat ausgeben können: $ cat /proc/filesystems

minix

ext2

msdos nodev

proc nodev

nfs

Fehlt nfs in dieser Liste, müssen Sie den Kernel neu kompilieren und dabei NFS mit einbinden oder das NFSKernel-Modul laden, wenn Sie NFS als Modulversion konfiguriert haben. Die Konfiguration der Netzwerkoptionen des Kernels wird im Abschnitt “Kernel-Konfiguration” in Kapitel 3 Konfiguration der Netzwerkhardware, beschrieben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NFS-Volume mounten NFS-Volumes werden fast genauso gemountet wie die normalen Dateisysteme auch. Sie verwenden dabei für mount die folgende Syntax: 1 # mount -t nfs nfs_volume local_dir options

nfs_volume wird dabei als remote_host:remote_dir angegeben. Weil diese Notation nur bei NFS-Dateisystemen gilt, können Sie die Option –t nfs weglassen. Eine ganze Reihe zusätzlicher Optionen kann beim Mounten eines NFS-Volumes angegeben werden. Diese können entweder auf die Option –o in der Kommandozeile folgen oder im Optionsfeld von /etc/fstab für dieses Volume stehen. In beiden Fällen werden mehrere Optionen durch Kommata (ohne Leerzeichen!) voneinander getrennt. Auf der Kommandozeile angegebene Optionen überschreiben immer die in fstab stehenden Werte. Nachfolgend ein Beispieleintrag aus /etc/fstab: # Volume timeo=14,intr

Mount-Punkt

Typ

Optionen news:/var/spool/news

/var/spool/news

nfs

Dieses Volume kann mit dem folgenden Befehl gemountet werden: # mount news:/var/spool/news

Fehlt ein solcher fstab-Eintrag, sehen NFS-mounts wesentlich unangenehmer aus. Nehmen wir zum Beispiel an, daß Sie die Home-Verzeichnisse der Benutzer von einer Maschine namens moonshot aus mounten, die eine Standard-Blockgröße von 4 K für Schreib-/Leseoperationen verwendet. Um die Blockgröße auf 8 K zu erweitern und damit eine höhere Performanz zu erreichen, benutzen Sie den folgenden Befehl: # mount moonshot:/home /home -o rsize=8192,wsize=8192

Eine vollständige Liste aller gültigen Optionen ist in der Manpage nfs(5) beschrieben. Nachfolgend ein Teil der Optionen, die Sie möglicherweise verwenden möchten:

rsize=n und wsize=n Bestimmt die bei Schreib- bzw. Leseanforderungen von NFS-Clients verwendete Datagrammgröße. Die Standardgröße hängt von der verwendeten Kernel-Version ab, ist aber normalerweise auf 1.024 Byte voreingestellt. timeo=n Bestimmt die Zeit (in Zehntelsekunden), die ein NFS-Client auf den Abschluß einer Anforderung wartet. Der voreingestellte Wert ist 7 (0,7 Sekunden). Was nach einem Timeout passiert, hängt davon ab, ob Sie die Option hard oder soft verwenden. hard Markiert dieses Volume explizit als “hart” gemountet (das ist die Voreinstellung). Mit dieser Option gibt der Server bei einem längeren Timeout eine Fehlermeldung auf die Konsole aus und setzt die Verbindungsversuche endlos fort. soft “Weiches” Mounten des Verzeichnisses (im Gegensatz zu hartem Mounten). Diese Option führt bei einem längeren Timeout zu einer Ein-/Ausgabe-Fehlermeldung an den Prozeß, der eine Dateioperation durchzuführen versucht. intr Ermöglicht die Unterbrechung von NFS-Aufrufen über Signale. Nützlich, wenn ein Server nicht antwortet und der Client abgebrochen werden muß. Mit Ausnahme von rsize und wsize wirken sich all diese Optionen auf das Verhalten des Client aus, wenn der Server kurzfristig nicht erreichbar sein sollte. Sie spielen auf folgende Weise zusammen: Sendet der Client eine Anforderung an den NFS-Server, erwartet er, daß die Operation innerhalb einer bestimmten Zeit abgeschlossen ist. Diese Zeit kann mit der Option timeout festgelegt werden. Wird innerhalb dieser Zeit keine Bestätigung empfangen, kommt es zu einem sogenannten MinorTimeout (leichter Timeout). Die Operation wird nun wiederholt, wobei das Timeout-Intervall verdoppelt wird. Wird der maximale Timeout von 60 Sekunden erreicht, tritt ein Major-Timeout (schwerer Timeout) auf. Per Voreinstellung gibt ein Client bei einem großen Timeout eine Fehlermeldung auf der Konsole aus und versucht es erneut. Dabei wird das ursprüngliche Timeout-Intervall verdoppelt. Theoretisch könnte dies immer so weitergehen. Volumes, die eine Operation immer wieder hartnäckig wiederholen, bis der Server wieder verfügbar ist, werden als hart gemountet (hardmounted) bezeichnet. Die andere Variante wird weich gemountet (soft-mounted) genannt und generiert einen I/O-Fehler für den rufenden Prozeß, wenn ein großer Timeout auftritt. Da der Buffer-Cache für verzögertes Schreiben sorgt, gelangt diese Fehlerbedingung nicht an den Prozeß selbst, bevor dieser das nächste Mal die Funktion write aufruft. Ein Programm kann daher nie sicher sein, daß eine Schreiboperation an ein weich gemountetes Volume überhaupt erfolgreich war. Ob Sie ein Volume hart oder weich mounten, hängt teilweise von Ihren persönlichen Vorlieben ab, andererseits aber auch von der Art der Informationen, auf die Sie über dieses Volume zugreifen wollen. Wenn Sie etwa Ihre X-Programme über NFS mounten, wollen Sie wahrscheinlich nicht, daß Ihre X-Session verrückt spielt, nur weil jemand das Netzwerk zum Erliegen gebracht hat, indem er sieben Instanzen von Doom gleichzeitig benutzt oder weil er kurz den Ethernet-Stecker gezogen hat. Wenn Sie die Verzeichnisse mit den Programmen hart mounten, stellen Sie sicher, daß der Computer so lange wartet, bis er die Verbindung zum NFS-Server wiederherstellen kann.Auf der anderen Seite brauchen unkritische Daten wie NFSgemountete News-Partitionen oder FTP-Archive nicht hart gemountet zu sein. Ist die entfernte Maschine zeitweise nicht erreichbar oder heruntergefahren, hängt sich Ihre Session nicht auf. Ist Ihre Netzwerkverbindung etwas instabil, oder läuft sie über einen überlasteten Router, können Sie den anfänglichen Timeout mit Hilfe der Option timeo erhöhen oder die Volumes hart mounten. NFS-Volumes werden standardmäßig hart gemountet. Harte Mounts sind jedoch nicht unproblematisch, da die Dateioperationen normalerweise nicht unterbrochen werden können. Wenn ein Prozeß zum Beispiel versucht, auf einen Remote-Server zu schreiben, und dieser Server unerreichbar ist, bleibt die Benutzerapplikation einfach stehen und wartet so lange, bis der Server wieder antwortet. Der Benutzer hat währenddessen aber keine Möglichkeit, die Operation vorzeitig abzubrechen. Wenn Sie aber beim harten Mounten die Option intr benutzen, bricht

jedes Signal, das der Prozeß empfängt, die NFS-Operation ab, so daß der Benutzer hängende Dateizugriffe über NFS unterbrechen und normal weiterarbeiten kann, natürlich ohne die Datei zu sichern. Der rpc.mountd-Dämon hält normalerweise auf die eine oder andere Art fest, welche Verzeichnisse von welchen Hosts gemountet wurden. Diese Information kann mit dem Programm showmount ausgegeben werden, das ebenfalls Teil des NFSServerpakets ist. # showmount -e moonshot Export list for localhost: /home # showmount -d moonshot Directories on localhost: /home # showmount -a moonshot All mount points on localhost: localhost:/home

1.

Man sagt Volume und nicht Dateisystem, weil es kein richtiges Dateisystem ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die NFS-Dämonen Wenn Sie anderen Hosts NFS-Dienste anbieten wollen, müssen die rpc.nfsd- und rpc.mountd-Dämonen auf Ihrer Maschine laufen. Als RPC-basierte Programme werden sie nicht von inetd verwaltet, sondern werden während der BootPhase gestartet und registrieren sich selbst beim Portmapper. Daher müssen Sie sicherstellen, daß die Programme erst gestartet werden, wenn rpc.portmap schon läuft. Normalerweise tragen Sie dazu in einem Ihrer Startskripten folgende Anweisungen ein: if [ -x /usr/sbin/rpc.mountd ]; then /usr/sbin/rpc.mountd; echo -n " mountd" fi if [ -x /usr/sbin/rpc.nfsd ]; then /usr/sbin/rpc.nfsd; echo -n " nfsd" fi

Die Besitzinformationen über Dateien, die ein NFS-Dämon an seine Clients liefert, bestehen üblicherweise nur aus den numerischen Benutzer- und Gruppen-IDs. Wenn der Client und der Server dieselben Benutzer- und Gruppennamen mit diesen numerischen IDs verbinden, spricht man von einem gemeinsamen UID/GID-Raum. Dies ist beispielsweise der Fall, wenn Sie NIS einsetzen, um die passwd-Informationen an alle Hosts in Ihrem LAN weiterzugeben. In manchen Fällen stimmen die IDs verschiedener Hosts aber nicht überein. Statt nun die UIDs und GIDs der Clients mit denen auf dem Server abzugleichen, können Sie auf dem Client den rpc.ugidd-Dämon einsetzen, um dieses Problem zu umgehen. Mit der nachfolgend erläuterten Option map_daemon können Sie rpc.nfsd anweisen, mit Hilfe von rpc.ugidd den UID/GID-Raum des Servers auf den UID/GID-Raum des Client abzubilden. Leider wird der rpc.ugidd-Dämon nicht in allen modernen Linux-Distributionen mitgeliefert, so daß Sie den Quellcode des Dämons bei Bedarf selbst kompilieren müssen. rpc.ugidd ist ein RPC-basierter Server, der ebenso wie rpc.nfsd und rpc.mountd aus einem Boot-Skript heraus gestartet wird. if [ -x /usr/sbin/rpc.ugidd ]; then

/usr/sbin/rpc.ugidd; echo -n " ugidd" fi

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die exports-Datei Nun beschäftigen wir uns mit der Konfiguration des NFS-Servers. Wir untersuchen, wie wir dem NFS-Server mitteilen, welche Dateisysteme er zum Mounten freigeben soll, und werfen einen Blick auf die diversen Parameter, die die Zugriffsrechte der Clients auf die Dateisysteme regeln. Der Server bestimmt die Zugriffsmöglichkeiten, über die auf die Dateien auf dem Server zugegriffen werden kann. Die Datei /etc/exports enthält eine Liste der Dateisysteme, die der Server den Clients zum Mounten und Anwenden zur Verfügung stellt. Per Voreinstellung erlaubt rpc.mountd niemandem, Verzeichnisse des lokalen Hosts über NFS zu mounten, was eine sehr vernünftige Einstellung ist. Um einem oder mehreren Hosts den NFS-Zugriff auf ein Verzeichnis zu erlauben, müssen Sie es exportieren, d.h. in der Datei exports eintragen. Eine Beispieldatei könnte so aussehen: # Export-Datei für vlager /home vale(ro) vstout(ro) vlight(ro) /usr/TeX vale(rw,no_root_squash) /home/ftp

vale(rw) vstout(rw) vlight(rw) /usr/X11R6 vale(ro) vstout(ro) vlight(ro) / (ro)

Jede Zeile definiert ein Verzeichnis und die Hosts, die es mounten dürfen. Ein Hostname ist üblicherweise ein voll qualifizierter Domainname, kann zusätzlich aber auch die Platzhalter * und ? enthalten, die auf dieselbe Weise funktionieren wie bei der Bourne-Shell. Beispielsweise wird bei lab*.foo.com sowohl lab01.foo.com als auch laber.foo.com akzeptiert. Der Host kann auch in Form eines IP-Adreßbereichs Adresse/Netzmaske angegeben werden. Wird wie im obigen Beispiel beim /home/ftp-Verzeichnis kein Hostname angegeben, darf jeder Host dieses Verzeichnis mounten. Bei der Prüfung eines Client-Host gegen die exports-Datei ermittelt rpc.mountd den Hostnamen des Client mit Hilfe eines gethostbyaddr-Aufrufs. Unter DNS liefert dieser Aufruf den kanonischen Hostnamen des Client zurück, d.h., Sie dürfen keine Aliases in exports verwenden. In einer NIS-Umgebung wird der erste passende Hostname aus der Hostdatenbank zurückgeliefert. In Umgebungen ohne DNS und NIS wird dagegen der erste Hostname aus der Datei hosts zurückgeliefert, bei dem die Adresse des Client übereinstimmt. Dem Hostnamen kann eine Liste mit durch Kommata getrennten Optionen folgen, die in Klammern eingeschlossen sind. Diese Optionen können unter anderem die folgenden Werte annehmen:

secure Diese Option bestimmt, daß Anforderungen von einem reservierten Internet-Port stammen müssen, d.h., die Portnummer muß kleiner als 1.024 sein. Diese Option ist per Voreinstellung aktiviert. insecure Diese Option kehrt die Wirkung der secure-Option um. ro Diese Option bewirkt, daß NFS-Mounts schreibgeschützt erfolgen, und ist per Voreinstellung aktiviert. rw Diese Option mountet Dateihierarchien mit Lese- und Schreibrechten. root_squash Dieses Sicherheits-Feature verweigert den Administratoren der angegebenen Hosts jegliche Sonderrechte, indem Anforderungen von UID 0 des Client auf UID 65534 (d.h. -2) auf dem Server abgebildet werden. Diese UID sollte dem Benutzer nobody zugeordnet sein. no_root_squash Bildet Anforderungen von UID 0 nicht ab. Diese Option ist per Voreinstellung aktiviert, so daß Administratoren für alle exportierten Verzeichnisse Ihres Systems Root-Rechte haben. link_relative Diese Option wandelt absolute symbolische Links (die mit einem Slash beginnen) in relative Links um. Diese Option macht nur Sinn, wenn das gesamte Dateisystem des Host gemountet ist. Andernfalls könnten einige Links ins Nirgendwo zeigen oder, noch schlimmer, auf Dateien, auf die niemals verwiesen werden sollte. Diese Option ist per Voreinstellung aktiviert. link_absolute Diese Option läßt alle symbolischen Links unverändert (das normale Verhalten bei von Sun abgeleiteten NFSServern). map_identity Diese Option weist den Server an, gleiche UIDs und GIDs für Clients und Server zu erwarten. Diese Option ist per Voreinstellung aktiv. map_daemon Diese Option weist den NFS-Server an, nicht denselben UID/GID-Raum für Clients und Server zu erwarten. rpc.nfsd baut dann eine Liste auf, die IDs zwischen Client und Server durch Abfrage des Client-Dämons rpc.ugidd abbildet. map_static Mit dieser Option können Sie eine Datei angeben, die eine statische Zuordnung von UIDs und GIDs enthält. Beispielsweise spezifiziert map_static=/etc/nfs/vlight.map die Datei /etc/nfs/vlight.map für die

UID/GID-Zuordnung. Die Syntax der Zuordnung ist in der Manpage exports(5) beschrieben. map_nis Diese Option bewirkt, daß der NIS-Server die UID- und GID-Zuordnung übernimmt. anonuid und anongid Diese Optionen legen die UID und GID des anonymen Accounts fest. Das ist nützlich, wenn Sie ein Volume für öffentliche Mounts exportiert haben. Fehler beim Lesen der exports-Datei werden an die daemon-Einrichtung von syslogd auf der Ebene notice weitergegeben, wenn rpc.nfsd oder rpc.mountd hochfährt. Beachten Sie, daß Hostnamen aus den IP-Adressen der Clients durch “Reverse Mapping” ermittelt werden, d.h., der Resolver muß korrekt konfiguriert sein. Wenn Sie mit BIND arbeiten und sehr sicherheitsbewußt sind, sollten Sie den SpoofSchutz in Ihrer host.conf aktivieren. Auf diese Thematik gehen wir in Kapitel 6 Name-Server- und Resolver-Konfiguration, ein.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kernel-basierte Unterstützung von NFSv2-Servern Der im Benutzerbereich arbeitende NFS-Server in Linux funktioniert zwar zuverlässig, wird aber unter voller Auslastung ziemlich langsam. Die Ursache dafür liegt hauptsächlich im Verwaltungsaufwand, der für die Systemaufrufe nötig ist, aber auch daran, daß der Server sich die Rechenleistung mit anderen, potentiell weniger wichtigen Benutzerprozessen teilen muß. Der Kernel 2.2.0 unterstützt einen experimentellen Kernel-basierten NFS-Server, der von Olaf Kirch entworfen und von H.J. Lu, G. Allan Morris und Trond Myklebust weiterentwickelt wurde. Die Kernel-basierte NFS-Unterstützung bietet einen deutlich verbesserten Server-Durchsatz. In den aktuellen Distributionen finden Sie die Server-Tools meistens bereits in binärer Form vor. Falls nicht, finden Sie sie in http://csua.berkeley.edu/~gam3/knfsd/. Um die Tools anwenden zu können, benötigen Sie einen 2.2.0-Kernel mit Kernel-basiertem NFS-Dämon. Ob Ihr Kernel den NFS-Dämon bereits enthält, können Sie daran sehen, ob die Datei /proc/sys/sunrpc/nfsd_debug in Ihrem System existiert. Ist das nicht der Fall, müßten Sie das rpc.nfsd-Modul mit dem Befehl modprobe laden. Der Kernel-basierte NFS-Dämon verwendet eine gewöhnliche /etc/exports-Konfigurationsdatei. Das Programmpaket enthält Ersatzversionen von rpc.mountd und rpc.nfsd, die Sie auf fast die gleiche Weise starten wie die Versionen für die Benutzerebene.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kernel-basierte Unterstützung von NFSv3-Servern Das bisher am häufigsten verwendete NFS ist NFS Version 2. Der Fortschritt ist nicht aufzuhalten, und so wurden mit der Zeit Schwachstellen offenbar, die nur durch eine Revision des Protokolls behoben werden konnten. Version 3 des Network File Systems unterstützt größere Dateien und Dateisysteme, enthält deutlich verbesserte Sicherheitsmerkmale und zeichnet sich schließlich durch eine Reihe von Performanzverbesserungen aus. Für die meisten Anwender werden diese Neuerungen nur von Vorteil sein. Olaf Kirch und Trond Myklebust entwickeln inzwischen einen experimentellen NFSv3-Server, der auf dem Kernel-basierten NFS-Dämon der Version 2 aufbaut. Er ist in den Entwickler-Kerneln der Version 2.3 enthalten, kann mit einem Patch aber auch in die 2.2er Kernel integriert werden. Diese Patches können von der Homepage für Kernel-basierte NFS-Server in Linux unter http://csua.berkeley.edu/~gam3/knfsd/ bezogen werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 15 IPX und das NCPDateisystem

Lange bevor Microsoft sich erstmals mit Netzwerken beschäftigte, sogar bevor das Internet außerhalb akademischer Zirkel überhaupt bekannt war, waren große Unternehmen bereits in der Lage, gemeinsame Dateien und Drucker zu benutzen. Sie verwendeten dafür Datei- und Druckerserver, die mit dem Betriebssystem Novell NetWare und den zugehörigen Protokollen arbeiteten.1 Viele Anwender dieser Unternehmen haben immer noch alte Netzwerke, die mit diesen Protokollen arbeiten, und würden gerne diesen Support in ihre neue TCP/IP-Unterstützung integrieren. Linux unterstützt nicht nur die TCP/IP-Protokolle, sondern auch die von Novells NetWareBetriebssystem verwendeten Protokolle. Bei diesen Protokollen handelt es sich um entfernte

Verwandte von TCP/IP. Zwar bieten sie eine ähnliche Funktionalität, unterscheiden sich jedoch in einigen Punkten und sind leider inkompatibel. Für Linux gibt es sowohl freie als auch kommerzielle Softwareangebote, die die Integration von Novell-Produkten unterstützen. In diesem Kapitel gehen wir kurz auf die Protokolle selbst ein, konzentrieren uns aber im wesentlichen darauf, wie man die freie Software konfiguriert und anwendet, um die Interoperabilität von Linux mit Novell-Produkten zu ermöglichen.

1.

Novell und NetWare sind Warenzeichen der Novell Corporation.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Geschichte von Xerox und Novell Zuerst fragen wir uns, wie die Protokolle überhaupt entstanden und wie sie gestaltet sind. In den späten 70er Jahren entwickelte und veröffentlichte die Firma Xerox einen offenen Standard, der unter dem Namen Xerox Network Specification (XNS) bekannt wurde. XNS beschreibt eine Reihe von Protokollen für allgemeine Netzwerkanwendungen, mit Schwerpunkt lokale Netzwerke. Dafür wurden zwei primäre Netzwerkprotokolle eingeführt: das Internet Datagram Protocol (IDP) zur verbindungslosen, unzuverlässigen Übertragung von Datagrammen zwischen verschiedenen Hosts sowie das Sequenced Packet Protocol (SPP), bei dem es sich um eine modifizierte Form von IDP handelte, die verbindungsbasiert und zuverlässig war. Die Datagramme eines XNS-Netzwerks wurden individuell adressiert. Das Adressenschema verwendete eine Kombination aus einer 4-Byte-IDPNetzwerkadresse (die einheitlich jedem Segment des Ethernet-LANs zugewiesen wurde) und einer 6Byte-Knotenadresse (die Adresse der NIC-Karte). Router waren Geräte, die Datagramme zwischen einem oder mehreren separaten IDP-Netzwerken verteilten. Subnetzwerke waren bei IDP unbekannt; jede neue Ansammlung von Hosts erforderte daher die Vergabe einer neuen Netzwerkadresse. Diese Adressen wurden so gewählt, daß sie im betreffenden Netzwerk einheitlich waren.In manchen Fällen entwickeln Administratoren besondere Vereinbarungen, daß jedes Byte eine andere Information codiert, wie z.B. geographische Daten, so daß die Netzwerkadressen auf systematische Weise vergeben werden. Das Protokoll selbst ist auf solche Zusatzinformationen natürlich nicht angewiesen. Die Firma Novell entschloß sich, ihre eigenen Netzwerkapplikationen auf XNS aufzubauen. Novell

führte kleine Verbesserungen an IDP und SPP durch und nannte sie IPX (Internet Packet eXchange) und SPX (Sequenced Packet eXchange). Außerdem führte Novell neue Protokolle ein, wie beispielsweise das NetWare Core Protocol (NCP), mit dem Zugriffe auf gemeinsame Dateien und Drucker mittels IPX möglich wurden, sowie das Service Advertisement Protocol (SAP), das die Hosts in einem Novell-Netzwerk darüber in Kenntnis setzte, welche Hosts welche Dienste bereitstellten. Tabelle 15.1 stellt die funktionalen Beziehungen zwischen XNS, Novell und TCP/IP dar. Das geschieht zwar nur näherungsweise, sollte Ihnen aber dennoch ein grundlegendes Verständnis vermitteln, so daß Sie wissen, was gemeint ist, wenn wir später auf diese Protokolle zurückgreifen. Tabelle 15.1: Beziehungen zwischen den Protokollen XNS, Novell und TCP/IP XNS Novell TCP/IP Eigenschaften IDP IPX

UDP/IP Verbindungsloser, unzuverlässiger Transport

SPP SPX

TCP

Verbindungsbasierter, zuverlässiger Transport

NCP

NFS

Dateidienste

RIP

RIP

Austausch von Routing-Informationen

SAP

Austausch von Informationen über verfügbare Dienste

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IPX und Linux Als erster entwickelte Alan Cox im Jahr 1985 IPX-Unterstützung für den Linux-Kernel.1 Am Anfang konnte man damit nicht viel mehr als IPX-Datagramme routen. Danach stellten andere Entwickler, besonders Greg Page, zusätzlichen Support bereit.2 Greg entwickelte die IPX-Utilities, die wir auch in diesem Kapitel zur Konfiguration unserer Schnittstellen benutzen. Volker Lendecke steuerte die Unterstützung für das NCP-Dateisystem bei, wodurch Linux nun in der Lage ist, übers Netz Volumes auf NetWare-Servern zu mounten.3 Er erzeugte auch Tools zum Drucken von und zu Linux-Rechnern. Ales Dryak und Martin Stover entwickelten unabhängig voneinander NCP-Dateiserver-Dämonen für Linux, mit denen NetWare-Clients übers Netz Linux-Verzeichnisse mounten können, die als NCPVolumes exportiert sind, genauso wie der NFS-Dämon es Linux ermöglicht, Dateisysteme über NFS an Clients freizugeben.4 Die Firma Caldera Systems bietet einen kommerziellen, voll lizensierten NetWare-Client und -Server an, der die neuesten Novell-Standards unterstützt, wozu auch der NetWare Directory Service (NDS) gehört.5 Heutzutage unterstützt Linux ein großes Spektrum an Netzwerkdiensten, mit deren Hilfe Systeme in Novell-basierte Netzwerke integriert werden können.

Support von Caldera Obwohl wir in diesem Kapitel nicht auf die Details des NetWare-Supports von Caldera eingehen, ist es

doch wichtig, einmal darüber zu sprechen. Caldera wurde von Ray Noorda, dem früheren CEO von Novell, gegründet. Beim NetWare-Support von Caldera handelt es sich um ein kommerzielles Produkt, für das Caldera uneingeschränkten Support bietet. Es ist Bestandteil der firmeneigenen LinuxDistribution namens Caldera OpenLinux. Die Caldera-Lösung ist der ideale Weg, wenn es darum geht, Linux in Umgebungen einzuführen, die sowohl nach kommerziellem Support als auch nach einer Möglichkeit verlangen, Linux in vorhandene oder neue Novell-Netzwerke zu integrieren. Der Caldera NetWare-Support wird vollständig von Novell lizensiert und bietet daher ein hohes Maß an Sicherheit, daß die Produkte beider Firmen interoperabel bleiben. Die einzigen Ausnahmen bilden “reine” IP-Operationen für den Client und den NDS-Server, obwohl beide noch gar nicht verfügbar waren, als dieses Buch geschrieben wurde. NetWare-Client und NetWare-Server sind bereits erhältlich. Außerdem gibt es bereits eine Ansammlung von Tools, mit denen nicht nur die Verwaltung Ihrer Linux-basierten NetWare-Maschinen, sondern auch die Ihrer Novell NetWare-Maschinen einfacher gestaltet werden kann — die Mächtigkeit der Unix-Skriptsprachen macht's möglich. Mehr Informationen über Caldera finden Sie auf Calderas Homepage.

Mehr über NDS-Support Mit der Version 4 von NetWare führte Novell ein Feature namens NetWare Directory Service (NDS) ein. Die Spezifikationen zu NDS sind nur erhältlich, wenn man eine Nichtveröffentlichungserklärung (Nondisclosure Agreement) unterzeichnet. Das ist eine Einschränkung, die die Entwicklung eines freien Supports behindert. Erst Version 2.2.0 und folgende des ncpfs-Pakets, das wir später noch behandeln werden, bietet Unterstützung für NDS. Das wurde mittels Reverse Engineering des NDSProtokolls erreicht. Das Paket scheint zwar zu funktionieren, wird aber offiziell immer noch als experimentell angesehen. Sie können die Nicht-NDS-Tools mit NetWare 4-Servern benutzen, vorausgesetzt, sie haben “bindery emulation mode” aktiviert. Die Caldera-Software bietet volle Unterstützung für NDS, da ihre Implementierung von Novell lizensiert wurde. Diese Implementierung ist jedoch nicht frei. Sie haben daher keinen Zugriff auf den Quellcode und auch nicht die Möglichkeit, die Software frei zu kopieren und weiterzuverteilen.

1.

Alan ist erreichbar unter [email protected].

2.

Greg ist erreichbar unter [email protected].

3.

Volker ist erreichbar unter [email protected].

4.

Ales ist erreichbar unter [email protected]. Martin ist unter [email protected] zu erreichen.

5.

Informationen über Caldera finden Sie unter http://www.caldera.com/.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration des Kernels für IPX und NCPFS Die Konfiguration des Kernels für IPX und NCP-Dateisysteme besteht eigentlich nur darin, die entsprechenden Optionen für die Kernel-Kompilierung auszuwählen. Wie bei vielen anderen Teilen des Kernels können auch die IPX- und NCPFS-KernelKomponenten entweder in den Kernel integriert oder als Module kompiliert werden. Die Module werden dann bei Bedarf mit dem Befehl insmod geladen. Damit Linux das IPX-Protokoll routen kann, müssen folgende Optionen gesetzt sein: General setup ---> Network device support Gerätetreiber

[*] Networking support Networking options ---> [*] Ethernet (10 or 100Mbit)

---> <*> The IPX protocol ... und geeignete Ethernet-

Wollen Sie Ihr Linux-System auch fit für NCP-Dateisysteme machen, um NetWare-Volumes übers Netz mounten zu können, benötigen Sie außerdem folgende Optionen: Filesystems volumes)

--->

[*] /proc filesystem support

<*> NCP filesystem support (to mount NetWare

Wenn Sie Ihren neuen Kernel kompiliert und installiert haben, steht dem IPX-Betrieb nichts mehr im Wege.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IPX-Schnittstellen konfigurieren Wie bei TCP/IP müssen Sie auch Ihre IPX-Schnittstellen erst konfigurieren, bevor Sie sie benutzen können. Das IPX-Protokoll stellt einige einzigartige Anforderungen, weshalb dafür extra ein spezieller Satz von Konfigurations-Tools entwickelt wurde. Diese Tools verwenden wir, um unsere IPXSchnittstellen und -Routen zu konfigurieren.

Netzwerkgeräte mit IPX-Unterstützung Das IPX-Protokoll geht grundsätzlich von der Annahme aus, daß alle Hosts, die Datagramme ohne Routing an andere Hosts senden können, zu ein und demselben IPX-Netzwerk gehören. Alle Hosts, die einem einzelnen Ethernet-Segment angehören, gehören somit zum selben IPX-Netzwerk. Auf ähnliche Weise (wenn auch weniger intuitiv) müssen zwei Hosts, die eine PPP-basierte serielle Verbindung unterstützen, zu dem IPX-Netzwerk gehören, das die serielle Verbindung selbst ist.In einer EthernetUmgebung gibt es eine Menge verschiedener Frame-Typen, die zur Übertragung von IPXDatagrammen verwendet werden können. Die Frame-Typen repräsentieren verschiedene EthernetProtokolle und beschreiben unterschiedliche Arten, multiple Protokolle im selben Ethernet-Netzwerk zu übertragen. Die häufigsten Frame-Typen, denen Sie begegnen werden, sind 802.2 und ethernet_II. Über Frame-Typen sprechen wir im nächsten Abschnitt. Die Linux-Netzwerkgeräte, die zur Zeit das IPX-Protokoll unterstützen, sind die Ethernet- und PPP-

Treiber. Die Ethernet- oder PPP-Schnittstelle muß immer aktiv sein, bevor sie für IPX-Anwendungen konfiguriert werden kann. Normalerweise werden Sie ein Ethernet-Gerät für beide Protokolle, also IP und IPX, konfigurieren, so daß das Gerät im System bereits bekannt ist. Wenn Ihr Netzwerk allerdings nur IPX benutzt, müssen Sie den Zustand des Ethernet-Geräts explizit mit ifconfig ändern: # ifconfig eth0 up

Konfigurations-Tools für IPX-Schnittstellen Greg Page entwickelte eine Reihe von Konfigurations-Tools für IPX-Schnittstellen. Sie sind in modernen Distributionen in vorkompilierter Form enthalten, aber auch als Quellcode in der Datei /pub/Linux/system/filesystems/ncpfs/ipx.tgz mittels anonymous FTP von http://metalab.unc.edu/ erhältlich. Die IPX-Tools werden für gewöhnlich beim Systemstart aus einem rc-Skript heraus gestartet. Wenn Sie die vorgefertigte Version installiert haben, erledigt das Ihre Distribution unter Umständen sogar automatisch.

Der Befehl ipx_configure Jede IPX-Schnittstelle muß darüber informiert sein, zu welchem IPX-Netzwerk sie gehört und welchen Frame-Typ sie für IPX benutzen soll. Jeder Host mit IPX-Unterstützung besitzt mindestens eine Schnittstelle, die der Rest des Netzwerks zum Zugriff benutzt. Sie wird als primäre Schnittstelle bezeichnet. Der IPX-Support des Linux- -Kernels bietet ein Feature, mit dem diese Parameter automatisch konfiguriert werden können. Es läßt sich mit dem Befehl ipx_configure ein- oder ausschalten. Sind keine Argumente angegeben, gibt ipx_configure die aktuellen Einstellungen zur automatischen Konfiguration aus: # ipx_configure Auto Primary Select is OFF Auto Interface Create is OFF

Sowohl die Auto-Primary-Option als auch die Auto-Interface-Option sind standardmäßig abgeschaltet. Um sie und die automatische Konfiguration zu aktivieren, geben Sie einfach folgende Argumente an: # ipx_configure --auto_interface=on --auto_primary=on

Ist das Argument --auto_primary auf on gesetzt, stellt der Kernel automatisch sicher, daß mindestens eine aktive Schnittstelle als primäres Interface für den Host zum Einsatz kommt. Wenn das Argument --auto_interface auf on gesetzt ist, analysiert der IPX-Treiber im Kernel alle empfangenen Frames in den aktiven Netzwerkschnittstellen und versucht, daraus die IPXNetzwerkadresse und den verwendeten Frame-Typ zu ermitteln. Die automatische Erkennung funktioniert gut in korrekt verwalteten Netzwerken.

Netzwerkadministratoren neigen jedoch manchmal zu Abkürzungen und Regelverletzungen, was der automatischen Erkennung in Linux Probleme bereiten kann. Das am häufigsten anzutreffende Beispiel ist ein IPX-Netzwerk, das so konfiguriert ist, daß es im selben Ethernet mit mehreren Frame-Typen umgeht. Technisch gesehen ist das eine unzulässige Konfiguration, da ein 802.2-Host nun mal nicht direkt mit einem Ethernet-II-Host kommunizieren kann und daher auch nicht beide im gleichen IPXNetzwerk liegen können. Die IPX-Netzwerksoftware von Linux “horcht” im Segment nach IPXDatagrammen, die darin transportiert werden. Anhand dieser versucht sie herauszufinden, welche Netzwerkadressen verwendet werden und welcher Frame-Typ jeder Adresse zugeordnet ist. Wird nun ein und dieselbe Netzwerkadresse für mehrere Frame-Typen oder Schnittstellen benutzt, erkennt der Linux-Code dies irrtümlicherweise als Netzwerkadressen-Kollision und kann nicht entscheiden, welcher Frame-Typ denn nun der richtige ist. Sie erkennen das daran, daß Ihre System-Logdatei Meldungen folgender Art enthält: IPX: Network number collision 0x3901ab00 eth0 etherII and eth0 802.3

Tritt ein solches Problem bei Ihnen auf, stellen Sie die automatische Erkennung ab und konfigurieren Sie die Schnittstellen manuell mit dem Befehl ipx_interface, wie im nächsten Abschnitt beschrieben.

Der Befehl ipx_interface Das Kommando ipx_interface wird benutzt, um die Unterstützung von IPX für eine vorhandene Netzwerkschnittstelle manuell hinzuzufügen, zu modifizieren oder zu entfernen. Sie sollten ipx_interface immer dann verwenden, wenn die gerade beschriebene automatische Erkennung nicht funktioniert oder wenn Sie die Konfiguration Ihrer Schnittstelle nicht dem Zufall überlassen wollen. Mit ipx_interface können Sie die IPX-Netzwerkadresse, den Zustand der primären Schnittstelle und den IPX-Frame-Typ festlegen, den ein Netzwerkgerät benutzen soll. Wenn Sie mehrere IPXSchnittstellen erzeugen, müssen Sie für jede den Befehl ipx_interface einzeln ausführen. Die Syntax des Befehls, um eine vorhandene Schnittstelle IPX-fähig zu machen, ist einfach gehalten und läßt sich am besten anhand eines Beispiels veranschaulichen: # ipx_interface add -p eth0 etherII 0x32a10103

Die Bedeutung der einzelnen Parameter: -p Dieser (optionale) Parameter gibt an, daß die Schnittstelle ein primäres Interface sein soll. eth0 Bezeichnet den Namen der Netzwerkschnittstelle, die wir IPX-fähig machen. etherII

Bestimmt den Frame-Typ, in diesem Fall Ethernet-II. Dieser Wert kann auch als 802.2, 802.3 oder SNAP codiert werden. 0x32a10103 Das ist die IPX-Netzwerkadresse, zu der diese Schnittstelle gehört. Der folgende Befehl entfernt IPX aus einer Schnittstelle: # ipx_interface del eth0 etherII

Schließlich erhalten wir eine Ausgabe der aktuellen IPX-Konfiguration einer Netzwerkschnittstelle mit: # ipx_interface check eth0 etherII

Der Befehl ipx_interface wird ausführlicher in der gleichnamigen Manpage beschrieben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

IPX-Router konfigurieren Sie erinnern sich sicher daran, als wir kurz über die Protolle in IPX-Umgebungen sprachen, daß IPX ein “routbares” Protokoll ist und für die Propagierung der Routing-Informationen das Routing Information Protocol (RIP) verwendet wird. Die IPXVersion von RIP ist der von IP ziemlich ähnlich. Sie arbeiten im wesentlichen auf dieselbe Weise; Router verbreiten die Inhalte ihrer Routing-Tabellen in regelmäßigen Abständen, und die anderen Router “lernen” hinzu, indem sie diese Informationen abhören und in sich aufsaugen. Die Hosts brauchen nur zu wissen, wo sich ihr lokales Netzwerk befindet, und können dann über ihren lokalen Router Datagramme an beliebige Zieladressen senden. Die Verantwortung zur Übertragung und Weiterleitung dieser Datagramme bis zur nächsten Etappe liegt dann beim Router. In einer IPX-Umgebung ist noch eine zweite Klasse von Netzwerkinformationen im Umlauf. Das Service Advertisement Protocol (SAP) überträgt Informationen, die Auskunft über die Dienste geben, die jeder Host im Netzwerk anbietet. SAP ermöglicht beispielsweise Benutzern, Listen von Datei- oder Druckerservern im Netzwerk zu erhalten. Das SAP funktioniert mittels Hosts, die Dienste anbieten, die in regelmäßigen Abständen eine Liste ihrer verfügbaren Dienste verbreiten. Die IPXNetzwerk-Router sammeln diese Informationen und machen sie zusammen mit den Routing-Informationen im Netz bekannt. Für einen IPX-fähigen Routermüssen Sie beide Informationsarten, also RIP und SAP, propagieren. Wie IP stellt auch IPX in Linux einen Routing-Dämon zur Verfügung, der als ipxd bezeichnet wird und für die Aufgaben zuständig ist, die mit der Verwaltung des Routings zu tun haben. Wie bei IP ist es auch hier eigentlich der Kernel, der den Transport der Datagramme zwischen IPX-Netzwerkschnittstellen übernimmt, wobei er sich dabei an eine Menge von Regeln hält, die als IPX-Routing-Tabelle bezeichnet werden. Der ipxd-Dämon hält diese Regeln immer auf dem neuesten Stand, indem er alle aktiven Netzwerkschnittstellen abhört und analysiert, wann ein Routing-Wechsel notwendig ist. ipxd antwortet aber auch auf Anfragen von Hosts in einem direkt verbundenen Netzwerk, die nach Routing-Informationen verlangen. In manchen Distributionen liegt ipxd bereits fertig ausführbar vor. Den Quellcode erhalten Sie über anonymous FTP von http://metalab.unc.edu/ in der Datei /pub/Linux/system/filesystems/ncpfs/ipxripd-x.xx.tgz. Für den ipxd-Dämon ist keine Konfiguration erforderlich. Sobald er gestartet wird, verwaltet er das Routing für die konfigurierten IPX-Schnittstellen automatisch. Entscheidend ist, daß Sie vorher Ihre IPX-Schnittstellen mit ipx_interface korrekt konfiguriert haben. Die automatische Erkennung mag zwar funktionieren, dennoch empfiehlt es sich für Routing, besser den Zufall aus dem Spiel zu lassen und die Schnittstellen manuell zu konfigurieren. Sie sparen sich viel Ärger, den die sonst möglicherweise auftretenden Routing-Probleme machen könnten. Alle 30 Sekunden überprüft ipxd alle lokal angebundenen IPX-Netzwerke und verwaltet sie automatisch. Dadurch können auch solche Schnittstellen verwaltet werden, die nicht immer aktiv sind, zum Beispiel PPP-Schnittstellen.

ipxd wird normalerweise beim Systemstart aus einem rc-Skript heraus gestartet: # /usr/sbin/ipxd

Hier ist kein &-Zeichen notwendig, da ipxd automatisch als Hintergrundprozeß läuft. Der ipxd-Dämon macht sich am nützlichsten auf Maschinen, die als IPX-Router fungieren, allerdings auch auf Hosts in Segmenten, in denen viele Router präsent sind. Wenn Sie das Argument –p angeben, arbeitet ipxd passiv; er achtet auf Routing-Informationen aus dem Segment und aktualisiert die Routing-Tabellen, überträgt jedoch selbst keinerlei Routing-Informationen. Auf diese Weise kann ein Host seine Routing-Tabellen immer aktuell halten, ohne ständig nach der Route fragen zu müssen, wenn er mal einen Remote-Host kontaktieren will.

Statisches IPX-Routing mit dem ipx_route-Befehl Es mag Situationen geben, in denen wir eine IPX-Route hart codieren möchten. Wie bei IP ist dies auch bei IPX möglich. Der Befehl ipx_route schreibt eine Route in die IPX-Routing-Tabelle hinein, so daß der ipxd-Routing-Dämon sie nicht extra zu “lernen” braucht. Die Routing-Syntax ist sehr einfach gehalten (da IPX ja keine Subnetze kennt) und sieht etwa so aus: # ipx_route add 203a41bc 31a10103 00002a02b102

Diese Anweisung fügt eine Route zum fernen IPX-Netzwerk 203a41bc über den Router unseres lokalen Netzwerks 31a10103 mit der Knotenadresse 00002a02b102 hinzu. Die Knotenadresse eines Routers können Sie herausfinden, indem Sie den tcpdump-Befehl mit der Option –e benutzen, um sich die Link-Level-Header und den Datenverkehr durch den Router ausgeben zu lassen. Ist der Router eine Linux-Maschine, können Sie das einfacher haben, indem Sie ifconfig benutzen. Zum Löschen einer Route nehmen Sie ipx_route: # ipx_route del 203a41bc

Eine Liste der aktiven Routen im Kernel können Sie der Datei /proc/net/ipx_route entnehmen. Unsere Routing-Tabelle sieht bisher so aus: # cat ipx_route Network Directly Connected

Router_Net

Router_Node 203A41BC

31A10103

00002a02b102 31A10103

Die Route zum Netzwerk 31A10103 wurde bei der Konfiguration der IPX-Schnittstelle automatisch erzeugt. Jedes unserer lokalen Netzwerke wird durch einen solchen Eintrag in der Datei /proc/net/ipx_route repräsentiert. Wenn unsere Maschine als Router arbeiten soll, braucht sie normalerweise mindestens noch eine weitere Schnittstelle.

Interne IPX-Netzwerke und Routing IPX-Hosts mit mehr als einem IPX-Interface haben für jede ihrer Schnittstellen eine einheitliche Netzwerk/KnotenAdressenkombination. Um zu solch einem Host eine Verbindung aufzubauen, können Sie jede dieser Adressenkombinationen benutzen. Wenn SAP Dienste bekanntgibt, liefert es in den Informationen über die Dienste auch immer die Adressenkombinationen mit. Für Hosts mit mehreren Schnittstellen bedeutet es, daß eine davon zur Propagierung ausgewählt werden muß; das ist die Funktion des Primary Interface Flags, worüber wir schon gesprochen haben. Das bringt aber ein Problem mit sich: Die Route zu dieser Schnittstelle muß nicht immer die optimale sein, und wenn ein Netzwerkfehler auftritt, der das Netzwerk vom Rest des Netzwerks isoliert, wird der Host unerreichbar, obwohl es noch andere mögliche Routen zu den anderen Schnittstellen gibt. Diese Routen sind allerdings auf den anderen Hosts nicht bekannt, da sie nie propagiert wurden, und der Kernel kann auch nicht wissen, daß er eigentlich nur ein anderes primäres Interface wählen bräuchte. Um solch ein Problem zu vermeiden, wurde ein spezielles Device entwickelt, das es einem IPX-Host ermöglicht, sich durch eine einzelne Routen-unabhängige Netzwerk/Knoten-Adresse zum Zweck der SAP-Propagierung bekannt zu machen. Das löst unser Problem, da diese neue Netzwerk/Knoten-Adresse über alle Host-Interfaces erreichbar und die vom SAP propagierte Adresse ist.

Das Problem und seine Lösung veranschaulicht Abbildung 15.1 anhand eines Servers, der an zwei IPX-Netzwerke angeschlossen ist. Das erste Netzwerk hat im Gegensatz zum zweiten kein internes Netzwerk. Der Host im Diagramm Abbildung 15.1 wählt eine seiner Schnittstellen als sein primäres Interface, beispielsweise 0000001a:0800000010aa. Diese Adresse wird als Dienstzugriffspunkt propagiert. Das funktioniert gut für Hosts im 0000001a-Netzwerk, aber bedeutet, daß Benutzer im 0000002c-Netzwerk durch das Netzwerk routen, um zu diesem Port zu gelangen, obwohl der Server bereits einen Port in diesem Netzwerk hat, wenn sie den Server über die SAP-Broadcasts entdeckt hätten. Abbildung 15.1: Interne IPX-Netzwerke

Das Problem läßt sich mit einer rein softwarebasierten Lösung, die solchen Hosts mit einem virtuellen Netzwerk mit virtuellen Hostadressen ausstattet, aus der Welt schaffen. Ein solches virtuelles Netzwerk stellt man sich am besten so vor, als ob es sich innerhalb des IPX-Hosts befände. Die SAP-Information braucht dann nur noch für diese virtuelle Netzwerk/KnotenAdressenkombination propagiert zu werden. Dieses virtuelle Netzwerk ist als ein internes Netzwerk bekannt. Wie bekommen aber die anderen Hosts mit, wie sie dieses interne Netzwerk erreichen? Remote-Hosts routen ins interne Netzwerk über die direkt am Host angeschlossenen Netzwerke. Das heißt, Sie sehen Routing-Einträge, die sich auf das interne Netzwerk von Hosts beziehen, die multiple IPX-Schnittstellen unterstützen. Diese Routen sollten immer die gerade optimale Route wählen, und sollte eine davon fehlschlagen, wird das Routing automatisch für die nächstbeste Schnittstelle und Route aktualisiert. In Abbildung 15.1 konfigurierten wir ein internes IPX-Netzwerk mit der Adresse 0x10000010 und benutzten die Hostadresse 00:00:00: 00:00:01. Diese Adresse wird unser primäres Interface und mittels SAP bekanntgegeben. Unser Routing spiegelt dieses Netzwerk so wider, als ob es über alle unsere realen Netzwerk-Ports erreichbar wäre. Die Hosts werden daher immer die beste Netzwerkroute für die Verbindungen zu unserem Server benutzen. Um dieses interne Netzwerk zu erzeugen, benutzen Sie das Programm ipx_internal_net aus dem IPX-Tools-Paket von Greg Page. Dessen Anwendung demonstrieren wir wiederum anhand eines kleinen Beispiels:

# ipx_internal_net add 10000010 000000000001

Diese Anweisung erzeugt ein IPX-internes Netzwerk mit der Adresse 10000010 und der Knotenadresse 000000000001. Die Netzwerkadresse muß wie jede andere IPX-Netzwerkadresse in Ihrem Netzwerk eindeutig sein. Die Knotenadresse ist beliebig wählbar, da normalerweise nur ein Knoten im Netzwerk existiert. Jeder Host darf nur ein IPX-internes Netzwerk haben, und falls konfiguriert, ist das interne Netzwerk immer das primäre Netzwerk. Um ein IPX-internes Netzwerk zu entfernen, verwenden Sie: # ipx_internal_net del

Ein internes IPX-Netzwerk macht für Sie nur dann Sinn, wenn Ihr Host einen Dienst anbietet und mehrere IPX-Schnittstellen aktiviert hat.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Mounten eines Remote-NetWare-Volumes IPX wird am häufigsten zum Mounten von NetWare-Volumes an das Linux-Dateisystem benutzt. Dadurch wird es möglich, Dateien von Linux und anderen Betriebssystemen gemeinsam zu nutzen. Volker Lendecke entwickelte den NCPClient für Linux und dazu eine Sammlung von Tools, die die gemeinsame Datennutzung möglich machen. In einer NFS-Umgebung würden wir den Befehl mount benutzen, um ein Remote-Dateisystem in Linux zu mounten. Leider stellt das NCP-Dateisystem einige besondere Anforderungen, die eine Integration in das normale mount unpraktisch machen. Statt dessen benutzen wir in Linux den Befehl ncpmount. Dieser Befehl ist eines der Tools, die in Volkers ncpfs-Paket enthalten sind, in binärer Form in den meisten modernen Distributionen angeboten werden oder als Quellcode von ftp.gwdg.de aus dem Verzeichnis /pub/linux/misc/ncpfs/ heruntergeladen werden können. Als dieses Buch geschrieben wurde, war 2.2.0 die aktuelle Version. Bevor Sie Remote-NetWare-Volumes mounten können, müssen Sie sicherstellen, daß Ihr IPX-Netzwerk korrekt konfiguriert ist (wie bereits beschrieben). Als nächstes müssen Sie die Login-Details für den NetWare-Server kennen, den Sie mounten wollen; dazu gehören die Benutzer-ID und das Paßwort. Schließlich müssen Sie noch wissen, welches Volume Sie mounten wollen und an welches lokale Verzeichnis Sie es mounten wollen.

Ein einfaches Beispiel für ncpmount Ein einfaches Beispiel einer ncpmount-Anwendung sieht etwa so aus: # ncpmount -S ALES_F1 -U rick -P d00-b-gud /mnt/brewery

Diese Anweisung mountet alle Volumes des Dateiservers ALES_F1 im Verzeichnis /mnt/brewery. Für das NetWareLogin wird der Benutzername rick und das Paßwort d00-b-gud verwendet. Der ncpmount-Befehl ist normalerweise auf Setuid root gesetzt und kann daher von jedem Linux-Anwender benutzt werden. Standardmäßig ist nur dieser Anwender Eigentümer der Verbindung, und nur er oder root können das gemountete Volume wieder abtrennen.

NetWare verwendet den Begriff Volume, was analog zu einem Dateisystem in Linux ist. Ein NetWare-Volume ist die logische Repräsentation eines NetWare-Dateisystems. Dabei kann es sich um eine einzelne logische Festplatten-Partition handeln, die über mehrere physikalische Partitionen verteilt ist.Standardmäßig sieht der NCPFS-Support von Linux die Volumes als Unterverzeichnisse eines umfassenderen logischen Dateisystems an, das durch den ganzen Dateiserver repräsentiert wird. Der Befehl ncpmount bewirkt, daß jedes der NetWare-Volumes eines gemounteten Dateiservers als Unterverzeichnis unterhalb des Mount-Punktes erscheint. Das ist ganz praktisch wenn Sie auf den gesamten Server zugreifen wollen. Aus komplizierten technischen Gründen können Sie allerdings diese Verzeichnisse nicht mit NFS reexportieren, wenn Sie das vorhaben sollten. Wie man dieses Problem umgeht, zeigen wir in Kürze anhand einer etwas aufwendigeren Alternative.

Der Befehl ncpmount im Detail Der Befehl ncpmount kennt eine Vielzahl von Kommandozeilenoptionen, die Ihnen viele Möglichkeiten geben, Ihre NCPMounts zu verwalten. Die wichtigsten Optionen werden in Tabelle 15.2 beschrieben. Tabelle 15.2: Optionen von ncpmount Argument

Beschreibung

–S server

Der Name des Dateiservers, der gemountet werden soll.

–U user_name

Die NetWare-Benutzer-ID für das Login in den Dateiserver.

–P password

Das Paßwort für den NetWare-Server-Login.

–n –C

Diese Option muß für NetWare-Logins angegeben werden, für die kein Paßwort erforderlich ist. Diese Option verhindert die automatische Umwandlung der Paßwörter in Großbuchstaben.

Mit dieser Option geben Sie an, wer der Eigentümer der Verbindung zum Dateiserver ist. Das ist –c client_name nützlich zum Drucken in NetWare. Darauf gehen wir später noch im Detail ein.

–u uid

–g gid

–f file_mode

Die Linux-Benutzer-ID, die als Eigentümer der Dateien im gemounteten Verzeichnis angezeigt werden soll. Ist diese Option nicht angegeben, wird die ID des Benutzers genommen, der den ncpmount-Befehl ausführt. Die Linux-Gruppen-ID, die als Eigentümer der Dateien im gemounteten Verzeichnis angezeigt werden soll. Ist diese Option nicht angegeben, wird die Gruppen-ID des Benutzers genommen, der den ncpmount-Befehl ausführt. Mit dieser Option stellen Sie die Dateiattribute (Zugriffsrechte) ein, die die Dateien im gemounteten Verzeichnis haben sollen. Der Wert sollte oktal angegeben werden, z.B. 0664. Die tatsächlichen Dateiattribute ergeben sich aus der maskierten Verknüpfung der Attribute dieser Option mit denjenigen Dateiattributen, die für die Dateiserver-Dateien der NetWare-Benutzer-ID angegeben sind. Sie müssen also sowohl Zugriffsrechte auf dem Server haben als auch Rechte, die von dieser Option festgelegt werden, um auf eine NetWare-Datei zugreifen zu können. Die Standardvorgabe wird von der aktuellen umask abgeleitet.

–d dir_mode

–V volume

–t time_out

Mit dieser Option spezifizieren Sie Zugriffsrechte auf Unterverzeichnisse des gemounteten Verzeichnisses. Sie verhält sich genauso wie die Option –f, mit der Ausnahme, daß die StandardZugriffsrechte von der aktuellen umask abgeleitet werden. Wo Leserecht gewährt wird, liegt auch Ausführungsrecht vor. Diese Option gibt den Namen eines einzelnen NetWare-Volumes an, das unter dem Mount-Punkt gemountet werden soll. Es werden somit nicht automatisch alle Volumes des Zielservers gemountet. Diese Option muß angegeben werden, wenn Sie ein gemountetes NetWare-Volume über NFS wieder exportieren wollen. Mit dieser Option geben Sie die Timeout-Zeit an, die der NCPFS-Client warten soll, bis er eine Antwort vom Server erhält. Der Timeout-Wert wird in Hundertstelsekunden angegeben und beträgt standardmäßig 60 ms. Wenn Sie bei NCP-Mounts irgendwelche Stabilitätsprobleme feststellen, sollten Sie es noch mal mit höheren Timeout-Werten probieren.

Der NCP-Client-Code versucht, Datagramme mehrmals zum Server zu senden, bevor er die Verbindung als getrennt ansieht. Die Anzahl der Wiederholungsversuche (standardmäßig 5) stellen –r retry_count Sie mit dieser Option ein.

Wie Sie Ihr NetWare-Login-Paßwort verstecken Es ist ziemlich riskant, das Paßwort in der Kommandozeile einzugeben, wie wir das beim ncpmount-Befehl gemacht haben. Andere gleichzeitig aktive Benutzer könnten das Paßwort zu Gesicht bekommen, wenn sie Programme wie top oder ps benutzen. Um solche Sicherheitslücken zu vermeiden, kann ncpmount bestimmte Details auch aus einer Datei im Home-Verzeichnis des Benutzers auslesen. In dieser Datei gibt der Benutzer den Login-Namen und das Paßwort für jeden Dateiserver an, den er mounten will. Diese Datei ist ~/.nwclient und muß auf Zugriffsrecht 0600 eingestellt sein, um sicherzustellen, daß andere Benutzer sie nicht lesen können. Sind die Zugriffsrechte nicht korrekt eingestellt, weigert sich ncpmount, die Datei zu benutzen. Die Datei hat eine sehr einfache Syntax. Jede Zeile, die mit einem # beginnt, wird als Kommentar aufgefaßt und ignoriert. Die anderen Zeilen haben folgende Syntax: fileserver/userid password

fileserver ist der Name des Dateiservers, der die Volumes enthält, die Sie mounten wollen. userid bezeichnet den Login-Namen Ihres Benutzerkontos auf diesem Server. Das Feld password ist optional. Wenn es nicht angegeben ist, fragt ncpmount die Benutzer nach dem Paßwort, wenn sie einen Mount-Versuch unternehmen. Wird im password das Zeichen – angegeben, wird kein Paßwort benutzt; das ist äquivalent zur Option –n. Sie können beliebig viele Einträge angeben, das Dateiserver-Feld muß aber eindeutig sein. Der erste Dateiserver-Eintrag hat eine besondere Bedeutung. ncpmount benutzt die Option –S, um zu ermitteln, welcher Eintrag in ~/.nwclient benutzt werden soll. Ist kein Server in der Option –S angegeben, wird der erste Servereintrag in ~/.nwclient als Ihr bevorzugter Server genommen. Sie sollten den Server, den Sie am häufigsten mounten, in der Datei an die erste Stelle setzen.

Ein etwas aufwendigeres Beispiel mit ncpmount Lassen Sie uns ein etwas komplizierteres Beispiel für ncpmount betrachten, in dem einige der eben besprochenen Features auftauchen. Als erstes erzeugen wir eine einfache ~/.nwclient-Datei: # NetWare-Login-Details für die virtuelle Brauerei und Winzerei # # Brauerei-Login ALES_F1/MATT staoic1 # # Winzerei-Login REDS01/MATT staoic1 #

Stellen Sie sicher, daß die Zugriffsrechte korrekt gesetzt sind: $ chmod 600 ~/.nwclient

Nun mounten wir ein Volume vom Server der Winzerei in ein Unterverzeichnis eines gemeinsam genutzten Verzeichnisses. Dabei setzen wir die Datei- und Verzeichnis-Zugriffsrechte so, daß andere Benutzer von dort aus auf gemeinsame Daten zugreifen können. $ ncpmount -S REDS01 -V RESEARCH -f 0664 -d 0775 /usr/share/winery/data/

Diese Anweisung bewirkt in Kombination mit der oben erwähnten Datei ~/.nwclient, daß das Volume RESEARCH des Servers REDS01 in das Verzeichnis /usr/share/winery/data/ gemountet wird, wobei MATT als NetWare-Benutzer-ID genommen und das Paßwort aus der Datei ~/.nwclient gelesen wird. Die Zugriffsrechte der gemounteten Dateien sind 0664, und die Zugriffsrechte des Verzeichnisses sind 0775.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Einige weitere IPX-Tools Das ncpfs-Paket enthält eine Menge nützlicher Tools, die wir bisher noch nicht näher beschrieben haben. Viele dieser Tools bilden das Verhalten der mit NetWare gelieferten Tools nach. In diesem Abschnitt beschäftigen wir uns mit den nützlichsten von ihnen.

Serverliste Der Befehl slist listet alle Dateiserver auf, auf die der Host zugreifen kann. Diese Information kommt vom nächstgelegenen IPX-Router. Ursprünglich war dieser Befehl wahrscheinlich nur dazu vorgesehen, den Benutzern mitzuteilen, von welchen Dateiservern sie überhaupt mounten können. Er hat sich aber mittlerweile zu einem recht nützlichen Netzwerk-Diagnose-Tool gemausert, mit dem Netzwerkadministratoren feststellen können, wo SAP-Informationen propagiert werden: $ slist NPPWR-31-CD01 A3062DB0 000000000001 F16 35540430 000000000001 CD01 53171D02 000000000001 D1014D0E 000000000001 MAIL_F4R

23A91330

QITG_284ELI05_F4 B2030D6A NMCS_33PARK08_F2 21790430 QCON_7TOMLI04_F7 QCON_481GYM0G_F1 33200C30

000000000001 V242X-14-F02 78A20430 000000000001 000000000001 VWPDE-02-F08 248B0530 000000000001 000000000001 NWGNG-F07 72760630 000000000001 77690130 000000000001 000000000001

QRWMA-04NCCRD-00W639W-F04 VITG_SOE-

Der Befehl slist akzeptiert keine Argumente. In der Ausgabe erscheint der Name des Dateiservers, die IPX-Netzwerkadresse und die Hostadresse.

Senden von Nachrichten an NetWare-Benutzer NetWare unterstützt einen Mechanismus, mit dem Nachrichten an eingeloggte Benutzer versendet werden können. Der Befehl nsend implementiert dieses Feature in Linux. Um Nachrichten senden zu können, müssen Sie in den Server eingeloggt sein. Sie müssen dazu den Namen des Dateiservers und die Login-Details in der Kommandozeile angeben, zusammen mit dem Namen des Adressaten und der zu sendenden Nachricht: # nsend -S vbrew_f1 -U gary -P j0yj0y supervisor queues!"

"Join me for a lager before we do the print

Hier sendet der Benutzer mit dem Login-Namen gary eine Einladung zur genannten Person, wobei er das supervisorBenutzerkonto auf dem Dateiserver ALES_F1 verwendet. Wenn wir diese Daten nicht angeben, werden für den Dateiserver und die Login-Berechtigungsnachweise Standardvorgaben genommen.

Das Browsen und Manipulieren von Bindery-Daten Jeder NetWare-Dateiserver führt einen Katalog über seine Benutzer und seine Konfiguration. Er wird als Bindery bezeichnet. Linux unterstützt eine Reihe von Tools, die Ihnen das Lesen und, wenn Sie Supervisor-Rechte auf dem Server haben, auch das Setzen und Löschen einer Bindery ermöglichen. Eine Übersicht dieser Tools zeigt Tabelle 15.3. Tabelle 15.3: Linux Bindery-Manipulations-Tools Befehlsname Beschreibung des Befehls nwfstime nwuserlist nwvolinfo nwbocreate nwbols nwboprops nwborm nwbpcreate nwbpvalues nwbpadd nwbprm

Zeigt oder setzt Datum und Uhrzeit eines NetWare-Servers Listet die in einem NetWare-Server eingeloggten Benutzer auf Gibt Informationen über NetWare-Volumes aus Erzeugt ein NetWare-Bindery-Objekt Listet NetWare-Bindery-Objekte auf Listet Eigenschaften eines NetWare-Bindery-Objekts auf Entfernt ein NetWare-Bindery-Objekt Erzeugt eine NetWare-Bindery-Eigenschaft Druckt die Inhalte einer NetWare-Bindery-Eigenschaft Setzt den Wert einer NetWare-Bindery-Eigenschaft Entfernt eine NetWare-Bindery-Eigenschaft

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Drucken in eine NetWare-Druckerwarteschlange Das ncpfs-Paket enthält ein kleines Hilfsprogramm namens nprint, mit dem man Druckaufträge über eine NCP-Verbindung an eine NetWare-Druckerwarteschlange senden kann. Dieser Befehl erzeugt automatisch eine Verbindung, sofern sie gerade nicht besteht, und benutzt die Datei ~/.nwclient, die wir bereits beschrieben haben, um den Benutzernamen und das Paßwort vor neugierigen Blicken zu verbergen. Die Befehlszeilenargumente, die für den Login-Prozeß verwendet werden, sind dieselben wie bei ncpmount, so daß wir hier nicht näher auf sie eingehen. In unseren Beispielen betrachten wir nur die wichtigsten Kommandozeilenargumente. Details können Sie der Manpage nprint(1) entnehmen. Das einzige für nprint erforderliche Argument ist der Name der Datei, die gedruckt werden soll. Ist als Dateiname – oder überhaupt kein Dateiname angegeben, erwartet nprint den Druckauftrag von der Standardeingabe stdin. Die wichtigsten Optionen von nprint geben den Dateiserver und die Druckerwarteschlange an, an die Sie den Druckauftrag senden wollen. Siehe dazu Tabelle 15.4. Tabelle 15.4: Kommandozeilenoptionen von nprint Option

-S server_name

-q queue_name

Beschreibung Der Name des NetWare-Dateiservers, der für die Druckerwarteschlange zuständig ist, an die Sie Druckaufträge schicken wollen. Für gewöhnlich ist es bequem, für den Server einen Eintrag in ~/.nwclient vorzusehen. Diese Option ist obligatorisch. Die Druckerwarteschlange, an die Sie den Druckauftrag schicken wollen. Diese Option ist obligatorisch.

Text, der im Druckerkonsolen-Utility erscheint, wenn die Liste der Druckaufträge in der Warteschlange -d job_description angezeigt wird.

-l lines -r columns -c copies

Die Anzahl der Zeilen pro gedruckter Seite. Vorgabewert ist 66. Die Anzahl der Spalten pro gedruckter Seite. Vorgabewert ist 80. Die Anzahl der Kopien des Druckauftrags. Vorgabewert ist 1.

Ein einfaches Anwendungsbeispiel von nprint sieht wie folgt aus:

$ nprint -S REDS01 -q PSLASER -c 2 /home/matt/ethylene.ps

Diese Anweisung druckt zwei Kopien der Datei /home/matt/ethylene.ps auf dem Drucker PSLASER auf dem Dateiserver REDS01 und benutzt dabei einen Benutzernamen und ein Paßwort aus der Datei ~/.nwclient.

Anwendung von nprint mit dem Line-Printer-Dämon Sie erinnern sich bestimmt daran, daß wir bereits erwähnten, daß die Option –c für den Befehl ncpmount nützlich zum Drucken ist. Wir erläutern nun abschließend, warum das so ist und wie es funktioniert. Linux nutzt normalerweise eine BSD-artige Druckersoftware. Der Line Printer Daemon (lpd) ist ein Dämon, der ein lokales SpoolVerzeichnis nach dort abgelegten Druckjobs durchsucht. lpd liest den Druckernamen und einige andere Parameter aus einer speziell formatierten Spool-Datei und schickt die Daten an den Drucker. Optional werden die Daten durch einen Filter geschickt, um sie auf irgendeine Weise zu transfomieren oder zu manipulieren. Der lpd-Dämon benutzt eine einfache Datei namens /etc/printcap, in der die Drucker-Konfigurationsdaten abgespeichert werden (welche Filter benutzt werden sollen etc.). lpd läuft normalerweise mit den Zugriffsrechten eines speziellen Systembenutzers namens lp. Sie könnten nprint als Filter für lpd konfigurieren, wodurch Benutzer Ihrer Linux-Maschine ihre Druckjobs direkt auf RemoteDrucker senden könnten, die von einem NetWare-Dateiserver gehostet werden. Dazu muß der Benutzer lp in die Lage versetzt werden, NCP-Anfragen an die NCP-Verbindung zum Server zu schreiben. Wenn Sie dasselbe erreichen wollen, ohne den Systembenutzer lp zum Aufbau einer eigenen Verbindung und zum Einloggen zu verpflichten, sollten Sie lp als Eigentümer einer Verbindung angeben, die von einem anderen Benutzer aufgebaut wurde. Das folgende Beispiel zeigt in drei Schritten, wie Sie das Drucksystem in Linux so einrichten, daß es Druckjobs von Clients über NetWare verarbeiten kann: 1. Schreiben Sie ein Wrapper-Skript. Die Datei /etc/printcap läßt keine Optionen zu, die an die Druckfilter weitergereicht werden könnten. Dafür müssen Sie erst ein kleines Skript schreiben, das den Befehl mit den gewünschten Optionen ausführt. Wie einfach so ein Wrapper-Skript sein kann, zeigt: #!/bin/sh # p2pslaser - einfaches Skript für die Ausgabeumleitung zur # Druckerwarteschlange PSLASER auf dem Server REDS01 # /usr/bin/nprint -S REDS01 -U stuart -q PSLASER #

Speichern Sie das Skript in der Datei /usr/local/bin/p2pslaser ab. 2. Schreiben Sie den /etc/printcap-Eintrag. Wir müssen das soeben erzeugte Skript p2pslaser als Ausgabefilter in /etc/printcap eintragen, etwa so: pslaser|Postscript Laser Printer hosted by NetWare server:\ :lp=/dev/null:\ :sd=/var/spool/lpd/pslaser:\ :if=/usr/local/bin/p2pslaser:\ :af=/var/log/lp-acct:\ :lf=/var/log/lperrs:\ :pl#66:\ :pw#80:\ :pc#150:\ :mx#0:\ :sh:

3. Fügen Sie dem Befehl ncpmount die Option –c hinzu. ncpmount -S REDS01 .... -c lp ....

Unser lokaler Benutzer stuart muß dann lp als Eigentümer der Verbindung angeben, wenn er den Remote-NetWare-Server mountet. Nun kann jeder Linux-Anwender pslaser als Druckernamen angeben, wenn er den Befehl lp ausführt. Der Druckjob wird dann zum angegebenen NetWare-Server geschickt und in dessen Druckerwarteschlange eingetragen.

Verwaltung von Druckerwarteschlangen

Der Befehl pqlist listet alle Druckerwarteschlangen auf, die auf dem angegebenen Server verfügbar sind. Wenn Sie in der Befehlszeile keinen Dateiserver mit der Option -S oder auch keinen Benutzernamen und kein Paßwort angeben, werden dafür die Vorgabewerte aus Ihrer ~/.nwclient-Datei genommen: # pqlist Queue ID AA02009E DA03007C 0D0A003B

-S vbrew_f1 -U guest -n Server: ALES_F1 Print queue name ------------------------------------------------------------ TEST Q2 EF0200D9 NPI223761_P1 Q1 F1060004 I-DATA NPI223761_P3 D80A0031

Unser Beispiel zeigt eine Liste von Druckerwarteschlangen, die dem Benutzer guest auf dem Dateiserver ALES_F1 zur Verfügung stehen.1 Um die Druckjobs in einer Warteschlange anzeigen zu lassen, benutzen Sie den Befehl pqstat. Er erwartet den Namen der Warteschlange als Argument und listet alle Jobs darin auf. Optional können Sie auch die Anzahl der auszugebenden Aufträge angeben. Das folgende Ausgabebeispiel wurde in der Zeilenlänge etwas gekürzt, damit es auf diese Buchseite paßt: $ pqstat -S ALES_F1 NPI223761_P1 Server: ALES_F1 6A0E000C Seq Name Description ---------------------------------------------------Active 0 02660001

Queue: NPI223761_P1 Queue ID: Status Form Job ID -------------------1 TOTRAN LyX document - proposal.lyx

Wir sehen hier nur einen Druckjob in der Warteschlange, dessen Eigentümer TOTRAN ist. Die anderen Optionen enthalten eine Beschreibung des Jobs, seines Zustands sowie die Job-ID. Der Befehl pqrm dient zum Entfernen von Druckaufträgen aus einer Warteschlange. Um den eben angezeigten Druckjob zu löschen, geben wir folgendes ein: $ pqrm -S ALES_F1 NPI223761_P1 02660001

Der Befehl ist einfach, aber umständlich zu bedienen, wenn man es eilig hat. Es lohnt sich vielleicht, dafür ein kleines Skript zu schreiben.

1.

Es hat den Anschein, als ob die Systemadministratoren erst einige Kostproben der virtuellen Brauerei genossen hätten, bevor sie sich einige Namen für die Warteschlangen ausdachten. ;-) Hoffentlich sind die Namen, die Sie auswählen, etwas aussagekräftiger.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Emulation von NetWare-Servern Unter Linux gibt es zwei freie Software-Emulatoren für NetWare-Dateiserver. lwared wurde von Ales Dryak und mars_nwe von Martin Stover entwickelt. Beide Softwarepakete stellen elementare NetWare-Dateiserver-Emulationen unter Linux zur Verfügung. Damit können NetWare-Clients LinuxVerzeichnisse mounten, die als NetWare-Volumes exportiert sind. Während der lwared-Server einfacher zu konfigurieren ist, bietet der mars_nwe-Server mehr Features. Die Installation und Konfiguration dieser Pakete würde den Rahmen dieses Kapitels sprengen, sie werden aber im IPXHOWTO beschrieben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 16 Taylor UUCP verwalten

UUCP wurde in den späten Siebzigern von Mike Lesk in den AT&T Bell Laboratories entworfen. Es sollte ein einfaches Wählnetzwerk über normale Telefonleitungen zur Verfügung stellen. Obwohl PPPund SLIP-Wählverbindungen ins Internet weit verbreitet sind, kommunizieren viele Leute, die E-Mail

und Usenet-News auf ihren Heimcomputern anwenden möchten, immer noch über UUCP, da es häufig günstiger ist. Das gilt insbesondere für Länder, in denen Internetanwender Minutenpreise für die Telefonverbindungen zahlen müssen oder ihre Provider nur über Ferngespräche erreichen können. Obwohl es eine ganze Reihe von UUCP-Implementierungen für eine Vielzahl unterschiedlicher Hardwareplattformen und Betriebssysteme gibt, sind sie dennoch in hohem Maße zueinander kompatibel. Aber wie bei der meisten Software, die sich über die Jahre irgendwie als “Standard” etabliert hat, gibt es kein UUCP, das man als das UUCP bezeichnen würde. Seit der ersten Version im Jahre 1976 wurde es ständig weiterentwickelt. Momentan gibt es zwei Arten, die sich im wesentlichen in der unterstützten Hardware und ihrer Konfiguration unterscheiden. Aus diesen beiden Versionen entstanden die unterschiedlichen Implementierungen, die jeweils leicht von ihren Geschwistern abweichen. Eine Spezies wird Version-2-UUCP genannt, was auf eine Implementierung von Mike Lesk, David A. Novitz und Greg Chessona aus dem Jahre 1977 zurückdatiert. Obwohl sie recht alt ist, wird sie immer noch häufig eingesetzt. Neuere Implementierungen von Version 2 bieten viel vom Komfort der neueren UUCP-Arten. Die zweite Spezies wurde 1983 entwickelt und wird allgemein als BNU (Basic Networking Utilities) oder HoneyDanBer-UUCP bezeichnet. Der Name wurde aus den Namen der Autoren (P. Honeyman, D. A. Novitz und B. E. Redman) abgeleitet und wird oft in der Kurzform HDB verwendet, die wir auch in diesem Kapitel benutzen werden. HDB wurde entwickelt, um einige Defizite der UUCPVersion 2 zu beseitigen. So kamen etwa neue Transferprotokolle hinzu, und das Spool-Verzeichnis wurde so aufgeteilt, daß es nun für jede Site, mit der Sie Daten austauschen, ein Verzeichnis gibt. Die Implementierung von UUCP, die momentan mit Linux geliefert wird und mit der wir uns in diesem Kapitel beschäftigen, ist Taylor UUCP 1.06.1 Sie wurde im August 1995 freigegeben. Taylor UUCP kann auch so kompiliert werden, daß es außer den traditionellen Konfigurationsdateien auch die neuartigen (Taylor-)Konfigurationsdateien versteht. Taylor UUCP ist in der Regel so kompiliert, daß es zu HDB, zum Taylor-Konfigurationsschema oder zu beidem kompatibel ist. Da das Taylor-Schema wesentlich flexibler und wohl auch einfacher zu verstehen ist als die oft obskuren HDB-Konfigurationsdateien, stellen wir hier nur das Taylor-Schema vor. Der Sinn und Zweck dieses Kapitels liegt nicht darin, Ihnen eine ausführliche Beschreibung jeder Kommandozeilenoption der verschiedenen UUCP-Befehle zu geben. Vielmehr soll gezeigt werden, wie Sie einen funktionierenden UUCP-Knoten aufbauen. Der erste Abschnitt gibt eine einfache Einführung, wie UUCP entfernte Programmausführung (remote execution) und Dateitransfers implementiert. Wenn Ihnen UUCP nicht ganz fremd ist, können Sie bereits jetzt im Abschnitt UUCPKonfigurationsdateien weitermachen, wo die verschiedenen Dateien beschrieben sind, mit denen UUCP eingerichtet wird. Im folgenden setzen wir voraus, daß Ihnen die Benutzerprogramme des UUCP-Pakets bekannt sind,

nämlich uucp und uux. Eine Beschreibung können Sie den Online-Manpages entnehmen. Neben den allgemein zugänglichen Programmen uux und uucp enthält das UUCP-Paket eine Reihe von Befehlen, die nur administrativen Zwecken dienen. Diese werden dazu genutzt, den UUCPTransport über Ihren Knoten zu überwachen, alte Logdateien zu entfernen oder Statistiken zu erstellen. Hier wird allerdings keines dieser Programme beschrieben, weil sie bei den Hauptaufgaben von UUCP nur eine untergeordnete Rolle spielen. Nebenbei gesagt, sind sie sehr gut dokumentiert und recht einfach zu verstehen; ausführliche Informationen finden Sie in den Manpages. Daneben gibt es noch eine dritte Kategorie, die die eigentlichen “Arbeitspferde” für UUCP stellt: uucico (wobei cico für copy-in copy-out steht) und uuxqt, das von einem entfernten Host gesandte Jobs ausführt. Auf diese beiden wichtigen Programme konzentrieren wir uns in diesem Kapitel. Diejenigen unter Ihnen, die in diesem Kapitel nicht alles finden, was sie brauchen, sollten sich die mit dem UUCP-Paket gelieferte Dokumentation vornehmen. Diese besteht aus einer Reihe von TexinfoDateien, die die Einrichtung unter Verwendung des Taylor-Konfigurationsschemas beschreiben. Die Texinfo-Dateien können Sie mit texi2dvi (im Texinfo-Paket Ihrer Distribution enthalten) in eine dviDatei konvertieren und sich diese mit dem Befehl xdvi anschauen. Guylhem Aznars UUCP-HOWTO ist eine weitere gute Informationsquelle über UUCP in LinuxUmgebungen. Es ist auf jedem Spiegelserver des Linux Documentation Projects erhältlich und wird regelmäßig nach comp.os.linux.answers gepostet. Es existiert auch eine Newsgruppe zum Thema UUCP namens comp.mail.uucp. Wenn Sie Fragen zu Taylor UUCP haben, sollten Sie sie lieber dort stellen als in den comp.os.linux.*-Gruppen.

1.

Autor und Copyright-Halter ist Ian Taylor (1995).

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

UUCP-Transfer und Remote-Befehle Das Konzept der Jobs ist für das Verständnis von UUCP von elementarer Bedeutung. Jeder Datentransfer, den ein Benutzer mit uucp oder uux initiiert, wird Job genannt. Er besteht aus einem Befehl, der auf dem Remote-System ausgeführt wird, einer Reihe von Dateien, die zwischen Sites übertragen werden sollen, oder aus beidem zusammen. Im folgenden Beispiel wird UUCP dazu benutzt, die Datei netguide.ps zu einem entfernten Host namens pablo zu übertragen und den Befehl lpr auf pablo auszuführen, um die Datei zu drucken: $ uux -r pablo!lpr !netguide.ps

UUCP ruft üblicherweise das entfernte System nicht direkt an, um einen Job auszuführen (sonst könnten Sie das auch mit kermit erledigen). Statt dessen wird vorübergehend eine Beschreibung des Jobs zwischengespeichert. Diese Technik wird Spooling genannt. Der Verzeichnisbaum, unter dem die Jobs gespeichert werden, wird daher auch Spool-Verzeichnis genannt und befindet sich üblicherweise in /var/spool/uucp. In unserem Beispiel würde die Job-Beschreibung Informationen zum Befehl (lpr) enthalten, der ausgeführt werden soll, zum Benutzer, der die Ausführung angefordert hat, und zu einigen weiteren Details. Neben der Job-Beschreibung muß UUCP auch die Eingabedatei netguide.ps speichern.

Der exakte Ort und die Bezeichnungen von Spool-Dateien können, abhängig von einigen Optionen während des Kompilierens, variieren. HDB-kompatible UUCPs speichern Spool-Dateien üblicherweise in einem /var/spool/uucp-Unterverzeichnis mit dem Namen der entfernten Site. Wurde UUCP für die Taylor-Konfiguration kompiliert, erzeugt es Unterverzeichnisse für verschiedene Arten von Spool-Dateien im Site-spezifischen Spool-Verzeichnis. In regelmäßigen Intervallen wählt UUCP das entfernte System an. Steht die Verbindung zum entfernten System, überträgt UUCP die den Job beschreibenden Dateien sowie alle Eingabedateien. Die eingehenden Jobs werden nicht sofort ausgeführt, sondern erst nachdem die Verbindung unterbrochen wurde. Dies wird im allgemeinen durch uuxqt erledigt, das auch dafür sorgt, daß alle Jobs weitergeleitet werden, die für eine andere Site bestimmt sind. Um zwischen wichtigen und weniger wichtigen Jobs zu unterscheiden, verknüpft UUCP mit jedem Job eine Klasse (Grade). Dabei handelt es sich um ein einzelnes Zeichen von 0 bis 9, A bis Z und a bis z, bei abnehmender Wichtigkeit. Mail wird normalerweise mit der Klasse B oder C gespoolt, während News mit Klasse N gespoolt werden. Jobs mit höheren Klassen werden früher übertragen. Sie können Spool-Klassen mit der Option –g vergeben, wenn Sie uucp bzw. uux starten. Sie können auch den Transfer von Jobs zu bestimmten Zeiten unterbinden, wenn eine bestimmte Klasse unterschritten wird. Dieser Wert wird als die maximale Spool-Klasse bezeichnet, ab dem eine Übertragung verboten ist. Sie ist normalerweise auf z voreingestellt, so daß alle Klassen übertragen werden dürfen. Beachten Sie die terminologische Doppeldeutigkeit an dieser Stelle: Eine Datei wird nur dann übertragen, wenn ihre Klasse gleich oder größer der maximalen Spool-Klasse ist.

Die interne Arbeitsweise von uucico Um zu verstehen, warum uucico bestimmte Dinge wissen muß, ist eine kurze Beschreibung darüber hilfreich, wie es die eigentliche Verbindung zu einem entfernten System herstellt. Wenn Sie uucico –s system von der Kommandozeile aus ausführen, muß uucico zuerst eine physikalische Verbindung herstellen. Die durchzuführenden Aktionen sind von der Verbindungsart abhängig. Wird eine Telefonleitung verwendet, muß ein Modem gefunden und herausgewählt werden. Unter TCP muß gethostbyname aufgerufen werden, um den Namen in eine Netzwerkadresse umzuwandeln. Der zu öffnende Port muß ermittelt und die Adresse an den entsprechenden Socket gebunden werden. Nachdem die Verbindung aufgebaut worden ist, muß eine Autorisierungsprozedur durchgeführt werden. Diese Prozedur besteht normalerweise darin, daß das entfernte System nach einem LoginNamen und eventuell nach einem Paßwort fragt. Dies wird im allgemeinen als Login-Chat bezeichnet. Die Autorisierungsprozedur wird entweder vom normalen getty/Login-Paket oder, bei TCP-Sockets, von uucico selbst durchgeführt. Ist die Autorisierung erfolgreich verlaufen, wird am anderen Ende uucico gestartet. Die lokale Kopie von uucico, die die Verbindung initiiert hat, wird als Master, die entfernte Kopie als Slave bezeichnet. Als nächstes folgt die Handshake-Phase: Der Master sendet nun seinen Hostnamen zusammen mit

einigen Flags. Der Slave überprüft diesen Hostnamen auf Login-Erlaubnis, Senden und Empfangen von Dateien usw. Die Flags beschreiben unter anderem die maximale Klasse der zu übertragenden Dateien. Falls aktiviert, wird ein Kommunikationszähler, die Call Sequence Number, an dieser Stelle überprüft. Mit dieser Option verwalten beide Seiten jeweils die Anzahl erfolgreicher Verbindungen, die nun miteinander verglichen werden. Stimmen sie nicht überein, schlägt der Handshake fehl. Diese Option ist nützlich, um sich vor Eindringlingen zu schützen. Zum Schluß versuchen sich beide uucicos auf ein gemeinsames Übertragungsprotokoll zu einigen. Dieses Protokoll legt fest, wie Daten übertragen, auf ihre Konsistenz hin überprüft und im Fehlerfall erneut übertragen werden. Wegen der verschiedenen möglichen Verbindungsarten müssen auch verschiedene Protokolle unterstützt werden. So benötigen Telefonverbindungen ein “sicheres” Protokoll, das pingelig auf Fehler achtet, während die TCP-Übertragung ausreichend zuverlässig ist und daher ein effizienteres Protokoll verwenden kann, bei dem viele der zusätzlichen Fehlerprüfungen weggelassen werden können. Nachdem der Handshake durchgeführt wurde, beginnt die eigentliche Übertragungsphase. Beide Seiten aktivieren den vereinbarten Protokolltreiber. An diesem Punkt führen die Treiber gegebenenfalls eine protokollspezifische Initialisierungssequenz durch. Der Master sendet dann alle aufgelaufenen Dateien, deren Spool-Klasse ausreichend hoch ist, an das entfernte System. Ist die Übertragung beendet, wird der Slave darüber informiert, daß die Übertragung abgeschlossen ist. Der Slave kann nun die Verbindung unterbrechen oder die Kommunikation selbst übernehmen. In diesem Fall werden also die Rollen getauscht: Das entfernte System wird zum Master, und das lokale wird zum Slave. Der neue Master überträgt nun seine Dateien. Ist auch diese Übertragung abgeschlossen, tauschen beide uucicos Terminierungsnachrichten miteinander aus und schließen die Verbindung. Wenn Sie mehr über UUCP wissen wollen, sehen Sie sich bitte den Quellcode an. Im Netz kursiert außerdem einwirklich antiquierter Artikel von David A. Novitz, der eine detaillierte Beschreibung des UUCP-Protokolls enthält.1 Auch die Taylor UUCP-FAQ enthält einige Details darüber, wie UUCP implementiert wurde. Sie wird regelmäßig an comp.mail.uucp gepostet.

Kommandozeilenoptionen von uucico In diesem Abschnitt beschreiben wir die wichtigsten Kommandozeilenoptionen für uucico. – – system, –s system Ruft das angegebene system an, wenn dies durch Rufzeitbeschränkungen nicht unterbunden wird. –S system Ruft das angegebene system ohne jede Vorbedingung an.

– –master, –r1 Startet uucico im Master-Modus. Dies ist Standard, wenn die Optionen –s oder –S angegeben sind. Steht die Option –r1 für sich allein, versucht uucico, alle in der sys-Datei eingetragenen Systeme anzurufen (wie im nächsten Abschnitt dieses Kapitels beschrieben), solange dies durch Ruf- oder Wiederholungs-Zeitbeschränkungen nicht unterbunden wird. – –slave, –r0 Startet uucico im Slave-Modus. Dies ist Standard, wenn die Optionen –s oder –S nicht angegeben sind. Im Slave-Modus wird davon ausgegangen, daß entweder die Standardeingabe/ausgabe mit einem seriellen Port verbunden ist oder daß der mit der Option –p angegebene TCP-Port verwendet wird. – –ifwork,–C Diese Option ist eine Ergänzung zu –s oder –S und weist uucico an, das genannte System nur dann anzurufen, wenn dafür Jobs gespoolt worden sind. – –debug typ, –x typ, –X typ Aktiviert das Debugging für den angegebenen Typ. Verschiedene Typen können in einer durch Kommata getrennten Liste angegeben werden. Die folgenden Typen sind zulässig: abnormal, chat, handshake, uucp-proto, proto, port, config, spooldir, execute, incoming und outgoing. Mit all werden alle Optionen aktiviert. Zwecks Kompatibilität mit anderen UUCPImplementierungen kann statt dessen auch eine Nummer angegeben werden, die das Debugging für die ersten n Einträge aus der obigen Liste aktiviert. Debugging-Nachrichten werden in die Datei Debug unter /var/spool/uucp eingetragen.

1.

Er ist auch im System Manager's Manual von 4.4BSD enthalten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

UUCP-Konfigurationsdateien Im Gegensatz zu einfacheren Datenübertragungsprogrammen wurde UUCP so konzipiert, daß es alle Übertragungen automatisch durchführen kann. Ist es einmal korrekt eingerichtet, ist ein tägliches Eingreifen des Administrators nicht mehr nötig. Die für automatischen Transfer benötigten Informationen werden in einer Reihe von Konfigurationsdateien festgehalten, die im Verzeichnis /usr/lib/uucp angesiedelt sind. Die meisten dieser Dateien werden nur beim Anwählen externer Hosts verwendet.

Eine sanfte Einführung in Taylor UUCP Die UUCP-Konfiguration als schwierig zu bezeichnen wäre eine Untertreibung. In der Tat ist sie eine haarige Angelegenheit, und das manchmal etwas kurz angebundene Format der Konfigurationsdateien macht die Dinge auch nicht gerade einfacher, obwohl das Taylor-Format im Vergleich zu den älteren Formaten von HDB oder Version 2 schon wesentlich leichter zu lesen ist. Um Ihnen ein Gefühl dafür zu vermitteln, wie diese Konfigurationsdateien zusammenwirken, wollen wir Ihnen die wichtigsten vorstellen und einen Blick auf einige beispielhafte Einträge in diesen Dateien werfen. Wir gehen hier nicht ins Detail; eine genauere Beschreibung wird in späteren, separaten Abschnitten gegeben. Wenn Sie UUCP auf Ihrer Maschine einrichten möchten, sollten Sie am besten auf einige Beispieldateien zurückgreifen und diese schrittweise an Ihre Bedürfnisse anpassen. Sie können dazu entweder auf die nachfolgend aufgeführten oder auf die in Ihrer Linux-Distribution enthaltenen Dateien zurückgreifen. Alle in diesem Abschnitt behandelten Dateien sind in /etc/uucp oder in einem Unterverzeichnis davon zu finden. Manche Linux-Distributionen enthalten UUCP-Binaries, die sowohl die HDB- als auch die Taylor-Konfiguration unterstützen, und verwenden verschiedene Unterverzeichnisse für den jeweiligen Satz von Konfigurationsdateien. Eine README-Datei finden Sie üblicherweise in /usr/lib/uucp. Damit UUCP ordnungsgemäß funktionieren kann, müssen die Dateien dem Benutzer uucp gehören. Einige davon enthalten Paßwörter und Telefonnummern und sollten daher die Zugriffsrechte 600 besitzen. Obwohl fast alle UUCP-Befehle auf Setuid uucp eingestellt sein müssen, gilt das auf gar keinen Fall für uuchk. Andernfalls könnten Benutzer sich die Systempaßwörter ansehen, auch wenn diese auf Zugriffsrecht 600 eingestellt sind. Die zentrale UUCP-Konfigurationsdatei ist /etc/uucp/config, die zum Setzen allgemeiner Parameter benutzt wird. Der

wichtigste (und vorerst einzige) davon ist der UUCP-Name Ihres Hosts. In der virtuellen Brauerei wird vstout als UUCPGateway benutzt: # /etc/uucp/config - Hauptkonfigurationsdatei für UUCP nodename

vstout

Die nächste wichtige Konfigurationsdatei ist sys. Sie enthält alle systemspezifischen Informationen zu Sites, mit denen Sie verbunden sind. Das beinhaltet den Namen der Site und Informationen zum Link selbst, beispielsweise die Telefonnummer bei einem Modem-Link. Ein typischer Eintrag für eine über Modem verbundene Site namens pablo würde wie folgt aussehen: # /usr/lib/uucp/sys - UUCP-Nachbarn benennen # System: pablo system pablo time Any phone 123456 port serial1 speed 38400 chat vstout ssword: lorca

ogin:

time gibt die Zeit an, in der das System angerufen werden kann. chat gibt die Login-Chat-Skripten an — die Sequenz von Strings, die ausgetauscht werden müssen, damit uucico sich in pablo einloggen kann. Auf Chat-Skripten kommen wir später noch zurück. Das Schlüsselwort port zeigt einfach auf einen Eintrag in der port-Datei (siehe Abbildung 16.1). Sie können jeden beliebigen Namen verwenden, solange er auf einen gültigen Eintrag in port verweist. Die port-Datei enthält die Link-spezifischen Informationen. Bei Modem-Links enthält sie die zu verwendende Gerätedatei, die unterstützten Geschwindigkeiten und die an der Schnittstelle angeschlossene Wähleinrichtung. Der nachfolgende Eintrag beschreibt /dev/ttyS1 (also COM 2), woran ein NakWell-Modem angeschlossen ist, das mit einer Geschwindigkeit von bis zu 38400 Bps betrieben werden kann. Der Name des Ports ist so gewählt, daß er mit dem Portnamen aus sys übereinstimmt. # /etc/uucp/port - UUCP-Ports # /dev/ttyS1 (COM2) port device /dev/ttyS1 speed 38400 dialer

serial1 type nakwell

modem

Die Informationen zur Wähleinrichtung (Dialer) werden in einer weiteren Datei namens — Sie ahnen es — dial festgehalten. Sie enthält für jeden Wähleinrichtungstyp grundsätzlich eine Reihe von Befehlen, die ausgeführt werden müssen, um eine Gegenstelle anzurufen, deren Telefonnummer angegeben wurde. Auch dies wird in Form eines Chat-Skripts spezifiziert. Der Eintrag für das NakWell-Modem könnte etwa so aussehen: # /etc/uucp/dial - Wähleinrichtungs-Informationen (je Wähleinrichtung) # NakWell-Modems dialer nakwell chat "" AT&F OK ATDT\T CONNECT

Die mit chat beginnende Zeile bestimmt den Modem-Chat, d.h. die Sequenz von Befehlen, die ans Modem geschickt und vom Modem empfangen wird, um es zu initialisieren und die gewünschte Nummer zu wählen. Die Sequenz \T wird dabei von uucico durch die Telefonnummer ersetzt. Damit Sie eine grobe Vorstellung davon bekommen, wie uucico mit diesen Konfigura-tionsdateien umgeht, stellen Sie sich vor, Sie geben folgenden Befehl ein: $ uucico -s pablo

Zuallererst sucht uucico in der Datei sys nach pablo. Aus dem sys-Eintrag für pablo ersieht es, daß es den Port serial1 verwenden soll, um die Verbindung aufzubauen. Aus der Datei port erfährt es, daß dies ein Modem-Port ist, an den ein NakWell-Modem angeschlossen ist. uucico durchsucht nun dial nach einem Eintrag, der das NakWell-Modem beschreibt. Nachdem dieser Eintrag gefunden wurde, wird aufgrund dieser Information die serielleSchnittstelle /dev/ttyS1 geöffnet und der Dialer-Chat ausgeführt, also AT&F gesendet, auf die Antwort OK gewartet usw. Wird der String \T erkannt, wird dieser durch die Telefonnummer (123456) ersetzt, die in der sys-Datei angegeben wurde. Sobald das Modem CONNECT zurückgeliefert hat, steht die Verbindung, und der Modem-Chat ist komplett. uucico kehrt nun zur sys-Datei zurück und führt den Login-Chat durch. In unserem Beispiel würde es zuerst auf den Prompt login: warten und den Benutzernamen (vstout) senden. Danach würde es auf den Prompt password: warten und das Paßwort (lorca) übertragen. Nach Abschluß der Autorisierung wird erwartet, daß die Gegenseite ihr eigenes uucico startet. Danach beginnen beide Seiten

mit der vorher beschriebenen Handshake-Phase. Abbildung 16.1 illustriert die Abhängigkeiten der Konfigurationsdateien untereinander. Abbildung 16.1: Zusammenspiel der Konfigurationsdateien bei Taylor UUCP

Was UUCP wissen muß Bevor Sie damit beginnen, die UUCP-Konfigurationsdateien zu schreiben, müssen Sie zuerst einige Informationen sammeln, die UUCP benötigt. Zuerst müssen Sie wissen, an welche serielle Schnittstelle Ihr Modem angeschlossen ist. Normalerweise sind die (DOS)Schnittstellen COM 1 bis COM 4 auf die Gerätedateien /dev/ttyS0 bis /dev/ttyS3 abgebildet. Einige Distributionen wie z.B. Slackware erzeugen einen Link namens /dev/modem, der auf die entsprechende ttyS*-Gerätedatei zeigt, und konfigurieren kermit, seyon und andere Kommunikationsprogramme so, daß diese Datei benutzt wird. In diesem Fall sollten Sie /dev/modem auch in Ihrer UUCP-Konfiguration verwenden. Der Grund für die Benutzung eines symbolischen Links liegt darin, daß alle Dialout-Programme die serielle Schnittstelle durch eine sogenannte Lock-Datei sperren, um zu signalisieren, daß sie benutzt wird. Die Namen dieser Lock-Dateien setzen sich aus dem String LCK.. und einem Gerätenamen zusammen, beispielsweise LCK..ttyS1. Wenn Programme für ein und dasselbe Gerät unterschiedliche Namen verwenden, werden die jeweils anderen Lock-Dateien von ihnen nicht erkannt. Folglich kommen sich diese Programme dann gegenseitig in die Quere, wenn sie zur selben Zeit gestartet werden. Dies ist gut möglich, wenn Sie Ihre UUCP-Aufrufe über crontab-Einträge abwickeln. Die Details zur Einrichtung Ihrer seriellen Schnittstellen entnehmen Sie bitte Kapitel 4 Konfiguration der seriellen Hardware. Als nächstes müssen Sie herausfinden, mit welcher Geschwindigkeit Ihr Modem und Linux kommunizieren. Diese Geschwindigkeit sollten Sie auf die höchstmögliche effektive Übertragungsrate einstellen. Die effektive Übertragungsrate kann dabei wesentlich höher sein als die eigentliche physikalische Übertragungsrate Ihres Modems. Beispielsweise senden und empfangen viele Modems Daten mit 56 Kbps. Durch die Verwendung von Komprimierungsprotokollen wie V.42bis kann die tatsächliche Übertragungsrate auf über 100 Kbps erhöht werden. Wenn UUCP überhaupt irgend etwas machen soll, müssen Sie natürlich auch die Telefonnummer eines Systems wissen, das angerufen werden soll. Außerdem benötigen Sie eine gültige Login-ID und eventuell ein Paßwort für diese Maschine.1

Sie müssen auch ganz genau wissen, wie Sie sich in das System einloggen. Müssen Sie die Return-Taste drücken, bevor der Login-Prompt erscheint? Wird login: oder user: angezeigt? Dies wird für die Erstellung des Chat-Skripts benötigt. Wenn Sie das nicht wissen, oder wenn der normale Chat fehlschlägt, versuchen Sie, das System mit einem Terminal-Programm wie kermit oder minicom anzurufen, und notieren Sie sich ganz genau, was Sie tun müssen.

Sites benennen Genau wie bei TCP/IP-basierten Netzwerken muß Ihr Host auch in UUCP-Netzen einenNamen besitzen. Solange Sie UUCP einfach nur zur Datenübertragung von und zu Sites verwenden wollen, die Sie direkt anwählen, oder in einem lokalen Netzwerk, muß dieser Name keinem Standard entsprechen.2 Wenn Sie UUCP dagegen für einen Mail- oder News-Link verwenden, sollten Sie darüber nachdenken, den Namen vom UUCP Mapping Project registrieren zu lassen.3 Das UUCP Mapping Project wird in Kapitel 17 Elektronische Post, besprochen. Selbst wenn Sie an einer Domain beteiligt sind, sollten Sie einen offiziellen UUCP-Namen für Ihre Site in Erwägung ziehen. Häufig wird der UUCP-Name so gewählt, daß er dem ersten Teil des voll qualifizierten Domainnamens entspricht. Ist die Domainadresse Ihrer Site etwa swim.twobirds.com, könnte der UUCP-Hostname swim lauten. Stellen Sie sich einfach vor, daß UUCP-Sites einander duzen. Natürlich können Sie auch einen UUCP-Namen verwenden, der mit Ihrem voll qualifizierten Domainnamen nichts zu tun hat. Achten Sie aber darauf, daß der unqualifizierte Site-Name nicht inMail-Adressen verwendet wird, wenn er nicht als Ihr offizieller UUCP-Name registriert ist. Im besten Fall landet eine Mail an einen nicht registrierten UUCP-Host irgendwo in einem großen schwarzen Sack. Wenn Sie einen Namen verwenden, der bereits von einem anderen Server registriert ist, wird die Mail an diese Site weitergeleitet und deren Postmaster -beträchtliche Kopfschmerzen bereiten. Standardmäßig verwendet das UUCP-Paket den über hostname gesetzten Namen als den UUCP-Namen der Site. Dieser Name wird normalerweise in den rc-Startskripten gesetzt und in der Regel in /etc/hostname gespeichert. Wenn sich Ihr UUCP-Name vom gesetzten Hostnamen unterscheidet, müssen Sie die Option hostname in der config-Datei benutzen, um uucico Ihren UUCP-Namen mitzuteilen. Dies wird nachfolgend beschrieben.

Taylor-Konfigurationsdateien Nun kehren wir wieder zu den Konfigurationsdateien zurück. Taylor UUCP erhält seine Informationen aus den folgenden Dateien: config Das ist die Haupt-Konfigurationsdatei. Hier können Sie den UUCP-Namen Ihrer Site definieren. sys Diese Datei beschreibt alle bekannten Sites. Jeder Eintrag spezifiziert den Namen, die Rufzeiten, die Rufnummer (falls vorhanden), den Gerätetyp der Site sowie Angaben zum Login. port Enthält Einträge, die jeden verfügbaren Port beschreiben, zusammen mit der unterstützten Übertragungsgeschwindigkeit und dem zu verwendenden Dialer. dial Beschreibt die zum Aufbau einer Telefonverbindung verwendeten Dialer. dialcode

Enthält Erweiterungen für symbolische Wählcodes. call Enthält den Login-Namen und das Paßwort, die beim Anruf eines Systems verwendet werden sollen. Wird selten benutzt. passwd Enthält Login-Namen und Paßwörter, die Systeme beim Einloggen benutzen könnten. Diese Datei wird nur verwendet, wenn uucico seine eigene Paßwortprüfung durchführt. Taylor-Konfigurationsdateien bestehen normalerweise aus Zeilen, die aus Schlüsselwort/Wert-Paaren bestehen. Das Doppelkreuz (#) leitet einen Kommentar ein, der bis zum Ende der Zeile reicht. Um ein Doppelkreuz in eigener Bedeutung zu verwenden, müssen Sie ihm einen Backslash voranstellen, z.B. \#. Es gibt eine ganze Reihe von Optionen, die Sie über die Konfigurationsdateien einstellen können. Wir können an dieser Stelle nicht alle Parameter besprechen, sondern wollen uns auf die wichtigsten beschränken. Danach sollten Sie in der Lage sein, einen modembasierten UUCP-Link zu konfigurieren. Weitere Abschnitte beschreiben dann die Modifikationen, die notwendig sind, wenn Sie UUCP über TCP/IP oder über eine direkte serielle Leitung verwenden wollen. Eine komplette Referenz finden Sie in den Texinfo-Dokumenten, die den Taylor UUCP-Quellen beiliegen. Wenn Sie glauben, Ihr UUCP-System vollständig konfiguriert zu haben, können Sie Ihre Konfiguration mit dem uuchk-Tool (zu finden in /usr/lib/uucp) überprüfen. uuchk liest Ihre Konfigurationsdateien und gibt eine detaillierte Liste mit den Konfigurationswerten für jedes System aus.

Allgemeine Konfigurationsoptionen — die config-Datei Für viel mehr als den UUCP-Hostnamen werden Sie diese Datei nicht benutzen. Standardmäßig benutzt UUCP den mit hostname besetzten Namen. Es ist aber grundsätzlich eine gute Idee, den UUCP-Namen hier explizit einzutragen. Nachfolgend eine config-Beispieldatei: # /usr/lib/uucp/config - UUCP-Haupt-Konfigurationsdatei hostname

vstout

Hier kann auch eine Reihe weiterer Parameter stehen, z.B. der Name des Spool-Verzeichnisses oder die Zugriffsrechte für “anonymous UUCP”. Letzteres wird noch in einem späteren Abschnitt beschrieben.

UUCP über andere Systeme informieren — die sys-Datei Die sys-Datei beschreibt die Systeme, die Ihrer Maschine bekannt sind. Ein Eintrag beginnt mit dem Schlüsselwort system und umfaßt alle Zeilen bis zur nächsten system-Direktive. Diese Zeilen beschreiben alle für diese Site spezifischen Parameter. Üblicherweise enthält ein Systemeintrag Parameter wie die Telefonnummer und den Login-Chat. Parameter, die vor der ersten system-Zeile stehen, setzen Standardwerte, die für alle Systeme gelten. Normalerweise enthält dieser Abschnitt solche Einträge wie allgemeine Protokollparameter. In den folgenden Abschnitten werden die wichtigsten Felder etwas detaillierter besprochen. Systemname Der Befehl system benennt das entfernte System. Sie müssen den richtigen Namen des Systems angeben und keinen erfundenen Alias, da uucico während des Logins diesen Namen mit dem vom entfernten System gelieferten Namen vergleicht.4

Jeder Systemname darf nur einmal vorkommen. Wenn Sie mehrere Konfigurationen für dasselbe System benutzen wollen (beispielsweise verschiedene Telefonnummern, die uucico nacheinander durchprobieren soll), können Sie Alternativen (alternates) beschreiben. Darauf gehen wir im Anschluß an die grundlegenden Konfigurationsoptionen ein. Telefonnummer Wird das entfernte System über eine Telefonleitung erreicht, enthält das Feld phone die vom Modem zu wählende Nummer. Sie kann verschiedene Platzhalter (Tokens) enthalten, die von uucico während der Wählprozedur interpretiert werden. Ein Gleichheitszeichen sorgt dafür, daß auf einen sekundären Wählton gewartet wird; ein Bindestrich sorgt für eine Pause von einer Sekunde. So kommen etwa einige Telefonanlagen ins Stocken, wenn zwischen einem speziellen Zugriffscode und der eigentlichen Telefonnummer nicht eine kurze Pause kommt.5 Aus Komfortgründen werden häufig Länder-Vorwahlnummern mit Namen statt Telefonnummern beschrieben. Die Datei dialcode ermöglicht es Ihnen, den Vorwahlnummern von Remote-Hosts Namen zuzuweisen, die Sie dann für die Einwahl benutzen können. Nehmen wir mal an, Sie hätten die folgende dialcode-Datei: # /usr/lib/uucp/dialcode - Übersetzung von Vorwahlnummern Bogoham 035119

024881 Coxton

Mit solchen Eintragungen können Sie Telefonnummern wie Bogoham7732 in der sys-Datei verwenden, was die ganze Sache vielleicht etwas leserlicher macht. Vor allem fällt Ihnen ein Update leichter, wenn sich die Vorwahlnummer von Bogoham mal ändern sollte. port und speed Die Optionen port und speed werden benutzt, um zu bestimmen, welches Gerät für die Verbindung zum anderen System verwendet werden soll und mit welcher Geschwindigkeit die Daten über dieses Gerät übertragen werden sollen.6 Ein systemEintrag kann jeweils eine der beiden Optionen oder beide zusammen enthalten. Wenn in der port-Datei nach einem passenden Eintrag gesucht wird, kommen nur die Ports in Frage, die den passenden Portnamen und/oder die passende Geschwindigkeit haben. Normalerweise sollte die Option speed ausreichen. Wenn Sie nur ein serielles Gerät in port definiert haben, wird uucico sowieso immer die richtige Wahl treffen, d.h., es genügt, wenn Sie die gewünschte Geschwindigkeit angeben. Selbst wenn Sie mehrere Modems an Ihrem System hängen haben, werden Sie häufig den Ports keinen Namen zuweisen. Wenn nämlich uucico mehrere passende Einträge findet, probiert es jedes Gerät der Reihe nach durch, bis es ein unbenutztes gefunden hat. Der Login-Chat Das Login-Chat-Skript, das uucico mitteilt, wie es sich in das entfernte System einzuloggen hat, haben wir ja bereits kennengelernt. Es setzt sich aus einer Reihe von Strings zusammen, die vom lokalen uucico-Prozeß erwartet und übertragen werden. uucico wartet so lange, bis die entfernte Maschine einen Login-Prompt sendet, und überträgt dann den Login-Namen. Danach wird auf den Paßwort-Prompt gewartet und das Paßwort übertragen. Die erwarteten und zu sendenden Strings werden abwechselnd angegeben. uucico hängt automatisch ein Wagenrücklaufzeichen (\r) an jeden zu sendenden String an. Ein einfaches Chat-Skript könnte etwa wie folgt aussehen: ogin: vstout ssword: catch22

Ihnen wird aufgefallen sein, daß die Felder mit den erwarteten Strings nicht den ganzen Prompt enthalten. Auf diese Weise wird garantiert, daß das Login auch dann erfolgreich ist, wenn das entfernte System die Meldung Login: anstelle von login: ausgibt. Wenn der erwartete oder zu sendende String Leerzeichen oder sonstige Whitespace-Zeichen enthält, müssen Sie ihn in Anführungszeichen setzen. uucico gestattet auch eine Art bedingter Ausführung, z.B. wenn der getty der entfernten Maschine zuerst zurückgesetzt werden muß, bevor ein Prompt gesendet wird. Zu diesem Zweck können Sie einen “Unter-Chat” an den erwarteten String anhängen, der durch einen Bindestrich abgesetzt wird. Der Unter-Chat wird nur ausgeführt, wenn der Haupt-Chat fehlschlägt, etwa durch einen Timeout-Fehler. Eine Möglichkeit, dieses Feature zu benutzen, besteht darin, einen BREAK an die entfernte Site zu

schicken, wenn kein Login-Prompt erscheint. Das folgende Beispiel ist ein universelles Chat-Skript, das auch dann funktionieren sollte, wenn zuerst die Return-Taste gedrückt werden muß, bevor das Login erscheint. Das erste leere Argument ("") weist UUCP an, nicht erst auf irgend etwas zu warten, sondern den nachfolgenden String direkt zu senden. "" \n\r\d\r\n\c ogin:-BREAK-ogin: vstout ssword: catch22

In einem Chat-Skript können eine ganze Reihe von speziellen Strings und Escape-Zeichen vorkommen. Nachfolgend ist ein Teil der Sonderzeichen aufgeführt, die in dem zu erwartenden String vorkommen können: "" Der leere String. Er weist uucico an, nicht auf einen String zu warten, sondern direkt mit dem Senden des nachfolgenden Strings fortzufahren. \t Tabulatorzeichen. \r Wagenrücklauf (Carriage Return). \s Leerzeichen (Space). Notwendig, um Leerzeichen in Chat-Strings einzubetten. \n Zeilenvorschub (Newline). \\ Umgekehrter Schrägstrich (Backslash). Bei zu sendenden Strings können Sie zusätzlich zu den obigen noch die folgenden Escape-Zeichen und -Strings verwenden: EOT Zeichen für das Ende der Übertragung (“End of Transmission”, ^D). BREAK Unterbrechungszeichen (Break). \c Unterdrückt die Übertragung eines Wagenrücklaufzeichens am Ende des Strings. \d Verzögert das Senden um eine Sekunde. \E Aktiviert die Überprüfung des Echos. In diesem Fall muß uucico darauf warten, daß alles, was es an die Gegenseite

geschickt hat, auch zurückgeschickt wird, bevor es im Chat-Skript weitergeht. Hauptsächlich bei Modem-Chats sinnvoll (denen wir später noch begegnen werden). Standardmäßig ist die Echoprüfung ausgeschaltet. \e Deaktiviert die Echoprüfung. \K Wie BREAK. \p Pause für einen Sekundenbruchteil. Alternativen (Alternates) Manchmal ist es wünschenswert, für ein System mehrere Einträge zu haben, beispielsweise wenn das System übermehrere Telefonnummern erreicht werden kann. Bei Taylor UUCP ist dies durch die Definition sogenannter Alternativen (Alternates) möglich. Eine Alternative übernimmt alle Einstellungen vom Haupteintrag und gibt nur solche Werte an, die überschrieben oder dem Haupteintrag hinzugefügt werden sollen. Eine Alternative ist vom Systemeintrag durch eine Zeile mit dem Schlüsselwort alternate abgesetzt. Wenn Sie zwei Telefonnummern für pablo benutzen wollen, können Sie den entsprechenden sys-Eintrag folgendermaßen verändern: system

pablo phone

123456 ... Einträge wie oben... alternate phone

123455

Für einen Anruf von pablo verwendet uucico zuerst die Nummer 123456. Schlägt dies fehl, versucht es die Alternative. Der alternative Eintrag behält alle Einstellungen des Haupteintrags bei und überschreibt nur die Telefonnummer. Einschränkung der Rufzeiten Taylor UUCP bietet eine ganze Reihe von Möglichkeiten, die Zeiten einzuschränken, in denen Anrufe zum entfernten Rechner durchgeführt werden können. Dies könnte notwendig sein, wenn ein Host seine Dienste zu bestimmten Zeiten einschränkt. Sie können so aber auch Zeiten ausschließen, in denen die Telefongebühren relativ hoch sind. Rufzeiteinschränkungen können jedoch immer überschrieben werden, indem Sie uucico mit den Optionen –S oder –f aufrufen. Standardmäßig unterbindet Taylor UUCP den Verbindungsaufbau zu allen Zeiten, d.h., Sie müssen Zeitangaben in irgendeiner Form in Ihre sys-Datei aufnehmen. Wenn Zeitbeschränkungen für Sie kein Thema sind, können Sie in der sys-Datei die Option time mit dem Wert Any belegen. Den einfachsten Weg, die Rufzeit einzuschränken, bietet der Eintrag time, dem ein String folgt, der aus einem Tag- und einem Zeit-Feld besteht. Das Tag-Feld kann eine Kombination aus Mo, Tu, We, Th, Fr, Sa, Su oder den Schlüsselwörtern Any, Never oder Wk (für Werktags) enthalten. Das Zeit-Feld besteht aus zwei Werten im 24-Stunden-Format, die durch einen Bindestrich voneinander getrennt sind. Sie bestimmen den Zeitraum, in dem Anrufe durchgeführt werden können. Kombinationen dieser Strings werden immer ohne Leerzeichen angegeben. Mehrere Datum- und Zeitspezifikationen können durch Kommata zusammengefaßt werden, wie das folgende Beispiel zeigt: time

MoWe0300-0730,Fr1805-2200

Dieses Beispiel erlaubt Anrufe Montags und Mittwochs von 3 Uhr bis 7:30 Uhr morgens und Freitags zwischen 6:05 Uhr und 22 Uhr. Überschreitet eine Zeitangabe die Mitternachtsgrenze, z.B. Mo1830-0600, wird dies als Montag zwischen Mitternacht

und 6 Uhr morgens sowie zwischen 18:30 und Mitternacht interpretiert. Die speziellen Zeit-Strings Any und Never tun genau, was Sie von ihnen erwarten: Anrufe können zu beliebigen Zeiten bzw. überhaupt nicht getätigt werden. Taylor UUCP kennt auch eine Reihe spezieller Kürzel, die Sie in Zeitangaben verwenden können, zum Beispiel NonPeak und Night, die Abkürzungen für Any2300-0800,SaSu0800-1700 und Any1800-0700,SaSu darstellen. Dem Befehl time kann optional ein zweites Argument folgen, das die Wahlwiederholung in Minuten enthält. Schlägt ein Verbindungsversuch fehl, verhindert uucico für einen bestimmten Zeitraum eine erneute Anwahl des entfernten Hosts. Legen Sie etwa ein Wiederholungsintervall von 5 Minuten fest, verweigert uucico nach dem letzten Fehler den Anruf des entfernten Hosts für die Dauer von 5 Minuten. Standardmäßig arbeitet uucico mit einem Schema, bei dem sich das Wiederholungsintervall mit jedem Fehlversuch exponentiell erhöht. Mit dem Befehl timegrade können Sie die maximale Spool-Klasse für einen Zeitplan festlegen. Nehmen wir an, Sie hätten die folgenden timegrade-Befehle in einen system-Eintrag aufgenommen: timegrade

N Wk1900-0700,SaSu timegrade

C Any

Auf diese Weise können Jobs mit einer Spool-Klasse von C oder höher (üblicherweise hat Mail die Klasse B oder C) bei jedem Anruf übertragen werden. News (üblicherweise Klasse N) dagegen werden nur nachts und an Wochenenden übertragen. Genau wie time akzeptiert auch timegrade ein Wiederholungsintervall in Minuten als optionales drittes Argument. Hier ist jedoch ein warnendes Wort zu den Spool-Klassen angebracht. Zuerst einmal gilt die Option timegrade nur für das, was Ihr System überträgt. Die Gegenseite kann immer noch alles übertragen, was sie will. Sie können die Option call-timegrade verwenden, um das andere System aufzufordern, nur Jobs ab einer bestimmten Klasse zu übertragen. Es garantiert Ihnen aber niemand, daß der andere Host sich tatsächlich daran hält.7 Außerdem wird das Feld timegrade nicht überprüft, wenn sich ein entferntes System bei Ihnen einwählt, d.h., alle aufgelaufenen Jobs für dieses System werden übertragen. Jedoch kann das andere System Ihr uucico explizit auffordern, sich auf eine bestimmte Spool-Klasse zu beschränken.

Verfügbare Geräte — die port-Datei Die Datei port klärt uucico über die vorhandenen Ports auf. Dabei kann es sich um Modem-Ports handeln, aber auch andere Arten wie direkte serielle Leitungen und TCP-Sockets werden unterstützt. Genau wie die sys-Datei besteht auch port aus separaten Einträgen, die mit dem Schlüsselwort port beginnen, dem der Portname folgt. Dieser Name kann im port-Befehl der sys-Datei genutzt werden. Der Name muß nicht eindeutig sein. Existieren verschiedene Ports mit demselben Namen, probiert uucico jeden einzelnen, bis es einen findet, der momentan nicht benutzt wird. Dem port-Befehl sollte unmittelbar der type-Befehl folgen, der anzeigt, welche Art von Port beschrieben wird. Gültige Typen sind modem, direct für direkte Verbindungen und tcp für TCP-Sockets. Fehlt der port-Befehl, ist der Porttyp auf Modem voreingestellt. In diesem Abschnitt werden nur Modem-Ports behandelt; TCP-Ports und direkte Leitungen werden in einem späteren Abschnitt besprochen. Bei Modems und direkten Ports müssen Sie das Gerät angeben, über das “nach draußen” gewählt wird. Dazu dient der Befehl device. Üblicherweise handelt es sich dabei um eine spezielle Gerätedatei im /dev-Verzeichnis, wie etwa /dev/ttyS1. Im Fall eines Modems bestimmt der Porteintrag auch, welche Art von Modem an den Port angeschlossen ist. Unterschiedliche Modems müssen auch verschieden konfiguriert werden. Selbst angeblich Hayes-kompatible Modems müssen nicht wirklich

untereinander kompatibel sein. Darum müssen Sie uucico mitteilen, wie das Modem zu initialisieren ist und wie es die gewünschte Nummer wählen soll. Taylor UUCP bewahrt die Beschreibungen aller Dialer in einer Datei namens dial auf. Soll eine dieser Beschreibungen verwendet werden, müssen Sie den Namen des Dialers mit dem Befehl dialer angeben. Manchmal möchten Sie ein Modem auch auf verschiedene Arten einsetzen, je nachdem, welches System Sie anrufen. So verstehen es beispielsweise einige ältere Modems nicht, wenn ein Highspeed-Modem versucht, eine Verbindung mit 56 Kbps aufzubauen; sie hängen einfach auf, anstatt die Verbindung mit einer Geschwindigkeit von 9.600 Bps aufzubauen. Wenn Sie wissen, daß die Site drop ein solch einfaches Modem benutzt, müssen Sie Ihr Modem anders einstellen, wenn Sie die Site anwählen. Dazu müssen Sie einen zusätzlichen Porteintrag in Ihrer port-Datei angeben, der einen anderen Dialer benutzt. Jetzt können Sie dem neuen Port einen anderen Namen, wie etwa serial1-slow, geben und die port-Direktive im drop-Systemeintrag in sys verwenden. Eine bessere Möglichkeit besteht darin, die Ports anhand der von ihnen unterstützten Geschwindigkeiten zu unterscheiden. Die beiden Porteinträge für die eben beschriebene Situation könnten dann wie folgt aussehen: # NakWell-Modem; Highspeed-Verbindungen port serial1 # Portname type modem # Modem-Port device /dev/ttyS1 # COM2 speed 115200 # unterstützte Geschwindigkeit dialer nakwell # normaler Dialer # NakWell-Modem; langsame Verbindung port serial1 # Portname type modem # Modem-Port device /dev/ttyS1 # COM2 speed 9600 # unterstützte Geschwindigkeit dialer nakwell-slow # hohe Geschwindigkeit gar nicht erst versuchen

Der Systemeintrag für drop würde nun serial1 als Portnamen enthalten, aber nur eine Geschwindigkeit von 9.600 Bps erlauben. uucico würde dann automatisch den zweiten Porteintrag benutzen. Für alle anderen Sites, die eine Geschwindigkeit von 115.200 Bps in ihrem Systemeintrag angeben, würde weiterhin der erste Porteintrag verwendet werden. Standardmäßig wird der erste Eintrag mit passender Geschwindigkeit benutzt.

Wie eine Nummer gewählt wird — die dial-Datei Die Datei dial beschreibt, wie die verschiedenen Dialer verwendet werden. Traditionell spricht man bei UUCP von Dialern und nicht von Modems, weil es früher gängige Praxis war, daß eine (teure) automatische Wähleinrichtung für eine ganze Reihe von Modems genutzt wurde. Heutzutage verfügen die meisten Modems über eingebaute Wahlunterstützung, d.h., diese Unterscheidung ist ein wenig überholt. Dessen ungeachtet können verschiedene Dialer oder Modems auch verschiedene Konfigurationen benötigen. Diese können Sie in der Datei dial beschreiben. Einträge in dial beginnen mit dem Befehl dialer, der den Namen des Dialers festlegt. Der wichtigste Eintrag neben dialer ist der Modem-Chat, der über den Befehl chat spezifiziert wird. Genau wie beim LoginChat besteht er aus einer Reihe von Strings, die uucico an den Dialer sendet, und den Antworten, die er daraufhin erwartet. Dieser Befehl wird normalerweise verwendet, um das Modem in einen definierten Zustand zurückzusetzen und die gewünschte Nummer zu wählen. Der folgende dialer-Eintrag zeigt einen typischen Modem-Chat für ein Hayes-kompatibles Modem: # NakWell-Modem; Highspeed-Verbindung dialer "" AT&F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT chat-fail NO\sCARRIER dtr-toggle true

nakwell # Dialer-Name chat BUSY chat-fail ERROR chat-fail

Der Modem-Chat beginnt mit "", dem “leeren” String. uucico sendet also direkt den Befehl AT&F an das Modem. AT&F ist der Hayes-Befehl zum Rücksetzen des Modems. Nun wartet uucico, bis das Modem OK zurückschickt, und setzt dann den nächsten Befehl ab, der das lokale Echo ausschaltet usw. Nachdem das Modem wieder mit OK antwortet, sendet uucico den Wählbefehl ATDT. Die Escape-Sequenz \T wird dabei durch die Telefonnummer ersetzt, die im Systemeintrag der sys-Datei gefunden wurde. uucico wartet dann darauf, daß das Modem die Zeichenkette CONNECT zurückschickt, was signalisiert, daß die Verbindung mit dem entfernten Modem erfolgreich aufgebaut werden konnte. Natürlich passiert es auch, daß die Verbindung mit dem entfernten System nicht zustande kommt, beispielsweise, weil das andere System gerade mit jemand anderem kommuniziert und die Leitung besetzt ist. In einem solchen Fall gibt das Modem eine entsprechende Fehlermeldung zurück. Modem-Chats sind nicht in der Lage, solche Meldungen aufzuspüren; uucico

wartet weiter auf den erwarteten String, bis ein Timeout erfolgt. In der UUCP-Logdatei erscheint daher nur die nichtssagende Meldung “timed out in chat script” und nicht die eigentliche Fehlerursache. Bei Taylor UUCP können Sie aber uucico über diese Fehlermeldungen informieren, indem Sie den Befehl chat-fail wie oben gezeigt verwenden. Erkennt uucico einen chat-fail-String während der Ausführung des Modem-Chats, bricht es den Anruf ab und speichert die Fehlermeldung in der UUCP-Logdatei. Der letzte Befehl im obigen Beispiel weist UUCP an, den Zustand der Steuerleitung DTR (Data Terminal Ready) umzuschalten, bevor der Modem-Chat beginnt. Normalerweise aktiviert der serielle Treiber DTR, wenn ein Prozeß das Gerät öffnet, um dem angeschlossenen Modem mitzuteilen, daß jemand mit ihm reden möchte. Mit dtr-toggle setzen Sie DTR für kurze Zeit auf Low und dann wieder auf High. Viele Modems können so konfiguriert werden, daß sie beim Heruntersetzen von DTR auflegen, in den Befehlsmodus gehen oder sich selbst zurücksetzen.8

UUCP über TCP So absurd es auch klingen mag, so ist die Verwendung von UUCP zur Datenübertragung über TCP keine so schlechte Idee, besonders wenn große Datenmengen wie Usenet-News übertragen werden sollen. In TCP-basierten Verbindungen werden News im allgemeinen über das NNTP-Protokoll übertragen, womit Artikel individuell ohne Komprimierung und andere Optimierungen angefordert und übertragen werden. Wenn dies für große Sites mit mehreren simultanen Newsfeeds auch angemessen sein mag, so ist dies für kleinere Sites mit langsameren Verbindungen wie z.B. ISDN doch sehr unvorteilhaft. Diese Sites werden im allgemeinen die Qualitäten von TCP mit den Vorteilen verknüpfen wollen, News in großen Paketen zu verschicken, die komprimiert und so mit sehr geringem Overhead übertragen werden können. Eine Standardlösung, um solche Batches zu übertragen, besteht in der Verwendung von UUCP über TCP. In sys würden Sie ein System, das über TCP angerufen wird, wie folgt beschreiben: system chat

gmu address news.groucho.edu time ogin: vstout word: clouseau

Any port

tcp-conn

Der Befehl address ermittelt die IP-Adresse des Hosts oder seinen voll qualifizierten Domainnamen. Der entsprechende portEintrag liest sich wie folgt: port

tcp-conn type

tcp service

540

Der Eintrag legt fest, daß eine TCP-Verbindung verwendet werden soll, wenn ein sys-Eintrag auf tcp-conn Bezug nimmt. Außerdem soll uucico versuchen, die Verbindung mit dem entfernten Host über den TCP-Netzwerk-Port 540 herzustellen. Das ist die Standardportnummer des UUCP-Dienstes. Anstelle der Portnummer können Sie auch einen symbolischen Portnamen an den service-Befehl übergeben. Die zu diesem Namen passende Portnummer wird in der Datei /etc/services nachgeschlagen. Der für den UUCP-Dienst übliche Name lautet uucpd.

Verwendung einer direkten Verbindung Stellen Sie sich vor, Sie verwenden eine Direktleitung von Ihrem System vstout zum System tiny. Genau wie bei einem Modem müssen Sie einen entsprechenden System-eintrag in Ihre sys-Datei aufnehmen. Der Befehl port gibt dabei den seriellen Port an, über den tiny angesprochen wird. system tiny time ogin: cathcart word: catch22

Any port

direct1 speed

38400 chat

In der port-Datei müssen Sie den seriellen Port für diese direkte Verbindung beschreiben. Ein dialer-Eintrag ist nicht nötig, da zum Wählen ja keine Veranlassung besteht. port

direct1 type

direct speed

38400 device

/dev/ttyS1

1.

Wenn Sie UUCP einfach nur mal ausprobieren wollen, erkundigen Sie sich nach einer Telefonnummer zu einer Archiv-Site in Ihrer Nähe. Schreiben Sie sich den Login-Namen und das Paßwort auf — sie sind öffentlich, um anonyme Downloads zu ermöglichen. In den meisten Fällen lauten sie etwa uucp/uucp oder nuucp/uucp.

2.

Die einzige Einschränkung ist, daß der Name nicht länger als sieben Zeichen sein sollte. Das ist notwendig, damit UUCPImplementierungen, die auf Betriebssystemen laufen, deren Dateinamen eine bestimmte Maximallänge nicht überschreiten dürfen, nicht irritiert werden. Namen, die mehr als sieben Zeichen enthalten, werden von UUCP häufig gekappt. Einige Versionen begrenzen die Namenslänge sogar auf sechs Zeichen.

3.

Das UUCP Mapping Project registriert alle UUCP-Hostnamen weltweit und sorgt dafür, daß sie eindeutig sind.

4.

Ältere UUCPs der Version 2 geben ihren Namen nicht bekannt, wenn sie aufgerufen werden; das tun häufig nur neuere Implementierungen sowie Taylor UUCP.

5.

So verlangen die meisten firmeneigenen Telefonanlagen die Ziffern 0 oder 9 für die Durchwahl nach außen.

6.

Die Transferrate der tty-Schnittstelle muß mindestens so hoch wie die maximale Übertragungsgeschwindigkeit sein.

7.

Nur bei Taylor UUCP hält sich das Remote-System daran.

8.

Manche Modems scheinen das aber überhaupt nicht zu mögen und hängen sich gelegentlich auf.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wer darf was bei UUCP — Zugriffsrechte bestimmen UUCP ist ein ziemlich flexibles System. Die Flexibilität erfordert allerdings eine sorgfältige Zugriffskontrolle über die Features, um Mißbrauch zu verhindern, egal ob beabsichtigt oder nicht. Die Hauptsorge des UUCP-Administrators betrifft dabei die ferne Befehlsausführung, Dateitransfers und Forwarding. Bei Taylor UUCP sind die Möglichkeiten zum Zugriff auf diese Features für ferne UUCP-Hosts eingeschränkt. Durch sorgfältige Auswahl der Zugriffsrechte kann der UUCPAdministrator sicherstellen, daß die Sicherheit des Hosts erhalten bleibt.

Befehlsausführung Die Aufgabe von UUCP besteht darin, Dateien von einem System auf ein anderes zu kopieren sowie die Ausführung bestimmter Befehle auf dem entfernten Host anzufordern. Natürlich wollen Sie als Administrator kontrollieren, welche Rechte Sie anderen Systemen einräumen — die Ausführung völlig beliebiger Befehle auf Ihrem System ist definitiv keine gute Idee. Standardmäßig erlaubt Taylor UUCP anderen Systemen nur die Ausführung von rmail und rnews auf Ihrem Rechner. Diese Programme werden häufig für den Austausch von E-Mail und Usenet-News über UUCP verwendet. Um die Menge der Befehle für ein bestimmtes System zu ändern, benutzen Sie in der sys-Datei das Wort commands. Genauso können Sie den Suchpfad auf die Verzeichnisse der ausführbaren Befehle einschränken. Den Suchpfad, den Sie für einen Remote-Host vorsehen möchten, können Sie mit dem Befehl command-path einstellen. Wenn Sie zum Beispiel pablo gestatten wollen, außer den Kommandos rmail und rnews auch den Befehl bsmtp auszuführen, geben Sie folgendes ein:1 system

pablo ... commands

rmail rnews bsmtp

Dateitransfer Taylor UUCP ermöglicht es Ihnen auch, den Dateitransfer bis ins kleinste Detail zu regeln. Im Extremfall können Sie den Transfer von und zu einem bestimmten System völlig unterbinden. Setzen Sie einfach request auf no, und das entfernte System wird nicht mehr in der Lage sein, Dateien von Ihrem System herunterzuladen oder auf Ihr System zu übertragen. Auf dieselbe Weise können Sie verhindern, daß die Benutzer Ihres Systems Dateien von bzw. zu Ihrem System übertragen, indem Sie transfer auf no setzen. Standardmäßig dürfen die Benutzer des lokalen und des entfernten Systems Dateien hoch- und herunterladen. Zusätzlich können Sie die Verzeichnisse konfigurieren, von denen bzw. in die Dateien kopiert werden dürfen. Üblicherweise

werden Sie den Zugriff für andere Systeme auf eine bestimmte Verzeichnishierarchie beschränken wollen, aber gleichzeitig den lokalen Benutzern erlauben, Dateien aus ihrem Home-Verzeichnis zu übertragen. Häufig dürfen die Benutzer anderer Systeme nur Dateien übertragen, die sich im öffentlichen UUCP-Verzeichnis /var/spool/uucppublic befinden. Dies ist der traditionelle Ort, an dem Dateien öffentlich zugänglich gemacht werden, ähnlich wie bei FTP-Servern im Internet.2 Taylor UUCP bietet vier verschiedene Befehle zur Konfiguration der Verzeichnisse, aus denen und in die Dateien kopiert werden dürfen. Diese sind: local-send, das eine Liste mit Verzeichnissen angibt, aus denen ein Benutzer Dateien senden darf; local-receive, das die Liste der Verzeichnisse enthält, in die ein Benutzer Dateien kopieren darf. Dazu kommen remote-send und remote-receive, die dieselbe Aufgabe für Anforderungen von einem entfernten System übernehmen. Sehen wir uns das folgende Beispiel an: system pablo ... local-send !~/incoming !~/receive remote-receive

/home ~ local-receive ~/incoming

/home ~/receive remote-send

~

Der Eintrag local-send erlaubt es den Benutzern Ihres Hosts, Dateien unter /home und aus dem öffentlichen UUCPVerzeichnis an pablo zu übertragen. Der Befehl local-receive erlaubt es den Benutzern, Dateien im allgemein schreibbaren Verzeichnis receive unter uucppublic oder in jedem allgemein schreibbaren Verzeichnis unter /home zu empfangen. Der Befehl remote-send erlaubt es pablo, Dateien aus /var/spool/uucppublic anzuforden, mit Ausnahme der Dateien aus den Verzeichnissen incoming und receive. Die Ausnahmen erkennt uucico an den Ausrufezeichen vor den Verzeichnisnamen. Die letzte Zeile erlaubt es pablo schließlich, Dateien in incoming abzulegen. Das Hauptproblem beim Dateitransfer mit UUCP ist, daß es Dateien nur in Verzeichnissen ablegt, in die allgemein geschrieben werden kann. Dies könnte Benutzer in Versuchung führen, anderen Benutzern Fallen zu stellen usw. Leider gibt es für dieses Problem keine Lösung, es sei denn, Sie verbieten den Dateitransfer unter UUCP ganz.

Weiterleitung (Forwarding) UUCP bietet einen Mechanismus, mit dem andere Systeme Dateitransfers in Ihrem Namen erledigen. Angenommen, Ihr System hätte uucp-Zugriff auf das System seci, aber nicht zum System uchile. Die folgende Anweisung würde es Ihnen ermöglichen, mit seci eine Datei von uchile herunterzuladen und anschließend auf Ihr System zu übertragen. $ uucp -r seci!uchile!~/find-ls.gz ~/uchile.files.gz

Das Verfahren, einen Job durch mehrere Systeme hindurchzureichen, wird Forwarding (Weiterleitung) genannt. Wenn Sie ein UUCP-System betreiben, werden Sie diesen Forwarding-Dienst auf einige wenige Hosts beschränken wollen, bei denen Sie sicher sind, daß sie keine horrende Telefonrechnung auflaufen lassen, indem sie zum Beispiel Ihren Host zum Download der neuesten X11R6-Source-Release benutzen. Standardmäßig ist bei Taylor UUCP das Forwarding komplett deaktiviert. Um Forwarding für ein bestimmtes System zu aktivieren, können Sie den Befehl forward verwenden. Dieser Befehl spezifiziert eine Liste von Sites, von und zu denen das System Jobs weiterleiten kann. Der UUCP-Administrator von seci müßte beispielsweise die folgenden Zeilen in seine sysDatei aufnehmen, um pablo die Anforderung von Dateien von uchile zu gestatten: #################### # pablo system pablo ... forward # uchile system uchile ... forward-to pablo

uchile ####################

Der Eintrag forward-to für uchile ist notwendig, damit die von ihm gelieferten Dateien auch wirklich an pablo weitergeleitet werden. Andernfalls würde UUCP sie einfach aussortieren. Dieser Eintrag benutzt eine Variante des forward-Befehls, der uchile nur das Senden von Dateien an pablo über seci erlaubt, aber nicht andersherum. Um das Forwarding für jedes System zu erlauben, müssen Sie das spezielle Schlüsselwort ANY (in Großbuchstaben!) benutzen.

1.

bsmtp wird verwendet, um Mails mit Batch-betriebenem SMTP zu versenden.

2.

Auf dieses Verzeichnis bezieht man sich im allgemeinen mit dem Tilde-Zeichen (~) — jedoch nur in UUCPKonfigurationsdateien. Außerhalb davon ist damit im allgemeinen das Home-Verzeichnis des Benutzers gemeint.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Das Einwählen in Ihr System einrichten Wenn Sie Ihre Site so einrichten wollen, daß sich jemand einwählen kann, müssen Sie Logins auf Ihrem seriellen Port erlauben und einige Systemdateien so anpassen, daß sie UUCP-Accounts enthalten. Wie dies genau funktioniert, ist Thema dieses Abschnitts.

UUCP-Accounts einrichten Als nächstes müssen Sie Benutzer-Accounts einrichten, über die sich andere Sites in Ihr System einloggen und eine UUCPVerbindung aufbauen können. Üblicherweise vergeben Sie für jedes System einen eigenen Login-Namen. Wenn Sie einen Account für das System pablo einrichten, könnten Sie ihm beispielsweise den Benutzernamen Upablo geben. Für die Wahl der Benutzernamen gibt es keine besonderen Richtlinien; es ist jedoch empfehlenswert, Namen auszuwählen, die dem Namen des Remote-Hosts ähneln. Bei Systemen, die sich über eine serielle Schnittstelle einwählen, müssen Sie diesen Account üblicherweise in die Paßwortdatei des Systems (/etc/passwd) aufnehmen. Sie sind sicher nicht schlecht beraten, wenn Sie alle UUCP-Logins in einer speziellen Gruppe wie uuguest aufnehmen. Das Home-Verzeichnis des Accounts sollte dabei auf das öffentliche Spool-Verzeichnis /var/spool/uucppublic zeigen. Als Login-Shell muß uucico verwendet werden. Um UUCP-Systeme zu bedienen, die sich über TCP mit Ihrem Server verbinden, müssen Sie inetd so einrichten, daß es die auf dem uucp-Port eingehenden Verbindungen verwaltet. Dies geschieht durch Einfügen der folgenden Zeile in Ihre /etc/inetd.conf:1 uucp

stream

tcp

nowait

root

/usr/sbin/tcpd

/usr/lib/uucp/uucico -l

Durch die Option –l führt uucico seine eigene Login-Autorisierung durch. Genau wie beim normalen login-Programm wird auch hier nach dem Login und dem Paßwort gefragt, zur Verifizierung wird aber eine private Paßwortdatei anstelle von /etc/passwd benutzt. Diese private Paßwortdatei heißt /etc/uucp/passwd und enthält Paare von Login-Namen und Paßwörtern: Upablo

IslaNegra Ulorca

co'rdoba

Diese Datei muß uucp gehören und die Rechte 600 besitzen. Macht diese Datei auf Sie einen so guten Eindruck,daß Sie sie auch für Ihre normalen seriellen Logins verwenden wollen? Nun, in manchen Fällen ist das tatsächlich machbar. Was Sie dafür benötigen, ist ein getty-Programm, das Sie dazu bringen, für Ihre UUCP-Benutzer uucico anstelle des normalen /bin/login zu starten.2 Der Aufruf von uucico sähe dann so aus: /usr/lib/uucp/uucico -l -u user

Die Option –u weist es an, den angegebenen Benutzernamen zu verwenden, anstatt danach zu fragen.3 Um Ihre UUCP-Benutzer vor Anrufern zu schützen, die einen falschen Systemnamen angeben und sich deren gesamte Mail ansehen, sollten Sie called-login-Befehle in jeden Systemeintrag in Ihrer sys-Datei aufnehmen. Dies ist im nächsten Abschnitt beschrieben.

Wie Sie sich vor Betrügern schützen Ein Hauptproblem von UUCP besteht darin, daß das anrufende System bei der Angabe seines Namens lügen kann. Es gibt seinen Namen zwar nach dem Login bekannt, aber der Server hat keine Möglichkeit, diesen zu überprüfen. Der Eindringling könnte sich also unter seinem eigenen UUCP-Account einloggen und anschließend vorgaukeln, jemand anders zu sein, um sich die Mail der anderen Site anzueignen. Dies ist besonders folgenreich, wenn Sie Logins via Anonymous UUCP anbieten, wo die Paßwörter öffentlich gemacht werden. Gegen diese Art von Eindringlingen müssen Sie sich schützen. Das Mittel gegen diese Seuche besteht darin, von jedem System einen bestimmten Login-Namen zu erwarten. Dieser wird durch den Befehl called-login in sys spezifiziert. Ein solcher Systemeintrag könnte etwa wie folgt aussehen: system

pablo ... usual options ... called-login

Upablo

Das Ergebnis ist, daß jedesmal, wenn ein System sich einloggt und vorgibt, pablo zu sein, uucico prüft, ob es sich unter Upablo eingeloggt hat. Wenn nicht, wird das anrufende System abgewiesen und die Leitung unterbrochen. Sie sollten es sich zur Gewohnheit machen, den Befehl called-login bei jedem System zu verwenden, das Sie in Ihre sys-Datei aufnehmen. Es ist wichtig, dies für alle Systeme in Ihrer sys-Datei zu tun, gleichgültig, ob sie Ihre Site jemals anwählen oder nicht. Bei Sites, die niemals bei Ihnen anrufen, sollten Sie called-login auf irgendeinen Phantasienamen setzen, zum Beispiel neverlogsin.

Seien Sie “paranoid” — Rufsequenz-Prüfungen (Call Sequence Checks) Eine andere Möglichkeit, Eindringlinge zu erkennen und abzuwehren, bieten sogenannte Rufsequenz-Prüfungen (Call Sequence Checks). Diese helfen beim Schutz vor Eindringlingen, denen es irgendwie gelungen ist, an das Paßwort zu gelangen, mit dem Sie sich in Ihr UUCP-System einloggen. Bei Rufsequenz-Prüfungen speichern beide Maschinen die Anzahl der bislang aufgebauten Verbindungen. Diese Zahl wird bei jeder neuen Verbindung erhöht. Nach dem Login sendet der Anrufer seine Rufsequenz-Nummer, die vom System mit der eigenen Zahl verglichen wird. Stimmen die Zahlen nicht überein, wird die Verbindung unterbrochen. Wird die Zahl zu Beginn zufällig gewählt, haben es Angreifer schwer, die richtige Nummer zu erraten. Aber Rufsequenz-Prüfungen tun noch mehr für Sie als das: Selbst wenn eine besonders clevere Person Ihre RufsequenzNummer und Ihr Paßwort ermittelt haben sollte, finden Sie das heraus. Dringt ein Angreifer in Ihren UUCP-Account ein und stiehlt Ihnen Ihre Mail, wird die Rufsequenz-Nummer um eins erhöht. Wenn Sie beim nächsten Mal versuchen, sich einzuloggen, wird das entfernte uucico Sie ablehnen, weil die Nummern nicht mehr übereinstimmen! Wenn Sie die Rufsequenz-Prüfungen aktiviert haben, sollten Sie Ihre Logdateien regelmäßig auf Fehlermeldungen

überprüfen, die auf mögliche Angriffe hinweisen. Weist Ihr System die Rufsequenz-Nummer ab, die ihm von einem System angeboten wurde, schreibt uucico eine Nachricht wie “Out of sequence call rejected” in die Logdatei. Wurde Ihr System abgewiesen, weil die Sequenznummer nicht übereinstimmt, finden Sie eine Nachricht wie “Handshake failed (RBADSEQ)” in Ihrer Logdatei vor. Um die Rufsequenz-Prüfung zu aktivieren, müssen Sie den folgenden Befehl zu Ihrem Systemeintrag hinzufügen: # Rufsequenz-Prüfung aktivieren sequence

true

Außerdem müssen Sie eine Datei erzeugen, die die Sequenznummer selbst enthält. Taylor UUCP bewahrt diese Zahl in einer Datei namens .Sequence im Spool-Verzeichnis des anderen Rechners auf. Sie muß uucp gehören und auf Zugriffsrecht 600 eingestellt sein (d.h., sie kann nur von uucp gelesen und geschrieben werden). Am besten initialisieren Sie diese Datei mit einer willkürlichen Zahl, auf die sich beide Seiten verständigt haben. Eine einfache Methode, diese Datei zu erzeugen, ist: # cd /var/spool/uucp/pablo # echo 94316 > .Sequence # chmod 600 .Sequence # chown uucp.uucp .Sequence

Natürlich muß auch die Gegenseite die Rufsequenz-Prüfung aktiviert haben und mit genau derselben Sequenznummer beginnen wie Sie.

Anonymous UUCP Wenn Sie den Zugriff auf Ihr System über Anonymous UUCP ermöglichen wollen, müssen Sie zuerst, wie oben beschrieben, einen speziellen Account dafür einrichten. In der Praxis wird für diesen anonymen Account häufig uucp als Login-Name und Paßwort verwendet. Zusätzlich müssen Sie einige Sicherheitsoptionen für unbekannte Systeme einrichten. So werden Sie üblicherweise verhindern wollen, daß diese Systeme irgendwelche Be-fehle auf Ihrem Rechner ausführen können. Nun können Sie diese Parameter aber nicht in der sys-Datei eintragen, weil der system-Eintrag einen Systemnamen erwartet, den Sie aber nicht haben. Taylor UUCP löst dieses Dilemma mit dem Befehl unknown. Er kann in der config-Datei verwendet werden, um Befehle anzugeben, die üblicherweise in einem Systemeintrag vorkommen können: unknown remote-receive ~/incoming unknown remote-send ~/pub unknown remote-debug none unknown command-path /usr/lib/uucp/anon-bin unknown rmail

maxcommands

Dies schränkt unbekannte Systeme darauf ein, Dateien unter dem Verzeichnis pub herunterzuladen und ins Verzeichnis incoming unter /var/spool/uucppublic zu kopieren. Die nächste Zeile stellt sicher, daß uucico alle Anforderungen ignoriert, das lokale Debugging zu aktivieren. Die letzten beiden Zeilen erlauben unbekannten Systemen die Ausführung von rmail, wobei der von uucico verwendete Suchpfad allerdings auf ein privates Verzeichnis namens anon-bin beschränkt ist. Auf diese Weise können Sie ein spezielles rmail anbieten, das beispielsweise alle Mail zur Prüfung an den Superuser weiterleitet. So können anonyme Benutzer den Verwalter des Systems erreichen, ohne irgendwelche Mails an andere Sites verschicken zu können. Um Anonymous UUCP zu aktivieren, müssen Sie mindestens eine unknown-Zeile in config aufnehmen. Andernfalls lehnt uucico alle unbekannten Systeme ab.

1.

Beachten Sie, daß tcpd normalerweise auf Zugriffsrecht 700 eingestellt ist, so daß Sie es als root, nicht als uucp aufrufen müssen. tcpd wird in Kapitel 12 Wichtige Netzwerk-Features, näher beschrieben.

2.

Gert Doerings mgetty ist so ein Biest. Es läuft auf einer Vielzahl von Plattformen, darunter SCO Unix, AIX, SunOS, HP-UX und Linux.

3.

Diese Option ist in Version 1.04 nicht verfügbar.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Low-Level-Protokolle unter UUCP Zur Abstimmung von Session-Kontrolle und Dateitransfers mit der Gegenseite verwendet uucico einen Satz von standardisierten Nachrichten, häufig als High-Level-Protokoll bezeichnet. Während der Initialisierungs- und Aufhängphase werden diese einfach als einfache Zeichenketten übertragen. Während der eigentlichen Transferphase wird aber ein zusätzliches Low-Level-Protokoll genutzt, das nahezu transparent für die höheren Level ist. Dieses Protokoll bringt einige weitere Vorteile mit sich; es erlaubt beispielsweise die Fehlerprüfung von Daten, die über unzuverlässige Verbindungen übertragen werden.

Protokollübersicht UUCP wird über verschiedene Arten von Verbindungen verwendet, wie serielle Leitungen, TCP oder manchmal sogar X.25. Es ist von Vorteil, UUCP in Protokollen zu übertragen, die speziell für das zugrundeliegende Netzwerkprotokoll ausgelegt sind. Zusätzlich haben verschiedene UUCPImplementierungen unterschiedliche Protokolle hervorgebracht, die in etwa dasselbe leisten. Protokolle können in zwei Kategorien eingeteilt werden: Paket- und Stream-orientierte Protokolle. Protokolle der letztgenannten Variante übertragen Dateien als Ganzes und berechnen für sie eventuell eine Prüfsumme. Dies geschieht nahezu frei von Overhead, setzt aber eine zuverlässige Leitung voraus, weil jeder Fehler die erneute Übertragung der gesamten Datei zur Folge hat. Diese Protokolle

werden üblicherweise bei TCP-Verbindungen verwendet, sind aber für Telefonleitungen nicht geeignet. Obwohl moderne Modems eine recht gute Fehlerkorrektur besitzen, sind sie doch nicht perfekt, und eine Fehlererkennung zwischen Ihrem Computer und dem Modem gibt es auch nicht. Auf der anderen Seite teilen paketorientierte Protokolle die Datei in viele kleine Stücke gleicher Größe auf. Jedes Paket wird separat verschickt und empfangen, eine Prüfsumme wird berechnet und eine Bestätigung an den Sender zurückgeschickt. Um dies noch effektiver zu machen, wurden sogenannte “Sliding-Window-Protokolle” eingeführt, die eine begrenzte Anzahl (ein Window) noch ausstehender Bestätigungen zu einer bestimmten Zeit ermöglichen. Das reduziert die Zeit, die uucico während einer Übertragung warten muß, ganz erheblich. Der im Vergleich zu den Stream-basierten Protokollen relativ große Overhead macht Paketprotokolle über TCP allerdings ineffizient, jedoch ideal für Telefonverbindungen. Auch die Datenbreite macht einen Unterschied. Manchmal ist die Übertragung von 8-Bit-Zeichen über eine serielle Leitung unmöglich, weil zum Beispiel die Verbindung über einen dummen TerminalServer läuft, der das achte Bit immer abschneidet. Sollen 8-Bit-Zeichen über eine 7-Bit-Verbindung übertragen werden, müssen sie für die Übertragung besonders markiert werden. Im ungünstigsten Fall wird die zu übertragende Datenmenge verdoppelt, obwohl eine von der Hardware durchgeführte Komprimierung das wieder kompensieren kann. Leitungen, über die beliebige 8-Bit-Zeichen übertragen werden können, werden häufig als 8-Bit-sauber (8-bit clean) bezeichnet. Dies ist bei allen TCP-, aber auch bei den meisten Modemverbindungen der Fall. Taylor UUCP 1.06 unterstützt viele UUCP-Protokolle. Die üblichsten davon sind: g Dies ist das am weitesten verbreitete Protokoll und sollte von nahezu jedem uucico verstanden werden. Es führt eine gründliche Fehlerprüfung durch und ist daher für verrauschte Telefonverbindungen besonders geeignet. g benötigt eine saubere 8-Bit-Verbindung. Es ist ein paketorientiertes Protokoll, das die Sliding-Window-Technik benutzt. i Ein bidirektionales Paketprotokoll, das Dateien zur selben Zeit senden und empfangen kann. Es benötigt eine Vollduplex-Verbindung und eine saubere 8-Bit-Verbindung. Zur Zeit wird es nur von Taylor UUCP verstanden. t Dieses Protokoll ist für die Benutzung über eine TCP-Verbindung oder andere wirklich fehlerfreie Netzwerke gedacht. Es verwendet Pakete von 1.024 Byte und eine saubere 8-BitVerbindung. e

Sollte grundsätzlich dasselbe tun wie t. Der Hauptunterschied liegt darin, daß e ein Streambasiertes Protokoll und daher nur für zuverlässige Netzwerkverbindungen geeignet ist. f Zur Verwendung über zuverlässige X.25-Verbindungen gedacht. Es ist ein Stream-basiertes Protokoll und erwartet einen 7 Bit breiten Datenpfad. 8-Bit-Zeichen müssen besonders gekennzeichnet werden, was es sehr ineffizient machen kann. G Die System V Release 4-Version des g-Protokolls. Wird auch von einigen anderen UUCPVersionen verstanden. a Entspricht dem ZMODEM-Protokoll. Benötigt eine 8-Bit-Verbindung, kennzeichnet aber bestimmte Steuerzeichen wie XON und XOFF.

Tuning des Übertragungsprotokolls In allen Protokollen können die Paketgrößen, Timeouts usw. in gewissem Umfang variiert werden. Normalerweise arbeiten die voreingestellten Werte unter Standardbedingungen gut, müssen aber nicht unbedingt gerade für Ihre Situation optimal geeignet sein. Zum Beispiel verwendet das g-Protokoll Window-Größen von 1 bis 7 und Paketgrößen in Zweierpotenzen von 64 bis 4.096. Wenn Ihre Telefonleitung so verrauscht ist, daß immer mehr als 5 Prozent der Pakete verlorengehen, sollten Sie die Paketgröße verringern und das Fenster verkleinern. Andererseits kann der Protokoll-Overhead für 128-Bit-Pakete bei sehr guten Telefonverbindungen unnötig verschwenderisch sein, so daß Sie die Paketgröße auf 512 oder sogar auf 1.024 Byte erhöhen können. Die meisten in Linux-Distributionen enthaltenen Binaries verwenden eine Window-Größe von 7 und 128-Byte-Pakete. Bei Taylor UUCP können Sie mit dem Befehl protocol-parameter in der sys-Datei diese Parameter an Ihre Bedürfnisse anpassen. Um etwa die Paketgröße des g-Protokolls auf 512 zu setzen, wenn Sie mit pablo kommunizieren, müssen Sie folgendes hinzufügen: system

pablo ... protocol-parameter g

packet-size

512

Die einstellbaren Parameter und ihre Namen sind von Protokoll zu Protokoll verschieden. Eine komplette Liste können Sie der Dokumentation entnehmen, die den Taylor UUCP-Quellen beiliegt.

Bestimmte Protokolle wählen Nicht jede Implementierung von uucico spricht und versteht jedes Protokoll. Daher müssen sich beide Prozesse während der Initialisierungsphase auf ein gemeinsames Protokoll einigen. Der uucico-Master

bietet dem Slave eine Liste unterstützter Protokolle durch Senden von Pprotlist, aus denen sich der Slave eines aussuchen kann. Basierend auf dem verwendeten Porttyp (Modem, TCP oder direkt), stellt uucico eine Standardliste mit Protokollen zusammen. Bei Modem- oder Direktverbindungen enthält diese Liste üblicherweise i, a, g, G und j. Bei TCP-Verbindungen lautet die Liste t, e, i, a, g, G, j und f. Diese Standardliste können Sie mit dem Befehl protocols überschreiben, der sowohl in einem System- als auch in einem Porteintrag stehen kann. Sie könnten etwa den Eintrag für Ihren Modem-Port in der port-Datei wie folgt setzen: port

serial1 ... protocols

igG

Jede über diesen Port ein- oder ausgehende Verbindung müßte dann i, g oder G verwenden. Wird keines von diesen vom anderen System unterstützt, ist keine Kommunikation möglich.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Fehlersuche Dieser Abschnitt beschreibt, was bei einer UUCP-Verbindung schiefgehen kann, und gibt einige Ratschläge zur Fehlerbehebung. Obwohl diese Probleme häufiger auftreten, gibt es noch wesentlich mehr mögliche Probleme, als wir hier aufgelistet haben. Wenn Sie ein Problem mit UUCP haben, sollten Sie mit der Option –xall das Debugging aktivieren und sich die Ausgaben in Debug im Spool-Verzeichnis ansehen. Das sollte Ihnen helfen, das Problem schnell zu erkennen. Es ist oft hilfreich, den Lautsprecher des Modems zu aktivieren, wenn keine Verbindung hergestellt werden kann. Bei Hayes-kompatiblen Modems erreichen Sie dies durch Einfügen von ATL1M1 OK im Modem-Chat der dial-Datei. Zuallererst sollten Sie immer kontrollieren, ob die Dateizugriffsrechte korrekt gesetzt sind. uucico sollte Setuid uucp sein, und alle Dateien in /usr/lib/uucp, /var/spool/uucp und /var/spool/uucppublic sollten uucp gehören. Es gibt auch einige versteckte Dateien im Spool-Verzeichnis, die auch uucp gehören müssen.1 Wenn Sie sichergestellt haben, daß die Zugriffsrechte aller Dateien korrekt eingestellt sind, und Sie trotzdem noch Probleme feststellen, sollten Sie die Fehlermeldungen genauer untersuchen. Im folgenden betrachten wir einige der häufigsten Fehler und Probleme.

uucico behauptet andauernd “Wrong Time to Call” Das bedeutet wahrscheinlich, daß Sie im Systemeintrag in sys keine time-Angabe gemacht haben, die bestimmt, wann das entfernte System angerufen werden darf. Vielleicht haben Sie aber auch die Zeit so eingestellt, daß ein Anruf momentan einfach nicht erlaubt ist. Wird keine Zeitangabe gemacht, setzt uucico voraus, daß das System niemals angerufen werden kann.

uucico beschwert sich: “Site Is Already Locked” Das bedeutet, daß uucico im Verzeichnis /var/spool/uucp eine Lock-Datei für das Remote-System entdeckt hat. Die Lock-Datei könnte von einem früheren Anruf zu diesem System stammen, der abgestürzt ist oder sonstwie abrupt beendet wurde. Eine andere mögliche Erklärung wäre, daß ein anderer uucico-Prozeß irgendwo herumlun-gert und versucht, das entfernte System anzurufen, und dabei im Chat-Skript steckengeblieben ist oder aus irgendeinem anderen Grund abgewürgt wurde. Um diesen Fehler zu beheben, brechen Sie alle das Remote-System betreffenden uucico-Prozesse mit einem Hangup-Signal ab und entfernen Sie alle Lock-Dateien, die von ihnen übriggeblieben sind.

Sie können die Verbindung mit der anderen Site herstellen, aber das ChatSkript schlägt fehl Sehen Sie sich den Text an, den Sie von der anderen Site empfangen. Wenn er verstümmelt ist, kann es sich um ein Geschwindigkeitsproblem handeln. Andernfalls sollten Sie prüfen, ob er wirklich mit dem übereinstimmt, was Ihr Chat-Skript erwartet. Denken Sie daran, daß das Chat-Skript zu Beginn auf einen String wartet. Wenn Sie den Login-Prompt empfangen und Ihren Namen senden, aber niemals den Paßwort-Prompt erhalten, sollten Sie eine Verzögerung einbauen, bevor Sie ihn senden, möglicherweise sogar zwischen den einzelnen Buchstaben. Sie könnten zu schnell für Ihr Modem sein.

Ihr Modem wählt nicht Wenn Ihr Modem nicht anzeigt, daß die DTR-Leitung aktiviert wurde, während uucico eine externe Verbindung aufbaut, haben Sie uucico möglicherweise nicht das richtige Gerät angegeben. Falls Ihr Modem DTR erkennt, prüfen Sie mit einem Terminal-Programm, ob Sie zum Modem schreiben können. Wenn ja, aktivieren Sie das Echo mit \E zu Beginn des Modem-Chats. Erfolgt kein Echo Ihrer Befehle während des Modem-Chats, sollten Sie prüfen, ob die Geschwindigkeit für Ihr Modem zu hoch oder zu niedrig ist. Funktioniert das Echo, sollten Sie überprüfen, ob die Modem-Antworten deaktiviert oder auf numerische Werte eingestellt sind. Prüfen Sie, ob das Chat-Skript selbst in Ordnung ist. Denken Sie daran, daß Sie immer zwei Backslashes schreiben müssen, um einen an das Modem zu senden.

Ihr Modem versucht zu wählen, kommt aber nicht raus

Fügen Sie eine Verzögerung in die Telefonnummer ein, insbesondere dann, wenn Sie aus einer Nebenstellenanlage einer Firma herauswählen. Stellen Sie sicher, daß Sie das korrekte Wählverfahren (Impulswahl oder Mehrfrequenzwahl) benutzen, da manche Telefonnetze nur eines davon unterstützen. Außerdem sollten Sie die gewählte Telefonnummer noch mal genau überprüfen.

Sie können sich einloggen, aber der Handshake schlägt fehl Nun, da kann es eine Reihe von Problemen geben. Die Ausgabe in der Logdatei sollte Ihnen viel dazu sagen können. Achten Sie darauf, welche Protokolle der andere Rechner anbietet (er sendet den String Pprotlist während des Handshakes). Damit der Handshake funktioniert, müssen beide Seiten mindestens ein gemeinsames Protokoll unterstützen. Prüfen Sie also nach, ob das der Fall ist. Sendet das andere System RLCK, existiert eine alte Lock-Datei für Ihren Rechner auf dem anderen System. Wenn Sie nicht bereits über eine andere Leitung mit diesem System verbunden sind, muß die Datei vom Administrator der Gegenseite entfernt werden. Wird RBADSEQ vom Remote-System gesendet, wurde eine Rufsequenz-Prüfung durchgeführt, aber die Zahlen stimmten nicht überein. Erhalten Sie die Meldung RLOGIN, wurde Ihnen das Login unter dieser ID verweigert.

1.

Versteckte Dateien sind Dateien, deren Name mit einem Punkt beginnt. Solche Dateien werden normalerweise nicht von ls angezeigt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Logdateien und Debugging Wenn Sie das UUCP-Paket so kompilieren, daß das Taylor-eigene Logging verwendet wird, gibt es nur drei globale Logdateien, die alle im Spool-Verzeichnis untergebracht sind. Die Haupt-Logdatei heißt Log und enthält alle Informationen über aufgebaute Verbindungen und übertragene Dateien. Ein typischer Auszug sieht wie folgt aus (die Formatierung wurde etwas geändert, damit er auf die Seite paßt): uucico pablo - (1994-05-28 17:15:01.66 539) Calling system pablo (port cua3) uucico pablo - (199405-28 17:15:39.25 539) Login successful uucico pablo - (1994-05-28 17:15:39.90 539) Handshake successful (protocol ’g’ packet size 1024 window 7) uucico pablo postmaster (1994-0528 17:15:43.65 539) Receiving D.pabloB04aj uucico pablo postmaster (1994-05-28 17:15:46.51 539) Receiving X.pabloX04ai uucico pablo postmaster (1994-05-28 17:15:48.91 539) Receiving D.pabloB04at uucico pablo postmaster (1994-05-28 17:15:51.52 539) Receiving X.pabloX04as uucico pablo postmaster (1994-05-28 17:15:54.01 539) Receiving D.pabloB04c2 uucico pablo postmaster (1994-05-28 17:15:57.17 539) Receiving X.pabloX04c1 uucico pablo - (1994-05-28 17:15:59.05 539) Protocol ’g’ packets: sent 15, resent 0, received 32 uucico pablo - (1994-05-28 17:16:02.50 539) Call complete (26 seconds) uuxqt pablo postmaster (1994-05-28 17:16:11.41 546) Executing X.pabloX04ai (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.30 546) Executing X.pabloX04as (rmail okir) uuxqt pablo postmaster (1994-05-28 17:16:13.51 546) Executing X.pabloX04c1 (rmail okir)

Die nächste wichtige Logdatei ist Stats, die die Datenübertragungs-Statistiken enthält. Der Ausschnitt aus Stats, der dem obigen Transfer entspricht, sieht wie folgt aus (auch hier wurden die Zeilen aufgeteilt, damit er auf die Seite paßt): postmaster pablo (1994-05-28 17:15:44.78) received 1714 bytes in 1.802 seconds (951 bytes/sec) postmaster pablo (1994-05-28 17:15:46.66) received 57 bytes in 0.634 seconds (89 bytes/sec) postmaster pablo (1994-05-28 17:15:49.91) received 1898 bytes in 1.599 seconds (1186 bytes/sec) postmaster pablo (1994-05-28 17:15:51.67) received 65 bytes in 0.555 seconds (117 bytes/sec) postmaster pablo (1994-05-28 17:15:55.71) received 3217 bytes in 2.254 seconds (1427 bytes/sec) postmaster pablo (1994-05-28 17:15:57.31) received 65 bytes in 0.590 seconds (110 bytes/sec)

Die dritte Datei ist Debug. In sie werden die gesamten Debugging-Informationen geschrieben. Wenn Sie Debugging verwenden, sollten Sie sicherstellen, daß die Datei den Zugriffsmodus 600 verwendet. Abhängig vom gewählten Debug-Modus kann sie das Login und das Paßwort enthalten, die Sie für den Verbindungsaufbau zum Remote-System verwenden. Wenn Sie einige Tools benutzen, die Ihre Logdateien im traditionellen Format verwenden, wie es von HDB-kompatiblen UUCP-

Implementierungen benutzt wird, können Sie Taylor UUCP auch so kompilieren, daß es HDB-konforme Logs erzeugt. Das ist nur eine Frage der richtigen Compile-Time-Option in der Datei config.h.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 17 Elektronische Post

Das Versenden von E-Mail war schon immer eine der geläufigsten Netzwerkanwendungen, seit es die ersten Netze gibt. E-Mail (vom englischen electronic mail) begann als sehr primitiver Dienst, der einfach eine Datei von einer Maschine auf eine andere transportierte und an die mailbox-Datei der Empfängerin anhängte. Dieses Prinzip hat sich im wesentlichen bis heute nicht geändert. Allerdings haben ein stetig wachsendes Netz mit seinen komplexen Anforderungen an das Routing und die ständig zunehmende Zahl der übertragenen Botschaften ein ausgefeilteres Konzept nötig gemacht.

Heute existiert eine ganze Reihe von Standards für den Transport von Mail. Internet-Sites verwenden ein Format, das ursprünglich in RFC-822 definiert, aber seitdem um einige RFCs erweitert wurde, die die maschinenunabhängige Übertragung von nahezu allem Möglichen beschreiben, wozu auch Grafiken, Sound-Dateien und spezielle Zeichensätze gehören.1 Der CCITT hat noch einen weiteren Standard — X.400 — definiert. Es wird noch in manchen großen Unternehmens- und Regierungsbereichen eingesetzt, stirbt aber langsam aus. Für Unix-Systeme wurde eine ganze Reihe von Programmen für den Transport von E-Mail implementiert. Eins der bekanntesten ist das von Eric Allman an der Universität Berkeley entwickelte sendmail. Eric Allman vertreibt sendmail nun kommerziell, das Programm bleibt aber freie Software. sendmail wird in einigen Linux-Distributionen als Standard-Mail-Programm eingesetzt. Auf die Konfiguration von sendmail gehen wir in Kapitel 18 Sendmail, ein. Linux verwendet auch Exim, das von Philip Hazel von der Universität Cambridge geschrieben wurde. Die Konfiguration von Exim beschreiben wir in Kapitel 19 Inbetriebnahme von Exim. Verglichen mit sendmail, ist Exim noch relativ neu. Für die große Mehrheit der Systeme mit E-MailBedarf sind ihre Kapazitäten nahezu gleich. Sowohl Exim als auch sendmail unterstützen eine Reihe von Konfigurationsdateien, die an Ihr System angepaßt werden müssen. Abgesehen von den Informationen, die nötig sind, um das lokale MailSystem zum Laufen zu bringen (wie beispielsweise der Hostname), lassen sich eine ganze Reihe weiterer Parameter einstellen. sendmails Haupt-Konfigurationsdatei ist zu Anfang völlig unverständlich. Die Datei sieht in etwa so aus, als sei Ihre Katze über die Tastatur spaziert, während Sie die Shift-Taste gedrückt hielten. Exims Konfigurationsdateien sind dagegen klarer strukturiert und einfacher zu verstehen als die von sendmail. Exim bietet jedoch keine direkte UUCP-Unterstützung und kommt nur mit Domainadressen zurecht. Das ist in der heutigen Zeit allerdings keine allzu große Einschränkung mehr, wie es vielleicht anfangs einmal der Fall war, da die meisten Systeme mit den Beschränkungen von Exim leben können. Trotzdem ist der Aufwand, den Sie für beide betreiben müssen, in ungefähr derselbe. In diesem Kapitel beschäftigen wir uns damit, was E-Mails überhaupt sind und welche Aufgaben auf die Administratoren zukommen. Kapitel 18 Sendmail, und Kapitel 19 Inbetriebnahme von Exim, geben nähere Anleitungen zur Einrichtung von sendmail und Exim sowie einige Anleitungen zum Einstieg. Mit deren Hilfe sollten Sie in der Lage sein, kleinere Sites einzurichten, aber das ist natürlich noch lange nicht alles. Wenn Sie wollen, können Sie Stunde um Stunde vor Ihrem Computer damit verbringen, die tollsten Features zu konfigurieren. Gegen Ende dieses Kapitels werden wir uns kurz mit der Einrichtung von elm beschäftigen, einem auf Unix-ähnlichen Systemen (inklusive Linux) sehr beliebten Benutzerprogramm für E-Mail. Weitere Informationen zum Thema E-Mail unter Linux finden Sie im Electronic Mail-HOWTO von Guylhem Aznar,2 das regelmäßig in die Newsgruppe comp.os.linux. -answers gepostet wird. Die Quellcode-Distributionen von elm, Exim und sendmail enthalten sehr ausführliche Dokumentationen,

die die meisten Ihrer Fragen zur Einrichtung dieser Programme beantworten sollten und auf die wir in den nachfolgenden Ausführungen auch verweisen werden. Wenn Sie nach Informationen über E-Mail im allgemeinen suchen, finden Sie im Literaturverzeichnis am Ende dieses Buches eine Liste relevanter RFCs.

1.

Wenn Sie das nicht glauben, lesen Sie RFC-1437!

2.

Guylhem ist erreichbar unter [email protected].

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Was ist überhaupt eine Mail? Ein elektronischer Brief besteht im allgemeinen zunächst aus dem Rumpf der Nachricht, also dem von Ihnen geschriebenen Text, und speziellen administrativen Daten, die die Empfänger angeben, das Transportmedium usw., ganz ähnlich dem, was Sie sehen, wenn Sie einen normalen Briefumschlag betrachten. Diese administrativen Daten lassen sich in zwei Kategorien einteilen. In die erste Kategorie fallen alle Daten, die das Transportmedium betreffen, wie z.B. die Adresse des Absenders und Empfängers. Man spricht deshalb auch vom Briefumschlag, dem Envelope. Diese Daten können von der Transportsoftware transformiert werden, während sie die Botschaft weiterreicht. Die zweite Sorte umfaßt alle Informationen, die zur Verarbeitung der E-Mail erforderlich sind und von jeglichem Transportmechanismus unabhängig sind. Dazu gehören beispielsweise die Betreff-Zeile (engl. subject), die Liste aller Empfänger sowie Datum und Uhrzeit, wann die Botschaft abgeschickt wurde. In vielen Netzwerken hat es sich eingebürgert, diese Informationen der eigentlichen Botschaft als Briefkopf voranzustellen. Dieser Kopf (oder mail header) ist vom Rumpf (oder mail body) der Botschaft durch eine Leerzeile getrennt.1 Die meisten Mail-Programme in der UNIX-Welt verwenden ein Header-Format, das in RFC-822 skizziert ist. Sein ursprünglicher Zweck war es, einen Standard für das ARPANET zu schaffen. Da es so entworfen wurde, daß es unabhängig von irgendeiner bestimmten Netzwerkumgebung ist, wurde es auch leicht an andere Netze angepaßt, einschließlich vieler UUCP-basierter Netze. RFC-822 ist allerdings nur der größte gemeinsame Nenner. In jüngerer Zeit sind verschiedene Standards entwickelt worden, die den wachsenden Bedarf an Zusätzen, wie Verschlüsselung, Unterstützung für internationale Zeichensätze und MIME (Multipurpose Internet Mail Extensions, beschrieben in RFC-1341 und anderen RFCs), bewältigen sollen. All diese Standards gehen davon aus, daß ein Mail-Header aus mehreren Zeilen besteht, getrennt durch Zeilenendezeichen. Eine Zeile setzt sich jeweils aus einem Feldnamen zusammen, der in Spalte eins beginnt, und dem Feld selbst, das durch einen Doppelpunkt und ein Leerzeichen abgesetzt ist. Das Format und die Bedeutung der einzelnen Felder variiert in Abhängigkeit vom Feldnamen. Ein Header-Feld kann über eine Zeile fortgesetzt werden, wenn die nächste Zeile mit Leerzeichen (Blank oder TAB) beginnt. Die Reihenfolge der Felder spielt keine Rolle. Ein typischer Mail-Header sieht so aus:

Return-Path: Received: ursa.cus.cam.ac.uk ([email protected] [131.111.8.6]) by al.animats.net (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id WAA04654 for ; Sun, 30 Jan 2000 22:30:01 +1100 Received: from ph10 (helo=localhost) by ursa.cus.cam.ac.uk with local-smtp (Exim 3.13 #1) id 12EsYC-0001eF-00; Sun, 30 Jan 2000 11:29:52 +0000 Date: Sun, 30 Jan 2000 11:29:52 +0000 (GMT) From: Philip Hazel Reply-To: Philip Hazel To: Terry Dawson , Andy Oram Subject: Electronic mail chapter In-Reply-To: <[email protected]> Message-ID:

Im Normalfall werden alle notwendigen Einträge im Header der Mail von Ihrem Mail-Programm wie elm, pine, mush oder mailx generiert. Einige sind optional und können vom Benutzer angefügt werden. elm erlaubt Ihnen beispielsweise, einen Teil des Headers zu editieren. Andere Felder werden von der Transportsoftware angefügt. Wenn Sie sich eine lokale MailboxDatei ansehen, werden Sie vielleicht feststellen, daß jeder Mail-Nachricht ein “From” (ohne Doppelpunkt) vorangestellt ist. In diesem Fall handelt es sich nicht um einen RFC-822-Header, sondern dieser Header wurde von Ihrer Mail-Software nachträglich eingefügt, um anderen Programmen das Lesen der E-Mails zu erleichtern. Um mögliche Verwechslungen mit Zeilen im Rumpf der Nachricht zu vermeiden, die auch mit “From” beginnen, hat sich die Standardkonvention durchgesetzt, solchen Wörtern immer ein >-Zeichen voranzustellen. Hier ist eine Liste geläufiger Header-Einträge und ihrer Bedeutung: From: Dieses Feld enthält die Mail-Adresse des Absenders und eventuell den “richtigen” Namen. Ein ganzer Zoo von Formaten wird hier benutzt. To: Liste von Mail-Adressen der Empfänger. Aufeinanderfolgende Empfänger-Adressen sind durch Kommata getrennt. Cc: Liste von Mail-Adressen, die “Durchschläge” (carbon copies) der Nachricht bekommen. Aufeinanderfolgende Empfänger-Adressen sind durch Kommata getrennt. Bcc: Liste von Mail-Adressen, die “Durchschläge” (carbon copies) der Nachricht bekommen. Der Hauptunterschied zwischen “Cc:” und “Bcc:” liegt darin, daß die in “Bcc:” aufgelisteten Adressen nicht im Header der an die Empfänger versendeten Mail-Nachrichten erscheinen. Es bietet die Möglichkeit, die Empfänger darauf hinzuweisen, daß Kopien der Nachricht an andere weitergeleitet wurden, ohne mitzuteilen, wer diese Empfänger sind. Aufeinanderfolgende Empfänger-Adressen sind durch Kommata getrennt. Subject: Beschreibt den Inhalt der Nachricht mit wenigen Worten. Date: Datum und Uhrzeit, wann die Nachricht abgeschickt wurde. Reply-To: Dieses Feld ist optional und gibt dem Empfänger die Adresse vor, an die seine Antwort geschickt wird. Das kann nützlich sein, wenn Sie mehrere Accounts haben, aber die meisten Ihrer Mails nur auf dem Account empfangen wollen, den Sie am häufigsten benutzen.

Organization: Die Organisation, der der Rechner gehört, von dem aus die Nachricht verschickt wurde. Wenn es Ihr eigener Rechner ist, lassen Sie das Feld einfach leer, tragen Sie “private” oder irgend etwas Unsinniges ein. Auch dieses Feld ist optional, wird aber in keinem RFC erwähnt. Manche Mail-Programme unterstützen es direkt, viele jedoch nicht. Message-ID: Eine eindeutige Kennung, die von der Transportsoftware des Absenders erzeugt wird. Sie dient dazu, die Nachricht eindeutig zu identifizieren. Received: Jedes System, das eine Mail verarbeitet (einschließlich der Maschinen von Absender und Empfänger), fügt ein solches Feld in den Header ein, das den Namen des Systems angibt, eine Nachrichten-ID, Datum und Uhrzeit, zu der die Nachricht empfangen wurde, von welchem System sie kam und welches Transportsystem benutzt wurde. Mit dieser Information können Sie, wenn nötig, die Route zurückverfolgen, die eine Nachricht genommen hat, und sich bei der verantwortlichen Person beschweren, wenn etwas schiefgelaufen ist. X-anything: Kein Mail-Programm sollte sich jemals über einen Header beschweren, der mit X- anfängt. Er wird dazu benutzt, zusätzliche Features zu implementieren, die noch kein RFC-Standard sind und es vielleicht auch nie werden. Zum Beispiel gab es mal einen sehr großen Linux-Mailinglist-Server, der es Ihnen ermöglichte, mittels der Zeichenfolge XMn-Key:, gefolgt vom Kanalnamen, einen bestimmten Kanal für Ihre Mail anzugeben.

1.

Es ist auch üblich, eine Art Unterschrift an eine Mail anzuhängen, die für gewöhnlich Informationen über den Absender enthält. Manchmal ist auch ein Witz oder ein Motto dabei. Diese signature (oder .sig) wird vom Rest der Botschaft durch eine einzelne Zeile abgesetzt, die das Zeichen “—” enthält, gefolgt von einem Leerzeichen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie wird Mail transportiert? Für gewöhnlich werden Sie Ihre E-Mails mit Hilfe von Programmen wie mail oder mailx schreiben oder mit etwas Komfortablerem wie mutt, tkrat oder pine. Diese Programme werden im Englischen als Mail User Agents bezeichnet (agent heißt Werkzeug) und MUA abgekürzt. Wenn Sie eine Nachricht abschicken, wird sie von Ihrem Benutzerprogramm in der Regel an ein anderes Programm weitergereicht, das den Transport zum Zielsystem übernimmt. Dieses Programm heißt Mail Transport Agent, kurz MTA. Auf den meisten Systemen wird derselbe MTA sowohl für lokalen als auch fernen Versand benutzt — in der Regel /usr/sbin/sendmail (bzw. /usr/lib/sendmail auf nicht-FSSTNDkonformen Systemen). Auf UUCP-Systemen ist es nicht ungewöhnlich, den Mail-Versand über zwei separate Programme laufen zu lassen: rmail für den Remote-Versand und lmail zum Versenden lokaler Mails. Die Auslieferung einer Mail an einen lokalen Benutzer umfaßt natürlich mehr, als sie nur an die Mailbox-Datei des Benutzers anzuhängen. Für gewöhnlich muß sich der lokale MTA um Aliasing (Einrichtung lokaler Empfänger-Adressen, die auf andere Adressen verweisen) und Forwarding (Umleiten einer Benutzer-Mail auf ein anderes Ziel) kümmern. Außerdem müssen nicht zustellbare Mails mitsamt einem Fehlerreport an den Absender zurückgesandt werden; im Englischen wird dieser Vorgang als bouncing bezeichnet. Bei der Auslieferung über ein anderes System hängt es ganz von der Art der Netzverbindung ab,

welche Transportsoftware verwendet wird. Werden die Nachrichten über ein TCP/IP-basiertes Netz zugestellt, wird für gewöhnlich SMTP verwendet. SMTP steht für Simple Mail Transfer Protocol und ist in RFC-821 beschrieben. SMTP wurde so entworfen, daß eine Nachricht direkt an eine EmpfängerMaschine zugestellt wird, wobei die Nachrichtenübertragung mit dem SMTP-Dämon der Gegenseite ausgehandelt wird. In Unternehmen ist es heutzutage üblich, spezielle Hosts zur Verfügung zu stellen, die alle an Empfänger im Unternehmen gerichteten Mails aufnehmen und ordnungsgemäß an die gewünschten Empfänger weiterleiten. In UUCP-Netzen werden Mails für gewöhnlich nicht direkt zugestellt, sondern über eine Reihe von Zwischensystemen bis zum Zielrechner durchgereicht. Um eine Nachricht über eine einzelne UUCPVerbindung zu senden, führt der sendende MTA auf dem Nachbarsystem mit Hilfe von uux das Programm rmail aus und übergibt ihm die Nachricht auf der Standardeingabe. Da uux für jede Nachricht separat aufgerufen wird, kann es auf größeren Mail-Verteilern zu einer beträchtlichen Arbeitslast kommen und gleichzeitig die UUCP-Spool-Verzeichnisse mit Hunderten kleiner Dateien füllen, die unverhältnismäßig viel Plattenplatz belegen.1 Einige MTAs erlauben Ihnen darum, mehrere Nachrichten, die an dasselbe System weitergereicht werden sollen, in einer einzelnen Batch-Datei zu sammeln. Diese Batch-Datei enthält die SMTP-Befehle, die der lokale MTA normalerweise ausgeben würde, wenn eine direkte SMTP-Verbindung benutzt würde. Diese Technik nennt sich BSMTP oder batched SMTP. Der fertige Batch wird dann auf dem anderen System an das Programm rsmtp oder bsmtp verfüttert, das die Eingabe so verarbeitet, als ob eine normale SMTPVerbindung vorläge.

1.

Da Plattenplatz immer in größeren Einheiten (z.B. 1.024 Byte) alloziert wird. Dadurch schluckt selbst eine Mini-Mail von ein paar Byte gleich ein ganzes Kilobyte.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

E-Mail-Adressen E-Mail-Adressen bestehen aus mindestens zwei Teilen. Ein Teil ist die Mail-Domain, bei der es sich entweder um den Namen des Empfänger-Hosts oder um den Namen einer Maschine handelt, die die Mail im Auftrag des Empfängers bearbeitet. Der andere Teil ist eine Art eindeutige BenutzerIdentifikation, wie der Login-Name des Benutzers oder der echte Name des Benutzers im “Vorname.Nachname”-Format oder ein beliebiger Alias, der zu einem Benutzer bzw. einer Liste von Benutzern übersetzt wird. Andere Adressierungsschemata wie X.400 verwenden einen allgemeineren Satz von “Attributen”, aus denen mit Hilfe eines X.500 Directory-Servers das Empfängersystem ermittelt wird. Wie Mail-Adressen interpretiert werden, hängt stark davon ab, welche Art von Netzwerk Sie benutzen. Wir konzentrieren uns darauf, wie TCP/IP- und UUCP-Netzwerke Mail-Adressen interpretieren.

RFC-822 Internetsysteme halten sich an den Standard RFC-822, der die übliche Schreibweise [email protected] verlangt, wobei host.domain der voll qualifizierte Domainname des Hosts ist. Das Ding in der Mitte ist ein “Klammeraffe”; der englische Name “commercial at” (kurz “at”) macht einem eher begreiflich, wieso es als Trennsysmbol gewählt wurde. Diese Notation gibt keine Route

zum Zielhost an. Wie Mails geroutet werden, beschreiben wir in Kürze. Wenn Sie eine Site im Internet betreiben, werden Sie viel mit RFC-822 zu tun haben. Dieses RFC betrifft übrigens nicht nur Mails, sondern auch andere Dienste wie z.B. News. Auf die Anwendung von RFC-822 gehen wir in Kapitel 20 Netnews, ein.

Veraltete Mail-Formate In der ursprünglichen UUCP-Umgebung war path!host!user die vorherrschende Form, wobei path die Reihenfolge der Systeme beschrieb, die die Nachricht zu passieren hatte, bevor sie das Zielsystem host erreichte. Diese Konstruktion nennt sich Bang-Path-Notation, da im Amerikanischen ein Ausrufezeichen auch manchmal “bang” genannt wird. Heute haben viele UUCP-basierte Netze RFC822 angenommen und verstehen auch die domainbasierten Adressen. Andere Netze haben noch ganz andere Adressierungsmöglichkeiten. Auf DECnet basierende Netze benutzen beispielsweise zwei Doppelpunkte als Trennzeichen, was Adressen der Form host::user ergibt.1 Der X.400-Standard verwendet dagegen ein ganz anderes Schema. Dort wird ein Empfänger durch eine Menge von Attribut/Wert-Paaren beschrieben, wie z.B. Land und Organisation. Im FidoNet wird jeder Benutzer durch einen Code wie 2:320/204.9 identifiziert, der aus vier Zahlen besteht, die die Zone bezeichnen (2 für Europa), das Netz (320 für Paris und Banlieue), den Knoten (der lokale Mail-Verteiler) und den sogenannten Point (der PC des Benutzers). FidoNet-Adressen können auf RFC-822-Adressen abgebildet werden; die obige würde als [email protected] geschrieben werden. Erwähnten wir nicht, daß Domainnamen leicht zu merken wären?

Verschiedene Mail-Formate mischen Wenn Sie eine Reihe verschiedener Systeme und dazu einige schlaue Leute zusammenbringen, ergibt es sich zwangsläufig, daß sie nach Mitteln und Wegen suchen werden, diese Systeme so zusammenzuschalten, daß sie schließlich ein gemeinsames Netzwerk bilden. Logisch, daß es nun eine Reihe unterschiedlicher Mail-Gateways gibt, die verschiedene Mail-Systeme miteinander verbinden können, so daß Mails von einem System auf ein anderes übertragen werden können. Der kritische Punkt bei der Verbindung zweier Systeme ist die Adressierung. Wir gehen hier nicht auf die Gateways selbst im Detail ein, sondern betrachten nur einige Problemfälle, die auftreten können, wenn man solche Gateways benutzt. Überlegen Sie mal, wie man UUCP-Adressen in Bang-Path-Notation und RFC-822 unter einen Hut bekommt. Diese zwei Arten der Adressierung lassen sich offensichtlich nicht so gut kombinieren. Wenn wir zum Beispiel die Adresse domainA!user@domainB betrachten, ist nicht ohne weiteres klar, ob der Klammeraffe @ Vorrang vor der Pfadangabe hat oder umgekehrt: Müssen wir die Nachricht zuerst an domainB schicken, von wo aus sie an domainA!user weitergereicht wird, oder soll sie an System domainA gesendet werden, das sie an user@domainB weiterleitet?

Solche Adressen, die verschiedene Arten von Adreßoperatoren vermischen, werden hybride Adressen genannt. Die geläufigste Art, die wir gerade eben illustriert haben, wird üblicherweise dadurch aufgelöst, daß dem @-Zeichen eine höhere Präzedenz gegenüber dem Pfad eingeräumt wird. Die Mail domainA!user@domainB würde also zuerst an domainB geschickt. Allerdings gibt es auch einen Weg, Routen in RFC-822-konformer Weise anzugeben: <@domainA,@domainB:user@domainC> ist die Adresse von user auf domainC, wobei domainC durch domainA und domainB (in dieser Reihenfolge) erreicht wird. Diese Art von Adressen wird oft als “source routed” bezeichnet. Auf Source-Routing sollte man aber besser nicht zurückgreifen. In den neueren RFC-Revisionen, die das Routing von Mails beschreiben, wird empfohlen, Source-Routing in Mail-Adressen zu ignorieren und statt dessen zu versuchen, Mails immer ohne Umwege direkt an die Zieladressen zu senden. Dann ist da noch der %-Adressenoperator: Eine Mail an user%domainB@domainA wird zuerst an domainA geschickt, das das am weitesten rechts stehende (und in diesem Falle einzige) Prozentzeichen durch ein @-Zeichen ersetzt. Die Adresse lautet nun user@domainB, und das MailSystem reicht sie fröhlich an domainB weiter, das sie an user ausliefert. Diese Art der Adressierung wird manchmal als “Ye Olde ARPAnet Kludge” bezeichnet. Von ihrer Verwendung wird allerdings abgeraten. Die Anwendung dieser verschiedenen Adressierungsarten führt zu einigen Folgeerscheinungen, auf die wir in den kommenden Abschnitten eingehen. In einer RFC-822-Umgebung sollten Sie ausschließlich absolute Adressen wie [email protected] benutzen.

1.

Wenn Sie aus einem Netz mit RFC-Adressierung eine DECnet-Adresse erreichen wollen, können Sie "host::user"@relay verwenden, wobei relay ein Internet-DECnet-Gateway sein muß.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie funktioniert Mail-Routing? Das Verfahren, wie eine Nachricht an den Host des Empfängers zugestellt wird, bezeichnet man als Routing. Dazu gehört nicht nur die Ermittlung der Übertragungsstrecke vom Sender zum Empfänger, sondern auch Fehlerprüfung sowie Geschwindigkeits- und Kostenoptimierung. Es gibt einen großen Unterschied in der Art und Weise, wie ein Internetsystem Routing durchführt und wie dies ein UUCPSystem tut. Im Internet wird die Hauptarbeit beim Datentransport an den Empfänger (sofern seine IP-Adresse bekannt ist) von der IP-Netzwerkschicht erledigt. Im UUCP-Bereich dagegen muß die Route vom Benutzer angegeben oder vom MailTransportprogramm erzeugt werden.

Mail-Routing im Internet Im Internet ist es ganz vom Zielsystem abhängig, ob überhaupt ein besonderes Mail-Routing vorgenommen wird. Im Normalfall wird eine Nachricht direkt an den Zielrechner übertragen, wobei zuerst festgestellt wird, an welchen Host die Nachricht gesendet werden soll, und danach die Nachricht direkt an diesen Host zugestellt wird. Die meisten Internet-Sites werden es allerdings vorziehen, daß alle eingehenden Mails von einem zentral verfügbaren Server entgegengenommen und lokal verteilt werden. Um diesen Dienst bekanntzumachen, veröffentlicht die Site im DNS einen sogenannten MX-Record für ihre lokale Domain. MX steht für den englischen Terminus Mail Exchanger. Im Grunde besagt ein MX-Record, daß der Server-Host bereit ist, alle Mail-Adressen in der Domain anzunehmen und weiterzuleiten. MX-Records können auch dazu verwendet werden, den Datenverkehr von Hosts, die nicht selbst ans Internet angeschlossen sind, zu verwalten. Typische Beispiele sind UUCP-Netzwerke und FidoNet-Rechner, deren Mails durch ein Gateway geleitet werden müssen. Einem MX-Record ist immer eine positive Zahl, die sogenannte Präferenz, zugeordnet. Wenn mehrere Mail-Exchanger für einen Host existieren, versucht der MTA, die Nachricht an den Mail-Exchanger mit dem niedrigsten Präferenzwert auszuliefern. Wenn dieser Versuch fehlschlägt, probiert er einen Host mit einem höheren Wert. Ist der lokale Host selbst ein Mail-Exchanger für die Zieladresse, darf er Nachrichten nur an Mail-Exchanger mit niedrigerer Präferenz als seiner eigenen ausliefern. Diese Einschränkung verhindert, daß sich eine Mail zwischen verschiedenen MX-Records in einer Schleife verfängt. Existiert kein MX-Record für eine Domain (oder kein passender), kann der MTA ermitteln, ob zu der Domain eine IP-Adresse existiert, und den Versuch unternehmen, die Mail direkt an diese Adresse zu senden. Angenommen, eine Firma namens Foobar GmbH möchte, daß alle anfallenden Mails von ihrem zentralen Server namens mailhub bearbeitet werden. Dann wird sie für jede ihrer Maschinen einen MX-Record wie diesen im DNS eintragen:

green.foobar.com.

IN

MX

5

mailhub.foobar.com.

Das macht mailhub.foobar.com als Mail-Exchanger für die Domain green.foobar.com mit einer Präferenz von 5 bekannt. Ein Host, der eine Nachricht an [email protected] ausliefern will, findet im DNS den MX-Record, der auf mailhub zeigt. Wenn er keinen anderen MX-Record mit einer kleineren Präferenz als 5 findet, wird die Nachricht an mailhub übertragen und von dort an green versendet. Soweit in groben Umrissen, wie MX-Records funktionieren. Weitergehende Informationen über Mail-Routing im Internet finden Sie in RFC-821, RFC-974 und RFC-1123.

Mail-Routing in der UUCP-Welt Das Mail-Routing in UUCP-Netzen ist wesentlich komplizierter als im Internet, da die Transportsoftware selbst keinerlei Routing durchführen kann. Früher mußten deshalb alle Mail-Adressen als Bang-Pfade angegeben werden. Ein Bang-Pfad gibt eine Liste von Maschinen an, durch die eine Nachricht weitergeleitet werden muß, getrennt durch Ausrufezeichen und gefolgt vom Benutzernamen. Um einen Brief an Janet User auf einer Maschine namens moria zu richten, müßten Sie eine Adresse wie eek!swim!moria!janet angeben. Das würde die Nachricht zuerst an eek schicken, von dort an swim, danach an moria, von wo sie schließlich an janet ausgeliefert würde. Der offensichtliche Nachteil dieser Technik ist, daß Sie dazu genötigt sind, sich wesentlich mehr über Netzwerktopologien, schnelle Verbindungen usw. zu merken als beim Routing übers Internet. Schlimmer noch, kurzfristige Veränderungen der Netzwerktopologie, wie die Entfernung von Links oder Hosts, können dazu führen, daß eine Nachricht ihr Ziel nicht erreicht, einfach weil Ihnen diese Änderung nicht bekannt ist. Zu guter Letzt müssen Sie sich im Falle eines Umzugs höchstwahrscheinlich alle Routen neu zusammensuchen. Ein wichtiger Grund, der Source-Routing notwendig machte, waren mehrdeutige Hostnamen. Angenommen, es gäbe zwei Systeme namens moria — eins in den USA, das andere in Frankreich, dann stellt sich die Frage: Auf welches bezieht sich nun die Adresse moria!janet? Die Angabe eines Pfades zu moria kann hier eine klare Zuordnung schaffen. Der erste Schritt in Richtung eindeutiger Hostnamen war die Gründung des UUCP Mapping Project. Es ist an der Rutgers University (USA) zu Hause und registriert alle offiziellen UUCP-Systeme mitsamt Informationen über die UUCP-Nachbarn jedes Systems und ihrer geographischen Position und stellt sicher, daß kein Name doppelt belegt wird. Die vom Mapping Project gesammelten Informationen werden in den Usenet Maps veröffentlicht und regelmäßig über das Usenet verteilt. Ein typischer Systemeintrag in einer Map sieht so aus (ohne Kommentare):1 moria

bert(DAILY/2),

swim(WEEKLY)

Dieser Eintrag besagt, daß moria eine Verbindung zu bert besitzt, die mindestens zweimal täglich aufgebaut wird, sowie eine mit swim, die einmal wöchentlich angerufen wird. Wir werden uns weiter unten noch etwas ausführlicher mit dem Format der Map-Dateien befassen. Mit Hilfe der Verbindungsinformationen in den Maps können Sie automatisch den vollen Pfad von Ihrem System zu jedem beliebigen Zielsystem erzeugen. Diese Pfade werden normalerweise in einer Datei namens paths oder pathalias aufbewahrt. Angenommen, Sie können von Ihrem System aus bert über ernie erreichen, dann sähe der aus obigem Map-Schnipsel erzeugte pathalias-Eintrag für moria so aus: moria

ernie!bert!moria!%s

Wenn Sie nun eine Mail an [email protected] schicken, wird Ihr MTA die oben gezeigte Route auswählen und die Nachricht mit dem Envelope bert!moria!janet an ernie schicken. Eine pathalias-Datei aus den vollständigen Usenet Maps zu generieren ist allerdings kein besonders genialer Einfall. Die darin enthaltenen Informationen geben die realen Verhältnisse nur sehr ungenau wieder und sind auch nicht immer auf dem neuesten Stand. Aus diesem Grunde erzeugen nur einige der größten Hosts ihre paths-Datei aus den vollständigen UUCP-World-Maps. Die meisten beschränken sich auf Routing-Informationen über Systeme in ihrer Nachbarschaft und leiten Nachrichten an

Systeme, die sich nicht in ihren Listen finden, an einen “Smart Host” weiter, der über umfangreichere Informationen verfügt. Diese Technik nennt sich Smart-Host-Routing. Systeme, die nur einen UUCP-Link haben (sogenannte Leaf-Sites), führen kein eigenes Routing durch, sondern überlassen dies ganz ihrem Smart Host.

UUCP und RFC-822 Die bis heute beste Medizin gegen Probleme beim Mail-Routing in UUCP-Netzen ist bis dato die Übernahme des Domainnamen-Systems in UUCP-Netzwerke. Natürlich können Sie über UUCP keine Name-Server befragen. Nichtsdestotrotz haben sich viele UUCP-Systeme zu kleinen Domains zusammengeschlossen, die ihr Mail-Routing untereinander abstimmen. In den Maps geben diese Domains dann ein oder zwei Maschinen als ihre Mail-Gateways bekannt, so daß nicht jede einzelne Maschine einen eigenen Map-Eintrag haben muß. Die Gateways bearbeiten alle ein- und ausgehenden Nachrichten der Domain, so daß das interne Routing für die Außenwelt vollständig unsichtbar ist. Das funktioniert insbesondere im Zusammenspiel mit dem oben beschriebenen Smart-Host-Routing sehr gut. Nur das Gateway selbst muß über globale Routing-Informationen verfügen; kleinere Systeme kommen mit einer kleinen, handgeschriebenen paths-Datei aus, die Routen innerhalb ihrer Domain und zum Mail-Verteiler beschreibt. Selbst die Mail-Gateways brauchen jetzt nicht mehr die gesamte Routing-Information für jedes einzelne UUCP-System der Welt bereitzuhalten. Abgesehen von den gesamten Routing-Informationen ihrer eigenen Domain müssen sie sich nur noch Routen zu ganzen Domains merken. Der folgende pathalias-Eintrag beispielsweise routet alle Mail an Systeme in der Domain sub.org zum System smurf: .sub.org

swim!smurf!%s

Eine Nachricht an [email protected] wird mit der Envelope-Adresse smurf!jones!claire an swim gesendet. Die hierarchische Organisation des Namensraums im DNS erlaubt es einem Mail-Server jetzt auch, spezifische Routen mit weniger spezifischen zu kombinieren. So kann zum Beispiel ein Server in Frankreich spezifische Routen für die Subdomains von fr kennen, aber Mails an die Hosts der us-Domain über einen Server in den USA routen. Auf diese Weise reduziert das domainorientierte Routing (wie diese Technik genannt wird) die Größe der Routing-Tabellen und den administrativen Aufwand. Der größte Vorteil der Verwendung von Domainnamen in einer UUCP-Umgebung ist aber, daß Adressen nun konform zu RFC-822 sind und damit der Austausch mit dem Internet erheblich einfacher wird. Viele UUCP-Domains haben heute bereits einen direkten Link zu einem Internet-Gateway, das ihnen als Smart Host dient. Zum einen ist der Transport von Mails übers Internet wesentlich schneller, zum anderen ist die Routing-Information wesentlich zuverlässiger, da Internet-Hosts statt auf Usenet Maps auf DNS zurückgreifen können. Um vom Internet aus erreichbar zu sein, muß eine UUCP-Domain über ihr Internet-Gateway einen MX-Record für sich bekanntgeben (MX-Records wurden oben im Abschnitt Mail-Routing im Internet beschrieben). Angenommen, moria gehört zur Domain orc-net.org und gcc2.groucho.edu dient als ihr Internet-Gateway. moria benutzt gcc2 dann als Smart Host, so daß Nachrichten an Systeme außerhalb der Domain übers Internet ausgeliefert werden. Umgekehrt gibt gcc2 einen MX-Record für *.orcnet.org bekannt und liefert alle ankommenden Mails für orcnet-Systeme an moria aus. Der Stern in *.orcnet. org ist ein Wildcard, das zu allen Hosts in dieser Domain paßt, denen kein anderer Record zugeordnet wurde. Das sollte normalerweise nur für reine UUCP-Domains zutreffen. Das einzige verbleibende Problem ist, daß die UUCP-Transportprogramme mit voll qualifizierten Domainnamen nichts anfangen können. Die meisten UUCP-Pakete kommen nur mit Namen bis zu acht Zeichen zurecht, einige sogar mit noch weniger. Die Benutzung von nichtalphanumerischen Zeichen wie Punkten steht für die meisten sowieso außer Frage. Aus diesem Grunde ist eine Abbildung der RFC-Namen auf UUCP-Hostnamen nötig. Diese Abbildung ist aber vollständig abhängig von der Implementierung. Eine gängige Methode, FQDNs auf UUCP-Namen abzubilden, ist die Verwendung der pathalias-Datei. moria.orcnet.org

ernie!bert!moria!%s

Dies erzeugt aus einer Adresse, die einen voll qualifizierten Domainnamen angibt, einen reinen UUCP-Bang-Path. Einige MailProgramme stellen hierfür eine spezielle Datei bereit; sendmail beispielsweise verwendet uucpxtable.

Beim Versenden von Nachrichten aus einem UUCP-Netz ins Internet ist manchmal die umgekehrte Vorgehensweise notwendig (auch “Domainisieren” genannt). Solange der Absender der Mail den voll qualifizierten Domainnamen in der Zieladresse verwendet, kann dieses Problem vermieden werden, indem die Mail-Software den Domainnamen nicht aus dem Envelope entfernt, sondern unverändert an den Smart Host weiterreicht. Allerdings gibt es immer noch UUCP-Systeme, die keiner Domain angehören. Sie werden in der Regel “domainisiert”, d.h. um die Pseudo-Domain uucp ergänzt. In UUCP-Netzen stellt die pathalias-Datei die wesentliche Quelle für Routing-Informationen dar. Ein typischer Eintrag sieht so aus: moria.orcnet.org

ernie!bert!moria!%s moria

ernie!bert!moria!%s

Hierbei sind der Systemname und die Pfadangabe jeweils durch Tabulatorzeichen -voneinander getrennt. Dieser Eintrag bewirkt, daß Mails an moria über ernie und bert ausgeliefert werden. Sowohl der FQDN als auch der UUCP-Name von moria müssen angegeben werden, wenn der Mailer keine andere Möglichkeit hat, diese Namen aufeinander abzubilden. Wenn Sie alle Nachrichten an die Hosts innerhalb einer Domain an deren Mail-Exchanger delegieren wollen, können Sie in einer pathalias-Datei auch einen Pfad eintragen, indem Sie den Domainnamen mit vorangestelltem Punkt als Ziel angeben. Wenn zum Beispiel alle Systeme in sub.org über swim!smurf erreichbar sind, könnte der pathalias-Eintrag so aussehen: .sub.org

swim!smurf!%s

Das Schreiben einer pathalias-Datei ist aber nur zumutbar, wenn Ihr System selbst nicht viel Routing vornehmen muß. Wenn Sie Routing für eine große Anzahl von Systemen durchführen müssen, ist es angebracht, die Pfade mit dem Programm pathalias aus Map-Dateien zu generieren. Maps lassen sich viel leichter auf dem neuesten Stand halten, da Sie ein System einfach dadurch hinzufügen oder entfernen können, indem Sie seinen Map-Eintrag editieren und die Pfadinformationen neu erzeugen lassen. Obwohl die vom Usenet Mapping Project veröffentlichten Maps kaum noch fürs Routing benutzt werden, ist es für kleinere Netze durchaus noch sinnvoll, ihre Routing-Informationen über ihre eigenen Maps auszutauschen. Eine Map-Datei besteht hauptsächlich aus einer Liste von Systemen und ihren unmittelbaren Nachbarn. Der Systemname beginnt in Spalte eins und wird gefolgt von einer Liste von Links (mit Kommata als Trennzeichen). Die Liste kann sich über mehrere Zeilen erstrecken, wenn die Fortsetzungszeilen mit einem Tabulatorzeichen beginnen. Jede Link-Angabe besteht aus dem Namen des Nachbarsystems und den in Klammern angegebenen “Kosten” des Links. Bei diesen Kosten handelt es sich um arithmetische Ausdrücke aus Zahlen und Symbolen wie DAILY oder WEEKLY. Zeilen, die mit einem Doppelkreuz (#) beginnen, sind Kommentare und werden ignoriert. Betrachten wir moria, das zweimal täglich eine Verbindung zu swim.twobirds.com aufbaut und einmal pro Woche mit bert.sesame.com. Die Verbindung zu bert verwendet ein langsames 2.400-Bps-Modem. morias Map-Eintrag sähe dann so aus: moria.orcnet.org bert.sesame.com(DAILY/2), moria.orcnet.org = moria

swim.twobirds.com(WEEKLY+LOW)

Die letzte Zeile macht moria auch unter dessen UUCP-Namen bekannt. Beachten Sie, daß es tatsächlich DAILY/2 heißen muß, da zwei Anrufe täglich die Kosten für diesen Link halbieren. Anhand der Informationen aus solchen Map-Dateien kann pathalias optimale Wege zu jedem in der paths-Datei aufgeführten System berechnen und daraus eine pathalias-Datei erzeugen, die direkt für das Routing zu diesen Systemen verwendet werden kann. pathalias stellt daneben noch eine ganze Reihe anderer Features bereit, wie das “Verstecken” einer Reihe von Systemen hinter einem Gateway (engl. site hiding). Details hierzu entnehmen Sie bitte der Manpage pathalias. Dort finden Sie auch eine vollständige Liste der Link-Kosten. Die Kommentare in einer Map-Datei enthalten im allgemeinen zusätzliche Informationen über die beschriebenen Systeme. Diese Angaben müssen in einem sehr rigiden Format gemacht werden, so daß sie später automatisch weiterverarbeitet werden können. So benutzt zum Beispiel das Programm uuwho eine aus Map-Dateien erzeugte Datei, um diese Informationen in einem übersichtlichen Format anzuzeigen. Wenn Sie Ihr System bei einer Organisation registrieren lassen, die Map-Dateien an

ihre Mitglieder verteilt, müssen Sie in der Regel immer einen solchen Map-Eintrag ausfüllen. Nachfolgend ein Beispieleintrag (tatsächlich ist es der für Olafs System): #N monad, monad.swb.de, monad.swb.sub.org #S AT 486DX50; Linux 0.99 #O private #C Olaf Kirch #E [email protected] #P Kattreinstr. 38, D-64295 Darmstadt, FRG #L 49 52 03 N / 08 38 40 E #U brewhq #W [email protected] (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993 # monad brewhq(DAILY/2) # Domains monad = monad.swb.de monad = monad.swb.sub.org

Der Leerraum nach den ersten zwei Zeichen ist ein Tabulatorzeichen. Die Bedeutung der meisten Felder ist recht offensichtlich; eine detaillierte Beschreibung erhalten Sie dort, wo Sie sich haben registrieren lassen. Den größten Spaß macht es, das Feld L auszufüllen: Es gibt Ihre Position in geographischer Länge und Breite an und wird dazu benutzt, die PostscriptKarten zu erzeugen, die die Usenet-Systeme für jedes Land bzw. weltweit zeigen.2

1.

Die Maps für vom Projekt registrierte Systeme werden über die Newsgruppe comp.mail.maps verteilt. Andere Organisationen veröffentlichen unter Umständen separate Maps für ihre eigenen Netzwerke.

2.

Sie werden regelmäßig in news.lists.ps-maps veröffentlicht. Seien Sie vorsichtig — sie sind RIESIG.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Konfiguration von elm elm steht für “electronic mail” und ist eins der eher einleuchtend benannten UNIX-Tools. Es besitzt eine bildschirmorientierte Benutzerschnittstelle mit einer guten Hilfefunktion. Wir werden uns hier nicht damit befassen, wie Sie elm bedienen, sondern nur mit seiner Konfiguration. Theoretisch können Sie elm benutzen, ohne sich in irgendeiner Weise um die Konfiguration zu kümmern — wenn Sie Glück haben. Es gibt aber einige Optionen, die Sie unbedingt einstellen müssen, auch wenn sie selten benutzt werden. Wenn Sie elm aufrufen, liest es verschiedene Konfigurationsvariablen aus der Datei elm.rc im Verzeichnis /etc/elm. Anschließend versucht es, .elm/elmrc in Ihrem Home-Verzeichnis zu lesen. Diese Datei schreiben Sie gewöhnlich nicht selbst. elm erzeugt sie für Sie, wenn Sie die elm-Option “Save new options” anwählen. Alle Optionen aus der privaten Konfigurationsdatei elmrc lassen sich auch im globalen elm.rc setzen. Die meisten Einstellungen in Ihrer privaten elmrc überschreiben diejenigen der globalen Datei.

Globale elm-Optionen In der globalen elm.rc-Datei müssen Sie Optionen setzen, die den Namen Ihres Hosts betreffen. In der virtuellen Brauerei zum Beispiel enthält die Datei für vlager folgende Einträge: # # Lokaler Hostname hostname = vlager # # Domainname hostdomain = .vbrew.com # # Voll qualifizierter Domainname (FQDN) hostfullname = vlager.vbrew.com

Diese Optionen legen fest, was sich elm unter dem lokalen Hostnamen vorstellt. Obwohl diese Information nur selten benötigt wird, sollten Sie diese Optionen trotzdem einstellen. Es sei darauf hingewiesen, daß diese Angaben nur wirksam werden, wenn sie in der globalen Konfigurationsdatei auftauchen; im privaten elmrc werden sie ignoriert.

Nationale Zeichensätze Es wurden eine Reihe von Standards und RFCs entwickelt, die den RFC-822-Standard dahingehend änderten, daß Mails verschiedene Arten von Daten enthalten können, wie zum Beispiel reinen Text, Postscript-Dateien, binäre Daten usw. Diese Standards werden oft unter dem Begriff MIME zusammengefaßt. MIME steht für Multipurpose Internet Mail Extensions oder Mehrzweckerweiterungen für Internet-Mail. Unter anderem kann mit einer solchen Erweiterung dem Empfänger mitgeteilt werden, ob eine Nachricht Sonderzeichen aus anderen Zeichensätzen als dem US-ASCII-Standard enthält, wie zum Beispiel französische Akzente oder deutsche Umlaute. Diese Sonderzeichen werden von elm in gewissem Umfang unterstützt. Linux verwendet zur Darstellung von Zeichen intern einen Zeichensatz namens ISO-8859-1, was auch die offizielle Bezeichnung des ISO-Standards ist (auch als Latin-1 bekannt). Jede Nachricht, die Zeichen aus diesem Zeichensatz benutzt, sollte die folgende Zeile in ihrem Header enthalten: Content-Type: text/plain; charset=iso-8859-1

Das empfangende System sollte diese Zeile auswerten und für die Ausgabe der Nachricht geeignete Maßnahmen ergreifen. Für Nachrichten vom Typ text/plain hat das Attribut charset per Voreinstellung den Wert us-ascii. Um Nachrichten mit anderen Zeichensätzen als US-ASCII darstellen zu können, muß elm wissen, wie diese Zeichen ausgegeben werden sollen. Wenn elm eine Nachricht mit einem anderen charset-Attribut als us-ascii erhält (oder einem anderen Typ als text/plain), versucht es die Nachricht vom Programm metamail ausgeben zu lassen. Mails, die metamail benötigen, werden im Übersichtsmenü mit einem M in der ersten Spalte angezeigt. Da Linux von Haus aus ISO-8859-1 versteht, ist es nicht nötig, metamail für die Ausgabe der Nachricht aufzurufen. Wenn elm weiß, daß das Ausgabe-Terminal ISO-8859-1 versteht, ruft es metamail nicht auf, sondern gibt die Nachricht direkt aus. Das können Sie über folgende Option in der globalen elm.rc einstellen: displaycharset = iso-8859-1

Sie sollten diese Option übrigens immer setzen, auch wenn Sie nie Nachrichten senden oder empfangen, die Nicht-ASCII-Zeichen enthalten. Denn mittlerweile ist es üblich, die Mailer so zu konfigurieren, daß Content-Type: immer im Mail-Header erscheint, egal ob ASCII-Mails verschickt werden oder nicht. Mit der Einstellung dieser Option in elm.rc ist es allerdings noch nicht getan. Wenn elm eine Nachricht mit seinem eingebauten Pager darstellt, ruft es für jedes Zeichen eine Bibliotheksfunktion auf, um festzustellen, ob es druckbar ist oder nicht. Im Normalfall erkennt diese Funktion nur ASCII-Zeichen als druckbar an, so daß alle anderen Zeichen nur als ^? ausgegeben werden. Dieses Problem beseitigen Sie dadurch, daß Sie die Umgebungsvariable LC_CTYPE auf ISO-8859-1 setzen. Das teilt der Bibliothek mit, daß sie Latin-1-Zeichen als druckbar erkennen soll. Die Unterstützung für dieses und andere Features ist seit Version 4.5.8 der LinuxStandardbibliothek vorhanden.

Wenn Sie in Ihren eigenen Mails Sonderzeichen aus ISO-8859-1 verwenden, sollten Sie sicherstellen, daß in Ihrem elm.rc auch die folgenden zwei Variablen gesetzt sind: charset = iso-8859-1 textencoding = 8bit

Das veranlaßt elm, den Zeichensatz im Mail-Header als ISO-8859-1 einzutragen und alle Zeichen als 8-BitWerte zu übertragen. Im Normalfall kürzt elm alle Zeichen auf 7 Bit. Natürlich können alle hier besprochenen zeichenbezogenen Optionen auch in der privaten elmrc-Datei statt in der globalen gesetzt werden. Somit kann jeder Benutzer seine individuellen Einstellungen vornehmen, wenn ihm die entsprechenden globalen nicht gefallen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 18 Sendmail

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Eine Einführung in sendmail Es wird behauptet, daß man kein echter UNIX-Systemadministrator sei, solange man noch keine sendmail.cf-Datei editiert hat. Es wird auch behauptet, daß man verrückt sei, wenn man es ein zweites Mal tut. sendmail ist ein unglaublich mächtiges Programm. Es ist aber auch unglaublich schwer zu lernen und zu verstehen. Jedes Programm, dessen endgültige Referenz (sendmail von Bryan Costales und Eric Allman, herausgegeben von O'Reilly) über 1000 Seiten lang ist, schreckt die meisten Leute zu Recht ab. Zum Glück sind neuere Versionen von sendmail da anders. Sie befreien Sie davon, die kryptische sendmail.cf-Datei bearbeiten zu müssen. Sie enthalten ein Konfigurationshilfsmittel, das Ihnen aus erheblich einfacheren Makrodateien eine geeignete sendmail.cf-Datei erzeugt. Damit brauchen Sie die komplizierte Syntax der sendmail.cf-Datei nicht mehr zu begreifen. Statt dessen hantieren Sie nur noch mit Listeneinträgen, zum Beispiel Namen von Eigenschaften, die Sie in Ihre Konfiguration aufnehmen wollen, und Parametern, die das Verhalten der Eigenschaften vorgeben. Ein altbewährtes Unix-Utility namens m4 nimmt dann Ihre Makro-Konfigurationsdaten, verbindet sie mit Daten aus Template-Dateien, die die eigentliche sendmail.cf-Syntax enthalten, um daraus Ihre sendmail.cf-Datei zu erzeugen.

Dieses Kapitel enthält eine Einführung in sendmail und beschreibt, wie Sie es installieren, konfigurieren und testen. Als Anwendungsbeispiel nehmen wir unsere virtuelle Brauerei. Wenn Ihnen die hier präsentierten Informationen die Aufgabe der Konfiguration von sendmail erleichtern, trauen Sie sich vielleicht eher zu, komplexere Konfigurationen auf eigene Faust durchzuführen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

sendmail installieren Das Mail-Transportprogramm sendmail ist in den meisten Linux-Distributionen bereits in vorgefertigter Form enthalten. Die Installation ist in diesem Fall relativ einfach. Trotzdem gibt es gute Gründe, den kompletten Quellcode neu zu kompilieren, besonders dann, wenn Sie auf Sicherheit bedacht sind. Das sendmail-Programm ist äußerst komplex und daher im Laufe der Jahre in den Verruf gekommen, Bugs zu enthalten, die die Systemsicherheit gefährden. Eines der bekanntesten Beispiele ist der RTM-Internet-Wurm, der in alten Versionen von sendmail eine Buffer-OverflowSchwachstelle für sein schädliches Machwerk ausnutzte. Darauf waren wir bereits kurz in Kapitel 9 TCP/IP-Firewall, eingegangen. Die meisten Sicherheitslücken, die auf Buffer Overflows basieren, entstanden erst dadurch, daß die sendmail-Kopien auf allen Plattformen identisch waren und dieselben Verzeichnispfade für die Konfigurationsdateien verwendeten. Genau das ist bei den Binärversionen von sendmail für Linux auch der Fall. Wenn Sie den Quellcode von sendmail selbst kompilieren, können Sie die Verzeichnispfade individuell wählen und dadurch die eben genannten Sicherheitsrisiken vermindern. Die modernen Varianten von sendmail sind weniger verwundbar, da sie einer sehr gründlichen Überprüfung unterzogen wurden, seitdem Sicherheitsaspekte in der Internet-gemeinde immer wichtiger wurden. Der aktuelle Quellcode-Archiv zu sendmail kann von ftp.sendmail.org per anonymous FTP bezogen werden.

Die Kompilierung ist sehr einfach, da Linux im Quellcode von sendmail direkt unterstützt wird. Die folgenden Schritte sind dazu notwendig (hier für sendmail Version 8.9.3): # cd /usr/local/src # tar xvfz sendmail.8.9.3.tar.gz # cd src # ./Build

Sie benötigen root-Privilegien, um die Installation der fertigen Binärdateien abzuschließen: # cd obj.Linux.2.0.36.i586 # make install

Damit wird die Binärdatei von sendmail im Verzeichnis /usr/sbin/ installiert, dazu diverse symbolische Links darauf im Verzeichnis /usr/bin. Über diese Links sprechen wir noch, wenn wir uns mit den üblichen Aufgaben beim Betrieb von sendmail beschäftigen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Übersicht der Konfigurationsdateien Früher wurde sendmail mittels einer System-Konfigurationsdatei eingerichtet, häufig /etc/mail/sendmail.cf oder /etc/sendmail.cf in älteren Distributionen oder sogar /usr/lib/sendmail.cf. Sie wurde in einer Sprache abgefaßt, die Sie wohl noch nie gesehen haben. Ein Versuch, sendmail.cf zu editieren, um das Verhalten von sendmail individuell anzupassen, kann in einer geradezu deprimierenden Erfahrung enden. Heutzutage sind alle Konfigurationsdetails von sendmail makrobasiert und lassen sich in einer leicht verständlichen Syntax beschreiben. Die Makromethode erzeugt Konfigurationen, die für die meisten Installationen völlig ausreichend sind. Wenn Sie in einer komplexeren Umgebung arbeiten, haben Sie immer noch die Möglichkeit, an der resultierenden sendmail.cf-Datei Feineinstellungen durchzuführen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Dateien sendmail.cf und sendmail.mc Der m4-Makroprozessor verarbeitet die Makro-Konfigurationsdatei des lokalen Systemadministrators und erzeugt daraus eine sendmail.cf-Datei. Diese Makro-Konfigurationsdatei werden wir im folgenden als sendmail.mc bezeichnen. Der Konfigurationsprozeß besteht im Grunde nur darin, daß eine geeignete sendmail.mc-Datei erzeugt wird, die die von Ihnen gewünschte Konfiguration mittels Makros beschreibt. Diese Makros sind Ausdrücke, die der m4-Makroprozessor versteht und in die komplizierte sendmail.cf-Syntax übersetzt. Ein Makro besteht jeweils aus dem Makronamen (der Text in Großbuchstaben am Anfang), was mit einem Funktionsnamen in einer Programmiersprache vergleichbar ist, und aus einigen Parametern (der Text in Klammern), die für die Expandierung benutzt werden. Die Parameter können wörtlich in die sendmail.cf-Ausgabe übernommen werden, oder sie beeinflussen lediglich die weitere Makroverarbeitung. Für eine minimale Konfiguration (UUCP oder SMTP, bei dem alle nichtlokalen Mails an einen direkt angeschlossenen Smart Host geleitet werden) reicht bereits ein 10- oder 15-Zeiler aus (ohne Kommentare).

Zwei sendmail.mc-Beispiele Wenn Sie ein Administrator mehrerer verschiedener Mail-Hosts sind, werden Sie Ihre Konfigurationsdatei nicht sendmail.mc nennen, sondern der üblichen Praxis folgen und sie nach dem Hostnamen benennen, in unserem Fall z.B. vstout.m4. Der Name spielt keine Rolle, solange die Ausgabedatei sendmail.cf heißt. Wenn Sie für jeden Host einen eindeutigen Namen für die Konfigurationsdatei wählen, können Sie alle Konfigurationsdateien in einem einzelnen Verzeichnis unterbringen, was Ihnen die administrative Arbeit erleichtert. Lassen Sie uns jetzt einen Blick auf zwei Beispiel-Makro-Konfigura-tionsdateien werfen, damit wir wissen, wo es langgeht. Die meisten sendmail-Konfigurationen benutzen heutzutage nur SMTP. sendmail für SMTP zu konfigurieren ist sehr einfach. Tabelle 18.1 geht von der Existenz eines DNS-Name-Servers aus, der für die Namensauflösungen zuständig ist und versucht, alle anfallenden Mails nur mit SMTP zu senden und zu empfangen. Beispiel 18.1: Beispiel-Konfigurationsdatei vstout.smtp.m4 divert(-1) # # Beispiel-Konfigurationsdatei für vstout - nur SMTP # divert(0) VERSIONID(`@(#)sendmail.mc 8.9 (Linux) 01/10/98´) OSTYPE(`linux´) # # Unterstützung für das lokale Mail-Transportprotokoll und SMTP MAILER(`local´) MAILER(`smtp´) # FEATURE(rbl) FEATURE(access_db) #

Ende

Eine sendmail.mc-Datei für vstout in der virtuellen Brauerei wird in Tabelle 18.2 gezeigt. vstout benutzt SMTP zur Kommunikation mit allen Hosts im Brauerei-LAN. Sie sehen die Gemeinsamkeiten mit der bereits beschriebenen allgemeinen Konfigurationsdatei, die nur SMTP unterstützt. Außerdem sendet die vstout-Konfiguration alle Mails für andere Bestimmungsorte über UUCP an moria, ihren Internet-Mail-Verteiler. Außerdem bewirkt die vstout-Konfiguration, daß alle Mails an andere Bestimmungsorte mittels UUCP an den Internet-Mail-Verteiler moria gesandt werden. Beispiel 18.2: Beispiel-Konfigurationsdatei vstout.uucpsmtp.m4 divert(-1) # # Beispiel-Konfigurationsdatei für vstout # divert(0) VERSIONID(`@(#)sendmail.mc 8.7 (Linux) 3/5/96´) OSTYPE(`linux´) dnl # moria ist unser Smart Host und benutzt den "uucp-newTransport". define(`SMART_HOST´, `uucp-new:moria´) dnl # Unterstützung für lokale, SMTP- und UUCPMail-Transportprotokolle. MAILER(`local´) MAILER(`smtp´) MAILER(`uucp´) LOCAL_NET_CONFIG # Diese Regel stellt sicher, daß alle lokalen Mails mittels SMTP # zugestellt werden. Alles andere läuft über den Smart Host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3 dnl # FEATURE(rbl) FEATURE(access_db) # Ende

Wenn Sie diese beiden Konfigurationen vergleichen, können Sie herausfinden, welchen Zwecken die Konfigurationsparameter dienen. Wir besprechen sie alle in Kürze.

Häufig genutzte Parameter in sendmail.mc Einige Einträge in der sendmail.mc-Datei werden immer wieder benötigt, andere können entfallen, wenn Sie mit den Standardvorgaben zufrieden sind. Die Definitionen in sendmail.mc nimmt man im allgemeinen in folgender Reihenfolge vor: 1. VERSIONID 2. OSTYPE 3. DOMAIN 4. FEATURE 5. Lokale Makrodefinitionen 6. MAILER 7. LOCAL_*-Regelsätze Alle diese Definitionen besprechen wir der Reihe nach in den folgenden Abschnitten. Für die Erläuterungen greifen wir gegebenenfalls auf unsere Beispiele in Tabelle 18.1 und Tabelle 18.2 zurück. Kommentare Alle Zeilen in der Eingabedatei sendmail.mc, die mit dem Hashzeichen (#) beginnen, werden von m4 nicht analysiert, sondern unverändert in die Ausgabedatei sendmail.cf übernommen. Sie können damit Kommentare zu Konfigurationsdetails angeben, die sowohl in der Eingabe- als auch in der Ausgabedatei erscheinen. Für Kommentare in der sendmail.mc-Datei, die nicht in sendmail.cf erscheinen sollen, benutzen Sie die m4-Schlüsselwörter divert und dnl. Mit divert(-1) läßt sich die Ausgabe vollständig unterbinden und mit divert(0) wieder freischalten; alle dazwischenliegenden Ausgabezeilen werden ignoriert. In unserem Beispiel haben wir diesen Befehl benutzt, um einen Kommentar einzufügen, der nur in sendmail.mc erscheint. Um dasselbe für eine einzelne Zeile zu erreichen, benutzen Sie dnl. Damit wird der Bereich vom Beginn des Wortes “dnl” bis zum (in der gleichen Zeile) folgenden Zeilenende gelöscht. Auch das haben wir in unserem Beispiel benutzt.

Nun folgen die Standard-Features von m4. Mehr darüber erfahren Sie in den Manpages. VERSIONID und OSTYPE VERSIONID(`@(#)sendmail.mc

8.9 (Linux) 01/10/98´)

Das Makro VERSIONID ist optional und nützlich zur Aufzeichnung der aktuellen Version der Sendmail-Konfiguration in der sendmail.cf-Datei. Dieser Option werden Sie oft begegnen, und wir können sie auch nur empfehlen. Wie auch immer, Sie sollten grundsätzlich folgendes mit angeben: OSTYPE(`linux´)

Das ist die vielleicht wichtigste Definition. Das OSTYPE-Makro bewirkt, daß eine Datei mit diversen Definitionen eingebunden wird, die sinnvolle Standardvorgaben für Ihr Betriebssystem enthalten. Die meisten Definitionen in dieser Makrodatei legen die Verzeichnisse verschiedener Konfigurationsdateien fest, dazu Verzeichnisse und Argumente für MailProgramme sowie Verzeichnisse, in denen sendmail die Nachrichten abspeichert. Der Standard-Quellcode von sendmail enthält unter anderem eine solche Datei für Linux, welche in unserem vorigen Beispiel eingebunden würde. Einige LinuxDistributionen, insbesondere Debian, enthalten eine eigene Definitionsdatei, die vollständig Linux-FHS-konform ist. Wenn Ihre Distribution auch eine solche Datei enthält, sollten Sie vielleicht lieber diese benutzen als die vorgegebene. Die OSTYPE-Definition sollte in Ihrer sendmail.mc-Datei möglichst ganz am Anfang erscheinen. Viele andere Definitionen hängen von dieser Option ab. DOMAIN Das DOMAIN-Makro ist dann nützlich, wenn Sie eine Vielzahl von Maschinen im gleichen Netzwerk einheitlich konfigurieren wollen. Wenn Sie es nur mit wenigen Hosts zu tun haben, ist der Aufwand vielleicht etwas zu hoch. Die Konfiguration betrifft normalerweise Einträge wie die Namen von Mail-Verteilern oder -Hubs, die alle Hosts Ihres Netzwerks benutzen. Die Standardinstallation enthält ein Verzeichnis mit m4-Makro-Templates, mit denen der Konfigurationsprozeß in Gang gebracht wird. Dieses Verzeichnis ist normalerweise /usr/share/sendmail.cf oder so ähnlich. Darin befindet sich ein Unterverzeichnis namens domain, das domainspezifische Konfigurations-Templates enthält. Um das DOMAIN-Makro anzuwenden, müssen Sie Ihre eigene Makrodatei erzeugen, die die für Ihr System erforderlichen Standarddefinitionen enthält, und sie im Unterverzeichnis domain abspeichern. Im allgemeinen geben Sie hier nur diejenigen Makrodefinitionen an, die ausschließlich für Ihre Domain gelten, zum Beispiel Definitionen von Smart Hosts oder Mail-Verteilern. Sie sind aber nicht darauf beschränkt. Der Quellcode von sendmail enthält eine Reihe von beispielhaften Domain-Makro-dateien, die Sie für Ihre eigenen Zwecke anpassen können. Wenn Sie Ihre Domain-Makrodatei als /usr/share/sendmail.cf/domain/vbrew.m4 gespeichert haben, binden Sie Definitionen in Ihrer sendmail.mc wie folgt ein: DOMAIN(`vbrew´)

FEATURE Mit dem FEATURE-Makro binden Sie vordefinierte sendmail-Features in Ihre Konfiguration ein. Diese Features erleichtern die Anwendung der unterstützten Konfigurationen ungemein. Es gibt viele davon; in diesem Kapitel gehen wir allerdings nur auf einige besonders nützliche und wichtige ein. Umfangreiche Informationen über die verfügbaren Features finden Sie in der Datei README im Unterverzeichnis cf des Quellcode-Archivs. Um eines der aufgeführten Features anzuwenden, fügen Sie eine Zeile wie die folgende in Ihre sendmail.mc ein: FEATURE(name)

Dabei bezeichnet name den Namen des Features. Für einige Features gibt es einen optionalen Parameter. Wenn Sie einen anderen Vorgabewert benutzen wollen, sollten Sie einen Eintrag folgender Form verwenden: FEATURE(name, param)

Dabei bezeichnet param den zu übergebenden Parameter. Lokale Makrodefinitionen Die Standard-Makro-Konfigurationsdateien von sendmail enthalten eine Fülle von Variablen, mit denen Sie Ihre Konfiguration anpassen können. Sie werden als lokale Makrodefinitionen bezeichnet. Viele davon sind in der README-Datei im Unterverzeichnis cf des sendmail-Quellcode-Archivs enthalten. In der Regel rufen Sie diese lokalen Makrodefinitionen auf, indem Sie ihren Namen angeben sowie ein Argument, das den Wert repräsentiert, den Sie in die vom Makro verwendete Variable eintragen wollen. Einige der geläufigeren lokalen Makrodefinitionen erkunden wir in den Beispielen, die wir später in diesem Kapitel vorstellen. Definition von Mail-Transportprotokollen Wenn Sie sendmail dazu bringen wollen, Mails auf irgendeine andere Weise als lokal zu transportieren, müssen Sie ihm ein Transportprotokoll angeben. Mit dem MAILER-Makro ist das ganz einfach. Die aktuelle sendmail-Version unterstützt eine Vielzahl von Mail-Transportprotokollen. Einige von ihnen befinden sich noch im experimentellen Stadium, andere werden eher selten genutzt. In unserem Netzwerk brauchen wir SMTP, um Mails zwischen den Hosts unseres LANs zu transportieren, und UUCP, um Mails von bzw. zu unserem Smart Host zu übertragen. Dazu geben wir einfach beide Protokolle smtp und uucp an. Der local-Mail-Transport ist standardmäßig enthalten, kann aber auf Wunsch zur Verdeutlichung trotzdem definiert werden. Wenn Sie sowohl smtp als auch uucp in Ihrer Konfiguration angeben, müssen Sie den smtp-Mailer immer zuerst definieren. Die geläufigeren Transportprotokolle, die Sie mit dem MAILER-Makro definieren können, sind in der folgenden Liste aufgeführt: local Dieser Transport umfaßt sowohl den lokalen Mail-Verteiler, mit dem Mails in die Mailbox der Benutzer auf dieser Maschine gesendet werden, als auch den prog-Mailer, mit dem Nachrichten an lokale Programme gesendet werden. Dieser Transport ist standardmäßig enthalten. smtp Dieser Transport implementiert das Simple Mail Transport Protocol (SMTP), das häufigste im Internet eingesetzte Transportmittel für E-Mail. Wenn Sie diesen Transport einbinden, werden insgesamt vier Mailer konfiguriert: smtp (basic SMTP), esmtp (Extended SMTP), smtp8 (8bit binary clean SMTP) und relay (speziell entwickelt für die Weiterleitung von Nachrichten zwischen Hosts). uucp Der uucp-Transport bietet Unterstützung für zwei Mailer: uucp-old, das traditionelle UUCP, und uucp-new, das in einem Transfer gleich mehrere Empfänger bedienen kann. usenet Mit diesem Mailer können Sie Mail-Nachrichten direkt an Usenet-artige News-Netzwerke senden. Jede lokale Nachricht, die an eine Adresse der Domain news.group.usenet gerichtet ist, wird an das News-Netzwerk der

Newsgruppe news.group weitergereicht. fax Wenn Sie die HylaFAX-Software installiert haben, können Sie mit diesem Mailer direkt E-Mails an sie senden. Damit können Sie ein E-Mail-Fax-Gateway aufbauen. Als dieses Buch geschrieben wurde, befand sich dieses Feature noch im Experimentierstadium. Mehr Informationen erhalten Sie unter http://www.vix.com/hylafax/. Es gibt auch noch andere Mail-Protokolle wie pop, procmail, mail11, phquery und cyrus. Sie sind alle nützlich, aber nicht sehr verbreitet. Wenn sie Ihre Neugier geweckt haben, können Sie darüber im sendmail-Buch oder in der Dokumentation zum Quellcode nachlesen. Mail-Routing für lokale Hosts konfigurieren Die Konfiguration für die virtuelle Brauerei ist vielleicht komplizierter als bei vielen anderen Systemen. Die meisten Systeme benutzen nur SMTP und brauchen sich mit UUCP überhaupt nicht auseinanderzusetzen. In unserer Konfiguration haben wir einen “Smart Host” definiert, der für alle ausgehenden Mails zuständig ist. Da wir in unserem lokalen Netzwerk nur SMTP benutzen, müssen wir sendmail darüber in Kenntnis setzen, daß die lokalen Mails nicht über den Smart Host gesendet werden sollen. Mit dem Makro LOCAL_NET_CONFIG können Sie sendmail-Regeln direkt in die erzeugte sendmail.cf einfügen, um festzulegen, wie die lokalen Mails verarbeitet werden sollen. Auf das Überschreiben von Regeln gehen wir später noch ein. Im Moment sollten Sie einfach akzeptieren, daß die Regel, die wir in unserem Beispiel angegeben haben, festlegt, daß alle an die Hosts der Domain vbrew.com gerichteten E-Mails mittels SMTP direkt an die Zielhosts zugestellt werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Datei sendmail.cf erzeugen Wenn Sie Ihre m4-Konfigurationsdatei fertiggestellt haben, müssen Sie daraus die Konfigurationsdatei /etc/mail/sendmail.cf für sendmail erzeugen lassen. Das geht ganz einfach, wie das folgende Beispiel zeigt: # cd /etc/mail # m4 /usr/share/sendmail.cf/m4/cf.m4 vstout.uucpsmtp.mc >sendmail.cf

Diese Anweisung ruft den m4-Makroprozessor auf und übergibt ihm den Namen zweier Makrodefinitionsdateien. m4 verarbeitet die Dateien in der angegebenen Reihenfolge. Die erste Datei ist ein Standard-sendmail-Makro-Template aus dem sendmail-Quellpaket. Die zweite Datei enthält natürlich unsere eigenen Makrodefinitionen. Die Ausgabe dieser Anweisung wird direkt in unsere Zieldatei /etc/mail/sendmail.cf geschrieben. Sie können sendmail nun mit der neuen Konfiguration starten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Rewrite-Regeln interpretieren und schreiben Das wohl mächtigste Feature von sendmail sind die Rewrite-Regeln. Solche Regeln werden von sendmail benutzt, um zu entscheiden, wie eine empfangene Mail verarbeitet werden soll. sendmail läßt die Adressen der Header einer E-Mail einen Satz von Rewrite-Regeln durchlaufen, die als Regelsätze (rulesets) bezeichnet werden. Die Rewrite-Regeln wandeln eine MailAdresse von einer Form in eine andere um. Stellen Sie sich das so vor, als hätten Sie in Ihrem Editor einen Befehl, mit dem Sie alle Textabschnitte, die zu einem bestimmten Suchmuster passen, durch einen anderen Text ersetzen. Jede Regel besteht aus einem linksseitigen (lhs=left hand side) und einem rechtsseitigen (rhs=right hand side) Teil, getrennt durch ein oder mehrere TAB-Zeichen. Wenn sendmail eine Mail verarbeitet, durchsucht es alle Rewrite-Regeln nach einem passenden linksseitigen Teil. Falls die Adresse zu einem dieser Teile paßt, wird sie durch den rechtsseitigen Teil ersetzt und anschließend weiterverarbeitet.

sendmail.cf-Befehle R und S In der sendmail.cf-Datei werden die Regelsätze mit Befehlen im Format Sn definiert. Dabei bezeichnet n der Regelsatz, der als der aktuelle aufgefaßt wird. Die Regeln selbst erscheinen in Anweisungen der Form R. Jede eingelesene R-Anweisung erweitert den aktuellen Regelsatz. Wenn Sie es nur mit der sendmail.mc-Datei zu tun haben, brauchen Sie sich über die S-Befehle nicht den Kopf zu zerbrechen – die Makros erzeugen sie für Sie. Sie müssen (meist) nur die R-Regeln im Rahmen der mc-Dateien manuell codieren. Ein sendmail-Regelsatz hat also folgendes Format: Sn Rlhs rhs Rlhs2 rhs2

Einige nützliche Makrodefinitionen sendmail verwendet intern eine Reihe von Standard-Makrodefinitionen. Davon sind folgende zum Schreiben der Regelsätze am nützlichsten:

$j Der voll qualifizierte Domainname (FQDN) dieses Hostrechners. $w Die Hostnamen-Komponente des FQDN. $m Die Domainnamen-Komponente des FQDN. Diese Makrodefinitionen können wir in unsere Rewrite-Regeln einbinden. Die Konfiguration unserer virtuellen Brauerei benutzt das Makro $m.

Der linksseitige Teil Im linksseitigen Teil einer Rewrite-Regel geben Sie ein Muster an, das auf eine Adresse paßt, die Sie transformieren wollen. Die meisten Zeichen werden direkt überprüft, es gibt aber eine Reihe von Zeichen mit besonderer Bedeutung; sie werden in der nachfolgenden Liste beschrieben. Die Rewrite-Regeln für den linksseitigen Teil sind: $@ Prüft auf exakt null Tokens. $* Prüft auf null oder mehr Tokens. $+ Prüft auf ein oder mehrere Tokens. $Prüft auf genau ein Token. $=x Prüft auf irgendeinen Satz in Klasse x. $~x Prüft auf irgendein Wort, das nicht in Klasse x enthalten ist. Ein Token ist eine durch Leerzeichen begrenzte Zeichenfolge. Leerzeichen können daher nicht Bestandteil eines Tokens sein. Das ist auch gar nicht notwendig, da die Suchmuster flexibel genug sind, um diesem Bedarf gerecht zu werden. Wenn eine Regel eine Adresse überprüft, wird jeder Textabschnitt, der zu einem der Suchmuster im Ausdruck paßt, einer speziellen Variablen zugewiesen, die wir dann im rechtsseitigen Teil der Regel benutzen. Die einzige Ausnahme bildet $@, das auf keine Tokens prüft und daher auch keinen Text produziert, der im rechtsseitigen Teil verwendet werden könnte.

Der rechtsseitige Teil Wenn der linksseitige Teil einer Rewrite-Regel zu einer Adresse paßt, wird der Ausgangstext komplett gelöscht und durch den

rechtsseitigen Teil der Regel ersetzt. Alle Tokens im rechtsseitigen Teil werden buchstabengetreu kopiert, solange sie nicht mit einem Dollarzeichen beginnen. Wie im linksseitigen Teil kann auch im rechtsseitigen Teil eine Reihe von Metasymbolen benutzt werden. Sie werden in der folgenden Liste beschrieben. Die Rewrite-Regeln für den rechtsseitigen Teil sind: $n Dieses Metasymbol wird durch den n-ten Ausdruck des linksseitigen Teils ersetzt. $[name$] Dieses Metasymbol bildet Hostnamen in kanonische Namen ab. Es wird durch die kanonische Form des angegebenen Hostnamens ersetzt. $(map key $@arguments $:default $) Dies ist die allgemeinere Form der Mustersuche. Ausgegeben wird das Resultat der Suche von key in der Map namens map, wobei die arguments als Argumente übergeben werden. map bezeichnet eine der von sendmail unterstützten Maps, beispielsweise virtusertable, die wir in Kürze beschreiben werden. Schlägt die Suche fehl, wird default ausgegeben. Ist keine Vorgabe angegeben und die Suche schlägt fehl, bleibt die Eingabe unverändert, und key wird ausgegeben. $>n Bewirkt, daß der Rest dieser Zeile analysiert und dann zur Auswertung an Regelsatz n übergeben wird. Die Ausgabe des aufgerufenen Regelsatzes wird an diese Regel weitergegeben. Mit diesem Verfahren können Regeln andere Regelsätze aufrufen. $#mailer Dieses Metasymbol beendet die Auswertung der Regelsätze und gibt den Mailer an, der diese Nachricht im nächsten Schritt seiner Zustellung transportieren soll. Es sollte nur von Regelsatz 0 oder von einer ihrer Subroutinen aufgerufen werden. Das ist die letzte Stufe der Adressenanalyse, die von den nächsten beiden Metasymbolen begleitet werden sollte. $@host Dieses Metasymbol gibt den Host an, an den diese Nachricht weitergeleitet werden soll, und kann entfallen, wenn es sich dabei um den lokalen Host handelt. host kann auch eine mit Doppelpunkten getrennte Liste von Zielhosts sein, die für die Nachrichtenzustellung der Reihe nach durchprobiert werden sollen. $:user Dieses Metasymbol gibt den Empfänger der Mail an. Eine passende Rewrite-Regel wird normalerweise immer wieder durchprobiert, bis sie schließlich fehlschlägt. Danach wird die Analyse mit der nächsten Regel fortgesetzt. Dieses Verhalten kann geändert werden, indem dem rechtsseitigen Teil eines von zwei speziellen Metasymbolen vorangestellt wird, die in der folgenden Liste beschrieben werden. Die Metasymbole für Rewrite-Regeln für eine rechtsseitige Schleifenstruktur sind: $@ Dieses Metasymbol führt dazu, daß der Regelsatz den Rest des rechtsseitigen Teils als Resultat zurückliefert. Es werden keine weiteren Regeln des Regelsatzes ausgewertet. $:

Dieses Metasymbol führt zur sofortigen Beendigung dieser Regel. Der Rest des aktuellen Regelsatzes wird aber noch ausgewertet.

Ein einfaches Regelmuster-Beispiel Um besser zu verstehen, wie die Suchmuster für Makroersetzungen funktionieren, betrachten wir den folgenden linksseitigen Teil: $* < $+ >

Diese Regel prüft auf “null oder mehr Tokens, gefolgt vom Zeichen <, gefolgt von einem oder mehreren Tokens, gefolgt vom Zeichen >”. Würde diese Regel auf [email protected] oder Head Brewer < > angewendet, würde sie nicht passen. Der erste String paßt nicht, da er kein <-Zeichen enthält, der zweite ebenfalls nicht, da $+ auf ein oder mehrere Tokens prüft und keine Tokens zwischen den <>-Zeichen zu finden sind. In allen Fällen, in denen eine Regel nicht paßt, wird der rechtsseitige Teil der Regel nicht verwendet. Würde man die Regel hingegen auf Head Brewer < [email protected] > anwenden, würde sie passen. Im rechtsseitigen Teil würde dann $1 durch Head Brewer und $2 durch [email protected] ersetzt werden. Für < [email protected] > würde die Regel auch passen, da $* auf null oder mehrere Tokens prüft. Im rechtsseitigen Teil der Regel würde $1 durch einen leeren String ersetzt werden.

Semantik der Regelsätze Jede der sendmail-Regelsätze wird aufgerufen, um eine bestimmte Aufgabe in der Mail-Verarbeitung zu erledigen. Wenn Sie selbst Regeln formulieren, ist es wichtig zu verstehen, was jeder Regelsatz eigentlich tut. Wir betrachten nun die Regelsätze, die wir gemäß den m4-Konfigurationsskripten modifizieren dürfen: LOCAL_RULE_3 Regelsatz 3 ist verantwortlich für die Konvertierung einer Adresse beliebigen Formats in ein allgemeines Format, das von sendmail weiterverarbeitet wird. Das erwartete Ausgabeformat ist das vertraute local-part@host-domainspec. Regelsatz 3 sollte den Hostnamen-Teil der konvertierten Adresse in < und > einklammern, um es den nachfolgenden Regelsätze leichter zu machen. Regelsatz 3 kommt bereits zum Zuge, bevor sendmail eine E-Mail-Adresse überhaupt bearbeitet. Wenn Sie also mit sendmail Mails von einem System übertragen wollen, das ein unübliches Adressenformat verwendet, sollten Sie eine Regel hinzufügen, die das LOCAL_RULE_3-Makro zur Konvertierung von Adressen in das allgemeine Format verwendet. LOCAL_RULE_0 und LOCAL_NET_CONFIG Nach dem Regelsatz 3 wendet sendmail Regelsatz 0 auf die Empfängeradressen an. Das Makro LOCAL_NET_CONFIG bewirkt, daß Regeln in die untere Hälfte des Regelsatzes 0 eingefügt werden. Von Regelsatz 0 wird erwartet, daß er die Zustellung der Nachricht an den Empfänger vornimmt. Die Nachricht muß daher in ein Tripel aufgelöst werden, bestehend aus Mailer, Host und Benutzer. Die Regeln werden vor etwaigen SmartHost-Definitionen plaziert. Wenn Sie also Regeln hinzufügen, die Adressen angemessen auflösen, werden alle Adressen, die zu einer dieser Regeln passen, vom Smart Host nicht weiter behandelt. Das ist genau die Art und Weise, wie wir das direkte smtp für die Benutzer unseres lokalen LANs in unserem Beispiel handhaben. LOCAL_RULE_1 und LOCAL_RULE_2

Regelsatz 1 wird auf alle Senderadressen angewendet, Regelsatz 2 dagegen auf alle Empfängeradressen. Beide sind für gewöhnlich leer. Interpretation der Regel in unserem Beispiel Unser Beispiel in Tabelle 18.3 benutzt das Makro LOCAL_NET_CONFIG. Es deklariert eine lokale Regel, die sicherstellt, daß jede Mail in unserer Domain direkt durch den smtp-Mailer ausgeliefert wird.Nachdem wir nun wissen, wie Rewrite-Regeln konstruiert werden, können wir verstehen, wie diese Regel funktioniert. Werfen wir noch einen Blick darauf. Beispiel 18.3: Rewrite-Regeln von vstout.uucpsmtp.m4 LOCAL_NET_CONFIG # Diese Regel stellt sicher, daß alle lokalen Mails über den smtp-Transport # ausgeliefert werden. Alles andere läuft über den Smart Host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

Wir wissen, daß das LOCAL_NET_CONFIG-Makro bewirkt, daß die Regel irgendwo ans Ende von Regelsatz 0 gesetzt wird, aber immer vor die erste Smart-Host-Definition. Außerdem wissen wir, daß der Regelsatz 0 der zuletzt auszuführende Regelsatz ist und ein Tripel aus Mailer, Host und Benutzer zurückliefern sollte. Die drei Kommentarzeilen können wir getrost ignorieren; sie tun nichts wirklich Nützliches. Die Regel selbst ist die Zeile mit dem R am Anfang. Wir wissen, daß R ein sendmail-Befehl ist und daß er diese Regel zum aktuellen Regelsatz hinzufügt, in diesem Fall zum Regelsatz 0. Sehen wir uns nun abwechselnd die links- und rechtsseitigen Teile an. Der linksseitige Teil sieht so aus: $* < @ $* .$m. > $*. Regelsatz 0 erwartet die Zeichen < und >, da sie Eingaben von Regelsatz 3 erhält. Regelsatz 3 konvertiert Adressen in ein allgemeines Format, um das Parsing einfacher zu machen. Außerdem setzt sie den Hostteil der Mail-Adresse in <>. Diese Regel verarbeitet alle Mail-Adressen der Form 'Benutzer < @ IrgendeinHost.UnsereDomain. > Irgendein Text'. Das heißt, sie prüft Mails für beliebige Benutzer auf beliebigen Hosts unserer Domain. Sie erinnern sich, daß Text, der zu Metasymbolen im linksseitigen Teil einer Rewrite-Regel paßt, Makrodefinitionen zugewiesen wird, die im rechtsseitigen Teil verwendet werden. In unserem Beispiel paßt das erste $* zum Textabschnitt vom Anfang der Adresse bis zum <-Zeichen. Dieser Bereich wird $1 zugewiesen und kann dann im rechtsseitigen Teil benutzt werden. Dementsprechend wird das zweite $* in unserer Rewrite-Regel an $2 zugewiesen und das letzte an $3. Nun haben wir genug gesehen, um den linksseitigen Teil zu verstehen. Diese Regel prüft auf Mails für beliebige Benutzer auf beliebigen Hosts innerhalb unserer Domain. Den Benutzernamen weist sie an $1 zu, den Hostnamen an $2 und den Rest an $3. Danach wird der rechtsseitige Teil der Regel aufgerufen, um diese Makros zu verarbeiten. Sehen wir uns nun an, was als Ausgabe erscheinen sollte. Der rechtsseitige Teil unserer Rewrite-Regel sieht folgendermaßen aus: $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3. Wird der rechtsseitige Teil unserer Regel verarbeitet, werden alle Metasymbole interpretiert und die relevanten Substitutionen vorgenommen. Das Metasymbol $# bewirkt, daß diese Regel zu einem spezifischen Mailer resolviert, in unserem Fall smtp. Das Symbol $@ resolviert den Zielhost. In unserem Beispiel ist $2.$m. als Zielhost angegeben, was dem voll qualifizierten Namen (FQDN) des Hostrechners in unserer Domain entspricht. Konstruiert wird dieser Name aus der HostnamenKomponente, die an $2 vom linksseitigen Teil zugewiesen wird, ergänzt um unseren Domainnamen (.$m.). Das Metasymbol $: spezifiziert den Zielbenutzer, den wir wiederum im linksseitigen Teil erfaßt und in $1 abgespeichert hatten.

Den Inhalt des <>-Abschnitts sowie den Rest übernehmen wir unverändert. Dazu greifen wir auf die im linksseitigen Teil gesammelten Daten zurück. Da diese Regel zu einem Mailer resolviert, wird die Nachricht zu dem Mailer weitergeleitet, der die Zustellung übernimmt. In unserem Beispiel würde die Nachricht mittels SMTP an den Zielhost weitergeleitet.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

sendmail-Optionen konfigurieren sendmail kennt mehrere Optionen, mit denen Sie festlegen können, wie manche Aufgaben zu erledigen sind. Von diesen Optionen gibt es sehr viele; in der folgenden Liste stellen wir daher nur einige der geläufigeren Optionen vor: Um irgendwelche Optionen zu konfigurieren, definieren Sie sie in der m4-Konfigurationsdatei (was die empfehlenswerte Methode ist), oder Sie fügen sie direkt in die sendmail.cf-Datei ein. Wenn wir zum Beispiel sendmail veranlassen wollen, für jede auszuliefernde Mail einen neuen Job zu starten, können wir dazu die folgende Zeile in unsere m4-Konfigurationsdatei eintragen: define(‘confSEPARATE_PROC’,‘true’)

Der zugehörige erzeugte sendmail.cf-Eintrag ist: O ForkEachJob=true

Die folgende Liste beschreibt gängige m4-Optionen (und die zugehörigen sendmail.cf-Äquivalente): confMIN_FREE_BLOCKS (MinFreeBlocks)

Es gibt Situationen, in denen irgendein vertracktes Problem die direkte Zustellung von Mails verhindert und sich die eingehenden Mails in der Warteschlange stauen. Wenn Ihr Mail-Host große Mengen von Mails verarbeitet, kann das Mail-Spool-Verzeichnis dermaßen stark anwachsen, daß das ganze zugehörige Dateisystem überläuft. Um so etwas zu verhindern, können Sie sendmail über diese Option mitteilen, wie viele Blöcke im Dateisystem mindestens frei sein müssen, bevor eine Mail-Nachricht akzeptiert wird. Damit stellen Sie sicher, daß sendmail Ihr Dateisystem niemals zum Überlaufen bringt. Die Standardvorgabe ist 100. confME_TOO (MeToo) Wenn eine Mail-Zieladresse, z.B. ein E-Mail-Alias, expandiert wird, kommt es manchmal vor, daß der Absender in der Empfängerliste erscheint. Diese Option legt fest, ob der Verfasser einer E-Mail eine Kopie erhält, falls er in der expandierten Empfängerliste vorkommt. Zulässige Werte sind true und false. Standardvorgabe ist false. confMAX_DAEMON_CHILDREN (MaxDaemonChildren) Immer wenn sendmail eine SMTP-Verbindung von einem Remote-Host erhält, erzeugt es eine neue Instanz von sich selbst, die sich um die Verarbeitung der eingehenden Mails kümmert. Auf diese Weise kann sendmail mehrere eingehende Mails gleichzeitig verarbeiten. Das ist zwar eine nützliche Sache, jedoch nimmt jede neue Instanz von sendmail Speicherplatz im Hostrechner in Anspruch. Wenn nun zufällig mal eine ungewöhnlich große Anzahl von Mails ankommt, verursacht durch irgendein technisches Problem oder vielleicht sogar durch eine böswillige Attacke, kann durch die vielen neuen sendmail-Instanzen der Systemspeicher überlaufen und das System zum Stillstand bringen. Diese Option bietet Ihnen einen Weg, die maximale Anzahl der sendmail-Instanzen festzulegen. Sobald diese Anzahl erreicht ist, werden neue Verbindungen abgewiesen, bis eine der vorhandenen Instanzen ihre Arbeit beendet hat. Standardvorgabe ist undefined. confSEPARATE_PROC (ForkEachJob) Bei der Verarbeitung der Mail-Warteschlange und beim Senden von Mails nimmt sich sendmail immer nur eine Mail zur Zeit vor. Ist diese Option aktiviert, erzeugt sendmail für jede auszuliefernde Nachricht eine neue Instanz von sich selbst. Sie ist besonders dann sinnvoll, wenn Mails vorliegen, die in der Warteschlange steckenbleiben, weil es irgendein Problem mit dem Zielhost gibt. Standardvorgabe ist false. confSMTP_LOGIN_MSG (SmtpGreetingMessage) Zu Beginn jeder Verbindung verschickt sendmail eine Grußbotschaft. Standardmäßig enthält sie den Hostnamen, den Namen des Mail-Verteilers, die sendmail-Versionsnummer, die lokale Versionsnummer und das aktuelle Datum. Nach RFC-821 sollte das erste Wort der Grußbotschaft den voll qualifizierten Domainnamen (FQDN) des Host enthalten, der Rest der Grußbotschaft kann dagegen beliebig gestaltet sein. Sie können hier auch sendmail-Makros angeben; sie werden bei ihrer Anwendung expandiert. Die einzigen, die diese Nachricht zu

Gesicht bekommen, sind die bemitleidenswerten Systemadministratoren, die sich mit den MailZustellungsproblemen herumschlagen müssen oder mit allzu neugierigen Zeitgenossen, die unbedingt herausfinden wollen, wie Ihre Maschine konfiguriert ist. Wenn Sie die Administratoren etwas aufmuntern wollen, können Sie Ihre Begrüßung vielleicht mit einem guten Witz garnieren. sendmail fügt das Wort “ESMTP” zwischen die ersten beiden Wörter ein, um den Remote-Hosts zu signalisieren, daß ESMTP unterstützt wird. Standardvorgabe: $j Sendmail $v/$Z; $b.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Nützliche sendmail-Konfigurationen sendmail-Konfigurationen gibt es wie Sand am Meer. In diesem Teil zeigen wir nur ein paar wichtige Konfigurationsarten, die in vielen sendmail-Installationen nützlich sind.

Benutzer, die das From:-Feld setzen dürfen Manchmal ist es nützlich, das From:-Feld einer ausgehenden Mail-Nachricht überschreiben zu können. Nehmen wir zum Beispiel an, Sie hätten ein webbasiertes Programm, das E-Mails erzeugt. Normalerweise enthalten Mail-Nachrichten immer den Namen des Absenders, der den Webserver-Prozeß ausführt. Nun möchten wir aber eine andere Quelladresse angeben, so daß die Mail den Eindruck erweckt, als käme sie von einem anderen Benutzer oder einer anderen Adresse auf dieser Maschine. sendmail stellt nun ein Mittel zur Verfügung, mit dem festgelegt werden kann, welche Systemanwender für vertrauenswürdig erachtet werden, Mail-Nachrichten in der geschilderten Weise modifizieren zu dürfen. Das Feature use_ct_file aktiviert die Spezifikation und Anwendung einer Datei, die eine Namensliste der vertrauenswürdigen Benutzer enthält. Standardmäßig wird nur eine kleine Anzahl von Systemanwendern von sendmail für vertrauenswürdig gehalten (z.B. root). Der übliche Dateiname dieses Features ist /etc/mail/trusted-users auf Systemen, die /etc/mail/ als Konfigurationsverzeichnis benutzen, bzw. /etc/sendmail.ct, wo das nicht der Fall ist. Sie können Name und Ort der Datei allerdings selbst angeben, indem Sie die Definition von confCT_FILE überschreiben. Tragen Sie FEATURE(use_ct_file) in Ihre sendmail.mc-Datei ein, um dieses Feature zu aktivieren.

Mail-Aliasnamen Mail-Aliase sind ein mächtiges Feature, mit dem Mails an Mailboxen geleitet werden können, bei denen es sich um alternative Namen für Benutzer oder Prozesse auf einem Zielhost handelt. Es ist zum Beispiel gängige Praxis, auf einem WWW-Server eingegebene Feedback-Daten oder Kommentare an den “Webmaster” zu leiten. Häufig gibt es aber gar keine Benutzer mit diesem Namen auf dem Zielrechner, sondern es handelt sich nur um einen Alias für einen anderen Anwender. Mail-Aliase werden häufig auch von Mailing-Listen-Serverprogrammen genutzt; sie leiten eingehende Nachrichten zur Verarbeitung an das Serverprogramm weiter. Aliasnamen werden in der Datei /etc/aliases aufbewahrt. Diese Datei wird von sendmail konsultiert, wenn zu entscheiden ist, wie eine eingehende Mail behandelt werden soll. Falls sendmail in der Datei einen zum Empfänger der Mail passenden Eintrag

findet, leitet es die Mail an die Adresse um, die im Eintrag beschrieben ist. Es gibt im besonderen drei Dinge, die durch Aliase möglich gemacht werden: ●

Sie gestatten es, für die Empfänger von Mails eine Kurzform oder einen gängigen Namen zu benutzen, mit dem eine bestimmte Person oder Personengruppe erreicht wird.

●

Sie können ein Programm aufrufen, dem die Mail-Nachricht als Eingabe übergeben wird.

●

Sie können Mail an eine Datei senden.

Jedes System, das der RFC-Norm entsprechen will, benötigt Aliasnamen für Postmaster und MAILER-DAEMON. Achten Sie bei der Definition von Aliasen, die Programme aufrufen oder Programmeingaben erzeugen, peinlich genau auf die Systemsicherheit, da sendmail immer mit root-Rechten läuft. Details zu Mail-Aliasen finden Sie in der Manpage aliases(5). Ein Beispiel für eine aliases-Datei zeigt Tabelle 18.4. Beispiel 18.4: Beispiel für eine aliases-Datei # # Die folgenden beiden Aliase müssen angegeben werden, # um RFC-konform zu sein. Wichtig ist, daß sie zu einer 'Person' # resolvieren, die die Mails routinemäßig liest. # postmaster: root # notwendiger Eintrag MAILER-DAEMON: postmaster # notwendiger Eintrag # # # Demonstration der allgemeinen Alias-Typen # usenet: janet # Alias für eine Person admin: joe,janet # Alias für mehrere Personen remoteuser: [email protected] # Alias für einen nicht-lokalen Benutzer newspak-users: :include:/usr/lib/lists/newspak # Empfänger aus Datei lesen changefeed: |/usr/local/lib/gup # Alias, der ein Programm aufruft complaints: /var/log/complaints # Alias, der Mail an eine Datei weitergibt #

Immer wenn Sie die Datei /etc/aliases geändert haben, müssen Sie unbedingt folgenden Befehl ausführen: # /usr/bin/newaliases

Damit wird die Datei neu gebildet, die sendmail intern benutzt. Der Befehl /usr/bin/newaliases ist ein symbolischer Link zum ausführbaren sendmail-Programm. Beim Aufruf dieses Links verhält sich sendmail so, als ob es wie folgt aufgerufen würde: # /usr/lib/sendmail -bi

Die Verwendung des Befehls newaliases ist demgegenüber jedoch etwas bequemer.

Anwendung eines Smart Host Manchmal stößt ein Host auf eine Mail, die er nicht direkt an den entsprechenden Remote-Host zustellen kann. Oft ist es zweckdienlich, wenn man in einem Netzwerk einen einzelnen Host dafür abstellt, solche schwer zustellbaren Mails zu verwalten, anstatt dieses den einzelnen Hosts zu überlassen. Überhaupt gibt es einige gute Gründe, einen einzelnen Host für die Mail-Verwaltung einzusetzen. Sie können die Systemverwaltung vereinfachen, da Sie nur noch einen Host mit einer umfangreichen Mail-Konfiguration ausstatten müssen, der all die verschiedenen Mail-Transportarten wie UUCP, Usenet usw. zu verarbeiten weiß. Alle anderen Hosts brauchen dann nur noch ein einzelnes Transportprotokoll, um ihre Mails an diesen zentralen Host zu senden. Man bezeichnet solche Hosts, die das zentrale Mail-Routing und -Forwarding übernehmen, als Smart Hosts. Wenn Sie einen Smart Host haben, der Mails von Ihnen annimmt, können Sie ihm Mails beliebiger Art zukommen lassen; er wird Ihnen das Routing und die Übertragung dieser Mails abnehmen und sie an die gewünschten Zieladressen weiterleiten. Eine weitere sinnvolle Anwendung für Smart-Host-Konfigurationen ist die Transportverwaltung von Mail über private

Firewalls. Eine Firma könnte sich zum Beispiel dazu entschließen, ein privates IP-Netzwerk zu installieren und darin ihre eigenen unregistrierten IP-Adressen zu benutzen. Dieses private Netzwerk könnte über einen Firewall mit dem Internet verbunden sein. Wollte man nun Mails von den Hosts dieses privaten Netzwerks mittels SMTP an die Außenwelt senden (bzw. umgekehrt), wäre das mit einer konventionellen Konfiguration nicht zu machen, da die Hosts nicht in der Lage wären, direkte Netzwerkverbindungen zu Hosts im Internet herzustellen. Statt dessen könnte sich die Firma dafür entscheiden, ihren FirewallRechner auch als Smart Host für die Mail-Verwaltung agieren zu lassen. Der auf dem Firewall laufende Smart Host wäre durchaus in der Lage, direkte Verbindungen mit Hosts sowohl im privaten Netzwerk als auch im Internet herzustellen. Er würde Mails von beiden Seiten annehmen, im lokalen Speicher ablegen und dann für die erneute Übertragung der Mails an die gewünschten Hosts sorgen. Üblicherweise werden Smart Hosts immer dann eingesetzt, wenn alle anderen Methoden der Mail-Zustellung fehlgeschlagen sind. Im Fall der Firma mit dem privaten Netzwerk wäre es absolut angemessen, die Hosts so einzurichten, daß sie versuchen, ihre Mails zunächst selbst zuzustellen, und im Falle eines Fehlschlags die betroffenen Mails an den Smart Host senden. Das würde den Smart Host von einer Menge Datenverkehr entlasten, denn schließlich könnten die Hosts im privaten Netzwerk sich ihre Mails ja gegenseitig direkt zusenden. sendmail bietet eine einfache Methode, einen Smart Host zu konfigurieren, nämlich das Feature SMART_HOST. Genau diese Methode benutzen wir bei der Implementierung in unserer virtuellen Brauerei. Die für die Definition des Smart Host relevanten Abschnitte in unserer Konfiguration sind: define(`SMART_HOST’, `uucp-new:moria’) LOCAL_NET_CONFIG # Diese Regel stellt sicher, daß die lokalen Mails mit Hilfe des smtp-Transports # zugestellt werden. Alles andere läuft über den Smart Host. R$* < @ $* .$m. > $* $#smtp $@ $2.$m. $: $1 < @ $2.$m. > $3

Mit dem SMART_HOST-Makro können Sie den Host spezifizieren, der alle ausgehenden Mails verteilt, die Sie nicht direkt zustellen können, sowie das dafür zu verwendende Mail-Transportprotokoll. In unserer Konfiguration benutzen wir den uucp-new-Transport zum UUCP-Host moria. Wollten wir sendmail so konfigurieren, daß es einen SMTP-basierten Smart Host verwendet, würden wir statt dessen etwa folgendes verwenden: define(`SMART_HOST’, `mail.isp.net’)

Wir brauchen SMTP nicht als Transportprotokoll anzugeben, da es ohnehin Standard ist. Erinnern Sie sich noch, was es mit dem LOCAL_NET_CONFIG-Makro auf sich hatte und was die Rewrite-Regel damit anstellten? Nun, mit dem LOCAL_NET_CONFIG-Makro können Sie “rohe” sendmail-Rewrite-Regeln in Ihre Konfiguration einfügen, die definieren, welche Mails nur im lokalen Mail-System umlaufen dürfen. In unserem Beispiel benutzen wir eine Regel, die zu allen E-Mail-Adressen paßt, deren Hosts zu unserer Domain (.$m.) gehören, und sie so übersetzt, daß sie direkt zum SMTPMailer gesendet werden. Damit wird sichergestellt, daß jede Mail an einen Host in unserer lokalen Domain direkt an den SMTPMailer gerichtet und von dort zu diesem Host geleitet wird, anstatt den Umweg über den Smart Host zu machen, wie es standardmäßig geschehen würde.

Verwaltung unerwünschter Mail (Spam) Wenn Sie sich in eine Mailing-Liste eingetragen, Ihre E-Mail-Adresse auf einer Website veröffentlicht oder einen Artikel ins UseNet gepostet haben, werden Sie höchstwahrscheinlich unerwünschte Werbe-Mails bekommen. Leider hat sich mittlerweile die Unart verbreitet, das Netz nach E-Mail-Adressen zu durchforsten, mit der Absicht, sie in Verteiler-Listen aufzunehmen und diese an Firmen zu verkaufen, die damit für ihre Produkte werben können. Diese Art von E-Mail-Massensendungen bezeichnet man als Spamming. Das Free On-line Dictionary of Computing bietet eine mailspezifische Definition von Spam an, die wie folgt lautet:1 2. (Eine Einschränkung von Bedeutung 1, siehe oben.) Das wahllose Versenden nicht angeforderter E-Mails zum Bewerben von Produkten oder Diensten. Spam in diesem Sinne entspricht dem elektronischen Äquivalent von Junk-Mails, die an “Bewohner” gesendet werden.

In den 90er Jahren, als die kommerzielle Bedeutung des Netzes immer größer wurde, gab es wirklich rücksichtslose Individuen, die Firmen, die im Internet werben wollten, Spamming als “Dienst” anboten. Dabei wurden Werbe-Mails an bestimmte Mail-Adressen-Gruppen, Usenet-News oder Mailing-Listen gesendet. Das führte bei vielen Internet-anwendern zu heftigen Gegenreaktionen und aggressiven Wutausbrüchen gegen die Verursacher. Zum Glück unterstützt sendmail Mechanismen, mit denen Sie unerwünschte Mails gesondert behandeln können. Real-time Blackhole List Die Real-time Blackhole List ist eine öffentliche Einrichtung, die Ihnen hilft, den Umfang unerwünschter Werbung, mit der Sie sich herumschlagen müssen, zu reduzieren. Die bekannten “schwarzen Schafe” unter den E-Mail-Adressen und Hosts sind in einer Datenbank im Internet gespeichert, die abgefragt werden kann. Sie werden von Leuten eingegeben, die unerwünschte Werbung von bestimmten E-Mail-Adressen erhalten haben. Größere Domains finden sich manchmal in dieser Liste wieder, wenn beim Einstellen des Spammings eine kleine Panne passiert ist. Obwohl sich manche Leute über einzelne Entscheidungen der RBL-Verwalter beschweren, ist diese Liste dennoch sehr populär, und Unstimmigkeiten werden für gewöhnlich schnell beiseite geräumt. Umfangreiche Informationen darüber, wie dieser Dienst funktioniert, findet man auf der Homepage des Mail Abuse Protection System unter http://maps.vix.com/rbl/. Wenn Sie dieses sendmail-Feature aktivieren, testet es die Quelladresse jeder ankommenden Mail-Nachricht gegen die Realtime Blackhole List, um festzustellen, ob die Mail akzeptiert werden kann. Wenn Sie eine große Website mit vielen Benutzern betreiben, kann Ihnen dieses Feature beachtlich viel Plattenspeicher einsparen. Dieses Feature akzeptiert einen Parameter, der den Namen des zu benutzenden Servers angibt. Standardvorgabe ist der Hauptserver von rbl.maps.vix.com. Um das Feature für die Real-time Blackhole List zu konfigurieren, fügen Sie folgende Makrodeklaration in Ihre sendmail.mcDatei ein: FEATURE(rbl)

Sollten Sie einen anderen RBL-Server angeben wollen, würden Sie etwa folgende Deklaration benutzen: FEATURE(rbl,`rbl.host.net’)

Die Zugriffsdatei Ein alternatives System, das mehr Flexibilität und Kontrolle auf Kosten manueller Konfiguration bietet, ist das sendmailFeature access_db. In der Zugriffsdatenbank legen Sie fest, von welchen Hosts oder Benutzern Sie Mails akzeptieren und an welche Sie Mails zustellen wollen. Es ist wichtig für Sie festzulegen, für wen Sie überhaupt Mails vermitteln, denn es gibt eine andere Technik, die häufig von Spamming-Hosts eingesetzt wird, um Systeme wie die gerade beschriebene Real-time Blackhole List zu umgehen. Anstatt Ihnen die Werbe-Mails direkt zuzusenden, leiten die Spammer die Mails über unverdächtige Hosts, die das dürfen. Die ankommende SMTP-Verbindung kommt dann nicht vom Spamming-Host, sondern vom sogenannten Relay-Host. Um sicherzustellen, daß Ihre Mail-Hosts nicht auf diese Weise mißbraucht werden, sollten Sie Mails nur für bekannte Hosts vermitteln. Seit sendmail, Version 8.9.0, ist diese Vermittlung standardmäßig abgeschaltet. Sie müssen daher die Zugriffsdatei heranziehen, um die Vermittlung für individuelle Hosts zu aktivieren. Das Grundprinzip ist einfach. Wenn eine ankommende SMTP-Verbindung empfangen wird, liest sendmail die Information im Mail-Header, konsultiert dann die Zugriffsdatei und entscheidet, ob es auch den Rumpf der Nachricht akzeptieren soll. Die Zugriffsdatei ist eine Ansammlung von Regeln, die beschreiben, welche Aktion für Nachrichten durchgeführt werden soll, die von benannten Hosts empfangen werden. Die Standard-Zugriffskontrolldatei ist /etc/mail/access. Die Tabelle hat ein einfaches Format. Jede Tabellenzeile enthält eine Zugriffsregel. Der linksseitige Teil jeder Regel ist ein Muster, mit dem der Absender einer eingehenden Mail-Nachricht überprüft wird. Dabei kann es sich um eine vollständige E-Mail-Adresse, um einen Hostnamen oder eine IP-Adresse handeln. Der rechtsseitige Teil beschreibt die durchzuführende Aktion. Sie können insgesamt fünf Arten von Aktionen konfigurieren:

OK Mail-Nachricht akzeptieren. RELAY Nachrichten von diesem Host oder Benutzer akzeptieren, auch wenn sie nicht für unseren Host bestimmt sind, d.h., diese Aktion akzeptiert Nachrichten zur Vermittlung von diesem Host an andere Hosts. REJECT Mail mit einer allgemeinen Nachricht ablehnen. DISCARD Nachricht unter Verwendung des Mailers $#discard aussondern. ### any text Eine Fehlermeldung zurückliefern und ### als Fehlercode (der RFC-821-konform sein sollte) und “any text” als Nachricht verwenden. Eine Beispieldatei /etc/mail/access könnte so aussehen: [email protected] [email protected]

REJECT aol.com OK linux.org.au

REJECT 207.46.131.30 RELAY

REJECT

Dieses Beispiel würde jede von [email protected] empfangene E-Mail ablehnen, ebenso jeden Host aus der Domain aol.com sowie den Host 207.46.131.30. Die nächste Regel würde E-Mails von [email protected] akzeptieren, obwohl die Domain selbst eine Reject-Regel hat. Die letzte Regel gestattet die Vermittlung von Mails von jedem Host in der linux.org.auDomain. Um das Zugriffsdatei-Feature zu aktivieren, benutzen Sie folgende Deklaration in Ihrer sendmail.mc-Datei: FEATURE(access_db)

Die Standarddefinition bildet die Zugriffsdatei mittels hash -o /etc/mail/access, was aus der Textdatei eine simple Hashdatei erzeugt. Für die meisten Installationen reicht das völlig aus. Es gibt noch andere Optionen, die Sie in Betracht ziehen sollten, wenn Sie eine große Zugriffsdatei haben wollen. Weiterführende Informationen erhalten Sie im sendmail-Buch oder in anderen sendmail-Dokumentationen. Benutzer vom Mail-Empfang ausschließen Wenn Sie Benutzer oder automatisierte Prozesse haben, die nur Mails senden, aber nie empfangen, ist es manchmal sinnvoll, an sie gerichtete Mails grundsätzlich abzublocken. Das erspart das Abspeichern unnötiger E-Mails, die sowieso nie gelesen werden. Mit dem blacklist_recipients-Feature, kombiniert mit dem access_db-Feature, können Sie den Mail-Empfang für lokale Benutzer abstellen. Um dieses Feature zu aktivieren, fügen Sie die folgenden Zeilen in Ihre sendmail.mc ein (wenn sie nicht bereits eingetragen sind): FEATURE(access_db) FEATURE(blacklist_recipients)

Um den Mail-Empfang für einen lokalen Benutzer abzustellen, tragen Sie einfach nur die Details über ihn in die Zugriffsdatei ein. Für gewöhnlich benutzen Sie dafür den ###-Eintrags-Stil, der eine informative Fehlermeldung an den Absender

zurückliefert, damit dieser erfährt, warum die Zustellung nicht geklappt hat. Dieses Feature eignet sich genausogut für Benutzer in virtuellen Mail-Domains; dann müssen Sie diese Domains in die Spezifikation der Zugriffsdatei eintragen. Beispieleinträge für /etc/mail/access könnten so aussehen: daemon 550 Dämon akzeptiert oder liest keine Mail. flacco 550 Mail für diesen User wurde administrativ abgeschaltet. [email protected] 550 Mail für diesen Empfänger abgeschaltet.

Virtuelles Mail-Hosting konfigurieren Virtuelles Mail-Hosting versetzt einen Host in die Lage, Mails im Namen verschiedener Domains zu empfangen und zu senden, als ob er selbst eine Gruppe separater Mail-Hosts wäre. Zwar wird es in den meisten Fällen von Internet Application Providern in Kombination mit virtuellem Web-Hosting genutzt, es ist aber leicht zu konfigurieren, und Sie wissen nie, ob Sie sich nicht eines Tages in einer Situation befinden werden, in der Sie eine Mailing-Liste für Ihr eigenes Linux-Projekt virtuell hosten. Daher gehen wir hier näher darauf ein. Mails für andere Domains akzeptieren Wenn sendmail eine E-Mail empfängt, vergleicht es den Zielhost in den Mail-Headern mit dem lokalen Hostnamen. Stimmen sie überein, akzeptiert sendmail die Nachricht für lokale Zustellung. Falls nicht, kann sendmail sich dafür entscheiden, die Nachricht zu akzeptieren und zu versuchen, sie an die Zieladresse weiterzuleiten. Details, wie man sendmail konfiguriert, daß es Mails zur Weiterleitung akzeptiert, finden Sie in “Die Zugriffsdatei” in diesem Kapitel. Wenn wir virtuelles Mail-Hosting konfigurieren wollen, müssen wir zuerst sendmail davon überzeugen, daß es auch Mails für die von uns gehosteten Domains akzeptiert. Zum Glück läßt sich das sehr leicht bewerkstelligen. Das sendmail-Feature use_cw_file gestattet uns, den Namen einer Datei anzugeben, in der wir die Domainnamen eintragen, für die sendmail Mails akzeptiert. Zur Konfiguration dieses Features fügen Sie die folgende Deklaration in Ihre sendmail.mc-Datei ein: FEATURE(use_cw_file)

Der Standardname dieser Datei lautet /etc/mail/local-host-names für Distributionen, die das Konfigurationsverzeichnis /etc/mail benutzen, ansonsten /etc/sendmail.cw. Alter-nativ dazu können Sie Name und Ort der Datei festlegen, indem Sie das Makro -confCW_FILE überschreiben. Beispiel: define(`confCW_FILE’,`/etc/virtualnames’)

Wenn wir bei den Standardnamen bleiben und virtuelles Hosting für die Domains -bovine.net, dairy.org und artist.org anbieten wollten, würden wir eine Datei /etc/mail/local-host-names mit folgendem Inhalt erzeugen: bovine.net dairy.org artist.org

Sobald das erledigt ist und davon ausgegangen werden kann, daß geeignete DNS-Records existieren, die diese Domainnamen auf unseren Host verweisen, wird sendmail Mail-Nachrichten für diese Domains so akzeptieren, als ob sie für unsere echten Domainnamen bestimmt wären. Virtuell gehostete Mail an andere Zieladressen weiterleiten Das sendmail-Feature virtusertable konfiguriert die Unterstützung für die virtuelle Benutzertabelle, wo wir virtuelles MailHosting konfigurieren. Die virtuelle Benutzer-tabelle bildet ankommende Mails, die für einen user@host bestimmt sind, in einen -otheruser@otherhost ab. Sie können sich das wie ein erweitertes Mail-Alias-Feature vorstellen, das nicht nur den Zielbenutzer betrifft, sondern auch die Zieldomain. Um das virtusertable-Feature zu konfigurieren, fügen Sie es wie folgt in Ihre sendmail.mc-Konfiguration ein: FEATURE(virtusertable)

Standardmäßig ist /etc/mail/virtusertable die Datei, die die Regeln für die Durchführung der Übersetzungen enthält. Das können Sie überschreiben, indem Sie der Makrodefinition ein Argument übergeben. Welche Optionen es gibt, können Sie in einer detaillierten sendmail-Referenz nachlesen. Das Format der virtuellen Benutzertabelle ist sehr einfach gehalten. Der linksseitige Teil jeder Zeile enthält ein Muster, das die ursprüngliche Zieladresse der Mail enthält. Der rechtsseitige Teil enthält ein Muster, das die Mail-Adresse repräsentiert, auf die die virtuell gehostete Adresse abgebildet wird. Das folgende Beispiel zeigt drei mögliche Arten von Einträgen: [email protected] colin [email protected] [email protected] @dairy.org [email protected] @artist.org [email protected]

Darin hosten wir drei Domains virtuell: bovine.net, dairy.org sowie artist.org. Der erste Eintrag stellt Mails, die für einen Benutzer der virtuellen Domain bovine.net bestimmt sind, an einen lokalen Benutzer auf der Maschine zu. Der zweite Eintrag leitet Mails für einen Benutzer in derselben virtuellen Domain an einen Benutzer in einer anderen Domain um. Die dritte Zeile bewirkt, daß alle Mails, die an irgendwelche Benutzer in der virtuellen Domain dairy.org adressiert sind, an eine einzelne Remote-Mail-Adresse umgeleitet werden. Schließlich führt der letzte Eintrag dazu, daß die an die Benutzer der virtuellen Domain artist.org gerichteten Mails an die gleichnamigen Benutzer einer anderen Domain adressiert werden, zum Beispiel von [email protected] nach [email protected].

1.

Das Free On-Line Dictionary of Computing ist in vielen Linux-Distributionen enthalten. Die Online-Dokumentation kann auf der Homepage unter http://wombat.doc.ic.ac.uk/foldoc/ eingesehen werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Testen Ihrer Konfiguration Der Befehl m4 verarbeitet die Makrodefinitionsdateien nach seinen eigenen Syntaxregeln, ohne überhaupt etwas von korrekter sendmail-Syntax zu verstehen. Er gibt daher auch keine Fehlermeldungen aus, wenn Sie in Ihrer Makrodefinitionsdatei etwas falsch gemacht haben. Aus diesem Grund ist es sehr wichtig, daß Sie Ihre Konfiguration gründlich testen. Zum Glück macht es uns sendmail hier relativ leicht. sendmail unterstützt einen “Adressentest”-Modus, mit dem wir unsere Konfiguration testen und Fehler aufspüren können. In diesem Betriebsmodus rufen wir sendmail von der Befehlszeile auf. Es fragt uns dann nach einer Regelsatzspezifikation und einer Ziel-Mail-Adresse. sendmail verarbeitet dann diese Zieladresse mit den angegebenen Regeln und gibt dabei die Ergebnisse der abgearbeiteten Rewrite-Regeln aus. Um sendmail in diesen Modus zu versetzen, rufen wir es mit dem Argument –bt auf: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

>

Die verwendete Standard-Konfigurationsdatei ist /etc/mail/sendmail.cf. Sie können auch eine alternative Konfigurationsdatei angeben, indem Sie das Argument –C benutzen. Um unsere Konfiguration zu testen, müssen wir eine Anzahl von Adressen auswählen, die uns darüber Auskunft geben, ob alle unsere mailbezogenen Anforderungen eingehalten werden. Zur Veranschaulichung arbeiten wir uns durch einen Test unserer etwas komplizierteren UUCP-Konfiguration, die in Tabelle 18.2 dargestellt ist. Zuerst testen wir, ob sendmail in der Lage ist, Mails an die lokalen Benutzer des Systems zuzustellen. Bei diesen Tests erwarten wir, daß alle Adressen für den local-Mailer auf dieser Maschine umgeschrieben werden: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 isaac rewrite: ruleset 3 input: isaac rewrite: ruleset 96 input: isaac rewrite: ruleset 96 returns: isaac rewrite: ruleset 3 returns: isaac rewrite: ruleset 0 input: isaac rewrite: ruleset 199 input: isaac rewrite: ruleset 199 returns: isaac rewrite: ruleset 98 input: isaac rewrite: ruleset 98 returns: isaac rewrite: ruleset 198 input: isaac rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Die Ausgabe zeigt uns, wie sendmail auf diesem System an isaac adressierte Mail verarbeitet. Jede Zeile zeigt uns die Informationen, die einem Regelsatz übergeben wurden, oder die durch Abarbeitung einem Regelsatz erzeugte Ausgabe. Wir

haben sendmail angewiesen, die Regelsätze 3 und 0 zur Adressenverarbeitung einzusetzen. Regelmenge 0 wird normalerweise aufgerufen, Regelsatz 3 haben wir hier ausdrücklich angegeben, da er nicht standardmäßig getestet wird. Die letzte Zeile zeigt schließlich, daß das Ergebnis des Regelsatzes 0 tatsächlich Mail an isaac an den local-Mailer leitet. Als nächstes testen wir die an unsere SMTP-Adresse [email protected] adressierten Mails. Hier sollten wir dasselbe Endresultat wie in unserem letzten Beispiel erhalten: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 [email protected] rewrite: ruleset 3 input: isaac @ vstout . vbrew . com rewrite: ruleset 96 input: isaac < @ vstout . vbrew . com > rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Auch dieser Test war erfolgreich. Nun testen wir Mails an unsere UUCP-Adresse vstout!isaac. # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 vstout!isaac rewrite: ruleset 3 input: vstout ! isaac rewrite: ruleset 96 input: isaac < @ vstout . UUCP > rewrite: ruleset 96 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vstout . vbrew . com . > rewrite: ruleset 198 returns: $# local $: isaac rewrite: ruleset 0 returns: $# local $: isaac

Dieser Test hat auch geklappt. Diese Tests bestätigen, daß wir Mails für die lokalen Benutzer unserer Maschine korrekt zustellen können, egal wie die Adressen formatiert sind. Wenn Sie für Ihre Maschinen irgendwelche Aliase definiert haben, wie z.B. virtuelle Hosts, sollten Sie diese Tests für alle alternativen Namen wiederholen, unter denen der Host bekannt ist, um sicherzustellen, daß sie auch korrekt funktionieren. Im nächsten Test überprüfen wir, ob Mails, die an andere Hosts in der Domain vbrew.com adressiert sind, vom SMTP-Mailer direkt an diese Hosts zugestellt werden: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 [email protected] rewrite: ruleset 3 input: isaac @ vale . vbrew . com rewrite: ruleset 96 input: isaac < @ vale . vbrew . com > rewrite: ruleset 96 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 3 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 199 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 98 returns: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 input: isaac < @ vale . vbrew . com . > rewrite: ruleset 198 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . > rewrite: ruleset 0 returns: $# smtp $@ vale . vbrew . com . / $: isaac < @ vale . vbrew . com . >

Bei diesem Test sehen wir, daß die Nachricht an den SMTP-Mailer gerichtet wird, um sie direkt an den Host vale.vbrew.com weiterzuleiten und an den Benutzer isaac zuzustellen. Dieser Test bestätigt uns, daß unsere LOCAL_NET_CONFIG-Definition ordnungsgemäß funktioniert. Damit dieser Test überhaupt erfolgreich verläuft, muß der Name des Zielhosts korrekt aufgelöst werden können; es ist daher ein Eintrag entweder in unserer /etc/hosts-Datei oder in unserem lokalen DNS vonnöten. Was passiert, wenn der Hostname nicht aufgelöst werden kann, sehen wir, wenn wir absichtlich einen unbekannten Hostnamen angeben: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 [email protected] rewrite: ruleset 3 input: isaac @ vXXXX . vbrew . com rewrite: ruleset 96 input: isaac < @ vXXXX . vbrew . com > vXXXX.vbrew.com: Name server timeout rewrite: ruleset 96 returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 3 returns: isaac < @ vXXXX . vbrew . com > == Ruleset 3,0 (3) status 75 rewrite: ruleset 0 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 199 input: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 199

returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 98 input: isaac < @ vXXXX . com > rewrite: ruleset 98 returns: isaac < @ vXXXX . vbrew . com > rewrite: ruleset 198 isaac < @ vXXXX . vbrew . com > rewrite: ruleset 95 input: < uucp-new : moria > isaac vXXXX . vbrew . com > rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac
vbrew . input:

Dieses Ergebnis sieht nun ganz anders aus. Erstens liefert Regelsatz 3 eine Fehlermeldung, daß der Hostname nicht aufgelöst werden konnte. Zweitens greifen wir für solche Fälle auf eine andere wichtige Einrichtung unserer Konfiguration zurück, nämlich den Smart Host. Dieser kümmert sich um jede Mail, die auf andere Weise nicht zugestellt werden kann. Der Hostname, den wir in diesem Test spezifiziert haben, kann nicht aufgelöst werden, und die Regelsätze entscheiden sich daher, die unzustellbare Mail über den uucp-new-Mailer an unseren Smart Host moria in die Schuhe zu schieben. Unser Smart Host könnte ja bessere Verbindungen haben und weiß schon, was er mit der Adresse anfangen soll. Unser letzter Test stellt nun sicher, daß jede Mail, die an einen Host außerhalb unserer Domain adressiert ist, bei unserem Smart Host abgeliefert wird. Das Ergebnis sollte in etwa dem vorigen Beispiel entsprechen: # /usr/sbin/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter

> 3,0 [email protected] rewrite: ruleset 3 input: isaac @ linux . org . au rewrite: ruleset 96 input: isaac < @ linux . org . au > rewrite: ruleset 96 returns: isaac < @ linux . org . au . > rewrite: ruleset 3 returns: isaac < @ linux . org . au . > rewrite: ruleset 0 input: isaac < @ linux . org . au . > rewrite: ruleset 199 input: isaac < @ linux . org . au . > rewrite: ruleset 199 returns: isaac < @ linux . org . au . > rewrite: ruleset 98 input: isaac < @ linux . org . au . > rewrite: ruleset 98 returns: isaac < @ linux . org . au . > rewrite: ruleset 198 input: isaac < @ linux . org . au . > rewrite: ruleset 95 input: < uucp-new : moria > isaac rewrite: ruleset 95 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 198 returns: $# uucp-new $@ moria $: isaac rewrite: ruleset 0 returns: $# uucp-new $@ moria $: isaac

Das Ergebnis dieses Tests zeigt, daß der Hostname resolviert werden konnte und die Nachricht trotzdem noch über unseren Smart Host läuft. Das beweist, daß unsere LOCAL_NET_CONFIG-Definition richtig funktioniert und beide Fälle korrekt behandelt. Unser gesamter Test ist also ein Erfolg, und wir können voller Zuversicht davon ausgehen, daß unsere Konfiguration korrekt ist, und sie daher benutzen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

sendmail-Betrieb Der sendmail-Dämon kann auf zweierlei Weise betrieben werden. Zum einen kann er vom inetd-Dämon gestartet werden, zum anderen (und das ist die übliche Methode) kann er auch als eigenständiger Dämon betrieben werden. Häufig starten MailProgramme sendmail als Benutzeranweisung, um die Zustellung lokal erzeugter Mails zu akzeptieren. Wenn sendmail im Einzelbetrieb gestartet werden soll, plazieren Sie die erforderliche Anweisung in eine rc-Datei, so daß sie beim Systemstart ausgeführt wird. Die geläufige Syntax dafür ist: /usr/sbin/sendmail -bd -q10m

Das Argument -bd weist sendmail an, als Dämon zu starten. Es erzeugt eine Instanz von sich selbst und läuft als Hintergrundprozeß. Das Argument -q10m fordert sendmail auf, seine Warteschlange alle zehn Minuten zu überprüfen. Sie können hier auch einen anderen Wert angeben. Um sendmail vom Netzwerkdämon inetd starten zu lassen, verwenden Sie einen Eintrag wie folgt: smtp

stream

tcp nowait

nobody

/usr/sbin/sendmail -bs

Das Argument -bs teilt sendmail mit, das SMTP-Protokoll nur über die Standardeingabe/-ausgabe zu benutzen. Dies ist für die Anwendung mit inetd erforderlich. Der runq-Befehl ist für gewöhnlich nur ein symbolischer Link zum sendmail-Binärprogramm und eine Abkürzung für: # sendmail -q

Wird sendmail auf diese Weise aufgerufen, verarbeitet es alle in der Warteschlange befindlichen Mails, die übertragen werden sollen. Wird sendmail von inetd gestartet, müssen Sie auch einen cron-Job erzeugen, der den runq-Befehl periodisch aufruft, um sicherzugehen, daß die Mail-Warteschlange regelmäßig bearbeitet wird. Ein geeigneter Eintrag für die cron-Tabelle könnte so aussehen: # Startet den Mail-Spooler jede Viertelstunde 0,15,30,45

*

*

*

*

/usr/bin/runq

Bei den meisten Installationen arbeitet sendmail die Warteschlange alle 15 Minuten ab, wie in unserem crontab-Beispiel, und versucht, jede darin enthaltene Mail zu übertragen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Tips und Tricks Es gibt eine Reihe von Möglichkeiten, die Sie wahrnehmen können, um die Verwaltung eines sendmail-Systems effizient zu gestalten. Im sendmail-Paket sind mehrere Management-Tools zur Verfügung gestellt. Hier werfen wir einen Blick auf die wichtigsten von ihnen.

Mail-Spool-Verzeichnis verwalten Mails werden vor ihrer Übertragung im Verzeichnis /var/spool/mqueue zwischengespeichert (gespoolt). Dieses Verzeichnis wird als Mail-Spool-Verzeichnis (engl. mail spool) bezeichnet. Das sendmail-Programm ermöglicht es, eine formatierte Liste aller gespoolten Mail-Nachrichten nebst ihrem Zustand anzuzeigen. /usr/bin/mailq ist ein symbolischer Link auf das ausführbare sendmail-Programm und verhält sich identisch zu: # sendmail -bp

Die Ausgabe zeigt die Mail-ID, die Größe, den Zeitpunkt, zu dem die Mail in die Warteschlange aufgenommen wurde, den Absender sowie eine Meldung über den aktuellen Zustand. Das folgende Beispiel zeigt eine Mail-Nachricht, die aufgrund eines Problems in der Warteschlange festsitzt. $ mailq Mail Queue (1 request) --Q-ID-- --Size-- -----Q-Time----- -----------Sender/Recipient------------ RAA00275 124 Wed Dec 9 17:47 root (host map: lookup (tao.linux.org.au): deferred) [email protected]

Diese Nachricht befindet sich noch in der Warteschlange, da die IP-Adresse des Zielhosts nicht ermittelt werden konnte. Wir können nun sendmail dazu bringen, die Warteschlange abzuarbeiten, indem wir den /usr/bin/runq-Befehl ausführen. Der runq-Befehl erzeugt keine Ausgaben. sendmail führt die Abarbeitung der Warteschlange im Hintergrund durch.

Remote-Hosts zur Abarbeitung von Warteschlangen anweisen Wenn Sie eine temporäre Dialup-Internetverbindung mit einer festen IP-Adresse benutzen und Ihre Mails von einem MX-Host

sammeln lassen, wenn Sie offline sind, werden Sie es sicher nützlich finden, wenn Sie den MX-Host dazu bringen könnten, seine Mail-Warteschlange direkt nach dem Aufbau der Verbindung abzuarbeiten. In der sendmail-Distribution ist ein kleines Perl-Programm enthalten, das dies für Mail-Hosts, die es unterstützen, ganz leicht macht. Das etrn-Skript hat nahezu denselben Effekt auf einen Remote-Host wie runq auf unserem eigenen Host. Wenn wir das Programm wie im folgenden Beispiel aufrufen # etrn vstout.vbrew.com

weisen wir den Host vstout.vbrew.com an, alle für unsere lokale Maschine aufgelaufenen Mails abzuarbeiten. Normalerweise würden Sie diesen Befehl in Ihr PPP-Skript ip-up einfügen, damit es umgehend gestartet wird, sobald Ihre Netzwerkverbindung hergestellt ist.

Mail-Statistiken analysieren sendmail sammelt auch Daten über den Mail-Traffic sowie Informationen über Hosts, denen es Mails zugestellt hat. Zur Ausgabe dieser Informationen gibt es zwei Befehle: mailstats und hoststat. mailstats Der Befehl mailstats zeigt Statistiken über den Umfang der Mails, die von sendmail verarbeitet wurden. Zuerst wird die Zeit angegeben, zu der die Datensammlung begann. Danach folgt eine Tabelle, in der für jeden konfigurierten Mailer eine Zeile eingetragen ist, gefolgt von einer abschließenden Zeile mit einer Summe über den gesamten Datenverkehr. Jede Zeile enthält acht Einträge mit Informationen: Feld

Bedeutung

M

Die Mailer-(Transportprotokoll-)Nummer

msgsfr

Die Anzahl der von diesem Mailer empfangenen Nachrichten

bytes_from Der Umfang der Mails von diesem Mailer (in KByte) msgsto

Die Anzahl der zum Mailer gesendeten Nachrichten

bytes_to

Der Umfang der an diesen Mailer gesendeten Mails (in KByte)

msgsreg

Die Anzahl der abgewiesenen Nachrichten

msgsdis

Die Anzahl der ausgesonderten Nachrichten

Mailer

Der Name des Mailers

Eine Beispielausgabe des mailstats-Befehls zeigt Tabelle 18.5. Beispiel 18.5: Beispielausgabe des mailstats-Befehls # /usr/sbin/mailstats Statistics from Sun Dec 20 22:47:02 1998 M bytes_to msgsrej msgsdis Mailer 0 0 0K 19 prog 3 33 545K 0 0K 0 0 139 1018K 0 0 esmtp ============================================================= T 1533K 0 0

msgsfr

bytes_from 515K 0 local 5 88 121

1517K

msgsto 0 972K 158

Diese Daten werden gesammelt, falls die Option StatusFile in der Datei sendmail.cf aktiviert ist und die Zustandsdatei existiert. Normalerweise fügen Sie das folgende in Ihre sendmail.cf ein: # Statusdatei O StatusFile=/var/log/sendmail.st

Um mit einer neuen Statistik zu beginnen, müssen Sie die Länge der Statistikdatei auf null setzen

> /var/log/sendmail.st

und sendmail neu starten. hoststat Der Befehl hoststat zeigt Informationen über den Zustand von Hosts an, denen sendmail Mails zuzustellen versuchte. Der Aufruf von hoststat hat denselben Effekt wie: sendmail -bh

In der Ausgabe erscheint für jeden Host eine eigene Zeile und für jeden die verstrichene Zeit seit dem letzten Zustellungsversuch sowie die zu diesem Zeitpunkt erhaltene Zustandsmeldung. Tabelle 18.6 zeigt die Ausgabearten, die Sie vom hoststat-Befehl erwarten können. Beachten Sie, daß die meisten Resultate auf eine korrekte Zustellung hinweisen. Das Resultat für earthlink.net dagegen zeigt an, daß die Zustellung nicht funktioniert hat. Manchmal gibt die Zustandsmeldung einen Hinweis auf die Ursache des Fehlers. Im vorliegenden Fall trat ein Timeout in der Verbindung auf, vermutlich weil der Host gerade nicht am Netz oder sonstwie unerreichbar war, als die Mail zugestellt werden sollte. Beispiel 18.6: Beispielausgabe des hoststat-Befehls # hoststat -------------- Hostname ---------- How long ago ---------Results--------mail.telstra.com.au 04:05:41 250 Message accepted for scooter.eye-net.com.au 81+08:32:42 250 OK id=0zTGai-0008S9-0 yarrina.connect.com.a 53+10:46:03 250 LAA09163 Message acce happy.optus.com.au 55+03:34:40 250 Mail accepted mail.zip.com.au 04:05:33 250 RAA23904 Message acce kwanon.research.canon.com.au 44+04:39:10 250 ok 911542267 qp 21186 linux.org.au 83+10:04:11 250 IAA31139 Message acce albert.aapra.org.au 00:00:12 250 VAA21968 Message acce field.medicine.adelaide.edu.au 53+10:46:03 250 ok 910742814 qp 721 copper.fuller.net 65+12:38:00 250 OAA14470 Message acce amsat.org 5+06:49:21 250 UAA07526 Message acce mail.acm.org 53+10:46:17 250 TAA25012 Message acce extmail.bigpond.com 11+04:06:20 250 ok earthlink.net 45+05:41:09 Deferred: Connection time

Der Befehl purgestat entfernt die angesammelten Hostdaten. Er ist äquivalent zu folgendem sendmail-Aufruf: # sendmail -bH

Die Statistiken werden immer umfangreicher, bis Sie sie mit purgestat wegräumen. Sie können diesen Befehl gelegentlich selbst manuell starten oder regelmäßig automatisch ausführen lassen, indem Sie ihn in eine crontab-Datei eintragen. Die Säuberung der Statistiken führt besonders in ausgelasteten Systemen dazu, daß zum Beispiel das Durchsuchen der Statistiken deutlich schneller vor sich geht.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 19 Inbetriebnahme von Exim

Dieses Kapitel gibt Ihnen eine kurze Einführung in die Einrichtung von Exim und eine Übersicht über seine Funktionalität. Exim ist zwar in seinem Verhalten weitgehend kompatibel zu sendmail, die Konfigurationsdateien dieser beiden Programme sind jedoch grundverschieden. Die Haupt-Konfigurationsdatei ist in den meisten Linux-Distributionen /etc/exim.conf oder /etc/exim/config, in den älteren Distributionen ist es /usr/lib/exim/config. Wo die Konfigurationsdatei

in Ihrem System liegt, finden Sie über folgenden Befehl heraus: $ exim -bP configure_file

Sie müssen die Konfigurationsdatei noch für Ihr System anpassen. In den meisten Konfigurationen müssen Sie allerdings nicht viel ändern, und eine bereits funktionierende Konfiguration braucht kaum noch geändert zu werden. Per Standardeinstellung verarbeitet Exim alle ankommenden Mails und stellt sie direkt zu. Wenn Sie einen relativ umfangreichen Datenverkehr haben, wollen Sie vielleicht Exim dazu bringen, alle Mails in einer sogenannten Warteschlange (Queue) zu sammeln und sie nur in regelmäßigen Abständen abzuarbeiten. Wird Mail innerhalb eines TCP/IP-Netzwerks behandelt, läuft Exim häufig im Dämon-Modus. Beim Systemstart wird es von /etc/init.d/exim1 aufgerufen und wartet dann als Hintergrundprozeß auf ankommende TCP-Verbindungen am SMTP-Port (in der Regel Port 25). Das ist besonders dort von Vorteil, wo Sie besonders viel Datenverkehr erwarten, da Exim nicht für jede ankommende Verbindung neu gestartet werden muß. Alternativ dazu kann inetd den SMTP-Port verwalten und Exim immer dann aufrufen, wenn es zu einer Verbindung an diesem Port kommt. Diese Vorgehensweise kann nützlich sein, wenn Sie wenig Speicher und ein geringes Mail-Volumen haben. Für Exim gibt es einen komplizierten Satz von Kommandozeilenoptionen, von denen viele wie bei sendmail sind. Anstatt zu versuchen, genau die richtigen Optionen für Ihre Anforderungen zusammenzustellen, können Sie die gängigsten Betriebsarten auch mit traditionellen Befehlen wie rmail oder rsmtp implementieren. Dabei handelt es sich um symbolische Links auf Exim (falls nicht, können Sie die Links leicht selbst einrichten). Wenn Sie einen dieser Befehle aufrufen, überprüft Exim den Dateinamen, den Sie für den Aufruf benutzten, und stellt die entsprechenden Optionen selbst ein. Zwei Links auf Exim sollten Sie unter allen Umständen haben: /usr/bin/rmail und /usr/sbin/sendmail.2 Wenn Sie eine Mail-Nachricht mit einem Anwenderprogramm wie elm verfassen und abschicken, wird die Nachricht zur Zustellung über eine Pipe an sendmail oder rmail übergeben. Das ist der Grund, warum sowohl /usr/sbin/sendmail als auch /usr/bin/rmail auf Exim zeigen sollten. Die Liste der Empfänger der Nachricht wird Exim über die Kommandozeile mitgeteilt.3 Dasselbe passiert mit Mails, die über UUCP ankommen. Die erforderlichen Pfadnamen zu Exim können Sie über die folgenden Shell-Anweisungen einrichten: $ ln -s /usr/sbin/exim /usr/bin/rmail $ ln -s /usr/sbin/exim /usr/sbin/sendmail

Wollen Sie sich tiefgreifender mit den Konfigurationsdetails von Exim beschäftigen, sollten Sie sich die vollständige Exim-Spezifikation vornehmen. Wenn sie nicht bereits in Ihrer Lieblings-LinuxDistribution enthalten ist, können Sie sie dem Quellcode von Exim entnehmen oder online auf Exims Homepage unter http://www.exim.org nachlesen.

1.

Andere mögliche Stellen sind /etc/rc.d/init.d und rc.inet2. Letztere ist üblich auf Systemen, in denen die Systemadministrations-Dateien in BSD-artigen Strukturen im /etc-Verzeichnis gehalten werden.

2.

Das ist der neue Standardpfad von sendmail, gemäß dem Linux File System Standard. Häufig wird auch /usr/lib/sendmail verwendet, insbesondere von Mail-Programmen, die nicht speziell für Linux konfiguriert sind. Beide Dateinamen können Sie als symbolische Links auf Exim definieren, so daß Programme und Skripten, die sendmail aufrufen wollen, statt dessen Exim für dieselbe Aufgabe in Anspruch nehmen.

3.

Manche Anwenderprogramme benutzen jedoch SMTP, um Nachrichten an das Transportprogramm zu übergeben, und rufen es dafür mit der Option –bs auf.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Betrieb von Exim Für den Betrieb von Exim müssen Sie erst entscheiden, ob Sie damit ankommende SMTP-Nachrichten verarbeiten und Exim dafür als separaten Dämon laufen lassen wollen oder ob Sie den SMTP-Port von inetd verwalten lassen wollen und Exim nur dann aufrufen, wenn gerade eine SMTP-Verbindungsanfrage von einem Client vorliegt. In der Regel werden Sie sich auf dem Mailserver für den Dämon-Betriebsmodus entscheiden, da die Maschine dann wesentlich weniger belastet wird, als wenn Exim für jede Verbindung immer wieder wieder neu gestartet werden muß. Da der Mailserver auch die meisten ankommenden Mails direkt an die Benutzer zustellt, sollten Sie auf den meisten anderen Hosts auch den inetdBetriebsmodus wählen. Für welchen Betriebsmodus Sie sich bei den einzelnen Hosts auch entscheiden, Sie müssen immer sicherstellen, daß Sie den folgenden Eintrag in Ihrer /etc/services-Datei haben: smtp

25/tcp

# Simple Mail Transfer Protocol

Das definiert das Kürzel smtp für die Portnummer, die für SMTP-Konversationen benutzt wird. Portnummer 25 ist der Standardwert, wie er in dem “Assigned Numbers”-RFC (RFC-1700) definiert ist. Wird Exim im Dämon-Modus gestartet, versetzt es sich selbst in den Hintergrund und wartet auf Verbindungen am SMTPPort. Sobald eine Verbindung anfällt, erzeugt Exim eine Instanz von sich selbst, und der Kindprozeß beginnt dann eine SMTP-Unterhaltung mit dem Prozeß auf dem anrufenden Host. Der Exim-Dämon wird normalerweise gestartet, indem er beim Systemstart von einem rc-Skript mittels folgender Anweisung aufgerufen wird: /usr/sbin/exim -bd -q15m

Die Option –bd aktiviert den Dämon-Modus, und –q15m führt dazu, daß Exim die in der Mail-Queue angefallenen Mails alle 15 Minuten abarbeitet. Wollen Sie dagegen inetd benutzen, sollte Ihre /etc/inetd.conf-Datei eine Zeile wie folgende enthalten: smtp

stream

tcp nowait

root

/usr/sbin/exim

in.exim -bs

Denken Sie daran, daß Sie inetd erst auffordern müssen, die Datei inetd.conf neu einzulesen. Dazu senden Sie nach jeder Änderung ein HUP-Signal.1 Dämon- und inetd-Betriebsmodus schließen sich gegenseitig aus. Wenn Sie Exim im Dämon-Modus betreiben, müssen Sie unbedingt alle Zeilen in inetd.conf auskommentieren, die den smtp-Dienst betreffen. Wenn Sie Exim dagegen von inetd managen lassen, müssen Sie natürlich sicherstellen, daß kein rc-Skript den Exim-Dämon startet. Sie können überprüfen, ob Exim für den Empfang von SMTP-Nachrichten korrekt eingerichtet wurde, indem Sie den SMTPPort auf Ihrer Maschine über Telnet ansprechen. Eine erfolgreiche Verbindung zum SMTP-Server sieht dann etwa wie folgt aus: $ telnet localhost smtp Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 richard.vbrew.com ESMTP Exim 3.13 #1 Sun, 30 Jan 2000 16:23:55 +0600 quit 221 richard.brew.com closing connection Connection closed by foreign host.

Wenn dieser Test kein SMTP-Banner erzeugt (die Zeile, die mit 220 beginnt), überprüfen Sie, ob Sie entweder einen EximDämon-Prozeß laufen haben oder ob Sie inetd richtig konfiguriert haben. Wird das Problem dadurch nicht offenbar, werfen Sie einen Blick in die Logdateien von Exim (Beschreibung folgt), ob da nicht vielleicht ein Fehler in Exims Konfigurationsdatei vorliegt.

1.

Verwenden Sie dafür kill HUP pid, wobei pid die Prozeß-ID des inetd-Prozesses ist, die Sie der Ausgabe von ps entnehmen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wenn Ihre Mail nicht durchkommt Für die Fehlersuche bei Installationsproblemen gibt es mehrere Möglichkeiten. Als erstes sollten Sie sich immer die Logdateien von Exim vornehmen. Auf Linux-Systemen werden sie normalerweise im Verzeichnis /var/log/exim/log angelegt und heißen exim_mainlog, exim_rejectlog sowie exim_paniclog. Auf anderen Betriebssystemen werden sie häufig in /var/spool/exim/log gespeichert. Wo die Logdateien sich genau befinden, finden Sie über folgenden Befehl heraus: exim -bP log_file_path

exim_mainlog listet alle Transaktionen auf, exim_rejectlog enthält Details über Nachrichten, die aus Gründen der Politiken abgewiesen wurden, und exim_paniclog enthält Infos über Konfigurationsfehler und ähnliches. Typische Einträge in exim_mainlog sind unten angegeben. Jeder Eintrag in dieser Logdatei besteht aus einer einzelnen Textzeile, die mit einem Datum und einer Uhrzeit beginnt. Die Einträge sind hier in mehrere Zeilen aufgeteilt, damit sie auf diese Seite passen. 2000-01-30 15:46:37 12EwYe-0004WO-00 <= [email protected] H=vstout.vbrew.com [192.168.131.111] U=exim P=esmtp S=32100 [email protected] 2000-01-30 15:46:37 12EwYe-0004WO-00 => jill <[email protected]> D=localuser T=local_delivery 2000-01-30 15:46:37 12EwYe0004WO-00 Completed

Diese Einträge zeigen an, daß eine Nachricht von [email protected] an [email protected] erfolgreich an eine Mailbox auf dem lokalen Host zugestellt werden konnte. Ankommende Nachrichten sind mit <= markiert, ausgehende mit =>. Es gibt zwei Arten von Zustellungsfehlern: permanente und temporäre. Ein permanenter Zustellungsfehler wird in einem Logeintrag folgender Form festgehalten (markiert mit **): 2000-01-30 14:48:28 12EvcH-0003rC-00 ** [email protected] R=lookuphost T=smtp: SMTP error from remote mailer after RCPT TO: : host lager.vbrew.com [192.168.157.2]: 550 ... User unknown

Nach einem solchen Fehler sendet Exim einen Fehlerreport, oft als Bounce Message bezeichnet, an den Absender zurück. Temporäre Fehler sind mit == markiert:

2000-01-30 12:50:50 12E9Un-0004Wq-00 == [email protected] out

T=smtp defer (145): Connection timed

Dieser Fehler ist typisch für eine Situation, in der Exim richtig erkennt, daß die Nachricht an einen Remote-Host zugestellt werden soll, aber mit dem SMTP-Dienst dieses Hosts keine Verbindung aufgenommen werden kann. Der entsprechende Host könnte gerade ausgefallen sein, oder es könnte eine Störung im Netz vorliegen. Immer wenn eine Nachricht so aufgeschoben wird, bleibt sie in Exims Warteschlange, und der Zustellungsversuch wird in regelmäßigen Abständen wiederholt. Wenn diese Versuche allerdings über einen längeren Zeitraum (in der Regel mehrere Tage) wiederholt fehlschlagen, tritt ein permanenter Fehler ein, und die Nachricht wird als Bounce Message wieder zurückgeschickt. Wenn Sie die Ursache Ihres Problems nicht in den Fehlermeldungen erkennen können, die Exim erzeugt, werden Sie Debugging-Meldungen aktivieren wollen. Dazu benutzen Sie die Option –d, optional gefolgt von einer Zahl, die die “Gesprächigkeit” angibt (9 für maximale Information). Exim gibt dann einen Bericht über seine Aktivitäten auf dem Bildschirm aus, anhand dessen Sie vielleicht genauere Hinweise finden, was da gerade schiefläuft.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Exim kompilieren Exim wird noch immer aktiv weiterentwickelt. Die in den Linux-Distributionen enthaltene EximVersion ist womöglich nicht mehr die aktuellste. Wenn Sie ein Feature oder einen Bugfix einer neueren Version benötigen, müssen Sie sich eine Kopie des Quell-codes herunterladen und diese selbst kompilieren. Die neueste Release finden Sie auf Exims Homepage unter http://www.exim.org. Linux ist eines der vielen Betriebssysteme, die vom Exim-Quellcode unterstützt werden. Um Exim für Linux zu kompilieren, sollten Sie die Datei src/EDITME editieren und das Resultat in der Datei Local/Makefile abspeichern. Kommentare in src/EDITME sagen Ihnen, welchen Zweck die verschiedenen Einstellungen erfüllen. Führen Sie danach make aus. Detaillierte Informationen, wie man aus dem Quellcode das fertige Exim erhält, finden Sie im Exim-Manual.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Mail-Zustellungsarten Wie bereits erwähnt, kann Exim Nachrichten direkt zustellen oder für die spätere Bearbeitung in eine Warteschlange aufnehmen. Alle ankommenden Mails werden im input-Verzeichnis unter /var/spool/exim abgelegt. Ist die Warteschlange nicht in Betrieb, wird für jede Mail, sobald sie eintrifft, ein Prozeß für die Zustellung gestartet. Ansonsten bleibt sie so lange in der Warteschlange, bis ein queue-runner-Prozeß sich ihrer annimmt. Die Warteschlange kann unabhängig von irgendwelchen Bedingungen betrieben werden, wenn die Option queue_only in der Konfigurationsdatei gesetzt ist. Sie kann aber auch abhängig von der aktuellen Systemlast im 1-Minuten-Taktbetrieben werden, indem Sie etwa folgende Option angeben: queue_only_load = 4

Das führt dazu, daß Nachrichten in die Warteschlange aufgenommen werden, wenn der System Load über 4 liegt.1 Wenn Ihr Host nicht permanent mit dem Internet verbunden ist, wollen Sie vielleicht eine Warteschlange für herausgehende Mails einrichten, während Exim die lokalen Mails immer direkt zustellen darf. Das erreichen Sie mit folgender Einstellung in der Konfigurationsdatei: queue_remote_domains = *

Wenn Sie irgendwelche Warteschlangen eingerichtet haben, müssen Sie sicherstellen, daß sie auch regelmäßig abgearbeitet werden, vielleicht so etwa alle 10 oder 15 Minuten. Auch wenn Sie keine expliziten Queue-Optionen angegeben haben, müssen die Warteschlangen trotzdem auf Nachrichten überprüft werden, die aufgrund von temporären Zustellungsproblemen verzögert sein könnten. Wenn Sie Exim im Dämon-Modus laufen lassen, müssen Sie in der Befehlszeile die Option –q15m angeben, um die Queue jede Viertelstunde abzuarbeiten. Sie können exim –q in diesen Abständen natürlich auch von cron ausführen lassen. Sie können sich den aktuellen Inhalt der Mail-Queue anzeigen lassen, indem Sie Exim mit der Option –bp aufrufen. Genausogut können Sie einen Link von mailq auf Exim einrichten und dann einfach mailq aufrufen: $ mailq 2h 52K 12EwGE-0005jD-00 <[email protected]> [email protected]

D [email protected]

Hier wird eine einzelne Nachricht von [email protected] an zwei Empfänger angezeigt, die sich in der Warteschlange befindet. Sie wurde erfolgreich an [email protected] zugestellt, aber noch nicht an [email protected], obwohl sie nun schon zwei Stunden in der Queue festsitzt. Die Nachricht hat einen Umfang von 52K, und die ID, unter der Exim die Nachricht identifiziert, hat die Bezeichnung 12EwGE-0005jD-00. Sie finden heraus, warum die Zustellung noch nicht funktioniert hat, indem Sie einen Blick in die individuelle Logdatei der Nachricht werfen, die im Verzeichnis msglog in Exims Spool-Verzeichnis eingetragen ist. Dazu benutzen Sie einfach die Option –Mvl: $ exim -Mvl 12EwGE-0005jD-00 2000-01-30 17:28:13 example.net [192.168.8.2]: Connection timed out 2000-01-30 17:28:13 [email protected]: remote_smtp transport deferred: Connection timed out

Individuelle Logdateien enthalten für jede Nachricht eine Kopie der Logeinträge, so daß Sie sie leicht inspizieren können. Dieselben Informationen könnten Sie auch aus exim_mainlog extrahieren. Dazu benutzen Sie das Utility exigrep: $ exigrep 12EwGE-0005jD-00 /var/log/exim/exim_mainlog

Dies nimmt allerdings mehr Zeit in Anspruch, insbesondere auf einem ausgelasteten System, auf dem die Logdateien ziemlich groß werden können. Das exigrep-Utility kommt erst dann groß heraus wenn man nach Informationen über mehrere Nachrichten sucht. Das erste Argument ist ein regulärer Ausdruck, und es sucht alle Logzeilen heraus, die mit irgendwelchen Nachrichten zu tun haben, die mindestens eine Logzeile enthalten, die zum regulären Ausdruck paßt. Es kann also dazu benutzt werden, alle Nachrichten für eine bestimmte Adresse zu ermitteln oder alle von bzw. zu einem bestimmten Host. Sie haben ständige Kontrolle über die Aktivitäten von Exim, wenn Sie den Befehl tail auf exim_mainlog anwenden. Eine andere Methode dafür ist die Ausführung des -eximon-Utilities, das mit Exim geliefert wird. Hierbei handelt es sich um eine X11-Anwendung, die eine fortlaufende Ausgabe des Inhalts der main log erzeugt, dazu eine Liste der Nachrichten anzeigt, die auf ihre Zustellung warten, und einige Kurzinfos über die Zustellungsaktivitäten präsentiert.

1.

Der System Load ist ein standardisiertes Unix-Maß für die durchschnittliche Anzahl der aufgelaufenen Prozesse. Der Befehl uptime zeigt den mittleren Load über die letzten 1, 5 und 15 Minuten an.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verschiedene Konfigurationsoptionen Im folgenden sehen Sie einige der nützlicheren Optionen, die Sie in der Konfigurationsdatei einstellen können: message_size_limit Begrenzt den Umfang der Nachrichten, die Exim akzeptiert. return_size_limit Begrenzt den Umfang einer ankommenden Nachricht, die Exim als Teil einer Bounce Message zurückliefert. deliver_load_max Ist der aktuelle System-Load größer als der in dieser Option angegebene Wert, wird die MailZustellung unterbrochen; auf Eis gelegt; ankommende Nachrichten werden jedoch weiterhin verarbeitet. smtp_accept_max

Die maximale Anzahl gleichzeitiger SMTP-Eingänge, die Exim zu akzeptieren bereit ist. log_level Bestimmt den Datenumfang, der in die Logdatei geschrieben wird. Es gibt auch einige Optionen, die mit log_ beginnen und spezifische Logausgaben einstellen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Routing und die Zustellung von Nachrichten Exim teilt die Mail-Zustellung in drei Aufgabengebiete ein: Routing, Vermittlung und Transport. Für jedes dieser Gebiete existiert eine Anzahl von Codemodulen, und jedes kann separat konfiguriert werden. Für gewöhnlich werden in der Konfigurationsdatei eine Reihe verschiedener Router, Vermittler und Transporte eingerichtet. Router lösen Remote-Adressen auf, ermitteln, an welchen Host eine Nachricht gesendet werden soll und welcher Transport dafür genutzt werden soll. In Hosts, die mit dem Internet verbunden sind, existiert oft nur ein Router, der die Namensauflösung mittels DNS durchführt. Alternativ dazu kann ein Router abgestellt sein, der sich um die Adressen kümmert, die für Hosts in einem lokalen LAN bestimmt sind, während ein zweiter Router die verbleibenden Adressen an einen einzelnen Smart Host sendet; das kann z.B. ein Mail-Server eines Internet Service Providers sein. Lokale Adressen werden an die Vermittler (engl. director) übergeben, von denen es normalerweise gleich mehrere gibt. Sie kümmern sich um Aliasing (Resolvierung von Aliasnamen) und Forwarding (Weiterleitung von Mails), aber auch um die Identifizierung lokaler Mailboxen. Mailing-Listen können von Aliasing- oder Forwarding-Vermittlern verarbeitet werden. Wird eine Adresse einem Aliasing oder Forwarding unterzogen, werden alle erzeugten Adressen unabhängig voneinander und je nach Bedarf von den Routern oder den Vermittlern weiterverarbeitet. Der bei weitem am häufigsten vorkommende Fall ist die Zustellung an eine Mailbox. Nachrichten können aber auch über eine Pipe an ein Kommando übergeben oder an eine andere Datei als die Standard-Mailbox angehängt werden. Ein Transport ist verantwortlich für die Implementierung einer Zustellungsmethode. Damit ist zum Beispiel das Versenden einer Nachricht über eine SMTP-Verbindung oder ihre Eintragung in eine bestimmte Mailbox gemeint. Die Router und Vermittler entscheiden selbst, welcher Transport für welche Empfängeradresse genommen wird. Falls ein Transport fehlschlägt, erzeugt Exim entweder eine Bounce Message oder verzögert die Zustellung für einen späteren Wiederholungsversuch. Bei Exim haben Sie viele Freiheiten, solche Aufgaben zu konfigurieren. Für jede Aufgabe gibt es eine Anzahl von Treibern, aus denen Sie sich die gewünschten auswählen können. Sie beschreiben sie für Exim in unterschiedlichen Abschnitten seiner Konfigurationsdatei. Zuerst werden die Transporte definiert, danach die Vermittler und schließlich die Router. Es gibt keine eingebauten Voreinstellungen, obwohl Exim mit einer Standard-Konfigurationsdatei ausgeliefert wird, die einfache Anwendungsfälle abdeckt. Wenn Sie Exims Routing-Strategie oder einen Transport verändern wollen, ist es am einfachsten, mit der Standard-Konfigurationsdatei zu beginnen und dort die notwendigen Änderungen durchzuführen, anstatt zu versuchen, mit einer völlig neuen Konfiguration zu beginnen.

Routing von Nachrichten Sobald eine zuzustellende Adresse vorliegt, prüft Exim zuerst, ob die Domain eine ist, die auf dem lokalen Host verarbeitet wird. Dazu vergleicht Exim sie mit einer Liste in der Konfigurationsvariablen local_domains. Falls diese Option nicht gesetzt ist, wird der lokale Hostname als einzige lokale Domain verwendet. Ist die Domain lokal, wird die Adresse an die Vermittler übergeben, andernfalls an die Router, um herauszufinden, an welchen Host die Nachricht weitergeleitet werden muß.1

Nachrichten an lokale Adressen zustellen In den meisten Fällen besteht eine lokale Adresse nur aus dem Login-Namen des Benutzers. In einem solchen Fall werden Nachrichten direkt an die Mailbox /var/spool/mail/user-name des Benutzers zugestellt. In anderen Fällen können Aliase, Namen von Mail-ing-Listen sowie Mail-Forwarding durch den Benutzer vorkommen. In diesen Fällen expandiert die lokale Adresse zu einer neuen Liste von Adressen, von denen jede lokal oder entfernt sein kann. Abgesehen von diesen “normalen” Adressen kommt Exim auch mit anderen Adressierungsweisen für lokale Nachrichten zurecht, wozu unter anderem Dateinamen und Pipe-Kommandos zählen. Bei der Zustellung an eine Datei hängt Exim die Nachricht an die Datei an oder erzeugt gegebenenfalls eine neue Datei. Dateien und Pipes sind -allerdings keine Adressen an sich; Sie können aus diesem Grund nicht beispielsweise an /etc/[email protected] eine Nachricht schicken und erwarten, daß die Paßwortdatei damit überschrieben wird. Zustellungen an eine bestimmte Datei sind nur dann zulässig, wenn sie von Forwarding- oder Alias-Dateien kommen. Beachten Sie, daß /etc/[email protected] zwar eine syntaktisch gültige E-MailAdresse ist, aber Exim sie nach Erhalt sofort als Bounce Message zurückschicken würde, denn Exim würde (normalerweise) nach einem Benutzer mit dem Login-Namen /etc/passwd suchen, der natürlich nicht existiert. In einer Alias-Liste oder einer Forwarding-Datei wird unter einem Dateinamen alles verstanden, was mit einem Schrägstrich (/) beginnt und keine voll qualifizierte E-Mail-Adresse darstellt. Zum Beispiel wird /tmp/junk in einer Forwarding- oder AliasDatei als Dateiname interpretiert, während /tmp/[email protected] eine (wenn auch nicht besonders sinnvolle) E-Mail-Adresse ist. Solche Adressen können durchaus zulässig sein, wie etwa bei Mails, die über X.400-Gateways gesendet werden, da X.400Adressen immer mit einem Schrägstrich beginnen. Auf ähnliche Weise versteht man unter einem Pipe-Kommando ein beliebiges Unix-Kommando, dem ein Pipe-Symbol (|) vorangestellt ist, es sei denn, der String stellt eine zulässige E-Mail-Adresse inklusive Domain dar. Wenn Sie nichts an Exims Konfiguration verändert haben, benutzt Exim keine Shell, um den Befehl auszuführen, sondern spaltet den String selbst in Befehlsname und Argumente auf und führt den Befehl direkt aus. Die Nachricht erhält der Befehl über seine Standardeingabe. Um zum Beispiel eine Mailing-Liste in eine lokale Newsgruppe umzuleiten, könnten Sie ein Shell-Skript namens gateit benutzen und einen lokalen Alias einrichten, der alle Nachrichten aus dieser Mailing-Liste mittels der Anweisung |gateit an das Skript übergibt. Wenn die Anweisung ein Komma enthält, muß sie (inklusive Pipe-Symbol) in Anführungszeichen gesetzt werden. Lokale Benutzer Eine lokale Adresse bezeichnet in der Regel eine Benutzer-Mailbox. Sie befindet sich normalerweise im Verzeichnis /var/spool/mail und hat den Namen des Benutzers, der auch Eigentümer dieser Datei ist. Fehlt diese Datei, wird sie von Exim erzeugt. In manchen Konfigurationen stimmt die Gruppe mit der Gruppe des Benutzers überein, und der Zugriffsmodus ist 0600. In diesen Fällen laufen die Zustellungsprozesse mit den Rechten des Benutzers, und der Benutzer darf daher die Mailbox vollständig löschen. In anderen Konfigurationen ist die Gruppe der Mailbox auf mail mit Zugriffsrecht 660 gesetzt. Die Zustellungsprozesse laufen dann unter einer System-UID und mit mail als Gruppe. Die Benutzer können ihre Mailbox-Dateien daher nicht löschen, sondern nur leeren. Beachten Sie, daß manche Mail-Software für andere Verzeichnisse als das aktuelle Standardverzeichnis /var/spool/mail für Mailbox-Dateien kompiliert sein kann, zum Beispiel /usr/spool/mail. Falls die Zustellung an Benutzer auf Ihrer Maschine permanent fehlschlägt, sollten Sie mal prüfen, ob es hilft, wenn Sie vom verwendeten Mail-Verzeichnis einen symbolischen

Link auf /var/spool/mail einrichten. Die Adressen MAILER-DAEMON und postmaster müssen in Ihrer Alias-Datei erscheinen und zur E-Mail-Adresse des Systemadministrators expandieren. MAILER-DAEMON wird von Exim als Absender in Bounce Messages benutzt. Es ist auch zu empfehlen, daß root als Alias für einen Administrator eingerichtet wird, besonders dann, wenn Zustellungen unter den Zugriffsrechten der Empfänger laufen. Das verhindert jede Zustellung als root. Forwarding Benutzer können ihre Mails an alternative Adressen umleiten, indem sie eine .forward-Datei in ihren Home-Verzeichnissen anlegen. Sie enthält eine Liste von Empfängern (durch Kommata und/oder Newline-Zeichen getrennt). Alle Zeilen dieser Dateien werden eingelesen und interpretiert. Es kann jede Adressierungsart verwendet werden. Ein praktisches Beispiel einer .forward-Datei für Abwesenheiten und Urlaub könnte so aussehen: janet, "|vacation"

In anderen Beschreibungen von .forward-Dateien sehen Sie vielleicht den Benutzernamen mit vorangestelltem Backslash am Anfang. Das war in manchen älteren MTAs notwendig, um eine Suche nach einem .forward für den neuen Namen zu stoppen, was zu einer Endlosschleife führen könnte. Der Backslash ist für Exim, das Schleifen solcher Art automatisch vermeidet, nicht notwendig.2 Dennoch ist ein Backslash erlaubt, und in der Tat macht dies einen Unterschied in Konfigurationen aus, wo mehrere Domains auf einmal behandelt werden. Ohne Backslash wird ein unqualifizierter Benutzername mit einer Standarddomain qualifiziert; mit Backslash bleibt die ankommende Domain dagegen unverändert. Die erste Adresse in einer Forward-Datei stellt die ankommende Nachricht an die Mail-box von janet zu, während der Befehl vacation eine Kurzmitteilung an den Absender zurückliefert.3 Als Ergänzung zur Unterstützung “traditioneller” Forwarding-Dateien kann Exim so konfiguriert werden, daß es auch komplexere Dateien, sogenannte Filter, gestattet. Anstatt einfach nur eine Liste von Forwarding-Adressen zu sein, kann eine Filterdatei auch Tests enthalten, die die Inhalte ankommender Nachrichten überprüfen, so daß zum Beispiel Nachrichten nur dann weitergeleitet werden, wenn ihr Subject die Meldung “dringend” enthält. Ob den Benutzern allerdings eine solche Flexibilität gewährt werden sollte, muß der Systemadministrator selbst entscheiden.

Alias-Dateien Exim kann Alias-Dateien verarbeiten, die kompatibel zu den sendmail-Alias-Dateien von Berkeley sind. Einträge in der AliasDatei können folgende Form annehmen: Alias: Empfänger

Empfänger ist eine durch Kommata getrennte Liste von Adressen, die für den Alias substituiert werden. Die Empfängerliste kann über das Zeilenende hinaus fortgesetzt werden, wenn die nachfolgende Zeile mit einem Leerzeichen beginnt. Ein spezielles Feature erlaubt Exim die Verarbeitung von Mailing-Listen, die separat von der Alias-Datei gehalten werden: Wenn Sie :include:Dateiname als einen Empfänger angeben, liest Exim die angegebene Datei ein und ersetzt ihre Inhalte durch eine Liste von Empfängern. Eine Alternative zur Verarbeitung von Mailing-Listen wird später in diesem Kapitel im Abschnitt Mailing-Listen gezeigt. Die Haupt-Alias-Datei ist /etc/aliases. Wenn Sie sie world- oder group-schreibbar machen, weigert sich Exim, sie zu benutzen, und legt alle lokalen Zustellungen auf Eis. Sie können den Test, den Exim auf die Zugriffsrechte der Datei anwendet, steuern, indem Sie die Option modemask im system_aliases-Verteiler setzen. Dies ist eine beispielhafte aliases-Datei: # vbrew.com /etc/aliases file hostmaster: janet postmaster: janet usenet: phil # Die DevelopmentMailing-Liste development: joe, sue, mark, biff, /var/mail/log/development ownerdevelopment: joe # Ankündigungen von allgemeinem Interesse # werden an alle staff-Benutzer gesendet

announce: :include: /etc/Exim/staff, /var/mail/log/announce owner-announce: root # Leitet die ppp-Mailing-Liste an eine lokale Newsgruppe weiter ppp-list: "|/usr/local/bin/gateit local.lists.ppp"

Wenn wie hier Dateinamen und Pipe-Kommandos in einer Alias-Datei vorkommen, muß Exim darüber informiert werden, unter welcher Benutzer-ID die Zustellungen erfolgen sollen. Die Option user (eventuell auch group) muß in der Konfigurationsdatei von Exim gesetzt sein — entweder auf dem Vermittler, der die Aliase verarbeitet, oder auf den Transporten, an die es diese Daten richtet. Falls bei der Zustellung an eine Adresse, die aus der aliases-Datei erzeugt wurde, ein Fehler auftritt, sendet Exim wie gewöhnlich eine Bounce Message an den Absender der Nachricht, aber das muß nicht unbedingt angemessen sein. Über die Option errors_to kann man festlegen, daß Bounce Messages woandershin gesendet werden, zum Beispiel an den Postmaster.

Mailing-Listen Anstatt über die aliases-Datei können Mailing-Listen auch von einem forwardfile-Vermittler verwaltet werden. Die Listen werden alle in einem einzelnen Verzeichnis wie /etc/exim/lists/ aufbewahrt; eine Mailing-Liste mit Namen nag-bugs wird dann durch die Datei lists/nag-bugs beschrieben. Diese sollte die Mitgliederadressen enthalten, die durch Kommata oder Zeilenwechsel getrennt werden. Zeilen, die mit einem # beginnen, werden wie Kommentare behandelt. Ein einfacher Vermittler für solche Daten ist folgender: lists: driver = forwardfile file = /etc/exim/lists/${local_part} errors_to = ${local_part}-request

no_check_local_user

Wenn dieser Vermittler läuft, werden die Werte der Optionen file und errors_to expandiert. Expansionen bewirken, daß bestimmte Abschnitte der Strings, die mit Dollarzeichen beginnen, bei jeder Anwendung der Strings ersetzt werden. Die einfachste Art der Expansion ist das Einfügen des Wertes einer der Exim-Variablen, und genau das passiert hier. Der Substring ${local_part} ersetzt den Wert von $local_part, was der lokale Teil der gerade abgearbeiteten Adresse ist. Für jede Mailing-Liste sollte ein Benutzer (oder Alias oder eine Mailing-Liste) namens listname-request existieren. Alle Fehler, die bei der Auflösung einer Adresse oder bei der Zustellung an Mitglieder der Mailing-Liste auftreten, werden an diese Adresse gemeldet.

1.

Das ist eine vereinfachte Darstellung. Vermittler können Adressen an Transporte weitergeben, die sie an Remote-Hosts zustellen, und ähnliches. Router können Adressen an lokale Transporte übergeben, die die Nachricht in eine Datei oder eine Pipe schreiben. Es ist Routern auch möglich, unter gegebenen Umständen Adressen an die Vermittler zu übergeben.

2.

Ein Vermittler wird übersprungen, wenn die Adresse, die er im Begriff ist zu verarbeiten, eine ist, die er vorher bei der Erzeugung der aktuellen Adresse bereits verarbeitet hat.

3.

Wenn Sie ein vacation-Programm benutzen, stellen Sie bitte sicher, daß es nicht auf Nachrichten aus Mail-ing-Listen antwortet! Es ist wirklich sehr lästig, wenn irgend jemand in Urlaub gegangen ist und man für jede von ihm empfangene Nachricht eine Vacation-Message vorfindet. Mailing-Listen-Administratoren: Dies ist ein gutes Beispiel dafür, warum es eine schlechte Gepflogenheit ist, in das Reply-To:-Feld von Mailing-Listen-Nachrichten die Submission-Adresse einzutragen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Schutz vor Mail Spam Mail Spam, oder unerwünschte E-Mail-Werbung, stellt für viele Anwender ein lästiges Problem dar. Daher wurde ein Projekt ins Leben gerufen, das sich dieses Problems annimmt: das Mail Abuse Protection System (MAPS). Und es wurde ein Mechanismus entwickelt, der dieses Problem in Schach hält, genannt Real Time Blackhole List (RBL). Informationen, wie die MAPS-RBL funktioniert, können der Online-Dokumentation unter http://maps.vix.com/rbl/ entnommen werden. Die Idee ist einfach. Systeme, die bei der Erzeugung von Mail Spam erwischt wurden, werden in die Datenbank eingetragen. Mail-Transfer-Agenten wie Exim können diese Datenbank abfragen, um eine Bestätigung zu erhalten, daß eine Quelle kein “Spammer” ist, bevor die Mail von ihm akzeptiert wird. Seit dem Erscheinen von RBL wurden diverse andere ähnliche Listen gebildet. Eine der nützlichsten ist die Dial-UpListe (DUL), die IP-Adressen von Dial-Up-Hosts enthält. Diese sollten ausgehende Mails normalerweise nur an die Mailserver ihres ISP senden. Viele Systeme blocken Mails von externen Dial-Ups ab, denn wenn solch ein Host den Server seines eigenen ISP meidet, führt er für gewöhnlich nichts Gutes im Schilde. Exim bietet Unterstützung für die Real-Time- und andere Black-Listen. Es ist sehr leicht zu konfigurieren. Um es zu aktivieren, fügen Sie folgende Zeilen in Ihre /etc/exim.conf-Datei ein: # Vixie / MAPS RBL (http://maps.vix.com/rbl) rbl_domains = rbl.maps.vix.com : dul.maps.vix.com

Dieses Beispiel prüft sowohl die RBL als auch die DUL und blockt alle Nachrichten von Hosts ab, die in einer der beiden Listen aufgeführt sind. Die Option rbl_hosts ermöglicht Ihnen die Angabe von Gruppen von Hosts, auf die die RBL-Prüfung angewendet (oder nicht angewendet) werden soll. Die Standardeinstellung ist: rbl_hosts = *

Das bedeutet, daß alle Hosts einer RBL-Prüfung unterzogen werden. Wenn Sie die Black-List überschreiben und Mail von einem bestimmten Host empfangen wollen, ohne für ihn eine RBL-Prüfung vorzunehmen, könnten Sie etwa folgendes benutzen:

rbl_hosts = ! nocheck.example.com : *

Das Ausrufezeichen vor dem ersten Eintrag in dieser Liste zeigt eine Negation an. Falls es sich beim anrufenden Host um nocheck.example.com handelt, paßt er zu diesem Eintrag. Jedoch wird aufgrund der Negation keine RBL-Prüfung vorgenommen. Alle anderen Hosts passen zum zweiten Eintrag in der Liste.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

UUCP einrichten Exim hat weder spezifischen Code für den Transport von Mail über UUCP, noch unterstützt es UUCP-Bang-Path-Adressen. Wenn jedoch Domainadressen verwendet werden, kann Exim recht einfach an UUCP gekoppelt werden. Hier folgt ein Ausschnitt einer Konfiguration zum Senden bestimmter Domains an UUCP, der einer echten Installation entnommen wurde: # Transport uucp: driver = pipe user = nobody command = "/usr/local/bin/uux -r - \ ${substr_-5:$host}!rmail ${local_part}" return_fail_output = true # Router uucphost: = uucp driver = domainlist route_file = /usr/exim/uucphosts search_type = lsearch

transport

In einer vollständigen Konfigurationsdatei würde der Transport zwischen den anderen Transporten installiert und der Router wahrscheinlich als erster Router definiert werden. Die Datei /usr/exim/uucphosts enthält Einträge folgender Art: darksite.example.com:

darksite.UUCP

Das bedeutet: “Sende Mail, die an die Domain darksite.example.com adressiert ist, zum UUCP-Host darksite.” Die Konfiguration könnte auch einfacher eingerichtet werden, so daß der Router nicht die Endung .UUCP an darksite anhängen muß, nur damit der Transport sie anschließend wieder entfernt. Dennoch ist dieser Weg sinnvoll, da er den Unterschied zwischen dem Domainnamen darksite.example.com und dem UUCP-Hostnamen darksite besonders deutlich macht. Immer wenn der Router auf eine Domain stößt, die in der Route-Datei angegeben ist, sendet er die Adresse an den UUCPTransport, der sie anschließend über eine Pipe an uux weitergibt (wie in Kapitel 16 Taylor UUCP verwalten, beschrieben). Falls ein Problem auftaucht, erzeugt uux einige Ausgaben und beendet sich mit einem Fehlercode ungleich null. Die Einstellung return_fail_output stellt sicher daß die Ausgabe an den Absender zurückgeliefert wird. Falls ankommende UUCP-Nachrichten in Dateien gruppiert sind, die dem Batched-SMTP-Format entsprechen, können sie mit folgender Anweisung direkt an Exim weitergereicht werden: exim -bS
Die Sache hat allerdings einen Haken. Wenn Exim eine Nachricht lokal empfängt, besteht es darauf, daß es sich beim Absender um den angemeldeten Systembenutzer handelt, der es aufruft. Bei einem UUCP-Batch wollen wir jedoch die Absender aus den ankommenden Nachrichten ermitteln. Exim macht dies auch, allerdings nur, wenn der Prozeß, der es aufruft, als trusted user läuft, also vertrauenswürdig ist. Wenn Sie wollen, daß ankommende UUCP-Nachrichten zum Beispiel

von einem Benutzer namens uucp bearbeitet werden, müssen Sie trusted_users = uucp

in der Konfigurationsdatei von Exim angeben, um sicherzustellen, daß die Absenderadressen korrekt verarbeitet werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 20 Netnews

Netnews bzw. Usenet-News sind und bleiben heutzutage einer der wichtigsten und am meisten geschätzten Dienste in Computernetzwerken. Auch wenn es von manchen als ein Sumpf von unerwünschten kommerziellen E-Mails und Pornografie abgestempelt wird, hält Netnews immer noch so manche Paradebeispiele für qualitativ hochwertige Diskussionsgruppen bereit, die es in den Tagen vor dem Web zu einer eminent wichtigen Ressource werden ließen. Sogar heute, in den Zeiten der zig

Millionen Webseiten, ist Netnews immer noch für viele Themenbereiche eine Quelle für Online-Hilfe und Online-Gemeinschaften.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Geschichte von Usenet Die Idee der Netzwerk-News wurde im Jahr 1979 geboren. Die beiden Studenten Tom Truscott und Jim Ellis wollten UUCP verwenden, um Maschinen miteinander zu verbinden, damit Informationen zwischen UNIX-Benutzern ausgetauscht werden könnten. Sie richteten ein kleines Netzwerk aus drei Maschinen in North Carolina ein. Zu Beginn wurde die Datenübertragung durch eine Reihe von Shell-Skripten (die später in C umgeschrieben wurden) gehandhabt. Diese wurden der Öffentlichkeit aber niemals zugänglich gemacht, sondern schnell durch “A News” ersetzt, der ersten öffentlichen Release einer NewsSoftware. A News war nicht dafür ausgelegt, mehr als einige Artikel pro Gruppe und Tag zu verwalten. Als das Volumen wuchs, wurde es von Mark Horton und Matt Glickman neu geschrieben, die es die “B”Release (also B News) tauften. Die erste öffentliche Release von B News war Version 2.1 im Jahre 1982. Es wurde kontinuierlich erweitert, und neue Features wurden integriert. Die aktuelle Version ist B News 2.11. Es ist aber langsam überholt; der letzte offizielle Verwalter wechselte zu INN. Die B News wurden noch einmal neu geschrieben und im Jahre 1987 von Geoff Collyer und Henry Spencer als Release “C”, oder C News, veröffentlicht. Seit seiner Veröffentlichung hat es eine Reihe von Patches für C News gegeben. Der bekannteste ist sicherlich die “C News Performance Release”.

Auf Systemen mit einer großen Anzahl von Gruppen ist der durch das ständige Aufrufen von relaynews erzeugte Overhead beträchtlich. Dieses Programm ist für die Weiterleitung eingehender Artikel an andere Hosts zuständig. Die Performance Release erweitert relaynews um eine Option, mit der das System im Dämon-Modus ausgeführt werden kann, bei dem sich das Programm selbständig in den Hintergrund begibt. Die Performance Release ist die Version der C News, die momentan in den meisten Linux-Releases zu finden ist. Wir beschreiben C News im Detail in Kapitel 21 C News. Alle News-Releases bis hin zu C waren primär für die Verwendung in UUCP-Netzwerken ausgelegt, obwohl sie auch in anderen Umgebungen verwendet werden konnten. Die effiziente Übertragung von News über Netzwerke wie TCP/IP oder DECNet machte ein neues Schema notwendig. Daher wurde im Jahr 1986 das Network News Transfer Protocol (NNTP) eingeführt. Es basiert auf Netzwerkverbindungen und spezifiziert eine Reihe von Befehlen für die interaktive Übertragung und den Empfang von Artikeln. Über das Netz stehen eine ganze Reihe von NNTP-basierten Anwendungen zur Verfügung. Eine davon ist das nntpd-Paket von Brian Barber und Phil Lapsley, mit dem Sie Newsreading-Dienste für eine ganze Reihe von Hosts innerhalb eines lokalen Netzwerks bereitstellen können. nntpd ist so entworfen worden, daß es News-Pakete wie B News oder C News um NNTP-Features erweitert. Wenn Sie NNTP mit dem C News-Server benutzen wollen, sollten Sie Kapitel 22 NNTP und der NNTPD-Dämon, lesen. Dort wird geschildert, wie man den nntpd-Dämon konfiguriert und ihn mit C News betreibt. Ein anderes NNTP-Paket ist INN oder auch Internet News. Es ist nicht einfach nur ein Frontend, sondern ein vollständiges News-System. Es besitzt einen leistungsfähigen News-Verteilerdämon, der effektiv mehrere NNTP-Links gleichzeitig verwalten kann, und ist daher der News-Server auf vielen Internetsystemen. Im Detail gehen wir darauf in Kapitel 23 Internet News, ein.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Und was ist nun das Usenet? Einer der erstaunlichsten Fakten über Usenet ist, daß es kein Teil irgendeiner Organisation ist und daß es auch keinerlei zentrale Autorität für das Netzwerkmanagement besitzt. In der Tat ist es ein Teil einer Usenet-Überlieferung, für die Sie — von einer technischen Beschreibung mal abgesehen — einfach nicht genau sagen können, was sie eigentlich ist. Auch auf die Gefahr hin, daß sich das dumm anhört, kann man das Usenet als einen Zusammenschluß separater Systeme betrachten, die untereinander Usenet-News austauschen. Um Ihr eigenes System in das Usenet einzubinden, müssen Sie nur ein anderes Usenet-System finden und mit deren Besitzern und Verwaltern eine Vereinbarung darüber treffen, daß mit Ihnen News ausgetauscht werden. Das Weitergeben von News an ein anderes System wird auch als Feeding bezeichnet, woher ein weiteres allgemeines Axiom der UsenetPhilosophie stammt: “Holen Sie sich einen Feed, und Sie sind dabei!” Die grundlegende Einheit der Usenet-News ist der Artikel. Dabei handelt es sich um eine Nachricht, die von einem Benutzer geschrieben und ins Netz eingespeist (“gepostet”) wurde. Damit das NewsSystem in der Lage ist, mit Artikeln umzugehen, werden diesen administrative Informationen, die sogenannten Artikel-Header, vorangestellt. Ein solcher Header erinnert stark an das Mail-HeaderFormat, das im Internet-Mail-Standard RFC-822 beschrieben ist. Er besteht aus verschiedenen Textzeilen, die mit einem durch einen Doppelpunkt abgeschlossenen Feldnamen beginnen, dem dann der Wert des Feldes folgt.1

Artikel werden in eine oder mehrere Newsgruppen übertragen. Sie können sich Newsgruppen als ein Forum für Artikel zu einem bestimmten Thema vorstellen. Alle Newsgruppen sind in einer Hierarchie angeordnet, wobei der Gruppenname den Platz in der Hierarchie widerspiegelt. Das macht es häufig einfach zu erkennen, um was es in einer Gruppe eigentlich geht. Beispielsweise kann jeder aus dem Namen dieser Newsgruppe erkennen, daß comp.os.linux.announce für Ankündigungen zu einem Computerbetriebssystem namens Linux genutzt wird. Diese Artikel werden dann zwischen allen Usenet-Systemen ausgetauscht, die willens sind, News aus dieser Gruppe weiterzuleiten. Sind zwei Systeme übereingekommen, miteinander News auszutauschen, können sie jede gewünschte Newsgruppe transportieren. Es können sogar eigene lokale News-Hierarchien eingeführt werden. Beispielsweise könnte groucho.edu einen News-Link zu barnyard.edu besitzen, der einer der Haupt-News-Verteiler ist, sowie verschiedene Links zu kleineren Systemen, die es mit News versorgt. Nun könnte das Barnyard College alle Usenet-Gruppen empfangen wollen, während die GMU nur einige der Haupthierarchien wie sci, comp, rec usw. nutzen möchte. Einige dahinterliegende Systeme, z.B. ein UUCP-System namens brewhq, könnten noch weniger Gruppen wollen, weil die Netzwerk- oder Hardwareressourcen nicht ausreichen. Andererseits könnte brewhq Newsgruppen aus der fj-Hierarchie empfangen wollen, die von der GMU nicht empfangen werden. brewhq besitzt daher einen weiteren Link zu gargleblaster.com, die alle fjGruppen empfängt und diese an brewhq weitergibt. Der Datenfluß der News ist in Abbildung 20.1 zu sehen. Die Bezeichnungen neben den von brewhq ausgehenden Pfeilen bedürfen vielleicht der Erklärung. Standardmäßig sollen alle lokal erzeugten News an groucho.edu geschickt werden. Weil groucho.edu aber die fj-Gruppen nicht transportiert, macht es keinen Sinn, ihm Nachrichten dieser Gruppe zu schicken. Daher wird der Feed von brewhq zur GMU mit dem Text all,!fj versehen, was verdeutlichen soll, daß alle Gruppen außer denen unterhalb von fj dorthin gesendet werden. Abbildung 20.1: Datenfluß von Usenet-News durch die Groucho-Marx-Universität

1.

Das Format von Usenet-News-Nachrichten ist in RFC-1036, “Standard for interchange of USENET messages”, angegeben.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie behandelt Usenet die News? Heutzutage hat das Usenet enorme Proportionen angenommen. Systeme, die die gesamten Netnews vorhalten, transportieren täglich weit über 60 Megabyte. Natürlich geht es hier um weit mehr als um das reine Umherschieben von Dateien. Sehen wir uns also an, wie die meisten UNIX-Systeme UsenetNews behandeln. News beginnen dort, wo Benutzer Artikel erzeugen und posten. Jeder Benutzer gibt eine Nachricht in eine spezielle Applikation ein, die als Newsreader bezeichnet wird und die sie für die Übertragung zum lokalen News-Server angemessen aufbereitet. In Unix-Umgebungen benutzt der Newsreader häufig den Befehl inews, um Artikel über TCP/IP zum News-Server zu übertragen. Es ist aber auch möglich, den Artikel direkt in eine Datei in einem speziellen Verzeichnis zu schreiben, das als News Spool bezeichnet wird. Ist der Artikel einmal beim lokalen News-Server gelandet, übernimmt dieser die Verantwortung für die Zustellung des Artikels zu anderen News-Anwendern. News werden im Netz über verschiedene Wege transportiert. Das historische Medium war UUCP, aber heutzutage wird der Hauptdatenverkehr über Internetsysteme abgewickelt. Das zum Routen verwendete Verfahren wird als Flooding-Algorithmus bezeichnet: Jedes System verwaltet eine Anzahl von Links (News-Feeds) zu anderen Systemen. Jeder vom lokalen System generierte oder empfangene Artikel wird an diese Links weitergeleitet. Wurde er bereits ausgeliefert, wird er ausrangiert. Ein System kann sich ansehen, welche Systeme der Artikel bereits passiert hat, indem es das Header-Feld

Path: untersucht. Dieser Header enthält eine Liste aller Systeme, die den Artikel weitergeleitet haben, in Bang-Path-Notation. Um Artikel unterscheiden und Duplikate erkennen zu können, enthalten Usenet-Artikel eine sogenannte Message-ID (spezifiziert im Header-Feld Message-Id:). Diese kombiniert den Namen des Systems, auf dem der Artikel gepostet wurde, und eine Seriennummer in einer Zeichenkette des Formats <seriennummer@system>. Für jeden verarbeiteten Artikel speichert das News-System diese ID in einer history-Datei, gegen die alle neu eingegangenen Artikel geprüft werden. Der Fluß zwischen diesen beiden Systemen kann über zwei Kriterien eingeschränkt werden. Zum einen kann einem Artikel eine bestimmte “Distribution” (im Header-Feld Distribution:) zugewiesen werden, die verwendet werden kann, um ihn auf eine bestimmte Gruppe von Systemen zu beschränken. Auf der anderen Seite kann die Anzahl der ausgetauschten Newsgruppen durch das sendende, aber auch durch das empfangende System eingeschränkt werden. Die Menge der Newsgruppen und Distributionen, die an ein bestimmtes System übertragen werden dürfen, ist üblicherweise in der Datei sys definiert. Alleine die Anzahl der Artikel macht es üblicherweise notwendig, das obige Schema zu verbessern. Bei UUCP-Netzwerken ist es durchaus üblich, Artikel über eine gewisse Zeit zu sammeln und in einer einzelnen Datei zu speichern, die komprimiert und dann an das andere System übertragen wird. Diese Technik wird Stapelverarbeitung oder auch Batching genannt. Eine alternative Technik ist das ihave/sendme-Protokoll, das verhindert, daß Artikel doppelt übertragen werden, und auf diese Weise Bandbreite spart. Anstatt alle Artikel in einer Batch-Datei zu speichern und zu versenden, werden nur die Message-IDs der Artikel zu einer großen “ihave”Nachricht zusammengefaßt und an das andere System übertragen. Das andere System liest diese Nachricht und vergleicht sie mit der eigenen History-Datei. Daraufhin wird in einer “sendme”Nachricht eine Liste der gewünschten Artikel zurückgeliefert. Nur diese Artikel werden dann übertragen. Diese Technik macht natürlich nur Sinn, wenn zwei große Systeme Daten austauschen, die News jeweils über mehrere unabhängige Quellen beziehen und sich oft genug-gegenseitig abfragen, so daß ein effizienter Fluß von News möglich ist. Auf Internetsystemen wird in der Regel TCP/IP-basierte Software eingesetzt, die das Network News Transfer Protocol (NNTP) verwendet. NNTP ist in RFC-977 beschrieben und verantwortlich für die Übertragung von News zwischen News-Servern und bietet Usenet-Zugriff für einzelne Benutzer auf anderen Hosts. NNTP kennt drei verschiedene Arten der News-Übertragung. Die erste ist eine Echtzeit-Version von ihave/sendme, die als “rüberschieben” (pushing) von News bezeichnet wird. Die zweite Technik ist das “Rüberziehen” (pulling) von News. Dabei fordert der Client eine Liste von Artikeln einer bestimmten Newsgruppe oder -Hierarchie an, die bis zu einem bestimmten Zeitpunkt auf der Serverseite angekommen sind, und wählt dann die aus, die in der History-Datei nicht gefunden werden. Bei der dritten Methode handelt es sich um interaktives Lesen von News. Dabei kann Ihr

Newsreader Artikel aus angegebenen Newsgruppen empfangen und gleichzeitig Artikel mit unvollständigen Header-Informationen posten. Auf jedem System werden News in einer Verzeichnis-Hierarchie unter /var/spool/news gehalten. Jeder Artikel steht in einer separaten Datei und jede Newsgruppe in einem separaten Verzeichnis. Der Verzeichnisname besteht aus dem Namen der Newsgruppe, wobei deren Komponenten die Komponenten des Pfads bilden. Die Artikel der Newsgruppe comp.os.linux.misc befinden sich also im Verzeichnis /var/spool/news/comp/os/linux/misc. Den Artikeln einer Newsgruppe werden Zahlen in der Reihenfolge ihres Eintreffens zugewiesen. Diese Zahlen dienen als Dateinamen. Der Wertebereich von Artikeln, die gerade online sind, wird in einer Datei namens active gespeichert. Die Datei enthält außerdem eine Liste der Newsgruppen, die Ihrem System bekannt sind. Weil Festplattenplatz nur eine endliche Ressource ist, muß man nach einer gewissen Zeit anfangen, alte Artikel auszusortieren.1 Das wird als Expiring, also “Löschen”, bezeichnet. Üblicherweise werden Artikel aus bestimmten Gruppen und Hierarchien nach einer festen Zeit (in Tagen) für ungültig erklärt und gelöscht. Diese Zeit kann durch den Verfasser durch Angabe eines Ungültigkeitsdatums im Feld Expires: des Artikel-Headers überschrieben werden. Nun haben Sie genug Informationen gesammelt, um zu entscheiden, was Sie als nächstes lesen. UUCP-Nutzer sollten sich die C News in Kapitel 21 C News, vornehmen. Wenn Sie ein TCP/IPNetzwerk benutzen, schauen Sie sich das Kapitel über NNTP in Kapitel 22 NNTP und der NNTPDDämon, an; falls Sie nur moderate Mengen an News per TCP/IP übertragen, könnte der in diesem Kapitel beschriebene Server ausreichen. Wenn Sie dagegen einen Hochleistungs-News-Server installieren wollen, der gigantische Mengen an Datenmaterial übertragen kann, lesen Sie das Kapitel über InterNet News in Kapitel 23 Internet News.

1.

Manche Leute behaupten, das Usenet sei eine Verschwörung von Modem- und Festplattenherstellern. ;-)

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 21 C News

Eines der bekanntesten Softwarepakete für Netnews ist C News. Es wurde für Systeme entwickelt, die News über UUCP-Verbindungen übertragen. Dieses Kapitel behandelt die zentralen Konzepte von C News und bespricht die grundlegenden Installations- und Verwaltungsaufgaben.

C News legt seine Konfigurationsdateien in /etc/news und die meisten seiner Binärdateien unterhalb des Verzeichnisses /usr/lib/news/ ab. Artikel werden unter /var/spool/news aufbewahrt. Sie sollten sicherstellen, daß praktisch alle Dateien in diesen Verzeichnissen den Benutzer news oder die gleichnamige Gruppe als Eigentümer haben. Die meisten Probleme entstehen durch Dateien, auf die C News nicht zugreifen kann. Melden Sie sich daher immer erst mit su als news an, bevor Sie irgendwelche Änderungen in den Verzeichnissen vornehmen. Die einzige Ausnahme bildet der Befehl setnewsids, mit dem einige News-Programme ihre echte Benutzer-ID einstellen. Dieses Programm muß root als Eigentümer und das Setuid-Bit gesetzt haben. In diesem Kapitel beschreiben wir ausführlich die Konfigurationsdateien von C News und zeigen Ihnen, was Sie tun müssen, um Ihr System am Laufen zu halten.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

News ausliefern Artikel können auf verschiedene Arten an C News übergeben werden. Postet ein lokaler Benutzer einen Artikel, übergibt der Newsreader ihn üblicherweise an den Befehl inews, der die HeaderInformationen dann vervollständigt. News von anderen Systemen — gleichgültig, ob ein einziger Artikel oder ein ganzer Stapel (Batch) — werden an den Befehl rnews übergeben, der sie im Verzeichnis /var/spool/news/in.coming ablegt. Von dort werden sie zu einem späteren Zeitpunkt von newsrun übernommen. Bei beiden Techniken landet der Artikel aber schließlich beim Befehl relaynews. Bei jedem Artikel überprüft der relaynews-Befehl zuerst, ob der Artikel bereits auf dem lokalen System besehen wurde, indem er die Message-ID in der Datei history nachschaut. Doppelte Artikel werden aussortiert. Danach sieht sich relaynews die Header-Zeile Newsgroups: an, um herauszufinden, ob das lokale System Artikel aus einer dieser Gruppen angefordert hat. Wenn ja, und wenn die Newsgruppe in der Datei active aufgeführt ist, versucht relaynews den Artikel im entsprechenden Verzeichnis des News-Spool-Bereichs zu speichern. Wenn das Verzeichnis nicht existiert, wird es angelegt. Die Message-ID des Artikels wird dann in die history-Datei aufgenommen. Andernfalls sortiert relaynews den Artikel aus. Ist relaynews nicht in der Lage, einen eingehenden Artikel zu speichern, weil dieser in eine Gruppe gepostet wurde, die nicht in Ihrer active-Datei aufgeführt ist, wird der Artikel in der Gruppe junk

untergebracht.1 relaynews prüft auch, ob die Artikel veraltet sind bzw. ob ein fehlerhaftes Datum vorliegt, und sortiert sie entsprechend aus. Ankommende Batches, die aus irgendeinem anderen Grund nicht bearbeitet werden können, werden nach /var/spool/news/in.coming/bad verschoben, und eine entsprechende Fehlermeldung wird in die Logdatei geschrieben. Danach werden die Artikel an alle anderen Systeme verteilt, die News aus diesen Gruppen anfordern. Dabei wird das für jedes System spezifizierte Transportverfahren benutzt. Um sicherzustellen, daß die Artikel nicht an ein System übertragen werden, das sie bereits gesehen hat, wird jedes Zielsystem mit dem Header-Feld Path: des Artikels verglichen. Dieses enthält eine Liste der Systeme in der UUCPtypischen Bang-Path-Notation (beschrieben in Kapitel 17 Elektronische Post), die der Artikel bislang passiert hat. Nur wenn der Name des Zielsystems nicht in dieser Liste erscheint, wird der Artikel dorthin gesendet. C News wird üblicherweise verwendet, um News zwischen UUCP-Systemen zu verteilen, obwohl es auch möglich ist, es in einer NNTP-Umgebung einzusetzen. Um News an ein anderes System auszuliefern — gleichgültig, ob es sich dabei um einzelne Artikel oder komplette Batches handelt —, wird uux verwendet, das rnews auf dem anderen Rechner ausführt, wobei die Artikel oder der Batch über die Standardeingabe eingespeist werden. Für weitere Informationen über UUCP sei auf Kapitel 16 Taylor UUCP verwalten, verwiesen. Der Begriff Batch-Betrieb beschreibt einen besonderen Betriebsmodus, bei dem große Bündel individueller Artikel auf einmal übertragen werden. Ist der Batch-Betrieb für ein bestimmtes System aktiviert, überträgt C News die eingehenden Artikel nicht direkt, sondern hängt den Pfadnamen an eine Datei (üblicherweise out.going/site/togo) an. Über die crontab wird regelmäßig ein BatchProgramm gestartet, das die Datei ausliest und alle aufgeführten Artikel in einer oder mehreren Dateien unterbringt, diese optional komprimiert und sie dann an rnews auf dem anderen System überträgt. 2 Abbildung 21.1 zeigt den Fluß von News durch relaynews. Artikel können an das lokale System (bezeichnet durch ME), über E-Mail zu einem System namens ponderosa und zu einem System namens moria übertragen werden, für das der Batch-Betrieb aktiviert ist. Abbildung 21.1: Fluß von News durch relaynews

1.

Es kann einen Unterschied geben zwischen den Gruppen, die auf Ihrem System vorhanden sind, und den Gruppen, die Ihr System zu empfangen bereit ist. Beispielsweise könnte die AbonnementListe comp.all enthalten, was alle Newsgruppen unter der comp-Hierarchie einschließt. Auf Ihrem System sind aber eine Reihe der comp-Gruppen nicht in Ihrer active-Datei eingetragen. In diese Gruppen gepostete Artikel werden in junk abgelegt.

2.

Beachten Sie, daß dies die crontab von news sein sollte, damit die Dateizugriffsrechte nicht beschädigt werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Installation C News sollte für jede moderne Linux-Distribution in vorgefertigter Form verfügbar sein, so daß die Installation leicht fällt. Wenn das nicht der Fall ist oder Sie lieber die Source-Distribution installieren möchten, können Sie das natürlich tun.1 Wie Sie es auch installieren, Sie müssen auf jeden Fall die Konfigurationsdateien von C News editieren. Ihre Formate werden in der folgenden Liste beschrieben: sys Die sys-Datei kontrolliert, welche Newsgruppen Ihr System empfängt und weiterleitet. Das erläutern wir ausführlich in den folgenden Abschnitten. active Wird für gewöhnlich nicht von der Administration editiert; enthält Anweisungen zur Behandlung der Artikel in allen vom System behandelten Newsgruppen. organization Der Name Ihrer Organisation, beispielsweise “Virtuelle Brauerei GmbH”. Auf Ihrem Rechner zu Hause sollten Sie “privates System” oder etwas Ähnliches angeben. Für die meisten Leute ist Ihr Rechner nicht richtig konfiguriert, solange diese Datei nicht angepaßt wurde. newsgroups Eine Liste mit allen Newsgruppen sowie einer einzeiligen Beschreibung der jeweiligen Funktion. Die Beschreibungen werden häufig von Ihrem Newsreader verwendet, wenn eine Liste aller von Ihnen abonnierten Gruppen ausgegeben wird. mailname

Der Mail-Name Ihres Systems, z.B. vbrew.com. whoami Der Name Ihres Systems für News-Zwecke. Häufig wird der UUCP-Systemname, z.B. vbrew, verwendet. explist Diese Datei sollte die von Ihnen gewünschten Zeiten enthalten, nach denen Artikel bestimmter Newsgruppen ungültig werden. Festplattenplatz spielt hier wahrscheinlich eine entscheidende Rolle. Um eine erste Hierarchie von Newsgruppen zu erzeugen, besorgen Sie sich die active- und newsgroups-Datei von dem System, das Sie mit News versorgt, und installieren Sie diese in /etc/news. Sorgen Sie dafür, daß die Dateien news gehören und den Modus 644 haben. Letzteres können Sie mit dem chmod-Befehl einstellen. Entfernen Sie alle to.*Gruppen aus der active-Datei, und fügen Sie to.my-site und to.feed-site ein. Auch junk und control müssen enthalten sein. Die Gruppen to.* werden normalerweise verwendet, um ihave/sendme-Nachrichten auszutauschen, Sie sollten sie aber auf jeden Fall einrichten, gleichgültig, ob Sie ihave/sendme verwenden wollen oder nicht. Ersetzen Sie nun mit den folgenden Befehlen alle Artikelnummern im zweiten und dritten Feld von active: # cp active active.old # sed ’s/ [0-9]* [0-9]* / 0000000000 00001 /’ active.old > active # rm active.old

Der zweite Befehl startet sed, einen Stream-Editor. Der Aufruf ersetzt zwei Strings aus Ziffern durch einen String aus Nullen bzw. den String 000001. Zum Schluß müssen Sie das News-Spool-Verzeichnis und die für die ein- und ausgehenden News benötigten Unterverzeichnisse erzeugen: # cd /var/spool # mkdir news news/in.coming news/out.going news/out.master # chown -R news.news news # chmod -R 755 news

Wenn Sie vorkompilierte Newsreader verwenden, die aus einer anderen Distribution stammen als von dem C NewsServer, den Sie benutzen, ist es möglich, daß einige den News-Spool in /usr/spool/news und nicht in /var/spool/news erwarten. Falls Ihr Newsreader also keine Artikel finden kann, erzeugen Sie einen symbolischen Link von /usr/spool/news auf /var/spool/news: # ln -sf /usr/spool/news /var/spool/news

Nun sind Sie in der Lage, News zu empfangen. Sie müssen übrigens die Spool-Verzeichnisse der individuellen Newsgruppen nicht selbst anlegen. Falls noch kein solches Verzeichnis existiert, erzeugt C News automatisch eines für jede Newsgruppe, für die es einen Artikel empfängt. Tatsächlich passiert das mit allen Gruppen, in die ein Artikel gepostet wurde. Nach einer Weile werden Sie sehen, daß Ihr News-Spool-Verzeichnis mit Verzeichnissen für Gruppen wie beispielsweise alt.lang.teco vollgepflastert ist, die Sie nie abonniert haben. Sie können dies verhindern, indem Sie alle ungewollten Gruppen aus active entfernen oder regelmäßig ein Shell-Skript starten, das alle leeren Verzeichnisse unter /var/spool/news löscht (natürlich mit Ausnahme von out.going und in.coming). Für C News muß ein Benutzer existieren, an den Fehlermeldungen und Statusberichte geschickt werden können. Standardmäßig ist dies der Benutzer usenet. Wenn Sie diese Voreinstellung beibehalten, müssen Sie einen oder mehrere Aliase einrichten, damit alle Nachrichten an die entsprechende(n) Person(en) weitergeleitet werden. Sie können aber auch alle Mails an einen anderen Benutzer schicken, indem Sie die Umgebungsvariable NEWSMASTER auf den entsprechenden Namen setzen. Dies müssen Sie in der news-crontab tun und jedesmal, wenn Sie ein AdministrationsTool von Hand aufrufen. Das Einrichten eines Alias ist also wahrscheinlich einfacher. Mail-Aliase werden in Kapitel 18

Sendmail, und Kapitel 19 Inbetriebnahme von Exim, beschrieben. Wenn Sie die Datei /etc/passwd editieren, sollten Sie sicherstellen, daß für alle Benutzer der echte Name im Feld pw_gecos der Paßwortdatei eingetragen ist (dies ist das vierte Feld). Es ist eine Frage der Usenet-Netiquette, daß der echte Name des Absenders im From:-Feld des Artikels erscheint. Wenn Sie einen Mailer eingerichtet haben, haben Sie das wahrscheinlich sowieso schon getan.

1.

Die Source-Distribution von C News erhalten Sie unter ftp.cs.toronto.edu in der Datei /pub/c-news/ c-news.tar.Z

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Datei sys Die Datei sys ist in /etc/news beheimatet und kontrolliert, welche Hierarchien Sie empfangen und an andere Systeme weiterleiten. Obwohl es Verwaltungswerkzeuge wie addfeed und delfeed gibt, sind wir doch der Meinung, daß es besser ist, diese Datei von Hand zu verwalten. Die sys-Datei enthält Einträge für jedes System, an das Sie News weiterleiten, sowie eine Beschreibung der Gruppen, die Sie akzeptieren. Die erste Zeile ist ein ME-Eintrag und beschreibt Ihr System. Mit folgendem Eintrag gehen Sie kein Risiko ein: ME:all/all::

Außerdem müssen Sie für jedes System, das Sie mit News versorgen wollen, eine Zeile hinzufügen, die etwa so aussieht: site[/ausschlüsse]:gruppenliste[/distliste][:optionen[:befehle]]

Einträge können durch einen Backslash (\) am Zeilenende über mehrere Zeilen fortgesetzt werden. Ein Doppelkreuz (#) leitet einen Kommentar ein. site Der Name des Systems, auf das der Eintrag zutrifft. Normalerweise wird der UUCP-Name des Systems gewählt. Es muß auch ein Eintrag für Ihr System in sys stehen, weil Sie sonst selbst keine Artikel empfangen können. Der spezielle Systemname ME steht für Ihr System. Der ME-Eintrag definiert alle Gruppen, die Sie lokal speichern wollen. Artikel, die über die ME-Zeile nicht zugeordnet werden können, wandern in die junk-Gruppe. Um Schleifen zu vermeiden, lehnt C News alle Artikel ab, die dieses System bereits passiert haben. Es stellt dazu sicher, daß der Name des lokalen Systems nicht im Path: des Artikels erscheint. Einige Systeme können über mehrere gültige Namen bekannt sein. Manche Systeme benutzen beispielsweise ihren voll qualifizierten Domainnamen in diesem Feld oder einen Alias wie news.site.domain. Damit der Mechanismus zur Verhinderung von Schleifen funktioniert, ist es wichtig, alle Aliase (durch Kommata getrennt) in die Ausschlußliste einzutragen. Beim Eintrag für das System moria zum Beispiel würde der Inhalt des site-Feldes moria/moria.orcnet.org lauten.

Falls moria auch über den Alias news.orcnet. org erreichbarwäre, würde unser site-Feld moria/moria.orcnet.org,news. orcnet.org enthalten. gruppenliste Eine durch Kommata unterteilte Abonnement-Liste aller Gruppen und Hierarchien für dieses bestimmte System. Eine Hierarchie wird durch Angabe des Hierarchie-Präfixes spezifiziert (beispielsweise comp.os für alle Gruppen, die mit diesem Präfix beginnen), dem optional das Schlüsselwort all folgen kann (z.B. comp.os.all ). Hierarchien oder Gruppen können von der Weiterleitung ausgeschlossen werden, indem ihnen ein Ausrufezeichen vorangestellt wird. Wird eine Newsgruppe mit dieser Liste verglichen, wird immer die größte Übereinstimmung verwendet. Wenn beispielsweise gruppenliste die folgende Liste !comp,comp.os.linux,comp.folklore.computers

enthielte, würden keine Gruppen der comp-Hierarchie außer comp.folklore.computers und alle Gruppen unter comp.os.linux an dieses System weitergegeben. Wenn das System alle News weitergeleitet haben möchte, die auch Sie selbst empfangen, geben Sie einfach all als gruppenliste an. distliste Dieser Wert ist von der gruppenliste durch einen Schrägstrich abgetrennt und enthält eine Liste von weiterzuleitenden Distributionen. Auch hier können Sie wieder verschiedene Distributionen durch Voranstellen eines Ausrufezeichens unterbinden. Mit dem Schlüsselwort all sind alle Distributionen gemeint. Wird keine distliste angegeben, wird automatisch all angenommen. Beispielsweise könnten Sie die Distributionsliste all,!local benutzen, um zu verhindern, daß News, die nur zur lokalen Verwendung bestimmt sind, an andere Systeme übertragen werden. Es gibt normalerweise wenigstens zwei Distributionen: world, der Standardverteiler, wenn keiner vom Benutzer angegeben wurde, und local. Es kann weitere Distributionen geben, die für eine bestimmte Region, Land, Staat usw. gelten. Schließlich gibt es noch zwei Distributionen, die nur von C News verwendet werden, und zwar sendme und ihave; sie finden Anwendung für das sendme/ihave-Protokoll. Die Verwendung von Distributionen ist Thema zahlreicher Debatten. Das Distributions-Feld in einem News-Artikel kann nach Belieben erzeugt werden. Damit eine Distribution aber effektiv ist, müssen die News-Server im Netzwerk über sie informiert werden. Manche Newsreader, die aus der Rolle fallen, erzeugen wirre Distributionen, indem sie die Top-Level-Hierarchie der Zieladresse des Artikels für eine angemessene Distribution halten. Newsreader könnten beispielsweise comp für eine solche Distribution halten, wenn sie in die Newsgruppe comp.os.linux.networking posten. Auch Distributionen für bestimmte Regionen sind häufig fragwürdig, weil News auch außerhalb Ihrer Region wandern können, wenn sie über das Internet geschickt werden.1 Distributionen, die sich dagegen an eine Organisation wenden, sind durchaus sinnvoll; so gilt es beispielsweise zu verhindern, daß vertrauliche Informationen ein Unternehmensnetzwerk verlassen. Dieses Ziel wird allerdings besser erreicht, indem eine separate Newsgruppe oder Hierarchie angelegt wird. optionen Hiermit beschreiben Sie verschiedene Parameter für den Feed. Dieses Feld kann leer sein oder eine Kombination der folgenden Schlüsselwörter enthalten: F Diese Option aktiviert den Batch-Betrieb.

f Diese Option ist nahezu identisch mit F, erlaubt es C News aber, die Größe der ausgehenden Batches präziser zu berechnen, und sollte vielleicht vorzugsweise benutzt werden. I Mit dieser Option erzeugt C News eine Artikelliste, die von ihave/sendme verwendet werden kann. Weitere Modifikationen werden in den Dateien sys und batchparms benötigt, um ihave/sendme zu aktivieren. n Dies erzeugt Batch-Dateien für die aktive NNTP-Übertragung wie z.B. mit nntpxmit (siehe Kapitel 22 NNTP und der NNTPD-Dämon). Die Batch-Dateien enthalten den Dateinamen des Artikels zusammen mit der Message-ID. L Damit weisen Sie C News an, nur Dateien zu übertragen, die auf Ihr System gepostet wurden. Dieser Option kann eine Dezimalzahl n folgen, die dafür sorgt, daß C News Artikel nur dann überträgt, wenn diese innerhalb von n Hops von Ihrem System entfernt gepostet wurden. C News ermittelt die Anzahl der Hops aus dem Path:Feld. u Weist C News an, Batches nur von Artikeln aus nicht moderierten Gruppen zu erstellen. m Weist C News an, Batches nur von Artikeln aus moderierten Gruppen zu erstellen. Sie dürfen maximal eine der Optionen F, f, I oder n benutzen. befehle Dieses Feld enthält einen Befehl, der bei jedem Artikel ausgeführt wird, solange der Batch-Betrieb nicht aktiviert ist. Der Artikel wird über die Standardeingabe übergeben. Diese Möglichkeit sollte nur bei sehr kleinen Feeds verwendet werden, weil sonst die Last auf beiden Systemen zu hoch wird. Der Standardbefehl lautet: uux - -r -z remote-system!rnews

Damit wird rnews auf dem entfernten System gestartet und der Artikel über die Standardeingabe übergeben. Der Standard-Suchpfad für die in diesem Feld angegebenen Befehle ist /bin:/usr/bin:/usr/lib/news/batch. Das letzte Verzeichnis enthält eine Reihe von Shell-Skripten, deren Namen mit via beginnen. Diese werden später in diesem Kapitel noch kurz besprochen. Ist der Batch-Betrieb über eine der Optionen F, f, I oder n aktiviert worden, erwartet C News in diesem Feld einen Dateinamen anstelle eines Befehls. Beginnt der Dateiname nicht mit einem Schrägstrich (/), wird angenommen, daß er relativ zu /var/spool/news/out.going ist. Ist das Feld leer, wird standardmäßig auf remote-system/togo zurückgegriffen. Die Datei muß dasselbe Format haben wie remote-system/togo und enthält eine Liste zu übertragender Artikel. Wenn Sie C News einrichten, müssen Sie höchstwahrscheinlich Ihre eigene sys-Datei schreiben. Es folgt eine Beispieldatei für

vbrew.com, von der Sie übernehmen können, was Sie benötigen: # Wir nehmen alles, was man uns gibt. ME:all/all:: # Wir senden alles, was wir empfangen, an moria, außer lokalen und # Brauerei-internen Artikeln. Wir arbeiten im Batch-Betrieb. moria/moria.orcnet.org:all,!to,to.moria/all,!local,!brewery:f: # Wir übertragen comp.risks über Mail an [email protected]. ponderosa:comp.risks/all::rmail [email protected] # swim bekommt einen kleinen Feed. swim/swim.twobirds.com:comp.os.linux,rec.humor.oracle/all,!local:f: # Mail-MapArtikel werden für spätere Bearbeitung gespeichert. usenetmaps:comp.mail.maps/all:F:/var/spool/uumaps/work/batch

1.

Es ist nicht unüblich, daß ein in, sagen wir mal, Hamburg geposteter Artikel seinen Weg nach Frankfurt über reston.ans.net in den Niederlanden oder sogar über ein System in den USA nimmt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Datei active Die Datei active ist unter /etc zu finden und enthält eine Liste aller Ihrem System bekannten Gruppen sowie aller Artikel, die momentan online sind. Sie werden diese Datei nur selten bearbeiten müssen, aber wir erklären sie an dieser Stelle der Vollständigkeit halber. Einträge haben die folgende Form: newsgruppe Obergrenze Untergrenze rechte

newsgruppe ist der Gruppenname. Untergrenze und Obergrenze stehen für die niedrigste bzw. höchste Anzahl von Artikeln, die gerade verfügbar sind. Sind gerade keine Artikel vorhanden, ist Untergrenze gleich Obergrenze +1. Zumindest ist das für Untergrenze so vorgesehen. Allerdings wird dieses Feld aus Effizienzgründen von C News nicht aktualisiert. Das wärenicht weiter schlimm, wenn nicht einige Newsreader von diesem Wert abhängig wären. Beispielsweise überprüft trn dieses Feld, um zu sehen, ob es irgendwelche Artikel aus der Thread-Datenbank löschen kann. Um das Untergrenze-Feld zu aktualisieren, müssen Sie daher regelmäßig den Befehl updatemin (bei älteren Versionen von C News das upact-Skript) ausführen. rechte ist ein Parameter, der detailliert beschreibt, welche Zugriffsrechte Benutzern bei dieser Gruppe zustehen. Er hat einen der folgenden Werte:

y Benutzer dürfen in diese Gruppe posten. n Benutzer dürfen nicht in diese Gruppe posten. Die Artikel dieser Gruppe dürfen aber trotzdem gelesen werden. x Diese Gruppe ist lokal deaktiviert worden. Dies kommt manchmal vor, wenn NewsAdministratoren (oder deren Vorgesetzte) weltanschauliche Vorbehalte gegen bestimmte Gruppen haben. Artikel, die für diese Gruppe empfangen werden, werden nicht lokal gespeichert, sondern nur an die Systeme weitergegeben, die sie angefordert haben. m Bezeichnet eine moderierte Gruppe. Versucht ein Benutzer, eine Nachricht in diese Gruppe zu posten, wird ein intelligenter Newsreader ihm einen Hinweis geben und den Artikel statt dessen an den Moderator schicken. Die Adresse des Moderators wird aus der Datei moderators in /usr/lib/news gelesen. =reale-gruppe Kennzeichnet newsgruppe als lokalen Alias für die Gruppe reale-gruppe. Alle Artikel, die in newsgruppe gepostet werden, werden in diese Gruppe umgeleitet. Bei C News müssen Sie auf diese Datei in der Regel nicht direkt zugreifen. Gruppen können über die Befehle addgroup bzw. delgroup lokal erzeugt bzw. gelöscht werden (siehe den nachfolgenden Abschnitt Verwaltungsaufgaben und -Tools). Die Control-Message newgroup erzeugt eine Gruppe im gesamten Usenet, während die Control-Message rmgroup eine Gruppe löscht. Senden Sie eine solche Nachricht niemals selbst! Anweisungen zum Anlegen einer neuen Newsgruppe finden Sie in den monatlichen Postings in news.announce.newusers. Eine eng mit active verwandte Datei ist active.times. Jedesmal wenn eine Gruppe angelegt wird, speichert C News eine Notiz in dieser Datei, die den Namen der erzeugten Gruppe und das Datum der Erzeugung enthält, ob dies über eine newgroup-Control-Message oder lokal erfolgte und wer sie erzeugte. Diese Informationen können dann von Newsreadern verwendet werden, die die Benutzer über neu erzeugte Gruppen informieren wollen. Außerdem wird diese Datei vom NNTP-Befehl NEWGROUPS verwendet.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Stapelverarbeitung von Artikeln (Batching) News-Batches verwenden ein bestimmtes Format, das für B News, C News und INN identisch ist. Jedem Artikel wird eine Zeile wie die folgende vorangestellt: #! rnews anzahl

anzahl bezeichnet die Anzahl Bytes in diesem Artikel. Bei Batch-Komprimierung wird die Datei als Ganzes komprimiert und eine weitere Zeile vorangestellt, die angibt, welches Programm zum Entpacken verwendet werden soll. Das StandardKomprimierungs-Tool ist compress, was durch folgende Zeile gekennzeichnet wird: #! cunbatch

Manchmal, wenn Batches über E-Mail-Software übertragen werden, die das achte Bit von allen Daten entfernt, wird ein komprimierter Batch durch die sogenannte c7-Codierung geschützt. Diese Batches sind durch c7unbatch markiert. Wird ein Batch an rnews auf einem anderen System übergeben, werden diese Markierungen geprüft, und der Stapel wird entsprechend korrekt verarbeitet. Manche Systeme verwenden auch andere Kompressions-Tools wie gzip und stellen den so komprimierten Daten zunbatch voran. C News kann mit solchen Headern nicht umgehen, da diese dem Standard nicht entsprechen. Sie müssen die Quelltexte entsprechend modifizieren, um sie zu unterstützen. Bei C News wird der Batch-Betrieb über /usr/lib/news/batch/sendbatches abgewickelt. Dabei wird eine Liste von Artikeln aus der Datei site/togo gelesen, aus denen dann mehrere News-Batches erzeugt werden. Der Befehl sollte einmal in der Stunde oder sogar noch häufiger ausgeführt werden, wenn Sie ein hohes Datenaufkommen haben. Kontrolliert wird der Batch-Betrieb über die Datei batchparms in /var/lib/news. Diese Datei beschreibt die maximal erlaubte Batch-Größe für jedes System, das zur Stapelverarbeitung und optional zur Komprimierung zu verwendende Programm sowie die zur Auslieferung zu benutzende Transportart. Sie können Batch-Parameter für jedes einzelne System einstellen, aber auch Standardwerte für Systeme vorgeben, die nicht explizit aufgeführt sind. Wenn Sie C News installieren, finden Sie höchstwahrscheinlich eine Version von batchparms in Ihrer Distribution, die einen sinnvollen Standardeintrag enthält, so daß gute Aussichten bestehen, daß Sie diese Datei gar nicht anfassen müssen. Falls Sie es doch tun müssen, beschreiben wir das Format dieser Datei. Jede Zeile besteht aus sechs Feldern, die durch Leerzeichen oder Tabulatoren voneinander getrennt sind:

site größe max batcher muncher transport

site site ist der Name des Systems, für das dieser Eintrag gilt. Die Datei togo für dieses System muß in out.going/togo im Spool-Verzeichnis zu finden sein. Der Systemname /default/ bezeichnet den Standardeintrag und steht für alle Systeme, die nicht direkt mit einem eindeutigen Eintrag spezifiziert sind. größe größe ist die maximale Größe von erzeugten Artikel-Batches (vor der Komprimierung). Bei einzelnen Artikeln, die größer als dieser Wert sind, macht C News eine Ausnahme und erzeugt einen einzelnen Batch. max max enthält die maximale Anzahl der erzeugten und zum Transfer ausgewiesenen Batches, bevor der Batch-Betrieb für dieses System vorübergehend eingestellt wird. Das ist dann sinnvoll, wenn ein anderes System für lange Zeit heruntergefahren sein sollte, weil auf diese Weise verhindert wird, daß C News Ihre UUCP-Spool-Verzeichnisse mit Abermillionen von News-Batches übersät. C News ermittelt die Anzahl wartender Batches über das queulen-Skript in /usr/lib/news/. Falls Sie C News in einer vorgefertigten Form installiert haben, sollten im Skript keinerlei Änderungen erforderlich sein. Wenn Sie jedoch mit einer anderen Art von Spool-Verzeichnissen arbeiten, beispielsweise bei Taylor UUCP, müssen Sie Ihr eigenes Skript schreiben. Wenn Sie die Anzahl der Spool-Verzeichnisse nicht interessiert (weil Sie die einzige Person sind, die diesen Computer benutzt, und weil Sie keine megabytegroßen Artikel verfassen), können Sie das Skript einfach auf den Eintrag exit 0 reduzieren. batcher Das Feld batcher enthält den Befehl, der verwendet wird, um aus der Liste von Artikeln in der togo-Datei einen Batch zu erzeugen. Bei normalen Feeds ist dies üblicherweise batcher. Für andere Zwecke können alternative Batcher verwendet werden. Beispielsweise verlangt das ihave/sendme-Protokoll, daß die Artikelliste in ihave- oder sendmeControl-Messages umgewandelt wird, die in die Newsgruppe to.site gepostet werden. Dies wird durch batchih und batchsm erledigt. muncher Das Feld muncher enthält den Befehl, der zur Komprimierung verwendet wird. Üblicherweise ist dies compcun, ein Skript, das einen komprimierten Batch erzeugt.1 Alternativ könnten Sie auch ein Skript verwenden, das gzip verwendet, beispielsweise gzipcun (um es deutlich zu sagen: Sie müssen es selbst schreiben). Sie müssen sicherstellen, daß uncompress auf dem anderen Rechner so gepatcht ist, daß es mit gzip komprimierte Dateien erkennt. Falls das andere System nicht über einen uncompress-Befehl verfügt, können Sie nocomp angeben. In diesem Fall wird keine Komprimierung durchgeführt. transport Das letzte Feld, transport, beschreibt die zu verwendende Transportart. Eine Reihe von Standardbefehlen, deren Namen mit via beginnen, steht für verschiedene Transportarten bereit. sendbatches übergibt ihnen den Namen des Zielsystems in der Kommandozeile. Falls der batchparams-Eintrag nicht /default/ lautet, leitet sendbatches den Systemnamen aus dem site-Feld ab, indem es alle Zeichen ab dem ersten Punkt oder Schrägstrich abschneidet. Beim Eintrag /default/ werden statt dessen die Verzeichnisnamen aus out.going verwendet. Um die Stapelverarbeitung für ein bestimmtes System durchzuführen, müssen Sie den folgenden Befehl verwenden:

# su news -c "/usr/lib/news/batch/sendbatches site"

Ohne Angabe von Argumenten verarbeitet sendbatches alle Batch-Queues. Wie das Wort “alle” interpretiert wird, hängt von der Präsenz eines Standardeintrags in batchparms ab. Ist einer vorhanden, werden alle Verzeichnisse in /var/spool/news/out.going geprüft. Andernfalls arbeitet es sich durch alle Einträge der batchparms hindurch und behandelt nur die dort gefundenen Sites. Beachten Sie: Sucht sendbatches das Verzeichnis out.going ab, werden nur solche Verzeichnisse als Systemnamen interpretiert, die keine Punkte oder Klammeraffen (@) enthalten. Es gibt zwei Befehle, die uux benutzen, um rnews auf dem anderen System auszuführen: viauux und viauuxz. Der letztere setzt dabei die Option –z für uux, um zu verhindern, daß die älteren Versionen von uux für jeden übertragenen Artikel eine Erfolgsmeldung zurückliefern. Ein anderer Befehl, viamail, verschickt Artikel-Batches per Mail an den Benutzer rnews des entfernten Systems. Natürlich ist es bei dieser Methode notwendig, daß das entfernte System die gesamte Post für rnews an das lokale News-System weitergibt. Eine komplette Liste der möglichen Transportarten finden Sie in der newsbatch-Manpage. Alle Befehle in den letzten drei Feldern müssen entweder in out.going/site oder in /usr/lib/news/batch zu finden sein. Bei den meisten handelt es sich um Skripten, die Sie einfach um neue Tools für Ihre persönlichen Bedürfnisse erweitern können. Aufgerufen werden sie über eine Pipe. Die Liste der Artikel wird dem Batcher über die Standardeingabe übergeben, der daraus den Batch erzeugt und an die Standardausgabe weiterleitet. Diese wird über eine Pipe an den Muncher weitergeleitet und so weiter. Hier folgt eine Beispieldatei: # batchparms-Datei für die Brauerei # site | größe |max |batcher |muncher |transport #-------------+--------+-------+---------+-----------+----------- /default/ 100000 22 batcher compcun viauux swim 10000 10 batcher nocomp viauux

1.

So wie es mit C News ausgeliefert wird, verwendet compcun compress mit der 12-Bit-Option, weil dies den kleinsten gemeinsamen Nenner für die meisten Systeme darstellt. Sie können eine Kopie, beispielsweise compcun16, erzeugen, bei der die 16-Bit-Komprimierung verwendet wird. Die Verbesserung ist allerdings nicht so berauschend.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

News und Expiring Bei B News wurden alte Artikel mit Hilfe des Programms expire entfernt. Als Argumente wurden eine Liste von Newsgruppen sowie eine Zeitspanne übergeben, nach denen Artikel gelöscht werden sollten. Um verschiedene Hierarchien unterschiedlich lange vorzuhalten, mußte man ein Skript schreiben, das expire für jede Hierarchie einzeln aufrief. C News bietet Ihnen hierfür eine bequemere Lösung. In einer Datei namens explist können Sie Newsgruppen zusammen mit den Zeitintervallen, nach denen jeweils gelöscht werden soll, festhalten. Ein Befehl namens doexpire wird dann üblicherweise einmal pro Tag von cron aus gestartet, der dann alle Gruppen entsprechend der Liste bereinigt. Gelegentlich möchten Sie Artikel aus verschiedenen Gruppen behalten, selbst wenn die Ablaufzeit bereits überschritten wurde. Beispielsweise möchten Sie alle Programme aus comp.sources.unix aufheben. Dies wird Archivierung genannt. explist erlaubt Ihnen die Markierung von zur Archivierung bestimmten Gruppen. Ein Eintrag in explist hat das folgende Format: gruppenliste rechte zeiten archiv

gruppenliste ist eine durch Kommata unterteilte Liste der Newsgruppen, für die dieser Eintrag gilt. Hierarchien können durch das Präfix des Gruppennamens spezifiziert werden, dem optional das Schlüsselwort all folgen kann. So können Sie etwa für einen Eintrag, der für alle Gruppen unter comp.os gilt, sowohl comp.os als auch comp.os.all angeben. Werden Artikel aus einer Gruppe gelöscht, wird der Name nacheinander mit allen Einträgen in explist verglichen. Der erste passende Eintrag wird dann verwendet. Um beispielsweise den größten Teil von comp nach vier Tagen zu löschen, mit Ausnahme von comp.os.linux.announce, die erst nach einer Woche entfernt werden soll, müssen Sie einfach einen Eintrag mit einer Frist von sieben Tagen für letztere definieren, dem der Eintrag von comp folgt, bei dem nur vier Tage angegeben werden. Das Feld rechte legt fest, ob der Eintrag für moderierte, unmoderierte oder beliebige Gruppen gilt. Dieses Feld kann einen der Werte m, u oder x annehmen, was entsprechend moderiert, unmoderiert oder beliebig bedeutet. Das dritte Feld, zeiten, enthält üblicherweise nur eine Zahl. Sie bestimmt die Anzahl von Tagen, nach denen ein Artikel für ungültig erklärt wird. Diese Ablaufzeit kann durch eine explizite Ablaufzeit im Feld Expires: des Artikel-Headers überschrieben werden. Beachten Sie, daß diese Zahl die Ablaufzeit nach dem Eintreffen auf Ihrem System bestimmt und sich nicht an der Zeit des Postings orientiert.

Das zeiten-Feld kann aber auch komplexer sein. Es kann eine Kombination von bis zu drei Zahlen enthalten, die voneinander durch Bindestriche getrennt sind. Die erste Zahl bestimmt die Anzahl von Tagen, die ein Artikel mindestens erhalten bleibt, auch wenn er nach der Information im Expires:-Feld bereits gelöscht sein sollte. Es ist kaum sinnvoll, diesen Wert auf etwas anderes als null zu setzen. Das zweite Feld enthält die bereits oben beschriebene Anzahl von Tagen, nach denen ein Artikel gelöscht wird. Der dritte Wert bestimmt die bedingungslose Ablaufzeit eines Artikels, gleichgültig, ob ein Expires:-Feld existiert oder nicht. Wird nur der mittlere Wert angegeben, werden für die beiden anderen Standardwerte eingesetzt. Diese können mit dem Spezialeintrag /bounds/ bestimmt werden, der später noch beschrieben wird. Im vierten Feld, archiv, wird festgelegt, ob die Newsgruppe archiviert wird, und wenn ja, wo. Wird keine Archivierung gewünscht, sollte an dieser Stelle ein Bindestrich stehen. Ansonsten steht an dieser Stelle entweder der volle Pfadname (der auf ein Verzeichnis zeigt) oder ein Klammeraffe (@). Der Klammeraffe steht für ein Standard-Archivierungsverzeichnis, das dann an doexpire über die Option –a in der Kommandozeile übergeben werden muß. Ein Archiv-Verzeichnis sollte news gehören. Archiviert doexpire etwa einen Artikel aus comp.sources.unix, speichert es diesen im Verzeichnis comp/sources/unix unter dem Archiv-Verzeichnis. Wenn dieses noch nicht existiert, wird es automatisch erzeugt. Das Archiv-Verzeichnis selbst wird allerdings nicht automatisch erzeugt. In der Datei explist gibt es zwei spezielle Einträge, auf die sich doexpire verläßt. Anstelle einer Liste mit Newsgruppen verwenden sie die Schlüsselwörter /bounds/ und /ex-pired/. Der /bounds/-Eintrag enthält die Standardwerte der drei oben beschriebenen Einträge für das zeiten-Feld. Im /expired/-Feld wird festgelegt, wie lange C News an Zeilen aus der history-Datei festhält. C News entfernt Zeilen aus der history-Datei nicht automatisch, wenn der oder die entsprechenden Artikel gelöscht wurden. Statt dessen wird die Zeile für den Fall behalten, daß noch eine Kopie des Artikels nach diesem Datum eintreffen sollte. Falls Sie von nur einem System mit News versorgt werden, können Sie diesen Wert klein halten. In UUCP-Netzen ist es ratsam, ihn auf ein paar Wochen zu setzen, abhängig von den Verzögerungen, mit denen News von diesen Systemen bei Ihnen eintreffen. Ein Beispiel einer solchen explist-Datei mit ziemlich kurzen Zeitintervallen ist nachfolgend aufgeführt: # history-Zeilen zwei Wochen halten. Kein Artikel bekommt mehr als drei Monate. /expired/ x 14 - /bounds/ x 0-1-90 - # Gruppen, die wir länger halten wollen als den Rest comp.os.linux.announce m 10 - comp.os.linux x 5 - alt.folklore.computers u 10 - rec.humor.oracle m 10 - soc.feminism m 10 - # Archiviere die *.sourcesGruppen comp.sources,alt.sources x 5 @ # Standardwerte für technische Gruppen comp,sci x 7 - # Genug für ein langes Wochenende misc,talk x 4 - # Schnell weg mit überflüssigem Ballast junk x 1 - # Steuernachrichten sind auch nicht von besonderem Interesse control x 1 - # Eintrag, der den ganzen Rest abfängt all x 2 -

Das Löschen von Artikeln zieht einige mögliche Probleme nach sich. Eines dieser Probleme ist, daß Ihr Newsreader sich möglicherweise auf das dritte Feld der oben erwähnten active-Datei verläßt, das die kleinste Nummer des online verfügbaren Artikels enthält. Werden Artikel gelöscht, aktualisiert C News dieses Feld nicht. Wenn dieses Feld die wirkliche Situation widerspiegeln muß (oder soll), muß jedesmal ein Programm namens updatemin ausgeführt werden, nachdem doexpire aufgerufen wurde. (Bei älteren C News-Versionen wurde ein Skript namens upact verwendet.) Sollen unter C News Artikel gelöscht werden, werden nicht die Verzeichnisse der Newsgruppen durchsucht, sondern es wird einfach anhand der history-Datei überprüft, ob ein Artikel das Ablaufdatum überschritten hat.1 Ist Ihre history-Datei aus irgendeinem Grund nicht auf dem neuesten Stand, könnten Artikel für immer auf Ihrer Festplatte schmoren, weil C News sie einfach vergessen hat.2 Sie können die Synchronisation durch das Skript addmissing wiederherstellen, das in /usr/lib/news/maint zu finden ist und fehlende Artikel in die history aufnimmt. Eine andere Möglichkeit bietet mkhistory, das die gesamte Datei neu erstellt. Denken Sie daran, diese Operationen als news durchzuführen, weil Sie ansonsten eine historyDatei erzeugen, die von C News nicht gelesen werden kann.

1.

Die Zeit, zu der ein Artikel eingetroffen ist, ist im mittleren Feld der history-Zeile zu finden. Der Wert wird in Sekunden seit dem 1.1.1970 angegeben.

2.

Ich weiß nicht, warum das passiert, aber bei mir kommt das von Zeit zu Zeit vor.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Weitere Dateien Es gibt eine Reihe von Dateien, die das Verhalten von C News kontrollieren, für den Betrieb aber nicht von grundlegender Bedeutung sind. Alle diese Dateien sind in /etc/news zu finden und werden nachfolgend kurz beschrieben. newsgroups Eine mit active verwandte Datei, die eine Liste mit den Namen jeder Newsgruppe zusammen mit einer einzeiligen Beschreibung ihres Hauptthemas enthält. Diese Datei wird automatisch aktualisiert, wenn C News die Steuernachricht checknews empfängt. localgroups Wenn Sie viele lokale Gruppen haben, über die sich C News nicht jedesmal beschweren soll, wenn Sie eine checkgroupsNachricht empfangen, dann tragen Sie ihre Namen und die Beschreibungen in diese Datei ein. Das Format entspricht dem von newsgroups. mailpaths Diese Datei enthält die Adresse des Moderators jeder moderierten Gruppe. Jede Zeile besteht aus dem Namen der Gruppe, dem, durch einen Tabulator getrennt, die E-Mail-Adresse des Moderators folgt. Zwei spezielle Einträge sind standardmäßig bereits enthalten: backbone und internet. Beide enthalten jeweils in Bang-PathNotation den Pfad zum nächsten Backbone-System bzw. zum nächsten System, das die RFC-822-Adressierung (benutzer@host) versteht. Die Standardeinträge lauten: internet

backbone

Sie müssen den Eintrag internet nicht ändern, wenn Sie exim oder sendmail installiert haben, weil diese die RFC-822Adressierung bereits verstehen. Der backbone-Eintrag wird immer verwendet, wenn ein Benutzer an eine moderierte Gruppe postet, deren Moderator nicht explizit aufgeführt ist. Ist beispielsweise der Name der Newsgruppe alt.sewer und enthält der backbone-Eintrag den Wert path!%s, schickt C News den Artikel per E-Mail an path!alt-sewer in der Hoffnung, daß die Backbone-Maschine in der Lage ist, den Artikel weiterzuleiten. Um herauszufinden, welchen Pfad Sie benutzen müssen, wenden Sie sich an den News-

Administrator des Systems, das Sie mit News versorgt. Als letzte Möglichkeit können Sie auch uunet.uu.net!%s verwenden. distributions Diese Datei ist eigentlich keine C News-Datei, sondern wird von einigen Newsreadern und nntpd benutzt. Enthalten ist eine Liste der von Ihrem System erkannten Distributionen sowie eine Beschreibung ihrer (gewünschten) Effekte. So besitzt die virtuelle Brauerei beispielsweise die folgende Datei: world überall auf der Welt local Niederlande mugnet nur MUGNET fr brewery nur die virtuelle Brauerei

nur lokal für dieses System nl nur die nur Frankreich de nur Deutschland

log In dieser Datei werden alle Aktivitäten von C News festgehalten. Sie sollte regelmäßig über newsdaily gestutzt werden. Kopien alter Logdateien werden unter den Namen log.o, log.oo und so weiter gespeichert. errlog In dieser Datei werden alle von C News erzeugten Fehlermeldungen gespeichert. Artikel, die aufgrund einer falschen Gruppe aussortiert wurden, und ähnliches fallen aber nicht hierunter. Diese Datei wird von newsdaily automatisch per E-Mail an den Newsmaster (standardmäßig usenet) geschickt, wenn sie nicht leer ist. errlog wird von newsdaily geleert. errlog.o bewahrt alte Kopien und dergleichen auf. batchlog In dieser Datei werden alle Durchläufe von sendbatches gespeichert. Diese Datei ist üblicherweise nur von geringem Interesse. Sie wird auch von newsdaily benutzt. watchtime Eine leere Datei, die jedesmal erzeugt wird, wenn newswatch gestartet wird.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Steuermeldungen Das Protokoll der Usenet-News kennt eine spezielle Kategorie von Artikeln, die be-stimmte Antworten bzw. Aktionen durch das News-System erzwingen. Diese werden als Steuermeldungen (control messages) bezeichnet. Erkannt werden sie durch das Vorhandensein eines Control:-Feldes im Artikel-Header, das den Namen der auszuführenden Steuerungsoperation enthält. Es gibt die verschiedensten Operationen, die alle durch Shell-Skripten übernommen werden, die in /usr/lib/news/ctl zu finden sind. Die meisten dieser Aktionen werden automatisch ausgeführt, während C News den Artikel bearbeitet, wobei der Newsmaster nicht darüber informiert wird. Standardmäßig werden nur checkgroups-Meldungen an den Newsmaster weitergeleitet, was Sie aber durch Editieren der Skripten ändern können.

Die cancel-Meldung Die bekannteste Meldung ist cancel. Damit kann ein Benutzer einen vorher geposteten Artikel löschen. Diese Nachricht entfernt den Artikel, wenn er existiert, aus den Spool-Verzeichnissen. Die cancel-Meldung wird an alle Systeme weitergeleitet, die News aus den Gruppen beziehen, die diese Meldung betrifft. Dabei ist es gleichgültig, ob das System den Artikel bereits gesehen hat oder nicht. So wird die Möglichkeit in Betracht gezogen, daß der eigentliche Artikel erst nach der cancel-Meldung eintrifft. Einige News-Systeme erlauben es, Nachrichten anderer Personen zu löschen. Das sollten Sie natürlich niemals tun.

newgroup und rmgroup Die zwei Steuermeldungen, die dem Erzeugen und Entfernen von Newsgruppen -dienen, sind newgroup und rmgroup. Newsgruppen unter den “üblichen” Hierarchien können nur nach einer Diskussion und einer abschließenden Abstimmung zwischen Usenet-Lesern erzeugt werden. Die bei der alt-Hierarchie gültigen Regeln kommen der totalen Anarchie recht nahe. Weitere Informationen finden Sie in den regelmäßigen Veröffentlichungen in news.announce.newusers und news.announce.newgroups. Senden Sie niemals selbst eine newgroup- oder rmgroup-Nachricht, solange Sie nicht ganz sicher sind, daß Sie das auch wirklich dürfen.

Die checkgroups-Meldung checkgroups-Meldungen werden von News-Administratoren verschickt, damit alle Systeme innerhalb eines Netzwerks ihre

active-Dateien mit den Gegebenheiten im Usenet synchronisieren können. So könnten etwa kommerzielle Internet Service Provider eine solche Nachricht an die Systeme ihrer Kunden schicken. Einmal im Monat wird die “offizielle” checkgroupsMeldung für die Haupt-Hierarchien vom entsprechenden Moderator in comp.announce.newgroups gepostet. Allerdings wird sie als normaler Artikel gepostet und nicht als Steuermeldung. Um die checkgroups-Operation durchzuführen, speichern Sie den Artikel in einer Datei, etwa /tmp/check, löschen alles bis zum Beginn der eigentlichen Steuermeldung und übergeben es mit dem folgenden Befehl an das checkgroups-Skript: # su news -c "/usr/lib/news/ctl/checkgroups" < /tmp/check

Dadurch wird Ihre newsgroups-Datei aktualisiert, wobei die in localgroups aufgeführten Gruppen hinzugefügt werden. Die alte newsgroups-Datei wird unter dem Namen newsgroups.bac gespeichert. Das lokale Posten einer solchen Meldung funktioniert übrigens selten, weil inews, der Befehl, der Artikel von Benutzern empfängt und postet, einen so großen Artikel nicht akzeptiert. Erkennt C News Unterschiede zwischen der checkgroups-Liste und der active-Datei, erzeugt es eine Liste von Befehlen, die Ihr System auf den neuesten Stand bringen, und schickt sie an den News-Administrator. Die Ausgabe sieht üblicherweise wie folgt aus: From news Sun Jan 30 16:18:11 1994 Date: Sun, 30 Jan 94 16:18 MET From: news (News Subsystem) To: usenet Subject: Problems with your active file The following newsgroups are not valid and should be removed. alt.ascii-art bionet.molbio.gene-org comp.windows.x.intrisics de.answers You can do this by executing the commands: /usr/lib/news/maint/delgroup alt.ascii-art /usr/lib/news/maint/delgroup bionet.molbio.gene-org /usr/lib/news/maint/delgroup comp.windows.x.intrisics /usr/lib/news/maint/delgroup de.answers The following newsgroups were missing. comp.binaries.cbm comp.databases.rdb comp.os.geos comp.os.qnx comp.unix.user-friendly misc.legal.moderated news.newsites soc.culture.scientists talk.politics.crypto talk.politics.tibet

Wenn Sie eine solche Meldung von Ihrem News-System erhalten, sollten Sie ihr aber nicht blind vertrauen. Je nachdem, wer Ihnen die checkgroups-Meldung geschickt hat, können einige Gruppen oder sogar ganze Hierarchien fehlen. Seien Sie also äußerst vorsichtig beim Entfernen jeglicher Gruppen. Wenn Sie Gruppen finden, die als fehlend aufgeführt sind, die Sie aber auf Ihrem System haben möchten, müssen Sie sie über das Skript addgroup aufnehmen. Speichern Sie die Liste der fehlenden Gruppen in einer Datei, und übergeben Sie sie an das folgende kleine Skript: #!/bin/sh # WHOIAM=`whoami` if [ "$WHOIAM" != "news" ] then echo "Sie müssen $0 als Benutzer ’news’ ausführen" > &2 exit 1fi # cd /usr/lib/news while read group; do if grep -si "^$group[[:space:]].*moderated" newsgroup; then mod=m else mod=y fi /usr/lib/news/maint/addgroup $group $mod done

sendsys, version und senduuname Zum Schluß gibt es noch drei Meldungen, durch die Sie etwas über die Netzwerktopologie erfahren können. Dies sind sendsys, version und senduuname. Sie veranlassen C News, die sys-Datei an den Absender zurückzuliefern sowie einen String, der die Softwareversion widerspiegelt, bzw. die Ausgabe von uuname. Bei der version-Meldung gibt sich C News dagegen eher wortkarg und liefert ein einfaches, schmuckloses C zurück. Auch in diesem Fall sollten Sie niemals eine solche Meldung verschicken, solange Sie nicht sichergestellt haben, daß sie Ihr (regionales) Netzwerk nicht verlassen kann. Antworten auf sendsys-Meldungen können ein UUCP-Netzwerk nämlich ganz schnell in die Knie zwingen.1

1.

Ich würde das allerdings auch im Internet nicht versuchen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

C News in einer NFS-Umgebung Ein einfacher Weg, News in einem lokalen Netzwerk zu verteilen, besteht darin, alle News auf einem zentralen Host zu speichern und die relevanten Verzeichnisse über NFS zu exportieren, so daß die Newsreader die Artikel direkt von dort lesen können. Der Vorteil dieser Methode gegenüber NNTP liegt darin, daß der durch den Abruf und das Threading verursachte Overhead deutlich geringer ist. Andererseits hat NNTP in heterogenen Netzwerken Vorteile, wo sich die Ausstattung der einzelnen Hosts stark unterscheidet oder wo Benutzer keine gleichwertigen Benutzerkonten auf der Servermaschine besitzen. Bei NFS müssen auf einem lokalen Host gepostete Artikel an die zentrale Maschine weitergeleitet werden, weil der gleichzeitige Zugriff auf administrative Dateien zu Inkonsistenzen führen kann. Darüber hinaus wollen Sie eventuell auch Ihren Spool-Bereich schützen, indem Sie ihn nur mit Leserechten exportieren, was wiederum die Weiterleitung an die zentrale Maschine erfordert. C News verwaltet die Konfiguration des Zentralrechners für den Benutzer transparent. Wenn Sie einen Artikel posten, startet Ihr Newsreader üblicherweise inews, um den Artikel an das News-System zu übergeben. Dieser Befehl führt eine ganze Reihe von Prüfungen des Artikels durch, vervollständigt den Header und prüft die Datei server in /etc/news. Wenn die Datei existiert und der Hostname sich von dem des lokalen Host unterscheidet, wird inews über rsh auf dem Server-Host ausgeführt. Weil das inews-Skript eine Reihe binärer Programme und Support-Dateien von C News verwendet, müssen

Sie C News entweder lokal installiert haben oder die News-Software über den Server mounten. Damit der rsh-Aufruf ordnungsgemäß funktionieren kann, muß jeder Benutzer, der News postet, ein entsprechendes Benutzerkonto auf dem Serversystem besitzen, d.h. eines, bei dem nicht nach einem Paßwort gefragt wird. Stellen Sie sicher, daß der in server stehende Hostname exakt mit der Ausgabe des hostname-Befehls auf der Servermaschine übereinstimmt, weil C News sonst beim Versuch, den Artikel auszuliefern, in einer Endlosschleife hängenbleibt. Über NFS sprechen wir ausführlich in Kapitel 14 Das Network File System.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verwaltungsaufgaben und -Tools Trotz der Komplexität von C News kann das Leben eines News-Administrators recht einfach sein, denn C News stellt eine breite Palette von Verwaltungs-Tools zur Verfügung. Einige wie beispielsweise newsdaily sind für den regelmäßigen Betrieb aus cron heraus gedacht. Die Verwendung dieser Skripten reduziert die Anforderungen an die tägliche Pflege Ihrer C NewsInstallation ganz beträchtlich. Wenn nicht anders erwähnt, sind diese Befehle in /usr/lib/news/maint zu finden. Denken Sie daran, diese Befehle nur als news auszuführen. Die Ausführung dieser Befehle als Superuser kann dazu führen, daß C News auf kritische News-Dateien nicht mehr zugreifen kann. newsdaily Der Name sagt es bereits: Führen Sie es einmal täglich aus. Es ist ein wichtiges Skript, mit dem Sie Ihre Logdateien klein halten, wobei jeweils Kopien der letzten drei Läufe aufgehoben werden. Es versucht auch, Anomalien, wie alte Batches in ein- oder ausgehenden Verzeichnissen oder Postings an unbekannte oder moderierte Newsgruppen usw., zu erkennen. Daraus resultierende Fehlermeldungen werden per E-Mail an den Newsmaster geschickt. newswatch

Dieses Skript sollte regelmäßig etwa einmal stündlich ausgeführt werden, um Anomalien im News-System zu entdecken. Es ist für die Erkennung von Problemen gedacht, die einen unmittelbaren Einfluß auf den Betrieb des News-Systems haben. Ein Problembericht wird dann per E-Mail an den Newsmaster geschickt. Überprüft werden Dinge wie alte LockDateien, die nicht entfernt wurden, unbeaufsichtigte Eingabe-Batches und knapper Festplattenspeicher. addgroup Fügt Ihrem lokalen System eine Gruppe hinzu. Der korrekte Aufruf sieht wie folgt aus: addgroup gruppenname y|n|m|=reale_gruppe

Das zweite Argument hat dieselbe Bedeutung wie die Option in der active-Datei, d.h., jeder kann in diese Gruppe posten (y), keiner darf posten (n), die Gruppe wird moderiert (m), oder dies ist ein Alias für eine andere Gruppe (=reale_gruppe). Sie können addgroup auch verwenden, wenn die ersten Artikel einer neu angelegten Gruppe früher erscheinen als die newgroup-Steuermeldung, die sie anlegen sollte. delgroup Erlaubt das lokale Löschen einer Gruppe. Der korrekte Aufruf lautet wie folgt: delgroup gruppenname

Die im Spool-Verzeichnis der Newsgruppe verbliebenen Artikel müssen Sie selbst löschen. Alternativ können Sie den Dingen auch ihren natürlichen Lauf lassen (d.h. expire abwarten), um sie verschwinden zu lassen. addmissing Nimmt fehlende Artikel in die history-Datei auf. Führen Sie dieses Skript aus, wenn Sie Artikel entdecken, die so aussehen, als würden sie für immer bei Ihnen rumhängen. newsboot Dieses Skript sollte während der Boot-Phase des Systems ausgeführt werden. Es entfernt alle Lock-Dateien, die übriggeblieben sind, wenn News-Prozesse bei einem Shutdown unterbrochen wurden. Außerdem schließt es alle Batches und führt noch übriggebliebene Batches aus NNTP-Verbindungen aus, die beim Shutdown des Systems beendet wurden. newsrunning Ist in /usr/lib/news/input zu finden und wird genutzt, um die Verarbeitung von Batches mit

ankommenden News (z.B. während der normalen Arbeitszeiten) zu unterdrücken. Der Befehl lautet: /usr/lib/news/input/newsrunning off

Die Verarbeitung wird wieder eingeschaltet durch Angabe von on anstelle des off.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 22 NNTP und der NNTPDDämon

Das Network News Transfer Protocol (NNTP) vertritt einen ganz anderen Ansatz für den Austausch von News von C News und anderen News-Servern, die keine NNTP-Unterstützung bieten. Anstatt sich auf eine Batch-basierte Technologie wie UUCP zu stützen, bei der News-Artikel zwischen einzelnen Maschinen übertragen werden, können bei NNTP Artikel über eine interaktive Netzwerkverbindung ausgetauscht werden. NNTP ist kein bestimmtes Softwarepaket, sondern ein Internetstandard, der in RFC-977 beschrieben wird. Es basiert auf einer Stream-orientierten Verbindung — üblicherweise über TCP — zwischen einem Client irgendwo im Netzwerk und einem Server auf einem Host, der die Netnews auf Platte hält. Die Stream-Verbindung erlaubt es dem Client und dem Server, interaktiv den Transfer von Artikeln zu vereinbaren, wobei es nahezu keine Verzögerungen gibt. Auf diese Weise wird die Anzahl doppelt übertragener Artikel klein gehalten.

Zusammen mit den hohen Übertragungsraten im Internet ergibt sich so ein News-Transport, der dem jener ursprünglichen UUCP-Netzwerke bei weitem überlegen ist. Während es vor einigen Jahren nicht unüblich war, daß ein Artikel zwei Wochen benötigte, um bis in die letzte Ecke des Usenet zu gelangen, sind es heute weniger als zwei Tage. Im Internet selbst ist es nur noch eine Frage von Minuten. Verschiedene Befehle erlauben es Clients, Artikel zu empfangen, zu versenden und zu posten. Der Unterschied zwischen dem Versenden und dem Posten liegt darin, daß bei letzterem auch Artikel mit unvollständigen Header-Informationen auftauchen können, was im allgemeinen bedeutet, daß der Benutzer den Artikel lediglich geschrieben hat.1 Der Abruf von Artikeln kann sowohl über NewsTransferclients als auch von Newsreadern erledigt werden. Das macht NNTP zu einem ausgezeichneten Werkzeug, mit dem vielen Clients in einem lokalen Netzwerk der Zugriff auf News gewährt werden kann, ohne daß die beim Einsatz von NFS üblichen Klimmzüge vonnöten wären. NNTP bietet einen aktiven und einen passiven Weg der News-Übertragung, die allgemein als “Pushing” (Schieben) und “Pulling” (Ziehen) bekannt sind. Pushing ist grundsätzlich dasselbe wie das ihave/sendme-Protokoll von C News (beschrieben in Kapitel 21 C News). Der Client bietet dem Server einen Artikel über den Befehl IHAVE msgid an, und der Server liefert einen Antwortcode zurück, der angibt, ob er den Artikel bereits hat oder ob er ihn haben möchte. Hat er ihn noch nicht, überträgt ihn der Client und schließt den Vorgang durch einen Punkt auf einer separaten Zeile ab. Dieses Schieben der News hat den einzigen Nachteil, daß es zu einer hohen Belastung des Serversystems führt, weil es seine history-Datenbank für jeden einzelnen Artikel durchsuchen muß. Die andere Technik ist das Ziehen oder Pulling von News. Dabei fordert der Client eine Liste aller (verfügbaren) Artikel aus einer Gruppe an, die nach einem bestimmten Datum angekommen sind. Diese Anfrage wird von dem Befehl NEWNEWS durchgeführt. Aus der zurückgegebenen Liste von Message-IDs wählt der Client jene aus, die er noch nicht besitzt, und wendet dafür auf jeden einzelnen Artikel den ARTICLE-Befehl an. Beim Ziehen von News bedarf es einer strengen Kontrolle durch den Server, welche Gruppen und Distributionen ein Client überhaupt anfordern darf. Beispielsweise muß sichergestellt sein, daß kein vertrauliches Material aus lokalen Newsgruppen des Systems an nicht autorisierte Clients übertragen wird. Es existiert eine Reihe weiterer Befehle, mit denen Newsreader den Artikel-Header und die eigentliche Nachricht (den Body) separat lesen können. Sogar einzelne Header-Zeilen aus einer Reihe von Artikeln können gelesen werden. Auf diese Weise wird es möglich, alle News auf einem zentralen Host zu halten, während alle Benutzer eines (vermutlich lokalen) Netzwerks über NNTPbasierte Clients News lesen und posten können. Dies ist eine Alternative zum im Kapitel 21 C News, beschriebenen Export von News-Verzeichnissen über NFS. Ein allgemeines Problem von NNTP ist, daß es gut informierten Personen die Möglichkeit bietet, Artikel mit falschen Absenderdaten in den News-Stream einzufügen. Das wird als Fälschen von News (News Faking oder Spoofing) bezeichnet.2 Eine Erweiterung von NNTP erlaubt die Verwendung von

Benutzer-Authentifizierungen für bestimmte Befehle und bietet einen gewissen Schutz vor Leuten, die Ihren News-Server auf diese Weise mißbrauchen. Es sind eine ganze Reihe von NNTP-Paketen verfügbar. Eines der bekanntesten Pakete ist der NNTPDämon, der auch als Referenz-Implementierung bekannt ist. Er wurde ursprünglich von Stan Barber und Phil Lapsley geschrieben, um die Details von RFC-977 zu veranschaulichen. Wie bei der meisten guten, heute erhältlichen Software gibt es den NNTP-Dämon in vorgefertigter Form für Ihre LinuxDistribution, oder Sie können sich die Quellen besorgen und ihn selbst kompilieren. Wenn Sie letzteres vorziehen, müssen Sie allerdings mit Ihrer Distribution gut vertraut sein, damit Sie alle Ihre Datenpfade auch wirklich korrekt konfigurieren. Das nntpd-Paket besteht aus einem Server und zwei Clients, mit denen News geschoben bzw. gezogen werden können. Außerdem gibt es einen Ersatz für den inews-Befehl. Sie sind für eine B NewsUmgebung konzipiert, mit wenigen Anpassungen aber auch mit C News zu verwenden. Wenn Sie aber mit dem Gedanken spielen, NNTP für mehr einzusetzen, als nur Newsreadern den Zugriff auf Ihren News-Server zu ermöglichen, ist die Referenz-Implementierung nicht wirklich geeignet. Aus diesem Grund behandeln wir an dieser Stelle nur den im nntpd-Paket enthaltenen NNTP-Dämon und lassen die Client-Programme außen vor. Wenn Sie ein großes News-System betreiben wollen, sollten Sie einen Blick auf InterNet News, kurz INN, werfen, das von Rich Salz geschrieben wurde. News können damit sowohl über NNTP als auch über UUCP transportiert werden. Wenn es um den News-Transport über NNTP geht, ist es definitiv besser als nntpd. INN besprechen wir ausführlich in Kapitel 23 Internet News.

1.

Wird ein Artikel über NNTP gepostet, fügt der Server mindestens ein Header-Feld, nämlich NntpPosting-Host:, hinzu. Es enthält den Hostnamen des Client.

2.

Dasselbe Problem existiert auch bei SMTP, dem Simple Mail Transfer Protocol. Die meisten MailTransportprogramme bieten nun Mechanismen, mit denen Spoofing verhindert werden kann.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz

© 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Das NNTP-Protokoll Wir erwähnten bereits zwei NNTP-Befehle, die maßgeblich dafür sind, wie News-Artikel zwischen Servern gezogen oder geschoben werden. Im Rahmen einer echten NNTP-Sitzung werfen wir einen näheren Blick auf diese Befehle, um Ihnen zu zeigen, wie einfach dieses Protokoll ist. Zur Veranschaulichung benutzen wir einen einfachen telnet-Client, um uns mit dem INN-basierten News-Server news.vbrew.com in der virtuellen Brauerei zu verbinden. Der Server wird hier nur mit einer minimalen Konfiguration betrieben, um die Beispiele möglichst knapp zu gestalten. Wie die Konfiguration dieses Servers vervollständigt wird, sehen wir dann in Kapitel 23 Internet News. Bei unserem Test achten wir sehr sorgfältig darauf, die Artikel ausschließlich in der Newsgruppe junk zu erzeugen, damit wir niemanden stören.

Verbindung mit dem News-Server herstellen Eine Verbindung zu einem News-Server aufzubauen erfordert nur,daß Sie eine TCP-Verbindung zu seinem NNTP-Port herstellen. Sobald Sie verbunden sind, werden Sie mit einer Willkommens-Meldung begrüßt. Einer der ersten Befehle, die Sie ausprobieren könnten, ist help. Die Antwort, die Sie erhalten, hängt im allgemeinen davon ab, ob der Server Sie für einen Remote-NNTP-Server oder für einen Newsreader hält, da dafür unterschiedliche Befehlssätze erforderlich sind. Ihren Betriebsmodus können Sie mit dem Befehl mode ändern; das betrachten wir gleich: $ telnet news.vbrew.com nntp Trying 172.16.1.1... Connected to localhost. Escape character is '^]'. 200 news.vbrew.com InterNetNews server INN 1.7.2 08-Dec-1997 ready help 100 Legal commands authinfo help ihave check takethis list mode xmode quit head stat xbatch xpath xreplic For more information, contact "usenet" at this machine. .

Die Antworten auf NNTP-Befehle enden grundsätzlich mit einem Punkt in einer separaten Zeile. Die Nummern, die Sie in der Ausgabeliste sehen, sind Antwortcodes (response codes) und werden vom Server benutzt, um einen Erfolg oder Mißerfolg eines Befehls anzuzeigen. Die Antwortcodes werden in RFC-977 beschrieben. Über die wichtigsten davon reden wir noch im folgenden.

News-Artikel auf einen Server schieben (Pushing) Den IHAVE-Befehl erwähnten wir bereits, als wir über das Schieben (Pushing) von Artikeln auf einen News-Server sprachen.

Jetzt werfen wir einen Blick darauf, wie IHAVE denn nun wirklich funktioniert: ihave <[email protected]> 335 From: [email protected] Subject: test message sent with ihave Newsgroups: junk Distribution: world Path: gw.vk2ktj.ampr.org Date: 26 April 1999 Message-ID: <[email protected]> Body: This is a test message sent using the NNTP IHAVE command. . 235

Bei allen NNTP-Befehlen wird nicht zwischen Groß- und Kleinschreibung unterschieden. Der IHAVE-Befehl verlangt ein obligatorisches Argument, nämlich die Message-ID des geschobenen Artikels. Jedem News-Artikel wird bei seiner Erzeugung eine eindeutige Message-ID zugewiesen. Der Befehl IHAVE bietet eine Möglichkeit, dem NNTP-Server die Auskunft zu entlocken, welche Artikel er hat, wenn er welche auf einen anderen Server schieben will. Der sendende Server führt einen IHAVE-Befehl für jeden Artikel durch, den er schieben will. Wenn der vom empfangenden Server erzeugte Antwortcode auf den Befehl im Bereich “3xx” liegt, überträgt der sendende NNTP-Server den vollständigen Artikel inklusive dem vollen Header und schließt den Artikel mit einem Punkt in einer Einzelzeile ab. Liegt der Antwortcode dagegen im Bereich “4xx”, hat sich der empfangende Server dafür entschieden, diesen Artikel nicht anzunehmen, vielleicht weil er ihn bereits hat oder aus irgendeinem anderen Grund, zum Beispiel weil mal wieder die Platte übergelaufen ist. Wenn der Artikel übertragen wurde, setzt der empfangende Server einen weiteren Antwortcode ab, der anzeigt, ob die Übertragung des Artikels erfolgreich verlaufen ist.

Wechsel in den NNRP-Reader-Modus Newsreader verwenden ihren eigenen Befehlssatz, wenn sie mit einem News-Server reden. Um diese Befehle zu aktivieren, muß der News-Server im sogenannten Leser-Modus bzw. Reader-Modus arbeiten. Die meisten News-Server befinden sich bereits standardmäßig im Reader-Modus, es sei denn, die IP-Adresse des verbindenden Hosts weist auf einen NewsForwarding-Peer hin. Wie auch immer, NNTP bietet jedenfalls einen Befehl, mit dem explizit in den Reader-Modus umgeschaltet werden kann: mode reader 200 news.vbrew.com InterNetNews NNRP server INN 1.7.2 08-Dec-1997 ready/ (posting ok). help 100 Legal commands authinfo user Name|pass Password|generic <prog> <args> article [MessageID|Number] body [MessageID|Number] date group newsgroup head [MessageID|Number] help ihave last list [active|active.times|newsgroups|distributions|distrib.pats|/ overview.fmt|subscriptions] listgroup newsgroup mode reader newgroups yymmdd hhmmss ["GMT"] [] newnews newsgroups yymmddhhmmss ["GMT"] [] next post slave stat [MessageID|Number] xgtitle [group_pattern] xhdr header [range|MessageID] xover [range] xpat header range|MessageID pat [morepat...] xpath MessageID Report problems to <[email protected]> .

Für den NNTP-Reader-Modus gibt es jede Menge Befehle. Viele davon sind so gestaltet, daß sie das Leben eines Newsreaders leichter machen. Wir hatten bereits früher erwähnt, daß es Befehle gibt, mit denen der Server angewiesen wird, den Header und den Inhalt von Artikeln separat zu senden. Außerdem gibt es Befehle, mit denen die verfügbaren Gruppen und Artikel aufgelistet werden können, und weitere Befehle, die Posting gestatten, eine Alternative, um News-Artikel an den Server zu senden.

Verfügbare Gruppen auflisten Der list-Befehl listet eine Reihe verschiedener Informationsarten auf, insbesondere die vom Server unterstützten Gruppen: list newsgroups 215 Descriptions in form "group description". control internal group junk News server internal group local.general local stuff local.test Local test group .

News server General

Aktive Gruppen auflisten Der Befehl list active zeigt jede unterstützte Gruppe an und stellt Informationen über sie bereit. Die beiden Nummern in jeder Ausgabezeile sind die Artikel-Obergrenze sowie die Artikel-Untergrenze, d.h. die höchste bzw. niedrigste Artikelnummer in jeder Gruppe. Der Newsreader gewinnt daraus eine Vorstellung über die Anzahl der Artikel in der Gruppe. Über diese Nummern sprechen wir gleich noch ein wenig. Das letzte Feld in der Ausgabe zeigt Optionen an, die steuern, ob Posting an

die Gruppe erlaubt ist, ob die Gruppe moderiert wird und ob gepostete Artikel tatsächlich gespeichert oder nur durchgereicht werden. Diese Optionen werden detailliert in Kapitel 23 Internet News, beschrieben. Ein Beispiel dafür sieht etwa so aus: list active 215 Newsgroups in form "group high low flags". control 0000000000 0000000001 y junk 0000000003 0000000001 y alt.test 0000000000 0000000001 y .

Posten eines Artikels Wir erwähnten bereits, daß es einen Unterschied gibt zwischen dem Schieben (Pushing) eines Artikels und dem Absenden (Posten) eines Artikels. Wenn Sie einen Artikel schieben, wird implizit angenommen, daß der Artikel bereits existiert, daß er eine eindeutige Message-ID besitzt, die ihm eindeutig vom Server zugewiesen wurde, an den er ursprünglich gepostet wurde, und daß er einen vollständigen Satz von Headern hat. Wenn Sie einen Artikel posten, erzeugen Sie diesen Artikel erstmals, und die einzigen Header, die Sie angeben, sind diejenigen, die für Sie von Bedeutung sind, wie zum Beispiel das Subject sowie die Newsgruppen, an die Sie den Artikel posten. Der News-Server, dem Sie den Artikel senden, fügt all die anderen Header automatisch für Sie hinzu und erzeugt eine Message-ID, die er dann benutzt, wenn er den Artikel auf andere Server schiebt. Alles in allem bedeutet dies, daß das Posten eines Artikels sogar einfacher als das Schieben eines Artikels ist. Ein Beispiel für ein Posting sieht etwa so aus: post 340 Ok From: [email protected] Subject: test message number 1 Newsgroups: junk Body: This is a test message, please feel free to ignore it. . 240 Article posted

Wir haben noch zwei weitere Nachrichten wie diese erzeugt, um unseren folgenden Beispielen etwas Realitätsnähe zu geben.

Neue Artikel auflisten Wenn ein Newsreader erstmals eine Verbindung zu einem neuen Server herstellt und der Benutzer eine Newsgruppe zum Browsen auswählt, benötigt der Newsreader eine Liste neuer Artikel, und zwar derjenigen, die seit dem letzten Login vom Benutzer gepostet oder empfangen wurden. Dafür gibt es den Befehl newnews. Ihm werden drei obligatorische Argumente übergeben: der Name der fraglichen Gruppe(n) sowie das Datum und der Zeitpunkt, ab dem Artikel aufgelistet werden sollen. Datum und Zeitpunkt werden jeweils als sechsstellige Zahl angegeben, wobei die wichtigste Information am Anfang steht: yymmdd bzw. hhmmss. newnews junk 990101 000000 230 New news follows <[email protected]> <[email protected]> <[email protected]> .

Gruppen zur Bearbeitung auswählen Wenn der Benutzer eine Newsgruppe zum Browsen auswählt, kann der Newsreader dem News-Server mitteilen, daß die Gruppe ausgewählt wurde. Das vereinfacht die Interaktion zwischen Newsreader und News-Server, da es nun nicht mehr nötig ist, mit jedem Befehl den Namen der Newsgruppe immer wieder mitzusenden. Der Befehl group nimmt einfach den Namen der ausgewählten Gruppe als Argument. Viele darauffolgende Befehle nehmen dann diese Gruppe als Vorgabewert, sofern keine andere Newsgruppe angegeben wird. group junk 211 3 1 3 junk

Der Befehl group liefert eine Nachricht zurück, die die Anzahl der aktiven Nachrichten, die Artikel-Unter- und -Obergrenze oder den Namen der Gruppe angibt. Obwohl die Anzahl der aktiven Nachrichten und die Artikel-Untergrenze in unserem Beispiel identisch sind, ist das häufig nicht der Fall. In einem aktiven News-Server können manche Artikel bereits gelöscht worden sein, was zwar die Anzahl der aktiven Nachrichten vermindert, die Artikel-Obergrenze jedoch unberührt läßt.

Liste von Artikeln in einer Gruppe Um auf bestimmte Artikel in Newsgruppen zugreifen zu können,muß der Newsreader wissen, welche Artikelnummern aktive

Artikel repräsentieren. Der Befehl listgroup zeigt eine Liste mit Nummern der aktiven Artikel in der aktuellen Gruppe bzw. in einer bestimmten Gruppe, wenn ein Gruppenname angegeben wird: listgroup junk 211 Article list follows 1 2 3 .

Nur Artikel-Header lesen Der Benutzer muß bereits einige Vorabinformationen über einen Artikel bekommen, bevor er entscheiden kann, ob er ihn überhaupt lesen will. Früher erwähnten wir bereits, daß einige Befehle es ermöglichen, den Artikel-Header und -Inhalt getrennt zu übertragen. Mit dem Befehl head wird der Server aufgefordert, nur den Header des angegebenen Artikels an den Newsreader zu übertragen. Wenn der Benutzer diesen Artikel nicht lesen will, haben wir nicht unnütz Zeit und Bandbreite damit verschwendet, einen unter Umständen großen Artikel-Inhalt zu übertragen, der sowieso nicht benötigt wird. Die Artikel werden entweder über ihre Nummer (vom Befehl listgroup) oder ihre Message-ID angesprochen: head 2 221 2 <[email protected]> head Path: news.vbrew.com!not-for-mail From: [email protected] Newsgroups: junk Subject: test message number 2 Date: 27 Apr 1999 21:51:50 GMT Organization: The Virtual brewery Lines: 2 Message-ID: <[email protected]> NNTP-Posting-Host: localhost X-Server-Date: 27 Apr 1999 21:51:50 GMT Body: Xref: news.vbrew.com junk:2 .

Nur Artikel-Inhalt lesen Falls sich der Benutzer aber dafür entscheidet, den Artikel zu lesen, muß der Newsreader den News-Server auffordern können, den Inhalt der ganzen Nachricht zu übertragen. Für diesen Zweck gibt es den Befehl body. Er arbeitet genauso wie der headBefehl, nur daß hier allein der Nachrichteninhalt zurückgeliefert wird: body 2 222 2 <[email protected]> body This is another test message, please feel free to ignore it too. .

Artikel einer Gruppe lesen Auch wenn es zumeist am effizientesten ist, die Header und Inhalte ausgewählter Artikel getrennt zu übertragen, gibt es dennoch Situationen, in denen die komplette Übertragung besser ist. Ein gutes Beispiel dafür sind Anwendungen, mit denen wir alle Artikel einer Gruppe ohne irgendeine Vorauswahl übertragen wollen, zum Beispiel, wenn wir ein NNTP-CacheProgramm wie leafnode benutzen.1 Normalerweise stellt NNTP dafür ein Mittel zur Verfügung, und es ist keine große Überraschung, daß es fast genauso wie der head-Befehl funktioniert. Der Befehl article nimmt auch eine Artikelnummer oder eine Message-ID als Argument, liefert aber den ganzen Artikel inklusive Header zurück: article 1 220 1 <[email protected]> article Path: news.vbrew.com!not-for-mail From: [email protected] Newsgroups: junk Subject: test message number 1 Date: 26 Apr 1999 22:08:59 GMT Organization: The Virtual brewery Lines: 2 Message-ID: <[email protected]> NNTP-Posting-Host: localhost X-Server-Date: 26 Apr 1999 22:08:59 GMT Body: Xref: news.vbrew.com junk:1 This is a test message, please feel free to ignore it. .

Wenn Sie einen unbekannten Artikel verlangen, liefert der Server eine Nachricht mit einem angemessen codierten Antwortcode und vielleicht sogar eine lesbare Textnachricht zurück: article 4 423 Bad article number

In diesem Abschnitt haben wir beschrieben, wie die wichtigsten NNTP-Befehle angewendet werden. Wenn Sie daran interessiert sind, Software zu entwickeln, die das NNTP-Protokoll implementiert, sollten Sie dafür die relevanten RFCDokumente heranziehen. Sie bieten eine Fülle detaillierter Informationen, auf die wir hier nicht eingehen können. Lassen Sie uns nun NNTP auf dem Server nntpd in Aktion erleben.

1.

leafnode ist per Anonymous FTP von wpxx02.toxi.uni-wuerzburg.de im Verzeichnis /pub/ erhältlich.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Installation des NNTP-Servers Der NNTP-Server heißt nntpd und kann, abhängig von der erwarteten Auslastung des News-Systems, auf zwei Arten kompiliert werden. Kompilierte Binärversionen sind nicht verfügbar, weil einige systemspezifische Standardwerte fest im ausführbaren -Programm integriert sind. Die gesamte Konfiguration wird über in common/conf.h -definierte Makros erledigt. nntpd kann als selbständiger Server konfiguriert werden, der beim Systemstart aus einer rc-Datei heraus gestartet wird. Alternativ kann er als Dämon konfiguriert werden, der von inetd verwaltet wird. Im letzeren Fall müssen Sie die folgende Zeile in Ihre /etc/inetd.conf aufnehmen: nntp

stream

tcp nowait

news

/usr/etc/in.nntpd

nntpd

Die Syntax von inetd.conf ist ausführlich in Kapitel 12 Wichtige Netzwerk-Features, beschrieben. Wenn Sie nntpd als eigenständigen Server konfigurieren, müssen Sie sicherstellen, daß eine solche Zeile in inetd.conf auskommentiert ist. In beiden Fällen müssen Sie dafür Sorge tragen, daß die folgende Zeile in /etc/services auftaucht: nntp

119/tcp

readnews untp

# Network News Transfer Protocol

Um alle ankommenden Artikel temporär zwischenspeichern zu können, benötigt nntpd auch ein .tmp-

Verzeichnis in Ihrem News-Spool. Sie können es mit den folgenden Befehlen einrichten: # mkdir /var/spool/news/.tmp # chown news.news /var/spool/news/.tmp

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NNTP-Zugriff beschränken Der Zugriff auf NNTP-Ressourcen wird durch die Datei nntp_access im Verzeichnis /etc/news geregelt. Die Zeilen in dieser Datei beschreiben die fremden Hosts zugestandenen Zugriffsrechte. Jede Zeile verwendet das folgende Format: system

read|xfer|both|no

post|no

[!ausser_diesen_gruppen]

Stellt ein Client die Verbindung über den NNTP-Port her, versucht nntpd, den voll qualifizierten Domainnamen des Host anhand der IP-Adresse über einen Reverse Lookup zu ermitteln. Der Hostname und die IP-Adresse des Client werden in der Reihenfolge ihres Auftretens in der Datei mit dem system-Feld verglichen. Bei exakter Übereinstimmung wird der Eintrag verwendet, bei teilweiser Übereinstimmung wird er nur verwendet, wenn nicht noch ein besserer Eintrag folgt. system kann in folgender Form angegeben werden: Hostname Der voll qualifizierte Domainname eines Host. Stimmt dieser mit dem kanonischen Hostnamen des Client exakt überein, wird der Eintrag verwendet, und die nachfolgenden Einträge werden ignoriert. IP-Adresse Die IP-Adresse in Dotted Quad Notation. Stimmt sie mit der IP-Adresse des Client überein, wird der Eintrag verwendet, und die folgenden Einträge werden ignoriert. Domainname Der als *.domain angegebene Domainname. Enthält der Hostname des Client den Domainnamen, wird der Eintrag verwendet. Netzwerkname Der Name eines in /etc/networks spezifizierten Netzwerks. Der Eintrag wird verwendet, wenn die Netzwerknummer der IP-Adresse des Client mit der dem Netzwerknamen zugewiesenen Netzwerknummer übereinstimmt.

default Der String default gilt für jeden Client. Allgemeinere Einträge in der Datei sollten am Anfang der Datei eingetragen sein, weil alle Übereinstimmungen durch später folgende, genauere Übereinstimmungen überschrieben werden. Das zweite und dritte Feld beschreiben die dem Client zugebilligten Zugriffsrechte. Im zweiten Feld wird bestimmt, ob News durch Ziehen (read) oder durch Schieben (xfer) übertragen werden dürfen. Wird both als Wert verwendet, ist beides möglich; no unterdrückt den Zugriff komplett. Im dritten Feld wird festgelegt, ob der Client Artikel posten, d.h. Artikel mit unvollständigen Header-Informationen ausliefern darf, die von der News-Software vervollständigt werden. Steht im zweiten Feld der Wert no, wird das dritte Feld ignoriert. Das vierte Feld ist optional und enthält eine durch Kommata unterteilte Liste von Gruppen, auf die der Client nicht zugreifen darf. Nachfolgend ein Beispiel für eine nntp_access-Datei: # # Standardmäßig darf jeder News übertragen, aber nicht lesen oder posten default xfer no # # public.vbrew.com bietet öffentlichen Zugang über Modem. # Wir erlauben das Lesen und Posten in alle(n) Gruppen außer local.* public.vbrew.com read post !local # # Alle anderen Hosts in der Brauerei dürfen lesen und posten *.vbrew.com read post

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

NNTP-Autorisierung Der nntpd-Dämon stellt ein einfaches Autorisierungsschema zur Verfügung. Durch Großschreiben der Zugriffs-Tokens in der nntp_access-Datei verlangt nntpd vom Client für die Durchführung der entsprechenden Operationen eine Autorisierung. Geben Sie beispielsweise Xfer oder XFER als Zugriffsrecht an (im Gegensatz zu xfer), verweigert nntpd dem Client so lange die Übertragung von Artikeln auf Ihr System, bis die Autorisierung erfolgreich abgeschlossen wurde. Die Autorisierungsprozedur wird über einen neuen NNTP-Befehl namens AUTHINFO abgewickelt. Bei diesem Befehl überträgt der Client einen Benutzernamen und ein Paßwort an den NNTP-Server. nntpd vergleicht diese mit seiner /etc/passwd-Datei und prüft gleichzeitig, ob der Benutzer der Gruppe nntp angehört. Die aktuelle Implementierung der NNTP-Autorisierung befindet sich in einem experimentellen Stadium und ist aus diesem Grund nicht besonders portabel gehalten. Daher funktioniert sie nur mit einfachen Paßwort-Datenbanken, Shadow-Paßwörter werden nicht erkannt. Wenn Sie den Quellcode kompilieren und das PAM-Paket installiert haben, können Sie die Paßwort-Überprüfung leicht ändern.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Interaktion von nntpd und C News Beim Empfang eines Artikels muß nntpd diesen an das News-Subsystem weiterleiten. Abhängig davon, ob der Artikel als Ergebnis eines IHAVE- oder eines POST-Befehls empfangen wurde, wird er an rnews oder inews übergeben. Statt rnews zu starten, können Sie es (während des Kompilierens) so konfigurieren, daß die eingehenden Artikel gesammelt und die daraus resultierenden Batches in /var/spool/news/in.coming gespeichert werden. Dort werden sie dann von relaynews beim nächsten Queue-Durchlauf benutzt. Um das ihave/sendme-Protokoll ordnungsgemäß durchführen zu können, muß nntpd in der Lage sein, auf die history-Datei zuzugreifen. Sie müssen daher beim Kompilieren darauf achten, daß der Pfad korrekt gesetzt ist. Sie müssen weiterhin sicherstellen, daß C News und nntpd sich über das Format Ihrer history-Datei einig sind. C News verwendet für den Zugriff darauf die Hashing-Funktionen von dbm. Allerdings gibt es eine Reihe unterschiedlicher und leicht inkompatibler Implementierungen der dbm-Bibliothek. Wurde C News mit einer anderen dbm-Bibliothek gelinkt als der in der Standardlibc enthaltenen, muß auch nntpd mit dieser Bibliothek gelinkt werden. Typische Anzeichen dafür, daß nntpd und C News im Datenbankformat nicht übereinstimmen, sind Fehlermeldungen im Systemlog, wonach nntpd die Artikel nicht korrekt öffnen kann. Auch mehrfach über NNTP empfangene Artikel sind ein Indiz. Ein guter Test besteht darin, einen Artikel aus Ihrem Spool-Bereich auszuwählen, Ihren nntp-Port über Telnet anzusprechen und den Artikel dann, wie im nachfolgenden Beispiel gezeigt, nntpd anzubieten. Natürlich müssen Sie msg@id durch die Message-ID des Artikels ersetzen, den Sie erneut an nntpd übergeben wollen. $ telnet localhost nntp Trying 127.0.0.1... Connected to localhost Escape characters is '^ ]'. 201 vstout NNTP[auth] server version 1.5.11t (16 November 1991) ready at Sun Feb 6 16:02:32 1194 (no posting) IHAVE msg@id 435 Got it. QUIT

Diese Konversation zeigt die korrekte Reaktion von nntpd: Die Nachricht Got it sagt Ihnen, daß der Artikel bereits empfangen wurde. Erhalten Sie statt dessen die Meldung 335 Ok, ist der Lookup in der history-Datei aus irgendeinem Grund fehlgeschlagen. Beenden Sie die Konversation durch Eingabe von Strg-D. Was schiefgelaufen ist, können Sie im Systemlog ermitteln. nntpd schreibt alle Meldungen in die daemon-Einrichtung von syslog. Eine inkompatible dbm-Bibliothek ist üblicherweise an einer Meldung zu erkennen, die besagt, daß dbminit fehlschlug.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 23 Internet News

Der Internet News Dämon (INN) ist der heute wohl populärste Netnews-Server. INN ist äußerst flexibel und ist für alle Systeme geeignet, wenn man mal von den sehr kleinen News-Systemen

absieht.1 INN skaliert gut und ist besonders für große News-Server-Konfigurationen geeignet. Der INN-Server besteht aus mehreren Komponenten, von denen jede ihre eigenen Konfigurationsdateien hat, die wir der Reihe nach besprechen werden. Die Konfiguration von INN kann ein wenig verzwickt sein, wir werden jedoch in diesem Kapitel über die einzelnen Schritte sprechen und Sie mit genügend Informationen ausstatten, damit Sie die INN-Manpages verstehen und Konfigurationen für beliebige Applikationen erstellen können.

1.

Kleine News-Systeme sollten ein Caching-NNTP-Server-Programm wie leafnode in Betracht ziehen, erhältlich unter http://wpxx02.toxi.uni-wuerzburg.de/~krasel/leafnode.html.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Aufbau von INN Der Hauptbestandteil von INN ist der innd-Dämon. Seine Aufgabe ist es, alle ankommenden Artikel aufzunehmen, sie lokal zu speichern und sie bei Bedarf an beliebige ausgehende Newsfeeds zu übergeben. Er wird beim Systemstart aufgerufen und läuft kontinuierlich als Hintergrundprozeß. Der Betrieb als Dämon verbessert den Durchsatz, da innd seine Statusdateien nur einmal beim Start einlesen muß. Je nachdem, wie umfangreich Ihr Newsfeed ist, haben bestimmte Dateien wie history (die eine Liste aller zuletzt behandelten Artikel enthält) einen Umfang zwischen einigen wenigen Megabytes bis zu zig Megabytes. Ein weiteres wichtiges Merkmal von INN ist, daß stets immer nur eine Instanz von innd läuft. Auch das bringt große Vorteile für den Durchsatz mit sich, da der Dämon alle Artikel verarbeiten kann, ohne sich irgendwelche Gedanken über die Synchronisierung seines internen Zustands mit anderen Instanzen von innd machen zu müssen, die zur gleichen Zeit im News Spool herumstöbern. Diese Wahl hat jedoch Einfluß auf das gesamte Design des News-Systems. Da es so wichtig ist, daß ankommende News immer so schnell wie möglich bearbeitet werden, ist es nicht akzeptabel, wenn der Server mit Allerweltsaufgaben beschäftigt wird, wie Newsreader zu bedienen, die über NNTP auf den News Spool zugreifen, oder Newsbatches zu dekomprimieren, die über UUCP hereinkommen. Diese Aufgaben wurden daher aus dem Hauptserver herausgenommen und in separate SupportProgramme implementiert. Abbildung 23.1 versucht, die Beziehungen zwischen innd, den anderen lokalen Aufgaben, Remote-News-Servern und Newsreadern zu illustrieren.

Heutzutage ist NNTP das meistgenutzte Protokoll zum Transport von News-Artikeln, und innd unterstützt nichts anderes unmittelbar. Das bedeutet, daß innd an einem TCP-Socket (Port 119) auf Verbindungen achtet und News-Artikel mittels des “ihave”-Protokolls aufnimmt. Artikel, die über andere Transporte als NNTP hereinkommen, werden indirekt unterstützt, indem ein anderer Prozeß die Artikel aufnimmt und sie über NNTP an innd weiterleitet. Newsbatches, die zum Beispiel über eine UUCP-Verbindung ankommen, werden auf herkömmliche Weise vom rnewsProgramm verarbeitet. Das rnews von INN dekomprimiert den Batch, falls notwendig, und zerteilt ihn in einzelne Artikel, die dann nacheinander an innd übergeben werden. Newsreader können News ausliefern, wenn ein Benutzer einen Artikel postet. Da die Bedienung der Newsreader besondere Beachtung verlangt, kommen wir später noch darauf zurück. Abbildung 23.1: Die Architektur von INN (vereinfachte Darstellung)

Nach Empfang eines Artikels sucht innd zuerst in der history-Datei nach der Message-ID des Artikels. Doppelte Artikel werden aussortiert und die Ereignisse optional in der Logdatei vermerkt. Dasselbe passiert mit Artikeln, die veraltet sind oder bei denen einige der erforderlichen Header-Felder fehlen (z.B. Subject).1 Wenn innd den Artikel für akzeptabel hält, schaut es im Newsgroups:-Feld nach, an welche Gruppe der Artikel gepostet wurde. Wird mindestens eine dieser Gruppen in der active-Datei gefunden, wird der Artikel auf die Festplatte geschrieben, ansonsten an die spezielle Gruppe junk weitergereicht. Die einzelnen Artikelwerden unter /var/spool/news, auch als News Spool bezeichnet, aufbewahrt. Jede Newsgruppe hat ihr eigenes Verzeichnis, in dem jeder Artikel in einer separaten Datei abgespeichert wird. Die Dateinamen bestehen dabei aus aufeinanderfolgenden Nummern, so daß beispielsweise ein

Artikel in comp.risks in der Datei comp/risks/217 abgelegt wird. Wenn innd merkt, daß das Verzeichnis für den Artikel noch nicht existiert, erzeugt es dieses automatisch. Abgesehen davon, daß Artikel lokal gespeichert werden können, wollen Sie womöglich auch Artikel an ausgehende Feeds weiterreichen. Dafür gibt es die Datei newsfeeds, die alle empfangenden Systeme zusammen mit den Newsgruppen auflistet, die an sie weitergeleitet werden sollten. Wie bei der Eingabevorrichtung von innd wird auch die Verarbeitung ausgehender News über eine einzelne Schnittstelle abgewickelt. Anstatt all die transportspezifischen Verarbeitungsschritte selbst durchzuführen, greift innd auf verschiedene Backends zurück, um die Übertragung von Artikeln auf andere News-Server durchzuführen. Die ausgehenden Einrichtungen werden allesamt als Kanäle (channels) bezeichnet. Je nach Zweck kann ein Kanal verschiedene Attribute haben, die exakt festlegen, welche Informationen innd ihm mitteilt. Für einen ausgehenden NNTP-Feed zum Beispiel könnte innd beim Start das Programm innxmit aufrufen und für jeden Artikel, der über diesen Feed gesendet werden soll, die Message-ID, die Größe und den Dateinamen an die Standardeingabe von innxmit übergeben. Für einen ausgehenden UUCPFeed dagegen könnte es die Größe und den Dateinamen des Artikels in eine spezielle Logdatei schreiben, die von einem anderen Prozeß in regelmäßigen Abständen untersucht wird, um Batches zu erzeugen und sie an die Queue des UUCP-Subsystems weiterzuleiten. Neben diesen beiden Beispielen gibt es noch andere Arten von Kanälen, die keine strikt ausgehenden Feeds sind. Sie werden zum Beispiel verwendet, wenn bestimmte Newsgruppen archiviert oder Übersichten erstellt werden. Übersichten sind als Hilfe für Newsreader gedacht, um die Artikel in Threads effizienter zu verwalten. Newsreader älterer Generationen mußten immer alle Artikel separat durchsuchen, um daraus die Header-Informationen für das Threading zu gewinnen. Auf einer Servermaschine war das natürlich eine erhebliche Belastung, besonders bei Benutzung von NNTP; außerdem war es sehr langsam.2 Der Übersichtsmechanismus vermindert dieses Problem dadurch, daß alle relevanten Header für jede Newsgruppe in einer separaten Datei (namens .overview) vorweg aufgenommen werden. Auf diese Information kann dann von den Newsreadern zurückgegriffen werden, entweder indem sie direkt aus dem Spool-Verzeichnis gelesen wird oder indem sie mit dem Befehl XOVER ermittelt wird, wenn eine NNTP-Verbindung besteht. Bei INN übergibt der inndDämon alle Artikel an den Befehl overchan, der über einen Kanal mit dem Dämon verbunden ist. Wie das gemacht wird, werden wir sehen, wenn wir später die Konfiguration von Newsfeeds besprechen.

1.

Angezeigt wird dies im Date:-Header-Feld; die Grenze liegt normalerweise bei zwei Wochen.

2.

Das Threading von 1.000 Artikeln konnte auf einem ausgelasteten Server schon mal fünf Minuten dauern, was wohl nur für hartgesottene Usenet-Süchtige annehmbar war.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Newsreader und INN Newsreader, die auf derselben Maschine laufen wie der Server (oder die den News Spool des Servers über NFS gemountet haben), können Artikel direkt aus dem Spool-Verzeichnis heraus lesen. Um einen vom Benutzer verfaßten Artikel zu posten, rufen sie das inews-Programm auf. Es ergänzt die Artikel um alle fehlenden Header-Felder und leitet sie über NNTP an den Dämon weiter. Alternativ dazu können Newsreader über NNTP entfernt auf den Server zugreifen. Diese Verbindungsart wird etwas anders gehandhabt als NNTP-basierte Newsfeeds, um den Dämon nicht zu beanspruchen. Immer wenn ein Newsreader eine Verbindung zum NNTP-Server herstellt, startet innd ein separates Programm namens nnrpd, das die Sitzung weiterführt, während innd zu den wichtigeren Dingen zurückkehrt (z.B. ankommende News aufnehmen).1 Sie fragen sich vielleicht, wie der inndProzeß zwischen einem ankommenden Newsfeed und einem verbindenden Newsreader unterscheiden kann. Die Antwort ist recht einfach: Das NNTP-Protokoll verlangt, daß ein NNTP-basierter Newsreader nach der Verbindungsaufnahme mit dem Server eine Mode Reader-Anweisung ausgibt. Nach Empfang dieser Anweisung startet der Server den nnrpd-Prozeß, übergibt ihm die Verbindung und kehrt wieder zurück, um auf Verbindungen von einem anderen News-Server zu achten. Es gab mal mindestens einen DOS-basierten Newsreader, der nicht dafür konfiguriert war, dies zu tun. Er scheiterte kläglich an der Kommunikation mit INN, da innd selbst keinen der Befehle zum Lesen der News erkennt, wenn er nicht weiß, daß die Verbindung von einem Newsreader stammt.

Über den Zugriff von Newsreadern auf INN sprechen wir noch ein wenig im Abschnitt “NewsreaderZugriff steuern” später in diesem Kapitel.

1.

Der Name steht offensichtlich für NetNews Read & Post Dämon.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Installation von INN Bevor wir in die (Un-)Tiefen der INN-Konfiguration abtauchen, lassen Sie uns über die Installation reden. Lesen Sie sich diesen Abschnitt durch, auch wenn Sie INN bereits aus einer der vielen LinuxDistributionen heraus installiert haben; er enthält einige Hinweise über Sicherheit und Kompatibilität. Die Linux-Distributionen enthielten über eine längere Zeitspanne die Version INN-1.4sec. Leider traten in dieser Version zwei heikle Sicherheitsprobleme auf. Moderne Versionen haben diese Probleme nicht mehr, und die meisten Distributionen enthalten ein vorkompiliertes Linux-Binary von INN Version 2 und höher. Wenn Sie wollen, können Sie INN selbst bauen. Den Quellcode erhalten Sie von ftp.isc.org im Verzeichnis /isc/inn/. Für die Bildung von INN müssen Sie eine Konfigurationsdatei editieren, die INN einige Details über Ihr Betriebssystem mitteilt. Für einige Features sind vielleicht auch kleinere Änderungen im Quellcode notwendig. Das Kompilieren des Pakets selbst ist recht einfach. Es gibt darin ein Skript namens BUILD, das Sie durch den Prozeß führt. Außerdem findet man im Quellcode umfangreiche Dokumentationen, wie INN installiert und konfiguriert wird. Nach der Installation aller Binärdateien können noch einige manuelle Nachbesserungen notwendig

sein, um INN zur Kooperation mit anderen Applikationen zu bewegen, die auf sein rnews- oder inewsProgramm zugreifen wollen. UUCP zum Beispiel erwartet das rnews-Programm im Verzeichnis /usr/bin oder /bin, während INN es standardmäßig in /usr/lib/bin installiert. Stellen Sie sicher, daß /usr/lib/bin/ im Suchpfad angegeben ist oder daß es symbolische Links zu den eigentlichen rnews- und inews-Programmen gibt.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von INN: Grundlegende Einrichtung Eines der größten Hindernisse, denen Neulinge begegnen, ist die Tatsache, daß INN — um ordnungsgemäß zu funktionieren — eine bereits funktionierende Netzwerkkonfiguration — sogar auf einem Einzelrechner — voraussetzt. Es ist daher unbedingt notwendig, daß Ihr Kernel für den Betrieb von INN Unterstützung für TCP/IP-Netzwerke bietet und daß Sie das Loopback-Interface eingerichtet haben, wie in Kapitel 5 TCP/IP-Konfiguration, beschrieben. Als nächstes müssen Sie sicherstellen, daß innd während der Boot-Phase gestartet wird. Die Standardinstallation von INN enthält dafür ein Skript namens boot im Verzeichnis /etc/news/. Falls Ihre Distribution ein init-Paket nach SystemV-Art verwendet, brauchen Sie nur einen symbolischen Link von Ihrer Datei /etc/init.d/inn auf /etc/news/boot zu erzeugen. Bei anderen init-Varianten müssen Sie sicherstellen, daß /etc/news/boot von einem Ihrer rc-Skripten gestartet wird. Da INN Netzwerkunterstützung benötigt, sollte das Startskript erst aufgerufen werden, nachdem die Netzwerkschnittstellen konfiguriert wurden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Die Konfigurationsdateien von INN Sobald diese allgemeinen Aufgaben abgeschlossen sind, können Sie sich dem wirklich interessanten Teil von INN zuwenden, nämlich seinen Konfigurationsdateien. Alle diese Dateien residieren in /etc/news. In Version 2 wurden einige Änderungen an den Konfigurationsdateien vorgenommen, und auf diese Version beziehen wir uns hier. Wenn Sie noch eine ältere Version benutzen, ist dieses Kapitel für Sie nützlich, um Ihnen Anleitungen zum Upgrade Ihrer Konfiguration zu geben. In den nächsten paar Abschnitten besprechen wir sie im einzelnen. Als Anschauungsbeispiel erzeugen wir eine Konfiguration für die virtuelle Brauerei. Wenn Sie mehr über die Eigenschaften einzelner Konfigurationsdateien herausfinden wollen, können Sie auch die Manpages zu Rate ziehen. Die INN-Distribution hält Manpages für jede von ihnen bereit.

Globale Parameter Eine Reihe von INN-Parametern sind global; sie sind für alle betriebenen Newsgruppen relevant. Die Datei inn.conf Die Hauptkonfigurationsdatei von INN ist inn.conf. Unter anderem legt sie den Namen fest, unter dem Ihre Maschine im Usenet bekannt ist. Bei Version 2 von INN kann man in dieser Datei eine geradezu verwirrende Anzahl von Parametern konfigurieren. Zum Glück gibt es für die meisten Parameter Standardwerte, die für die meisten Systeme geeignet sind. Die Manpage inn.conf(5) beschreibt all diese Parameter ausführlich, und Sie sollten sie sorgfältig studieren, wenn Sie irgendwelche Probleme bekommen. Hier folgt ein einfaches Beispiel für eine inn.conf-Datei: # inn.conf-Beispiel für die virtuelle Brauerei server: vlager.vbrew.com domain: vbrew.com fromhost: vbrew.com pathhost: news.vbrew.com organization: The Virtual Brewery mta: /usr/sbin/sendmail -oi %s moderatormailer: %[email protected] # # Pfade zu INN-Komponenten und -Dateien. # pathnews: /usr/lib/news pathbin: /usr/lib/news/bin pathfilter: /usr/lib/news/bin/filter pathcontrol: /usr/lib/news/bin/control pathdb: /var/lib/news pathetc: /etc/news pathrun: /var/run/news pathlog: /var/log/news pathhttp: /var/log/news pathtmp: /var/tmp pathspool: /var/spool/news

patharticles: pathoutgoing: patharchive: overviewname:

/var/spool/news/articles pathoverview: /var/spool/news/outgoing pathincoming: /var/spool/news/archive pathuniover: .overview

/var/spool/news/overview /var/spool/news/incoming /var/spool/news/uniover

Die erste Zeile teilt den Programmen rnews und inews mit, welchen Host sie kontaktieren müssen, um Artikel auszuliefern. Dieser Eintrag ist unter allen Umständen erforderlich; um Artikel an innd zu übergeben, müssen sie eine NNTP-Verbindung mit dem Server herstellen. Nach dem Schlüsselwort domain sollte der Domainteil des voll qualifizierten Domainnamens des Host angegeben werden. Eine ganze Reihe von Programmen muß einen Look-up auf den voll qualifizierten Domainnamen Ihres Host durchführen; wenn Ihre Resolver-Bibliothek nur den nichtqualifizierten Hostnamen zurückliefert, wird das domain-Attribut angeheftet. Es ist kein Problem, es auf beide Arten zu implementieren; am besten ist es, domain zu definieren. Die nächste Zeile definiert, welchen Hostnamen inews benutzt, wenn es Artikel, die von lokalen Benutzern gepostet wurden, um eine From:-Zeile erweitert. Die meisten Newsreader benutzen das From:-Feld, wenn sie eine Antwort-Mail-Nachricht an den Verfasser eines Artikels schreiben. Wenn Sie dieses Feld auslassen, wird standardmäßig der voll qualifizierte Domainname Ihres News-Host verwendet. Das ist jedoch nicht immer die beste Wahl. Sie könnten zum Beispiel News und Mails von zwei verschiedenen Hosts verwalten lassen. In diesem Fall würden Sie nach der fromhost-Anweisung den voll qualifizierten Domainnamen Ihres Mail-Host angeben. Die Zeile pathhost definiert den Hostnamen, den INN dem Path:-Header-Feld hinzufügt, wenn es einen Artikel empfängt. In den meisten Fällen werden Sie hier den voll qualifizierten Domainnamen Ihrers News-Servers benutzen wollen; dann können Sie dieses Feld auslassen, da das sowieso die Standardvorgabe ist. Wenn Sie eine große Domain bedienen, möchten Sie vielleicht gelegentlich einen allgemeinen Namen benutzen, wie news.vbrew.com. Auf diese Weise können Sie Ihr NewsSystem leicht auf einen anderen Host verlegen, wenn Sie das irgendwann mal vorhaben sollten. Die nächste Zeile enthält das Schlüsselwort organization. Mit dieser Anweisung können Sie konfigurieren, welchen Text inews in die Zeile Organization: derjenigen Artikel schreibt, die von Ihren lokalen Benutzern gepostet werden. Hier geben Sie eine förmliche Beschreibung oder den vollen Namen Ihrer Organisation an. Sollten Sie nicht so förmlich sein wollen: Moderne Organisationen mit Sinn für Humor haben hier Gelegenheit, das unter Beweis zu stellen. Das Schlüsselwort organization ist unbedingt erforderlich und gibt den Pfadnamen des Mail-Transport-Agenten an, der zum Posten von Moderatornachrichten benutzt wird. %s wird durch die E-Mail-Adresse des Moderators ersetzt. Der Eintrag moderatormailer definiert eine Standardadresse, die benutzt wird, wenn ein Anwender an eine moderierte Newsgruppeposten will. Die Liste der Moderatoradressen für jede Newsgruppe wird für gewöhnlich in einer separaten Datei gehalten; wenn Sie über alle den Überblick behalten wollen, stehen Ihnen allerdings schwere Zeiten bevor. Als letzter Ausweg ist daher der Eintrag moderatormailer gedacht; wenn er definiert ist, ersetzt inews den String %s durch den (leicht veränderten) Namen der Newsgruppe und sendet den ganzen Artikel an diese Adresse. Wenn man zum Beispiel an soc.feminism postet, wird bei obiger Konfiguration der Artikel per Mail an [email protected] gesendet. Bei UUNET sollte für jede dieser Submission-Adressen ein Mail-Alias installiert sein, der automatisch alle Nachrichten an den passenden Moderator weiter-leitet. Die restlichen Einträge geben schließlich die Pfade einiger zu INN gehöriger Komponentendateien oder ausführbarer Dateien an. Wenn Sie INN aus einem vorgefertigten Paket installiert haben, sollten diese Pfade bereits für Sie konfiguriert sein. Wenn Sie INN dagegen aus dem Quellcode heraus installieren, müssen Sie sicherstellen, daß die Einträge die Pfade aufweisen, wo Sie INN installiert haben.

Konfiguration der Newsgruppen Der News-Administrator eines Systems kann kontrollieren, auf welche Newsgruppen Anwender zugreifen dürfen. INN stellt zwei Konfigurationsdateien zur Verfügung, die dem Administrator die Entscheidung erlauben, welche Newsgruppen unterstützt werden sollen, und die Beschreibungen für sie anbieten. Die Dateien active und newsgroups

Die Dateien active und newsgroups dienen zur Speicherung und Beschreibung der Newsgruppen, die auf diesem News-Server gehostet werden. Sie enthalten Angaben, für welche Newsgruppen wir Artikel senden und empfangen wollen, sowie administrative Informationen über sie. Diese Dateien befinden sich im Verzeichnis /var/lib/news/. Die active-Datei bestimmt, welche Newsgruppen dieser Server unterstützt. Ihre Syntax ist eindeutig. Jede Zeile in der activeDatei enthält vier Felder, die durch Leerzeichen unterteilt sind: name obergrenze untergrenze optionen

Das Feld name ist der Name der Newsgruppe. Das obergrenze-Feld ist die größte Nummer, die für einen Artikel in dieser Newsgruppe verwendet wurde. Das untergrenze-Feld ist die niedrigste aktive Nummer, die in der Newsgruppe verwendet wird. Um zu zeigen, wie dies funktioniert, stellen Sie sich folgendes Szenario vor: Stellen Sie sich vor, wir hätten eine neu erzeugte Newsgruppe. obergrenze und untergrenze sind jeweils 0, da es noch keine Artikel gibt. Wenn wir fünf Artikel posten, werden sie von 1 bis 5 durchnumeriert. obergrenze hat nun den Wert 5, die höchste Artikelnummer, während untergrenze die kleinste Artikelnummer, also den Wert 1 hat. Wenn Artikel 5 annulliert wird, bleiben diese Werte unverändert. obergrenze bleibt weiterhin auf 5 gesetzt, um sicherzustellen, daß diese Artikelnummer nicht wieder benutzt wird. untergrenze bleibt weiterhin die niedrigste aktive Artikelnummer, also 1. Wenn wir nun Artikel 1 annullieren, bleibt obergrenze unverändert, nicht jedoch untergrenze, das nun auf 2 gesetzt wird, da Artikel 1 nicht mehr aktiv ist. Wenn wir nun einen neuen Artikel posten, erhält er die Artikelnummer 6, so daß obergrenze nun ebenfalls den Wert 6 hat. Artikel 5 war ja bereits benutzt worden, so daß diese Nummer nicht wiederverwendet wird. untergrenze bleibt weiterhin 2. Dieses Verfahren macht es uns leicht, neuen Artikeln eindeutige aktive Nummern zuzuordnen und abzuschätzen, wie viele aktive Artikel in der Gruppe vorhanden sind: obergrenze–untergrenze. Das Feld kann einen der folgenden Einträge enthalten: y Direktes Posten an diesen News-Server ist erlaubt. n Direktes Posten an diesen News-Server ist nicht erlaubt. Dies verhindert, daß Newsreader direkt an diesen News-Server posten. Neue Artikel dürfen nur von anderen News-Servern empfangen werden. m Die Gruppe ist moderiert. Alle an diese Newsgruppe geposteten Artikel werden an den Moderator der Newsgruppe weitergeleitet und von ihm genehmigt, bevor sie Zutritt zur Newsgruppe bekommen. Die meisten Newsgruppen werden nicht moderiert. j Artikel für diese Gruppe werden nicht gespeichert, sondern nur weitergeleitet. Das bewirkt, daß der News-Server zwar Artikel annimmt, mit ihnen aber nichts anderes macht, als sie an die up-stream-News-Server weiterzuleiten. Er stellt diese Artikel nicht den Newsreadern zur Verfügung, die von diesem Server lesen. x Artikel können nicht in diese Newsgruppe gepostet werden. Der einzige Weg, News-Artikel an diesen Server auszuliefern, besteht darin, sie per Feeding von einem anderen News-Server zu bekommen. Newsreader dürfen nicht direkt Artikel auf diesen Server schreiben. =foo.bar Artikel werden lokal in die “foo.bar”-Gruppe übertragen.

In unserer simplen Serverkonfiguration betreiben wir nur eine kleine Anzahl von Newsgruppen, so daß unsere /var/lib/news/active-Datei etwa so aussieht: control 0000000000 0000000001 y junk 0000000000 0000000001 y rec.crafts.brewing 0000000000 0000000001 y rec.crafts.brewing.ales 0000000000 0000000001 y rec.crafts.brewing.badtaste 0000000000 0000000001 y rec.crafts.brewing.brandy 0000000000 0000000001 y rec.crafts.brewing.champagne 0000000000 0000000001 y rec.crafts.brewing.private 0000000000 0000000001 y

Die Nummern obergrenze und untergrenze in diesem Beispiel sind diejenigen, die Sie bei der Erzeugung neuer Newsgruppen benutzen würden. Bei einer Newsgruppe, die schon einige Zeit aktiv ist, sehen diese beiden Werte natürlich ganz anders aus. Die Datei newsgroups ist noch einfacher. Sie enthält einzeilige Beschreibungen von Newsgruppen. Manche Newsreader können diese Informationen lesen und den Anwendern präsentieren, um ihnen bei der Entscheidung, ob sie die Newsgruppen abonnieren wollen, behilflich zu sein. Das Format der newsgroups-Datei ist einfach: name beschreibung

Das name-Feld ist der Name der Newsgruppe, und das Feld beschreibung enthält eine einzeilige Beschreibung dieser Newsgruppe. Wir wollen nun die Newsgruppen beschreiben, die unser Server unterstützt, daher bilden wir unsere newsgroups-Datei wie folgt: rec.crafts.brewing.ales Brauerei für dunkles und helles Bier rec.crafts.brewing.badtaste Brauerei für stinkendes Gebräu rec.crafts.brewing.brandy Brauerei unseres Weinbrands rec.crafts.brewing.champagne Brauerei unseres eigenen Champagners rec.crafts.brewing.private Brauereigruppe der virtuellen Brauerei

Konfiguration von Newsfeeds INN gibt dem News-Administrator die Kontrolle darüber, welche Newsgruppen an andere News-Server weitergeleitet werden und wie das geschieht. Die gängigste Methode verwendet das (bereits beschriebene) NNTP-Protokoll, aber INN gestattet auch Newsfeeds über andere Protokolle, wie z.B. UUCP. Die Datei newsfeeds Die newsfeeds-Datei bestimmt, wohin News-Artikel gesendet werden. Normalerweise befindet sie sich im Verzeichnis /etc/news/. Das Format der newsfeeds-Datei sieht auf den ersten Blick etwas kompliziert aus. Wir beschreiben hier das allgemeine Layout, und die Details, die wir auslassen, beschreibt die Manpage newsfeeds(5). Das Format ist wie folgt: # Dateiformat von newsfeeds system:muster:optionen:param system2:muster2\

:optionen2:param2

Jeder Newsfeed zu einem System wird über eine einzelne Zeile beschrieben oder über mehrere Zeilen, wenn das Fortsetzungszeichen \ benutzt wird. Die Doppelpunkte dienen als Trennzeichen zwischen den Feldern einer Zeile. Das Doppelkreuz # am Zeilenanfang kennzeichnet die Zeile als Kommentar. Die system-Feldnamen benennen das System, auf das sich diese Beschreibung bezieht. Der Systemname kann nach Belieben gewählt werden und braucht kein Domainname des Systems zu sein. Der Systemname wird später benutzt und verweist auf einen Eintrag in einer Tabelle, die den Hostnamen an das innxmit-Programm liefert, das die News-Artikel mittels NNTP an den Remote-Server überträgt. Für jedes System können Sie mehrere Einträge angeben; jeder Eintrag wird dann individuell behandelt.

Das muster-Feld gibt an, welche Newsgruppen an dieses System gesendet werden sollen. Nach Standardvorgabe werden alle Gruppen gesendet. Wenn es das ist, was Sie wollen, lassen Sie dieses Feld einfach leer. Normalerweise besteht dieses Feld aus einer mittels Kommata unterteilten Liste von Suchmuster-Ausdrücken. Das Zeichen * prüft auf keine oder mehr Zeichen, das Ausrufezeichen (falls am Anfang eines Ausdrucks benutzt) führt ein logisches NICHT durch, und das Zeichen @ am Anfang eines Newsgruppen-Namens bedeutet: “Leite keine Artikel weiter, die an diese Gruppe (cross-) gepostet wurden.” Punkte haben keine spezielle Bedeutung. Die Liste wird von links nach rechts analysiert; Sie sollten daher sicherstellen, daß die spezifischeren Regeln zuerst aufgeführt werden. Das Muster rec.crafts.brewing*,!rec.crafts.brewing.poison,@rec.crafts.brewing.private

würde die gesamte News-Hierarchie von rec.crafts.brewing außer rec.crafts.brewing.poison senden. Es würde keine Artikel zuführen, die an die rec.crafts.brewing.private-Newsgruppe (cross-)gepostet wurden. Diese Artikel würden abgefangen und stünden nur den Benutzern dieses Servers zur Verfügung. Wenn Sie die ersten beiden Muster vertauschen, wird das erste Muster vom zweiten überschrieben, was schließlich dazu führen würde, daß Sie Artikel für die Newsgruppe rec.crafts.brewing.poison zuführen würden. Dasselbe gilt für das erste und letzte Muster. Sie müssen grundsätzlich die spezifischeren Muster vor die weniger spezifischen Muster plazieren, damit alle Musterwirksam werden. optionen kontrolliert und plaziert Beschränkungen für die Zuführung von News-Artikeln an dieses System. Dieses Feld enthält eine mittels Kommata unterteilte Liste, die beliebige Einträge der folgenden Liste enthält:
Newsfeed-Typen: f (Datei), m (Trichter; das param-Feld bezeichnet den Eintrag, an den Artikel getrichtert werden), p (Pipe zu Programm), c (senden an Standardeingabe-Kanal des Subprozesses des param-Felds) und x (wie c, aber verarbeitet Befehle in Standardeingabe). Wbegriffe Was anzugeben ist: b (Artikelgröße in Bytes), f (voller Pfad), g (erste Newsgruppe), m (Message-ID), n (relativer Pfad), s (System, das Artikel zuführt), t (empfangene Zeit), * (Namen von Zuführungen über Trichter oder allen Systemen, die den Artikel bekommen), N (Header von Newsgruppen), D (Header von Verteilern), H (alle Header), O (Übersichtsdaten) sowie R (Replikationsdaten). Das param-Feld hat ein spezielles Format, das abhängig von der Art des Feeds ist. In der gängigsten Konfiguration ist es die Stelle, wo Sie den Namen der Ausgabedatei spezifizieren, in die Sie den ausgehenden Feed schreiben. In anderen Konfigurationen können Sie dies auslassen. In wieder anderen Konfigurationen hat es verschiedene Bedeutungen. Wenn Sie etwas Außergewöhnliches vorhaben, erklärt Ihnen die Manpage newsfeeds(5) die Anwendung des param-Felds ziemlich ausführlich. Es gibt einen speziellen Systemnamen, der als ME codiert und als erster Eintrag in der Datei erscheinen sollte. Dieser Eintrag wird benutzt, um die Standardeinstellungen für Ihren Newsfeed zu steuern. Wurde dem ME-Eintrag eine Verteilerliste zugeordnet, wird diese Liste jedem der anderen Systemeinträge vorangestellt, bevor sie versendet werden. Das gestattet Ihnen beispielsweise, einige Newsgruppen für automatische Feeds zu deklarieren oder sie automatischvon Feeds auszusperren, ohne dafür das Muster in jedem Systemeintrag wiederholen zu müssen. Wir erwähnten bereits früher, daß es möglich war, einige spezielle Feeds zu benutzen, um Thread-Daten zu erzeugen, die dem Newsreader die Arbeit leichter machen. Dies erreichen wir, indem wir den Befehl overchan, der zur INN-Distribution gehört, gebrauchen. Dazu haben wir einen speziellen lokalen Feed namens overview erzeugt, der die Newsartikel an den overchanBefehl übergibt, um sie zu Übersichtsdaten zu verarbeiten. Unser News-Server stellt nur einen externen Newsfeed zur Verfügung, der zur Groucho-Marx-Universität geht, und sie empfangen Artikel für alle Newsgruppen außer für -control, junk, rec.crafts.brewing.private (wird lokal gehalten) sowie rec.crafts.brewing.poison, von der wir nicht wollen, daß Leute aus unserer Brauerei dorthin posten. Wir benutzen den nntpsend-Befehl, um die News per NNTP an den Server news. -groucho.edu zu übertragen. nntpsend verlangt von uns, daß wir die “Datei”-Auslieferungsmethode verwenden und den Pfadnamen sowie die Artikel-ID angeben. Beachten Sie, daß wir das param-Feld auf den Namen der Ausgabedatei gesetzt haben. Wir reden später noch ein wenig mehr über den nntpsend-Befehl. Unsere resultierende Newsfeed-Konfiguration sieht wie folgt aus: # /etc/news/newsfeeds-Datei für die virtuelle Brauerei # # Sende standardmäßig alle Newsgruppen außer control und junk ME:!control,!junk:: # # Erzeuge Übersichtsdaten für jeden zu verwendenden Newsreader overview::Tc,WO:/usr/lib/news/bin/overchan # # Liefere der Groucho-Marx-Universität alles außer unsere private Newsgruppe # und alle Artikel, die an die Newsgruppe rec.crafts.brewing.poison # gepostet werden gmarxu:!rec.crafts.brewing.poison,@rec.crafts.brewing.private:\ Tf,Wnm:news.groucho.edu #

Die Datei nntpsend.ctl Das nntpsend-Programm verwaltet die Übertragung von News-Artikeln mittels NNTP-Protokoll durch Aufruf des Befehls innxmit. Wir sahen bereits früher eine einfache Anwendung des nntpsend-Befehls, es hat jedoch auch eine Konfigurationsdatei, was uns etwas Flexibilität gibt, wie wir unsere Newsfeeds konfigurieren. Der nntpsend-Befehl erwartet Batch-Dateien für die Systeme, denen er zuliefern wird. Er erwartet, daß diese Batch-Dateien den Namen /var/spool/news/out.going/systemname haben. innd erzeugt diese Batch-Dateien bei der Bearbeitung eines Eintrags in der newsfeeds-Datei, die wir bereits in den vorangegangenen Abschnitten gesehen haben. Wir gaben den Systemnamen als Dateiname im param-Feld an, was den Eingabe-Anforderungen des nntpsend-Befehls gerecht wird. Der nntpsend-Befehl hat eine Konfigurationsdatei namens nntpsend.ctl, die für ge-wöhnlich im Verzeichnis /etc/news/ gespeichert ist.

Die nntpsend.ctl-Datei gestattet uns, einen voll qualifizierten Domainnamen, einige Newsfeed-Größenbeschränkungen sowie eine Anzahl von Übertragungsparametern mit dem Systemnamen eines Newsfeeds zu verbinden. Der Systemname dient der eindeutigen Identifizierung eines logischen Feeds von Artikeln. Das allgemeine Format der Datei ist: systemname:fqdn:max_groesse:[args]

Die folgende Liste beschreibt die Elemente dieses Formats: systemname Der Systemname, wie er in der newsfeeds-Datei übergeben wird. fqdn Der voll qualifizierte Domainname des News-Servers, an den wir die News-Artikel senden. max_groesse Der maximale Umfang an News, die in jeder einzelnen Übertragung gesendet werden. args Zusätzliche Argumente für den innxmit-Befehl. Unsere Beispielkonfiguration benötigt nur eine sehr einfache nntpsend.ctl-Datei. Wir haben nur einen Newsfeed, und den beschränken wir auf maximal 2 MByte. Außerdem übergeben wir dem innxmit-Befehl ein Argument, das einen dreiminütigen Timeout (180 Sekunden) festlegt. Wenn wir ein größeres System und viele Newsfeeds hätten, würden wir einfach für jedes neue Newsfeed-System neue Einträge erzeugen, die in etwa wie folgt aussehen: # /etc/news/nntpsend.ctl # gmarxu:news.groucho.edu:2m:-t 180 #

Zugriffskontrolle des Newsreaders Vor nicht allzu vielen Jahren war es für Organisationen üblich, öffentliche Zugriffe auf ihre News-Server anzubieten. Heutzutage ist es weitaus schwieriger, überhaupt noch öffentliche News-Server zu finden. Die meisten Organisationen kontrollieren sorgfältig, wer Zugriff auf ihre Server hat, und normalerweise beschränken sie den Zugriff auf Anwender, die von ihrem Netzwerk unterstützt werden. INN stellt Konfigurationsdateien zur Verfügung, mit denen dieser Zugriff gesteuert werden kann. Die Datei incoming.conf In unserer Einführung in INN erwähnten wir, daß es seine Effizienz und Größe zum Teil der Trennung des NewsfeedMechanismus vom Newsreading-Mechanismus verdankt. In der /etc/news/incoming.conf-Datei geben Sie an, welche Hosts Ihnen per NNTP-Protokoll News zuführen. Dort definieren Sie auch einige Parameter, die steuern, wie Ihnen Artikel von diesen Hosts zugeführt werden. Jeder nicht in dieser Datei aufgeführte Host, der mit dem News-Socket Verbindung aufnimmt, wird nicht vom innd-Dämon behandelt, sondern vom nnrpd-Dämon. Die Syntax der Datei /etc/news/incoming.conf ist sehr einfach, auch wenn man sich erst ein wenig daran gewöhnen muß. Drei Arten zulässiger Einträge sind erlaubt: Schlüssel/Wert-Paare, mit denen Sie Attribute und ihre Werte spezifizieren; Gegenstellen (Peers), mit denen Sie den Namen eines Hosts spezifizieren, der uns Artikel per NNTP senden darf; und Gruppen zur Anwendung von Schlüssel/Wert-Paaren auf Gruppen von Peers. Schlüssel/Wert-Paare können drei verschiedene Arten von Gültigkeitsbereichen haben. Globale Paare betreffen jede in der Datei definierte Gegenstelle. Paare von Gruppen betreffen alle in dieser Gruppe definierten Peers. Paare eines Peers betreffen nur diesen einen Peer. Spezifische Definitionen überschreiben weniger spezifische; daher überschreiben Peer-Definitionen die Gruppen-Definitionen, die wiederum globale Paare

überschreiben. Anfang und Ende der group- und peer-Spezifikationen werden mit geschweiften Klammern ({}) abgegrenzt. Ein Doppelkreuz (#) in einer Zeile markiert den Rest der Zeile als Kommentar. Schlüssel/Wert-Paare werden mittels Doppelpunkt unterteilt und in jeweils einer Zeile angegeben. Mehrere verschiedene Schlüssel können spezifiziert werden. Die geläufigeren und nützlichen sind: hostname Spezifiziert eine mittels Kommata unterteilte Liste aus voll qualifizierten Domainnamen oder IP-Adressen der Gegenstellen, denen wir das Senden von Artikeln zu uns erlauben. Wenn dieses Schlüsselwort nicht angegeben ist, wird für den Hostnamen die Bezeichnung der Gegenstelle genommen. streaming Bestimmt, ob Streaming-Befehle von diesem Host erlaubt sind. Dies ist ein Boolescher Wert mit dem Standardvorgabewert true. max-connections Spezifiziert die maximale Anzahl der Verbindungen, die von dieser Gruppe oder Gegenstelle erlaubt sind. Null bedeutet unbegrenzt (was auch mittels none angegeben werden kann). password Erlaubt die Angabe des Paßwortes, das von einer Gegenstelle verwendet werden muß, wenn ihr die Übertragung von News gestattet werden soll. Die Standardvorgabe ist, kein Paßwort zu verlangen. patterns Spezifiziert die Newsgruppen, die wir von der zugehörigen Gegenstelle akzeptieren. Dieses Feld ist exakt nach denselben Regeln codiert, die wir in unserer newsfeeds-Datei verwendet haben. In unserem Beispiel haben wir nur einen Host, von dem wir News erwarten: unseren Upstream-News-Provider an der GrouchoMarx-Universität. Wir benutzen zwar kein Paßwort, stellen aber sicher, daß wir keine Artikel für unsere private Newsgruppe von außerhalb erhalten. Unsere Datei hosts.nntp sieht daher folgendermaßen aus: # Datei incoming.conf der virtuellen Brauerei # Globale Einstellungen streaming: true maxconnections: 5 # Erlaube NNTP-Posting von unserem lokalen Host. peer ME { hostname: "localhost, 127.0.0.1" } # Erlaube groucho das Senden aller Newsgruppen außer unseren lokalen. peer groucho { hostname: news.groucho.edu patterns: !rec.crafts.brewing.private }

Die Datei nnrp.access Wir erwähnten bereits, daß Newsreader und in der Tat alle nicht in der hosts.nntp-Datei aufgeführten Hosts, die mit dem INNNews-Server eine Verbindung herstellen, vom nnrpd-Programm verarbeitet werden. nnrpd benutzt die Datei /etc/news/nnrp.access, um festzulegen, wer vom News-Server Gebrauch machen darf und welche Zugriffsrechte sie haben sollen. Die nnrp.access-Datei hat eine ähnliche Struktur wie die anderen Konfigurationsdateien, die wir schon betrachtet haben. Sie besteht aus einer Menge von Mustern, die zur Überprüfung des Domainnamens oder der IP-Adresse des verbundenen Hosts verwendet werden, und aus Feldern, die bestimmen, welche Zugriffsrechte dem Host gegeben werden sollen. Jeder Eintrag sollte jeweils in einer einzelnen Zeile erscheinen, und die Felder werden durch Doppelpunkte getrennt. Der letzte Eintrag in dieser Datei, der zum verbundenen Host paßt, ist derjenige, der schließlich benutzt wird. Sie sollten daher wiederum allgemeine Muster immer zuerst und die spezifischeren Muster erst danach aufführen. Die fünf Felder jedes Eintrags sollten in

folgender Reihenfolge angegeben werden: Hostname oder IP-Adresse Dieses Feld ist konform zu den Mustererkennungs-Regeln von wildmat(3) und gibt den Namen oder die IP-Adresse des verbundenen Hosts an. Zugriffsrechte Bestimmt, welche Zugriffsrechte dem passenden Host gewährt werden sollen. Sie können hier zwei Zugriffsrechte konfigurieren: R für Leserecht und P für das Recht zum Posten. Benutzername Dieses Feld ist optional und gestattet Ihnen die Spezifikation eines Benutzernamens, unter dem sich ein NNTP-Client beim Server anmelden muß, bevor er überhaupt News posten darf. Das Feld kann auch leer bleiben. Zum Lesen von Artikeln ist keine Benutzerauthentifizierung erforderlich. Paßwort Dieses Feld ist optional und enthält das Paßwort für das username-Feld. Ist es leer, können Artikel auch ohne Paßwort gepostet werden. Newsgruppen Ein Muster, das angibt, auf welche Newsgruppen der Client zugreifen darf. Für die Muster gelten dieselben Regeln wie bei der newsfeeds-Datei. Standardvorgabe ist keine Newsgruppe, daher würden Sie hier normalerweise ein Muster konfigurieren. Im Beispiel der virtuellen Brauerei erlauben wir jedem NNTP-Client in dieser Domain sowohl das Lesen von allen Newsgruppen als auch das Posten in alle Newsgruppen. Wir gestatten allen NNTP-Clients nur Lesezugriffe auf alle Newsgruppen, mit Ausnahme unserer privaten internen Newsgruppe. Unsere nnrp.access sieht etwa so aus: # Virtuelle Brauerei - nnrp.access # Wir gestatten öffentliche Lesezugriffe auf alle Newsgruppen # mit Ausnahme unserer privaten Gruppe. *:R:::*,!rec.crafts.brewing.private # Alle Hosts der virtuellen Brauerei-Domain dürfen von allen # Newsgruppen lesen und in alle Newsgruppen posten *.vbrew.com:RP::*

News-Artikel löschen Werden News-Artikel vom News-Server empfangen, werden sie auf Platte gespeichert. Damit sie überhaupt erst ihren Zweck erfüllen, müssen die News-Artikel den Anwendern eine Weile zur Verfügung stehen. Ein großer News-Server kann daher sehr viel Plattenplatz benötigen. Um sicherzustellen, daß der Plattenplatz effizient genutzt wird, können Sie sich dafür entscheiden, News-Artikel nach einer gewissen Zeit automatisch zu löschen. Dieses automatische Löschen veralteter Artikel wird im Englischen als Article Expiration bezeichnet. INN stellt normalerweise ein solches Verfahren zur Verfügung. Die Datei expire.ctl Der INN-Server verwendet ein Programm namens expire, um veraltete News-Artikel zu löschen. expire wiederum verwendet eine Datei namens /etc/news/expire.ctl, um die Regeln zu konfigurieren, die das Löschen der Artikel steuern. Die Syntax von /etc/news/expire.ctl ist recht einfach. Wie bei den meisten Konfigurationsdateien werden leere Zeilen oder solche, die mit einem Doppelkreuz (#) beginnen, ignoriert. Die allgemeine Regel ist, daß Sie jeweils eine Regel pro Zeile konfigurieren. Jede Regel definiert, wie das Löschen von Artikeln bei Newsgruppen vor sich geht, die zu einem gegebenen Muster passen. Die Regelsyntax sieht folgendermaßen aus:

muster:modopt:mindauer:normdauer:maxdauer

Die nachfolgende Liste beschreibt die Felder: muster Eine durch Kommata unterteilte Liste von Mustern, die zu Namen von Newsgruppen passen. Zum Mustervergleich wird die Routine wildmat(3) verwendet. Die letzte Regel, die zum Namen einer Newsgruppe paßt, wird angewendet. Wenn Sie also Wildcard-Regeln (*) spezifizieren wollen, sollten sie in dieser Datei an erster Stelle aufgeführt werden. modopt Beschreibt, wie diese Regel auf moderierte Newsgruppen angewendet wird. Dieses Flag kann mit einem M codiert sein, damit diese Regel nur für moderierte Newsgruppen gilt, mit einem U, damit die Regel nur für nicht moderierte Newsgruppen gilt, oder mit einem A, um den Moderationszustand zu ignorieren und die Regel auf alle Newsgruppen anzuwenden. mindauer In diesem Feld können Sie die Mindestdauer angeben, die ein Artikel mit einem “Expires”-Header aufbewahrt wird, bevor er verfällt und gelöscht wird. Die Einheit besteht aus Tagen und wird als Fließkommazahl angegeben, z.B. 7.5 für siebeneinhalb Tage. Sie können hier aber auch never angeben, wenn der Artikel für immer in einer Newsgruppe verbleiben soll. normdauer Dieses Feld ist das wichtigste. Es erlaubt Ihnen die Angabe einer Zeitdauer, die ein Artikel ohne Expires-Header aufbewahrt wird. Die meisten Artikel haben keinen Expires-Header. Dieses Feld wird auf die gleiche Weise codiert wie das mindauer-Feld, wobei never bedeutet, daß Artikel ohne Expires-Header nie verfallen. maxdauer Dieses Feld erlaubt Ihnen die Angabe der maximalen Zeitdauer, die ein Artikel mit einem Expires-Header aufbewahrt wird, bevor er verfällt und gelöscht wird. Die Codierung dieses Feldes ist die gleiche wie beim mindauerFeld. Unsere Anforderungen sind einfach. Wir behalten alle Artikel aller Newsgruppen standardmäßig für 14 Tage. Artikel, die einen Expires-Header aufweisen, werden zwischen sieben und 21 Tagen aufbewahrt. Die Newsgruppe rec.crafts.brewing.private ist unsere interne Newsgruppe, weshalb wir sicherstellen wollen, daß darin keine Artikel verfallen: # expire.ctl-Datei für die virtuelle Brauerei # Lösche alle Artikel standardmäßig nach 14 Tagen; # Artikel mit Expires-Header sollen nach 7 bis 21 Tagen verfallen. *:A:7:14:21 # Spezielle interne Newsgruppe, deren Artikel nie verfallen. rec.crafts.brewing.private:A:never:never:never

In Ihrer /etc/news/expires.ctl-Datei können Sie noch eine einzelne Zeile angeben, die exakt folgendes Format hat: /remember/:tage

In diesem Eintrag legen Sie die minimale Anzahl von Tagen fest, die ein Artikel in der History-Datei vermerkt wird, unabhängig davon, ob der Artikel schon verfallen ist oder nicht. Das kann nützlich sein, wenn irgendein System Ihnen nur in unregelmäßigen Abständen Artikel zusendet und die lästige Angewohnheit hat, Sie hin und wieder mit alten Artikeln abzuspeisen. Das Setzen des /remember/-Felds hindert den Upstream-Server daran, Ihnen einen alten Artikel nochmals zu senden, auch wenn er bereits von Ihrem Server gelöscht wurde. Wenn sich Ihr Server daran erinnert, daß er den Artikel bereits bekommen hat, wird er neuere Versuche, den Artikel wiederholt zu senden, ablehnen. Es ist wichtig, daran zu erinnern, daß diese Einstellung überhaupt keinen Einfluß auf die Verweildauer der Artikel hat, sondern sie betrifft ausschließlich die Zeitdauer, über die Informationen über einen Artikel in der History-Datei aufbewahrt werden.

Verarbeitung von Steuernachrichten Wie C News kann auch INN automatisch Steuernachrichten verarbeiten. INN bietet einen mächtigen Konfigurationsmechanismus, mit dem gesteuert werden kann, welche Aktionen für die verschiedenen Arten von Steuernachrichten ausgeführt werden sollen, sowie einen Zugriffskontrollmechanismus, mit dem gesteuert werden kann, wer Aktionen gegen welche Newsgruppen auslösen kann. Die Datei control.ctl Die control.ctl-Datei ist recht einfach strukturiert. Die Syntaxregeln dafür sind weitgehend dieselben wie bei den anderen INNKonfigurationsdateien. Zeilen, die mit # beginnen, werden ignoriert; Zeilen können mittels / fortgesetzt werden, und Felder werden durch : unterteilt. Wird eine Steuernachricht empfangen, wird sie der Reihe nach gegen jede Regel getestet. Die letzte Regel, die zur Nachricht paßt, wird verwendet, so daß Sie alle allgemeinen Regeln an den Anfang der Datei und die spezifischeren Regeln an das Ende der Datei setzen sollten. Die allgemeine Syntax der Datei ist: nachricht:von:newsgruppen:aktion

Die Bedeutung dieser Felder sehen Sie im folgenden: nachricht Der Name der Steuernachricht. Typische Steuernachrichten werden später beschrieben. von Ein Muster im Shell-Stil, das zur E-Mail-Adresse der Person paßt, die die Nachricht sendet. Vor dem Mustervergleich wird die E-Mail-Adresse in Kleinbuchstaben umgewandelt. newsgruppen Falls die Steuernachricht newgroup oder rmgroup lautet, enthält dieses Feld ein Shell-typisches Muster, das zur erzeugten oder gelöschten Newsgruppe paßt. aktion Gibt an, welche Aktion für jede Nachricht ausgelöst wird, die zur Regel paßt. Es gibt eine ganze Reihe von Aktionen, die wir nehmen können; sie werden in der nächsten Liste beschrieben. Das nachricht-Feld jeder Zeile kann einen der folgenden Werte haben: checkgroups Fordert die News-Administratoren auf,die Datenbank ihrer aktiven Newsgruppen gegen die in der Steuernachricht übergebene Liste von Newsgruppen zu resynchronisieren. newgroup Fordert zur Erzeugung einer neuen Newsgruppe auf. Der Inhalt der Steuernachricht sollte eine Kurzbeschreibung des Zwecks der neuen Newsgruppe sein. rmgroup

Fordert zum Löschen einer Newsgruppe auf. sendsys Fordert dazu auf, die sys-Datei dieses News-Servers per Mail an den Absender der Steuernachricht zu übertragen. Nach RFC-1036 erfordert eine Usenet-Mitgliedschaft, daß diese Information öffentlich verfügbar ist, da sie dazu verwendet wird, die Usenet-Map auf dem laufenden zu halten. version Fordert auf, den Hostnamen und die Version der News-Server-Software an den Absender der Steuernachricht zurückzuliefern. all Ein spezielles Codewort, das für alle Steuernachrichten paßt. Das nachricht-Feld kann die folgenden Aktionen enthalten: doit Der angeforderte Befehl wird ausgeführt. In vielen Fällen wird eine Mail-Nachricht andie Administratoren gesendet, um sie über die Durchführung der Aktion zu unterrichten. doit=datei Wie doit, wobei zusätzlich eine Lognachricht in die Logdatei datei geschrieben wird. Ist mail als Datei angegeben, wird der Logeintrag per E-Mail versandt. Ist die angegebene Datei dagegen ein Nullstring, wird die Lognachricht an das Gerät /dev/null geschrieben, und die Aktion entspricht somit dem nichtqualifizierten doit. Beginnt der dateiName mit einem Schrägstrich, beschreibt er einen absoluten Pfadnamen für die Logdatei; ansonsten wird der angegebene Name übersetzt zu /var/log/news/datei.log. doifarg Der verlangte Befehl wird nur ausgeführt, falls er ein Argument hat. Andernfalls wird die Steuernachricht ignoriert. drop Der verlangte Befehl wird ignoriert. log Eine Lognachricht wird an die stderr-Ausgabe des innd-Prozesses gesendet. Sie wird normalerweise in die Datei /var/log/news/errlog geleitet. log=datei Wie bei einer log-Aktion, wobei die Logdateinach denfür die doit=datei-Aktion festgelegten Regeln spezifiziert ist. mail An den News-Administrator wird eine E-Mail-Nachricht mit Details über den angeforderten Befehl gesendet. Es findet keine weitere Aktion statt.

verify-* Beginnt eine Aktion mit dem String verify-, wird die Steuernachricht mittels PGP (oder GPG) authentifiziert.1 Wie eine control.ctl-Datei in der Praxis aussehen könnte, sehen Sie im folgenden kurzen Beispiel: ## Beispiel /etc/news/control.ctl ## ## Warnung: Diese Datei ist nicht für die Anwendung gedacht, ## sondern dient nur zur Veranschaulichung. ## Verarbeitung von Steuernachrichten all:*:*:mail checkgroups:*:*:mail ihave:*:*:drop sendme:*:*:drop sendsys:*:*:log=sendsys senduuname:*:*:log=senduuname version:*:*:log=version newgroup:*:*:mail rmgroup:*:*:mail ## Verarbeitung von Steuernachrichten für die acht wichtigsten News-Hierarchien ## COMP, HUMANITIES, MISC, NEWS, REC, SCI, SOC, TALK checkgroups:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop newgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop rmgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop checkgroups:[email protected]:*:verify-news.announce.newgroups newgroup:[email protected]:comp.*|misc.*|news.*:verify-news.announce.newgroups newgroup:[email protected]:rec.*|sci.*|soc.*:verify-news.announce.newgroups newgroup:[email protected]:talk.*|humanities.*:verify-news.announce.newgroups rmgroup:[email protected]:comp.*|misc.*|news.*:verify-news.announce.newgroups rmgroup:[email protected]:rec.*|sci.*|soc.*:verify-news.announce.newgroups rmgroup:[email protected]:talk.*|humanities.*:verify-news.announce.newgroups ## GNU ( Free Software Foundation ) newgroup:[email protected]:gnu.*:doit newgroup:news@*ai.mit.edu:gnu.*:doit rmgroup:[email protected]:gnu.*:doit rmgroup:news@*ai.mit.edu:gnu.*:doit ## LINUX (Newsfeed von news.lameter.com) checkgroups:[email protected]:linux.*:doit newgroup:[email protected]:linux.*:doit rmgroup:[email protected]:linux.*:doit

1.

PGP und GPG sind Tools, die zur Authentifizierung oder Verschlüsselung von Nachrichten mit öffentlichen Schlüsseltechniken entworfen wurden. GPG ist die freie GNU-Version von PGP. GPG ist erhältlich unter http://www.gnupg.org/, während PGP unter http://www.pgp.com/ erhältlich ist.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Betrieb von INN Das Quellpaket von inn enthält ein Skript, das zum Starten von inn beim Systemstart geeignet ist. Dieses Skript ist für gewöhnlich /usr/lib/news/bin/rc.news. Es liest Argumente von einem anderen Skript, üblicherweise /usr/lib/news/innshellvars, das Definitionen von Dateinamen und Dateipfaden enthält, die inn zur Lokalisierung von benötigten Komponenten verwendet. Generell ist es eine gute Idee, inn nicht mit Systemadministratorrechten auszuführen, sondern zum Beispiel als Benutzer news. Um sicherzustellen, daß inn beim Systemstart auch wirklich gestartet wird, sollten Sie überprüfen, ob /usr/lib/news/innshellvars korrekt konfiguriert ist, und dann das Skript /usr/lib/news/bin/rc.news aus einem Skript heraus starten, das beim Systemstart ausgeführt wird. Außerdem gibt es administrative Aufgaben, die regelmäßig durchgeführt werden müssen. Diese Aufgaben werden für gewöhnlich so konfiguriert, daß sie vom cron-Befehl ausgeführt werden. Der beste Weg besteht darin, die entsprechenden Anweisungen Ihrer /etc/crontab-Datei hinzuzufügen, oder noch besser, eine Datei zu erzeugen, die für das /etc/cron.dVerzeichnis geeignet ist, sofern Ihre Distribution ein solches Verzeichnis anbietet. Ein Beispiel für eine solche Datei könnte wie folgt aussehen: # Beispieldatei /etc/cron.d/inn, wie sie in der Debian-Distribution verwendet wird # SHELL=/bin/sh PATH=/usr/lib/news/bin:/sbin:/bin:/usr/sbin:/usr/bin # Lösche alte News und Übersichtseinträge über Nacht, erzeuge Berichte. 15 0 * * * news news.daily expireover lowmark delayrm # Starte rnews -U stündlich. Das ist nicht nur für UUCP-Systeme, sondern # auch, um aufgelaufene Artikel zu verarbeiten, die dort von inn.nnrpd # abgelegt wurden, sofern innd gerade keine Artikel akzeptierte. 10 * * * * news rnews -U

Diese Befehle stellen sicher, daß alte News automatisch täglich gelöscht werden und daß alle aufgelaufenen Artikel stündlich verarbeitet werden. Beachten Sie, daß sie mit den Zugriffsrechten des Benutzers news ausgeführt werden.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Verwaltung von INN: Der Befehl ctlinnd Der INN-News-Server hat einen Befehl zur Verwaltung seiner täglichen Operationen. Der Befehl ctlinnd kann verwendet werden, um Newsgruppen und Newsfeeds zu bearbeiten, den Zustand des Servers zu ermitteln und ihnzu starten, zu stoppen und neu zu laden. Normalerweise erhalten Sie eine Übersicht der ctlinnd-Befehlssyntax über folgende Anweisung: # ctlinnd -h

Wir behandeln hier nur einige der wichtigeren Anwendungen von ctlinnd. Für weitere Informationen konsultieren Sie bitte die Manpage von ctlinnd.

Newsgruppen hinzufügen Um eine neue Newsgruppe hinzuzufügen, verwenden Sie folgende Syntax: ctlinnd newgroup gruppe rest erzeuger

Die Argumente sind wie folgt definiert:

gruppe Der Name der zu erzeugenden Gruppe. rest Dieses Argument sollte auf dieselbe Weise codiert sein wie das optionen-Feld der activeDatei. Wenn nichts angegeben ist, wird standardmäßig y genommen. erzeuger Der Name der Person, die die Gruppe erzeugt. Setzen Sie ihn in Anführungszeichen, wenn er Leerzeichen enthält.

Newsgruppen ändern Benutzen Sie die folgende Syntax, um eine Gruppe zu ändern: ctlinnd changegroup gruppe rest

Die Argumente sind wie folgt definiert: gruppe Der Name der zu ändernden Gruppe. rest Dieses Argument sollte auf dieselbe Weise codiert sein wie das optionen-Feld der activeDatei. Dieser Befehl ist nützlich, um den Moderationszustand einer Gruppe zu ändern.

Newsgruppen entfernen Verwenden Sie folgende Syntax zur Entfernung einer Gruppe: ctlinnd rmgroup gruppe

Das Argument ist wie folgt definiert: gruppe

Der Name der Gruppe, die entfernt werden soll. Dieser Befehl entfernt die angegebene Newsgruppe aus der active-Datei. Er hat keinen Einfluß auf den News Spool. Alle Artikel im Spool für die angegebene Gruppe verfallen auf normale Weise, es werden jedoch keine neuen Artikel mehr akzeptiert.

Die Numerierung einer Gruppe ändern Um die Numerierung einer Gruppe zu ändern, verwenden Sie folgende Syntax: ctlinnd renumber gruppe

Das Argument ist wie folgt definiert: gruppe Der Name der Gruppe, deren Numerierung geändert werden soll. Ist gruppe ein Leerstring, werden alle Gruppen neu numeriert. Dieser Befehl aktualisiert die Artikel-Untergrenze der angegebenen Gruppe.

Newsreader erlauben / verweigern Benutzen Sie die folgende Syntax, um Newsreader zu erlauben oder zu verweigern: ctlinnd readers option text

Die Argumente sind wie folgt definiert: option Die Angabe n bewirkt, daß alle Newsreader-Verbindungen verweigert werden. Die Angabe y erlaubt Newsreader-Verbindungen. text Der angegebene Text wird an Newsreader übergeben, die eine Verbindung herzustellen versuchen, und beschreibt für gewöhnlich den Grund, warum der Newsreader-Zugriff abgeschaltet wurde. Wenn der Newsreader-Zugriff wieder eingeschaltet wird, muß dieses Feld entweder einen Leerstring enthalten oder eine Kopie des Textes, der beim Abschalten des Newsreaders geliefert wurde. Dieser Befehl hat keinen Einfluß auf ankommende Newsfeeds. Er steuert lediglich die Verbindungen von Newsreadern.

Newsfeed-Verbindungen ablehnen Benutzen Sie die folgende Syntax, um Newsfeed-Verbindungen abzulehnen: ctlinnd reject grund

Das Argument ist wie folgt definiert: grund Der übergebene Text sollte erläutern, warum ankommende Verbindungen zu innd abgelehnt werden. Dieser Befehl betrifft keine Verbindungen, die an nnrpd übergeben wurden (d.h. Newsreader), sondern nur solche, die von innd direkt behandelt würden, wie etwa Remote-Newsfeeds.

Newsfeed-Verbindungen erlauben Benutzen Sie die folgende Syntax, um Newsfeed-Verbindungen zu erlauben: ctlinnd allow grund

Das Argument ist wie folgt definiert: grund Der übergebene Text muß genauso wie beim vorangegangenen reject-Befehl oder ein Leerstring sein. Dieser Befehl kehrt den Effekt einer reject-Anweisung um.

News-Server abschalten Benutzen Sie die folgende Syntax, um den News-Server abzuschalten: ctlinnd throttle grund

Das Argument ist wie folgt definiert: grund Der Grund für das Abschalten des Servers.

Dieser Befehl ist gleichzeitig äquivalent zu einem newsreaders no und einem reject. Er ist nützlich, wenn Notfallarbeiten an der News-Datenbank durchgeführt werden, und stellt sicher, daß niemand versucht, sie zu aktualisieren, solange Sie daran arbeiten.

News-Server neu starten Benutzen Sie die folgende Syntax, um den News-Server neu zu starten: ctlinnd go grund

Das Argument ist wie folgt definiert: grund Der Grund für den Halt des Servers. Ist dieses Feld ein Leerstring, wird der Server bedingungslos neu eingeschaltet. Ist ein Grund angegeben, werden nur diejenigen abgeschalteten Funktionen neu gestartet, deren Grund im Mustervergleich zum übergebenen Text paßt. Dieser Befehl dient zum Neustart einer Serverfunktion nach einer throttle-, pause- oder rejectAnweisung.

Zustand eines Newsfeeds anzeigen Benutzen Sie die folgende Syntax, um den Zustand eines Newsfeeds anzuzeigen: ctlinnd feedinfo system

Das Argument ist wie folgt definiert: system Der Name des Systems (aus der newsfeeds-Datei), für das Sie sich den Zustand des Newsfeeds anzeigen lassen möchten.

Newsfeed streichen Benutzen Sie die folgende Syntax, um einen Newsfeed zu streichen: ctlinnd drop system

Das Argument ist wie folgt definiert:

system Der Name des Systems (aus der newsfeeds-Datei), für das Newsfeeds gestrichen werden. Ist das Feld ein Leerstring, werden alle aktiven Feeds gestrichen. Das Streichen eines Newsfeeds zu einem System führt zum sofortigen Stop aller aktiven Newsfeeds zu diesem System. Das ist keine dauerhafte Änderung. Dieser Befehl wäre nützlich, wenn Sie die Feed-Details für ein System modifiziert haben und ein Feed zu diesem System aktiv ist.

Newsfeed starten Benutzen Sie die folgende Syntax, um einen Newsfeed zu starten: ctlinnd begin system

Das Argument ist wie folgt definiert: system Der Name des Systems (aus der newsfeeds-Datei), für das Newsfeeds gestartet werden. Ist bereits ein Feed zum System aktiv, wird zuerst automatisch ein drop-Befehl abgesetzt. Dieser Befehl bewirkt, daß der Server die newsfeeds-Datei neu einliest, den passenden Eintrag lokalisiert und mit den gefundenen Informationen einen Newsfeed zum genannten System beginnt. Diesen Befehl können Sie dafür verwenden, einen neuen Newsfeed zu einem System zu testen, nachdem Sie seinen Eintrag in der newsfeeds-Datei hinzugefügt bzw. modifiziert haben.

Stornieren eines Artikels Benutzen Sie die folgende Syntax, um einen Artikel zu stornieren: ctlinnd cancel message-id

Das Argument ist wie folgt definiert: message-id Die Message-ID des Artikels, der storniert werden soll. Dieser Befehl bewirkt die Entfernung des angegebenen Artikels vom Server. Er erzeugt keine Abbruchmeldung.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Kapitel 24 Newsreader-Konfiguration

Ein Newsreader ist ein Programm, das Benutzer zum Ansehen, Speichern und Erzeugen von NewsArtikeln aufrufen. Einige Newsreader wurden bereits nach Linux portiert. Wir beschreiben hier die grundlegende Einrichtung der drei meistbenutzten Newsreader: tin, trn und nn. Einer der effektivsten Newsreader ist:

$ find /var/spool/news -name '[0-9]*' -exec cat {} \; | more

Das ist die Methode, mit der wahre Unix-Hardliner ihre News lesen ;—) Die meisten Newsreader sind jedoch weitaus höher entwickelt. Sie bieten für gewöhnlich ein Fullscreen-Interface mit verschiedenen Ebenen zur Darstellung aller Gruppen, die der Benutzer abonniert hat, eine Übersicht über alle Artikel in jeder Gruppe und über individuelle Artikel. Viele Webbrowser kann man auch als Newsreader benutzen; wenn Sie jedoch einen Standalone-Newsreader bevorzugen, erläutert Ihnen dieses Kapitel, wie Sie zwei klassische Varianten konfigurieren: trn und nn. Auf Newsgruppen-Ebene zeigen die meisten Newsreader eine Liste von Artikeln an, in der ihre Subject-Zeilen und die Autoren erscheinen. In großen Gruppen ist es für den Anwender schwierig, die Übersicht über zusammengehörige Artikel zu behalten, obwohl es möglich ist, Antworten auf frühere Artikel zu identifizieren. Für gewöhnlich wiederholt eine Antwort das Subject des ursprünglichen Artikels und stellt ihm ein Re: voran. Zusätzlich sollte die Header-Zeile References: die Message-ID des Artikels enthalten, auf die diese Antwort direkt folgt. Durch Sortierung nach diesen beiden Kriterien erhält man kleine Anhäufungen (tatsächlich sind es Bäume) von Artikeln, die als Threads bezeichnet werden. Eine der Aufgaben beim Schreiben eines Newsreaders besteht darin, sich ein effizientes Schema für das Threading auszudenken, da die dafür benötigte Zeit zum Quadrat der Anzahl der Artikel proportional ist. Wir befassen uns hier nicht damit, wie die Benutzerschnittstellen aufgebaut sind. Alle gegenwärtig für Linux erhältlichen Newsreader besitzen eine gute Hilfefunktion. Bitte benutzen Sie diese für weitere Informationen. In den folgenden Abschnitten beschäftigen wir uns nur mit administrativen Aufgaben. Die meisten davon beziehen sich auf die Erzeugung von Thread-Dateien und Accounting.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen

Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von tin Der vielseitigste Newsreader in bezug auf Threading ist tin. Er wurde von Iain Lea geschrieben undentstand auseinem älteren Newsreader namens tass (geschrieben von Rich Skrenta). Er führt sein Threading durch, wenn der Benutzer die Newsgruppe betritt, und er ist ziemlich schnell, wenn Sie Postings nicht gerade über NNTP bekommen. Ein 486DX50 braucht ungefähr 30 Sekunden für einen Thread von 1000 Artikeln, wenn er direkt von Platte liest. Es dauert dagegen mehr als fünf Minuten, einen ausgelasteten News-Server über NNTP zu erreichen.1 Sie können diese Zeit verbessern, indem Sie Ihre Indexdatei in regelmäßigen Abständen aktualisieren und dafür tin mit der Option –u aufrufen, so daß beim nächsten Mal, wenn Sie tin zum Lesen der News starten, die Threads bereits existieren. Alternativ dazu können Sie tin zum Lesen der News auch mit der Option –U starten. In diesem Fall erzeugt tin einen Hintergrundprozeß, um die Indexdateien zu bilden, während Sie die News lesen. Für gewöhnlich legt tin seine Thread-Dateien im Home-Verzeichnis des Benutzers unter .tin/index ab. Das kann jedoch zu Lasten der Ressourcen gehen, weshalb Sie besser eine einzelne Kopie davon an einem zentralen Ort aufbewahren sollten. Das erreichen Sie zum Beispiel, indem Sie tin auf Setuid news setzen. tin hält dann alle Thread-Dateien unter /var/spool/news/.index. Bei jedem Dateizugriff oder beim Verlassen einer Shell setzt es seine effektive Benutzer-ID auf die echte ID des Benutzers zurück, der tin aufgerufen hat.2

Manche Linux-Distributionen enthalten eine tin-Version, die ohne NNTP-Unterstützung kompiliert wurde; bei den meisten wird NNTP jedoch mittlerweile unterstützt. Wird tin als rtin oder mit der Option –r aufgerufen, versucht es, eine Verbindung mit dem NNTP-Server aufzunehmen, der in der Datei /etc/nntpserver oder in der Umgebungsvariablen NNTPSERVER angegeben ist. Die nntpserverDatei enthält einfach nur den Namen des Servers in einer einzelnen Zeile.

1.

Das Ganze läuft allerdings wesentlich schneller ab, wenn der NNTP-Server das Threading selbst übernimmt und dem Client die Thread-Datenbank zur Verfügung stellt. INN zum Beispiel verfährt so.

2.

Das ist der Grund, warum Sie seltsame Fehlermeldungen bekommen, wenn Sie tin als Systemadministrator aufrufen. Allerdings sollten Sie Routinearbeiten ohnehin nicht als Benutzer root durchführen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von trn Auch trn ist ein Nachfolger eines alten Newsreaders, nämlich von rn (was für read news steht). Das “t” im Namen steht für “threaded”. Geschrieben wurde er von Wayne Davidson. Im Unterschied zu tin bietet trn keine Möglichkeit, um Thread-Dateien zur Laufzeit zu erzeugen. Statt dessen benutzt es Thread-Dateien, die bereits von einem Programm namens mthreads vorbereitet wurden. Zur Aktualisierung dieser Indexdateien muß mthreads in regelmäßigen Abständen von cron aufgerufen werden. Sie können auch dann auf neue Artikel zugreifen, wenn Sie mthreads nicht betreiben, allerdings werden Sie dann all die vielen Artikel mit “EINMALIGE INVESTITIONSGELEGENHEIT” in Ihrem Artikel-Auswahlmenü wild verstreut angezeigt bekommen statt in einem einzigen Thread, den Sie mühelos überspringen könnten. Um Threading für einzelne Newsgruppenzu aktivieren, rufen Sie mthreads mit der Liste der Newsgruppen in der Kommandozeile auf. Das Format der Liste ist dasselbe wie bei der sys-Datei von C News. Beispiel: $ mthreads ’comp,rec,!rec.games.go’

Dieser Befehl aktiviert Threading für alle Newsgruppen von comp und rec, ausgenommen rec.games.go (Leute, die Go spielen, brauchen keine aufwendigen Threads). Danach rufen Sie einfach mthreads ohne weitere Argumente auf, damit es neu ankommende Artikel indiziert. Um das Threading für alle Gruppen einzuschalten, die in Ihrer active-Datei gefunden werden, rufen Sie mthreads mit der Gruppenliste all auf. Empfangen Sie News bei Nacht, werden Sie auf herkömmliche Weise mthreads einmal morgentlich aufrufen; Sie können das bei Bedarf aber auch häufiger tun. Systeme mit sehr hohem Datenverkehr werden mthreads im Dämon-Modus laufen lassen wollen. Wenn es beim Systemstart mit der Option –d aufgerufen wird, versetzt es sich selbst in den Hintergrund, wacht alle zehn Minuten auf, um nachzusehen, ob inzwischen irgendwelche neuen Artikel angekommen sind, und indiziert sie dann. Um mthreads im Dämon-Modus laufen zu lassen, tragen Sie folgende Zeile in Ihr rc.news-Skript ein: /usr/local/bin/rn/mthreads -deav

Die Option –a veranlaßt mthreads, Threading für alle neuen Gruppen, wenn sie erzeugt werden, automatisch zu aktivieren. Die Option –v bewirkt die Ausgabe ausführlicher Lognachrichten in der mthreads-Logdatei mt.log in dem Verzeichnis, in dem Sie trn installiert haben. Alte Artikel, die nicht länger verfügbar sind, müssen regelmäßig aus den Indexdateien entfernt werden. Per Standardeinstellung werden nur Artikel mit einer Nummer entfernt, die unterhalb der Artikel-Untergrenze liegt.1 Artikel, die oberhalb dieser Nummer liegen und veraltet sind (weil dem ältesten Artikel von einem Expires:-Header-Feld ein langes Verfalldatum zugeordnet wurde), dürfen trotzdem gelöscht werden, wenn mthreads die Option –e übergeben wird, um einen “erweiterten” Löschdurchlauf zu erzwingen. Läuft mthreads im Dämon-Modus, führt die Option –e dazu, daß mthreads einmal täglich (kurz nach Mitternacht) einen solchen erweiterten Löschdurchlauf durchführt.

1.

Beachten Sie, daß C News (beschrieben in Kapitel 21 C News) diese Artikel-Untergrenze nicht automatisch aktualisiert; Sie müssen dafür erst updatemin aufrufen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen

Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Konfiguration von nn nn, geschrieben von Kim F. Storm, behauptet von sich, ein Newsreader zu sein, dessen ultimatives Ziel es ist, keine News zu lesen. Sein Name steht für “Keine Neuigkeiten” (engl. no news), und sein Motto ist “Keine Neuigkeiten sind gute Neuigkeiten. nn ist besser”. Zur Erreichung dieses ehrgeizigen Ziels kommt nn mit einem großen Sortiment von VerwaltungsTools daher, die nicht nur Thread-Erzeugung gestatten, sondern auch umfassende DatenbankKonsistenzprüfungen, Accounting und Sammlung von Benutzerstatistiken und Zugriffsbeschränkungen. Außerdem gibt es ein Administrationsprogramm namens nnadmin, mit dem Sie diese Aufgaben interaktiv erledigen können. Es ist sehr intuitiv, weshalb wir uns hier nicht mit diesen Aspekten befassen, sondern nur mit der Erzeugung der Indexdateien. Die Thread-Dateien von nn werden mit dem Programm nnmaster verwaltet. Für gewöhnlich wird es als Dämon betrieben und beim Systemstart aus einem rc-Skript heraus gestartet. Aufgerufen wird es wie folgt: /usr/local/lib/nn/nnmaster -l -r -C

Dies aktiviert Threading für alle Newsgruppen, die in Ihrer active-Datei vorhanden sind.

Genauso können Sie nnmaster auch regelmäßig von cron aufrufen lassen, wobei Sie eine Liste von Gruppen angeben, die behandelt werden sollen. Diese Liste ähnelt sehr stark der Subskriptionsliste in der sys-Datei, mit der Ausnahme, daß Leerzeichen anstelle von Kommata benutzt werden. Statt der Pseudogruppe all wird hier das leere Argument "" benutzt, um alle Gruppen zu bezeichnen. Ein Beispielaufruf sieht so aus: # /usr/local/lib/nn/nnmaster !rec.games.go rec comp

Beachten Sie, daß die Reihenfolge wichtig ist. Es “gewinnt” immer diejenige passende GruppenSpezifikation, die am weitesten links steht. Auch wenn wir beispielsweise !rec.games.go nach rec angeben, würden trotzdem alle Artikel dieser Gruppe indiziert werden. nn bietet verschiedene Methoden, um veraltete Artikel aus seinen Thread-Dateien zu löschen. Die erste Möglichkeit, die Dateien zu aktualisieren, besteht darin, die Newsgruppen-Verzeichnisse zu durchsuchen und die Einträge zu streichen, deren entsprechender Artikel sein Verfalldatum überschritten hat. Dies ist das Standardverfahren, das durch Aufruf von nnmaster mit der Option –E erreicht wird. Es geht einigermaßen schnell, wenn Sie es nicht gerade über NNTP machen. Die zweite Methode verhält sich genauso wie ein standardmäßiger Löschdurchlauf von mthreads. Dabei werden nur diejenigen Einträge entfernt, die auf Artikel verweisen, deren Nummer unterhalb der Artikel-Untergrenze in der active-Datei liegt. Dies kann über die Option –e aktiviert werden. Das letzte Verfahren schließlich löscht die komplette Datenbank und sammelt alle Artikel neu zusammen. Aktiviert werden kann es über die Option –E3. Die Liste der zu löschenden Gruppen wird über die Option –F in derselben Weise wie oben angegeben. Wenn Sie nnmaster jedoch als Dämon betreiben, müssen Sie ihn erst (mit –k) killen, bevor das Löschen vonstatten geht, und hinterher mit den ursprünglichen Optionen neu starten. Folglich sieht die korrekte Anweisung zum Löschen aller Gruppen mit der ersten Methode so aus: # nnmaster -kF "" # nnmaster -lrC

Es gibt noch viel mehr Optionen, mit denen das Verhalten von nn bis ins kleinste festgelegt werden kann. Wenn Sie schlechte Artikel entfernen oder Artikelsammlungen aufsplitten wollen, lesen Sie die Manpage von nnmaster. nnmaster ist auf eine Datei namens GROUPS angewiesen, die sich im Verzeichnis /var/lib/nn befindet. Wenn sie beim ersten Start von nnmaster noch nicht existiert, wird sie erzeugt. Sie enthält für jede Newsgruppe eine Zeile, die mit dem Gruppennamen beginnt, optional gefolgt von einer Zeitangabe und weiteren Flags. Sie können diese Flags editieren, um bestimmte Verhaltensweisen für die fragliche Gruppe einzustellen, Sie dürfen dabei allerdings nicht die Reihenfolge der Gruppen verändern.1 Die zulässigen Flags und ihre Auswirkungen werden ebenfalls ausführlich in der Manpage von nnmaster beschrieben.

1.

Diese Reihenfolge muß mit der Reihenfolge der Einträge in der (Binär-)Datei MASTER übereinstimmen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Anhang A Beispielnetzwerk: Die virtuelle Brauerei Das ganze Buch hindurch haben wir das nachfolgende Beispiel benutzt. Es ist etwas weniger komplex als bei der Groucho-Marx-Universität und entspricht den Aufgaben, die Ihnen im Alltag tatsächlich begegnen, vielleicht etwas eher. Die virtuelle Brauerei ist eine kleine Firma, die — wie der Name schon sagt — virtuelles Bier braut. Um ihr Geschäft effizienter zu verwalten, wollen die virtuellen Brauer ihre Computer vernetzen. Dabei handelt es sich um PCs, die mit dem denkbar besten Produktions-Kernel von Linux laufen. Abbildung 24.1 zeigt die Netzwerkkonfiguration. Auf gleicher Höhe, quer durch die Halle, befindet sich die virtuelle Winzerei, die eng mit der virtuellen Brauerei zusammenarbeitet. Die Weinhändler betreiben ein eigenes Ethernet. Ganz selbstverständlich wollen die beiden Firmen ihre Netzwerke zusammenschalten, sobald sie betriebsbereit sind. Im ersten Schritt wollen sie einen Gateway-Host einrichten, der Datagramme zwischen den beiden Subnetzen überträgt. Später wollen sie auch einen UUCP-Link zur Außenwelt haben, über den sie Mails und News austauschen können. Auf lange Sicht wollen sie außerdem PPP-Verbindungen einrichten, um mit Stellen außerhalb des Netzes und zum Internet Verbindung aufzunehmen.

Das gesamte Netzwerk ist ein Klasse-B-Netz, und die Subnetze der virtuellen Brauerei und Winzerei sind jeweils Klasse-C-Netze. Als Gateway zwischen den Subnetzen wird der Host vlager eingesetzt. Er unterstützt auch die UUCP-Verbindung. Abbildung 24.2 zeigt die Konfiguration. Abbildung A.1: Die Subnetze der virtuellen Brauerei und Winzerei

Abbildung A.2: Das Netzwerk der virtuellen Brauerei

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Anhang B Nützliche Kabel-Konfigurationen Wenn Sie zwei Computer miteinander verbinden wollen und gerade kein Ethernet parat haben, benötigen Sie entweder ein serielles Nullmodem-Kabel oder ein paralleles PLIP-Kabel. Man kann diese Kabel zwar auch käuflich erwerben, es ist aber viel billiger und recht einfach, sie selbst herzustellen.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Anhang C Linux – Wegweiser für Netzwerker, Copyright-Hinweise zur zweiten Auflage Copyright © 1993 Olaf Kirch Copyright © 2000 Terry Dawson Copyright der gedruckten Version von O'Reilly © 2000 O'Reilly & Associates Die Online-Version dieses Buches, die bei Drucklegung exakt denselben Text wie die gedruckte Version von O'Reilly enthält, ist unter der GNU FDL erhältlich. Die Rechte zum Nachdruck des Dokuments unter der FDL beinhalten das Recht zum Druck und zur Verbreitung gedruckter Kopien der Online-Version. Die Rechte zum Kopieren der gedruckten O'Reilly-Version sind vorbehalten. Die Online-Version der Lizenz finden Sie unter http://www.oreilly.com/catalog/linag/licenseinfo.html. Das englische Originalbuch ist erhältlich unter http://www.linuxdoc.org/LDP/nag/nag.html und http://www.oreilly. com/catalog/linag2/ und darf von anderen an anderer Stelle zur Verfügung gestellt werden. Die deutsche Übersetzung ist unter http://www.oreilly.de/catalog/linag2ger/ zu finden. Permission is granted to copy, print, distribute, and modify the online document under the terms of the GNU Free Documentation License, Version 1.1, or any later version published by the Free Software

Foundation; with the Invariant Sections being the Acknowledgments (Vorwort and Anhang 3 Linux – Wegweiser für Netzwerker, Copyright-Hinweise zur zweiten Auflage). Further acknowledgments can be added outside the Invariant Section. The Front-Cover Text must read: Linux Network Administrator's Guide by Olaf Kirch and Terry Dawson Copyright © 1993 Olaf Kirch Copyright © 2000 Terry Dawson Copyright on O'Reilly printed version © 2000 O'Reilly & Associates Im folgenden drucken wir den Text der GNU Free Documentation License ab, dieser Text ist auch unter http://www.gnu.org/copyleft/fdl.html nachzulesen. Eine nichtoffizielle deutsche Übersetzung ist unter http://nautix.sourceforge.net/docs/fdl.de.html zu finden. Version 1.1, March 2000 Copyright © 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Anhang D SAGE: Die System Administrators Guild Wenn Sie nicht alles, was Sie benötigen, durch Posten an comp.os.linux.*-Newsgruppen oder durch Studium der Dokumentation herausfinden, ist es vielleicht an der Zeit, Mitglied bei SAGE zu werden, der System Administrators Guild, die von USENIX gesponsert wird. Das Hauptziel von SAGE ist die Etablierung der Systemadministration als ernsthaften Beruf. SAGE bringt System- und Netzwerk-administratoren zusammen, um professionelle und technische Entwicklung zu pflegen, Probleme und Lösungen zu teilen und mit Anwendern, Management und Herstellern über Themen der Systemadministration zu kommunizieren. Die aktuellen SAGE-Initiativen beinhalten: ●

●

Gemeinsames Sponsoring der sehr erfolgreichen jährlichen SystemadministrationsKonferenzen (LISA) mit USENIX. Veröffentlichung der Job Descriptions for System Administrators, geschrieben von Tina Darmohray, die erste einer Reihe sehr praktischer Broschüren und Betriebs-anleitungen über Fragen und Techniken der Systemadministration.

●

●

Erzeugung einer Archiv-Site, ftp.sage.usenix.org, für Unterlagen von den System-administrations-Konferenzen und für Sysadmin-bezogene Dokumentation. Gründung von Arbeitsgruppen in für Systemadministratoren wichtigen Bereichen wie Arbeitsstellen, Veröffentlichungen, Politik, elektronische Informationsverteilung, Bildung, Verkauf und Standards.

Wenn Sie mehr über die UNIX Association und ihre Special Technical Group, SAGE, wissen wollen, rufen Sie das USENIX Associates-Büro unter (510) 528-8649 in den Vereinigten Staaten an oder schicken Sie eine E-Mail an [email protected]. Um Informationen auf elektronischem Weg zu erhalten, kontaktieren Sie [email protected]. Die jährliche Mitgliedschaft bei SAGE kostet 25 USDollar (Sie müssen auch ein Mitglied von USENIX sein). Mitglieder erhalten kostenlose Abonnements von login: und Computing Systems, ein vierteljährlich erscheinendes technisches Magazin, außerdem Preisnachlässe für Konferenzen und Symposien, Rabatte auf SAGEPublikationen und noch andere Dienste.

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag

Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

! ! (in Mail-Adressen) 1 % (in Mail-Adressen) 1 & (in Mail-Adressen) 1 öffentliche Schlüssel 1, 2 /etc/aliases (Datei) 1 /proc-Dateisystem, Einrichten 1 /usr/sbin/sendmail 1 16450 UART 1 16550 UART 1 2.0-Kernel IP-Accounting 1 IP-Firewalls 1 2.2-Kernel IP Firewall Chains 1 IP-Accounting 1 NFS-Server-Support 1 2.2er Kernel IP-Masquerade 1 NFS-Server-Unterstützung 1 2.4-Kernel, netfilter und IP tables 1 2.4er Kernel

IP-Accounting 1 IP-Masquerade 1 8250 UART 1 A A (DNS-Record) 1 Absolute Mail-Adressen 1 accept() 1 accept(2) 1 access, NNTP 1 access_db-Feature (sendmail) 1 active-Datei (INN) 1 active.times-Datei (/var/lib/news) 1-2 Address Resolution Protocol siehe ARP 1 Adreßauflösung 1 Adresse, Loopback 1 Adressen Abbildung in Hostnamen 1 Auswahl (IP) 1 bang path 1, 2 Broadcast 1 Broadcast- 1, 2 DNS-Resource-Record 1 E-Mail 1 Ethernet 1 Hesiod 1 hybride 1 IP 1, 2 Mail 1 UUCP-Hostnamen 1 Vereinbarung bei PPP 1, 2 Vereinbarung mit PPP 1 aktiver Hub 1-2 Alias C News 1 Hostnamen 1 Alias-Dateien für Exim 1 Aliase E-Mail 1 Hostname 1 Mail 1 Aliasing, IP (Internet Protocol) 1 Aliasnamen E-Mail 1 Mail 1 Allman, Eric 1 Amateurfunk-Prokolle 1

Amateurfunker-Protokolle 1 Ampersand (in Mail-Adressen) 1 Anonymous UUCP 1 Anzeige IP-Routing-Tabelle 1 irtt 1 Schnittstelle, Statistiken 1 Anzeigen aktive Verbindungen 1 ARP-Tabelle 1 UUCP-Konfiguration 1 ArcNet-Protokoll-Treiber 1 ARP (Address Resolution Protocol) 1 Aktivierung/Deaktivierung 1 Proxy 1, 2, 3 Tabelle anzeigen 1 ARPANET 1 article-Befehl (NNTP) 1 Artikel (news) 1 Batch-Betrieb 1 Header/Nachrichteninhalt ermitteln 1 löschen 1 Listing 1 Posten 1 Async-Map 1 Asynchronous Control Character Map 1 ATM (Asynchronous Transfer Mode) 1, 2 Aufbauen einer Verbindung 1 Aufrufreihenfolge prüfen 1 Ausgabe IP-Routing-Tabelle 1 NIS-Map-Spitznamen 1 Schnittstellen-, Konfiguration 1 Auslieferung, News 1, 2 Ausrufezeichen (in Mail-Adressen) 1 Austausch E-Mail 1 Mail 1 News 1 Auswahl einer NIS-Domain 1 IP-Adressen 1 UUCP-Hostnamen 1 Authentifizierung auf Remote-Hosts 1 Ausgaben 1 PPP 1 Auto-IRQ 1

Autoprobing Ethernet- 1 Fehlschlag des 1 Autorisierung mit PPP 1 NNTP 1 Autoritative Name-Server 1, 2, 3 AX.25-Device 1 AX.25-Protokoll 1, 2, 3 AX25-HOWTO 1, 2 Aznar, Guylhem 1 B Barber, Stan 1 Basic Networking Utilities (BNU) siehe Taylor-UUCP, HDB 1 Batch E-Mail 1 Mail 1 BBS (Bulletin Board System) 1 Becker, Donald 1 Befehl domainname 1 Beginn der Autorisation 1 Benutzergruppen 1 Berkeley Internet Name Domain siehe BIND 1 Berkeley Socket Library 1 Betriebsmodus 1 BIND (Berkeley Internet Name Domain) 1, 2 bind() 1 bind(2) 1 Bindery-Manipulations-Tools 1 Biro, Ross 1 blacklist_recipients-Feature (sendmail) 1 BNC-Stecker 1 BNU (Basic Networking Utilities) siehe auch Taylor UUCP, HDB 1 body-Befehl (NNTP) 1 BOOTP 1 Bootup-Sequenz 1 Bridges 1 Brief 1 Broadcast-Adresse 1 bsmtp (Programm) 1 Bulletin Board 1 Burkett, B. Scott 1 C

C News 1, 2 active (Datei) 1, 2, 3 active-Datei aktualisieren 1 archivieren 1 Artikel-Untergrenze aktualisieren 1, 2 Batch-Betrieb 1, 2-3 Batch-Parameter 1 Batches komprimieren 1 Erzeugen der Anfangskonfiguration 1 Feed beschränken 1 Feed einschränken 1, 2 history (Datei) 1, 2 Hostname-Alias 1 ihave/sendme 1, 2 Installation 1 Liste aktueller Gruppen 1 Liste aktueller Newsgruppen 1 Logdateien 1 moderierte Gruppen 1 Nachrichten austauschen 1 News ausliefern 1 News austauschen 1 News empfangen 1, 2 News und Expiring 1 News versenden 1, 2, 3 Newsmaster 1 NFS 1 NNTP-Support 1 NNTP-Unterstützung 1 relaynews (Befehl) 1 rnews (Befehl) 1 Spool-Verzeichnis 1 Stapelverarbeitung von Artikeln (Batching) 1 Steuermeldungen 1 sys (Datei) 1, 2 Systeme ausschließen 1 togo (Datei) 1 Usenet 1 UUCP 1, 2 Cache (BIND-Option) 1 Caching-only-Name-Server 1, 2 Caldera (Linux distribution) 1 Caldera (Linux-Distribution), NetWare-Support 1 cancel (Steuermeldung) 1 Chains, IP Firewall 1 CHAP (Challenge Handshake Authentication Protocol) 1, 2, 3 chargen (interner Dienst) 1

chat (Programm) 1 Chat-Programm 1 PPP 1 SLIP 1 Chat-Skript 1 UUCP 1 checkgroups (Steuermeldung) 1-2 Clients ohne Laufwerk 1 CNAME (DNS-Record) 1 Code beziehen, Linux-Netzwerk 1 Quellen, Linux-Netzwerk 1 Code erhalten für, sendmail 1 Collyer, Geoff 1 com-Domain 1 COM-Port 1 comp.mail.uucp 1 comp.os.linux.admin 1 comp.os.linux.announce 1 comp.os.linux.development 1 comp.os.linux.help 1 comp.os.linux.misc 1 comp.os.linux.networking 1 Compressed Serial Line IP siehe CSLIP 1 connect() 1 connect(2) 1 control.ctl-Datei (INN) 1 Corel (Linux distribution) 1 Cox, Alan 1, 2, 3 cron 1 ausführen, newsdaily in 1 betreiben, Exim via 1 News und Expiring 1 CSLIP (Compressed Serial Line IP) 1 CSLIP (Compressed Serial Line IP) Protocol 1, 2 CSLIP-Protokoll (Compressed Serial Line IP) 1, 2 ctlinnd-Befehl (INN) 1 D Dämonen 1 Wrapping über tcpd 1 D-Link-Pocket-Adapter 1 Datei /etc/networks 1 Das route-Kommando 1 Datagramm-Arten, ICMP-Protokoll 1 Datagramme 1, 2

Fragmentierung von 1 IP-Filterung 1 Masquerading 1 Verarbeitungsschritte 1 Vergleich von IP-Chains und netfilter 1 Datei nsswitch.conf 1 Handlungsanweisungen 1 Datei resolv.conf 1 Dateien /etc/exports 1 /etc/fstab 1 .ppprc 1 Dateisystem-Standard 1 Davies, David C. 1 daytime (interner Dienst) 1 dbmload (Programm) 1 DDI (Device Driver Interface) 1 Debian (Linux distribution) 1 Debugging DNS-Datenbanken 1 PPP-Setup 1 UUCP-Einrichtung 1 Delegieren DNS-Subdomains 1, 2 IP-Subnetze 1 Denial-of-Service-Attacken 1 Dent, Arthur 1 /dev/cua* 1 /dev/modem 1 /dev/ttyS* 1 Device Driver Interface (DDI) 1 Dial-Up List (DUL) 1 Dialin-Gerät 1 Dialout-Gerät 1 Dialup-IP 1 Dienste 1 bekannte 1, 2 einrichten 1 Portnummern 1 Zugriff beschränken 1 Zugriff einschränken 1 dip-Programm 1 diphosts (Datei) 1 diplogin (Befehl) 1 DISPLAY (Umgebungsvariable) 1-2 DNS (Domain Name System) 1 Anfrage 1 Konvertierung von /etc/hosts 1

Datenbank-Debugging 1 Datenbanken 1, 2 Lebensdauer 1, 2 nachschlagen 1 Resolver und 1 Resource Record 1 Resource-Record 1 Reverse Mapping 1 Root-Name-Server 1, 2 RR siehe DNS, Resource Record 1 Server konfigurieren 1 suchen 1 Test 1 Tools 1 Zonen 1, 2 dnswalk-Programm 1 Dokumentation (Linux) FTP 1 kommerzielle 1 WWW 1 Domänen Namen 1 Standard 1 Namen von, NIS versus DNS 1 DOMAIN (Makrodefinition) 1 Domain Name System siehe DNS 1 Domain-Name-Server 1 domainname (Befehl) 1 Domains 1 Mail-Routing 1 Namen 1, 2 Default 1 NIS 1-2, 3 Top-Level 1 Dotted Decimal Notation 1 Dotted Quad Notation 1, 2 Druckerwarteschlangen, NetWare 1 Dryak, Ales 1, 2 dynamisches Routen 1 E E-Mail 1 über UUCP 1 Adressenformate 1 Aliase 1, 2 an einen Befehl übergeben 1

Bang-Path-Notation 1, 2 Batch 1 Benutzer ausschließen 1 domainbasiertes Routing 1, 2 elm 1 Exim 1 Forwarding 1-2 Gateway 1 Header 1 in eine Datei schreiben 1 Inhalt 1 Map-Dateien 1 Maps 1 Message-Header 1 Multimedia 1 Nachrichtenformat 1 paths (Datei) 1, 2 Queue 1, 2 Routing 1, 2 domainbasiert 1 im Internet 1 Smart-Host- 1 UUCP-Netzwerke 1 sendmail 1 smail siehe auch smail 1 Spam verwalten 1, 2 Standardroute 1 Transport 1 unerwünscht 1, 2 unzustellbar 1 Verfassen 1 virtuelles Hosting 1 Warteschlange 1, 2, 3 Zentral 1 zentralisieren 1, 2 E-Mail in Warteschlange eintragen 1 echo (Dienst) 1 Echo Request/Echo Response-Nachrichten 1 echte Benutzernamen 1 edu-Domain 1 einen Host erreichen 1 eingeschränkter Zugriff auf Dienste 1 Einrichten des /proc-Dateisystems 1 NIS-Domain 1 Einrichtung, NIS-Domain 1 Einwahl

nach Bedarf 1 permanent 1 Einwahl nach Bedarf 1 Ekwall, Bjørn 1 Elektronische Post siehe E-Mail 1 elm (electronic mail) 1 nationale Zeichensätze 1 entfernte (remote), Befehlsausführung 1 entfernter (remote), Dateizugriff 1, 2 entferntes (remote), Login 1 Eriksson, Peter 1 erzeugen DNS-Zonen 1 NIS-Maps 1 Subdomains 1 Subnetze 1, 2 /etc/aliases (Datei) 1 /etc/aliases (Datei) 1 /etc/dip.pid (Datei) 1 /etc/diphosts (Datei) 1 /etc/exports (Datei) 1 /etc/fstab (Datei) 1 Datei /etc/fstab 1 /etc/group (Datei) 1 /etc/group (Datei) 1 /etc/host.conf-Datei 1 Datei /etc/hosts 1, 2, 3, 4 /etc/hosts.allow (Datei) 1 /etc/hosts.deny (Datei) 1 /etc/inetd.conf (Datei) 1, 2 Datei /etc/named.boot 1 /etc/networks (Datei) 1 /etc/news/incoming.conf-Datei (INN) 1 /etc/nsswitch.conf (Datei) 1 /etc/passwd (Datei) 1 echte Benutzernamen 1 /etc/passwd (Datei) 1, 2, 3 /etc/ppp/chap-secrets (Datei) 1-2 /etc/ppp/options (Datei) 1 /etc/ppp/options (Datei) 1, 2 /etc/ppp/pap-secrets (Datei) 1, 2 /etc/protocols (Datei) 1 /etc/protocols (Datei) 1 /etc/rpc (Datei) 1 /etc/services (Datei) 1, 2, 3 /etc/shadow (Datei) 1 /etc/shadow (Datei) 1

/etc/ssh/ssh_config (Datei) 1 /etc/ssh/ssh_host_key (Datei) 1 /etc/ssh/ssh_host_key.pub (Datei) 1 /etc/yp.conf (Datei) 1 /etc/ypserv.securenets (Datei) 1-2 eth0 (Ethernet-Interface) 1 eth1-Device 1 Ethernet über den Parallelport 1 Adressen 1, 2 verglichen mit IP Adressen 1 Autoprobing 1 Becker-Treiber 1 Installation 1 Karten 1 Kollision 1 Nachteile 1 Promiscuous-Modus 1 Schnittstelle konfigurieren 1 Thick/Thin 1 Twisted Pair 1 Zweidraht 1 Exim 1 Alias-Dateien 1 Benutzer-Mailboxen 1 Betrieb 1 Dämon-Modus 1 Fehlersuche 1 Filterdateien 1 kompilieren 1 Konfigurationsdateien 1 Optionen 1 Logdateien 1, 2 Mail an einen Befehl übergeben 1 Mail in eine Datei schreiben 1 Mail in Warteschlange eintragen 1 Mail weiterleiten 1 Mail-Queue prüfen 1 Mail-Warteschlange prüfen 1 Mail-Zustellungsarten 1 Mailing-Listen 1 Nachrichten an lokale Adressen zustellen 1 Router 1 Routing von Nachrichten in 1 symbolische Links auf 1 Transporte 1 Troubleshooting 1

Utilities 1 UUCP einrichten 1 Vermittler 1 expect (Programm) 1 expire.ctl-Datei (INN) 1 exports (Datei) 1 External Data Representation (XDR) 1 F Fälschen von News 1 FDDI (Fiber Distributed Data Interface) 1, 2 FEATURE (Makrodefinition) 1 Fehler, Prüfen auf 1 Fehlermeldung “Netzwerk unerreichbar” 1 FHS (File Hierarchy Standard) 1 Fiber Distributed Data Interface (FDDI) 1, 2 FidoNet 1 Filterdateien 1 Filtern siehe auch Masquerade 1 Filterung IP 1 Stufen der 1 finger (Dämon) 1 Wrappen mit tcpd 1 Fingerprint 1 Firewalls 1, 2 Angriffsmethoden 1 Beispielkonfiguration 1 benutzerdefinierte Ketten 1 IP Chains 1 IP-Chains, Sichern/Wiederherstellen 1 netfilter 1 Original IP 1 Sicherheit 1 Spezifikation der Netzmaske 1 TCP/IP 1 Testen einer Konfiguration 1 TOS-Bit-Manipulation 1 Warnung 1 Flooding-Algorithmus 1 .forward (Datei) 1 forwardfile (Vermittler) 1 Forwarding E-Mail 1-2 IP 1, 2 Mail 1-2

FRAD (Frame Relay Access Device) 1 Fragmentierung, Datagramm 1 Frampton, Steve 1 FSSTND (File System Standard) 1 FTP (File Transfer Protocol), Quelle für Linux-Quellen 1 G gated (Befehl) 1, 2 gated-Befehl 1 Gateways 1, 2, 3 E-Mail 1 Konfigurieren 1 Mail 1 Routing von Netzwerken durch 1 gemeinsame Dateien 1, 2 Geräte Linux-Netzwerk- 1 Major/Minor Number 1 mit IPX-Unterstützung 1 serielle 1 Gerätedateien 1 Gerätetreiber (device driver) 1 get-Befehl 1 gethostbyaddr() 1, 2, 3 gethostbyname() 1, 2, 3 uucico und 1 getpwnam() 1 getpwuid() 1 getservbyname() 1 Glue Records 1 GNU libc (NIS-Unterstützung) 1, 2 Goldt, Sven 1 gov-Domain 1 GPG (GNU Privacy Guard) 1 Groucho-Marx-Universität (GMU) 1, 2 group-Befehl (NNTP) 1 H Ham-Radio 1, 2 Handshake, Hardware 1, 2, 3 Hankins, Greg 1 Hardware Handshake 1, 2, 3 Konfiguration der seriellen 1 Netzwerkkonfiguration 1

Harper, John D. 1 Hazel, Philip 1 HDB siehe auch Taylor-UUCP, BNU 1 HDLC (High-Level Data Link Control) 1 head-Befehl (NNTP) 1 Hesiod-Adressen 1 Hilfe, online 1 HoneyDanBer siehe Taylor-UUCP, HDB 1 host.conf (Datei) 1, 2 hostcvt-Programm 1 Hostname Aliase 1 Auflösung 1 Domainname und 1 ermitteln aus Adresse 1 kanonisch 1 kanonischer 1 mehrdeutig 1 nachschlagen 1 Resolution 1, 2 Setzen des 1 suchen 1 UUCP 1 voll qualifizierter 1 Hostnamen auf Adressen abbilden 1 auflösen 1 ermitteln 1 Hosts 1 Standalone 1-2 Virtuelle 1 hosts-Datei 1-2 konvertieren in BIND-Master-Datei 1 hosts.byaddr (Datei) 1 hosts.byname (Datei) 1 Hostschlüssel 1 hoststat (Befehl) 1 HOWTOs 1 AX25 1, 2 E-Mail 1-2 IPCHAINS 1 IPTABLES 1 IPX 1 Mail 1 Netzwerke 1 PACKET-FILTERING 1 PPP 1

Serial- 1 UUCP 1 hybride Adressen 1 I IBM-Token-Ring-Netzwerke 1 ICMP (Internet Control Message Protocol) Accounting von Datagrammen 1 Datagramm-Arten 1 Redirect 1 unerreichbarer Port 1 IETF (Internet Engineering Task Force) 1 IETF (Internet Engineering TaskForce) 1 ifconfig (Befehl) 1 ifconfig-Befehl 1, 2, 3, 4 ihave-Befehl (NNTP) 1, 2, 3 ihave/sendme (News-Protokoll) 1 in-addr.arpa-Domain 1 incoming.conf-Datei (INN) 1 inetd (Super-Server) 1 inetd-Superserver, Exim betreiben unter 1 inetd.conf (Datei) 1 inews (Befehl) 1 Informationen zu Linux 1 INN (Internet News) 1 Betrieb 1 globale Parameter 1 Installation 1 Konfiguration Newsfeeds 1 Newsgruppen 1 Konfigurationsdateien 1 Löschen von News-Artikeln 1 Newsreader 1 Zugriffskontrolle 1 NNTP 1 Steuernachrichten, Verarbeitung 1 Verwaltung 1 inn-Quellpaket 1 inn.conf-Datei (INN) 1 innd-Befehl (INN) 1 innxmit-Befehl (INN) 1, 2 Installation INN (Internet News) 1 Netzwerkprogramme 1 sendmail 1

Internationalisierung für elm 1 Internet 1 Anbindung 1 Anschluß 1 Dämon 1 E-Mail-Routing 1 Mail-Routing 1 Verbindung 1 verglichen mit Internetworking 1 Internet Control Message Protocol siehe ICMP 1 Internet Datagram Protocol (IDP) 1 Internet News siehe INN (Internet News) 1 Internet Protocol Control Protocol siehe IPCP 1 Internet Protocol siehe IP 1 Internet-Protokolle für serielle Leitungen siehe auch SLIP; PPP 1 Internetworking 1, 2 IP (Internet Protocol) 1 Adresse, Hostname und 1 Adressen 1, 2, 3 Hostnamen und 1 private 1 Vereinbarung bei PPP 1, 2, 3 verglichen mit Hostnamen 1 zuweisen 1 Alias-Konfiguration 1 Aliasing 1 Broadcast-Adresse 1, 2 Default-Route 1, 2 Dialup 1, 2 dynamisches Routen 1 Filterung 1 Firewall Chains 1 Forwarding 1, 2 Gateways 1, 2 IPv4 1 IPv6 1 Masquerade 1 Metrik 1 metrische, Werte 1 MTU 1 MTU siehe Maximum Transfer Unit 1 Multicast-Adressen 1 netmask 1 Network Control Protocol (PPP) 1 Netzmaske 1, 2, 3 Netzwerke 1, 2 Parallele Leitung siehe PLIP-Protokoll (Parallel Line IP) 1

private Adressen 1 Routen, Auswirkungen der Netzmaske 1 Routing 1, 2, 3, 4 Protokolle 1 Redirect (ICMP) 1 Tabelle 1, 2-3, 4 Schnittstelle, Konfiguration 1 Schnittstellen/Interface 1 Serial Line 1 serielle Leitung 1 Serielle Leitung siehe SLIP (Serial Line IP) protocol 1 Source-Routing 1 Subnetze 1, 2, 3, 4 TOS-(Type-Of-Service-)Bits 1 IP-Accounting 1 anhand von Adressen 1 von ICMP-Datagrammen 1 Kernel-Konfiguration 1 Konfiguration 1 passive Sammlung 1 anhand des Protokolls 1 Regeln verwerfen 1 Resultate benutzen von 1 anhand von Service-Ports 1 Zähler zurücksetzen 1 ipchains (Befehl) 1, 2 Accounting-Daten auflisten mit 1 Firewall-Optionen 1 IP-Accounting konfigurieren 1 IP-Masquerade konfigurieren 1 Regeln auflisten mit 1 Setzen der TOS-Bits 1 Support-Skripten 1 IPCHAINS-HOWTO 1 ipchains-restore (Befehl) 1 ipchains-save (Befehl) 1 IPCP (Internet Protocol Control Protocol) 1, 2 ipfwadm (Befehl) 1, 2 Accounting-Daten auflisten mit 1 Firewall-Optionen 1 IP-Accounting konfigurieren 1 IP-Masquerade konfigurieren 1 Regeln auflisten mit 1 Setzen der TOS-Bits 1 ipfwadm-wrapper (Befehl) 1, 2, 3 iptables (Befehl) 1 Accounting-Daten auflisten mit 1

Erweiterungen 1 Firewall-Optionen 1 IP-Accounting konfigurieren 1 IP-Masquerade konfigurieren 1 Setzen der TOS-Bits 1 IPTABLES-HOWTO 1 IPv4 (Internet Protocol) 1 IPv6 (Internet Protocol) 1 IPX (Internet Packet eXchange) 1, 2 interne Netzwerke 1 Kernel-Konfiguration 1 Konfigurations-Tools für Schnittstellen 1 PPP-Netzwerkprotokoll 1 Routing 1, 2 Tools nsend 1 pqlist 1 slist 1 IPX-HOWTO 1 ipxd (Befehl) 1 ipx_configure (Befehl) 1 ipx_interface (Befehl) 1 ipx_route (Befehl) 1 IRC Network, OpenProjects 1 IRQ (Interrupt Request) 1, 2 Setzen des 1 irtt-Parameter 1 ISO-8859-1 1 J Jobs (UUCP) 1 Junk-Newsgroup 1 K kanonischer Hostname 1, 2 Kempen, Fred van 1 Kermit (Terminal-Programm) 1 Kernel für Masquerade konfigurieren 1 Konfiguration 1 konfigurieren für IPX und NCPFS 1 konfiguriert mit IP-Firewall 1 NFSv2/NFSv3-Server-Support 1 Kernel-Versionsnummern 1 Ketten, benutzerdefiniert 1

Kirch, Olaf 1, 2 Kollision (Ethernet) 1 Komprimierung, TCP/IP-Pakete 1 Konfiguration C News 1 im LAN 1 elm (electronic mail) 1 Ethernet 1 Ethernet- 1, 2 Hostname 1 Resolution 1 IP-Accounting 1 IP-Masquerade 1 IPX 1 Kernel 1 für IP-Accounting 1 mit IP-Firewall 1 für IP-Masquerade 1 Netzwerke Dienste 1 Hardware 1 Newsfeeds 1 Newsgruppen 1 NFS 1 NIS 1, 2, 3 NNTP 1 PLIP 1 PLIP- 1 PPP 1, 2, 3 Remote-Login und Ausführen von Befehlen 1 sendmail 1 für SMTP 1 serieller Port 1 SLIP 1 Server 1 smail siehe smail 1 ssh (Befehl) 1 Taylor UUCP 1 Usenet-News 1 Konfiguration der Dummy-Schnittstelle 1 Konfigurationsdateien INN (Internet News) 1 sendmail 1 Taylor UUCP 1 UUCP 1 Konfigurieren Default-Domain 1 dip-Programm 1

DNS over SLIP/PPP 1 Ethernet 1 Hostname, Resolution 1 IP-Gateways 1 Loopback-Interface 1 Name-Server 1 Aufrufe 1 Netzwerke, Schnittstellen 1 Nur cachende Name-Server 1 PLIP 1 PPP 1 SLIP 1, 2 Standard-Domain 1 Kukuk, Thorsten 1 L LANs siehe lokale Netzwerke 1 Lapsley, Phil 1 Latin-1-Zeichensatz 1 Lauschangriffsprogramme 1 LCP (Link Control Protocol) 1 Echo-Nachrichten 1 Optionen 1 LDP (Linux Documentation Project) 1 Leaf-Sites 1 leafnode (NNTP-Cache-Programm) 1 Lendecke, Volker 1 libc6 (NIS-Unterstützung) 1, 2 Libes, Don 1 Lilo-Kommando 1 line discipline 1, 2 Link Control Protocol siehe LCP 1 Linux Dokumentation 1 HOWTOs 1 Informationsquellen 1 Netzwerk, Quellcode beziehen 1 Netzwerke 1 Quellen für Code 1 Linux distributions 1 Linux Network Administrator's Guide 1 Linux Standard Base (LSB) 1 Linux User Groups (LUG) 1 Linux-Distributionen, Standard Base 1 Linux-Dokumentationsprojekt 1 linux-kernel Mailing-Liste 1

Linux-Kernels, Versionsnummern des 1 linux-net Mailing-Liste 1 linux-ppp Mailing-Liste 1 Linux-Quellcode beziehen 1 Linux-Zeitschriften 1 list active-Befehl (NNTP) 1 list-Befehl (NNTP) 1 listen() 1 listen(2) 1 listgroup-Befehl (NNTP) 1 lo (Loopback-Interface) 1 Local Area Networks (LANs) 1 Hardware für 1 Paßwörter 1 localgroups-Datei (/etc/news) 1 Localhost (dummy hostname) 1 local_domains (Konfigurationsvariable) 1 LOCAL_NET_CONFIG (Makrodefinition) 1, 2 LOCAL_RULE_0 (sendmail-Regelsatz) 1 LOCAL_RULE_1 (sendmail-Regelsatz) 1 LOCAL_RULE_2 (sendmail-Regelsatz) 1 LOCAL_RULE_3 (sendmail-Regelsatz) 1 Lock-Datei, PPP 1 Logdatei (UUCP) 1 Logdateien (Debugging) 1 login-Befehl und NIS-Maps 1 lokale Adressen 1 lokale Makrodefinitionen 1 Lokale Netzwerke (LANs) News 1 Remote-Login 1 verbinden 1 Loopback Adresse 1 Schnittstelle 1 Konfigurieren 1 lpd (line printer daemon) 1 LSB (Linux Standard Base) 1 Lu, H.J. 1 LUG (Linux Benutzergruppen) 1 LUG (Linux User Groups) 1 M m4 (Makroprozessor), sendmail-Optionen konfigurieren 1 m4-Makroprozessor 1 Mail 1

über UUCP 1 Adressenformate 1 Aliase 1 Aliasnamen 1 an einen Befehl übergeben 1 Bang-Path-Notation 1, 2 Batch 1 Benutzer ausschließen 1 domainbasiertes Routing 1, 2 elm 1 Exim 1 Forwarding 1-2 Gateway 1 Header 1 in eine Datei schreiben 1 Inhalt 1 Map-Dateien 1 Maps 1 Message-Header 1 Multimedia 1 Nachrichtenformat 1 paths (Datei) 1 Queue 1, 2 Routing 1 domainbasiert 1 im Internet 1 Smart-Host- 1 UUCP-Netzwerke 1 zwischen Internet und UUCP 1 sendmail 1 Spam verwalten 1, 2 Standardroute 1 Transport 1 unerwünscht 1, 2 unzustellbar 1 Verfassen 1 virtuelles Hosting 1 Warteschlange 1, 2, 3 Zentral 1 zentralisieren 1, 2 Mail Abuse Protection System (MAPS) 1 Mail Exchanger (DNS-Record) 1 Mail in Warteschlange eintragen 1 mail spool (Verwaltung) 1 Mail Transport Agent (MTA) 1 Mail User Agent (MUA) 1 Mail siehe E-Mail 1

Mail-Verzeichnis (Verwaltung) 1 Mailbox-Dateien 1 MAILER (Makrodefinition) 1 Mailer siehe sendmail, Mailer 1 Mailing-Listen 1 in Exim 1 mailpaths-Datei (/etc/news) 1 mailstats (Befehl) 1 makedbm (Programm) 1 Makrodefinitionen, sendmail.mc (Datei) 1 manuelle Konfiguration Ethernet 1 PLIP 1 Maps, Usenet 1, 2 Marx, Groucho 1 Masquerade Funktionsweise 1 Kernel-Konfiguration 1 Konfiguration 1 Name-Server-Lookups 1 Nebeneffekte von 1 Regeln auflisten 1 Zeitparameter setzen für 1 Master-Server 1, 2 Maximum Receive Unit (MRU) 1 Maximum Transfer Unit (MTU) 1, 2 Maximum Transmission Unit (MTU) 1, 2 IP 1 Meer, Sven van der 1 metrische Werte (Einträge in Routing-Tabellen) 1 mgetty (Programm) 1 Middelink, Pauline 1 mil-Domain 1 MIME (Multipurpose Internet Mail Extensions) 1 Format 1 minicom (Terminal-Programm) 1 Modem, Einwahl nach Bedarf 1 Modems Links, Kommunikationssoftware für 1 ständige Einwahl 1 Verbindungen, Konfigurieren mit dip 1 Morris, G. Allan 1 mount (Befehl) 1 mountd (Dämon) 1 Mounten des /proc-Dateisystems 1 ein NFS-Volume 1 MRU (Maximum Receive Unit) 1

MTU siehe Maximum Transfer Unit 1 Multimedia-Mail 1 Multimedia-Post 1 MX (DNS-Record) 1, 2 Myklebust, Trond 1 N Nachrichten, E-Mail, Mail 1 Name-Server 1 Aufrufe 1 autoritativ 1-2 autoritative 1 Cache 1 caching-only 1, 2, 3 für IP-Masquerade 1 konfigurieren 1 nur cachende 1 primärer 1, 2 Root 1 Root- 1 sekundäre 1 sekundärer 1 synchronisieren 1 Test 1 Name-Server-Konfiguration 1 Name-Servers, Slave 1 Datei named.boot 1 Datei named.conf 1 named-Programm 1, 2 Namenssuche, via DNS 1 Namespace (DNS) 1 NAT (Network Address Translation) 1, 2 nationale Zeichensätze in elm 1 NCP (Network Control Protocol) 1 NCPFS (NetWare Core Protocol FileSystem) 1 Kernel-Konfiguration 1 ~/.nwclient (Datei) 1 Server-Emulation 1 Volumes mounten 1 ncpmount (Befehl) einfaches Beispiel 1 Kommandozeilenoptionen 1 komplexes Beispiel 1 NCSA Telnet 1 Net-1 1 Net-2d 1

Net-2Debugged 1 Net-2e-Protokoll 1 Net-3 1 Net-3-Protokoll 1 Net-4-Protokoll 1 net-Domain 1 netfilter IP tables und 1 Kernel-Module 1 Netnews siehe News (Netzwerke); Usenet 1 NetRom-Protokoll 1, 2, 3 netstat-Befehl 1, 2 Verbindungen anzeigen 1 NetWare 1 Druckerwarteschlange, Drucken in 1 NetWare Core Protocol (NCP) 1 NetWare Directory Service (NDS) 1 Network File System siehe NFS 1 Network Information System siehe NIS 1 Network News Transfer Protocol siehe NNTP 1 Networking initialisieren 1 Netzwerk-HOWTO 1 Netzwerk-News siehe News (Netzwerk) 1 Netzwerkdateien 1 Netzwerke 1 ARPANET 1 booten 1 Dienste 1 Dienste siehe Ports 1 Einführung in 1 Ethernet 1 Ethernet- 1 Geräte 1 Hardware, Konfiguration 1 Initialisierungsskripten 1 Interfaces siehe Interface 1 Internet- 1 IP-Adresse 1 Kerneloptionen 1 Linux 1 Local Area 1 Paßwörter 1 Paßwörter synchronisieren 1 packet-switching 1 paketorientiert 1 Ports 1 private 1

Programmierschnittstelle 1 Protokolle 1 TCP/IP 1, 2 TCP/IP siehe TCP/IP 1 Thinnet 1 Token Ring 1 unerreichbare 1 Unternehmens- 1 UUCP 1 UUCP siehe UUCP 1 verbinden 1 verbinden siehe Internetworking 1 Verbindungen anzeigen 1 Verbindungen siehe Netzwerke, Port 1 Netzwerken, Namen von 1 Neuling, Michael 1 newgroup (Steuermeldung) 1 newnews-Befehl (NNTP) 1, 2 News (Netzwerk) 1 active (Datei) 1, 2 active-Datei aktualisieren 1 alte Gruppen entfernen 1 Artikel 1 Batch-Betrieb 1 Header/Nachrichteninhalt ermitteln 1 löschen 1 Listing 1 News schieben (Pushing) 1 Posten 1 Artikel archivieren 1 Artikel löschen 1 Austausch 1 austauschen 1, 2 Batch-Betrieb 1 C-Release siehe C-News 1 Distribution 1 empfangen 1 Expiring 1 fälschen 1 Flooding-Algorithmus 1 Gruppen 1 History 1, 2 ihave/sendme 1 Internet News 1 Löschen alter News 1 Löschen von 1 Message-IDs 1, 2

neue Gruppe hinzufügen 1 Newsmaster 1 NNTP 1, 2 schieben (Pushing) 1, 2 spool 1 Stapelverarbeitung (Batching) 1 Steuermeldungen 1 Usenet 1 Verteilung (Distribution) 1 Weitergabe (Feeding) 1-2 weitergeben (Feeding) 1 Weiterleitung (Feed) einschränken 1 ziehen (Pulling) 1, 2 News (Usenet) siehe Usenet, News 1 News empfangen 1 News schieben (Pushing) 1, 2 News ziehen (Pulling) 1 News, C siehe C-News 1 Newsfeeds 1 Newsfeeds konfigurieren 1 newsfeeds-Datei (INN) 1, 2 newsgroups Datei (/etc/news) 1 Usenet 1 newsgroups-Datei (INN) 1 Newsgruppen 1 Artikel auflisten 1 auflisten 1 auswählen 1 comp.mail.uucp 1 comp.protocols.ppp 1 comp.protocols.tcp-ip.domains 1 entfernen 1 erzeugen 1 Konfiguration 1 löschen 1 Liste 1 Liste von Artikeln 1 Newsmaster 1 Newsreader INN (Internet News) 1 Wechsel in NNRP-Reader-Modus 1 Zugriffskontrolle 1 newsrun (Befehl) 1 NFS (Network File System) 1 Blockgröße einschränken 1 C News 1

Dämonen 1 exports (Datei) 1 hart mounten versus weich mounten 1 Kernel-basierter Server-Support 1 Prüfung von UIDs und GIDs 1 Timeout 1 UIDs und GIDs prüfen 1 via TCP/IP 1 Volume exportieren 1 Volume mounten 1 Volumes mounten an 1 NFS-Volume exportieren 1 nfsd (Dämon) 1 NFSv2/NFSv3-Server-Support 1 NIS (Network Information System) 1, 2, 3 Clients 1, 2 Datenbanken 1 Domains 1, 2 GNU libc 1, 2 Map 1 Maps erzeugen 1 passwd (Maps) 1 Resolver und 1, 2 securenets-Option 1 Server 1 Server lokalisieren 1 Shadow-Paßwörter 1 Sicherheit 1, 2 Spitzname 1 Zuordnungen (Maps) 1 NIS+ 1 nnrp.access-Datei (INN) 1 nnrpd-Befehl (INN) 1, 2 NNTP (Network News Transfer Protocol) 1, 2 article (Befehl) 1 Autorisierung 1 body (Befehl) 1 C News 1 group (Befehl) 1 Gruppen auflisten 1 head (Befehl) 1 ihave (Befehl) 1, 2, 3 leafnode 1 list (Befehl) 1 list active (Befehl) 1 listgroup (Befehl) 1 newnews (Befehl) 1, 2

post (Befehl) 1 Verbindung mit einem News-Server herstellen 1 Wechsel in NNRP-Reader-Modus 1 Zugriff beschränken 1, 2 nntpd 1 Installation des NNTP-Servers 1 Komponenten 1 nntpsend.ctl-Datei (INN) 1 nntp_access (Datei) 1 Noorda, Ray 1 Novell Corporation 1 nprint (Befehl) 1 lpd benutzen (Line-Printer-Dämon) 1 nsend (Befehl) 1 nslint-Programm 1 nslookup-Prrogramm 1 Nur cachende Name-Server 1 NYS 1 O Oja, Joanna 1 Oktette 1 Online-Hilfe 1 Open Source Writers Guild 1 OpenProjects IRC Network 1 org-Domain 1 OSPF-Protokoll (Open Shortest Path First) 1 OSTYPE (Makrodefinition) 1 OSWG (Open Source Writers Guild) 1 P Paßwörter NetWare-Paßwörter verstecken 1 netzwerkweit 1 Remote-Login und 1 PACKET-FILTERING-HOWTO 1 PAD (Packet Assembler Disassembler) 1 Page, Greg 1 Paket-Radio 1 paketorientierte Netzwerke 1 PAP (Password Authentication Protocol) 1, 2 Parallel Line IP siehe PLIP-Protokoll (Parallel Line IP) 1 Parallelport Ethernet- 1 IP 1

Password Authentication Protocol siehe PAP 1 pathalias (Befehl) 1-2 pathalias (Datei) 1 paths (Datei) 1, 2 PC/TCP-Kompatibilität 1 PGP (Pretty Good Privacy) 1 Ping Flooding 1 ping-Befehl 1 PLIP-Protokoll (Parallel Line IP) Routen 1 Schnittstelle 1 Treiber 1, 2 plip1-Device 1 plipconfig-Befehl 1 Point-to-Point Protocol siehe PPP 1 Point-to-Point-Link 1 Pomerantz, Ori 1 portmap (Dämon) 1 Portmapper, Dämon 1 Ports 1 COM- 1 Ports siehe Netzwerke, Port 1 post-Befehl (NNTP) 1 PPP (Point-to-Point Protocol) 1, 2, 3, 4, 5, 6 Async-Map 1 Authentifizierung 1 CHAP benutzen 1 CHAP nutzen 1 Chat-Skript 1 Dämon 1 Daten komprimieren 1 Datenkomprimierung 1 Default-Route 1 dynamische Adreß-Zuweisung 1 Einwahl nach Bedarf konfigurieren für 1 erweiterte Konfigurationen 1 IP-Adressen 1, 2 IPX-Transfer 1 Lock-Datei 1 Maximum Receive Unit 1 Optionsdateien 1 PAP benutzen 1 PAP nutzen 1 Proxy-ARP 1 Routen 1 Routing 1 Secrets-Dateien 1

Server konfigurieren 1 Setup debuggen 1 Sicherheit 1 Ständige Einwahl konfigurieren für 1 Steuerzeichen durch Escape-Sequenzen ersetzen 1 Treiber 1 PPP-HOWTO 1 ppp0 (PPP-Schnittstelle) 1 ppp1-Device 1 pppd (PPP-Kernel-Modul) 1, 2, 3 .ppprc (Datei) 1 pqlist (Befehl) 1 pqstat (Befehl) 1 Prüfen ARP-Tabellen 1 Erreichbarkeit 1, 2 Ethernet-Schnittstellen 1 IP-Routing-Tabelle 1 Mail-Queue 1 Mail-Warteschlange 1 Netzwerk Konfiguration 1, 2 Schnittstelle 1 Verbindungen 1 Netzwerk-, Schnittstelle 1 Routing-Tabelle 1 TCP-Server-Aktivität 1 UUCP 1 Prüfung NIS 1-2, 3 NNTP 1 primary-Option (BIND) 1 print-Befehl 1 private IP-Adressen 1 private Schlüssel 1, 2 /proc/filesystems (Datei) 1 /proc/kmsg (Datei) 1 Datei/proc/net 1 /proc/net/ipx_route (Datei) 1 Programme, Installation 1 protocols (Datei) 1 Protokoll AX.25- 1 PLIP- 1 Protokolle 1 ATM (Asynchronous Transfer Mode) 1, 2 AX.25 1, 2, 3 Beziehungen zwischen XNS, Novell und TCP/IP, XNS, Novell und TCP/IP 1

CSLIP 1 Ethernet- 1 Frame Relay 1 HDLC 1 ICMP 1 Internet (IP) 1 Internet Datagram Protocol (IDP) 1 Internet Packet eXchange (IPX) 1, 2, 3 NetRom 1, 2, 3 NetWare Core Protocol (NCP) 1 NNTP 1 OSPF 1 PPP 1, 2 Rose 1, 2, 3 Routing Information Protocol (RIP) 1, 2 Sequenced Packet eXchange (SPX) 1 Sequenced Packet Protocol (SPP) 1 Service Advertisement Protocol (SAP) 1, 2 SLIP 1, 2, 3 SMTP 1 TCP 1 Token-Passing 1 UDP 1 UUCP 1 X.25 1, 2 XNS 1-2 Protokollnummern 1 Proxy-ARP 1, 2, 3 Prozentzeichen (in Mail-Adressen) 1 PTR (DNS-Record) 1 Punkt-zu-Punkt-Verbindung 1-2, 3, 4 Q Quellen für Linux-Quellcode 1 R RARP (Reverse Address Resolution Protocol) 1-2, 3 rc-Skript 1 Real-time Blackhole List (RBL) 1, 2 RedHat (Linux distribution) 1 relaynews (Befehl) 1 Remote Ausführung 1 Dateisystem 1 Dateizugriff 1, 2

Login 1, 2 über TCP/IP 1 TCP/IP 1 X Window-Sitzung 1 Remote Procedure Call siehe RPC 1 Repeaters 1 resolv.conf (Datei) 1 Resolver Anwendung eines Name-Servers 1 Anwendung von NIS 1 Benutzung eines Name-Servers 1 Bibliothek 1-2 Konfigurieren 1 Robustheit 1 Umgebungsvariablen 1-2 Resolvers, Benutzung des NIS- 1 RESOLV_ADD_TRIM_DOMAINS-Umgebungsvariable 1-2 RESOLV_HOST_CONF-Umgebungsvariable 1-2 RESOLV_MULTI-Umgebungsvariable 1-2 RESOLV_OVERRIDE_TRIM_DOMAINS-Umgebungsvariable 1-2 RESOLV_SERV_ORDER-Umgebungsvariable 1-2 RESOLV_SPOOF_CHECK-Umgebungsvariable 1-2 Resource-Record (RR) 1 Reverse Address Resolution Protocol siehe RARP 1 Reverse Mapping 1 Rewrite-Regeln (sendmail) 1 RFC-793 1 RFC-821 1, 2 RFC-822 1, 2, 3-4 Namen 1 RFC-974 1 RFC-1036 1 RFC-1123 1 RFC-1341 1 RFC-1700 1 RIP (Routing Information Protocol) 1, 2, 3, 4 RIP (Routing Information Protocol) siehe auch Routing Information Protocol 1 rmail (Befehl) 1 rmgroup (Steuermeldung) 1 rnews (Befehl) 1, 2, 3 Root-Domain 1 Rose-Protokoll 1, 2, 3 round-trip-Zeit (IP) 1 Route, Default 1, 2, 3 route-Befehl 1-2, 3, 4 routed (Befehl) 1 Routen

dynamisches 1 Proxy-ARP 1 Routers 1 Routing über PPP 1 Dämon 1 dynamisch 1, 2 dynamisches 1, 2 E-Mail siehe E-Mail, Routing 1 ICMP-Redirect 1 IP 1 Datagramme siehe IP, Routing 1 Gateways 1 IPX (Internet Packet eXchange) 1 metrisch 1, 2 Metrisches 1 Protokolle 1 Smart-Host- 1 Routing Information Protocol (RIP) 1, 2, 3, 4, 5 Routing-Tabelle 1 Ausgabe via netstat 1 rpc (Datei) 1 RPC (Remote Procedure Call) 1 Ports auf Programme abbilden 1 Programmnummern 1 rpc.mountd (Dämon) 1 rpc.nfsd (Dämon) 1, 2 rpc.portmap (Dämon) 1 rpcinfo (Befehl) 1 RR (Resource-Record) 1 RS-232 serielle Schnittstelle 1 rsmtp Befehl 1 Programm 1 RTS/CTS (Ready to Send/Clear to Send) 1 Running Linux 1 Rusling, David A. 1 Russell, Paul 1 S Salz, Rich 1 Schlüssel öffentlich 1, 2 Host- 1 privat 1, 2 Schlüssel-Fingerprints 1

Schnittstellen 1, 2, 3 Alias 1 AX.25- 1 Dummy 1 Ethernet- 1, 2 IPX konfigurieren 1 Konfiguration von 1 Loopback- 1, 2 Netzmaske 1, 2, 3, 4 PLIP- 1, 2 PPP 1 PPP- 1, 2 SLIP- 1, 2 Statistiken, Anzeige 1 Token Ring 1 Schnittstellen/Interfaces 1 scp (Befehl) 1, 2 securenets (Option) 1 sed (UNIX-Befehl) 1 sekundäre Option (BIND) 1 Semantik der Regelsätze (sendmail) 1 sendbatches (Befehl) 1 sendmail 1, 2 Betrieb 1 E-Mail-Aliasnamen 1 hoststat (Befehl) 1 installieren 1 Konfiguration testen 1 Konfigurationsdateien 1 m4 (Optionen) 1 mail spool verwalten 1 Mail-Aliasnamen 1 Mail-Statistiken analysieren 1 Mail-Verzeichnis verwalten 1 mailstats (Befehl) 1 Management-Tools 1 Optionen (Konfiguration) 1 Rewrite-Regeln 1 Semantik der Regelsätze 1 Smart Host (Konfiguration) 1 Transportarten siehe sendmail, Mailer 1 virtuelles E-Mail-Hosting 1 virtuelles Mail-Hosting 1 virtusertable (Feature) 1 Warteschlangen abarbeiten 1 wichtige Konfigurationen 1 Zugriffsdatei 1

sendmail.cf (Datei) 1, 2 erzeugen 1 R- und S-Befehle 1 sendmail-Optionen konfigurieren 1 sendmail.df (Datei) 1 sendmail.mc (Datei) 1 Parameter 1 zwei Beispiele 1 .Sequence (Datei) 1 Sequenced Packet eXchange (SPX) 1 Sequenced Packet Protocol (SPP) 1 Serial Line, Zeichenschutz 1 Serial Line IP siehe SLIP; PPP 1 serielle Geräte Konfiguration 1 Zugriff auf 1 serielle Leitung Gerätedatei 1 Hardware-Handshake 1, 2 Server inetd 1 Kernel-basierter Support 1 Master 1 Master- 1 nfsd (Dämon) 1 NIS 1 NNTP 1 rpc.nfsd (Dämon) 1 Slave 1 Slave- 1 tcpd (Dämon-Wrapper) 1 UUCP 1 ypserv (Befehl) 1 Service Advertisement Protocol (SAP) 1, 2 services (Datei) 1 services.byname (Map) 1 setnewsids (C News) 1 setserial-Befehl 1 Setzen Domainname 1 Hostname 1 IRQ 1 Shadow-Paßwörter und NIS 1 Sicherheit 1 Angriffsmethoden 1 Ethernet 1 falsche Hostnamen 1 Filterung 1

Firewalls 1 Netzwerk 1 NIS 1 PPP 1, 2 Remote-Login 1 SLIP 1 Spoofing 1 System 1 TCP-Server 1-2 UUCP 1 Simple Mail Transfer Protocol (SMTP) siehe SMTP 1 Sites 1 Leaf 1 Skahan, Vince 1 sl0 (SLIP-Schnittstelle) 1 sl1-Device 1 Slackware (Linux distribution) 1 slattach-Programm 1 Slave-Server 1, 2 SLIP (Serial Line IP), Anwender aufrufen lassen 1 SLIP-Protokoll (Serial Line IP) 1, 2, 3 Betrieb 1 Routen 1 Schnittstelle 1 Treiber 1 SLIPDISC (line discipline) 1 sliplogin-Programm 1 slist (Befehl) 1 slogin (Befehl) 1, 2 Smart Host (Konfiguration) 1 Smart-Host-Routing 1 SMART_HOST (Makro) 1 SMTP (Simple Mail Transfer Protocol) 1 Batch 1 Batch-Betrieb 1 Dienst 1 SOA (DNS-Record) 1, 2 Sockets 1 Source-Routing 1 Source-Routing (Adresse) 1 Spamming 1, 2 Spencer, Henry 1 Spoofing Attacken 1 Vorbeugen 1 Spool-Verzeichnis 1 Spooling 1

ssh (Befehl) Clients 1 Clients starten 1 Konfiguration 1 sshd (Dämon) 1 ssh-keygen (Hilfsmittel) 1, 2 ssh-Tools 1 .ssh/authorized_keys (Datei) 1 sshd (Dämon) 1 ständige Einwahl 1 Standalone Host 1-2 Standard-E-Mail-Route 1 Standard-IP-Route siehe IP (Internet Protocol), Standardroute 1 Standard-Mail-Route 1 Stapelverarbeitung (Batching), News 1, 2 Start of Authority 1 Stover, Martin 1, 2 stty-Befehl 1 Subdomains 1 DNS 1, 2 Subnetze DNS, erzeugen 1 IP 1-2, 3 sudo-Befehl 1 Super-Server inetd 1 SuSE (Linux distribution) 1 Synchronisation von Name-Servern 1 sys-Datei (/etc/news) 1 syslog 1, 2, 3 Systemsicherheit 1 Systemverwaltung 1 T Taylor UUCP 1 über TCP/IP 1 Accounts 1 als Server konfigurieren 1 Alternates 1 Alternativen 1 Anonymous 1 Aufrufreihenfolge prüfen 1 Befehlsausführung 1 Call Sequence Check 1 Chat-Skripten 1 Dateitransfer 1 Device 1, 2

dial (Datei) 1 dialcode (Datei) 1 Direktverbindung 1 einschränken Dateitransfer 1 Forwarding 1 Einschränkung Befehlsausführung 1 Rufzeit 1 Einwählen 1 Forwarding 1 Gerät 1, 2 Handshake 1 HDB 1 Herauswählen 1 Hostname 1 Hostnamen 1 Job 1-2 Konfigurationsdateien 1, 2 Logdateien und Debugging 1 Logging und Debugging 1 Login 1, 2 Login einrichten 1 Login-Chat 1 Login-Sicherheit 1 Mail 1 Mapping Project 1 Master 1 Modem 1, 2 News 1 passwd (Datei) 1 port (Datei) 1 Prüfen 1 Prioritäten 1, 2 Protokolle 1 Einstellen 1 Tuning 1 Remote-System 1, 2 Rufsequenz-Prüfungen 1 Rufzeit 1 Slave 1 Spool-Klassen 1, 2 Spool-Verzeichnis 1 Statistik 1 sys (Datei) 1 Telefonnummer 1 uucico 1

Wiederholungsintervall 1 Taylor, Ian 1 TCP (Transmission Control Protocol) 1 UUCP 1 Wrapper-Programm 1 TCP/IP (Transmission Control Protocol/Internet Protocol) Accounting 1 Firewalls 1 Netzwerke 1, 2 Netzwerke konfigurieren 1 Pakete komprimieren 1 Paketkomprimierung 1 tcpd (Dämon-Wrapper) 1 Telefon Daten senden über 1 Daten senden per 1, 2 Einwahl nach Bedarf 1 Telefone, ständige Einwahl 1 Terminal-Programme 1 Test Hostnamen 1 Name-Server 1 sendmail (Konfiguration) 1 Testen Netzwerkkonfiguration 1, 2 PPP 1 TFTP (Trivial File Transfer Protocol) 1, 2 TFTP (Trivial File Transfer Protocol) 1 Thümmler, Swen 1 Thinnet 1 TNC (Terminal Node Controller) 1 Token Ring ARP und 1 Netzwerke 1 Treiber 1 TOS-(Type-Of-Service-)Bits, Manipulation 1 tr0-Device 1 Transmission Control Protocol siehe TCP 1 Transport E-Mail 1 Mail 1 Treiber ArcNet- 1 D-Link- 1 Ethernet 1 Ethernet- 1 FDDI- 1 PLIP- 1

PPP 1 PPP- 1 SLIP- 1 Token-Ring- 1 Tridgell, Andrew 1 tripwire-Befehl 1 Trivial File Transfer Protocol siehe TFTP 1 T'so, Theodore 1 ttys 1 Betriebsmodus 1 line discipline 1, 2 Verbindungsmodus 1 U UART 1 UDP (User Datagram Protocol) 1 Umgebungsvariable, DISPLAY 1 Umgebungsvariablen DISPLAY 1-2 Resolver 1-2 unerwünschte Mail verwalten 1 unerwünschte Mail, Verwaltung 1 Unix-to-Unix Copy siehe UUCP 1 Unterstützung, online 1 unzustellbare E-Mail 1 unzustellbare Mail 1 Urlichs, Matthias 1 Usenet 1 Map-Dateien 1 Maps 1 User Datagram Protocol (UDP) 1 User Datagram Protocol siehe UDP 1 user groups 1 /usr/lib/uucp/passwd (Datei) 1 uucico (Befehl) 1, 2 Kommandozeilenoptionen 1 UUCP 1 Anonymous 1 E-Mail 1 E-Mail-Routing 1 Exim-Schnittstelle zu 1 Fehlersuche 1 Jobs 1 Mail 1 Mail-Routing 1 Map-Dateien 1

Mapping Project 1 Netzwerke 1 News 1 Prüfen 1 Protokolle 1 Auswahl 1 Sicherheit 1 Taylor siehe Taylor-UUCP 1 uucp-Domain 1 uucpxtable 1 uuwho (Befehl) 1 uux (Befehl) 1 V Van-Jacobson-Header-Komprimierung 1, 2 Verbindungsmodus 1 VERSIONID (Makrodefinition) 1 Verwaltung, System 1 virtuelles Mail-Hosting Mails an andere Zieladressen weiterleiten 1 Mails für andere Domains akzeptieren 1 virtusertable-Feature (sendmail) 1 volle Benutzernamen 1 Vos, Jos 1 W Wahl einer NIS-Domain 1 NIS-Maps 1 Warteschlangen 1 Welsh, Matt 1 Wirzenius, Lars 1 Wrapper, TCP 1 X X Window 1 X.25-Protokoll 1, 2 XDR (External Data Representation) 1 Xerox Corporation 1 Xerox Network Specification (XNS) 1 XNS (Xerox Networking System) 1-2 Y

Ye Olde ARPAnet Kludge 1 Yellow Pages (YP) 1 yp-linux (Befehl) 1 ypbind (Befehl) 1 ypcat Befehl 1 Hilfsmittel 1 yppasswd 1 ypserv (Befehl) 1 Yutaka, Niibe 1 Z Zeichensatz in elm 1 Zen 1 zentrale Mail-Verwaltung 1, 2 zentralisierte Mail-Verwaltung 1 Zonen, DNS siehe DNS (Domain Name System), Zonen 1 Zonendateien 1 Zugriff auf Remote-Dateien 1 beschränken 1, 2 einschränken 1, 2 ermöglichen 1 gewähren 1, 2 NNTP 1 PPP 1 UUCP 1 Zugriff auf Netzwerk-Hardware siehe Interfaces 1

Weitere Informationen zum Linux - Wegweiser für Netzwerker Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center

O'Reilly Home|O'Reilly-Partnerbuchhandlungen|Bestellinformationen Kontakt|Über O'Reilly|Datenschutz © 2001, O'Reilly Verlag