\documentclass[a4paper,11pt]{article} \usepackage{ngerman} \usepackage[latin1]{inputenc} \setlength\parskip{\medskipamount} \setlength\parindent{0pt} \begin{document} % inn % Copyright Steffen Dettmer % Lizenz: GFDL % % $Name: $ % $Revision: 1.1.2.10 $ % $Source: /cvsroot/selflinux/tutorial/advanced/netzwerk_advanced/andere_dienste/newsserver/inn/inn,v $ % SelfLinux-0.7.2 % % Diese Datei ist Teil von SelfLinux http://www.selflinux.de % %%% $Id: inn,v 1.1.2.10 2003/02/02 22:54:53 motw_1 Exp $ \title{INN} \author{Steffen Dettmer} %\url{mailto:steffen@dett.de} \maketitle %\ref{../index.tex} %\ref{andere_dienste1.tex} Internet %\ref{News.tex} News %\ref{News-Server.tex} Server \ref{inn} \par{Layout} Matthias Hagedorn %\url{mailto:herbert_kw@t-online.de} \par{Lizenz} GFDL \tableofcontents{} \section{Einleitung} \label{d52e51} \par Dieses Dokument beschreibt den Betrieb eines {\bf echten} Newsservers mit der Software {\bf INN}. Es richtet sich an angehende News-Administratoren, nicht jedoch an Heimanwendungen. Für Heimanwendungen verwendet man am besten einen bereits bestehenden Newsserver oder das Programm {\bf leafnode}. Der Betrieb eines {\bf echten} Newsservers ist sehr aufwendig, kompliziert und erfordert bei größeren, sinnvollen Installationen, daß mindestens ein Newsserver angepaßt wird, damit der eigene Server News zugeschickt bekommt (das ist ein grundlegender Unterschied zum eMail-Versand, wo ja jeder einfach einen eigenen Server betreiben kann). \par Der Betrieb eines {\bf echten} Newsserver lohnt sich, wenn man viele Clienten bedienen möchte (das heißt, weit mehr als 10), oder viele Artikel verwalten muß (das heißt, weit mehr als 10.000). Für kleinere Installationen sollte entweder ein fremder Newsserver verwendet werden, oder das Programm {\bf leafnode} verwendet werden. Nur, wenn wirklich Bedarf besteht, sollte man sich einen {\bf echten} Newsserver leisten, denn Einrichtung und richtiger Betrieb sind aufwendig. \subsection{News} \label{d52e88} \par Mit News bezeichnet man kurze Textdateien, von denen ständig welche geschrieben werden (in einigen Fällen sind das auch binäre Dateien). Diese werden an viele Benutzer verteilt. Diese können dann auch darauf antworten. Da es sehr viele solcher Artikel gibt, hat man diese sogenannten Gruppen zugeordnet. So gibt es eine Gruppe {\bf comp.os.linux}, die sich mit Linux beschäftigt und viele andere, bis hin zu {\bf de.alt.freieliebe}. \par Um der Flut von Artikeln Herr zu werden, werden diese nach einiger Zeit, zum Beispiel nach einem Monat, gelöscht. Es handelt sich schließlich um {\bf News} - also Neuigkeiten. \subsection{Überblick} \label{d52e111} \par Ein Benutzer schreibt einen solchen Artikel mit einem Programm, zum Beispiel mit Netscape. Das Programm sendet (postet) den Artikel dann zu einem bestimmten Server. Dieser verteilt den Artikel dann an weitere Server und diese verteilen den Artikel dann auch wieder weiter. Über irgendwelche Wege {\bf kennt} jeder Server indirekt jeden anderen (sonst würde es {\bf Inseln} geben). Es kann somit auch einige Zeit dauern, bis der Artikel überall zur Verfügung steht, von allen gelesen und beantwortet werden kann. Heutzutage sind jedoch die Verbindungen so schnell, daß ein Artikel in Sekunden fast alle Teile der Welt erreicht hat. Jedoch gibt es auch Server, die zum Beispiel aus Kostengründen Artikel nur nachts übertragen. \subsection{Usenet} \label{d52e131} \par Mit Usenet bezeichnet man alle Server, die News-Artikel untereinander austauschen. Das Usenet ist eine dezentrale Anordnung von Newsservern. Das Usenet enthält Artikel, die einer Gruppe zugehören. Die Gruppen sind dabei in (mehrere) Hierarchien gegliedert, eine davon heißt z.B. {\bf de} und beinhaltet u.a. {\bf de.answers}, {\bf de.test} und (Sub-) Hierarchien wie z.B. {\bf de.comp} (mit {\bf de.comp.os} usw.). Ein Newsserver hat eine bestimmte Menge von Newsgroups, die er verwaltet/kennt. \par Ein Client, auch Newsreader genannt (z.B. tin, Netscape), kann nun über den NNTP Port auf den Newsserver connecten, sich eine Liste der Newsgroups geben lassen, sich einzelne Artikel herunterladen oder senden ({\bf posten}). Diese Clienten werden hier als Newsreader (oder kurz Reader) bezeichnet, mit Server wird im folgenden ein Newsserver bezeichnet. \section{Verteilung von News} \label{d52e175} \subsection{Verteilung vieler Artikel} \label{d52e180} \par Um die Verteilung zu ermöglichen, stehen die Newsserver untereinander in Verbindung. Da in der Regel viele Artikel übertragen werden und aus Effizienzgründen keine doppelt übertragen werden sollen, wird ein spezielles Verfahren verwendet. Die Server pflegen Listen, in denen die zu übertragenden Artikel stehen, wird eine Übertragung durchgeführt, wird die Liste {\bf abgearbeitet}, so daß mit einer Verbindung alle Artikel übertragen werden können. Diese Listen nennt man {\bf Feedlisten}. Hat ein Newsserver einen neuen Artikel empfangen, so trägt er die Nummer des Artikels in die Feedlisten ein. Ein Artikel trägt in seinem Header Steuerinformationen, wie z.B. eine Pfadliste, in der die Newsserver stehen, die diesen Artikel übertragen haben (jeder Server fügt seinen Namen am Anfang der Liste ein, das Verfahren ist analog zur Pfadadresse einer eMail aus UUCP-Zeiten). \subsection{Feeden und Posten} \label{d52e197} \par Artikel, die in der Feedliste stehen, sollen also später gefeeded werden. Dies darf man nicht mit dem posten verwechseln. Clients posten, Newsserver feeden. Feeden ist auf den ersten Blick zwar sehr ähnlich, jedoch auf Protokollebene anders. Feeden ist für große Mengen an Artikeln optimiert. Posten funktioniert einfacher. Beim Posten geht der Newsserver davon aus, daß der Artikel neu ist. Gepostete Artikel werden gegebenenfalls um eine ID ergänzt. Gefeedete Artikel müssen immer bereits eine ID besitzen. \subsection{Feedlisten} \label{d52e208} \par Soll ein Artikel in die Feedliste für einen Zielserver eingetragen werden, ist das natürlich nur nötig, wenn der Name des Zielservers noch nicht in der Pfadliste steht (denn anderenfalls hat er den Artikel ja bereits gesehen und gespeichert). Der Artikel wird also nur in die Feedlisten der Server eingetragen, die den Artikel noch nicht weitergeleitet haben. Nun kann aber ein Zielserver diesen Artikel von einem anderen Server erhalten haben. Um sinnlosen Datenverkehr zu unterbinden, hat deshalb jeder Artikel eine weltweit eindeutige ID (genauer gesagt, muß die ID eindeutig im gesammten Usenet sein, also eindeutig in allen bekannten Universen). Connected ein Server einen anderen, um ihm Artikel zu schicken, sendet er erst einmal eine Liste von IDs, die er hat. Diese Liste wird aus den Feedlisten erstellt. Der andere Server vergleicht diese mit seinem Datenbestand. Artikel mit unbekannten IDs werden nun übertragen. Dieser Vorgang läuft ebenfalls oft über den NNTP Port ab (deswegen kann es Schwierigkeiten geben, wenn vom Feeder aus versucht wird, eine Client-Verbindung aufzubauen, da der Server häufig hier nur einen Server erwartet, und sich entsprechend {\bf [falsch]} verhält). \subsection{Die eigentliche Übertragung} \label{d52e222} \par In regelmäßigen Zeitabständen wird ein {\bf cron}-job gestartet, der die Feedlisten überträgt. Alternativ dazu kann man das auch über ein Programm erledigen, was sich wie ein Client verhält und diese Artikel postet (also nicht feeded!), dabei müssen die Artikel allerdings etwas modifiziert werden, da ein Client einige Headerfelder nicht setzen darf (z.B. NNTP-Posting-Host, Xref, X-Trace, X-Complaints-To, NNTP-Posting-Date), da diese vom Newsserver gesetzt werden (dazu kann man ein Filterscript verwenden). \par Um nicht in der Datenflut zu ersticken, akzeptiert ein Newsserver nur einige Gruppen (das können auch einige hundert sein). Das sollte bereits beim Erstellen der Feedlisten berücksichtigt werden, man muß schließlich keine Artikel in die Listen eintragen, die sowieso nicht akzeptiert werden. Auch möchte man evtl. einige {\bf private} Gruppen führen, die ebenfalls nicht gefeeded werden sollen. \section{Neue Gruppe einrichten} \label{d52e246} \subsection{Überblick} \label{d52e253} \par Eine neue Gruppe wird in drei Schritten eingerichtet. Zum Einen muß der Feeder (i.d.R. der ISP) die neue Gruppe in seine Feedliste aufnehmen, damit der Feeder neue Artikel in die Feedliste einträgt (das macht er nur, wenn der Empfänger die Gruppe überhaupt haben will). Dazu ist es natürlich notwendig, daß der Feeder der Gruppe selbst gefeeded bekommt und neue Artikel entsprechend {\bf zurückfeeden} kann, sonst erhält man natürlich keine Artikel. Einfacher gesagt, man kann keine Gruppen bekommen, die er selbst nicht hat. \par Zum Anderen muß der lokale Newsserver diese Gruppe bedienen, d.h. diese Gruppe muß {\bf active} sein, ansonsten würde der lokale Newsserver die gefeedeten Artikel als {\bf unwanted} - {\bf ungewollt} - ablehnen und in der {\bf Pseudo}-Gruppe {\bf junk} - {\bf Müll} ablegen (diese Gruppe hat nur einen geringe Lebensdauer, oft werden die Artikel nach einem Tag bereits gelöscht). \par Dann muß als drittes der lokale Newsserver diese Gruppe auch an den {\bf Feeder feeden}, damit eventuelle Antworten ins Usenet gelangen. Ansonsten würde man ja keine Antwort auf die Artikel bekommen. \subsection{Vorgehen} \label{d52e294} \par Man beginnt sicherheitshalber immer mit dem zweiten Schritt (damit keinesfalls Artikel in {\bf junk} landen und {\bf verloren} gehen, denn ein manuelles Übertragen von {\bf junk} in eine Gruppe ist mindestens mühsam!). Dazu richtet man mit dem Dienstprogramm {\bf {\bf ctlinnd(1m)}} eine neue Gruppe ein. Dabei sorgt {\bf ctlinnd} hier {\bf nur} für eine ordnungsgemäße Eintragung in {\bf active} (und macht diese Änderung dem innd bekannt). Der Aufruf lautet dabei z.B.: \begin{tt} \begin{scriptsize} root@linux \~{}/ \# ctlinnd newgroup de.talk.jokes \end{scriptsize} \end{tt} \linebreak \par Dabei können noch weitere Argumente angegeben werden, daß ist hier ein minimalistisches Beispiel. Dann richtet man am besten erstmal gleich den eigenen Feed ein, damit Postings dann auch zurückgehen können (bzw. an weitere Server verteilt werden). Dazu muß man dann die Datei {\bf newsfeeds} (meist {\bf /etc/news/newsfeeds}) anpassen, wenn nötig (es kann z.B. sein, das alle Gruppen, evtl. bis auf Ausnahmen, gefeeded werden). \par Nun muß der Feeder den newsfeed für unseren Newsserver anpassen. \par Normalerweise bekommt man vom Feeder keine alten Artikel. Das heißt, es kann eine Weile dauern, bis neue Gruppen auch wirklich Artikel beinhalten! \section{Gruppen entfernen} \label{d52e349} \par Eine Gruppe loszuwerden, läuft entsprechend rückwärts. Um die Benutzer nicht zu ärgern, sollte sowas immer angekündigt und abgesprochen werden. Zu diesem Zwecke kann man z.B. eine Gruppe {\bf local.users} oder so verwenden. Zuerst sollte dann der Feeder die Gruppe nicht mehr feeden. Es kommen damit keine neuen Artikel, aber es kann noch gepostet werden. Dann kann man die Gruppe einfach {\bf expiren} lassen - irgendwann ist sie leer. Spätestens dann sollte man dann die Gruppe aus dem feed nehmen, und dann auch entfernen. \section{Newsserver ohne Feeder} \label{d52e369} \par Wenn man keinen Newsserver zur Verfügung hat, der den eigenen Newsserver feedet, also man keinen Newsadministrator überreden kann, für seinen eigenen Server Feedlisten zu pflegen, kann man auch einen Newsserver betreiben, der sich wie ein Client verhält. \par Das bedeutet, er holt die Artikel wie ein Client ab und verteilt Artikel nicht über Feeds, sondern postet diese selbst auch wieder. Mischformen sind natürlich auch möglich. \par Man kann hier {\bf suck} und {\bf rpost} verwenden. \subsection{Artikel einspeisen} \label{d52e391} \par {\bf Suck} verwendet man wie folgt: \begin{tabular}{|l|} \hline \begin{tt} Suck \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #!/bin/sh suck -c -bi /var/spool/news/batch -dt /var/spool/news \ -dm /var/spool/news/Msgs -dd /var/spool/news /usr/lib/news/bin/innxmit localhost /var/spool/news/batch \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Die Pfade müssen natürlich den Gegebenheiten angepaßt werden. \subsection{Artikel weiterschicken} \label{d52e417} \par Beim Posten müssen noch einige Infos aus dem Header gefiltert werden, da der andere Server keine Newsserver Einträge in den Artikeln sehen möchte (viele Newsserver werfen solche Artikel gleich in {\bf junk}). \par Hier ein Beispiel für die Verwendung von Post: \begin{tabular}{|l|} \hline \begin{tt} Beispiel für die Verwendung von Post \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #!/bin/bash mv /var/spool/news/out.going/newssrv3 \ /var/spool/news/out.going/newssrv3.new /usr/lib/news/bin/ctlinnd flush newssrv3 /usr/bin/rpost newssrv3.bedi.net -d -b \ /var/spool/news/out.going/newssrv3.new \ -p /var/spool/news \ -f /etc/news/post.filter \$\$o=/tmp/filtered_msg \ \$\$i /tmp/filtered_msg \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Das ist hier {\bf quick-and-dirty} (für Testumgebungen z.B.). Hier wird {\bf out.going} sicherheitshalber für die Dauer des {\bf rpost} Aufrufes umbenannt, damit keine Artikel übergangen oder doppelt gepostet werden. \subsubsection{Artikel zum Versand aufbereiten} \label{d52e454} \par Ein Beispiel-Filter für das Entfernen der Header und Newsservereinträge ({\bf /etc/news/post.filter}) könnte so aussehen: \begin{tabular}{|l|} \hline \begin{tt} Beispiel-Filter für das Entfernen der Header und Newsservereinträge \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #!/bin/sh PATH=/usr/local/bin:/usr/bin:/bin:/usr/lib/news/bin PERLCMD='/^(NNTP-Posting-Host|Xref|X-Trace|\ X-Complaints-To|NNTP-Posting-Date)/ or print' INFILE=$1 OUTFILE=$2 if [ -f ${INFILE} ]; then cat ${INFILE} | perl -ne "${PERLCMD}" > ${OUTFILE} if [ $? -ne 0 ]; then echo "Error" exit -1 fi else echo "$1 does not exist" exit -1 fi \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Automatisierung} \label{d52e478} \par Beide Scripte kann man über einen {\bf Wrapper} (News eXchanger) starten: \begin{tabular}{|l|} \hline \begin{tt} Wrapper (News eXchanger) \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} #!/usr/bin/bash /etc/news/post.sh >> /var/log/news/post_log 2>&1 /etc/news/suck.sh >> /var/log/news/suck_log 2>&1 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Hier werden noch Logdateien geschrieben. \par Das kann man dann per Cron alle 5 Minuten ausführen lassen: \begin{tabular}{|l|} \hline \begin{tt} per Cron alle 5 Minuten ausführen lassen \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} */5 * * * * /etc/news/NX.sh \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Erweiterungen} \label{d52e516} \par Das ist ein kleines Grundgerüst, auf dem man aufbauen kann. Es ist damit zu rechnen, daß weitere Dinge angepaßt werden müssen; leider verhalten sich Newsserver nicht einheitlich. Das ist meistens neben dem Verwalten der Datenmengen die größte Schwierigkeit beim Administrieren von {\bf richtigen} Newsservern. \section{Echte Feeds} \label{d52e534} \subsection{Feeds für andere Server konfigurieren} \label{d52e541} \par 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 {\bf newsfeeds}. Das Format sieht wie folgt aus: \par Mit {\bf \#} beginnende Zeilen sind Kommentare. Ein Eintrag ist eine Zeile lang, kann sich über mehrere erstrecken, wenn als letztes Zeichen ein {\bf $\backslash$} kommt. Die Felder eines Eintrags werden durch {\bf :} getrennt und bedeuten: \begin{tabular}{|l|} \hline \begin{tt} Datei newsfeeds \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} Newsserver/Alias \ :Gruppenpattern/Distribution \ :flag,flag \ :param \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Jeder Eintrag entspricht einer Feedliste und damit einem Server, dem man Artikel feeden möchte. \par Ist Newsserver bereits im Pfad, so wird ein Artikel nicht gefeeded. Unter Umständen stimmen Newsserver {\bf 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. \subsection{Einen Feed konfigurieren} \label{d52e585} \par Was genau der Server gefeeded bekommen soll, wird über die Optionen des Feedlisten-Eintragen eingestellt. \par Gruppenpattern bestimmt die Gruppen, die gefeeded werden sollen. Dabei ist als Wildcard {\bf *} erlaubt (was eine beliebige Anzahl von ebenfalls beliebigen Zeichen darstellt). \linebreak Gruppen, die ausgeschlossen werden sollen, kann man hinter {\bf !} definieren. Zusätzlich kann man eine Distributionsliste angeben (incl. Ausnahmen). \par Die beiden wichtigesten Flags sind: \par {\bf T\verb+<+type\verb+>+ mit \verb+<+type\verb+>+ \verb+<+f|p|...\verb+>+} {\bf f}: file \linebreak {\bf p}: programm \par (hier wird nur {\bf Tf} erklärt: die Feedliste ist eine normale Datei) \par {\bf W\verb+<+items\verb+>+ mit \verb+<+items\verb+>+ {m,n,H...}} {\bf m}: Message-ID \linebreak {\bf n}: Pfadname \linebreak {\bf H}: Alle Header \par 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 {\bf Wnm} \subsection{Feedlisten zusammenstellen} \label{d52e661} \par 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: \begin{tabular}{|l|} \hline \begin{tt} \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} ME\ :*,!control,!junk\ :: \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par ({\bf control} und {\bf junk} interessieren nicht) \par Ein Beispiel für einen Feed zum ISP könnte so aussehen: \begin{tabular}{|l|} \hline \begin{tt} \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} newsfeed\ :*,!control,!junk,!local.*\ :Tf,Wnm: \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Das bedeutet: Es soll NNTP zum Feeden verwendet werden [UUCP ist so gut wie tot]. Dabei sollen alle Gruppen, außer {\bf control}, {\bf junk}, und {\bf local.*} übertragen werden. {\bf nntpsend} erwartet ein File ({\bf Tf}) mit dem Format Message-ID und Pfad ({\bf Wnm}). \par Overview- und Crosspostsdata kann so erzeugt werden: \begin{tabular}{|l|} \hline \begin{tt} Overview- und Crosspostsdata \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} overview!:*:Tc,WO:/usr/bin/overchan crosspost:*:Tc,Ap,WR:/usr/bin/crosspost \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Diese Datei {\bf newsfeed} gehört ins Verzeichnis {\bf /etc/news}. \subsection{Feeds durchführen} \label{d52e744} \par Um diese Feeds auch durchzuführen, muß ein entsprechender {\bf 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: \begin{tabular}{|l|} \hline \begin{tt} alle 10 Minuten starten \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} */10 * * * * /usr/lib/news/bin/nntpsend \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Feeds testen} \label{d52e767} \par Zu Testzwecken kann man {\bf nntpsend} natürlich auch manuell starten. Ein (leider selten nützliches) {\bf logfile} liegt unter {\bf /var/log/news/nntpsend.log}. \linebreak Das sieht z.B. so aus: \begin{tabular}{|l|} \hline \begin{tt} /var/log/news/nntpsend.log \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 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 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Im Falle, daß Artikel gesendet wurden ({\bf nntpsend} verwendet {\bf innxmit} nur in diesem Fall). Ansonsten besteht es nur aus start/stop Zeilen (keine Artikel übertragen). \par Der {\bf innd} auf der {\bf anderen} Seite, also der Empfänger, loggt diese Vorgänge auch (das wird dabei indirekt von {\bf nntpsend} gesteuert), das sieht so aus: \begin{tabular}{|l|} \hline \begin{tt} /var/log/news/nntpsend.log \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 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 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Hier sieht man eine nette Fehlkonfiguration: der Newsserver hat von 737 Artikeln 736 abgelehnt (vermutlich {\bf 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 {\bf Spam}, oder der Artikel hat falsche Struktur oder sowas, beispielsweise die oben erwähnten Newsserverheader). Das ganze hat zwei Sekunden gedauert. \subsection{Beliebte Fehlersituationen bei Feeds} \label{d52e837} \par Es gibt weitere häufige Fehlermeldungen, die nicht immer klar verständlich sind. Hier einige wichtige Beispiele. \subsubsection{Der eigene Server läuft nicht} \label{d52e847} \par Situation: Der eigene Server ist down, {\bf nntpsend} bekommt keine Daten zum versenden. Das sieht dann so aus: \begin{tabular}{|l|} \hline \begin{tt} /var/log/news/nntpsend.log \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 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 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsubsection{Der fremde Server läuft nicht} \label{d52e870} \par Situation: Der fremde Server ist down, innxmit kann ihn nicht erreichen: \begin{tabular}{|l|} \hline \begin{tt} /var/log/news/nntpsend.log \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} nntpsend: [3888:3909] innxmit -a newsfeed ... Can't connect to newsfeed, Connection refused \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsubsection{Probleme mit den Gruppen} \label{d52e890} \par In der Praxis kommt es immer wieder mal vor, daß der Server plötzlich hunderte von Artikel ablehnt. \par Ungewollte newsgroups werden in {\bf unwanted.log} erfaßt: \begin{tabular}{|l|} \hline \begin{tt} unwanted.log \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 130 newsgroup de.comp.lang.delphi.datenbanken 3 newsgroup de.comp.datenbanken.misc \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par 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. \subsection{Selektion von Gruppen} \label{d52e920} \par 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. {\bf de.*} oder {\bf 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 {\bf Selbstzweck}-Newsgroups ({\bf news.admin.technical} z.B.) ist hilfreich, daher auch das folgende Zitat: \begin{tabular}{|l|} \hline \begin{tt} Zitat \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} > 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. \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \par Ü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... \section{Cron Jobs} \label{d52e959} \subsection{Für Feeds} \label{d52e966} \par Hier ein Cronjob zum Durchführen der Feeds: \par nntpsend z.B. alle 10 Minuten starten. Dazu dient unter Linux z.B.: \begin{tabular}{|l|} \hline \begin{tt} alle 10 Minuten starten \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} */10 * * * * /usr/lib/news/bin/nntpsend \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Nächtliches Aufräumen} \label{d52e989} \par Diese Jobs können viel Rechen- und Plattenleistung verbrauchen und sollten daher nachts ausgeführt werden. \begin{tabular}{|l|} \hline \begin{tt} Cronjob \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 0 * * * * /usr/lib/news/bin/news.daily expireover lowmark 24 3 * * 0 /usr/lib/news/bin/expireover -a -v 24 1 1 * * /usr/lib/news/bin/makehistory -buv \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \subsection{Löschen alter Artikel} \label{d52e1009} \par Meist reicht es aus, {\bf news.daily} regelmäßig auszuführen. Beispielsweise könnte man es dreimal täglich starten (bei großen Servern vielleicht auch nur einmal täglich, daher der Name des Scriptes; einmal nachts beim Aufräumen reicht meistens): \begin{tabular}{|l|} \hline \begin{tt} news.daily \end{tt} \\ \hline \begin{minipage}{130mm} \begin{scriptsize} \begin{verbatim} 5 9,15,21 * * * /usr/bin/news.daily delayrm \ expireover norenumber nomail nologs >/dev/null 26gt;&1 \end{verbatim} \end{scriptsize} \end{minipage} \\ \hline \end{tabular} \section{Debugging, Inbetriebnahme, Probleme} \label{d52e1033} \subsection{1.1 Informationsquellen} \label{d52e1040} \par Die beiden wichtigsten Quellen für Informationen bzw. Fehlerbeschreibungen sind eMails, die an {\bf news} bzw. {\bf root} gemailt werden, und die Logfiles. Die wichtigesten logfiles werden dabei meistens via {\bf syslog} verwaltet. Der Standard-Pfad ist {\bf /var/log/*} (einschließlích {\bf /var/log/news/*}) unter Linux. Diese lassen sich natürlich anpassen, wenn man möchte. Eine kleine Inkonsistenz tritt hierbei auf: Linux-Syslog legt manchmal alle news Meldungen in {\bf news.notice} ab. Diese beiden Dateien sind immer die erste Anlaufstelle bei Problemen. \subsection{Startprobleme} \label{d52e1069} \par Wenn innd überhaupt nicht startet, kann es z.B. an einem Syntaxfehler in der Konfiguration liegen. Das Programm {\bf inncheck} hilft, derartige Fehler zu finden. Im Normalfall sollte es keine Ausgabe machen. Ausgewiesene Fehler sind entsprechend zu korrigieren, klar. Wenn es gar nicht klappt, kann man evtl. durch ein System trace (mit {\bf strace -f /pfad/innd} - Pfade ergänzen!) Hinweise bekommen. Die Interpretation erfordert allerdings recht intensive Systemkenntnisse. \subsection{Zugriffsprobleme} \label{d52e1086} \par Wenn {\bf innd} läuft, kann man prüfen, ob ein Client Zugriff bekommt: \begin{tt} \begin{scriptsize} root@linux \~{}/ \# telnet newshost 119 \end{scriptsize} \end{tt} \linebreak \par Wenn man einen {\bf connect} bekommt, kann man z.B. das Kommando {\bf LIST} probieren (danach dann {\bf QUIT}). Man sollte die Gruppenliste erhalten. Ein Feedtest macht man z.B. mit dem Kommando \begin{tt} \begin{scriptsize} root@linux \~{}/ \# ihave \verb+<+xxx@test.de\verb+>+ \end{scriptsize} \end{tt} \linebreak \par Einem Clienten sollte dann geantwortet werden {\bf 480 Transfer permission denied}, einem Feeder {\bf 335} und dem Warten auf Eingaben (Ende mit {\bf \verb+<+CR\verb+>+''.''\verb+<+CR\verb+>+} (also einem Punkt als einziges Zeichen auf einer Zeile, wie auch bei SMTP). Die zu erwartende Fehlermeldung: {\bf 437 No colon-space in header}. Je nach Version und Typ werden Abweichungen vorhanden sein. \subsection{Probleme mit Feedern} \label{d52e1139} \par Wird ein Feed nicht als Feed erkannt, sollte als erstes geprüft werden, ob der {\bf FQDN} (Systemname des Servers) übereinstimmt. Dazu kann man z.B. eine Verbindung aufbauen und dann mit \begin{tt} \begin{scriptsize} root@linux \~{}/ \# netstat -a|grep nntp \end{scriptsize} \end{tt} \linebreak \par schauen, wie der Name ist, bzw. \begin{tt} \begin{scriptsize} root@linux \~{}/ \# netstat -an|grep 119 \end{scriptsize} \end{tt} \linebreak \par mit nachfolgendem {\bf nslookup}. Ist der Name bestimmt, können die Einträge in {\bf hosts.nntp} überprüft werden. \subsection{Abgelehnte Artikel} \label{d52e1177} \par Gründe für rejects oder refuses zu finden, kann aufwendig werden. Es ist zu beachten, daß auch bereits gespoolte Artikel abgelehnt werden können. Unerwünschte Gruppen werden sowieso abgelehnt. Ein Blick ins {\bf active}-File ist jedenfalls immer ratsam. \subsection{Probleme mit Clienten} \label{d52e1191} \par Falls sich Clienten beschweren, nicht mehr connecten zu können, sollten als erstes die Prozesse des Newsservers neu gestartet werden: \begin{tt} \begin{scriptsize} root@linux \~{}/ \# /etc/init.d/inn stop \end{scriptsize} \end{tt} \linebreak \begin{tt} \begin{scriptsize} root@linux \~{}/ \# /etc/init.d/inn start \end{scriptsize} \end{tt} \linebreak \par Dann kann z.B. mit: \begin{tt} \begin{scriptsize} root@linux \~{}/ \# telnet \verb+<+newsserver\verb+>+ 119 \end{scriptsize} \end{tt} \linebreak \par ein Test gemacht werden. \linebreak In jedem Falle sind die Logfiles zu analysieren. Das sollte von Zeit zu Zeit auch gemacht werden, wenn augenscheinlich alles funktioniert, um evtl. Fehler früh zu erkennen. \subsection{Vollaufen eines Dateisystems} \label{d52e1225} \par Einer der schlimmsten anzunehmenden Fehler ist ein Vollaufen eines Dateisystems, insbesondere des {\bf root}-Dateisystems. In einem solchen Fall wird nicht nur der Newsbetrieb gestört, sondern fast alle Serverfunktionen. Außerdem können dadurch undefinierte Zustände auftreten, die sich nur schwer erkennen und beheben lassen (z.B. existierende, aber leere Dateien). Dateien, die regelmäßig {\bf überarbeitet} und neuangelegt werden, verschwinden dabei unter Umständen. Deshalb ist die freie Kapazität streng zu beobachten. Dabei ist es eine Hilfe, daß bei normalen Konfigurationen per Cronjob eine eMail generiert wird, die auch diese Information liefert. Man kann das Problem entschärfen, in dem man Quotas verwendet oder eine eigene Partition für News bereitstellt. Newsserver neigen im Betrieb dazu, riesige Datenmengen zu produzieren. \ref{inhalt.tex} \end{document}