Aus dem Leben eines Szlauszafs (Entries tagged as inn)

Kaum macht man es richtig, schon funktioniert es!

thh@inter.net (Thomas Hochstein) — Sat, 29 Jan 2011 17:21:46 +0100

Dieser Tage stellte ich fest, daß mein Newsserver offensichtlich keine Steuernachrichten mehr ausführt. Aber warum bloß?

Die Rücknahme einiger jüngerer Änderungen - die sicherstellen sollten, daß die Steuernachrichten nicht nur ausgeführt, sondern mir auch gemailt werden (mit Dank an den Widder!) - brachte keine Lösung. Also bin ich zu systematischen Debugging übergegangen; dank fehlenden Loggings anhand des Einstreuens von Ausgabeanweisungen in eine Kopie des zuständigen Scripts (controlchan). Stunden später[tm] stellte sich dann als Ursache ... ein Bedienerfehler heraus (wie immer). Wenn man Steuernachrichten für eine bestimmte Hierarchie verwerfen will, dann sollte man den Namen der Hierarchie nicht nur als Kommentar in die control.ctl eintragen, sondern für den entsprechenden Eintrag auch ein Muster wie “hierarchie.*” verwenden. “*” alleine führt nicht zum erwünschten Ergebnis (sondern zum Verwerfen aller Steuernachrichten für alle Hierarchien).

INN-Funktionsweise: Expire

thh@inter.net (Thomas Hochstein) — Tue, 26 Jan 2010 21:40:00 +0100

Wie ich vor anderthalb Wochen schrieb, fehlte meiner Beschreibung der Funktionsweise des Newsservers INN noch der Teil über Expire; namentlich deshalb, weil mir die Funktionsweise selbst nicht hinreichend klar war. Inzwischen habe ich aber, so denke ich, dank der hilfreichen Erläuterungen in de.comm.software.newsserver den notwendigen Durchblick gewonnen und die Beschreibung entsprechend ergänzt.

INN: Authentifizierung gegen MySQL-Datenbank

thh@inter.net (Thomas Hochstein) — Sat, 23 Jan 2010 17:55:00 +0100

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

Die Module DBI und Time::Localtime werden benötigt; außerdem müssen natürlich die Zugangsdaten für die Datenbank definiert werden:

use DBI;
use Time::localtime;

### DB Vars - EDIT ME!
$conf{’dbdriver’} = “mysql”;
$conf{’dbhost’}   = “localhost”;
$conf{’database’} = “”;
$conf{’dbuser’}   = “”;
$conf{’dbpw’}     = “”;
$conf{’dbtable’}  = “”;
$conf{’actcheck’} = 1;

Der eigentliche Zugriff auf die Datenbank kommt in die Subroutine “authenticate”, die dann vom INN aufgerufen wird:

### DB init
my $dbs = sprintf(’DBI:%s:database=%s;host=%s’,$conf{’dbdriver’},$conf{’database’},$conf{’dbhost’});
my $dbhandle = DBI->connect($dbs, $conf{’dbuser’}, $conf{’dbpw’}, { PrintError => 1 });

### Query database and disconnect.
my(@result);
# quote SQL
my $sql_user = $dbhandle->quote($attributes{username});
my $sql_pass = $dbhandle->quote($attributes{password});
my $query = sprintf(“SELECT domain FROM %s.%s WHERE user = %s AND password = %s”,$conf{’database’},$conf{’dbtable’},$sql_user,$sql_pass);
if ($conf{’actcheck’}) {
  $query .= ' AND active = 1’;
};
my $dbquery = $dbhandle->prepare($query);

Wenn die Abfrage erfolgreich verlief, es also einen passenden Benutzer mit passenden Paßwort gibt, wird der Zeitpunkt des letzten Logins in der Datenbank aktualisiert:

if ($dbquery->execute()) {
 @result = $dbquery->fetchrow_array;
 $dbquery->finish;
 if (@result) {
  # log timestamp
  my $tm = localtime;
  my $today = sprintf(’%04d-%02d-%02d’, $tm->year+1900, ($tm->mon)+1, $tm->mday);
  $query = sprintf(“UPDATE %s.%s SET llo = ‘%s’ WHERE user = %s”,$conf{’database’},$conf{’dbtable’},$today,$sql_user);
  $dbquery = $dbhandle->prepare($query);
  $dbquery->execute();
  $dbquery->finish;
 };
};
$dbhandle->disconnect;

Danach ist nur noch entsprechend zu reagieren:

### check password and respond appropriate
if (@result) {
 my $user = $attributes{username} . ‘@’ . $result[0];
 return (281, ‘Authentication successful: ‘.$user, $user);
} else {
 return (481, ‘Authentication failure’);
}

Das komplette Perl-Script gibt’s in meinem Git-Repository.

