Skip to content

DE-Regio

Wie ich bereits vorgestern berichtete, habe ich die letzten Tage über versucht, die vorhandenen Informationen über deutschsprachige regionale Usenethierarchien zu sammeln, und mittlerweile habe ich begonnen, diese Informationen datenbankgestützt zusammenzustellen. Die ersten Ergebnisse lassen sich bereits auf DE-Regio beschauen: eine Liste der bekannten Regionalhierarchien mit Art, Aktivitäts- und Pflegezustand und Links zu näheren Informationen über die betreffende Hierarchie, soweit vorhanden.

Der nächste Schritt wird jetzt sein, die Informationen zu ergänzen, zu verfizieren und zu aktualisieren und dann die Ergebnisse nach Möglichkeit ins "offizielle" control.ctl aufnehmen zu lassen, das bspw. mit dem INN ausgeliefert wird.

Deutschsprachige regionale Usenet-Hierarchien

Wenn’s mal wieder etwas länger dauert …

Im Zusammenhang mit den geplanten Auffrischungsarbeiten an meinem Newsserver wollte ich auch mal die dort geführten Hierarchien abgleichen und vielleicht auch etwas erweitern; dabei stolperte ich dann ja, wie bereits geschildert, über die "List of Usenet public managed hierarchies", und nachdem dort Lücken bezüglich einiger deutschsprachiger Hierarchien auftauchten, brachte mich das auf den Gedanken, "mal eben" die notwendigen Ergänzungen vorzunehmen. Das sollte ja schnell gemacht sein - schließlich stammen die ganzen deutschsprachigen kleinen und regionalen Hierarchien aus den Anfangszeiten des deutschen Usenets, meistens aus einem universitären oder Vereins-Umfeld, und sind daher vermutlich gut gepflegt, mit kanonischen Listen der existierenden Newsgroups ("checkgroups"), dazugehörigen Webseiten usw. usf., wie ich das beispielsweise von der Karlsruher Regionalhierarchie "ka.*" kannte.

To make a long story short: mitnichten.

Ich sitze jetzt bereits seit letztem Jahr (und damit bald eine gute Woche) daran, mir einen Überblick zu verschaffen, und weiß inzwischen, daß einerseits leider nur noch die wenigsten "kleinen" Hierarchien überhaupt noch aktiv sind, und daß andererseits so Dinge wie Gruppenlisten, Einrichtungsregeln, digital signierte Steuernachrichten etc. pp. in der guten alten Zeit offenbar keine besondere Rolle gespielt haben. Oft genug sind bspw. die Webseiten der früher zum "Individual Network" gehörenden Vereine nicht mehr existent, oder das Angebot - und die Domain - wurde an einen Nachfolger abgegeben, der zwar noch im Internetzugangsgeschäft tätig ist, aber mit Usenet nichts mehr am Hut hat, oder sie wurde "vor kurzem" (bspw. 1998 oder so) aktualisiert. Dementsprechend ist das Web in den meisten Fällen eine sehr schlechte Informationsquelle, aber auch das Usenet und die Newsgroups der jeweiligen Hierarchien erweisen sich nicht direkt als Goldgruben, denn auch dort ist von geposteten Gruppenlisten oder ähnlichen administrativen Dokumenten wenig zu sehen, oder man liest nur davon, daß vor Jahren bereits der bisherige Verantwortliche sein Amt aufgegeben hat und ein Nachfolger nicht in Sicht ist. Der Gruppenbestand variiert teilweise von Server zu Server, und manche Hierarchien scheinen ein "Geisterdasein" zu führen, da die Gruppen zwar auf vielen Servern eingerichtet sind (oft wohl als Folge von Kristian Köhntopps "Regio"-Paket aus der Zeit, als er selbst einen Newsserver betrieb und vielen Neueinsteigern als erster Peer unter die Arme griff), aber die eigentlichen, ursprünglichen "Kernserver" gar nicht mehr existent sind (oder die Gruppen jedenfalls nicht mehr mit ihnen gepeert werden).

Inzwischen habe ich aber sozusagen Blut geleckt und finde es umso wichtiger, für diejenigen, die daran interessiert sind, diese regionale Vielfalt - und sei es nur als wehmütige Erinnerung an die Anfangszeiten des deutschen Netzes - zu erhalten und die wenigen nicht aktiven Hierarchien zu verteilen und zu fördern, die notwendigen Informationen zur Verfügung zu stellen. Ich werde also weiter sammeln und auch aktiv nachforschen und dann das Ergebnis meiner Nachforschungen in geeigneter Weise zusammenstellen. Stay tuned!

