Dieses Handbuch wird mit freundlicher Genehmigung von Sebastian Hetze auf den Servern der Linux Information Systems AG gehosted.

next up previous contents index
Next: Der Newsreader tin Up: Datenreisen und reisende Daten Previous: Usenet News

Subsections


INN

INN besteht aus einer ganzen Reihe von Dienstprogrammen und einer Art Chef-Programm, dem Dämon innd. Diese Programme befinden sich zusammen mit diversen Hilfsdateien im Verzeichnis /usr/lib/news. Außerdem gibt es noch das Verzeichnis /var/spool/news, kurz Newsspool  genannt. Hier werden unter anderem die einzelnen Artikel abgelegt.

innd wird beim Booten des Rechners gestartet und läuft von da an im Hintergrund, bis Sie den Rechner wieder herunterfahren. Diese Methode beschleunigt die Bearbeitung von News ganz erheblich, weil auf diese Weise die Statusdateien nicht für jeden ankommenden Newsbatch neu gelesen werden müssen, sondern nur einmal beim Start des Dämons. Zu den Aufgaben von innd  gehört es, alle hereinkommenden Artikel zu bearbeiten, lokal abzuspeichern und gegebenenfalls an andere Programme weiterzugeben, z.B. zur Archivierung oder zum Transport an Nachbarsysteme.

Andere wichtige Komponenten von INN sind rnews,  inews  und nnrpd.  Wenn ein anderes System per UUCP einen Newsbatch an Sie schickt, wird der bei der Ankunft auf Ihrem System von rnews in Empfang genommen, der die einzelnen darin enthaltenen Artikel an innd übergibt. inews ist das Pendant dazu: wenn Sie von Ihrem Newsreader aus einen Artikel posten, vervollständigt er die Header-Informationen und reicht ihn dann an innd weiter. nnrpd schließlich bedient Newsreader, die über NNTP auf das Newssystem zugreifen. Direkte NNTP-basierte Feeds werden von innd selbst bedient. Die einzelnen Komponenten kommunizieren über Netzwerk-Sockets miteinander.

Abbildung 7.12 zeigt schematisch den Newsfluß durch INN. In der oberen Hälfte des Bildes sehen Sie die Einlieferung von News über rnews und inews angedeutet. Die Ellipse soll eine Netzverbindung über UUCP symbolisieren.[*] In der unteren Hälfte ist dargestellt, auf welchen Wegen Informationen von innd weitergegeben werden; wir werden uns mit diesen Komponenten gleich eingehender beschäftigen.


  
Abbildung: Newsfluß durch INN
\begin{figure}
 \begin{center}
 \leavevmode
 \epsfysize7cm\epsfbox{abbildungen/news1.eps}
 \end{center}\end{figure}

Wenn innd einen Artikel empfängt, prüft er zunächst anhand der Message-ID, ob er ihn schon einmal bearbeitet hat oder nicht. Falls sich die ID bereits in der Datei /usr/lib/news/history findet, verwirft er sie einfach. Handelt es sich aber wirklich um einen neuen Artikel, legt innd ihn lokal ab und stellt stellt anhand der Datei /usr/lib/news/newsfeeds fest, ob er ihn außerdem an andere Sites weitergeben, ihn archivieren und eventuell noch ganz andere Dinge mit ihm anstellen soll.

Artikel werden unterhalb des Verzeichnisses /var/spool/news gespeichert (dem Newsspool, wie schon erwähnt). Jeder Newsgruppe entspricht ein Verzeichnis, in dem jeder Artikel in einer separaten Datei abgelegt wird. Die Dateinamen sind fortlaufende Nummern, so daß ein Artikel in comp.risks beispielsweise in comp/risks/217 abgelegt wird. Die jeweils letzte Artikelnummer einer Gruppe vermerkt INN in der Datei /usr/lib/news/active.

Soll ein Artikel über UUCP an ein anderes System weitergegeben werden, sagen wir cicero, legt INN den Dateinamen in der Datei out.going/cicero im Newsspool ab. Diese Datei wird später vom Batchskript send-uucp gelesen, das die Artikel in einen oder mehrere Batches verpackt und über UUCP an cicero weiterschickt.

Nach soviel Theorie werden wir jetzt etwas konkreter und wenden uns der eigentlichen Installation zu. Wir beschränken uns hier auf eine ganz einfache Konfiguration eines UUCP-Systems mit nur einem Newsfeed. INN kann natürlich noch eine ganze Menge mehr, aber eine ausführliche Beschreibung all dieser Möglichkeiten würde wohl den Rahmen dieses Buches sprengen. Falls Sie mehr über INN wissen wollen, empfehlen wir Ihnen die (englischsprachige) Dokumentation, die zur INN-Distribution dazugehört, sowie die monatlich in news.answers und news.software.b gepostete INN-FAQ.[*]

INN und IP-Networking

Eine der Schwierigkeiten, die Anfänger manchmal mit INN haben, ist die Tatsache, daß die einzelnen Komponenten von INN über Netzwerkverbindungen (Sockets) kommunizieren - auch, wenn sich alles nur auf einer einzelnen Maschine abspielt.[*] Sie brauchen also für den Betrieb von INN einen Kernel mit zumindest minimalen Netzwerkfähigkeiten. In diesem Kapitel werden Sie deshalb einem Crash-Kurs in Sachen Netzwerk-Konfiguration unterzogen. Aus Platzgründen kann ich nur beschreiben, wie Sie das tun - für Erklärungen reicht's leider nicht aus. Wenn Sie sich für diese Details interessieren, lege ich Ihnen (nicht ohne rot zu werden) den Linux Network Administrator's Guide ans Herz.

Wenn Sie Ihren Rechner bereits für eine Art von Networking konfiguriert haben, brauchen Sie sich um die meisten Dinge in diesem Abschnitt nicht zu kümmern. Die einzige Ausnahme gilt für Maschinen, deren einzige Netzverbindung ein SLIP- oder PPP-Link ist; sie sollten unbedingt das Dummy-Device konfigurieren, wie im folgenden beschrieben. Wenn Sie bisher noch überhaupt keine Netzwerksoftware installiert haben, sollten Sie das jetzt nachholen.

