[ lamepage · Linux · News · INN CNFS ]

Umstellung der INN Konfiguration auf Storage API CNFS

Einleitung

INN (InterNetNews) bietet seit der Version 2.x neue Speichermanagement-Systeme für die Aufbewahrung der Newsartikel:

Ein paar Worte über CNFS

CNFS verwaltet die Buffer als sog. Metabuffer, den mehrere physikalische Buffer zugeornet werden können. Bei so einer mehrfachen Zuordnung werden die Artikel cyklisch auf alle zugewiesene Buffer gespeichert, was Performancevorteile bringt. CNFS bringt neben der Geschwindigkeit weitere Vorteile. Dank der Festen Buffergröße lässt sich der Speicherplatz auf der Festplatte besser planen (Vorteilhaft bei kleinen Newsservern die noch zu anderen Zwecken benutzt werden). Das FIFO Prinzip der Buffer macht das Management des Expire-Systems für die Artikel schon fast überflüssig, denn wird platz für neue Artikel gebraucht werden dafür alte entfernt. Expire wird nur für die Übersichtsdatenbank gebraucht.
Es gibt jedoch auch Nachteile: viele INN-Tools laufen nicht ohne weiteres mit CNFS zusammen und müssen an das neue System angepasst werden. Die interne Identifikation der Artikel erfolgt nicht mehr über die Message-Id sondern wird mit Hilfe eines sog. Tokens erreicht. Ein Token ist eine lange Zahl die mit einem @ anfängt und einem @ endet, hier ist ein Beispiel eines Tokens: 
@03004F4E45000000000000006116000000010000D7B31D0097000000@
Dieses Token ist einer der Probleme, die externe Tools von Drittanbietern mit CNFS haben. Das alles muss individuel erwogen werden bei der Entscheidung CNFS einzusetzen.

Was ist zu tun ?

Um CNFS zu aktivieren müssen mehrere Konfigurations-Dateien verändert werden. Zuerst muss INN runtergefahren werden. Dazu loggt man sich als news oder root (und wechselt dann zu news) ein und gibt folgendes ein: 
/etc/rc.d/inn stop
oder 
killall 'innd'
Jetzt wechselt man ins Homeverzeichnis des news (dort wo die ganzen Konfigurationsdateien liegen).

inn.conf

zuerst muss INN wissen, dass es die storage API verwenden soll, dafür editiert man die inn.conf Datei und sucht man nach er Zeile mit dem Wort "storageapi" und ändert diese wie folgt:

inn.conf:

...
storageapi:             true
...
Für weitere Informationen zu den Optionen in der inn.conf siehe Man Page zu inn.conf(5).

storage.conf

Nun kann der Speichermanager konfiguriert werden. Die Datei storage.conf legt die Speichermethode fest, bestimmt wieviele Buffer verwendet und welche Artikel wohin gespeichert werden.
Im unseren Beispiel werden zwei Buffer konfiguriert, der eine für kleinere Artikel und ein anderer für große:

storage.conf:

method cnfs {
        newsgroups: *
        class: 1
        size: 0,3999
        options: SMALLAREA
}
method cnfs {
        newsgroups: *
        class: 2
        size: 4000,1000000
        options: BIGAREA
}
Die Option newsgroups legt die Newsgroups fest die dort gespeichert werden sollen, hier: alle (denkbar wäre auch eine Newsgroups-abhängige Aufteilung auf die Buffer).
class spezifiziert die Klasse (eine Zahl, die in der ganzen Datei eindeutig ist), sie wird hauptsächlich für expire.ctl benötig.
size legt die Größe der Artikel fest die in den jeweiligen Buffern gespeichert werden sollen, hier: im ersten Artikel mit einer Größe von 0 bis 3999 Bytes und im zweiten mit 4k-100k Größe. Für die Methode CNFS werden in den options SMALLAREA und BIGAREA übergeben. Sie stehen für die Namen der Metabuffer, den wiederum später in der cycbuff.conf (siehe unten) phisikalische Buffer zugewiesen werden. Für weitere Informationen siehe die Man Page von storage.conf(5).

cycbuff.conf