Eingebunden wird dieses Perl-Script in die readers.conf des INN als Authentification Group:

auth “users-mysql” {
        hosts: *
        perl_auth: “/usr/lib/news/bin/auth/passwd/perl_mysql”
}

Es liefert dann eine Benutzerkennung der Form user@domain zurück; die domain kann dann in folgenden Access Groups referenziert werden:

access “customers” {
 users: “*@customer.news.host.example”
 newsgroups: “*, !internal.*, !special.*”
 access: “RP”
}

INN-Funktionsweise: Steuernachrichten und Filter

thh@inter.net (Thomas Hochstein) — Sun, 17 Jan 2010 17:06:00 +0100

Der Urlaub neigt sich endgültig seinem Ende zu, und - leider - ist die Todo-Liste, insbesondere hinsichtlich angedachter größerer Projekte, die man abends oder am Wochenende (zumindest bei meiner derzeitigen zeitlichen Belastung) nicht sinnvoll angehen kann, nicht merklich geschrumpft. Stattdessen habe ich mich (ungeplant) auf die Datensammlung zu Usenet-Hierarchien und danach dann auf den Umgang mit git konzentriert und am Ende eine ganze Reihe Dinge umgesetzt, die auf der ToDo-Liste eigentlich gar nicht vorkamen.

Nachdem Newsserver in den letzten Wochen eine so große Rolle gespielt haben ist es jetzt zum Abschluss nur recht und billig, wenn ich (nach mehrjähriger Pause) meine Seite zur Funktionsweise des INN endlich um die noch fehlenden Teile ergänze; umso mehr, als ich meine Webseiten mittlerweile in ein git-Repository eingecheckt habe und daher auch den Umgang damit üben kann, insbesondere, was fraktionierte Commits betrifft. Das ist eine sehr nette Sache: man nimmt eine Reihe unterschiedlicher Änderungen vor, die nichts miteinander zu tun haben - bspw. eine Ergänzung der INN-Beschreibung auf der einen Seite und Richtigstellungen/Tippfehlerkorrekturen, über die man zufällig stolpert, auf der anderen -, und kann diese Änderungen aber selektiv committen, bspw. zuerst nur die Ergänzungen, dann die Änderungen, dann die Rechtschreibfehler. Das macht die Commits übersichtlicher und ggf. auch leichter zu reverten, weil man nur logisch zusammengehörendes auch zusammen committet, ohne daß man beim Editieren darauf achten müßte.

Ich kann also hiermit verkünden, daß ich die Abschnitte über Steuernachrichten (control.ctl), Filter und Reader-Authentifizierung sowie eine recht umfangreiche Linksammlung ergänzt habe. Fehlen nur noch Erläuterungen zum Expire, aber das muß ich erst einmal selbst verstehen.

Update 2010-01-26: Inzwischen steht auch die Erläuterung zum Expire online. Die Seite ist damit - endlich! - fast fünf Jahre nach ihrer ersten Erstellung komplettiert. Ich hoffe, sie hilft dem einen oder anderen (vermißt wurden die fehlenden Teile allerdings offensichtlich nicht, wenn man nach dem erhaltenen Feedback über die Jahre geht ...).

INN: NoCeMs verarbeiten

thh@inter.net (Thomas Hochstein) — Sat, 12 Dec 2009 22:56:00 +0100

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:

digitale Schlüssel der Versender herunterladen (bspw. von der NoCeM Registry: NoCeM-Keyring)
konfigurieren, welche NoCeMs ausgeführt werden sollen (nocem.ctl)
entsprechenden Feed in perl-nocem einrichten
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

thh@inter.net (Thomas Hochstein) — Sun, 15 Nov 2009 16:02:00 +0100

“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

thh@inter.net (Thomas Hochstein) — Sat, 14 Nov 2009 21:49:00 +0100

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

Egal, wie man zu der Überprüfung von Cancel-Lock und -Key steht: zumindest das automatische Einfügen derselben in Postings der eigenen Benutzer (Cancel-LOck für jedes Posting, Cancel-Key für Cancel und Supersedes) ist in keinem Fall schädlich und durchaus hilfreich, eben weil es Server gibt, die Cancel nur noch mit passendem Cancel-Key ausführen. Es bietet sich an, diese Funktionalität für den INN im filter_nnrpd zu implementieren, dem Filter also, den alle, aber auch nur die lokal geposteten Beiträge durchlaufen. Eine denkbare Implementation ist die folgende für filter_nnrpd.pl, basierend auf dem Posting von Alexander Bartolich:

#
# Do any initialization steps.
#
use Digest::MD5  qw(md5_base64);
use Digest::SHA1();
use Digest::HMAC_SHA1();
use MIME::Base64();

$CANCEL_LOCK = ‘hereasecretword’;