Anschließend müssen Sie den Kernel neu übersetzen, wie in Kapitel beschrieben. Bei der Konfiguration müssen Sie die Frage nach TCP/IP Networking mit y beantworten. Bei den Netzwerktreibern sollten Sie das Dummy-Device einschalten, wenn Sie keine permanente IP-Verbindung zur Außenwelt haben. Das Dummy-Device ist eine Art ``Haken'', an dem Sie eine IP-Adresse festmachen können.

Anschließend müssen einige Konfigurationsdateien angepaßt werden. Achten Sie darauf, daß in der Datei /etc/hosts der volle Hostname Ihres Rechners (mit Domain) eingetragen ist:

# Beispiel-Datei /etc/hosts
# IP-Adresse       Name(n)
127.0.0.1          localhost
192.168.1.1        isis.in-berlin.de isis

Die seltsamen Nummern in der linken Spalte sind IP-Adressen; sie werden vom Netzwerk benutzt, um Rechner weltweit eindeutig zu identifizieren. Wenn Sie nicht netzwerktechnisch bereits ans Internet angebunden sind, werden Sie sicherlich keine solche Adresse haben. Woher also nehmen wenn nicht stehlen? Das ist nicht weiter schwierig; die Adresse 127.0.0.1 müssen Sie sowieso für den Namen localhost verwenden (das gehört so). Und wenn Sie sowieso nicht ans Internet angeschlossen sind, muß die Adresse Ihrer Maschine auch nicht mehr eindeutig sein; Sie können also getrost die aus dem Beispiel übernehmen.[*]

Als nächstes editieren Sie die Datei /etc/rc.d/rc.inet1; hier muß sinngemäß folgendes stehen:

# Beispiel-Datei /etc/rc.d/rc.inet1.
# Konfiguration des Loopback-Device
/sbin/ifconfig lo localhost
/sbin/route add -net 127.0.0.0

# Konfiguration des Dummy-Device
/sbin/ifconfig dummy isis
/sbin/route add isis

Wenn Sie Slackware benutzen, müssen Sie außerdem noch die Dateien NETWORKING und HOSTNAME im Verzeichnis /etc anpassen; die erste muß einfach den String yes enthalten; die andere den vollen Hostnamen (in unserem Beispiel also isis.in-berlin.de).

Administrativer Kleinkram

Damit INN auf Ihrem System problemlos laufen kann, müssen zunächst einige Vorbedingungen erfüllt sein.

Als erstes müssen auf Ihrem System ein Benutzer und eine Gruppe namens news existieren. Alle Dateien und Programme, die Teil von INN sind, müssen diesem Benutzer und zu dieser Gruppe gehören. Das ist sehr wichtig; sollten Sie einmal aus Versehen eine Datei einem anderen Benutzer zuordnen, kann sie dadurch für INN unzugänglich werden und so Ihr gesamtes Newssystem lahmlegen. Aus diesem Grunde sollten Sie alle Operationen, die INN betreffen, als news ausführen, wenn nicht anders beschrieben. Ausnahmen sind der Start des Newssystems über rc.news (dieses Skript muß als root laufen) und ctlinnd (dieses Programm dürfen Sie auch als root aufrufen). Beide Programme werden in späteren Abschnitten noch ausführlicher besprochen.

Im folgenden werden Befehle, die Sie als root ausführen können, durch root# gekennzeichnet; solche, die Sie als news aufrufen müssen, werden durch den Shell-Prompt news$ gekennzeichnet. Für letztere ist es nicht unbedingt nötig, sich auch tatsächlich als news einzuloggen. Folgende Methode ist recht bequem, um ein Kommando als news aufzurufen:

root# su news -c "kommando"
root# _

Verschiedene zu INN gehörige Programme schicken dann und wann eine Mail an die News-Administratorin, beispielsweise, um auf ein Problem hinzuweisen. Diese Nachrichten werden an den Benutzer newsmaster geschickt. Sie sollten für diese Adresse einen Alias in der Datei   /usr/lib/aliases eintragen, der auf die für die Wartung von INN zuständige Person zeigt:

# newsmaster-Alias in /usr/lib/aliases
newsmaster:	karla

Außerdem sollten Sie darauf achten, daß die Programme inews und rnews ``im Pfad'' stehen, das heißt, daß Benutzer sie aufrufen können, ohne den vollen Pfadnamen angeben zu müssen. Üblicherweise legt man dafür symbolische Links von /usr/bin oder /usr/local/bin an, die auf die tatsächlichen Programm verweisen. Wenn Ihr INN aus einer Linux-Distribution stammt, sollte das eigentlich von der Installationsprozedur erledigt werden. Das ist aber nicht immer der Fall. Prüfen Sie deshalb nach, ob diese Links existieren; wenn nicht, legen Sie sie mit den folgenden Befehlen an:

root# cd /usr/bin
root# ln -s ../lib/news/rnews rnews
root# ln -s ../lib/news/inews inews
root# _

Schließlich sollten Sie darauf achten, daß die für den Betrieb von INN nötigen Systemressourcen vorhanden sind. INN benötigt im laufenden Betrieb je nach Größe Ihres Newsfeeds mindestens 1.5 Megabyte Swapspace für den Dämon innd und eventuell zugehörige Prozesse wie overchan. Die allermeisten Sites werden mit diesen 1.5 MB auskommen; auf großen Systemen kann innd aber auch wesentlich ``fetter'' werden und 8 MB oder mehr benötigen.

