Netz - Rettung - Recht

Es gibt eine ganze Reihe von Lösungen, um FAQs automatisiert und regelmäßig ins Usenet zu posten:

Zum einen kann man dafür auto-faq von Ian Kluft und Paul W. Schleck nutzen, ein Perl-Script, das ich seit Ende der Neunziger für das automatische Posten diverser FAQs verwende. Es besteht aus einer Konfigurationsdatei, in der für jede FAQ definiert wird, wie sie nach wo gepostet wird. Die einzelnen FAQs sind als Textdateien abgelegt, über die Konfigurationsdatei werden die einzelnen Header und Pseudo-Header festgelegt; Message-IDs, Expires:- und Supersedes:-Header werden automatisch erzeugt. Gepostet werden die FAQs, deren Namen bei Aufruf des Scripts übergeben werden; das läßt sich via cron automatisieren, wobei für jede FAQ ein eigener crontab-Eintrag benötigt wird. auto-faq bietet einen ganzen Haufen an Optionen, hat aber den Nachteil, zum Posten zwingend inews - aus dem INN-Paket - oder vergleichbare Tools zu verwenden; außerdem bietet es eine Unzahl von Funktionen, namentlich auch zum Posten vielteiliger FAQs, die aber - jedenfalls für mich - keine Relevanz hatten. Und auto-faq wurde 1992 entwickelt und hat seit 1999, also seit über 10 Jahren, keine Änderung mehr erfahren …

Eine Alternative dazu stellt postfaq von Russ Allbery dar, gleichfalls in Perl implementiert. postfaq verfolgt ein anderes Konzept: hinterlegt in einer Textdatei wird hier nicht nur der Body der FAQs, sondern das komplette Posting einschließlich aller Headerzeilen. Konsequenterweise wird eine gesonderte Konfigurationsdatei nicht benötigt. Auch postfaq erzeugt die notwendigen Headerzeilen und postet die beim Aufruf angegebenen FAQs, was via cron automatisiert werden kann; es benötigt dazu aber keine externen Programme wie inews o.ä. Es wird aktiv gepflegt (letzte Änderung 2008).

Und eine weitere Möglichkeit ist yapfaq ("yet another postfaq"), ein Script von Marc Brockschmidt, das ich vor etlichen Jahren bereits einmal angetestet hatte, jetzt aber nirgendwo mehr wiedergefunden habe. Marc war aber dankenswerterweise so nett, mir die aktuelle Version (letzte Änderung: Februar 2003) zu überlassen; ich plane, yapfaq noch ein wenig für meine Zwecke zu bearbeiten und weiter zu entwickeln, as time permits. Einstweilen steht yapfaq über ein Git-Repository zur Verfügung.

yapfaq arbeitet grundsätzlich vergleichbar zu auto-faq: in einer zentralen Konfigurationsdatei wird definiert, welche FAQs in welchen Abständen wohin gepostet werden sollen. Die einzelnen FAQs sind als Textdateien abgelegt, wobei die Header durch das Script beim Posten gesetzt und ergänzt werden. Im Unterschied zu auto-faq postet yapfaq aber nicht nur eine bestimme FAQ, sondern alle FAQs, die "dran" sind, die also zuletzt vor - mindestens - dem definierten Zeitraum gepostet wurden. Es ist also nicht notwendig, für jede FAQ einen eigenen crontab-Eintrag zu definieren; vielmehr kann man yapfaq einfach täglich aufrufen, und jede FAQ wird dann gepostet, soweit sie "fällig" ist.

INN bietet vielfältige Möglichkeiten der Benutzerauthentifizierung an. Wenn man einer größeren Anzahl von Benutzern einen Zugang einräumen will, bietet es sich an, die notwendigen Daten - Benutzerkennung, Paßwort, etc. - in einer Datenbank zu halten, bspw. in einer MySQL-Datenbank.

Eine denkbare Lösung dafür, die neben Benutzerkennung und Paßwort auch Namen und E-Mail-Adresse des Benutzers erfaßt sowie ein Flag für aktive/inaktive Benutzer und eine Trennung nach verschiedenen Zugriffsstufen kennt sowie den Zeitpunkt des letzten Logins festhält, möchte ich hier vorstellen. Dazu gehört über das hier vorgestellte Script für den INN hinaus natürlich noch ein passendes (Web-)Interface, mit dem Benutzer angelegt und gelöscht sowie Paßworte geändert werden können etc.

