[ lamepage · Linux · News · MultiNews ]

Erweiterung von INN um mehrere Newsserver

(anhand der S.u.S.E. - Distribution (inn & suck))

Übersicht:

Vorwort

Bisher waren wir auf ein einzigen News Server angewiesen und zwar den Defaultserver unseres Providers. Es gibt aber im Internet viele public Server wo jeder News lesen und posten kann. Um diese neben dem Stammserver zu erreichen, bedarf es an einer speziellen Konfiguration die nicht gerade einfach ist.
Dieser Text soll eine Erweiterung der Anleitung "Einrichtung eines News-Systems unter Linux" von Carsten Voss bieten. Es ist kein standalone Text der einfach so von einem Anfänger befolgt werden kann. Ich möchte hiermit lediglich eine Hilfe für all die bieten, die aus ihrem INN mehr machen möchten. Der Text richtet sich hauptsächlich an diejenigen, die nur eine DialUp Internetverbindung haben und nicht unbedingt alle Newsgroups herunter laden möchten. Alle hier vorgeschlagene Änderungen sind nur den zu empfehlen, die bereits ein INN System zum laufen gebracht haben und dessen Konfiguration auch einigermaßen verstanden haben. Die so väranderte Konfiguration funktioniert bei mir ohne Probleme und wurde auf die gängige Problemfälle geprüft. Dennoch für eventuele Missfunktionalitäten und Nebenwirkungen übernehme ich keine Garantie, daher Benutzung auf eigene Gefahr. Für Fragen und konstruktive Kritik stehe ich jederzeit zu Verfügung (per eh-mehl :-).

In den folgenden Schritten gehe ich davon aus, daß die Konfigurationsdateien von suck unter /var/lib/news/suck abgelegt sind und daß die INN-Shellvariablen in der innshellvars Datei (meistens in /var/lib/news/etc zu finden) korrekt gesetzt sind, das letztere wird in den meisten Fällen bei der Installation erledigt. Alles was hiernach folgt baut darauf auf, aber es dürfte auch in der Regel kein Problem darstellen alles den abweichenden Gegebenheiten anzupassen. Namen mit runden Klammern mit einer Nummer drin sollen auf die man-Page hinweisen.

Konfiguration

Die nachfolgende Anleitung erklärt die Vorgehensweise in einzelschritten und soll helfen die Zusammenhänge zu verstehen.
Die Konfiguration für mehrere Server beinhaltet das Einrichten der active, newsfeeds und evtl. Anpassen der sucknewsrc Dateien.
Zuerst überlegen wir uns die Feednamen für die Newsserver die dann intern bei uns benutzt werden, wir sollten uns angewöhnen als Newsfeedsnamen, einen eindeutige den Server identifizierende Namen auszuwählen, zB.: Newsserver: news.myhostA.com Feedname: myhostA und Newsserver: news.myhostB.com Feedname: myhostB.
Diese Namen werde ich im Laufe dieser Anleitung allgemein auch als <site> bezeichnen die dann individuell an die jeweilligen Newsserver angepasst werden müssen. Für jeden News-Server werden separate active und sucknewsrc Datei benötigt bzw. angelegt.
Ferner, werde ich folgende (imaginäre) Hostnamen verwenden: news.myhostA.com als den bereits eingerichteten und news.myhostB.com als den, den wir hinzufügen möchten.. Einige Befehle müssen als root ausgeführt werden falls die erforderlichen Rechte nicht vorhanden sind, das betrifft insbesondere ctlinnd.
WICHTIG: wir sollten uns das angewöhnen, jegliche Änderungen am unseren News System als der User news durchzuführen.
Ich würdee es sehr empfehlen im ~news/.profile die PATH Variable um /usr/lib/news/bin/ und /var//lib/news/suck/ zu ergänzen bzw. einzufügen mit: PATH=$PATH:/usr/lib/news/bin:/var/lib/news/suck. Im Laufe meiner Anleitung werde ich davon ausgehen, daß die o.g. Ergänzung gemacht wurde und verzichte hier und dort auf Pfadangaben. Vor die Befehle habe ich meistens ein cd Kommando vorangestellt damit wir jeder Unklarheit bzgl. des Verzeichnisses aus dem Weg gehen.
So, wir fangen nun im /var/lib/news/suck Verzeichnis an (cd /var/lib/news/suck/).

INN

Zum INN gehört ein sehr wichtiges Tool namens: ctlinnd(8), das uns Interaktivitäten während des INN Betriebs erlaubt. Mit diesem Tool werden wir INN zuerst anhalten (evtl. als root) um Änderungen an dessen Konfiguration ungestört machen zu können :

 ctlinnd throttle "configuration"