Außerdem benötigen Sie einiges an Plattenplatz. Ein wesentlicher Faktor ist der Newsspool. Wenn Sie nur einen kleinen Feed von ein paar Dutzend Newsgruppen durchschnittlicher Größe haben und die meisten Artikel nach wenigen Tagen wieder weggeworfen werden, können Sie durchaus mit 20 MB auskommen. Der Normalfall wird aber eher bei ca. 40 MB und darüber liegen.[*] Zusätzlich benötigen Sie auf der Platte, auf der sich das Verzeichnis /usr/lib/news befindet, neben dem Platz für die Programme, Skripte und so weiter (ca. 2.5 MB) noch mindestens 1 MB für die Datei history.

Globale Parameter

Die Haupt- und Staatskonfiguration des INN findet in der Datei /usr/lib/news/inn.conf statt. Hier wird unter anderem der Hostname festgelegt, unter dem Ihr Rechner im Usenet firmiert. Das ist in den meisten Fällen Ihr voller Domainname; vereinzelt wird hier aber auch noch der UUCP-Name verwendet. 

# inn.conf - Beispiel fuer isis.in-berlin.de
#
server:          isis.in-berlin.de
domain:          in-berlin.de
moderatormailer: %s@uunet.uu.net
organization:    Lives in Limbo

Die erste Zeile dieser Beispieldatei legt fest, mit welchem Host die Programme rnews und inews Kontakt aufnehmen, wenn sie einen Artikel oder Batch an innd abliefern wollen. In unserem Fall bleibt ihnen keine andere Wahl als isis selbst.

Das zweite Attribut legt den Namen der Domain fest, in der der Rechner sich befindet. Dieses Attribut müssen Sie nicht unbedingt angeben, da innd meist in der Lage ist, den vollen Systemnamen aus /etc/hosts zu erfragen.[*]

Die nächste Zeile gibt eine Adresse an, an die Artikel für moderierte Newsgruppen geschickt werden sollen. Ein Artikel, den Sie in die moderierte Gruppe soc.feminism posten, wird dann von INN automatisch an soc-feminism@uunet.uu.net geschickt. Auf UUNET gibt es für jede moderierte Usenet-Gruppe einen passenden Alias, der Ihren Artikel dann an die richtige Person weiterleitet.[*]

Das Attribut organization legt den Text fest, den INN in das Organization:-Feld jedes Artikel-Headers einfügt, der auf Ihrer Maschine gepostet wurde. Wenn Sie nicht gerade einen Ruf zu verlieren haben, gilt es durchaus als chic, hier dem eigenen Sinn für Humor freien Lauf zu lassen.

Neben inn.conf müssen Sie auch noch die Dateien hosts.nntp und nnrp.access für Ihr System anpassen, die den Zugang zu Ihrem Newssystem festlegen. hosts.nntp regelt, welche Systeme News über rnews und direkte NNTP-Verbindungen einliefern dürfen, während nnrp.access für das Posten von Artikeln über inews und NNTP-basierte Newsreader zuständig ist.

Auf einem System wie isis ist es nicht sonderlich interessant, den Zugriff auf INN einzuschränken; diese Mechanismen entfalten Ihre volle Wirkung erst auf einer Internet-Site. Um aber selbst News posten zu können, müssen Sie zumindest Ihre eigene Maschine in diesen Dateien eintragen, weil sich INN sonst schlichtweg weigert, Artikel von irgendwem anzunehmen.

Die Konfiguration von hosts.nntp für isis sieht so aus: 

# /usr/lib/news/hosts.nntp fuer isis
isis.in-berlin.de:

Fast genauso simpel ist nnrp.access: 

# /usr/lib/news/nnrp.access fuer isis
isis.in-berlin.de:Read Post:::*

Ich will hier nicht auf die Bedeutung der einzelnen Felder eingehen; wenn Sie sich mit diesen Mechanismen beschäftigen wollen, finden Sie die nötigen Informationen in den Manual-Seiten nnrp.access(5) und hosts.nntp(5).

Die Dateien active und newsgroups

  

Über die active-Datei findet die Buchhaltung des Newssystems statt. Sie enthält Informationen über den aktuellen Status jeder einzelnen Newsgruppe. Ein Ausschnitt aus einer active-Datei stellt sich beispielsweise so dar:

de.comp.databases 0000000813 0000000803 y
de.comp.dtp 0000000586 0000000577 y
de.comp.gnu 0000001469 0000001462 y
de.comp.graphik 0000001121 0000001108 y
de.comp.lang.c 0000002398 0000002334 y
de.comp.lang.c++ 0000001790 0000001761 y
de.comp.lang.forth 0000000270 0000000268 y
de.comp.lang.lisp 0000000039 0000000040 y
de.comp.lang.misc 0000000374 0000000358 y
de.comp.lang.pascal 0000001824 0000001776 y

Jede Zeile beginnt mit dem Namen der Newsgruppe. Die folgenden zwei Zahlen geben jeweils die höchste und niedrigste Nummer der aktiven Artikel in dieser Gruppe an. Enthält die Gruppe im Augenblick keine Artikel, ist die zweite Zahl um eins höher als die erste. Das letzte Feld enthält ein Flag, das den Status der Gruppe festlegt. Am häufigsten wird Ihnen dabei y für ``yes'' begegnen, was bedeutet, daß lokale Postings in diese Gruppe erlaubt sind. n verbietet das, läßt aber immer noch zu, daß die hereinkommenden Artikel von anderen Systemen im Newsspool abgelegt werden, und m bezeichnet eine moderierte Gruppe. Daneben gibt es noch die Flags x, j und =, die aber so gut wie nie benötigt werden. Die Bedeutung dieser Flags finden Sie in der Manpage active(5) erklärt.

innd liest diese Datei beim Start ein und behält sie während der gesamten Laufzeit teilweise im Speicher. Sie sollten diese Datei also niemals editieren, während INN läuft! Die Folge ist meistens ein heilloses Durcheinander, das sich nur unter größten Verrenkungen beheben läßt.

Bei der Erstkonfiguration Ihres Systems sollten Sie sich eine aktuelle active-Datei von Ihrem Newsfeed besorgen. Sie können sie getrost unverändert installieren; wenn Sie wollen, können Sie aber auch vorher noch die Artikelnummern zurücksetzen. Das geht beispielsweise mit den folgenden Befehlen:

root# cd /usr/lib/news
root# sed 's/ [0-9]* [0-9]* / 000000000 000000001 /' active > active.new
root# mv active.new active
root# chown news.news active
root# chmod 644 active
root# _

Wenn Sie die active-Datei installieren, sollten Sie sicherstellen, daß es die Newsgruppen junk und control enthält. junk ist so etwas wie der Mülleimer Ihres Newssystems. Ein Artikel wird dann in junk abgelegt, wenn keine der Gruppen, in die er gepostet wurde, in Ihrer active-Datei vorkommt. Sie sollten deshalb ab und zu in junk hineinschauen; wenn die Gruppe nicht leer ist, sollten sie die fehlenden Gruppen entweder bei Ihrem Feed abbestellen oder sie lokal einrichten (wie, wird in Abschnitt 7.7.9 erklärt).

Die Gruppe control dient als Ablage der sogenannten Control-Messages, die ebenfalls in Abschnitt 7.7.9 behandelt werden.

Zu guter Letzt sollten Sie sich ein aktuelles Exemplar der Datei newsgroups besorgen. Sie wird zwar von INN nicht gebraucht, ist aber trotzdem für Ihren Newsreader ganz nützlich. Diese Datei enthält nämlich zu jeder Gruppe eine Kurzbeschreibung in wenigen Worten. Viele Newsreader zeigen diesen Text in der Übersicht der Newsgruppen an, so daß Sie sich schneller orientieren können.

Wer bekommt was - newsfeeds

  

Die Datei newsfeeds stellt den zentralen Verteiler von INN dar. Hier wird vor allem festgelegt, welche Newsgruppen an welche Sites weitergegeben werden. Beachten Sie, daß newsfeeds nichts darüber aussagt, was für Gruppen Ihr Feed an Sie ausliefert - das wird ausschließlich in dessen newsfeeds-Datei festgelegt.[*]

Eine Beispielkonfiguration für isis sieht so aus:

# Beispiel-Konfiguration newsfeeds fuer isis.in-berlin.de
#
ME\
        :!*/!local\
        ::

# cicero.lunetix.de - unser groesster und einziger Newsfeed
cicero/cicero.lunetix.de,news.lunetix.de\
        :*,!junk,!local/!local\
        :Tf,Wfb:

Einträge in dieser Datei bestehen aus vier Feldern, getrennt durch Doppelpunkte. Das erste Feld enthält den Namen des Feeds, z.B. cicero. Dem Namen folgt optional eine Ausschlußliste, abgetrennt durch einen Schrägstrich. Bevor innd einen Artikel an einen Feed weitergibt, überprüft er anhand der Path:-Zeile im Header, ob der Artikel bereits über diese Site gelaufen ist. Dabei bezieht er nicht nur den Namen des Feeds (hier also cicero), sondern auch die der Sites in die Ausschlußliste (d.h. cicero.lunetix.de und news.lunetix.de) mit ein.

Das zweite Feld enthält die Liste aller Newsgruppen und Hierarchien, die an den Feed weitergereicht werden. Da es etwas unhandlich wäre, alle Newsgruppen einzeln aufzuführen, werden hier bestimmte Ausdrücke, sogenannte wildmat-Patterns, angegeben. Diese Ausdrücke funktionieren so ähnlich wie die Wildcards in der Shell, d.h. comp.* trifft auf alle Untergruppen der Hierarchie comp zu, und comp.os.v* auf Gruppen wie comp.os.v und comp.os.vms. In newsfeeds können Sie mehrere dieser Patterns in einer Liste kombinieren, wie beispielsweise de.*,!de.comp.sys.*. Dieser Ausdruck wählt alle Gruppen in der Hierarchie de mit Ausnahme der Gruppen unterhalb von de.comp.sys aus.

Zur Liste der Newsgruppen gehört auch noch eine Liste von gültigen Distributionen; das ist der Teil nach dem Schrägstrich. Sie können nämlich im Artikel-Header eine Distribution:-Zeile angeben, die die Verteilung des Artikels weiter einschränken soll. So gab es eine Zeitlang eine Distribution de, die sicherstellen sollte, daß Artikel den deutschsprachigen Teil des Usenet nicht verlassen. Diese Distributionen sind aus verschiedenen Gründen aus der Mode gekommen.[*] Die einzige Distribution, der allgemein noch eine Daseinsberechtigung zugestanden wird, ist local.

Schauen wir uns jetzt unser Beispiel an, so werden diese kryptischen Zeilen etwas klarer: wir geben an cicero alle Newsgruppen außer von junk und local weiter (das ist der Teil *,!junk,!local). Eine Ausnahme sind Artikel mit der Distribution local, sie werden auf gar keinen Fall weitergereicht (das ist der Teil mit /!local).

Das dritte Feld eines Eintrags in newsfeeds enthält diverse Flags, die INN mitteilen, um was für eine Art Feed es sich handelt. Es ginge hier zu weit, die Bedeutung dieser Flags im einzelnen zu erklären; Details finden Sie in der Manpage newsfeeds(5).

Im Falle von cicero besagen die Flags Tf,Wfb, daß INN die Pfadnamen der zu sendenden Artikel in einer Datei ablegen soll. Der voreingestellte Standardname für die Datei ist /var/spool/news/out.going/cicero. Sie können aber im letzten Feld des Eintrags einen anderen Namen angeben, wenn Sie wollen. Uns ist der Default aber ganz recht, da wir die Liste der Artikel später mit dem Batcher bearbeiten wollen; dieses Programm erwartet die Datei eben in out.going. Das b in Wfb bewirkt, daß innd neben dem Pfadnamen auch noch die Länge des Artikels in Bytes ablegt; dadurch kann der Batcher die Größe der ausgehenden Batches genauer berechnen.

