From: kai-martin knaak <k...@familieknaak.de>
Newsgroups: de.comm.provider.usenet
Subject: Newsserver im Debian-Stil?
Date: Mon, 21 Feb 2005 02:13:02 +0100
Lines: 159
Message-ID: <pan.2005.02.21.01.12.52.335900@familieknaak.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 5y7Vvz37/KJkIurdMMkSfwLSUX+u+5qvE0rAE7LIs3+TeZfuH8
User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))
Moin.
Die aktuelle Entwicklung bei individual könnte man als Aufforderung an
die User auffassen, sich mehr um die die Infrastruktur des Usenets zu
küern. Da bricht gerade eines der wichtigsten Standbeine in D weg
(Ich vermute, dass das Geschäftskonzept nicht lange tragen wird).
Hier ein paar Gedanken dazu, wie man dem Trauerspiel nicht passiv
zuschauen muss:
Der eigentliche Inhalt des Usenets wird wie die einzelnen Linux-Programme
von vielen individuellen Autoren verfasst und der Öffentlichkeit zur
Verfügung gestellt. Richtig nutzbar wird das Ganze aber erst, wenn
jemand die Dienstleistung erbringt, eine Sammlung zusammenzustellen und
die Daten zum User zu bringen. Bei Linux ist das die Distribution. Beim
Usenet übernimmt der Newsserver diese Funktion. Nun gibt es bei Linux
sowohl Distributoren mit kommerzieller Gewinnmaximierung (Suse, Redhat,
etc) als auch nicht-kommerzielle. Insbesondere ist Debian den
Gnu-Prinzipien verpflichtet und operiert so dezentral, frei und
unkommerziell, wie nur möglich. Ich will natürlich darauf hinaus,
dass man in Sachen Newsserver vielleicht von Debian lernen kann.
Mindestens ist es ein Beispiel, wie ein erheblich größeres Projekt
an offener Infrastruktur auf rein freier Basis erfolgreich funktionieren
kann. Das heißt schon viel, denn es zeigt, dass die Ressourcen da
wären, sich von der Abhängigkeit von individual/arcor/iund1/$ISP
zu befreien.
Idealerweise sollte ein Gnu-Newsservice das gleiche leisten, wie bisher
individual.de --- Freier Zugang für alle natürlichen Personen, eine
einigermaßen vollständige und aktuelle Abdeckung der Text-Gruppen,
Filterung von offensichtlichem Spam, Bearbeitung von Beschwerden und
Sperrung bei Missbrauch. Das Ganze natürlich mit hoher Datenrate,
minimaler Verzögerung und rund um die Uhr. (Hab ich was vergessen?)
Wie könnte ein Gnu-Newsservice betrieben werden?
Vorschlag 1) Wie den bisherigen Servern auch. Eine hinreichend schneller
Rechenkiste hängt an einer dicken Datenleitung. Ein Team von
Administratoren teilt sich die Arbeit, mit Zugangsdaten,
Programm-Konfiguration, Gruppen-Löschung usw. Einziger Unterschied zu
individual wäre, dass das Admin-Team so groß ist, dass sich für
jeden einzelnen die Arbeit auf ein kleineres Hobby reduziert. Es bleibt
die Finanzierung der Datenleitung und der eigentlichen Hardware. Das
düte pro User so gering ausfallen, dass es aus freiwilligen Abgaben
aufzubringen wäre. Der jeweilige Stand des Spendenbarometers könnte
als lokaler Thread regelmäßig in den Gruppen eingeschoben werden.
Falls dieser Appell an die Vernunft nicht ausreicht, könnte man für
positive Rückkopplung zwei Transfer-Raten einführen --- Wer gezahlt
hat, kommt auf die Überholspur. Die Zahlungen nimmt ein eingetragener
Verein entgegen, dessen Satzung entsprechend dem Gnu-Verständnis von
Freiheit ausgerichtet ist.
Aber ich denke, das man das Projekt am Debian-Beispiel orientieren
könnte:
Vorschlag 2) Dezentrale Server.
Die Last der vielen Lesezugriffe wird auf viele Mirrors verteilt, die
ihren Newsfeed von einem zentralen Feed-Knoten erhalten. Auch die
Zugangsdaten verwalten die Mirrors nicht selbst, sondern erhalten sie
regelmäßig von einem zentralen Zugangs-Server. Der Feed-Knoten
erhält die Info für die Gruppen, die er saugen soll, ebenfalls vom
Zugangs-Server. Auf diese Weise können die Mirrors und der Feed-Knoten
im wesentlichen unbeaufsichtigt ihren Dienst tun. Die Administation der
Groups und der User-Daten läuft für den Zugangs-Server und wird
wie beim ersten Vorschlag auf viele Schultern verteilt. Zur Lastverteilung
der Mirrors trägt der Feed-Knoten eine Hitliste der aktuell am
wenigsten belasteten Knoten in einer speziell dafür eingerichteten
newsgroup ein. Der Wechsel zum weniger belasteten Mirror kann dann
entweder händisch durch den User passieren, oder automagisch durch
einen entsprechend programmierten Newsreader.
Die technischen Anforderungen an den Server, der die Zugangsdaten und die
zu haltenden Gruppen verwaltet, sind minimal. Es müssen ja lediglich
die jeweiligen Änderungen ürmittelt werden. Auch der Aufwand beim
Knoten, der den Newsfeed vom Rest der Usenet-Welt entgegennimmt, sind
erheblich geringer als beim ersten Vorschlag, denn es müssen lediglich
die Mirrors bedient werden und nicht 100k User. Die Mirrors wiederum
bedienen jeweils nur einen Teil der User und werden so ebenfalls nicht
überlastet. Die Notwendigkeit einer besonders dicken Datenleitung
entfällt.
Im Grunde hätte man damit ein skalierbares Unternetz des Usenet
installiert, in dem an jedem Knoten die gleichen Gruppen zu sehen sind und
die gleichen Zugangsberechtigungen herrschen. Da die Anforderungen an die
einzelnen Mirrors vergleichsweise gering sind und sie keine
regelmäßige Administration brauchen, könnten sie ähnlich wie
öffentliche ftp-Server in freundlichen Uni-Rechenzentren unterkommen.
Damit ist zwar die Last verteilt, aber man ist immer noch von wohlgesonnen
Teilen der öffentlichen Hand abhängig und in Gefahr der
nächsten Sparwelle zum Opfer zu fallen. Vor allem muss das Netzwerk
der Mirrors überhaupt erst aufgebaut werden. Ob es da genügend
"wohlgesonene" Rechenzentren gibt?
Wenn man das konsequent weiter denkt, braucht man eine Möglichkeit, die
User-Rechner selbst als News-Verteiler einzusetzen. Seit ein wesentlicher
Anteil der privaten Usenet-Junkies für DSL verfügt, wären
dafür im Prinzip die Resourcen vorhanden:
Vorschlag 3) Dynamisch-dezentrale Mirrors. Die generelle Struktur ist
ähnlich wie beim zweiten Vorschlag, nur dass die Mirrors jeweils
für begrenzte Zeit auf User-Rechnern laufen. Als Nutzer hat man die
Wahl: Entweder man will nur normal das Usenet nutzen, dann bekommt man vom
Zugangsserver eine Liste von Mirror-Rechnern, die gerade aktiv sind. Oder
man entscheidet sich dafür selbst für einige Zeit und die
Mirror-Rolle einzunehmen. Natüich würde ein kompletter Newsfeed
die technischen Möglichkeiten bei weitem überschreiten. Aber wenn
sich die Mirror-Rolle auf die Gruppen beschränkt, die der Newsclient
aktuell subscribed hat, sollte es kein Problem. Ein netter Nebeneffekt
dieser Auswahl ist, dass stark bevölkerte Gruppen automatisch mehr
Mirror zugewiesen bekommen. Wenn für eine wenig besuchte Gruppe gerade
kein Mirror verfüar ist, dann werden Leseanforderungen eben direkt
vom Feed-knoten bedient, natürlich mit niedriger Priorität.
Die Zeit als Mirror muss gar nicht einmal so lang sein. Eine Stunde
wäre schon sinnvoll. Natürlich fällt in dieser Zeit für den
Mirror mehr Netzwerk-Verkehr an, als er bei einem reinen Lesebetrieb
hätte. Der Bereitsteller der Bandbreite hat dafür aber auch einen
Komfort-Vorteil: Er bekommt seine News mit der vollen
DSL-Download-Geschwindigkeit vom Feedknoten. Reine Leser müssen sich
mit einer anteiligen Upload-Geschwindigkeit der Mirrors begnügen. Auf
diese Weise haben alle Beteiligten einen Gewinn. Die Nur-Leser haben einen
kostenfreien News-Zugang und die Mirror-Betreiber haben einen
ultraschnellen Newsfeed (und können sich auf die Schultern klopfen,
weil sie etwas für die Gemeinschaft tun). Die Aufgaben des Feedknoten
und der Zugangsserver können natürlich nicht von zufälligen
User-Rechnern übernommen werden. Sie haben aber deutlich weniger zu
tun, als ein konventioneller Newsserver mit gleichem Leser-Volumen und ihr
Betrieb braucht entsprechend weniger Kleingeld (die Administration ist
ohnehin auf viele Schultern verteilt).
Der technische Charme dieser Lösung liegt darin, dass sie sich in
gewissem Rahmen selbst skaliert. Bei viel Lesenachfrage gibt es
automatisch mehr Mirrors. Wichtiger ist aber, dass der Usenet-Betrieb sich
aus sich heraus trägt. Auf die Dauer könnte es sogar die
Popularität steigern, weil so ein offener Zugang ohne Probleme als
Default in die Newsclients eingetragen werden kann. Damit entfällt
effektiv die leidige Schwelle mit der Suche nach einem Newsserver und
abschreckenden Erfahrungen mit Google&Co.
Der Nachteil der radikal-dezentralen Lösung ist natürlich, dass die
Software, für die Mirrors und den Zugangsserver erst noch geschrieben
werden muss. Das heißt, das wäre ein Projekt das einigen Vorlauf
braucht und man muss abwägen, ob der mögliche Gewinn in einem
vernünftigen Verhältnis zum Aufwand steht.
So. Genug Frust vom Leib geschrieben.
Bleiben die Gretchenfragen:
a) Gibt es zwingende Grüne gegen einen Gnu-News-Server?
b) Gibt es solche Projekte schon?
---<(kaimartin)>---