Next: Der Newsreader tin Up: Datenreisen und reisende Daten Previous: Usenet News
Next: Der Newsreader tin
Up: Datenreisen und reisende Daten
Previous: Usenet News
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.![[*]](./icons/foot_motif.gif){kind=icon}
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.
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.
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
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).
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.
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).
Ü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.
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.
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.
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.
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: 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.
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$ _
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.
Das Linux Anwenderhandbuch