Jetzt sind wir so lange auf dem cicero-Eintrag herumgeritten; was hat es denn nun mit ME auf sich? Der Eintrag ME spielt eine besondere Rolle, er enthält die Default-Liste der Newsgruppen, die an andere Sites weitergegeben werden dürfen. Angenommen, Sie haben lokal die Newsgruppe secret eingerichtet, in denen Sie mit Ihren Kollegen über das Rezept für den perfekten Taco diskutieren; dann brauchen Sie nur *,!secret ins Newsgruppenfeld von ME einzutragen, um zu verhindern, daß diese Gruppe weiterverbreitet wird. Ansonsten hat der ME-Eintrag (was ehemalige C News-Benutzer vielleicht etwas überraschen wird) keine weitere Bedeutung.[*]

Leben und Sterben des innd

Wie bereits erwähnt, wird innd beim Booten des Systems gestartet. Das geschieht durch das Skript rc.news. In den meisten Linux-Distributionen wird das Skript nicht automatisch ausgeführt, sondern Sie müssen diesen Aufruf noch von Hand in eines der rc-Skripte einfügen. Ein günstiger Platz dafür ist in /etc/rc.d/rc.local, zum Beispiel durch den folgenden Befehl:

# start INN
if [ -x /usr/lib/news/etc/rc.news ]; then
    /bin/sh /usr/lib/news/etc/rc.news
fi

Da wir vom Booten reden, paßt es ganz gut, uns auch gleich mit dem umgekehrten Vorgang zu befassen. Beim Herunterfahren des Systems schickt das shutdown-Kommando allen Prozessen das TERM-Signal. Der unschöne Nebeneffekt ist, daß syslogd meist vor innd die Arbeit einstellt, so daß innd eine ganze Reihe bedrohlich wirkender Meldungen auf den Bildschirm ausgibt. Wenn Sie das vermeiden wollen, können sie INN vorher ordnungsgemäß herunterfahren. Das geschieht durch das folgende Befehlspaar:

root# /usr/lib/news/bin/ctlinnd throttle "system shutdown"
root# /usr/lib/news/bin/ctlinnd shutdown "system shutdown"
root# _

Der Befehl ctlinnd ist sozusagen Ihr Sprachrohr, wenn Sie sich zur Laufzeit mit Ihrem innd unterhalten wollen. Die Wirkung des Befehls shutdown brauche ich wohl nicht weiter auszumalen. Interessant ist aber das Kommando throttle - es ``drosselt'' den Server. In diesem Zustand akzeptiert innd keine weiteren NNTP-Verbindungen mehr und bearbeitet auch die bestehenden Verbindungen nicht. Damit können auch rnews und inews keine Artikel mehr einliefern.

ctlinnd ist aber nicht nur zum Herunterfahren des Servers nützlich. Sollte es einmal nötig werden, eine Datei wie /usr/lib/news/history zu editieren,[*] müssen Sie dazu nicht extra das Newssystem herunterfahren. Stattdessen können Sie folgende Befehle eingeben:

root# cd /usr/lib/news
root# bin/ctlinnd throttle "edit history"
root# vi history
....
root# bin/ctlinnd reload history "fixed corruption"
root# bin/ctlinnd go "edit history"
root# _

Der go-Befehl hebt eine vorhergehende Drosselung des Servers wieder auf.

Die Strings, die hier bei jedem Befehl mit angegeben werden, werden von innd an syslogd übergeben; sie sollten den Grund für die Drosselung usw. bündig benennen. Der genaue Wortlaut des Texts ist aber völlig nebensächlich. Die einzige Bedingung ist, daß Sie beim go-Kommando denselben Grund angeben wie beim vorhergehenden throttle.

Das Kommando reload veranlaßt innd, die angegebene Datei neu zu laden. Neben history sind noch Parameter wie active, newsgroups oder all gültig.

Ein ausgehender Newsfeed über UUCP

Wir haben im vorletzten Abschnitt bereits gesehen, was Sie in newsfeeds eintragen müssen, um Artikel an ein anderes System weitergeben zu können. Das ist aber nur die halbe Geschichte, denn innd tut zunächst nichts anderes, als die Pfadnamen und Größe der Artikel in einer Datei einzutragen - für cicero war das out.going/cicero im Newsspool. Sie muß zu einem späteren Zeitpunkt vom Batcher weiterverarbeitet werden, der die genannten Artikel in einen oder mehrere Batches verpackt und auf die Reise zu cicero schickt.

Bei INN ist das zentrale Stück dieses Mechanismus das Programm batcher. Es wird aber meist nicht direkt aufgerufen, sondern über Shell-Skripte, die noch einige Magie drumherum veranstalten.[*] Ein solches Skript ist send-uucp, dem Sie beim Aufruf den Namen des Systems übergeben, für das es die Päckchen schnüren soll:

news$ send-uucp cicero
news$ _

Auch hier ist es wichtig, daß send-uucp nur unter der Benutzer-ID news läuft. Am sinnvollsten ist es, send-uucp in regelmäßigen Abständen von cron aus aufzurufen. Wir zeigen in Abschnitt 7.7.11 ein Beispiel hierfür.

send-uucp greift sich die Datei out.going/cicero und verfüttert sie an batcher, der daraus einen komprimierten Newsbatch erzeugt. Die fertigen Batches werden mittels UUCP an das Kommando rnews auf cicero übermittelt. UUCP überträgt die Daten aber nicht umgehend, sondern spoolt sie nur. Die tatsächliche Übertragung findet erst dann statt, wenn Sie das nächste Mal die Verbindung zu cicero aufbauen.

send-uucp ist leider nicht optimal und bietet bei weitem nicht den Komfort, den ehemalige C News-Benutzer von ihrem sendbatches gewöhnt sind. Zu seinen Schwächen gehört, daß Sie Parameter wie die maximale Größe der Batches nur für alle Nachbarsysteme gleich einstellen können, und das auch nur, wenn Sie das Skript editieren. Es ist also wirklich nicht für viel mehr geeignet, als auf einer kleinen Leafsite[*] die lokal erzeugten Artikel ``stromaufwärts'' zu seinem Newsfeed zu transportieren. Für größere Systeme empfiehlt es sich, per FTP das sendbatches-Paket von grasp.univ-lyon1.fr zu besorgen.

