Im Katalog suchen

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.


vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel



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: %s@uunet.uu.net # # 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:           /var/spool/news/articles pathoverview:           /var/spool/news/overview pathoutgoing:           /var/spool/news/outgoing pathincoming:           /var/spool/news/incoming patharchive:            /var/spool/news/archive pathuniover:            /var/spool/news/uniover overviewname:           .overview

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 News-System 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 soc-feminism@uunet.uu.net 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 active-Datei 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: obergrenzeuntergrenze.

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:

<anzahl

Artikel muß weniger als anzahl Bytes lang sein.

Abegriffe

Artikelprüfungen. begriffe kann eines oder beide der folgenden Zeichen enthalten: d (muß Verteiler-Header haben) und p (nicht auf System im Path-Header prüfen).

Bhoch/niedrig

Interne Puffergröße, bevor in die Ausgabe geschrieben wird.

H[anzahl]

Artikel muß weniger als anzahl Hops haben. Vorgabewert ist 1.

Igröße

Interne Puffergröße (für Zuführung einer Datei).

Mmuster

Nur moderierte Gruppen, die zum Muster passen.

Nmuster

Nur nichtmoderierte Gruppen, die zum Muster passen.

Sanzahl

Spooling starten, wenn mehr als anzahl Bytes in die Warteschlange gelangen.

Ttyp

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 overchan-Befehl ü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 Newsfeed-Mechanismus 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 Groucho-Marx-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 max-connections: 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 INN-News-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 mindauer-Feld.

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 INN-Konfigurationsdateien. 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 datei-Name 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:group-admin@isc.org:*:verify-news.announce.newgroups newgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups newgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups newgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups rmgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify-news.announce.newgroups rmgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify-news.announce.newgroups rmgroup:group-admin@isc.org:talk.*|humanities.*:verify-news.announce.newgroups  ## GNU ( Free Software Foundation ) newgroup:gnu@prep.ai.mit.edu:gnu.*:doit newgroup:news@*ai.mit.edu:gnu.*:doit rmgroup:gnu@prep.ai.mit.edu:gnu.*:doit rmgroup:news@*ai.mit.edu:gnu.*:doit  ## LINUX (Newsfeed von news.lameter.com) checkgroups:christoph@lameter.com:linux.*:doit newgroup:christoph@lameter.com:linux.*:doit rmgroup:christoph@lameter.com: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.


vorheriges Kapitel Inhaltsverzeichnis Stichwortverzeichnis nächstes Kapitel


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