Leafnode ist ein relativ einfacher Newsserver, der alternativ
zu INN oder CNEWS eingesetzt werden kann.
Die Instalation und Konfiguration ist einfach, manchmal
gehen aber schon ein paar Dinge ab, so z.B. lokale Gruppen.
Das Usenet (weltweite Diskusionsforen, Newsgroups, ...)
stellt eine wichtige Quelle zur Informationsbeschaffung dar. Auf Grund
der anfallenden Datenmenge kann es sich aber kein Internetprovider leisten
alle Artikel (Postings) für immer zu speichern. Der Haltezeitraum
(Expire) beträgt typischerweise 2-4 Wochen, dieser Wert hängt
aber sehr stark vom Inhalt der Gruppe und Internetprovider ab. Speicherintensive
Postings in Binary-Gruppen können u.U. schon nach wenigen Tagen gelöscht
werden.
Daher war es mein Ziel einige Gruppen auf einem eigenen
Server permanent zu speichern und nie ablaufen zu lassen. Prinzpiell ist
es egal welche Gruppen man so archiviert, solange Netzanbindung und Plattenplatz
mitspielen. Natürlich kann leafnode die gespeicherten Postings auch
für Newsclients zur Verfügung stellen bzw. neue Postings zurück
in das Internet leiten.
Die folgende Installationsbeschreibung stellt meine Erfahrung
auf zwei verschiedenen Systemen dar (SuSE 5.3, Red Hat 5.2) und bezeiht
sich auf die Version 1.9.2. Da ich leafnode als Archiv benutzen möchte,
habe ich mir die Programme zum Löschen alter Postings (expire) erst
gar nicht angesehen. Es sei auf die Doko verwiesen ;-).
Angestachelt durch ein Posting in at.linux habe ich mich
eines Tages zu mitternächtlicher Stunde hinter meinen Firmenmailserver
geklemmt und begonnen geschriebenes zu lesen. Bei diesem Server handelt
es sich um ein Museumsstück (486/33, 12MB RAM, 6GB IDE-HDD) auf dem
eine SuSE 5.3 (out-of-the-box) Installation treu ihre Dienste versieht.
Leider ist bei dieser Distribution leafnode noch nicht enthalten (sondern
CNews), ich habe mich daher im Netz nach einer Version, vorzugsweise als
RPM, umgesehen. Fündig wurde ich bei SuSE
selbst bzw. einem Mirrow auf der TU-Wien
wo für SuSE 6.0 die Version 1.7 von leafnode als RPM bereitlag. Die
Installation mittels YAST (Paket einspielen) und die nachfolgende Konfiguration
waren ein Kinderspiel, nur funktioniert hat es halt leider nicht (Gruppen
werden angezeigt, aber keinerlei Postings). Als Newsreader habe ich Netscape
4.05 auf einem Windows 95 PC im Netz verwendet und da lag auch der größte
Wauwau begraben, aber das habe ich erst einige Stunden später bemerkt.
In weiterer Folge habe ich mir die leafnode-Sourcen der Version 1.9 besorgt
und compiliert. Dies hat sehr gut funktioniert und ich konnte schon sehen,
wieviele Postings in einer gewählen Gruppe sind. Lesen konnte ich
sie allerding noch immer nicht. Ein kurzer Check mit dem Forte Free Agent
auf dem Windows-PC hat mit dann die Augen und somit das Tor zum Usenet
geöffnet. Andere Newsreader als Netscape funktionieren mit älteren
leafnode-Versionen gut, nur Netscape läuft erst am 1.9.2 (!!!) zufriedenstellend.
Die Doku die mit den Sourcen mitkommt ist, wie leider
öfters beobachtet, recht betagt. So erwartet die Version 1.9.2 ihr
config-file in /etc/leafnode/, alle früheren Versionen (also auch
1.9) wie in der Doku beschrieben /usr/lib/leafnode/.
Festgelegt (und änderbar) ist dies im File configure.
Leafnode besteht aus mehreren Programmen, für mich
waren leafnode als nntp-Server und fetch zum Abholen/Abliefern der Postings
wichtig.
Ganz zu Beginn wäre es eine gute Idee die config-Datei
von leafnode zu bearbeiten. Diese steht bei Versionen ab 1.9.2 in /etc/leafnode.
Die Datei config.example dient als Vorlage und ist zu aller erst nach config
zu kopieren. Der einzige Eintrag, der geändert werden MUSS ist der
Servername von dem die News geholt werden sollen. Normalerweise ist dies
der Newsserver des Providers. Für mein Archiv habe ich die expire-Einträge
sehr hoch gesetzt, da ich aber das Programm expire nicht aufrufe dürfte
das egal sein.
Zuerst muß der Name des Rechners auf dem leafnode
läuft in /etc/nntpserver eingetragen werden. Wenn unbekannt,
dann mal mit hostname nachschauen.
Es ist notwendig, daß es im System einen User news
gibt. Dieser wird üblicherweise von der Distibution angelegt und sollte
minimale Rechte haben. Wenn nicht vorhanden, dann einfch mit adduser
news anlegen.
Anders als bei INN kann (muß) Installation und
Betrieb als root erfolgen.
Damit ein Client auf den Server zugreifen kann muß
dort ein entspechender Dämon laufen. Gestartet wird dieser bei Bedarf
durch den inetd-"Super Server".
Dann ist für den nntp-Dienst in der Datei /etc/inetd.conf
folgender Eintrag nötig:
nntp stream tcp
nowait news /usr/sbin/tcpd /usr/local/sbin/leafnode
Ein typischer SuSE-Leger (Falle) ist hier das Verzsichnis
/usr/local/sbin/. SuSE (so auch das RPM-Paket, das ich ursprünglich
installiert hatte) verwendet /usr/sbin/, wenn man dann aber die Sourcen
ohne Änderungen in configure selbst compiliert befinden sich die neuen
Files eben in /usr/local/sbin/. Bei RedHat hat man dieses Problemchen nicht.
Wichtig: es kann nur einen geben; nntp-Eintrag meine
ich. Sollte in /etc/inetd.conf bereits eine Zeile mit nntp beginnend stehen,
dann diese bitte auzukommentieren (# vor die Zeile setzen).
Dann ist ein Restart des inetd angesagt (SuSE mit: kill
-HUP <pid of inetd>, RedHat mit: /etc/rc.d/init.d/inet restart
).
Wenn alles richtig eingestellt ist, dann sollte es möglich
sein mit telnet localhost nntp auf den leafnode-server einzuloggen.
Hier ist besonders die Versionsnummer zu beachten. Wenn eine ältere
Nummer erscheint als erwartet, dann liegt das u.U. an den oben erwähnten
Verzeichnisunstimmigkeiten. Raus kommt man mit quit. Die Hilfe mit help
ist nicht wirklich eine Hilfe (aber wenigstens ein guter Witz).
Jetzt ist fetch drann: wird /usr/(local/)sbin/fetch
zum erstem mal aufgerufen, dann holt es vom Provider (siehe config-Datei)
die Liste aller vorhandenen Gruppen. Das kann schon ein ganzes Weilchen
dauern, bei einer ISDN-Anbindung ist sicher ein Kaffe drinnen. Besonders
zu Beginn ist es sinnvoll fetch ein klein wenig zuzusehen. Durch die Option
-v wird fetch gesprächig, durch -vv noch mehr, durch -vvv noch mehr,
mehr als -vvvv gibts dann aber nicht. Wenn fetch fertig ist, tut sich einmal
nichts, erst durch drücken einer Taste kommt man wieder zum Eingabeprompt.
Jetzt gilt es einmal den Newsclient zu starten, den leafnode-Server
als Newsserver anzugeben und Gruppen zu abonieren. Das eben übertragene
File muß angezeigt, die Gruppen in gewohnter Weise selektiert werden.
Danach erscheint in den gewählten Gruppen jeweils
ein Posting. wird dieses gelesen, legt leafnode ein entsprechendes File
an, damit fetch beim nächsten Aufruf diese Gruppe vom Newsserver holt
(die Anzahl der Postings die maximal gelesen werden steht in im config-File).
Daher: gleich nochmal fetch (-v ... -vvvv) aufrufen.
Die Postings werden abgeholt. Auch das kann dauern.
Mehr steckt nicht dahinter. Fast nicht, denn es ist noch
ein Meschanismus nötig, der neue Postings abholt bzw. ins Usenet stellt.
Ein Cronjob eignet sich ganz hervorragend (z.B: 12 * * * * root /usr/local/sbin/fetchnews
>/dev/null.)
Im config-File gibt es einen Paremeter "timeout_long",
der angibt, wann eine Gruppe, die nicht mehr gelesen wird auch nicht mehr
vom Quellserver geholt werden soll. In meinem Fall war es aber notwendig
einige Gruppen immer abzuholen, auch wenn ich im Urlaub bin und sonst niemand
diese Gruppen liest. Ein kleiner Trick mit einem eigenen Cronjob (als User
news) wirkt Wunder:
11 * * * * /usr/bin/touch /var/spool/news/interesting.groups/at.linux
11 * * * * /usr/bin/touch /var/spool/news/interesting.groups/at.netway
That's it. Keep on posting ;-)
Nachtrag: Anderungen
der Version 1.9.4
Bessere Konfigurierbarkeit in der config-Datei. So kann
eingestellt werden, wie lange eine bestimmte Gruppe bezogen weren soll;
der oben ganannte Trick mit touch via cron kann somit entfallen.
Das help-menü beim Aufruf des leafnode-Servers (via
Telnet) verdient seinen Namen.
Der Name von fetch wurde auf fetchnews geändert.