Hier ist der Ort, darauf hinzuweisen, daß in manchen Linux-Distributionen das Programm compress ein symbolischer Link auf gzip ist. Traditionell wird zum Komprimieren der Batches compress benutzt, dessen Komprimierung mit der von gzip nicht kompatibel ist. Das kann bei der Kommunikation mit Newssystemen, die kein Linux fahren, Probleme bereiten. Die korrekte Lösung des Problems ist hier, den symbolischen Link zu löschen und stattdessen das richtige compress zu installieren.

Löschen von Artikeln mit expire

 

Wenn Sie vermeiden wollen, daß Ihre Festplatte nach kürzester Zeit überläuft, müssen Sie regelmäßig alte Artikel löschen. Dafür ist bei INN das Programm expire zuständig. Sie sollten es mindestens einmal täglich laufen lassen, bei höherem Aufkommen auch öfter. Eine mögliche Art, es aufzurufen, ist diese:

news$ cd /usr/lib/news
news$ bin/ctlinnd throttle "running expire"
news$ bin/expire -s -v1
news$ bin/ctlinnd go "running expire"
news$ _

Achten Sie darauf, daß Sie expire nur als Benutzer news aufrufen. Wenn Sie das als root tun, können unter Umständen die Zugriffsrechte für einige Dateien so verändert werden, daß andere Teile von INN nicht mehr darauf zugreifen können, was für alle Seiten fatale Folgen hat.

Dieser Aufruf löscht alle ``alten'' Artikel aus Ihrem Newsspool (wir werden gleich sehen, wie alt ``alt'' ist). Die Flags -s und -v1 erzeugen zusätzliche Ausgaben über die Anzahl der gelöschten Artikel, den derzeit verbrauchten Plattenplatz usw. Eine ganze Reihe weiterer Flags finden Sie in der Manual-Seite expire(8) erklärt.

Die Arbeit von expire wird über die Datei expire.ctl gesteuert. Hier können Sie für einzelne Newsgruppen oder -hierarchien angeben, nach wievielen Tagen Artikel in diesen Gruppen weggeworfen werden. Sie sollten mit diesen Werten ruhig experimentieren; neben dem vorhandenen oder nicht vorhandenen Plattenplatz ist es vor allem eine Frage der persönlichen Vorlieben, welche Newsgruppen Sie länger vorhalten und welche nicht.

Auf isis könnte expire.ctl so aussehen:

## expire.ctl
## So lange wird die Message-ID in der history aufgehoben:
/remember/:14

## Default: 2 Tage
*:A:1:2:2

## junk und control verschwinden umgehend
junk:A:1:1:2
control:A:1:1:2

## die groesseren Hierarchien
sci.*,comp.*:A:1:2:14
de.*:A:1:4:30
alt.*:A:1:1:30

## comp.os.linux.* bleibt etwas laenger
comp.os.linux*,comp.unix.*:U:1:7:31
comp.os.linux*,comp.unix.*:M:1:14:31

Im ersten Feld jeder Zeile begegnen uns die wildmat-Patterns wieder, die Sie bereits in der Datei newsfeeds gesehen haben. Sie legen fest, auf welche Gruppen der jeweilige Eintrag zutreffen soll, der Ausdruck sci.*,comp.* betrifft beispielsweise alle Newsgruppen der Hierarchien sci und comp. expire ``durchsucht'' die Datei sequentiell und verwendet dabei für eine bestimmte Gruppe jeweils die letzte passende Zeile. Ein Artikel in comp.os.linux.announce würde von der letzten Zeile gematcht, obwohl einige Zeilen weiter oben bereits ein Eintrag für die ganze Hierarchie comp auftaucht.

Auf den wildmat-Ausdruck folgen vier weitere Felder, die durch Doppelpunkte voneinander getrennt sind. Das wichtigste ist das vorletzte, das angibt, wieviele Tage ein Artikel aus dieser Gruppe im Normalfall vorgehalten wird. Es ist wichtig zu wissen, daß ab dem Zeitpunkt des Eintreffens auf Ihrem System gerechnet wird, nicht ab dem Zeitpunkt, als der Artikel gepostet wurde.

Das dritte und fünfte Feld legen die Mindest- und Höchstdauer fest, die ein Artikel in Ihrem Newsspool bleiben darf. Das erscheint auf den ersten Blick widersinnig - wenn alle Artikel nach fünf Tagen weggeworfen werden, wie soll dann nach einem Monat immer noch einer übrig sein?!

Das hängt mit einem weiteren Feld im Artikel-Header zusammen, mit dem Sie die Lebensdauer eines Artikels künstlich hochsetzen können, der Expires:-Zeile. Bei manchen Artikeln ist es durchaus erwünscht, daß sie länger aufgehoben werden als gewöhnliche Artikel, zum Beispiel bei periodisch geposteten Informationen wie den Einführungen in de.newusers oder der Linux-FAQ. Diese Artikel erhalten vom Absender ein ausdrückliches Verfallsdatum in Expires: mit auf den Weg, das von Ihrem Newssystem ausgewertet wird. Ein solcher Artikel wird erst dann gelöscht, wenn entweder das festgesetzte Verfallsdatum erreicht ist, die Maximalzeit, die Sie ihm in expire.ctl zugestanden haben, abgelaufen ist, oder eine neuere Version der FAQ eingetroffen ist.[*]

Die minimale Lebenszeit eines Artikels, die in Feld drei enthalten ist, hat eine verwandte Funktion. Sie verhindert, daß ein Artikel sofort weggeworfen wird, wenn das Datum im Expires-Header schon abgelaufen wird, wenn er Ihr System erreicht. Das kommt selten genug vor, und es gibt kaum einen Grund, diesen Wert höher als einen Tag anzusetzen.

