» SelfLinux » Internet » News » Server » INN » Abschnitt 5 SelfLinux-0.10.0
zurück   Startseite Kapitelanfang Inhaltsverzeichnis GFDL   weiter

SelfLinux-Logo
Dokument INN - Abschnitt 5 Revision: 1.1.2.5
Autor:  Steffen Dettmer
Formatierung:  Matthias Hagedorn
Lizenz:  GFDL
 

6 Echte Feeds


6.1 Feeds für andere Server konfigurieren

Hier nun ein paar Infos, wie man INN verrät, wie die Feedlisten auszusehen haben. Als erstes muß INN natürlich wissen, für welchen Newsserver überhaupt Feedlisten erstellt werden müssen und welche Gruppen enthalten sein sollen. Das erledigt man in der Datei newsfeeds. Das Format sieht wie folgt aus:

Mit # beginnende Zeilen sind Kommentare. Ein Eintrag ist eine Zeile lang, kann sich über mehrere erstrecken, wenn als letztes Zeichen ein \ kommt. Die Felder eines Eintrags werden durch : getrennt und bedeuten:

Datei newsfeeds
Newsserver/Alias			\
	:Gruppenpattern/Distribution	\
	:flag,flag			\
	:param
	 

Jeder Eintrag entspricht einer Feedliste und damit einem Server, dem man Artikel feeden möchte.

Ist Newsserver bereits im Pfad, so wird ein Artikel nicht gefeeded. Unter Umständen stimmen Newsserver FQDN und dessen Pfadeintrag nicht überein (ein Server kann ja mehrere [Alias-] Namen haben). Diese kann (und sollte) man dann alle bei Alias aufführen.



6.2 Einen Feed konfigurieren

Was genau der Server gefeeded bekommen soll, wird über die Optionen des Feedlisten-Eintragen eingestellt.

Gruppenpattern bestimmt die Gruppen, die gefeeded werden sollen. Dabei ist als Wildcard * erlaubt (was eine beliebige Anzahl von ebenfalls beliebigen Zeichen darstellt).
Gruppen, die ausgeschlossen werden sollen, kann man hinter ! definieren. Zusätzlich kann man eine Distributionsliste angeben (incl. Ausnahmen).

Die beiden wichtigesten Flags sind:

T<type> mit <type> <f|p|...>

f: file
p: programm

(hier wird nur Tf erklärt: die Feedliste ist eine normale Datei)

W<items> mit <items> {m,n,H...}

m: Message-ID
n: Pfadname
H: Alle Header

Zum späteren Senden via NNTP mittels nntpsend wird die Message-ID und der Pfad benötigt (der Rest steht ja im Artikel unter Pfad), also Wnm



6.3 Feedlisten zusammenstellen

Aus technischen Gründen muß erst ein spezieller Feed für den Server selbst eingerichtet werden. Dieser enthält in der Regel alles. Ein entsprechende Eintrag sieht so aus:

ME\
        :*,!control,!junk\
        ::
	 

(control und junk interessieren nicht)

Ein Beispiel für einen Feed zum ISP könnte so aussehen:

newsfeed\
        :*,!control,!junk,!local.*\
        :Tf,Wnm:
	 

Das bedeutet: Es soll NNTP zum Feeden verwendet werden [UUCP ist so gut wie tot]. Dabei sollen alle Gruppen, außer control, junk, und local.* übertragen werden. nntpsend erwartet ein File (Tf) mit dem Format Message-ID und Pfad (Wnm).

Overview- und Crosspostsdata kann so erzeugt werden:

Overview- und Crosspostsdata
overview!:*:Tc,WO:/usr/bin/overchan
crosspost:*:Tc,Ap,WR:/usr/bin/crosspost
	 

Diese Datei newsfeed gehört ins Verzeichnis /etc/news.



6.4 Feeds durchführen

Um diese Feeds auch durchzuführen, muß ein entsprechender cronjob laufen. Man kann ihn nachts laufen lassen, nur dann erhält man frühestens einen Tag später eine Antwort, laufen beide Feeds (also Server zum ISP und ISP zum Server) einmalig nachts, kann eine Antwort frühestens zwei Tage später erscheinen. Für ein schnelleres Verhalten sollte man nntpsend z.B. alle 10 Minuten starten. Dazu dient unter Linux z.B. folgender Eintrag:

alle 10 Minuten starten
*/10 * * * * /usr/lib/news/bin/nntpsend
	 


6.5 Feeds testen

Zu Testzwecken kann man nntpsend natürlich auch manuell starten. Ein (leider selten nützliches) logfile liegt unter /var/log/news/nntpsend.log.
Das sieht z.B. so aus:

/var/log/news/nntpsend.log
nntpsend: [5694] start
nntpsend: [5694] stop
nntpsend: [5694:5715] begin newssrv2 Wed Dec 15 20:06:03 MET 1999
nntpsend: [5694:5715] innxmit -a newssrv2 ...
nntpsend: [5694:5715] end newssrv2 Wed Dec 15 20:06:04 MET 1999
	 

Im Falle, dass Artikel gesendet wurden (nntpsend verwendet innxmit nur in diesem Fall). Ansonsten besteht es nur aus start/stop Zeilen (keine Artikel übertragen).

