7.1 Für Feeds

Hier ein Cronjob zum Durchführen der Feeds:

nntpsend z.B. alle 10 Minuten starten. Dazu dient unter Linux z.B.:

*/10 * * * * /usr/lib/news/bin/nntpsend
	 

7.2 Nächtliches Aufräumen

Diese Jobs können viel Rechen- und Plattenleistung verbrauchen und sollten daher nachts ausgeführt werden.

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
	 

7.3 Löschen alter Artikel

Meist reicht es aus, 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):

5 9,15,21 * * * /usr/bin/news.daily delayrm \
expireover norenumber nomail nologs >/dev/null 26gt;&1
	 

8.1 1.1 Informationsquellen

Die beiden wichtigsten Quellen für Informationen bzw. Fehlerbeschreibungen sind eMails, die an news bzw. root gemailt werden, und die Logfiles. Die wichtigesten logfiles werden dabei meistens via syslog verwaltet. Der Standard-Pfad ist /var/log/* (einschließlích /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 news.notice ab. Diese beiden Dateien sind immer die erste Anlaufstelle bei Problemen.

8.2 Startprobleme

Wenn innd überhaupt nicht startet, kann es z.B. an einem Syntaxfehler in der Konfiguration liegen. Das Programm 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 strace -f /pfad/innd - Pfade ergänzen!) Hinweise bekommen. Die Interpretation erfordert allerdings recht intensive Systemkenntnisse.

8.3 Zugriffsprobleme

Wenn innd läuft, kann man prüfen, ob ein Client Zugriff bekommt:

Wenn man einen connect bekommt, kann man z.B. das Kommando LIST probieren (danach dann QUIT). Man sollte die Gruppenliste erhalten. Ein Feedtest macht man z.B. mit dem Kommando

Einem Clienten sollte dann geantwortet werden 480 Transfer permission denied, einem Feeder 335 und dem Warten auf Eingaben (Ende mit <CR>"."<CR> (also einem Punkt als einziges Zeichen auf einer Zeile, wie auch bei SMTP). Die zu erwartende Fehlermeldung: 437 No colon-space in header. Je nach Version und Typ werden Abweichungen vorhanden sein.

8.4 Probleme mit Feedern

Wird ein Feed nicht als Feed erkannt, sollte als erstes geprüft werden, ob der FQDN (Systemname des Servers) übereinstimmt. Dazu kann man z.B. eine Verbindung aufbauen und dann mit

schauen, wie der Name ist, bzw.

mit nachfolgendem nslookup. Ist der Name bestimmt, können die Einträge in hosts.nntp überprüft werden.

8.5 Abgelehnte Artikel

Gründe für rejects oder refuses zu finden, kann aufwendig werden. Es ist zu beachten, dass auch bereits gespoolte Artikel abgelehnt werden können. Unerwünschte Gruppen werden sowieso abgelehnt. Ein Blick ins active-File ist jedenfalls immer ratsam.

8.6 Probleme mit Clienten

Falls sich Clienten beschweren, nicht mehr connecten zu können, sollten als erstes die Prozesse des Newsservers neu gestartet werden:

Dann kann z.B. mit:

ein Test gemacht werden.
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.

8.7 Vollaufen eines Dateisystems

Einer der schlimmsten anzunehmenden Fehler ist ein Vollaufen eines Dateisystems, insbesondere des 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 überarbeitet und neuangelegt werden, verschwinden dabei unter Umständen. Deshalb ist die freie Kapazität streng zu beobachten. Dabei ist es eine Hilfe, dass 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.