#
# Filter
#
sub filter_post {
   my $rval = “” ;             # assume we’ll accept.
   $modify_headers = 1;

   [...]

   # Cancel-Lock / Cancel-Key
   add_cancel_lock(%hdr, $user);
     
   if (exists( $hdr{“Control”} ) && $hdr{“Control”} =~ m/^cancel\s+(<[^>]+>)/i) {
      my $key = calc_cancel_key($user, $1);
      add_cancel_item(%hdr, ‘Cancel-Key’, $key);
   }
   elsif (exists( $hdr{“Supersedes”} )) {
      my $key = calc_cancel_key($user, $hdr{“Supersedes”});
      add_cancel_item(%hdr, ‘Cancel-Key’, $key);
   }
     
   return $rval;
}

#
# Cancel-Lock / Cancel-Key
#
sub add_cancel_item($$$) {
   my ( $r_hdr, $name, $value ) = @_;
   my $prefix = $r_hdr->{$name};
   $prefix = defined($prefix) ? $prefix . ' sha1:’ : ‘sha1:’;
   $r_hdr->{$name} = $prefix . $value;
}

sub calc_cancel_key($$) {
   my ( $user, $message_id ) = @_;
   return MIME::Base64::encode(Digest::HMAC_SHA1::hmac_sha1($message_id, $user . $CANCEL_LOCK), ‘’);
}

sub add_cancel_lock($$) {
   my ( $r_hdr, $user ) = @_;
   my $key = calc_cancel_key($user, $r_hdr->{’Message-ID’});
   my $lock = MIME::Base64::encode(Digest::SHA1::sha1($key), ‘’);
   add_cancel_item($r_hdr, ‘Cancel-Lock’, $lock);
}

Dort, wo oben [...] steht, können andere Teile des Filters eingefügt werden.

Die Überprüfung kann bspw. in cleanfeed in die cleanfood.local eingebunden werden; zunächst sind wieder die notwendigen Perl-Module einzubinden:

use MIME::Base64();
use Digest::SHA1();
use Digest::HMAC_SHA1();

Danach wird in local_filter_cancel() die Validität des Cancels geprüft und in local_filter_after_emp() die Validität von Supersedes:

#
# local_filter_cancel
#
sub local_filter_cancel {
   unless($hdr{Control} =~ m/^cancel\s+(<[^>]+>)/i) {
      return “Cancel with broken target ID”;
   }
   return verify_cancel(%hdr, $1, ‘Cancel’);
}

sub local_filter_after_emp {
   if (exists( $hdr{’Supersedes’} )) {
      #return verify_cancel(%hdr, $hdr{’Supersedes’}, ‘Supersedes’);
      # verify_cancel is called, but not returned, so the
      # posting is unconditionally accepted
      # verify_cancel calls INN:cancel() if verification suceeds
      verify_cancel(%hdr, $hdr{’Supersedes’}, ‘Supersedes’);
   }

   return undef;
}

Diese Variante setzt voraus, dass die Cancelverarbeitung in INN deaktiviert ist (innflags: -C in inn.conf setzen und INN neu starten). Sie akzeptiert nur Cancel mit passendem Cancel-Key; Supersedes werden in jedem Fall angenommen, aber nur ausgeführt, wenn sie über einen passenden Cancel-Key verfügen. Bei aktivierter Cancelverarbeitung sind die beiden hervorgehobenen Zeilen auszutauschen, d.h. die eine ist durch Entfernen des Kommentarzeichens zu aktivieren, die andere auszukommentieren.

Die eigentliche “Arbeit” erfolgt dann in den folgenden zusätzlich noch einzufügenden Funktionen:

sub verify_cancel($$$) {
   my $r_hdr = shift || die;
   my $target = shift;
   my $descr = shift;

   my $headers = INN::head($target) || return “$descr of non-existing ID $target”;

   my %headers;
   for my $line(split(/\s*\n/, $headers))    {
      if ($line =~ m/^([[:alnum:]-]+):\s+(.*)/) {
         $headers{$1} = $2;
      }
   }

   my $lock = $headers{’Cancel-Lock’};
   if (defined($lock)) {
      my $key = $r_hdr->{’Cancel-Key’} || return “$descr of $target without Cancel-Key”;
      #return verify_cancel_key($key, $lock, ' target=’ . $target);
      return verify_cancel_key($key, $lock, $target);
   }

   return undef;
}