"configuration" ist ein frei wählbarer Text, der nach jeder Anfrage an den NNTP-Port angezeigt wird und fungiert quasi als das Kennwort das wir später brauchen um INN wieder zu starten.
Hiernach wird INN quasi auf "StandBy" gestellt und weist alle Anfragen an den Port 119 mit der Meldung: "configuration" ab.
Dieses "updating active" sollten wir uns unbedingt merken, denn am Ende unserer Konfiguration wird es nochmals gebraucht.

active

Die active Datei ist maßgebend für den Betrieb von INN und deshalb bedarf sie einer ausführlichen Behandlung.
Es gibt eine globale active Datei, in welcher alle Newsgroups verzeichnet sind, die INN anbieten und akzeptieren soll und eine active.times in welcher alle Veränderungen der active Datei durch ctlinnd geloggt werden. Die active Datei enthält die Namen der Newsgroups, die niedrigste und die höchste Artikelzahl und ein Typebezeichner. Jeweils eine Zeile pro Newsgroup zB:

 alt.test 0000000006 0000000007 y
Als Typebezeichner sind folgende möglich: Die bisherige globale active Datei hatten wir ja schon früher von unserem Stamm-Newsserver geholt. Nun, bei mehreren Newsservern müssen wir alle active-Dateien der entsprechenden Newsserver zusammenfügen. Im Normalfall würden wir die einzelnen Dateien nach dem zusammenfügen gar nicht mehr brauchen, aber im unseren Fall ist es anders, wir brauchen sie um die Herkunft der Newsgroups bestimmen zu können (aber dazu später mehr).
Als erstes besorgen wir uns von jedem Newsserver mit getlist(1) die active-Dateien und speichern wir sie unter /var/lib/news/suck/active.<site>, zB.:
 cd /var/lib/news/suck/
 getlist -h news.myhostA.com >active.myhostA
 getlist -h news.myhostB.com >active.myhostB
 ...
 ...
Falls noch mehr Newsserver zusammengefügt werden sollen, können auch die active-Dateien analog dazu bezogen werden.
Es empfielt sich jedes mal wenn ein neuer Server hizugefügt werden soll, alle active-Dateien neuzubeziehen, damit jegliche Änderungen seitens Anbieter berücksichtigt werden.

Spätestens hier müssen wir uns entscheiden welche Newsgroups von welchen Newsservern "gesaugt" werden sollen. Die neuen active-Dateien geben uns nun Auskunft wo, welche Newsgroups angeboten werden. Damit die globale active Datei zusammengesetzt werden kann müssen zuerst alle doppelten Einträge (dupes, falls eine Gruppe von mehr als einem Newsserver angeboten wird) entfernt werden. Es gibt mehrere Möglichkeiten die doppelten Newsgroupsnamen zu umgehen und zu bestimmen welche Newsgroups von welchen active Dateien übernommen werden sollen:

  1. man kann die active-Dateien unverändert lassen. In diesem Fall werden die doppelt vorhandenen Newsgroups in verschiedenen active-Dateien von den hinzugekommenen überschrieben und der zuletzt eingefügte Newsserver kann somit alle anderen überschreiben, was zu Problemen führen kann falls ein Server eine Newsgroup zwar anbietet aber nicht propagiert. Dieses Verhalten läßt sich mit einem Kommandozeilenparameter beinflußen. Im Bezug auf diese Anleitung, Rate ich auf diese Methode gänzlich zu verzichten.Diese Methode habe ich nur aus theoretischen Gründen erwähnt.
  2. man kann die einzelnen active.<site> Dateien so bearbeiten (Einträge löschen), daß nur die gewünschten Newsgroups übrig bleiben, wobei man gleiche Newsgroupsnamen in verschiedenen active.<site> Dateien vermeiden sollte. Bei active Dateien von zB. 300kB größe ist das eine langwierige Erfahrung. Diese Methode ist nicht besonders empfehlenswert.
  3. man fertigt sich die sogennanten ignore-Files an, für jede active-Datei eine: ignore.<site>. Diese Methode ist auf jeden Fall der beiden ersten vorzuziehen, denn durch diese Dateien wird später ein active-Update zum Kinderspiel. Wie man diese ignore-Files erstellt wird im folgenden erklärt.
Diejenigen die sich trotzdem entschlossen haben die active Dateien per Hand zu verändern oder gar darauf verzichten, können hier weitermachen.

ignore