Jetzt können Sie einen Eintrag wie de.*:A:1:4:30 fast vollständig entziffern: der Eintrag betrifft alle Gruppen unter de und wirft das Gros der Artikel nach 4, spätestens aber nach 30 Tagen fort. Jeder Artikel wird aber mindestens einen Tag vorgehalten.

Was noch fehlt, ist die Bedeutung des zweiten Feldes. Es enthält ein Flag, mit dem Sie noch einmal zwischen moderierten und unmoderierten Gruppen differenzieren können. Ein M schränkt den Eintrag auf moderierte Gruppen ein, ein U auf unmoderierte. Ein A ignoriert den Unterschied. In den letzten beiden Zeilen unseres Beispiels sehen Sie eine Anwendung dieser Flags.

comp.os.linux*,comp.unix.*:U:1:4:31
comp.os.linux*,comp.unix.*:M:1:14:31

Artikel in moderierten Untergruppen von comp.os.linux und comp.unix[*] werden hier erst nach zwei Wochen gelöscht, während solche aus unmoderierten Gruppen bereits nach 4 Tagen verschwinden.

Ein besonderer Eintrag in expire.ctl verdient noch unsere Beachtung; das ist die Zeile, die mit /remember/ beginnt. Sie legt fest, wie lange sich INN eine Message-ID in der Datei history merkt. Würde INN nämlich die ID eines Artikels sofort wieder entfernen, sobald expire diesen gelöscht hat, könnte es passieren, daß ein Artikel ein zweites Mal akzeptiert wird, falls er noch einmal vorbeikommt.[*]

In unserem Beispiel ist der remember-Wert auf 14 Tage eingestellt. Das ist ganz sinnvoll für eine kleine Site wie isis, wo die meisten Duplikate (wenn sie mal auftreten) bereits von cicero abgefangen werden.

Control-Messages

  Es kommt gelegentlich vor, daß neue Newsgruppen eingerichtet oder alte gelöscht werden. Das geschieht im Usenet automatisch über sogenannte newgroup und rmgroup Control-Messages. Sie werden wie gewöhnliche Artikel durchs Usenet transportiert, unterscheiden sich aber durch eine zusätzliche Headerzeile namens Control:. Sie enthält den Typ der Control-Message und eventuelle Parameter. Für die Einrichtung von de.comp.os.tunix müßte der Artikel etwa folgende Zeile enthalten:

Control: newgroup de.comp.os.tunix

Neben newgroup und rmgroup gibt es noch einige andere Control-Messages, z.B. cancel zum nachträglichen Löschen eines Artikels durch den Absender, oder etwas exotischere wie sendsys, senduuname und checkgroups.

INN bearbeitet diese Nachrichten halbautomatisch. Das Canceln von Artikeln erledigt innd meist selbständig, während newgroup und rmgroup meist als Mail an die administrative Adresse news gesendet werden. Diese Mail enthält neben dem ursprünglichen Artikel auch den korrekten Aufruf von ctlinnd, mit dem Sie die Gruppe dann auch tatsächlich einrichten können. Beispielaufrufe zum Einrichten und Entfernen der Newsgruppe local.test sehen so aus:

root# ctlinnd newgroup local.test y root@isis.in-berlin.de
root# ctlinnd rmgroup  local.test
root# _

Sie können INN allerdings auch damit beauftragen, diese Aufgaben für bestimmte Hierarchien automatisch zu erledigen, wenn als Absender des Artikels der dafür zuständige (d.h. gewählte) ``Netzgott'' auftaucht. Für die sieben großen Hierarchien ist das David Lawrence (tale@uu.net); für de ist das zur Zeit Wilhelm Bühler (news@roka.de). Sie können INN in der Datei control.ctl mitteilen, welchen Control-Messages Sie vertrauen:

# control.ctl - Beispiel

# Default: mail an Administrator
all:*:*:mail

# newgroup
newgroup:*:*:mail
newgroup:news@roka.de:de.*:doit=mail
newgroup:tale@uu.net:comp.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:doit=mail

# rmgroup
rmgroup:*:*:mail
rmgroup:news@roka.de:de.*:doit=mail
rmgroup:tale@uu.net:comp.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:doit=mail

# ihave/sendme wird weggeworfen
ihave:*:*:drop
sendme:*:*:drop

# sendsys, senduuname und version sind harmlos
sendsys:*:*:doit=mail
senduuname:*:*:doit=mail
version:*:*:doit=mail

Das Beispiel zeigt eine einfache control.ctl-Datei. Das Flag doit=mail besagt, daß die betreffende Control-Message ausgeführt und anschließend eine Mail an den Administrator geschickt wird. Bei mail wird nur eine Mail geschickt, und bei drop schließlich ignoriert INN die Aufforderung ganz. An der länglichen newgroup-Zeile sehen Sie beispielsweise, daß der Befehl ausgeführt wird, wenn er eine Newsgruppe unterhalb der Großen Sieben betrifft und von tale@uu.net stammt.

Overview-Dateien

  Zum Grundrepertoire aller Newsreader gehört es, der Benutzerin eine Übersicht aller derzeit verfügbaren Artikel in einer Newsgruppe anzuzeigen. Im einfachsten Falle enthält die Liste jeweils den Absender und den Titel (d.h. das Subject) des Artikels. Manche Newsreader gruppieren außerdem noch zusammengehörige Artikel der Übersichtlichkeit wegen in sogenannten threads (Diskussions``fäden'').

Das bedeutet, daß der Newsreader von jedem Artikel mindestens einmal den Header einlesen muß, um die wichtigsten Informationen zu extrahieren. Newsreader wie tin bearbeiten auf diese Weise alle neuen Artikel, wenn Sie sich die Übersicht über eine Newsgruppe anzeigen lassen. Das kann bei großen Gruppen schon einmal eine Minute oder länger dauern; beim Newslesen über NNTP sind auch fünf Minuten nicht unmöglich.