Der innd auf der anderen Seite, also der Empfänger, loggt diese Vorgänge auch (das wird dabei indirekt von nntpsend gesteuert), das sieht so aus:

/var/log/news/nntpsend.log
Dec 15 20:05:00 newssrv1 innd: newssrv3 flush
Dec 15 20:05:00 newssrv1 innd: newssrv3 opened newssrv3:15:file
Dec 15 20:05:00 newssrv1 innd: newssrv3 closed
Dec 15 20:05:02 newssrv1 innd: localhost connected 18 streaming allowed
Dec 15 20:05:02 newssrv1 innd: localhost:18 NCmode "mode stream" received
Dec 15 20:05:04 newssrv1 innxmit[5692]: localhost stats offered 737 accepted 1 refused 736 rejected 0
Dec 15 20:05:04 newssrv1 innxmit[5692]: localhost times user 0.070 system 0.110 elapsed 2.337
Dec 15 20:05:04 newssrv1 innd: localhost:18 closed seconds 2 accepted 1 refused 736 rejected 0
	 

Hier sieht man eine nette Fehlkonfiguration: der Newsserver hat von 737 Artikeln 736 abgelehnt (vermutlich hat er diese Gruppe nicht, bzw. möchte sie nicht, weil er sie nicht bedient). Einen hat er jedoch akzeptiert (und keinen rejected. Rejected wird, wenn er ihn eigentlich möchte, aber er z.B. meint, es handle sich um Spam, oder der Artikel hat falsche Struktur oder sowas, beispielsweise die oben erwähnten Newsserverheader). Das ganze hat zwei Sekunden gedauert.



6.6 Beliebte Fehlersituationen bei Feeds

Es gibt weitere häufige Fehlermeldungen, die nicht immer klar verständlich sind. Hier einige wichtige Beispiele.


6.6.1 Der eigene Server läuft nicht

Situation: Der eigene Server ist down, nntpsend bekommt keine Daten zum versenden. Das sieht dann so aus:

/var/log/news/nntpsend.log
nntpsend: [2681] start
Can't send "flush" command (dead server failure) No such process.
nntpsend: file /var/news/storage/out.going/newsfeed for newsfeed not found
nntpsend: skipping newsfeed via newsfeed
	 


6.6.2 Der fremde Server läuft nicht

Situation: Der fremde Server ist down, innxmit kann ihn nicht erreichen:

/var/log/news/nntpsend.log
nntpsend: [3888:3909] innxmit -a newsfeed ...
Can't connect to newsfeed, Connection refused
	  


6.6.3 Probleme mit den Gruppen

In der Praxis kommt es immer wieder mal vor, dass der Server plötzlich hunderte von Artikel ablehnt.

Ungewollte newsgroups werden in unwanted.log erfaßt:

unwanted.log
130 newsgroup de.comp.lang.delphi.datenbanken
3 newsgroup de.comp.datenbanken.misc
	  

Dies kann kommen, wenn uns Datenbanken nicht mehr interessieren und die Gruppe nicht mehr geführt wird. Der Feeder sollte seine Feedlisten anpassen; in der Praxis kann sowas leider oft lange dauern, da die Administratoren selten Zeit haben.




6.7 Selektion von Gruppen

Bei der Auswahl der erwünschten Newsgroups, die vom ISP gefeeded werden sollen, ist sehr selektiv auszuwählen. Keinesfalls darf der Fehler gemacht werden, z.B. de.* oder alt.* haben zu wollen (es sei denn, Sie sind glücklicher Besitzer einer gelangweilten E3 Anbindung - das sind 34 Mbit Bandbreite - und haben einen Kleiderschrank voller Geld für die Trafficgebühren). Lektüre entsprechender Selbstzweck-Newsgroups (news.admin.technical z.B.) ist hilfreich, daher auch das folgende Zitat:

Zitat
> curt@kcwc.com (Curt Welch) wrote:
> thebyte@san.rr.com (Daniel Trewella) wrote:
> > Our news server currently hogs about 2mb/s on our 6mb/s backbone.
> > (Can
> > you say "ouch"?) Is there a way to limit the bandwith that our news
> > server is using?
> >
> > The system is running FreeBSD 3.0-RELEASE and INN 2.1.
> 
> Are you talking about your incoming feeds?  You're lucky it's only
> 2mb/s.
> A full feed is more like 8mb/s these days.
> 
> The only good way to deal with the size of your incomming feed is to
> change what your feeds are sending you.
	 

Überschlagen wir mal ganz grob: 8mb/s sind 1Mbyte/s. Der Tag hat 60*60*24 Sekunden, macht etwa 84 GB am Tag, und 2,5 TB (TeraByte) im Monat. Nehmen wir mal an, 1 GB würde EUR 10,- kosten (das ist ein in etwa realistischer Preis), dann kämen wir auf etwa 25.000 Euro im Monat!! Dies setzt natürlich voraus, das die Bandbreite im Tagesdurchschnitt bei 8Mbit liegt...




zurück   Seitenanfang Startseite Kapitelanfang Inhaltsverzeichnis GFDL   weiter