Zeitfressender Faktor beim Lesen und Schreiben im Usenet ist nicht
das Laden und Senden der Nachrichten sondern der User vor dem Bildschirm,
der in Ruhe seine News lesen und beantworten will.
Nicht erst seit der Erhöhung der Telefontarife bietet es sich also an,
einen eigenen Server zu Hause zu installieren und Mitteilungen auf diesem
kostengünstig und komfortabel offline zu lesen und zu schreiben.
Inhalt
Notwendige Voraussetzungen
Lesen bildet... Dokumente im Netz
Installation des Newsreaders
/news/etc/
Trau, schau, wem... control.ctl
Horch', was kommt von draussen rein ... incoming.conf
Die inn.conf - Herz aus Gold
moderators
Konfuzius grüßt - newsfeeds
nnrp.access
Einrichten und los
... wir sind fertig!
Befehle
Message-ID und Pfadeintrag - it's not trivial
Wie sieht eine Message-ID aus
Wozu dient diese Message-ID eigentlich?
Wer vergibt die Message-ID?
Mein INN erstellt aber eigene IDs
Unvollständige Liste solcher Provider
Mein Leafnode erstellt auch eigene Message-IDs
Was kann passieren
Andere Gefahren
Um offline News lesen zu können sind folgende Voraussetzungen zu erfüllen:
Auf den zweiten und dritten Punkt werden wir nun näher eingehen.
Informationen zur Verwendung des INN findet man an vielen Stellen im Netz. Nahegelegt sei die Lektüre der Manpages (die sich nach der Installation im Unterverzeichnis man befinden und mit der Erweiterung des Manpaths um dieses Verzeichnis ständig zugreifbar gemacht werden sollten (alternativ kann man auch mit man -M zugreifen.
Weiterführende Informationen und Hilfen findet man in der Newsgruppe de.comm.software.newsserver und auf den Webseiten des ISC.
Der INN in seiner aktuellen Version 2.2 kann vom FTP-Server des ISC im Verzeichnis /isc/inn/ geladen werden. Die Verwendung der vorcompilierten Binaries, die bei diversen Distributionen beiliegen, bietet sich aus Aktualitäts- und Konfigurationsgründen nicht an und wird in diesem Dokument auch nicht behandelt.
Nach dem Download muss das Paket inn-2.2.tar.gz in ein temporäres Verzeichnis entpackt und mittels ./configure --with-perl --prefix=/news configuriert werden. Für diesen Schritt muss sich eine lauffähige Version eines Perl 5.002 oder größer im Pfad befinden, ebenso sendmail. Liegt sendmail nicht im Pfad oder hat es einen anderen Namen, so muss dieses dem configure-Script per --with-sendmail=/pfad/zu/sendmail/binary mitgeteilt werden.
Nach abgeschlossenem configure-Lauf wird das Paket mittels make compiliert. Während dies passiert, wechseln wir auf eine neue Shell und erstellen das Verzeichnis /usr/news (oder wo auch immer ab 500MB aufwärts für Daten und Binaries verfügbar sind) und linken dieses mittels ln -s /pfad/zu/news /news nach /news. Solltest du dich in diesem Schritt entscheiden, eine andere Verzeichnisstruktur als ich zu verwenden, so musst du in den folgenden Schritten die Pfadangaben entsprechend anpassen.
Der Compiliervorgang sollte jetzt abgeschlossen sein, mittels make install wird der Server installiert.
Diese Datei regelt, wer auf unserem System Steuernachrichten (control messages) ausführen lassen darf. Nachdem wir eine Leafsite sind und ganz gerne selbst entscheiden würden, welche Gruppen eingerichtet sind, bietet es sich an, alle Nachrichten wegzuwerfen und ab und an einen Blick auf den aktuellen checkgroups zu werfen.
all:*:*:drop
... alle weiteren Zeilen kannst du getrost löschen.
Wer als Server auf unseren Server verbinden darf, wird in der incoming.conf geregelt. Auch hier tragen wir dem Leafsite-Gedanken Rechnung - nur wir selbst dürfen auf unseren Server verbinden.
peer ME {
hostname: "localhost, 127.0.0.1"<
}
In der inn.conf ist das Grundverhalten des INN geregelt, diese Datei hat sich von den Versionen 1.x zur heutigen 2.2 stark geändert und erlaubt es heute auch, Dinge zu konfigurieren, die vorher ein Neucompilieren erfordert hätten. Um diese Datei zu verstehen sollte man die mitgelieferte Man-Page lesen, die wichtigsten Konfigurationen sind hier erklärt:
organization: nethammer - beat the SHIT out of Trolls
Welcher Organization: Header soll vom Server eingefügt werden, wenn kein Header im Posting vorhanden ist?
pathhost: nethammer.qad.org
Welchen Pfadeintrag (siehe Message-ID und Pfad) soll der Server setzen?
domain: qad.org fromhost: nethammer.qad.org
Domain deines lokalen Rechners (Mails des Servers gehen an news@domain und kommen von news@fromhost). Müssen existente FQDN sein (siehe Message-ID und Path)
complaints: lart@no.cabal.org
Beschwerdestelle. Muss eine existente E-Mail-Adresse sein und wird als X-Complaints-To: im Header eingefügt.
Eine einzige Zeile muss hier stehen. Sie wird immer dann verwendet, wenn Postings in moderierte Gruppen gesendet werden. Das %s wird durch den Gruppennamen ersetzt, Punkte in "-" umgewandelt.
*:%s@moderators.isc.org
D.h. alle Nachrichten gehen an moderators.isc.org, wenn die moderierte Gruppe z.B. de.admin.arnooo.warmduscher hieße, würde die Mail an de-admin-arnooo-warmduscher@moderators.isc.org gehen.
Die zweifellos komplizierteste Konfigurationsdatei ist die Datei newsfeeds in der der Umgang mit empfangenen Postings (egal woher) geregelt wird. Hier müssen wir einen Eintrag definieren, welcher von uns gepostete Nachrichten in den Ausgangskorb legt um diese später von unserem NTA an den Provider versenden zu lassen.
ipf/newsreader.ipf.de\ :*,!local,@babylon.*,@net.*,@bofh.*,@nethammer.*\ :Tf,Wnm:ipf
Die einzelnen Felder in Folge:
Eine genauere Beschreibung des Formats findest du in der Datei newsgroups selbst - bechte bitte, dass du den ME:-Eintrag sowie crosspost und overview nicht löschen darfst.
In der nnrp.access sind die Reader aufgelistet, die lesend und schreibend auf den Server zugreifen können. Lösche zunächst alle Zeilen aus dieser Datei und füge dann ein:
*::::!* 127.0.0.1:Read Post:::* stdin:Read Post:::* localhost:Read Post:::*
So können alle User, die auf dem lokalen Recher sitzen, in alle Gruppen (*) lesen und schreiben. Der letzte gefundene passende Eintrag zählt.
Unser Newsserver ist jetzt konfiguriert. Wir müssen ihm nur noch eine kleine Gruppenliste geben und seine Datenbanken initialisieren. Dazu erstellen wir eine minimale Gruppenliste in der /news/db/active, in folgendem Format:
control 0000000001 0000000000 y junk 0000000001 0000000000 y
Dies legt die notwendigen Gruppen control (für Steuernachrichten) und junk (für Müll, den wir nicht haben wollen) an. Mit dem Befehl ../bin/makehistory -o (als User news, im Verzeichnis /news/db stehend) werden die Datenbanken erzeugt und...
Der Server wird mit dem Befehl /news/bin/rc.news gestartet und mit einem telnet localhost 119 seine Funktion überprüft. Nun muss noch der NTA (News Transport Agent) suck aus dem Netz (siehe Freshmeat für neueste Version) gezogen werden und mit ./configure ; make ; make install installiert werden. Das Setup des suck ist trivial. Im Hinterkopf sollten wir immer behalten, welchen Namen wir im letzten Feld der /news/etc/newsgroups angegeben haben; dieses Feld benötigt suck um zu wissen, welche Artikel er versenden soll.
Wenn alles läuft, dann kann man als User news mit dem Befehl /news/bin/ctlinnd newgroup gruppenname status neue Gruppen anlegen. gruppenname ist der volle Name der Gruppe, status ist y (alle dürfen posten und lesen), m (moderiert) oder n (nur Lesen).
Um Gruppen zu löschen gibt es den Befehl ctlinnd rmgroup welcher den Gruppennamen als Argument erwartet.
Der Server kann mit der Anweisung ctlinnd shutdowngrund runtergefahren werden.
Nach RFC822 (das ist der, der festlegt, wie ein Mailheader auszusehen hat - kann auf ftp.ripe.net/rfc/ gesaugt werden) hat eine Message-ID das Format
<einmalig@domain_name>
wobei einmalig ein beliebiger String (in dem kein <, > oder @ vorkommen darf) ist, dessen Einmaligkeit für mindestens zwei Jahre garantiert sein muss, und domain_name der Name des Systems ist, über den der Artikel das Usenet betritt.
Die Message-ID ist das einzig Eindeutige an einer Nachricht. Anders als From: oder Betreffzeile klassifiziert sie ein Posting vollständig, d.h. sie ist der Wert, nach dem die Newsserver dieser Welt ein Posting verwalten. Um z.B. festzustellen, ob ein Server bereits ein angebotenes Posting in seinem Datenbestand hat (oder hatte und es bereits löschte), vergleicht dieser die ID der angebotenen Nachricht mit seiner internen Liste (der sog. History).
Spätestens der Newsserver, auf dem die Nachricht eingeliefert wird und damit an die große weite Welt (oder auch nicht) verteilt, generiert diese ID. Aufgabe der ID ist es, mindestens zwei Jahre weltweit eindeutig zu sein um zu verhindern, dass Nachrichten doppelt auf demselben Server (sog. Dupes) erscheinen. Das ist böse, macht Arbeit und trägt zu einem kleinen aber nicht unerheblichen Teil zum Unlesbarwerden des Usenet bei.
Ja, denn dein INN ist ein vollwertiger Newsserver, der all das tut, was ein Newsserver tun sollte, also auch Message-IDs generiert für Postings (Nachrichten), die noch keine haben. Da eine ID nun eindeutig sein muss, ist es sinnlos - genauer gesagt grundfalsch - eine ID zu generieren, die als Teil nach dem @ den Hostnamen deines Providers oder einen erfundenen Hostnamen hat. Woher soll dein INN denn wissen, ob diese ID schon vergeben ist (und das in den letzten zwei Jahren). Als Möglichkeit bleibt dir also nur, einen FQDN (also einen eigenen Domainnamen) zu bekommen oder zu verhindern, dass dein INN eine Message-ID erzeugt, wenn du auf ihn postest.
Letzteres macht man mit einem Editor und dem Quellcode des INN, das ist nicht trivial und kann noch mehr Probleme erzeugen als es löst, deshalb werde ich auf diese Möglichkeit nicht eingehen.
An einen eigenen, für dich reservierten, Hostnamen kommst du auf mehreren Wegen. Der zweifellos einfachste ist eine Nachfrage beim eigenen Provider, ob er dir eine Subdomain zuweisen mag. Diese Domain muss keinesfalls Mails annehmen oder sonst irgend wie aktiv sein, es muss nur sichergestellt sein, dass außer dir niemand diese verwendet.
Bei allen weiteren hilft das Nachfragen beim Newsmaster sicherlich weiter.
Alternativ gibt es das Projekt nethammer bei dem es auch Subdomains gibt, sowie die Dienste von http://www.ddns.org/, http://www.eu.org/, http://www.subdomain.de/, http://www.dyndns.org/, http://www.dhis.org/ und http://www.dhs.org/.
Auch Leafnode ist ein Newsserver und erstellt deswegen ebenfalls eigene Message-IDs für Nachrichten, die noch keine haben. Im Wesentlichen gilt das für den INN Gesagte.
Falls man sich einen Domainnamen besorgt hat und Leafnode diesen beibringen moechte, genügt es, im Konfigurationsfile die Option fqdn = entsprechend zu setzen. Nähere Erläuterungen findet man in der Dokumentation zu Leafnode.
Stell dir vor, ein Posting wird nicht mehr als "schon vorhanden" erkannt. Dieses Posting würde auf allen Newsservern dieser Welt ein zweites Mal auftauchen. Wenn dein Provider auch noch das From: umschreibt (T-Online tut das z.B.), dann wird aus dem:
From: jonas@ping.finger.mount.fsck.de (Jonas Luster) Message-ID: <dont-delete-me.934ksdhf67.fsf@nethammer.qad.org>
ein
From: Mein Name <meine@mail.de> Message-ID: <ich-tus-trotzdem@linux-magazin.de>
Also tauchen Nachrichten von Menschen neu in den News auf, die deinen Absender tragen. Unschöne Sache.
Passiert ist sowas schnell. Um zu verhindern, dass ein Newsserver Artikel, die er von einem Host hat, an diesen zurückschickt, wird vor dem Versenden der Path-Header des Postings geprüft. Nur wenn in diesem nicht der Name des Servers, an den man senden will, auftaucht, wird das Posting diesem angeboten. Da man ja nun dummerweise die Message-ID gelöscht hat, nimmt dieser das Posting auch an, gibt ihm eine neue ID und wirft es in die Welt.
Nehmen wir an, du hast in deiner newsfeeds Folgendes stehen
provider/news.provider.de\
und dein Provider schickt dir Postings mit
Path: news.provider.de!news.ander-provider.de
dann werden diese Nachrichten nicht in den Ausgangskorb (out.going) gelegt.
Wenn nun dein Provider seinen Pfadeintrag ändert (sowas kommt in den besten Familien vor) und vergisst, dich zu informieren (sowas soll vorkommen) dann matchen Postings, die vom Provider geholt werden, nicht mehr auf den Teil nach dem / oben und gehen in den Ausgangskorb - batsch, Dupe-Schwemme.
Zigtausende von Newsservern routen diesen Artikel ein zweites Mal, eine unzählbar höhere Anzahl von Clients bekommt ihn ein zweites Mal und die Newsadminsitration vieler beteiligter Systeme haben eine nicht unerhebliche Mehrarbeit - und das ist schon recht oft vorgekommen.
Auch vom Path-Header sollte jeder seine Finger lassen. Im Path-Header sind die Systeme aufgeführt, durch die der Artikel auf jeden Fall schon einmal geroutet wurde. Modifiziert man diesen Header, bekommen die gelöschten Systeme den Artikel ebenfalls ein zweites Mal angeboten.
Dasselbe gilt für den Date-Header. Wenn im Posting nicht explizit ein Expire: angegeben ist und der Newsadmin dieses zulässt, wird anhand des Date: Headers die Haltezeit eines Postings bestimmt. Diesen auf ein aktuelles Datum zu setzen hätte den Effekt, dass Unmengen an uralten Postings in Newsgruppen nicht expired (gelöscht) werden.