List of Usenet public managed hierarchies

Nachdem ich mich derzeit gerade um meinen im November neu eingerichteten Newsserver bemühe und dabei bin, die Liste der geführten Newsgroups einmal zu konsolidieren, bin ich dabei auf die "List of Usenet public managed hierarchies" auf usenet.trigofacile.com gestoßen, der vom derzeitigen Mit-/Hauptentwickler des INN betriebenen Webseite. Dort findet sich ein komfortables Webinterface für den Zugriff auf die durch konventionell anderweitig verfügbaren Daten zur Konfiguration von Usenet-Hierarchien, also sowohl deren Gruppenbestand und dessen Änderungen als auch die notwendige Konfiguration des Newsservers, um Steuernachrichten für Änderungen des Gruppenbestands automatisiert durchzuführen. Die entsprechenden Rohdaten finden sich auf dem FTP-Server des ISC, wie bspw. das Steuernachrichten-Archiv, das generische Active- und Newsgroups-File und das generische control.ctl etc. pp.

Gepflegt werden sie von Russ Alberry, der auch die zugehörigen Scripts und Daten ("control-archive") pflegt.

Nach dieser Erkenntnis habe ich direkt einmal Updates bzw. Ergänzungen für ka.* und szaf.* dort eingeworfen und news.admin.hierarchies abonniert. :-)

INN: NoCeMs verarbeiten

Ergänzend zur bereits im November eingerichteten Auswertung von Cancel-Lock und -Key auf news.szaf.org habe ich heute die Auswertung von NoCeMs eingerichtet. NoCeM ("No See ‘Em") sind, grob umrissen, digital signierte Usenet-Beiträge in einem festen Format zur Löschung meist einer ganzen Reihe anderer Beiträge, also so etwas wie digital signierte Massencancel. Das mit INN ausgelieferte perl-nocem erlaubt die Auswertung dieser Nachrichten fein granuliert nach den jeweiligen Absendern. Zur Einrichtung sind folgende Anleitungen zu empfehlen:

Zur Einrichtung gehören in jedem Fall folgende Schritte:

  1. digitale Schlüssel der Versender herunterladen (bspw. von der NoCeM Registry: NoCeM-Keyring)
  2. konfigurieren, welche NoCeMs ausgeführt werden sollen (nocem.ctl)
  3. entsprechenden Feed in perl-nocem einrichten
  4. ggf. entsprechende Newsgroups, in denen NoCeMs gepostet werden, abonnieren

Der newsfeeds-Eintrag kann beispielsweise so aussehen:

nocem!\
    :!*,alt.nocem.misc,news.lists.filters,de.admin.net-abuse.announce\
    :Tc,Wf,Ap:/usr/lib/news/bin/perl-nocem

Bei den o.g. Anleitungen sind die Pfade ggf. anzupassen. Es hat sich m.E. bewährt, einfach die durch die jeweilige Distribution vorgegebene Struktur zu übernehmen.

Aktueller Cleanfeed

"Cleanfeed" ist, wie der Name bereits nahelegt, ein Filter für den Newsserver INN, der auf per Feed von anderen Newsservern (Peers) empfangene Artikel wirkt, also den Feed "säubert", vor allem von Spam, böswilligen Massenpostings (als Form des "Angriffs" auf bestimmte Newsgroups) und anderen unerwünschten Erscheinungen. Nachdem die ursprünglich in den Neunzigern von Jeremy Nixon begonnene Entwicklung lange eingeschlafen erschien (und der Filter wie auch die mit ihm ausgelieferte Konfiguration zunehmend überaltert wirkten), hat sich seit 2007 nunmehr Steven Crook der Sache angenommen, einige Updates herausgebracht, die Konfiguration weiter modularisiert und eine Webseite mit entsprechender Dokumentation aufgesetzt.

Dieser "neue" Cleanfeed werkelt jetzt nach der einfachen Installation auf news.szaf.org; nur die Konfiguration bedarf sicherlich noch weiter der Verfeinerung (nachdem ich bisher wie mit dem Vorgänger in den vergangenen Jahren primär auf die Defaults setze).

INN: Cancel-Lock und Cancel-Key

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:

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.)

"INN: Cancel-Lock und Cancel-Key" vollständig lesen

Umbaumaßnahmen