Die Datenbankstruktur sieht folgendermaßen aus:

    CREATE TABLE IF NOT EXISTS `users` (
      `userid` int(11) NOT NULL auto_increment,
      `user` varchar(16) collate latin1_bin NOT NULL default '',
      `password` varchar(16) collate latin1_bin NOT NULL default '',
      `active` tinyint(1) NOT NULL default '1',
      `username` varchar(60) collate latin1_bin default NULL,
      `usermail` varchar(60) collate latin1_bin default NULL,
      `domain` varchar(40) collate latin1_bin default '<EDITME>',
      `llo` date default NULL,
      PRIMARY KEY  (`userid`),
      UNIQUE KEY `user` (`user`)
    );

Die Felder sollten weitgehend selbsterklärend sein; "llo" steht für "last logged in".

Im Rahmen der notwendigen Umbaumaßnahmen und der Neueinrichtung von news.szaf.org habe ich endlich auch die Unterstützung von Cancel-Lock und Cancel-Key umgesetzt.

Cancel sind Steuernachrichten zur Löschung anderer Nachrichten im Usenet, vorgesehen zur Löschung eigener Beiträge (oder ggf. noch zur Löschung von Beiträgen durch den Newsadministrator des einspeisenden Servers). Das Protokoll sieht aber keine Verifizierung dieser Nachrichten vor; grundsätzlich kann also jeder Teilnehmer Nachrichten von jedem anderen Teilnehmer löschen, was zwar unzulässig ist und auf breite Ablehnung stößt, aber dennoch in der Vergangenheit gerne vieltausendfach genutzt wurde, nicht nur für von der Netzgemeinschaft akzeptierte Spamcancel, sondern auch für Attacken gegen bestimmte Newsgroups ("leercanceln") oder Netzteilnehmer. Die als Reaktion oft erfolgte Abschaltung der Cancel-Funktionalität war aber auch nicht der Weisheit letzter Schluß.

Daher wurden bereits Ende der Neunziger Vorschläge gemacht, wie das Canceln von Beiträgen nur für Befugte ermöglicht werden kann, nämlich durch das Hinzufügen eines kryptographischen Cancel-Locks in jedem Beitrag, zu dem eine Cancelnachricht den passenden Cancel-Key enthalten muß, wenn sie ausgeführt werden soll. Cancel-Lock und -Key sind dabei zusammengesetzt aus einem geheimen Schlüssel und der Message-ID des jeweiligen (bzw. zu cancelnden) Postings. Nachdem diese Vorschläge jedenfalls auf Client-Seite nie breite Umsetzung - außerhalb einiger unixoider Newsreader - fanden (und sich das Prinzio vermutlich deshalb auch auf Serverseite nicht durchsetzte), bekamen Cancel-Lock und -Key Ende Juni 2007 durch deren verpflichtende Einführung bei dem bedeutenden deutschen Newsserver news.individual.de neuen Auftrieb. Dort hat man nämlich nicht nur die Überprüfung von Cancel-Locks aktiviert, sondern zugleich hinsichtlich der fehlenden Unterstützung im Client zumindest für die eigenen Nutzer insoweit Abhilfe geschaffen als Cancel-Locks durch den Server (!) automatisch allen Beiträgen hinzugefügt werden (und bei berechtigten Canceln wird in gleicher Weise automatisch der passende Cancel-Key eingetragen).

Bereits kurz danach wurden in de.comm.software.newsserver - namentlich durch Alexander Bartolich - erste Implementationen sowohl zum Einfügen als auch zum Prüfen von Cancel-Lock und -Key für den INN veröffentlicht:

• Cancel-Lock in filter_nnrpd.pl setzen
• Cancel-Lock in filter_nnrpd.pl/cleanfeed.local überprüfen
  

Grundsätzlich sind für die Überprüfung von Cancel-Lock und -Key zwei Varianten denkbar: Entweder läßt man die Cancelverarbeitung in Betrieb und filtert unerwünschte Cancel (und Supersedes!) im filter_innd aus, oder man deaktiviert die Cancel-Verarbeitung komplett und führt nur erwünschte Cancel aus filter_innd heraus aus. Letzteres ermöglicht die weitere Unterscheidung, ob man Cancel ablehnen oder zwar annehmen und weiterverbreiten, aber nicht ausführen oder annehmen und ausführen möchte. Weiterhin muß man sich entscheiden, wie man mit Postings ohne Cancel-Lock umgehen will. Für diese Postings kann man weiterhin alle Cancel akzeptieren - oder keinen. (Und man muß sich eine Lösung für Spamcancel überlegen; entweder akzeptiert man signierte Cancel aus vertrauenswürdiger Quelle, oder man implementiert zugleich NoCeM als Ergänzung.)