cycbuff.conf ist die eigentliche Konfigurationsdatei für CNFS. Hier werden die physikalischen Buffer definiert, die die Artikel speichern sollen und dann o.g. Metabuffern zugewiesen. Für unseren Beispiel werden hier 2 physikalische Buffer definiert: one und two.  Die Syntax der Zeile die den Buffer definiert lautet: 
cycbuff:buffer_name:file_name:buffer_size
Wobei:
buff_name der symbolischer Name (nicht größer als 7 Buchstaben) des Buffers ist
file_name der Dateinamen, unter dem der Buffer auf der Festplatte abgelegt ist und
buffer_size schliesslich die Größe des Buffers in kByte (* 1024) ist. Als nächstes werden die physikalische Buffer den Metabuffern zugewiesen die in der storage.conf festgelegt wurden. Die Syntax dieser Zeile lautet: 
metacycbuff:meta_cyclic_buffer_name:buffer_name[,buffer_name]
Wobei: meta_cyclic_buffer_name der Name des Metabuffers und
buffer_name schliesslich der symbolische Name des physikalischen Buffers. Hier können auch mehrere physikalische Buffer einem Metabuffer zugeordnet werden, in diesem Fall werden die Artikel beim speichern cyklisch gespeichert, das verbessert noch mal die Performance. So, die fertige Konfiguration für unser Beispiel sieht folgendermassen aus:

cycbuff.conf:

cycbuff:ONE:/var/spool/news/cycbuffs/one:102400
cycbuff:TWO:/var/spool/news/cycbuffs/two:102400
metacycbuff:SMALLAREA:ONE
metacycbuff:BIGAREA:TWO
Hier wurden zuerst die beiden Buffer ONE und TWO definiert und deren Größe festgelegt, dann den Metabuffern SMALLAREA und BIGAREA zugewiesen. Für weitere Informationen über die Möglichkeiten der Konfiguration siehe die Man Page von cycbuff.conf(5). Nach dem die Buffer konfiguriert wurden müssen sie noch auf der Festplatte erzeugt werden. Dazu gibt man in der Shell folgende Zeilen ein: 
dd if=/dev/zero of=/var/spool/news/cycbuffs/one bs=32k count=3200
dd if=/dev/zero of=/var/spool/news/cycbuffs/two bs=32k count=3200
Damit werden zwei 100MB große Dateien erzeugt. Die Größe der Dateien wird durch die Blockgröße (hier 32k) und der Anzahl der Blöcke bestimmt (hier 3200) was in unserem Beispiel 3200*32*1024 = 104857600 Bytes ergibt.

overview.ctl

Bei der Standard-Speichermethode wird die Übersichtsdatenbank overview extern von overchan(8) geschrieben. Wenn die storage api verwendet wird (wie das im Fall von CNFS ist), wird diese Datenbank direkt von INN beschrieben, die Indexdaten jedoch von overchan, aus dem Grund wird diese Datenbank unified overview ("vereinte Übersicht") genannt. Die overview.ctl definiert das Verhalten von INN beim Schreiben der Datenbank und in der Regel wird dort nur eine Zeile benötigt:

overview.ctl:

0:*
Weitere Informationen sind auf der Man Page von overview.ctl(5) zu finden.

newsfeeds

Da die Übersichtsdatenbank jetzt von direkt INN von geschrieben wird, muss overchan(8) so umkonfiguriert werden, daß es nur die Indexdaten schreibt. Dieser Schritt wird gerne vergessen ist aber dennoch sehr wichtig, denn erst danach kann auch ein Newsreader die geposteten Artikel sehen. Dazu ändert man die bereits vorhandene Zeile für overview in:

newsfeeds:

overview!:*:Tc,Ao,WhR,S30000:/usr/lib/news/bin/overchan
Auch hier gilt: weitere Infos zu den Optionen siehe Man Page von newsfeeds(5).

Änderungen im out.going Buffer

Mit der Umstellung auf CNFS ändert sich das Format der Buffer im out.going Verzeichnis. Wo früher die Pfade zu den jeweiligen Artikel zu finden waren (worüber man die Artikel direkt erreichen konnte), findet man jetzt ein Token mit einigen Zusatzinformationen (je nach Einstellung in der newsfeeds Datei). Um an den Inhalt des Artikels zu kommen, benutzt man ein Tools Names sm(8), zB: 
sm @03004F4E45000000000000006116000000010000D7B31D0097000000@
zeigt den Artikel in standard Ausgabe Kanal (stdout). Das ist die Stelle wo es die meisten Tools von Drittabietern schwer haben.

Wie geht es weiter ?

So, nun ist lokal alles eingerichtet. Jetzt kann INN wieder gestartet werden und man sollte dabei genau auf das Log-File achten, am besten man führt vorher auf einer anderen Console: tail -f /var/log/news aus.
Wenn alles ohne Fehler hochgelaufen ist, sollte man jetzt eigene Artikel posten und sie auch selbst lesen können.
Aber, womit kann man jetzt die Artikel spoolen ? Welches Tool kann mit CNFS umgehen ?
Hier bietet sich der Script Package für Suck und INN an. Weitere Infos siehe sp4si (erst ab Version 0.97). 

Anmerkung

Diese Anleitung erhebt keinen Anspruch auf Vollständigkeit und Benutzung auf eigene Gefahr !
Tips und Anregungen sind gerne wilkommen !