Figure 1. Eröffnungsbildschirm von Gnus
News im Verein
Der Verein Central-Net bietet, wie viele andere Provider auch, seinen Mitgliedern den Zugriff auf einen eigenen News-Server an. Für viele Einsteiger in die Welt des Internets ist zunächst das World Wide Web die Spielwiese. Nach einiger Zeit wird man jedoch feststellen, daß der Besuch von Web-Seiten zwar interessant, unterhaltsam oder informativ ist, die Informationen jedoch relativ statisch sind und die mögliche Interaktivität des Mediums Internet oft nur unzureichend genutzt wird.
Auch die häufig auf Web-Servern angebotenen Chat-Foren oder lokale Newsgroups helfen auf Dauer nicht weiter, da die Besucher regelmäßig manuell dort (und möglicherweise auf vielen anderen Servern) vorbeischauen müssen. Nimmt man an vielen Foren teil, so ist das zeitaufwendig und teuer, außerdem ist bei jedem Forum die Benutzeroberfläche anders. Bei News landen alle Diskussionen auf dem eigenen (lokalen) Server, so daß mit einem Programmaufruf alle aktuellen Diskussionen verfolgt werden können. Außerdem sind viele News-Reader wesentlich besser für diese Art der Diskussionen geeignet als Web-Browser oder HTML-Seiten.
Bereits in der Frühzeit der Vernetzung begann man, persönliche Nachrichten (sogenannte Mails) zwischen den Systemen auszutauschen. Oftmal möchte man aber mit seinen Fragen, Hinweisen oder Ergüssen mehr als eine (bereits bekannte) Person erreichen oder Kontakt mit anderen Benutzern, die Interesse an verschiedenen Themen haben, aufnehmen. Daher wurden recht schnell sogenannte Mailinglisten eingerichtet, das sind Verteiler für verschiedenen Themen. Eine Mail an diesen Verteiler erreicht in kürzester Zeit alle dort hinterlegten Benutzer.
Mit intensiverer Nutzung dieses Mediums zeigte sich, daß für manche Situationen auch Mailinglisten nicht das geeignete Medium sind. Die Net-News oder News waren geboren. Noch heute findet man den Begriff des Usenet, das sind die Rechner, die mittels Mail und News miteinander kommunizieren. Transportmedium ist häufig das Internet, oft wird aber auch noch UUCP zum Transport der Daten über Wählverbindungen benutzt.
News ist eine verteilte Datenbank, in der von vielen Rechnern rund um die Welt die Artikel verschiedenster Benutzer gespeichert und ausgetauscht werden. Die Datenmenge ist in sogenannte Newsgroups (politisch korrekt auch GABELN[1] genannt) unterteilt, die hierarchisch geordnet sind. Damit ist es relativ einfach möglich, zu einem Thema eine geeignete Gruppe zu finden.
[1] Gruppen, Areas, Bretter, Echos, Listen, Newsgroups
Das Verfahren »News« basiert auf einer Reihe von Vereinbarungen. Auf der technischen Seite ist es das Format der Artikel, die zwischen den Systemen ausgetauscht werden. Das Artikelformat ist in rfc822,[xref to BIBLIOENTRY unsupported] rfc1036 und son-of-rfc1036 (das ist der hoffentlich irgedwann erscheinende Nachfolger zu rfc1036) festgelegt. Mit Hilfe dieser Informationen kann jeder News-Server die für ihn relevanten Daten speichern und nach einer gewissen Haltezeit auch wieder löschen. Der Transport der Daten erfolgt entweder über UUCP oder NNTP (beschrieben in rfc977).
Organisatorisch steht hinter dem System »News« die Absprache der News-Administratoren, sich gegenseitig mit News zu versorgen (zu »feeden«) und diese den eigenen Benutzern zur Verfügung zu stellen (Das System stammt aus einer Zeit, wo auf einem Rechner möglicherweise sehr viele Benutzer arbeiteten). Das erwünschte Verhalten der Benutzer selbst wird in der sogenannte Nettiquette rfc1855 geregelt, das Usenet ist auch heute noch weitgehend in der Lage sich selbst zu verwalten.
Im Usenet gibt es keine zentrale Administration, d. h. im Prinzip ist jeder Administrator frei darin, welche Newsgroups er auf seinem System führt und an andere weiterleitet. Das manifestiert sich oft darin, daß lokale Gruppen eingerichtet werden, in denen Tests durchgeführt werden oder lokale Ereignisse diskutiert werden können.
Ohne gewisse Regeln würde binnen kurzer Zeit das Chaos ausbrechen, wenn der Austausch und die Einrichtung von Gruppen unkoordiniert ablaufen würde. Je nach News-Hierarchie gibt es unterschiedliche Verfahren zur Einrichtung oder Löschung einer Gruppe. In der de-Hierarchie werden Gruppen nur nach ausführlicher Diskussion (in de.admin.news.groups, kurz dang) und einer Abstimmung eingerichtet oder gelöscht. Die Aufrufe zur Diskussion und Abstimmung sowie die Veröffentlichung der Ergebnisse erfolgen parallel in themen-verwandten Newsgroups und de.admin.news.announce (kurz dana). Das Verfahren ist in den verschiedenen Texten, die regelmäßig nach de.newusers.infos gepostet werden, dokumentiert. Ähnliches gilt für andere Hierarchien.
Eine gewisse Ausnahme sind die Hierarchien de.alt.* und alt.*, hier ist das Verfahren wesentlich abgekürzt. In einer speziellen Gruppe (de.alt.admin bzw. alt.config) wird über die Einrichtung der Gruppe diskutiert und nach einer gewissen Zeit diese eingerichtet, wenn zu der Gruppe Konsens besteht.
Das Einrichten oder Löschen von Gruppen, das in einer Abstimmung beschlossen wurde, ist für den News-Administrator nicht bindend, allerdings werden seine Benutzer früher oder später nach den entsprechenden Gruppen fragen. Technisch wird Verwaltung der Gruppen durch spezielle News-Nachrichten, sogenannte Control-Nachrichten, gesteuert. Mehr zu diesem Thema folgt weiter unten.
Technisch besteht News aus zwei Teilen: dem News-Server, der für einen Rechner, eine Domain oder einen Provider die Daten speichert und den Anwendern bereitstellt. In der Anfangszeit wurde A News als Server verwendet, das irgendwann durch B News ersetzt wurde. Die nächste Version, C News, ist heute noch auf vielen Rechnern im Einsatz. Viele andere Systeme verwenden INN (InterNetNews), manche proprietäre Systeme wie Lotus Notes, Netscape oder andere. Für den Anwender ist es praktisch egal, welche Software auf dem Server zum Einsatz kommt, er greift über eine standardisierte Schnittstelle, in der Regel NNTP (Net News Transfer Protocol) auf den Server zu.
Der Benutzer liest und schreibt News mit einem speziellen Client, dem News-Reader. Hier hat jeder praktisch freie Auswahl, beliebte Programme sind Netscape, Outlook (schüttel), tin, trn, slrn, knews, Gnus etc. Der Client kann entweder die Daten direkt von der Festplatte des Servers lesen, wenn Client und Server auf einem Rechner laufen. In der Praxis wird man aber fast immer den Zugriff über das Netzwerk mittels NNTP (Net News Transfer Protocoll) durchführen (rfc977).
Es gibt Zwischenlösungen wie »Crosspoint« oder »Agent«, die News in einer eigenen Datenbank verwalten. Auch Gnus kann dies, allerdings ist diese Lösung für Multi-User Systeme nicht besonders geeignet, da mehrere User möglicherweise denselben Artikel mehrfach übertragen und speichern. Im folgenden werden wir uns daher u.a. auch mit 'echten' News-Servern beschäftigen.
“ There are no threads in a.b.p.erotica, so there's no gain in using a threaded news reader. ” -- unknown Source
Der Benutzer ist in der Wahl seines News-Readers relativ frei. In der Regel arbeitet jeder Client mit jedem Server problemlos zusammen, so daß technische Aspekte hier unberücksichtigt bleiben können. Die Auswahl des Readers hängt sehr stark von persönliche Vorlieben und dem, was man von anderen Benutzern sieht oder hört ab. Suchen Sie sich einfach ein Programm aus und lernen Sie das Medium kennen[1]. Wenn Sie mehr Erfahrung gesammelt haben, machen Sie sich auf die Suche nach einem Programm, das Ihren Anforderungen entspricht. Es gibt keinen 'besten' Newsreader, obwohl für mich »Gnus« die beste Wahl ist.
[1] Man sagt, daß sie erstmal ein paar Tage oder Wochen als Beobachter an News teilnehmen sollten, um den Stil und die Sprache der anderen Diskussionsteilnehmer kennenzulernen.
In den folgenden Abschnitten werde ich anhand des »Gnus« einige Bemerkungen zu Newsreadern machen. Diese sind, wie oben angemerkt, persönlich gefärbt. Sie sollten wohl in jedem Fall einen Überblick über nützliche (und manchmal überflüssige) Funktionen erhalten. »Gnus« ist in Emacs-Lisp geschrieben und läuft innerhalb des Editors GNU-Emacs oder XEmacs. »Gnus« ist sehr flexibel und leistungsfähig und kannn sehr weitgehend an die Bedürfnisse des Benutzers angepaßt werden. Außerdem ist der Quellcode verfügbar, so daß man sich bei Interesse mit der Arbeitsweise des Programmes vertraut machen kann oder eigene Erweiterungen produzieren kann (aber normalerweise nicht nötig hat).
Nach dem Start des Readers wird üblicherweise eine Liste der abonnierten Newsgroups angezeigt. Der Newsreader Gnus bietet die Möglichkeit, Gruppen nach verschiedenen Kriterien zu ordnen. Eine beliebte Art ist das Sortieren in verschiedene Topics, so daß logisch zusammengehörende Themen auch gemeinsam angezeigt werden. Zu jeder Gruppe wird die Anzahl der neu hinzugekommenen Nachrichten angezeigt. Viele Newsreader zeigen nur die Gruppen an, in denen ungelesene Artikel vorhanden sind. Die Abbildung Figure 1 zeigt beispielhaft die Gruppenübersicht in »Gnus«.
Bei dem meisten Readern wird man eine einzelne Gruppe anwählen und dann eine Übersicht der dort vorhandenen Nachrichten angezeigt bekommen. Dabei sind wieder verschiedene Sortierungen möglich, die meisten Reader bieten zunächst die Sortierung nach Threads (zum selben Thema gehörenden Postings) an. Je nach Reader und Konfiguration werden entweder alle Artikel oder nur die Start-Postings eines Threads angezeigt.
Wie der Benutzer durch die Gruppen und Artikel navigiert, ist von Programm zu Programm unterschiedlich, Sie sollten also einen Blick in die Hilfe oder das Handbuch werfen. Für mich wesentlich ist, daß der Newsreader vollständig mit nur wenigen verschiedenen Tasten bedient werden kann. Dadurch kann eine Hand über den entsprechenen Tasten schweben und das Wechseln zwischen Artikeln und Gruppen geht schnell von der Hand.
Die Abbildung Figure 2 zeigt wiederum beispielhaft die Darstellung der Threads in der Artikel-Übersicht in Gnus.
Der eigentliche Text wird in Artikeln oder Postings gespeichert. Viele Reader bieten die Möglichkeit, Header auszublenden oder speziell zu formatieren. Ebenfalls beliebt ist die farbliche Unterscheidung der verschiedenen Textabschnitte, die von unterschiedlichen Autoren stammen und gequotet (zitiert) wurden. Die Abbildung Figure 3 zeigt die Darstellung eines Artikels. Dabei ist zu bemerken, daß Gnus dem Benutzer viele Möglichkeiten bei der Gestaltung der Darstellung eröffnet.
Das Verfassen eines neuen Artikels wird »posten« genannt. Bevor Sie das erste Mal in einer Gruppe posten, beobachten Sie diese Gruppe einige Tage. Außerdem sollten Sie vorher in einer lokalen Testgruppe mindestens ein Test-Posting abgesetzt haben und von Ihrem News-Administrator prüfen lassen (Die Chancen stehen gut, daß der das bei jedem Test-Posting macht). Verwenden Sie in keinem Fall eine beliebige Gruppe zum Testen. Haben Sie keine lokale Gruppen, dann nehmen Sie de.test. Das Besondere an dieser Gruppe ist, daß verschiedene Server Ihnen Ihr Posting per Mail zukommen lassen mit dem Hinweis, daß dieses auf dem Server eingegangen ist.
Früher mal, als News noch neu war, kam es häufiger vor, daß im Header aus technischen Gründen keine korrekte Mail-Adresse zu finden war. Um Problemen vorzubeugen wurde häufig die Adresse in der sogenannten Signatur zusätzlich untergebracht. Heute ist das nicht mehr nötig, dennoch setzen viele Anwender eine Signatur unter Ihre Postings. Die meisten News-Reader machen das automatisch, wenn die Datei ˜/.signature existiert. Es ist üblich (aus: son-of-rfc1036), daß die Signatur nicht länger als vier Zeilen sein sollte; es ist normalerweise auch nicht notwendig.
Das News-System ermöglicht es, in viele verschiedene Newsgroups gleichzeitig zu posten (Crosspost). In der Regel werden Crosspostings nicht gerne gesehen. Sollte es aber, zum Beispiel für eine Ankündigung, notwendig sein in mehrere Gruppen zu posten, so sollten Sie die nachfolgenden Diskussionen in einer Gruppe bündeln, indem Sie die Zeile Followup-To: im Header entsprechend einfügen. Ein spezieller Werte ist hier 'poster', der als Antwort eine Mail an denn Autor vorsieht. Viele Newsreader beachten diese Vorschläge, man kann diese aber auch ignorieren.
Wenn Sie auf ein fremdes Posting antoworten wollen, dann haben Sie zwei Möglichkeiten: öffentlich (als »Follow-Up«) und privat (als Mail). Viele Anwender mögen es garnicht, wenn Sie ein Follow-Up gleichfalls als Mail (das ist eine sogenannte »Courtesy-Copy«) erhalten, besonders wenn diese Mail nicht als solche markiert ist.
Wenn Sie auf ein Posting anworten, so können Sie das Original- oder Bezugsposting zitieren (quoten). Zitieren Sie so, daß der ursprüngliche Autor zu erkennen ist und nur das, was zum Verständnis unbedingt notwendig ist. Im Header Ihres Artikels steht zusätzlich ein Verweis auf den Original-Artikel (in der »References:«-Zeile), so daß interessierte Leser sich mit einem Tatsendruck das vollständige Original ansehen können.
In der Netiquette wird vorgeschlagen, daß man möglichst einfach quoten soll, also nur mit einem Quote-Zeichen wie »:« oder »>«. Als Autor können Sie dies unterstützen, indem Sie zwischen die Absätze eine Leerzeile einfügen und nicht mehr als 70 Zeichen in einer Zeile schreiben. Manche Leute, wie ich beispielsweise, zitieren mit Namen; das ist aber oft nicht erwünscht.
Eine nützliche Funktion, die fast jeder News-Reader bietet sind sogenannte Kill-Files. Hier kann man einzelne Autoren oder Themen hinterlegen, die grundsätzlich aus der Anzeige ausgeschlossen werden. Wenn Sie also bestimmte Personen oder Subjects nicht interessieren, packen Sie diese in Ihr Kill-File. Manche Anwender verkünden Ihre Entscheidung, bestimmte Personen ins Kill-File aufzunehmen mit dem Geräusch »PLONK«, da beim Aufschlag im Kill-File entsteht.
Kill-Files alleine sind oft genug nicht ausreichend um in Gruppen mit hohem Aufkommen an Nachrichten den Überblick zu behalten. In diesen Fällen erweisen sich sog. Score-Files als nützlich. Hier können Autoren oder Titeln (oder beliebigen Header-Feldern) eine höherer oder niedrigerer Score zugeteilt werden. Anschließend kann nach diesem Score sortiert werden oder die Darstellung (z.B. farblich) angepaßt werden. Eine Erweiterung davon ist das Adaptive Scoring von Gnus. Hier merkt sich das Programm, welche Personen und Titel bisher interessant waren und versieht diese automatisch mit einem hohem Score. Personen, die selten oder nie gelesen werden erhalten, genauso wie uninteressante Titel, einen niedrigeren Score. Nach einer Weile pendelt sich dieses Verfahren gut ein und vereinfacht das Leben des Benutzers, kann aber außerdem manuell überschrieben werden.
Wenn man von den abgedruckten Bildschirmbildern absieht, ist dieser Abschnitt bisher vollkommen unabhängig vom Newsreader. Daher hier nur eine kurze Aufstellung beliebter Newsreader: tin, trn, slrn, krn, knews, nn, Gnus oder Netscape.
Ein Posting besteht, aus technischer Sicht betrachtet, aus zwei Teilen, dem »Header« und dem »Body«. Im Header werden Verwaltungsinformationen transportiert, im Body der vom Benutzer verfaßte Text. Die Abbildung Figure 4 zeigt einen einfachen News-Artikel.
Figure 4. Ein einfacher News-Artikel
Path: delphi.central.de!uranus.central.de!eregion.central.de!lemmy Date: 23 Jul 1998 22:35:00 +0200 From: lemmy@eregion.eregion.central.de (Mathias Homann) Newsgroups: central.test 5 Message-ID: <6yPnEnZNRYB@schleppi.eregion.central.de> Subject: test 1 2 3 X-Newsreader: CrossPoint v3.11 R/C182 Organization: private site @ moringen Lines: 15 10 Xref: delphi.central.de central.test:334 this is a test bye 15 Lemmy |
Betrachten wir zunächst den Header genauer. Jede Zeile beginnt mit einem Schlüsselwort, gefolgt von einem Doppelpunkt. Im Rest der Zeile folgt dann der zugehörige Text. Eine Reihe von Headern sind in verschiedenen RFCs standardisiert, besonders die Header »X-« können jedoch beliebig verwendet werden. Die folgende Aufzählung erläutert die Header im obigen Artikel genauer.
Weg des Artikels vom Sender bis zum aktuellen News-Server. Dieser Eintrag wird durch jeden Server, über den der Artikel übertragen wird verlängert. Oft wird er dazu verwendet, den gerade empfangenen Artikel nicht an den Sender zurück zu übertragen.
Sendedatum des Artikels. Problematisch kann hier sein, daß die verschiedenen Leser in unterschiedlichen Zeitzonen zuhause sind und das Format sich durchaus zwischen verschiedenen Postings unterscheidet. Gnus hat eine Funktion, mit der man das Datum z.B. durch die seither abgelaufene Zeitspanne darstellen lassen kann.
Hier steht üblicherwiese die Mail-Adresse des Absenders. Diese kann jedoch beliebig geändert werden, sie ist also kein Beweis für die Identität des Authors. Da in letzter Zeit viele Werbe-Mails an Poster im Usenet versendet werden, gehen einige Leute dazu über hier verfälschte Adressen anzugeben. Damit wird aber die Kommunikation erschwert und das Medium Usenet langsam zerstört.
Der Absender hat die From:-Zeile geändert, hier steht dann der originale Wert, mit dem man möglicherweise garnichts anfangen kann.
Dieser Header gibt an, in welchen Newsgroups der Artikel auftauchen soll. Hier können mehrere Newsgroups durch Kommata getrennt angegeben werden; allerdings sollten Sie dann mit Hilfe des Followup-To:-Headers die Diskussion in einer Gruppe bündeln.
Damit ein Artikel nicht mehrfach übertragen werden kann wurde als eindeutige Identifikation dieser Header eingeführt. Kein Programm, das am Usenet beteiligt ist, darf diesen Header ändern, sonst könnten sog. Dupes entstehen.
Der »Betreff« des Artikels. Hier sollten Sie eine möglichst treffende Angabe zum Inhalt Ihres Artikels machen. Viele Leser ignorieren Postings mit dem Subject »Hilfe«, genauso ist es unhöflich in Großbuchstaben zu SCHREIEN oder zu viele Ausrufe- oder Fragezeichen zu verwenden.
Manchmal interessant, am ehesten noch für statistische Zwecke ist diese Zeile, die hoffentlich angibt, welchen News-Reader der Author benutzt.
Diese Zeile kann entweder durch den Autor oder seinen News-Server eingefügt werden. Hier findet man oft den Firmennamen oder den Namen des Providers.
Ist ein Muß-Header, der nötigenfalls vom Server generiert wird und gibt die Anzahl der Zeilen im Body an. Manche Leute verwenden diese Zahl, um Artikel als mehr oder weniger lesenswert zu markieren. Ich mache das mit Postings der Zeilenzahl 0.
Dieser Header wird (u.a.) von INN generiert und ermöglicht es dem News-Reader einen crossgeposteten Artikel nur ein einziges Mal anzuzeigen.
Gibt die Adresse des Rechners an, von dem der Client aus gepostet hat.
Cancel-Nachrichten
Im vorherigen Abschnitt wurde an einigen Stellen auf Konventionen hingewiesen. Viele von diesen sind einerseits gesunder Menschenverstand, andererseits ist vieles auch in rfc1855 festgelegt. Auch die Texte in de.newusers.info sind hier zu erwähnen.
Dinge, die mich persönlich sehr stören, sind u.a.:
Verfälschte Mail-Adressen
Überlange Signaturen
Komplett gequotete Artikel
Benutzer, die fremde News-Server mißbrauchen
Werbung in Newsgroups (SPAM)
Exzessives Crossposten ohne Followup-To:
überlange und unstrukturierte Postings
Das News-System ist eine verteile Datenbank mit News-Artikeln. Jeder Server hat eine lokale Datenbasis, die regelmäßig mit seinen Nachbarn (den Newsfeeds) abgeglichen wird. Dabei ist die Hardware und das Betriebssystem, auf dem der Server läuft praktisch egal. Viele News-Server im Internet laufen unter Unix und verwenden den INN. Viele ältere Server benutzen immer noch CNews, der Unterschied ist für Benutzer und Feeds egal. Weitere News-Server sind z.B. Lotus Domino oder der von Netscape.
Hier geht's um inn, den freien Newsserver. Normalerweise werden die eingehenden Artikel im Verzeichnis /var/spool/news abgelegt. Dabei wird für jede Newsgroup ein eigenes Verzeichnis angelegt und jedes Posting als eine Datei (der Name ist eine laufende, lokal vergebene Nummer) gespeichert. Daher benötigt man viel Plattenplatz und sehr viele i-Nodes. Beim Anlegen von /var/spool/news sollte also unbedingt die Option für viele i-Nodes angegeben werden, unter Linux geht das mit mke2fs -i 1024 /dev/hdxx.
Die wichtigsten Dateien für den Betrieb des News-Servers sind die Dateien active und history. In der active-Datei sind die auf dem Server verfügbaren Gruppen festgelegt. Änderungen an dieser Datei sollten normalerweise nicht manuell, sondern mit Hilfe des Programmes ctlinnd (siehe auch Abschnitt ...) durchgeführt werden.
Die history-Datei sorgt dafür, daß doppelt gefeedete Postings erkannt werden können. Dazu wird von jedem Posting die (eindeutige) Message-ID gespeichert und auch länger als der eigentliche Artikel aufgehoben. Sollte derselbe Artikel nocheinmal vom Newsfeed kommen, so kann er abgelehnt werden. Das ist einer der Gründe dafür, daß die Message-ID in keinem Fall geändert werden sollte. Beliebt sind hier insbesondere Fehler in Gates zu anderen Netzen, wie z.B. dem Fido-Netz.
Die Namen der Gruppen werden in der Datei newsgroups gespeichert. Viele Reader holen die Dateien active und newsgroups bei jedem Start, so daß dies relativ lange dauern kann. Gerade bei Modem-Verbindungen ist es daher sinnvoll, die Anzeige der Gruppen-Beschreibungen auszuschalten um sich die langwierige Übertragung der newsgroups-Datei zu ersparen.
Der News-Server INN läuft unter der Kennung des Unix-Benutzers news. Alle betroffenen Dateien müssen daher diesem Benutzer gehören und les- bzw. schreibbar sein. Wenn Sie eine Funktion des News-Systems als Benutzer root ausführen, dann stimmen hinterher viele Permissions nicht mehr. Es gibt Gerüchte, daß sich die Situation nach einem Expire-Lauf verbessern würde. Gibt's es eigentlich ein entsprechendes Prüf-Programm? In manchen Fällen hilft der Aufruf des Programmes inncheck weiter.
Das Volumen eines Newsfeeds kann, je nach den bestellten Gruppen sehr groß sein. Da die üblichen Festplatten nur eine beschränkte Kapazität haben, müssen regelmäßig alte, nicht mehr benötigte Artikel gelöscht werden. Dies erfolgt mit Hilfe des sog. Expire-Laufes, der einmal täglich stattfinden sollte. Da dies, gerade bei größeren Servern, länger dauern kann und die Maschine belastet, sollte dies nach Möglichkeit nachts geschehen.
Die Steuerung des Expire erfolgt mit Hilfe der Datei expire.ctl. Hier kann für jede Gruppe bzw. Hierarchie eine Haltezeit festgelegt werden, nach der Artikel automatisch gelöscht werden. Da Unix ein Multi-User System ist, ist also jeder Benutzer für sich selbst verantwortlich, die gewünschen Artikel dauerhaft in seinem Home-Verzeichnis zu sichern.
Figure 5. expire.ctl
## $Revision: 1.4 $ ## expire.ctl - expire control file ## Format: ## /remember/:<keep> 5 ## <patterns>:<modflag>:<keep>:<default>:<purge> ## First line gives history retention; other lines specify expiration ## for newsgroups. Must have a "*:A:..." line which is the default. ## <patterns> wildmat-style patterns for the newsgroups ## <modflag> Pick one of M U A -- modifies pattern to be only 10 ## moderated, unmoderated, or all groups ## <keep> Mininum number of days to keep article ## <default> Default number of days to keep the article ## <purge> Flush article after this many days ## <keep>, <default>, and <purge> can be floating-point numbers or the 15 ## word "never." Times are based on when received unless -p is used; ## see expire.8 ## If article expires before 14 days, we still remember it for 14 days in ## case we get offered it again. Depending on what you use for the innd 20 ## -c flag and how paranoid you are about old news, you might want to ## make this 28, 30, etc. /remember/:28 ## Keep for 1-10 days, allow Expires headers to work. 25 *:A:1:10:never ## Some particular groups stay forever. # Keep FAQ's for a month, so they're always available *.answers:M:1:35:90 30 news.announce.*:M:1:35:90 # Some other recommendations. Uncomment if you want # .announce groups tend to be low-traffic, high signal. # *.announce:M:1:30:90 35 # Weather forecasts # *.weather:A:1:2:7 # test posts # *.test:A:1:1:1 40 ## Some particular groups stay forever. # dc.dining*:A:never:never:never # uunet*:A:never:never:never *.announce:A:180:180:never 45 *.answers:A:30:30:never control.*:A:180:180:never central.*:A:180:180:never central.test:A:10:10:never kassel.*:A:180:180:never |
Beim Expire-Lauf werden außerdem die Overview-Dateien, das sind Indizes, die News-Readern beim Anzeigen und Suchen in den Gruppen nützlich sein können, ebenfalls angepaßt. Wenn man die Option expireover im News.daily vergißt, dann wachsen einem diese Dateien irgendwann über den Kopf. Das ist besonders kritisch, weil diese Dateien ebenfalls unter /var/spool/news, aber im Pfad over.view zu finden sind und außerdem den Namen .overview haben und damit bei einem ls normalerweise nicht zu sehen sind.
Außerdem wird beim Expire das History-File auf den neuesten Stand gebracht, indem ebenfalls alte Einträge gelöscht werden. Daher ist darauf zu achten, daß immer mindestens der Platz für eine Kopie des History-Files zur Verfügung steht, bevor der Expire läuft. Plattenplatz-Probleme sind beim INN ein sehr lästiges Problem, daher ist die Ausgabe des news.daily, das der Administrator per Mail bekommen praktisch täglich zu prüfen.
Einmal enthält diese Mail wichtige Informationen über den Zustand des Servers, so daß man über das, was in letzter Zeit dort passier ist gut informiert ist. Zusätzlich sind hier einige interessante Statistiken enthalten, die gerade bei einem größeren Server einige Aussagekraft haben können. In neueren INN-Versionen werden diese Statistiken auch als HTML-Dateien abgelegt, so daß man diese einfach mit einem Browser auf nachträglich betrachten kann.
Das Usenet ist eine lose Kopplung von Systemen, die jeweils lokal verwaltet werden. Die Koordination, welche Gruppen existiren wird durch sog. Control-Nachrichten gesteuert. Die Datei control.ctl bestimmt, was der eigene Server mit diesen Nachrichten anfängt. Da im Prinzip jeder Internet-Benutzer weltweit Control-Nachrichten erzeugen und dazu den Header (From:, Approved: etc.) beliebig fälschen kann, sollte die Ausführung durch andere Mittel abgesichert werden.
Als dieses andere Mittel wird PGP eingesetzt. Bei INN kann man einrichten, daß bestimmte Control-Nachrichten nur dann ausgeführt werden, wenn diese mittels PGP korrekt signiert wurden. In diesem Fall ist der Aufwand für die Verwaltung eines News-Servers praktisch null, da alle anfallenden Aufgaben automatisch durch geeignete Programme erledigt werden. Andernfalls muß nämlich der Administrator früher oder später einen Haufen Gruppen wieder einrichten oder löschen, sofern ihm das überhaupt rechtzeitig auffällt.
Figure 6. control.ctl
Revision: 1.4 $
## control.ctl - access control for control messages
## Format:
## <message>:<from>:<newsgroups>:<action>
5 ## The last match found is used.
## <message> Control message or "all" if it applies
## to all control messages.
## <from> Pattern that must match the From line.
## <newsgroups> Pattern that must match the newsgroup being
10 ## newgroup'd or rmgroup'd (ignored for other messages).
## <action> What to do:
## doit Perform action (usually sends mail too)
## doifarg Do if command has an arg (see sendsys)
## doit=xxx Do action; log to xxx (see below)
15 ## drop Ignore message
## log One line to error log
## log=xxx Log to xxx (see below)
## mail Send mail to admin
## verify-pgp_userid Do PGP verification on user.
20 ## verify-pgp_userid=logfile PGP verify and log.
## xxx=mail to mail; xxx= (empty) to toss; xxx=/full/path
## to log to /full/path; xxx=foo to log to ${LOG}/foo.log
##
## The defaults have changed.
25 ##
## Firstly. Most things that caused mail in the past no longer do. This is
## due to proliferation of forged control messages filling up mailboxes.
##
## Secondly, the assumption now is that you have pgp on your system. If you
30 ## don't, then you should get it to help protect youself against all the
## looser control message forgers. If you can't use pgp, then you'll have
## to fix some sections here. Search for *PGP*. At each "*PGP*" found
## you'll need to comment out the block of lines right after it (that have
## 'verify-' in their 4th field). Then uncomment the block of lines that
35 ## comes right after that. You'll also need to change WANT_PGPVERIFY in
## config.data.
##
###########################################################################
40 ##
## DEFAULTS
##
all:*:*:mail
45 checkgroups:*:*:mail
newgroup:*:*:mail
rmgroup:*:*:mail
sendsys:*:*:log=sendsys
senduuname:*:*:log=senduuname
50 version:*:*:log=version
ihave:*:*:drop
sendme:*:*:drop
## DE (German language)
55 checkgroups:moderator@dana.de:de.*:pgp-verify_de.admin.news.announce=checkgroups
newgroup:moderator@dana.de:de.*:pgp-verify_de.admin.news.announce=newgroup
rmgroup:moderator@dana.de:de.*:pgp-verify_de.admin.news.announce=rmgroup
##
60 ## People we'd rather just send over the falls in a barrel
## (aka. The Idiot List) Keep this at the end.
##
## "Real" People
65 all:*@*michigan.com:*:drop |
Ein oder mehr Newsfeeds sind die zentrale Ressource für den Betrieb eines News-Servers. Es ist zwar nett, wenn man sich in-House unterhalten kann, aber wirklich interessant wird es erst, wenn man sich mit anderen News-Lesern intensiv auseinandersetzen kann.
Das News-Volumen ist so groß, daß viele Provider die eingehenden Daten praktisch nur noch durchreichen und anschließend unmittelbar wieder löschen müssen. Mit etwas Glück findet man eine Haltezeit von ein paar Tagen. Unter diesen Bedingungen passiert es leicht, daß bei einem lägeren Ausfall eines Feeds die Versorgung mit News gestört ist. Daher feeden sich viele NNTP-Server vermascht gegenseitig.
In der Datei /etc/news/newsfeeds wird festgelegt, wer auf welchem Weg welche News erhält. Das Format ist nicht gerade einfach, insbesondere die verschiedenen Flags und Parameter sind nicht-trivial. Ein Beispiel für diese Datei findet sich im Listing Figure 7
Figure 7. Die Datei /etc/newsfeeds
## $Revision: 1.17 $ ## newsfeeds - determine where Usenet articles get sent ## Format: ## site[/exclude,exclude...]\ 5 ## :pattern,pattern...[/distrib,distrib...]\ ## :flag,flag...\ ## :param ## Summary of flags: ## <size Article must be less then size bytes. 10 ## Aitems Article checks -- d (must have Distribution header) ## p (don't check for site in Path header). ## Bhigh/low Internal buffer size before writing to output. ## H[count] Article must have less then count hops; default is 1. ## Isize Internal buffer size (if a file feed) 15 ## Nm Only moderated groups that match the patterns. ## Nu Only unmoderated groups that match the patterns. ## Ssize Start spooling if more than size bytes get queued. ## Ttype Feed types -- f (file) m (funnel; param names the ## real entry) p (pipe to program) c (send to stdin 20 ## channel of param's sub-process); x (like c, but ## handles commands on stdin). ## Witems What to write -- b (article bytesize) f (full path) ## g (first newsgroup) m (Message-ID) n (relative ## path) s (site that fed article) t (time received) 25 ## * (names of funnel feed-in's or all sites that get ## the article) N (Newsgroups header) D (Distribution ## header) H (all headers) O (overview data) R ## (replication data). ## Param field depends on T flag. For Tf, relative paths are from the 30 ## out.going directory. For Tp and Tc, it is a shell command to execute. ## If a Tm refers to this entry (which will have its own T param) then "*" ## is expanded to all the funnel sites that triggered this one. Useful ## for spawning one mail process, e.g. ## 35 ## This file is complicated -- see newsfeeds.5! ## This is the local site. ## The "pattern" field gives the intial subscription list for ## all other sites. You might want to put "!control,!junk,!<local>.*" 40 ## there. The "distrib" subfield limits incoming articles. ## ## You can also have ME/bad.site: to refuse articles from a particular ## site (by matching the Path: entry). Other pseudo-sites may be put ## in here, to REFUSE certain types of 3rd-party cancel messages 45 ## (See the "Cancel FAQ" news.admin.net-abuse.misc): ## cyberspam Spam cancels, munged articles, binary postings ## spewcancel just munged articles from runaway gateways ## bincancel just binary postings to non-binaries groups ## 50 ## Note that refusing articles means you won't offer them to sites you feed ## Default of everything to everybody except for junk, control, anything ## with "local" as the newgroup prefix (i.e. matches "localhost.stuff") or ## groups under foo. Articles posted to any group under alt.binaries.warez 55 ## will not get propogated, even if they're cross posted to something that ## is. ME\ :*,@alt.binaries.warez.*,!junk,!control*,!local*,!foo.*,!delphi.*\ /world,usa,na,gnu,bionet,pubnet,u3b,eunet,vmsnet,inet,ddn,k12\ 60 :: # central.de: uranus/uranus.central.de,ud.dinoex.sub.org\ :*,!delphi.*\ 65 :Tf,Wnb: # dinoex: net2.dinoex.sub.de/ud.dinoex.sub.org,uranus.central.de\ :*,!delphi.*\ 70 :Tf,Wnb: ## Create the links for cross posted articles crosspost:*:Tc,Ap,WR:/usr/lib/news/bin/crosspost -s - 75 ## News overview overview!:*:Tc,WO:/usr/lib/news/bin/overchan # Feed all moderated source postings to an archiver #source-archive!:!*,*sources*,!*wanted*,!*.d\ 80 # :Tc,Wn:/usr/news/bin/archive -f -i /usr/spool/news.archive/INDEX # Feed all local non-internal postings to nearnet; sent off-line via # nntpsend or send-nntp. #nic.near.net\ 85 # :!junk/!foo\ # :Tf,Wnm:nic.near.net # A real-time nntplink feed #uunet\ 90 # :/!foo\ # :Tc,Wnm:/usr/news/bin/nntplink -i stdin news.uu.net # Capture all Foo, Incorporated, postings #capture\ 95 # :*/foo\ # :Tp,H2:/usr/news/local/capture %s # A UUCP feed, where we try to keep the "batching" between 4 and 1K. #ihnp4\ 100 # :!junk,!control/!foo\ # :Tf,Wnb,B4096/1024: |
Für jede Site, die News erhalten soll (das kann entweder ein Feed oder eine Leaf-Site sein, die nur von uns mit einer kleinen an News beliefert wird) enthält diese Datei einen Eintrag. Schauen wir uns hier den Eintrag für den Rechner uranus an, zur Verbesserung der Übersichtlichkeit nochmals in Listing Figure 8 dargestellt.
Figure 8. Auszug aus der Newsfeeds-Datei für die Uranus
# central.de: uranus/uranus.central.de,ud.dinoex.sub.org\ :*,!delphi.*\ :Tf,Wnb: |
Kommentare beginnen mit einen Hash-Zeichen (
# |
Der Rechner ud.dinoex.sub.org wird hier ausgeschlossen, da ich als Leaf-Site keinen zusätzlichen Feed zwischen den Rechnern generieren möchte. Da ich nur unregelmäßig per UUCP bei beiden Rechnern polle, macht das einfach keinen Sinn.
Die dritte Zeile in Listing Figure 8 bestimmt, welche Artikel an den Feed weitergereicht werden. Hier werden alle Artikel transportiert, die nicht in einer der lokalen Gruppen delphi.* gepostet wurden. Die meisten Systeme haben eine oder mehrere derartige Gruppen eingerichtet, damit Benutzer lokal testen können oder interne Dinge besprechen können.
Wie ist das mit dem Distribution:-Header?
Die letzte Zeile im Listing Figure 8 beschreibt, auf welchem Weg die Postings zum Feed gelangen. Eine Übersicht über die möglichen Flags findet man in der Man-Page.
Im aktuellen Fall bedeutet 'Tf', daß der Feed bestimmte Daten in einer Datei ablegt. Der Name der Datei ist /var/spool/news/out.going?, kann aber geändert werden. Ein weiteres Programm kann diese Daten lesen und dann entsprechend weiterverarbeiten. Hier wird sendbatch verwendet, um die Daten an das UUCP-System zu übergeben.
Das Flag 'Wnb' legt fest, daß der Dateiname des Artikels (realtiv zum Verzeichnis /var/spool/news und die Größe des Artikels gespeichert werden sollen. Das Programm sendbatch kann aufgrund dieser Informationen dann Pakete erstellen, die eine bestimmte Größe haben. Warum macht das heute noch Sinn?
Weitere Arten von Feeds; Message-ID in das Feed-File?
ctlinnd reload newsfeed "Eine gute Lüge einfallen lassen"
Den Provider wechseln. Alles andere ist ein kurieren an Symptomen, die möglichen Lösungen werden irgendwann zu einem Teil des Problems.
Normalerweise wird der Provider einem Zugriff auf den eigenen News-Server geben. Dort kann man dann mittels NNTP Online lesen. Nachteile: Telefonkosten, Instabilität.
Programme wie Agent oder Leafnode holen die Artikel gesammelt ab, halten diese in einer lokalen Datenbasis und liefer neue Artikel auch wieder beim Provider ab. Vor- und Nachteile?
Wann hat das Verfahren Vorteile? News von fremden Servern ohne Feed allgemein zur Verfügung stellen, z.B. Support-Gruppen von MS, oder StarOffice oder ähnliches. Nachteil: Load auf dem Server, man sollte sich also absprechen.
Beim Zugriff auf den News-Server ist, alleine aufgrund der unterschiedlichen Zugriffsmuster, zwischen Lesern (Benutzern bzw. News-Readern) und Feeds zu unterscheiden. Benutzer lesen i.d.R. deutlich mehr Artikel, als neu erstellt werden. Bei Feeds ist das Verhältnis normalerweise umgekehrt.
Zugriffskontrolle ist sinnvoll, weil ein News-Server einen hohen Resourcen-Verbrauch hat; es wird eine große Platte benötigt und der Rechner benötigt eine Menge Speicher und CPU, sowie eine nicht zu vernachlässigende Bandbreite. Aus diesem Grund hat man bei vielen Servern keinen Zugriff, wenn man nicht aus der lokalen Domain kommt. Außerdem kann so wirkungscoll verhindert werden, daß Fremde über den News-Server unerwünschte Werbung o.ä. in das Usenet posten und jede Menge Schaden verursachen können.
zeus:(ttyp1):~% telnet news nntp Trying 192.168.30.155... Connected to zeus.delphi.central.de. Escape character is '^]'. 5 200 delphi.central.de InterNetNews NNRP server INN 1.7 16-Oct-1997 ready (posting ok). quit zeus:(ttyp1):~% telnet news.uni-stuttgart.de nntp Trying xxx.xxx.xxx.xxx... 10 Connected to news.uni-stuttgart.de Escape character is '^]'. 200 news.uni-stuttgart.de InterNetNews NNRP server INN 1.7 16-Oct-1997 ready (no posting). quit 15 zeus:(ttyp1):~% telnet news.central.de nntp Trying xxx.xxx.xxx.xxx... Connected to news.central.de Escape character is '^]'. 200 news.central.de InterNetNews NNRP server INN 1.7 16-Oct-1997 20 ready (no posting). No permission to talk. |
Der Zugriff der Clients wird mit Hilfe der Datei nnrp.access durchgeführt. Es gibt die häufig eingesetzte Möglichkeit, Zugriffe auf IP-Adressen bzw. Hostnames einzuschränken. Eher selten wird die Zugangskontrolle mit Name und Paßwort verwendet, der Verwaltungsaufwand ist einfach zu groß. Ein Beispiel für diese Datei finden Sie in Listing Figure 10.
Figure 10. Zugriffsschutz mit nnrp.access
## $Revision: 1.4 $ ## nnrp.access - access file for on-campus NNTP sites ## Format: ## <host>:<perm>:<user>:<pass>:<groups> 5 ## Connecting host must be found in this file; the last match found is ## used, so put defaults first. ## <host> Wildcard name or IP address ## <perm> R to read; P to post ## <user> Username for authentication before posting 10 ## <pass> Password, for same reason ## <groups> Newsgroup patterns that can be read or not read ## To disable posting put a space in the <user> and <pass> fields, since ## there is no way for client to enter one. ## 15 ## Default is no access, no way to authentication, and no groups. *:: -no- : -no- :!* ## Foo, Incorporated, hosts have no password, can read anything. localhost:Read Post:::* *.delphi.central.de:Read Post:::* |
Die obige Kontrolle greift nur für Zugriffe von Clients, die durch NNRP behandelt werden. Zugriffe, die wie Feeds direkt NNTP verwenden, werden in der Datei hosts.nntp eingestellt. Auch hier kann wieder ein Paßwort (je Feed) vergeben werden. Das Listing Figure 11 enthält wiederum ein Beispiel.
Figure 11. Die Datei hosts.nntp
## $Revision: 1.7 $ ## hosts.nntp - names and addresses that feed us news ## Format ## <host>: 5 ## <host>:<password> ## <host> can be a name or IP address; no wildcards. Any hosts not ## listed here are handed off to nnrpd. localhost: |
Die Unterscheidung zwischen News-Reader und Feed liegt in den unterschiedlichen Protokollen begründet. Feeds können (und sollen) Artikel mittels IHAVE einliefern, wohingegen Reader dazu das Protokoll-Kommando POST verwenden müssen. Im Zweifelsfall macht das entweder keinen oder einen großen Unterschied. Im Normalfall ist's eher uninteressant.
Wenn Ihr News-Server Paßworte verlangt, so können und müssen sie diese in der Konfiguration Ihres News-Clients angeben. Wenn Ihr Feed Paßworte verlangt, dann können sie diese in der Datei /etc/news/passwd.nntp hinterlegen.
moderators, overview.fmt inn.conf, innctld.
Für viele Anwendungen kann ein News-Server ein wichtiges Kommunikationsinstrument in einer Gemeinschaft sein. Siehe Motorola-Projekt
UDP, aktiv und passiv
NoCeM, SPAM-Killer, Breitbart-Index etc.
grephistory
Wie geht das Protokoll? Stevens fragen
Die meisten Sites, die eine Standleitung haben, bekommen News per NNTP. Für Anwender, die nur eine Dial-Up-Verbindung haben, ist UUCP stabiler, schneller und damit billiger als News Online zu lesen oder mittels NNTP zu übertragen. UUCP ist zunächst nicht besonders einfach zu konfigurieren (insbesondere muß für jedes System die Konfiguration angepaßt werden), daher bieten viele Provider diese Dienstleistung nicht an. Eine rühmliche Ausnahme sind die IN-Vereine.
Trotz des Namens UUCP ist der Datenaustausch nicht auf Unix-Systeme beschränkt. Es gibt Implementationen des UUCP-Protokolles für praktische alle Betriebssysteme. Unter DOS wird hier sehr gerne CrossPoint eingesetzt.
Hier geht es nicht um die Konfiguration von UUCP, sondern zunächst nur um die Schnittstelle zwischen dem News- und dem UUCP-System. UUCP hat zwei Funktionen: Dateien zwischen den beteiligten Systemen zu kopieren und/oder Befehle auf dem entfernten Rechner auszuführen. Beide Funktionen werden hier benötigt.
In der newsfeeds-Datei des Servers wird festgelegt, welche Systeme wie zu beliefern sind. Für die UUCP-Sites wird regelmäßig der Befehl sendbatch aufgerufen. Dieser verpackt alle neu hinzugekommenen News, die diese Site lt. newsfeeds-Datei erhalten soll in sogenannte Batches. Diese werden an das UUCP-System übergeben mit der Aufforderung die Daten an die Site zu übertragen und auf dem Zielsystem den Befehl rnews auszuführen. Auf dem Zielsystem sortiert dieser die Daten in das News-System ein.
sendbatch und uucico
Internet-Adressen
INN: http://www.isc.org
Leafnode
UUCP
Eine Reihe von Büchern über das Internet widmen sich auch dem Thema News. Leider kenne ich keines dieser Bücher, so daß ich für den Anwender-Einstieg kein Buch empfehlen kann.
Managing UUCP and Usenet, XXX YYY, O'Reilly, ISBN: x.
Die Standards, die das Internet zusammenhalten...
rfc822: Standard for the format of ARPA Internet text messages., D. Crocker.
rfc977: Network News Transfer Protocol, B. Kantor, P. Lapsley.
rfc1036: Standard for interchange of USENET messages, M.R. Horton, R. Adams.
rfc1123: Requirements for Internet hosts - application and support, R.T. Braden.