Ich habe meinen Downloadbereich mal etwas durchgesehen und veraltete Downloads auf den Dachboden geschoben. Neu dabei ist außerdem checkmail, ein Script zum Prüfen der Zustellfähigkeit von Mailadressen.

Lange Monate habe ich nach einer Lösung gesucht, meine FAQs nur in einer Fassung zu pflegen, daraus aber mit wenig bis keinem Aufwand sowohl eine ansehnliche, in meine Homepage eingepaßte (X)HTML-Fassung wie eine brauchbare Nur-Text-Fassung für das Usenet zu generieren, die nicht nach "lynx —dump" aussieht, sondern Aufzählungen, ja ggf. auch Tabellen verstehen kann.

Der erste Ansatz, nämlich asc2html, erwies sich nach längerem Nachdenken als schlicht dämlich - warum sollte ich eine Textfassung pflegen, aus der ich dann mit viel Umstand und Hängen und Würgen eine HTML-Fassung generiere? Das ist ooch quasi zum Scheitern verurteilt, weil HTML mehr Informationsgehalt als die Textfassung hat, der dann interpoliert werden muß. Außerdem verbricht das Tool eine gar schauderbare Tagsoup. :-/

Der zweite Ansatz war dann Docbook. Monatelange Pause, fast ein Jahr, bis ich mich dann mal dazu aufraffen konnte, damit zu experimentieren. Zwei lange Abende und Nächte später, die ich mit Tutorials und Cygwin verbrachte, wurde mir dann klar: das ist auch nicht das, was ich will. Die Vorteile - alles mögliche daraus generieren zu können - brauche ich nicht wirklich; LaTEX und PDF sind ja fein, aber nicht das eigentliche Ziel. Und warum soll ich von SGML nach HTML und von da nach Text konvertieren?

Die Lösung: ich pflege einfach die HTML-Fassung und konvertiere die dann nach text/plain. Also kann ich die Suche nach diversen Varianten von sgmltools, die dann zufällig auch noch bei mir laufen, aufgeben, und nach brauchbaren html2text-Konverntern suchen.

Und noch eine neue Beta-Version von usestats.pl steht im Downloadbereich zur Verfügung.

Neben der immer noch falschen Berechnung der Postings pro Tag, die nunmehr komplexer, aber dafür auch richtig ist, werden nun auch für jeden Monat die Postings in diesem insgesamt und pro Tag ausgegeben. Außerdem können die geparsten Header gespeichert werden, damit für weitere Durchläufe, ggf. mit anderen Auswertungen, die gewünscht werden, nicht wieder alle Postings neu geparst werden müssen.

Eine neue Beta-Version von usestats.pl, dem Newsgroup-Statistik-Script, steht jetzt im Downloadbereich zur Verfügung.

Alle vorherigen Versionen weisen in der Auswertung der “Postings pro Tag” einen bösen Denkfehler auf, der sich auswirkt, wenn es postingfreie Tage gibt. Die wurden nämlich nicht ausgegeben, mit der Folge, daß alle Angaben für die Folgetage in der entsprechenden Woche “aufrücken” und die “Leertage” sich dann am Ende der Woche finden, die Angaben also nicht mehr stimmig sind. Gleichermaßen fehlerhaft war die Berechnung der Postings pro Tag, bei der ebenfalls “Leertage” nicht berücksichtigt wurden.

Aufgrund einer weiteren Änderung wird jetzt auch das Modul Getopt::Std benötigt; dafür kann (und muß) man eine Configdatei jetzt vernünftig, d.h. mit Leerzeichen zwischen “-c” und Dateinamen, übergeben.

Eine neue Version von usestats.pl, dem Newsgroup-Statistik-Script, steht jetzt in meinem Downloadbereich. Neu ist, dass man auch eine Statistik der Postings pro Gruppe erhalten kann, wenn man mehrere Gruppen auswertet; außerdem sind ein paar Codeverbesserungen eingebaut.

Ich hoffe, es ist dabei nichts kaputtgegangen. Tester und Kommentare sind immer willkommen.