Die ignore-Files sind Dateien, die anhand einfacher Regeln genau bestimmen welche Newsgroups aus der entsprechenden active-Datei übernommen werden sollen. Wir erstellen sie dort, wo bereits unsere active.<site> Dateien existieren: in /var/lib/news/suck/ignore.<site>. Durch einen sehr einfachen Syntax ist es relativ schnell die Regel festzulegen. Der Syntax einer ignore Datei sieht folgendermaßen aus:

 # comment 
 c  newsgroup [type ...]
 i  newsgroup [type ...]
c - bedeutet "check" und damit wird diese Newsgroup (-herarchie) übernommen,
i - bedeutet "ignore" womit man die Newsgroup (-herarchie) ignoriert,
type - bietet eine zusätzliche Möglichkeit die Newsgroups nach ihrem Typ zu behandeln. Sie entsprechen den von der active-Datei.
Wer noch mehr wissen möchte, sei auf die man-Pages von actsync(8) und active(5) verwiesen.
Hier ist ein Beispiel von ignore-Files, bezogen auf die o.g. Server:

mal angenommen, wir möchten von myhostA die Herarchie de.* (unmoderiert) und alle anderen mit Ausnahme von alt.binaries.* und von myhostB nur rec.*, soc.*, news.* und fido.* beziehen und das alles mit kleinen Bedingungen, damit es spannend wird :-):

Beispiel von /var/lib/news/suck/ignore.myhostA:

 # file: ignore.myhostA
 #
 # all groups will be checked as default, therefore you will needn´t the next entry (c *)
 # c *
 # check all newsgroups from de.* herarchy even if unmoderated, (=ignore moderated)
 c de.*
 i de.* m
 #
 # check all newsgroups from alt.* herarchy besides the alt.binaries.* herarchy
 c alt.*
 i alt.binaries.*
Beispiel von /var/lib/news/suck/ignore.myhostB:
 # file: ignore.myhostB
 #
 # ignore all groups first
 i *
 # check the rec.* herarchy even if local postings are allowed
 c rec.* y
 # check the soc.*, news.* and fido.* herarchy
 c soc.*
 c news.*
 c fido.*
Zu diesem Zeitunkt sollten wir bereits für jeden Server einzelne active.<site> und ignore.<site> Dateien im /var/lib/news/suck/ Verzeichnis haben.
Die active-Dateien werden nun anhand der ignore-Files mit Hilfe von actsync(8) durchgefiltert und somit auf das Zusammenfügen zu der globalen active(5) vorbereitet. Damit wir nicht jedes mal die Parameter eingeben müssen setzen wir uns eine Variable: ACTFLAGS.
Der current path Prefix "./" darf nicht vergessen werden, weil actsync danach unterscheidet, daß es sich um einen Dateinamen und nicht um Hostnamen handelt. Für jeden weiteren Newsserver kann analog dazu verfahren werden:
 # cd /var/lib/news/suck/
 export ACTFLAGS="-b 0 -d 0 -g 0 -o aK -p 0 -q 12 -s 0 -t 0 -v 2"
 actsync -i ignore.myhostA $ACTFLAGS /dev/null ./active.myhostA >active.tmp
 mv active.tmp active.myhostA
 actsync -i ignore.myhostB $ACTFLAGS /dev/null ./active.myhostB >active.tmp
 mv active.tmp active.myhostB
 ...
 ...
Die so veränderten active-Dateien werden nun mit actsync(8) zusammengefügt. Es sei vermerkt, daß falls doch noch doppelte Newsgroupsnamen in den active.<site> Dateien bestehen, werden sie von der zweiten active-Datei  inhaltlich überschrieben (Flag: -o aK). ZB. wenn in der active.myhostA und active.myhostD die Newsgroup de.test vorhanden ist wird die von active.myhostA spätestens dann überschrieben wenn die active.myhostD dazugefügt wird (siehe actsync(5)). Das Zusammenfügen wird folgendermaßen bewerkstelligt:
 # cd /var/lib/news/suck/
 actsync -m $ACTFLAGS ./active.myhostA ./active.myhostB >active.1
Wobei die active.1 unsere zukünftige globale active Datei darstellt, die dann zu /var/lib/news/active verschoben werden muß. Falls weitere Newsserver hizugefügt werden sollen, würde man dieses folgendermaßen fortsetzen:
 actsync -m $ACTFLAGS ./active.1 ./active.myhostC >active.2
 actsync -m $ACTFLAGS ./active.2 ./active.myhostD >active.3
 ...
 ...
An dieser Stelle wäre die active.3 unseres Endprodukt und müsste in die  /var/lib/news/active verschoben werden:
 # cd /var/lib/news/suck/
 mv active.3 ../active
