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 Support-Programme 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 rnews-Programm 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).¹ 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 UUCP-Feed 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.² 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 innd-Dä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.

Weitere Informationen zum Linux - Wegweiser für Netzwerker

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