sub verify_cancel_key($$$) {
   my $cancel_key = shift;
   my $cancel_lock = shift;
   my $msg = shift;

   $msg = ‘’ unless(defined($msg));
   # -thh
   my $target = $msg;
   $msg = ' target=’ . $msg;

   my %lock;
   for my $l(split(/\s+/, $cancel_lock))   {
      next unless($l =~ m/^(sha1|md5):(\S+)/);
      $lock{$2} = $1;
   }

   for my $k(split(/\s+/, $cancel_key))    {
      unless($k =~ m/^(sha1|md5):(\S+)/) { 
        INN::syslog(’notice’, “Invalid Cancel-Key syntax ‘$k’.$msg”);
        next;
      }

      my $key;
      if ($1 eq ‘sha1’) {
         $key = Digest::SHA1::sha1($2); }
      elsif ($1 eq ‘md5’) {
         $key = Digest::MD5::md5($2);
      }
      $key = MIME::Base64::encode_base64($key, ‘’);

      if (exists($lock{$key})) { 
         INN::syslog(’notice’, “Valid Cancel-Key $key found.$msg”);
         # -thh
         # article is canceled now
         INN::cancel($target) if ($target);
         return undef;
      }
   }

   INN::syslog(’notice’,
      “No Cancel-Key[$cancel_key] matches Cancel-Lock[$cancel_lock]$msg”
   );
   return “No Cancel-Key matches Cancel-Lock.$msg”;
}

Auch diese Funktionen sind für eine generell deaktivierte Cancelverarbeitung geschrieben; wenn die Cancelverarbeitung aktiv ist, ist die hervorgehobene Zeile wegzulassen oder auszukommentieren.

Auch der Code für cleanfeed stammt im wesentlichen von Alexander Bartolich und ansonsten von “Ray Banana”.

(Die obigen Codeteile sind aus Postings zusammengetragen, getestet und für meine eigenen Zwecke angepaßt; dieser Blog-Beitrag soll eine mögliche Umsetzung von Cancel-Lock und -Key vorstellen, die ich im Rahmen der Neueinrichtung meines Newsserver vorgenommen habe. Er kann und will keine Darstellung des Für und Wider und der verschiedenen Möglichkeiten des Umgangs damit bieten.)

Umbaumaßnahmen

thh@inter.net (Thomas Hochstein) — Sat, 14 Nov 2009 20:07:00 +0100

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)

thh@inter.net (Thomas Hochstein) — Mon, 27 Apr 2009 20:55:00 +0200

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.

Das ist - mit dem INN 2.4.5-Paket aus Debian Lenny - eigentlich ganz einfach:

Ein SSL/TLS-fähiger nnrpd ist bereits vorhanden (nnrpd-ssl). Wer nicht das vorgenannte Paket verwendet, muß den INN (oder zumindest den nnrpd) ggf. mit “configure --with-openssl” noch einmal kompilieren.
Schlüssel muß man sich erzeugen, sofern noch nicht vorhanden. Vorhandene Zertifikate bzw. Schlüssel sollte man vielleicht am einfachsten kopieren; standardmäßig werden sie in /etc/news gesucht. Das ist verhandelbar respektive konfigurierbar, aber das Zertifikat und der Schlüssel müssen dem User news gehören und die Rechte 600 aufweisen.
Die Konfigurationsdatei /etc/news/sasl.conf muß editiert (oder ggf. angelegt) werden, um die korrekten Pfade zum Zertifikat und dem privaten Schlüssel des Servers aufzunehmen. “tls_cert_file” und “tls_key_file” sind die relevanten Parameter.
Danach muß der nnrpd-ssl nur noch veranlasst werden, auf Port 563 (NNTPS) zu lauschen. Das kann man u.a. über den (x)inetd erreichen, indem man bspw. folgende Konfigurationsdatei in /etc/xinet.d/ einwirft:

service nntps
{
   socket_type     = stream
   protocol        = tcp
   wait            = no
   user            = news
   group           = news
   server          = /usr/lib/news/bin/nnrpd-ssl
   server_args     = -S -p 563
}

Voraussetzung dafür ist, daß die /etc/services den Service “nntps” kennt.

Voila. Wer mag, kann auch noch eine CA daran anflanschen und bspw. Nutzer statt via Paßwort auch via Zertifikat authentifizieren, indem er die readers.conf entsprechend anpaßt, aber daran habe ich keinen Bedarf; mir genügt die Verschlüsselung der Verbindung zwischen Server und Client.

(Danke an Viktor Kafke für die entsprechenden Tips.)

INN: (History-)Cache as cache can

thh@inter.net (Thomas Hochstein) — Sun, 12 Apr 2009 20:52:00 +0200

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.

INN - wie funktioniert er?

thh@inter.net (Thomas Hochstein) — Wed, 27 Apr 2005 22:23:00 +0200

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

thh@inter.net (Thomas Hochstein) — Wed, 13 Apr 2005 20:38:00 +0200

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.

Newsserver

thh@inter.net (Thomas Hochstein) — Sat, 09 Apr 2005 18:17:00 +0200

Nachdem gerade allenthalben das große Newsserver-Fieber ausgebrochen ist, habe ich mal wieder zwei neue Schnippsel online gestellt:

Vielleicht kann ja jemand etwas damit anfangen.