Wir werden vielleicht jetzt festellen, daß wir uns die Schritte mit getlist eigentlich hätten sparen können, wenn wir mittels actsync die active-Dateien direkt von den Newsservern heruntergeladen und gleich zusammengefügt hätten. Jedoch, gibt es zwei gute Gründe es so zu tun wie oben beschrieben:
  1. wie kann man ein ignore-File erstellen wenn man gar nicht weißt welche Newsgroups einem angeboten werden ?
  2. wir werden die fertiggefilterten active-Dateien brauchen um festzustellen welche Newsgroups von welchen Newsservern geladen werden sollen: rebuildrc (siehe Abschnitt "Betrieb")
Damit hätten wir die zukünftige globale active Datei fertig und somit auch festgelegt welche Newsgroups unser INN nun anbietet bzw. akzeptiert.

newsfeeds

Nun wollen wir uns der Konfiguration des newsfeeds File widmen. Hierbei müssen wir darauf achten, welche Gruppen wir zu welchem Servern propagieren möchten. Also es wird dringend geraten sich die manpage zu newsfeeds(5) anzuschauen.
Der Syntax des newsfeed Files ist relativ verständlich:

 sitename[/exclude,exclude,...]\
 :pattern,pattern...[/distrib,distrib...]\
 :flag,flag...\
 :param
oder anders dargestellt:
 sitename/exclude,...:pattern,.../distrib,...:flag,...:param
sitename - ist der Newsfeedname (<site>)
exclude - ist der Name eines Newsservers, der nicht im Path einer Message vorkommen darf, damit sie an diesen Newsfeed weitergeleitet wird, oder anders ausgedrückt: Messages die diesen Host in ihrem Path vorweisen können werden nicht an sitename geschickt. Wichtig, damit man nicht frisch empfangene Artikel zurückschickt, ist zwar nicht so schlimm verursacht aber Traffic.
pattern - die Newsgroups-Pattern, siehe newsfeeds(5)
distrib - siehe newsfeeds(5)
flag - siehe newsfeeds(5)
param - siehe newsfeeds(5)

Ich werde hier nur ein kleines Beispiel der newsfeeds Konfiguration nennen.

mal angenommen, wir möchten an myhostA die Herarchie alle newsgroups mit Ausnahme den vom myhostB und an myhostB nur rec.*, soc.*, news.* und fido.* propagieren:

Beispiel: /var/lib/news/newsfeeds:

 #
 # for my overview
 OVERVIEW!:*:Tc,WO:/usr/lib/news/bin/overchan
 #
 # what I have to accept
 ME:*::
 #
 # newsfeed where I put to myhostA
 myhostA/news.myhostA.com:*,!rec.*,!soc.*,!news.*,!fido.*:!junk,!control:Tf,Wnm:
 #
 # newsfeed where I put to myhostB
 myhostB/news.myhostB.com:!*,rec.*,soc.*,news.*,fido.*:Tf,Wnm:
Wie wir hier sehen, wird bei dem myhostB alles abgewählt (!*) und dann selektiv nur das ausgewählt (rec.*,soc.*,news.*,fido.*) was wir dorthin propagieren möchten. Bei myhostA haben wir das umgekehrte Prinzip, hier wird zuerst alles ausgewählt (*) und dann nur das abgewählt (!rec.*,!soc.*,!news.*,fido.*, !junk, !control) was wir dorthin nicht propagieren möchten.
Damit wäre auch das "Versenden" von News erledigt.

suck

Im folgendem wird davon ausgegangen, daß die get.news, put.news und die sucknewsrc Dateien unter /var/lib/news/suck abgelegt sind.
Damit auch INN mit unseren neuen Newsgroups auch immer mit frischen News von suck(1) beliefert werden kann, müssen wir noch eine Änderung am get.news Script (gehört zum suck-Paket) durchführen. Bisher wurde get.news einfach mit: "get.news" aufgerufen, nun wird sich das bedingt durch die hinzugekommene Newshosts ändern. Es müssen folgende Zeilen gefunden und so geändert werden:

 ...
 SITE=$1        # name of site (newsfeed)
 REMOTE_HOST=$2 # name of remote host
 ...
 # download messages
 ${SUCK} ${REMOTE_HOST} -c -bi ${BATCHFILE} -dt ${TMPDIR} -dm ${MSGDIR} -dd ${BASEDIR} -p .${SITE}
 ...
