Inhalt

6. News

Folgende Dateien sind wichtig für die Arbeit und Konfiguration von INN und suck:

6.1 Den Benutzer »news« anlegen

Dies sollte schon bei der Installation geschehen sein; ansonsten geht es wie folgt:

6.2 Die Konfiguration von INN

/etc/news/inn.conf 

organization:   [Firmenname o.ä.]
server:         localhost

/etc/news/hosts.nntp

Die Datei /etc/news/hosts.nntp enthält nur einen einzigen Eintrag: 

localhost

/etc/news/nnrp.access

Die Datei /etc/news/nnrp.access sollte folgendermaßen aussehen: 

*:: -no- : -no- :!
(none):ReadPost:::*
localhost:ReadPost:::*

/etc/news/expire.ctl

Die /etc/news/expire.ctl Datei bestimmt, nach welcher Zeitspanne alte Artikel gelöscht werden. Sie sollte ungefähr so aussehen: 

/remember/:14
*:A:4:10:10
junk:A:1:1:2
control:A:1:1:2
*.test:A:1:1:1

/etc/news/newsfeeds

Die Datei /etc/news/newsfeeds muß so aussehen: 

ME:*::
OVERVIEW!:*:Tc,WO:/usr/lib/news/bin/overchan
newsserv/[Name des Newsservers]:*:Ap,Tf,Wnm:newsserv

/var/lib/news/active

Der letzte Schliff

Der Moment der Wahrheit

Spannung. Ob es wohl funktioniert? Ein erster Test kann lokal auf dem eigenen Rechner durchgeführt werden: 

# /usr/lob/news/bin/rc.news

Es sollte folgende Meldung erscheinen: 

Starting innd

Nun kann man sich mit Telnet auf den eigenen Newsserver einloggen: 

# telnet localhost 119
Trying 127.0.0.1....
Connected to localhost
Escape charakter is ']'
200 Rechner InterNetNews server INN 1.5.1 17-Dec-1996 ready

Mit quit geht's wieder zum gewohnten Prompt!

Wenn das geklappt hat: Herzlichen Glückwunsch. Die Wahrscheinlichkeit, daß der innd auch sonst richtig arbeitet, ist sehr hoch.

Sollte es nicht funktioniert haben: Herzliches Beileid, denn jetzt heißt es, den Fehler zu suchen: Schauen Sie nach, ob root eine Mail bekommen hat, überprüfen Sie die Konfiguration (vor allem Besitzer und Rechte kontrollieren); sehr hilfreich kann auch ein Aufruf von /usr/lib/news/bin/inncheck sein.

INN dauerhaft einrichten

Damit INN bzw. sein Daemon innd beim Hochfahren des Rechners automatisch gestartet wird, muß bei den meisten Distributionen nichts mehr eingerichtet werden. Anderenfalls kann man, je nach Distribution, entweder in /etc/rc.d/rc.local folgenden Abschnitt einfügen 

# INN starten
if [ -x /usr/lib/news/bin/rc.news ] then
   /bin/sh /usr/lib/news/bin/rc.news
fi
oder man erzeugt in /etc/rc.boot ein File mit Namen inn, welches den oben gezeigten Inhalt hat. Ein korrekterer Weg wäre jedoch, in /etc/rc2.d einen Link names S50inn auf die Datei /etc/init.d/inn zu setzen, die folgenden Inhalt hat: 

#!/bin/sh
# Startet/beendet den News Server

test -f /usr/sbin/innd || exit 0

case "$1" in
start)
        echo "Starte News Server: innd"
        start-stop-daemon --quiet --start --user root \
           --pidfile /var/run/innd/innd.pid \
           --startas /etc/news/boot | \
           sed -e '/Starting innd./d' \
               -e 's/^/innd: boot: /' &
        sleep 2
        ;;
stop)
        echo "Stoppe News Server: innd"
        if [ -f /var/run/innd/innwatch.pid ]
        then
                start-stop-daemon --quiet --stop \
                   --pidfile /var/run/innd/innwatch.pid
        fi
        start-stop-daemon --quiet --stop \
                --pidfile /var/run/innd/innd.pid \
                --exec /usr/sbin/innd
        ;;
*)      echo "Syntax: /etc/init.d/inn start|stop"; 
        exit 1 ;;
esac

exit 0

rc2.d gilt für Runlevel 2; wenn das System auch in anderen Runleveln läuft, z.B. Runlevel 3 beim Einsatz von xdm, so muß auch im entsprechenden rc[n].d Verzeichnis ein Link S20inn vorhanden sein. Sicherheitshalber sollte man dieses für alle Runlevel machen. Eine Ausnahme stellen jedoch die Runlevel 0 (halt), 1 (Single-User) und 6 (reboot) dar; hier lautet der Link K50inn, hat aber das gleiche Ziel. Zur Behandlung der Runlevel sollte unbedingt die Dokumentation der jeweiligen Distribution beachtet werden.

Die regelmäßigen Arbeiten

Damit die News, welche auf den Rechner geschaufelt und hier geschrieben werden, einer regelmäßigen Wartung unterzogen werden, engagieren wir einen kleinen Helfer, der diese Arbeiten erledigt. Wann er was machen soll, wird in /etc/crontab festgelegt.

6.3 suck

Wichtige Dateien

Zu beachten sind folgende Datein:

/etc/suck/get-news.conf

Die Datei /etc/suck/get-news.conf sollte so aussehen: 

server: localhost
remoteserver: [Newsserver]
outgoingfile: newsserv
#userid:
#password:
sedcmd: /^NNTP-Posting-Host:\|^Xref:/d

/etc/suck/sucknewsrc

Mit der Datei /etc/suck/sucknewsrc wird suck mitgeteilt, welche Gruppen zu holen sind. Die Datei könnte so aussehen: 

#comp.os.linux.announce -1
#comp.security.announce -1
#gnu.announce -1
#news.announce.newusers -1
#news.newusers.questions -1
de.comp.os.linux.x 16314
de.comp.os.linux.misc 67222
de.comp.os.linux.networking 25000
hhu.forum 4588
hhu.linux 225
hhu.modem 2160
hhu.bibliothek 130
#hhu.test 1383
de.comp.text.tex 13466
de.comp.lang.perl 6338
hhu.wohnheime 278
de.alt.comp.kde 653

Bei der ersten Einrichtung einer Gruppe gibt man als Zahl z.B. -20 an. Das bedeutet, suck soll die von diesem Zeitpunkt an 20 neuesten Nachrichten der Gruppe holen. Der Wert wird dann bei jedem Polling aktualisiert.

Der entsprechende Befehl lautet 

# get-news

Dies wiederum ist ein Link auf /usr/sbin/get-news.inn. suck übernimmt dann sowohl das Saugen neuer News als auch das Posten der Artikel, die lokal verfasst wurden. Dabei werden aber nur Artikel an den Newsserver weitergeleitet, die nicht von ihm stammen, so daß keine Dupes erzeugt werden.

Inhalt