Bereits gestern abend hatte ich bis heute in der Früh ;-) störungsbedingt die ersten Dienste (einen semi-öffentlichen bitlbee-Server, die Mailinglisten, den secondary MX für einige Domains) auf die neue Maschine umgezogen; heute war dann der Newsserver dran, der inzwischen auch provisorisch seinen Dienst aufgenommen hat. "Provisorisch" insofern, als er bislang seinen Feed von der alten Maschine bekommt und auch primär nach dort feedet, aber die ersten Peers haben erfreulich schnell auf meine Bitte per E-Mail reagiert und ihren Feed geschwenkt.

Diesmal bemühe ich mich überdies, die Konfiguration des INN direkt von Anfang an "sauber" aufzusetzen und zugleich die ersten Punkte auf (m)einer Liste der geplanten Änderungen und Verbesserungen umzusetzen. Auf dieser Liste finden sich Dinge wie

  • die reproduzierbar funktionsfähige Verifikation von Steuernachrichten,
  • ein aktueller Cleanfeed,
  • das automatische Setzen und das Auswerten von Cancel-Lock/Cancel-Key,
  • die Auswertung (ggf. auch Generierung) von NoCeMs,
  • das Überarbeiten des Gruppenangebots,
  • das Zuweisen von jeweils eigenen Hostnamen pro Feed, um diese ggf. gezielt schwenken zu können
  • usw. usf.

Inbesondere letzteres dürfte sich bei künftigen IP-Änderungen bewähren, weil man dann erst einmal einige Feeds auf die neue Maschine schwenken und sie dabei beobachten kann (laufen Hardware und Software stabil? ist alles richtig konfiguriert? …), und bei Bedarf auch Lastmanagement, also die Verteilung der Feeds auf verschiedenen Maschinen, ermöglichen.

Mit dem Umzug des Newsservers sollte dann die Migration von haystack, der alten Maschine, auf den Nachfolger pasture abgeschlossen sein.

INN und SSL/TLS (Debian Lenny)

Das Internet ist schon lange kein friedlicher Ort mehr, an dem jeder jedem trauen kann - und deshalb wurden die ursprünglichen, unverschlüsselten Kommunikationsprotokolle schon lange durch kryptograhpisch abgesicherte Variationen ersetzt. Telnet verwendet heute wohl niemand mehr offen im Netz, stattdessen gibt es SSH; auch im Mailverkehr pflegt man - hoffentlich - zumindest das Paßwort beim Abruf über POP3 via APOP und beim Versand via SMTP über eine SMTP-Aut-Variante mit Verschlüsselung zu sichern, wenn man nicht ohnehin die ganze Kommunikation SSL-verschlüsselt, und auch diejenigen, die FTP noch nicht durch SCP/SFTP ersetzt haben, nutzen hoffentlich wenigstens SSL, um die Paßwortübertragung zu verschlüsseln.

So weit, so gut, aber schon vor einer ganzen Weile fiel mir auf, daß diese Regel für Netnews (NNTP) offenbar nicht gilt (und für UUCP oft auch nicht …); denn zu seinem oder seinen Newsserver(n) verbindet man sich oft genug noch unverschlüsselt, obwohl auch dort ein Paßwort übertragen wird. So ging es zumindest mir, und ich habe mich am vergangenen Wochenende entschlossen, dagegen etwas zu unternehmen und auch die Verbindung zumindest zu meinem eigenen Newsserver zu verschlüsseln.

"INN und SSL/TLS (Debian Lenny)" vollständig lesen

INN: (History-)Cache as cache can

Die sog. "History" ist beim INN die zentrale Tabelle, die Message-IDs (also die eindeutige Kennung jedes Newspostings) mit ihrem Speicherort verbindet, so daß man ein über eine Message-ID referenziertes Posting auch im Speicher-Backend wiederfinden kann; zugleich wird vor der Annahme von Postings über die History geprüft, dass das entsprechende Posting noch nicht vorhanden ist. Es sammeln sich also große Datenmengen an, auf die zudem ständig zugegriffen werden muß; ein effizientes Handling derselben ist daher Pflicht. INN unterstützt deshalb zur Verkürzung von Zugriffszeiten einen Cache für die History, der die letzten Zugriffe zwischenspeichert.

Seit Jahren betreibe ich meinen Newsserver, seit Jahren stolpere ich in den täglichen Reports des Servers darüber, daß mein Cache offenbar nicht (richtig) funktioniert, und seit Jahren plane ich, daß "bei Gelegenheit" einmal zu überprüfen. Allerdings kommt so eine "Gelegenheit" normalerweise spät oder nie …