Für diejenigen, die eine fertige Datei bevorzugen, können sich meinerget.news Version bedienen.
Damit get.news nach dieser Änderung auch News beziehen kann, sollten die sucknewsrc.<site> vorhanden sein. Man kann sie nun mit einem Texteditor editieren oder einfach automatisch mit rebuildrc (siehe Abschnitt "Betrieb") automatisch erstellen lassen.
Das macht den get.news Script auf alle anderen Server anwendbar und macht eine weitergehende Erweiterung zum Kinderspiel.
Falls irgendeine sucknewsrc.<site> Datei nicht vorhanden sein sollte ist es auch nicht weiter schlimm. Get.news verabschiedet sich hierbei nur mit einer Fehlermeldung.
Hiermit haben wir das "Empfangen" von News aus verschiedenen Newsservern möglich gemacht. Nach dieser Änderung wird get.news folgendermaßen aufgerufen: "get.news <site> <newsserver>" zum Beispiel:
 /var/lib/news/suck/get.news myhostA news.myhostA.com
 /var/lib/news/suck/get.news myhostB news.mahostB.com
 ...
 ...
Hierbei können wir jetzt ein Script namens /var/lib/news/suck/news erstellen, der als Inhalt o.g. Aufrufe enthält. Den Script könnten wir dann in der /etc/ppp/ip-up (pppd) aufrufen lassen. Es vereinfacht die Administration und erlaubt dem User news zu bestimmen welche NewsServer nun wirklich gespoolt werden sollen, sonst wären hierbei die root-Rechte nötig um die ip-up zu verändern.
Damit INN unsere Änderungen berücksichtigt, müssen wir ihm zuerst die neue Dateien mitteilen:
 ctlinnd reload all "for newshost add"
hier angefürtes "for newshost add" wird lediglich für Log-Zwecke benutzt und hat nichts mit unserem "configuration"-String zu tun.
Dann müssen wir INN wieder aktivieren:
 ctlinnd go "configuration"
Da wir jetzt die globale active-Datei verändert haben stimmen auch unsere "low-water" Nummern nicht mehr, deswegen ist es sehr wichtig diese auf den richtigen Stand zu bringen. Dafür lassen wir jetzt INN alle Artikel im Spool-Verzeichnis durchzählen und die aktuelle "low-water" Nummern in die neue active Datei eintragen (das "" ist wichtig damit ctlinnd alle Newsgroups durchzählt):
 ctlinnd renumber ""
So, hiermit haben wir unsere Konfiguration in Einzelschritten vollzogen. Es war ein wenig umfangreich und kompliziert aber notwendig um die Zusammenhänge ein wenig zu durchschauen.
Ich werde jetzt bewusst kein Script zum automatischen Hinzufügen von Newshosts anbieten, weil es jeder wissen muß was er da tut. Wenn jemand im Stande ist diese Beschreibung nachzuvollziehen, der ist allemal im Stande sich selbst ein Script zu schreiben.
Sorry.

Betrieb

Bei einem Newsserver war die Sache mit den Gruppen ja auch einigermaßen einfach zu handhaben, denn alles was wir bis jetzt lesen wollten haben wir einmal mit den Newsreader bestellt (subscribe Funktion) damit man sie angezeigt bekommt und dann noch die sucknewsrc dem entsprechend verändert damit man auch mit den News versorgt wird.
Bei mehreren Servern geht die Übersichtlichkeit aber schnell verloren und bei mehreren Useraccounts wird das Chaos perfekt. Dazu entstand ein speziell zu diesem Zweck entwickeltes sp4si Paket (Script Package for Suck & INN). sp4si bietet eine sehr große Hilfe und erspart eine Menge Tipparbeit bei jeder Erweiterung als auch im laufendem Betrieb, da es auch ein Newsgroups-Administrationstool darstellt und sich selbst administriert. Somit versucht es die Funktionen und Möglichkeiten eines komplexen News-Systems mit den Konfigurationsvorteilen eines einfachen Minimalsystems zu vereinen.

Public News Server

Jetzt stellt man sich bestimmt fragen wie: "wozu das ganze ?" oder "woher soll ich denn die Adressen der Newsserver nehmen ?".
Tja, nichts leichter als das ! Einfach auf einen Searcher (zB.: http://www.yahoo.com/)gehen und nach "public news server" suchen lassen. Entgegen bekommt man haufenweise Verweise (<- cooler Reim :-) auf diverse PublicNewsServer-Listen. Für ein guten Anfang ist hier eine davon: http://www.geocities.com/TheTropics/7915/newsd.html.

Ich hoffe mit meiner Anleitung geholfen zu haben und wünsche viel Spaß und Erfolg mit Linux !