Um diesen etwas unbefriedigenden Zustand zu beseitigen, entwarf Geoff Collyer 1992 NOV, das News Overview System. Das ist keine eigenständige Applikation oder ähnliches, sondern ein Datenformat. Das Newssystem, in unserem Fall also INN, legt die wichtigsten Headerzeilen eines hereinkommenden Artikels in einer separaten Datei namens .overview im Spoolverzeichnis der jeweiligen Newsgruppe ab. Newsreader müssen jetzt nur noch eine, nämlich die Overview-Datei einlesen, um an die komplette Header-Information aller Artikel zu gelangen.[*] Das macht das Leben mit tin deutlich bequemer.

Damit INN diese Overview-Dateien erzeugt, müssen Sie in newsfeeds einen weiteren Feed eintragen. Er sieht üblicherweise so aus:

# NOV: News Overview Database
@overview:*:Tc,WO:/usr/lib/news/bin/overchan

Dieser Eintrag übergibt die NOV-Daten für Artikel in allen Gruppen (das Newsgruppen-Feld enthält *) an das Programm overchan. Dieses wertet die Informationen nun aus und legt sie in den entsprechenden .overview-Dateien ab.[*]

Nachdem Sie diesen Eintrag an Ihr newsfeeds angefügt haben, müssen Sie das System noch initialisieren. Dazu rufen Sie (als Benutzer news) folgenden Befehl auf:

news$ /usr/lib/news/expireover -a
news$ _

Das erzeugt für alle Artikel, die sich bereits in Ihrem Newsspool befinden, die nötigen Einträge in den .overview-Dateien. Anschließend veranlassen Sie innd dazu, newsfeeds neu zu laden, so daß die Änderung wirksam wird:

root# /usr/lib/news/bin/ctlinnd reload newsfeeds
root# _

Natürlich muß auch das Overview-System regelmäßig auf den neuesten Stand gebracht werden, d.h. in der Zwischenzeit gelöschte Artikel müssen auch aus der entprechenden .overview-Datei entfernt werden. Das erledigt das Programm expireover für Sie:

news$ /usr/lib/news/bin/expireover -s
news$ _

Und jetzt ohne Hände...

  Nach der anfänglichen Konfiguration können Sie Ihr Newssystem fast vollständig auf Autopilot umstellen, indem Sie alle anfallenden Routine-Jobs über cron abwickeln lassen. Das heißt nicht, daß Sie jetzt die Hände in den Schoß legen dürfen - Sie sollten sich trotzdem von Zeit zu Zeit vergewissern, daß alles auch so läuft wie gewünscht. Dazu gehört, gegelentlich einen Blick in die Logdateien in /var/log/news zu werfen, ob sie irgendwelche Anomalien aufweisen, und sicherzustellen, daß genügend Plattenplatz vorhanden ist. Nichts verträgt nämlich ein Newssystem weniger als keinen Platz: dann wandern unter Umständen alle hereinkommenden Artikel kommentarlos in die Tonne. Wenn Sie Platzprobleme haben, spielen Sie etwas mit den Einstellungen in expire.ctl herum, kaufen sich eine neue Platte oder löschen endlich Ihre DOS-Partition:-)

Das folgende Beispiel zeigt die crontab für den Benutzer news, wie sie auf meinem System im Einsatz ist:

PATH=/usr/lib/news/bin:/usr/lib/news:/bin:/usr/bin
# Der Batcher wird alle 15 Minuten angeworfen:
6-52/15 *       *       *       *       send-uucp brewhq
# Falls rnews Batches rumliegen laesst:
16      *       *       *       *       rnews -U
# taegliche Wartungsarbeiten
10      8       *       *       *       news.daily
# Artikel loeschen mit expire
28      5,15    *       *       *       doexpire

Der erste Eintrag wirft alle 15 Minuten den Batcher an. Natürlich bin ich nicht so ein Vielschreiber, daß in diesem Zeitraum mehr als ein oder zwei Artikel zusammenkommen, aber mir ist es wichtiger, daß ein Artikel beim nächsten Aufbau der UUCP-Verbindung hinausgeht, als daß ich bei der Übertragung 20 Sekunden einspare.

Der Aufruf von rnews dient dazu, übriggebliebene Newsbatches nachträglich an innd einzuliefern. Das geschieht gelegentlich, wenn innd gedrosselt ist, während über UUCP News hereinkommen, da rnews die Batches dann nicht korrekt abliefern kann. Sie werden dann im Newsspool im Verzeichnis in.coming zwischengelagert. Das Flag -U weist rnews an, sich um solche eventuell vorhandenen Dinger zu kümmern.

Das Skript news.daily ist ebenfalls Teil von INN und führt tägliche Routine-Aufgaben durch; zum Beispiel stutzt es Log-Dateien zurecht und überprüft die Konsistenz des Systems. Wie der Name nahelegt, sollte es einmal täglich laufen; wenn Sie das nicht tun, wird INN das beim Systemstart feststellen und eine Mail schicken, in der es sich darüber beklagt.

Der letzte Eintrag dient dem regelmäßigen Löschen alter Artikel. Ich rufe hier nicht expire direkt auf, sondern ein kurzes Shell-Skript, das ich zu diesem Zweck geschrieben habe. Es sieht so aus:

#!/bin/sh
# /usr/lib/news/bin/doexpire - kleiner Wrapper fuer News Expiry

. /usr/lib/news/innshellvars
cd $SPOOL

# Drosseln des Systems
ctlinnd throttle "running expire"

# Artikel wegwerfen ...
expire -s -v1

# ... und .overview-Files auf den aktuellen Stand bringen
expireover -s

# Und weiter geht's
ctlinnd go "running expire"

Es besetzt zunächst eine Reihe von Shell-Variablen, indem es die Datei innshellvars einliest. Anschließend geht es ins Spoolverzeichnis und ruft dort expire auf. Zu guter Letzt bringt es die in Abschnitt 7.7.10 beschriebenen Overview-Dateien auf den neuesten Stand.

 


next up previous contents index
Next: Der Newsreader tin Up: Datenreisen und reisende Daten Previous: Usenet News

Das Linux Anwenderhandbuch
(C) 1997 LunetIX