Dieser Tage bin ich dann tatsächlich einmal dazu gekommen, das anzugehen und mich zu erkundigen, wo für das schlechte Abschneiden des Caches wohl die Ursachel liegen könne. Diese Werte erscheinen schließlich wirklich nicht berauschend:

History cache:
Reason                      Count     %Count
Cache misses               190461      66.9%
Do not exist                94182      33.1%
Positive hits                   0       0.0%
Negative hits                   0       0.0%

Entscheidend für das (Nicht-)Funktionieren des Caches ist, wie ich dann erfuhr, dessen Größe, die durch den Parameter hiscachesize in der inn.conf gesteuert wird. Empfohlen wurde, ihn auf mindestens 1 kB zu setzen, ggf. auch höher; bei mir stand er, wie ich dann sah, auf 0 … was einiges erklären dürfte. :-)

Nach Erhöhung der Cachegröße auf 5 kB sieht die Sache jetzt doch deutlich besser aus:

Reason                 Count     %Count
Positive hits         183728      65.9%
Negative hits          59022      21.2%
Do not exist           35762      12.8%
Cache misses              81       0.0%

Kleine Ursache, große Wirkung, man kennt das ja.

Once again: Spam gegen Spam

Spam ist ein seit gut 10 Jahren bekanntes Übel, und Spam, der durch Spamfilter rutscht, leider auch nicht so selten, daß er einen Blogeintrag wert wäre. Spam, in dem Spam-Bekämpfung beworben wird, ist allerdings hinreichend selten, dafür aber umso dreister - und wenn die beworbene "Lösung" so (vermutlich unfreiwillig) humoristisch angehaucht ist wie in diesem Fall, dann sollte man diese Verbindung aus Unverschämtheit und unfreiwilliger Komik auch entsprechend würdigen.

Das angepriesene Werk will dem durchschnittlichen Nutzer in drei Schritten nahebringen, wie er Spam vermeiden kann, ja wie Spam geradezu ausgerottet wird, wenn nur jeder diese Schritte befolgt. Kurz gefaßt umfaßt dabei Schritt 1 die Auswahl einer passenden E-Mail-Adresse. In der aus einschlägigen Teleshoppingsendungen und (Tv-)Ratgebern bekannten Sprache erfahren wir auf 53 Seiten, was Spam ist, und daß wir eine E-Mail-Adresse auswählen sollen, die möglichst schwer zu erraten ist; am besten sollen wir dazu mit Papier und Stift in Ruhe unserer Kreativität freien Lauf lassen. Zwar ist richtig, daß damit das Erraten der Mailadresse erschwert oder unmöglich gemacht wird, aber so richtig zielführend mag die Übung dann nicht erscheinen. Garniert wird das (für Fortgeschrittene und Firmen) dann noch mit dem tollen Tip, leicht erratbare Adressen (info@, support@, …) abzuschalten und dort nur einen Autoresponder mit Verweis auf ein Webformular einzurichten (also collateral spam zu produzieren). Daß auch über ein Webformular gespamt werden könnte, scheint dem Autor noch nicht begegnet zu sein (oder es geht über den Horizont des 175-Seiten-Buches hinaus, daß sich gezielt auf E-Mail-Spam beschränken will).

"Once again: Spam gegen Spam" vollständig lesen

INN - wie funktioniert er?

Nachdem "das INN-Fieber umgeht", wie Jörg so nett schrieb, habe ich mich einmal darangewagt, einen kleinen Überblick über die - anfangs nicht ganz so übersichtliche - Funktionsweise des INN zu schreiben. Die Frage nach der Einrichtung haben ja Sven und Isotopp bereits abgedeckt, die einzelnen Programmteile und Konfigurationsdateien sind im wesentlichen durch die (wirklich beispielhaft vielen!) man-Pages abgedeckt, es fehlte aber - so jedenfalls der Eindruck bei meinem Einstieg - eine Einführung in die großen Zusammenhänge, wie die einzelnen Programmteile und Konfigurationsdateien ineinander greifen, wie der INN das tut, was er tut.

INN crash recovery

War der INN in Version 1.7.x wohl recht stabil und genügsam, so daß er auch nach einem unsanften Beenden - des Prozesses oder auch gleich des gesamten Systems - beim Neustart direkt auf die Füße gefallen ist, so sind neuere Versionen (wenigstens unterhalb von 2.4.x) erwiesenermaßen ziemlich mimosig. Gut, wenn man dann das passende Script mit den richtigen Maßnahmen zur Bepuschelung zur Hand hat.