FAQ zu den "News in Dosen" v1.3 vom 8. April 1998 Tobias.Hennerich@swabsib.s.bawue.de Aenderungen seit der Version 1.2 vom 2. Maerz: - Inhaltsverzeichnis - innfeed wird vollstaendig unterstuetzt - Verschiedene neue Fragen: - Was sind die Unterschiede zu timehash und CNFS? - Was passiert mit den News in Dosen bei der naechsten INN-Version? - Ich moechte die overview-db neu erstellen, wie? - Was bedeutet nun eigentlich shelf.01/199805182202!0000019110 ? - Ich moechte kurz diesen einen bestimmten Artikel lesen... - Ich moechte inpaths einsetzen - Diverse andere Aenderungen an allen Ecken und Enden: - expire, news.daily, crontab, expireover Aenderungen seit der Version 1.1 vom 9. Februar: - innfeed wird mit einer ersten Beta unterstuetzt - Ausfuehrlichere Erlaeuterungen bzgl. crontab-Eintrag beim Thema Installation - Was muss ich tun, wenn ich ein anderes Dosen-Intervall haben moechte? INHALTSVERZEICHNIS Allgemeines - Was sind die "News in Dosen" ? - Was bringt dieses Verfahren? - Was sind die Nachteile dieses Verfahrens? - Was sind die Unterschiede zu timehash und CNFS? - Was passiert mit den News in Dosen bei der naechsten INN-Version? - Wo finde ich die News in Dosen? - Gibt es eine Mailingliste? - Gibt es eine Web-Page? - Auf was fuer Systemen laufen die News in Dosen? Internas - Wie funktioniert das System nun genauer? - Was passiert bei Crosspostings? - Was passiert bei Cancels? - Ok, die eigentlichen Artikel koennen nun sehr schnell und ohne viel - Wie werden genau diese Dosen angelegt? Installation - Die kurze Fassung - Die lange Fassung: - Compilieren - syslog.conf - crontab - overview.fmt - newsfeeds - /var/spool/news/articles Betrieb und Administration - Ich habe schon einen INN am laufen und moechte die Artikel - Ich moechte die Expire-Zeiten auf meinem System aendern. - Was macht dann eigentlich noch der Expire? - Wie funktioniert der expireover? - Ich moechte die overview-db neu erstellen, wie? - Ich moechte eine zusaetzliche Partition fuer Newsspool verwenden. - Ich moechte mehrere Filesysteme auf eine Partition zusammenlegen? - Die verschiedenen Regale werden nicht gleichmaessig mit Dosen belegt, warum? - Ich moechte ein anderes Expire-Intervall als 4 Stunden haben. - Ich bekomme nach einem unsauberen Shutdown des innd folgende Meldung - Was bedeutet nun eigentlich shelf.01/199805182202!0000019110 ? - Ich moechte kurz diesen einen bestimmten Artikel lesen... - Ich moechte inpaths einsetzen Sonstiges - Ich moechte noch mehr ueber die Internas der News in Dosen - Ich habe Probleme bzw. weitere Fragen. Wer kann mir helfen? - Ich habe noch eine andere Frage. Warum steht das nicht hier - Sonst noch was? ALLGEMEINES Frage: Was sind die "News In Dosen" ? Die News in Dosen sind eine modifizierte Version des Usenet-News Newsservers INN, bei welcher Newsartikel nicht mehr als einzelne Dateien abgespeichert, sondern stattdessen in grossen Files zusammengefasst werden. Alle Newsartikel in einem solchen File werden gleichzeitig zu einem bestimmten Zeitpunkt wieder geloescht, was man der Datei schon am Filenamen ansieht. Man kann also sagen, dass jede Datei ein Verfallsdatum hat, so wie auch Konservendosen. Daher der Name des ganzen Systems. Frage: Was bringt dieses Verfahren? - Nachdem nicht mehr dauernd neue Dateien angelegt werden muessen, koennen Artikel sehr schnell und in grossen Buendeln auf den Festplatten abgelegt werden. Der Geschwindigkeitsvorteil liegt auf diversen Test-Systemen im Bereich zwischen Faktor 5 und Faktor 10. Es wurde von Installationen berichtet mit Einsortiergeschwindigkeiten von ueber 200 Artikel pro Sekunde. Auch 486er mit ISA-Platte schaffen noch ohne weiteres Tuning >30 Artikel pro Sekunde, mit einem inn-1.7.2-insync waren es nur halb so viel. - Da die Artikel alle in einer Datei gesammelt werden, faellt kein Verschnitt auf der Festplatte an, wodurch der Platzbedarf fuer die Artikel sinkt. - Der Expire ist nicht mehr eine Sache von Stunden, sondern erfordert nur das Loeschen einer einzigen Datei, bzw. (bei sehr vielen News) sehr weniger grossen Dateien. - Da der Expire sehr schnell erledigt ist, koennen mehrmals am Tag immer wieder Artikel geloescht werden und dadurch eine gleichmaessigere Auslastung der Festplatten erzielt werden. - Trotzdem hat man weiterhin das uebliche Expireverhalten wie bei herkoemmlichen Newssystemen, d.h. die am Montag geposteten Artikel bleiben gleich lange auf dem System wie die am Freitag geposteten, bei Administrationsproblemen bleibt das System stehen und faengt nicht an alles wahllos wegzuloeschen, Artikel mit Expire:-Header werden beruecksichtigt. - Als Abfallprodukt entstand auch ein neuer overchan, der sehr viel schneller als die bisherigen Versionen arbeitet. Frage: Was sind die Nachteile dieses Verfahrens? - Programme auf dem Newsserver, die direkt auf die Newsartikel zugreifen und davon ausgehen, dass jeder Artikel in einer eigenen Datei liegt, funktionieren nicht mehr. Die wichtigsten Programme der normalen INN-Distribution wie innxmit, batcher, nnrpd, alle control-Scripte usw. und natuerlich der innd selbst sind an das neue System angepasst. In der Zwischenzeit existiert auch eine angepasste Version des des beliebten Feeders innfeed. Wer andere Sachen zum Laufen bekommen will, muss diese erst modifizieren. Es existiert dazu allerdings eine Library und ein kleines Tool, um Artikel einfach lesen zu koennen. So mussten z.B. beim Backend innxmit von ueber 1600 Zeilen nur 38 Zeilen angepasst bzw. ergaenzt werden, von denen die Aenderung bei den meissten aus einem Ersetzen der Buchstabenkombination "qio" in "qci" lautete. Beim innfeed mussten von 18000 Zeilen weniger als 50 modifiziert werden. - Eine rasche Aenderung des Expires zur Behebung von akutem Fest- plattenmangel ist (noch) nicht moeglich bzw. hat erst nach mehreren Tagen eine Auswirkung. Man kann aber natuerlich eine noch gar nicht zum Loeschen vorgesehene Dose (Datei) vorzeitig freigeben und sich dadurch kurzfristig Luft verschaffen. - Die Dokumentation ist noch nicht angepasst. Alle Aenderungen gegenueber der normalen INN-Version sind entweder hier beschrieben oder aber in der Ausarbeitung zu der Studienarbeit, auf der dieses Projekt beruht. - Sehr grosse Newssysteme im Master-Slave-Modus, welche sich Newsartikel im Zweifelsfall per NFS von einer anderen Platte holen, werden noch nicht unterstuetzt. Dies liegt nicht am nicht funktionierenden Master-Slave-Modus, sondern daran, dass man nicht so einfach direkt auf einen Artikel auf einer anderen Maschine zugreifen kann - es sei denn man macht dies ueber NNTP. - Dieses README existiert aus Zeitmangel bisher nur in einer deutschen Version. Frage: Was sind die Unterschiede zu timehash und CNFS? Timehash speichert alle Artikel nach einem Hashing-Algorithmus (basierend auf dem Zeitpunkt wann die Artikel angekommen sind bzw. wann sie gepostet wurden) in einzelne Files. Der Vorteil von NiD, dass weniger Dateizugriffe notwendig sind, ist bei timehash nicht gegeben. Eigentlich verringert timehash nur die Probleme von sehr grossen Newsgruppen wie misc.jobs.offered und control, in denen mehrere 10000 - 100000 Artikel gleichzeitig vorkommen koennen. Dies ist allerdings fuer NiD auch kein Problem. CNFS arbeitet wie die NiD mit grossen Dateien in welche die einzelnen Artikel einfach hintereinander geschrieben werden, aber das bei NiD erhaltene expire-Konzept ist mit CNFS nicht mehr moeglich: Wenn ein neuer Artikel reinkommt, wird ein alter Artikel zwangsweise geloescht (bzw. wenn ein sehr grosser Artikel reinkommt u.U. auch viele alte kleine). Expire-Header koennen gar nicht beruecksichtigt werden. Das Dateiformat ist (anders als bei NiD) nicht einfach mit Shellscripts usw. bearbeitbar. Man kann auch nicht im laufenden Betrieb neue Platten hinzunehmen. Frage: Was passiert mit den News in Dosen bei der naechsten INN-Version? Was wohl? Die NiD werden natuerlich angepasst. Nachdem die naechste INN-Version ein Storage-Konzept haben wird, welches es ermoeglicht verschiedene Artikelspeichermethoden gleichzeitig zu verwenden, sollte dies sogar eleganter moeglich sein, als es bei der derzeitigen Codebasis teilweise moeglich war. Frage: Wo finde ich die News in Dosen? Die News in Dosen sind unter folgender URL erreichbar: ftp://ftp.uni-stuttgart.de/pub/unix/comm/news/nid/inn-nid.tar.gz Das File inn-nid.tar.gz ist ein Link, welcher immer auf die aktuellste Version der News in Dosen zeigt. Aeltere Versionen werden trotzdem noch vorhanden sein. Im selben Verzeichnis werden auch andere Dinge wie diese FAQ abgelegt werden. Frage: Gibt es eine Mailingliste? Ja, sie ist auch an der Uni-Stuttgart eingerichtet. Man schicke eine Mail an majordomo@listserv.uni-stuttgart.de mit folgender Zeile im Body: subscribe nid Der Rest passiert automatisch. Wer mehr wissen will, kann auch "help" als Nachricht im Body schicken und bekommt dann etwas mehr Informationen. Mails an die Liste schickt man dann an die Adresse nid@listserv.uni-stuttgart.de Man beachte bitte, dass der Listserver nicht automatisch ein Reply-To: setzt, man auf die Mails also per Group-Reply antworten sollte, damit die anderen Teilnehmer der Liste Antworten auch lesen koennen. Frage: Gibt es eine Web-Page? Leider nein. Bis dato hatte ich keine Zeit um auch noch in sowas meine Zeit zu stecken. Wer will kann gerne ein paar Webpages machen und sie mir schicken, ich werde sie dann auch kurzfristig auf dem Web-Server der Uni-Stuttgart unterbringen koennen. Frage: Auf was fuer Systemen laufen die News in Dosen? Entwickelt und getestet wurden sie von mir selbst unter NeXTSTEP, FreeBSD und Solaris 2.6. Das System ist auch auf mehreren Linux- Maschinen im Einsatz. Allgemein kann gesagt werden, dass die News in Dosen kaum von besonderen Features einzelner Unix-Versionen abhaengen und deswegen mit kleineren Aenderungen ueberall laufen sollten, wo auch ein normaler INN funktioniert. Frage: Wie funktioniert das System nun genauer? Die einzelnen Punkte sind wie folgt: - Der innd liest beim Start die Datei expire.ctl ein und merkt sich zu jeder Newsgruppe des Active-Files wie lange diese Newsgruppe auf dem System gehalten werden soll. - Wenn nun Newsartikel angeliefert werden, wird zum aktuellen Datum die Haltedauer hinzuaddiert ("Expire:"-Header werden entsprechend den Einstellungen im expire.ctl beruecksichtigt) und der Artikel am Ende der berechneten Dose angehaengt. Um nicht dauernd verschiedene Dosen oeffnen und schliessen zu muessen, haelt der innd eine Reihe von Dosen gleichzeitig offen. - Im history-File wird vermerkt, dass der Artikel mit der Msg-ID x sich in der Dose y an Position z befindet. Ausserdem bekommt die Overview-Database einen zusaetzlichen Eintrag pro Artikel, in welchem steht, dass der Artikel 12345 der Newsgruppe a.b.c sich auch in der dose y an Position z steht. In den out.going-Files fuer die diversen Feeds steht nicht mehr Msg-ID x, a.b.c/12345 unsondern eben Msg-ID x, y!z. - Der innd greift nun (wie bisher) ueber die history auf die Newsartikel zu. Der nnrpd fuer die Newsreader ueber die overview- Database. Die Backends innxmit und batcher ueber die Referenzen in den out.going-Files. Frage: Was passiert bei Crosspostings? Newsartikel die in mehreren Newsgruppen gleichzeitig gepostet werden, speichert der innd weiterhin nur einmal ab. Und zwar laut der Newsgruppe, die am laengsten auf dem System gehalten wird in der am spaetesten zu loeschenden Dose. Es spielt also keine Rolle, ob der Newsspool ueber mehrere Platten verteilt ist oder nicht, man hat auch keine Probleme mit symbolic-Links usw. Natuerlich wird in der Overview-Database fuer jede Newsgruppe ein eigener Eintrag erzeugt, so dass man von allen Newsgruppen auf den Artikel zugreifen kann. Frage: Was passiert bei Cancels? Nachdem es sehr schwierig ist Newsartikel in der Mitte von 100MB-Dateien wieder zu entfernen, werden gecancelte Artikel nur als geloescht markiert und an Reader nicht mehr weitergegeben, nicht aber tatsaechlich aus dem Newsspool geloescht. Es waere relativ einfach moeglich sich den Umstand zunutze zu machen, dass man bei Unix-Filesystemen in Dateien "Loechern" erzeugen kann, die keinen Speicherplatz benoetigen. Dazu muesste man dann einmal am Tag die Dosen umkopieren und alle Artikel durch Loecher ersetzen. Dies ist aber noch nicht implementiert. Frage: Ok, die eigentlichen Artikel koennen nun sehr schnell und ohne viel Plattenkopf-Bewegungen gespeichert werden. Was nuetzt dies denn noch, wenn der overchan weiterhin pro Newsartikel (bei Crosspostings sogar noch oefters) eine Datei beschreiben muss, und deswegen weiterhin sehr viele Plattenkopfbewegungen noetig sind? Das hat zwar nichts direkt mit dem Konzept "News in Dosen" zu tun, aber dieses Problem wurde zumindest etwas entschaerft: Der overchan wurde mit einem Puffer ausgestattet, so dass er nicht mehr sofort die einzelnen Overview-Zeilen an die Dateien anhaengt, sondern erst einmal nur Daten sammelt. Nach - einem Timeout, oder aber - nach einer bestimmten Menge an Daten, oder aber - wenn der overchan der Meinung ist, dass da ein lokal geposteter Newsartikel einzutragen ist (Msg-ID=lokale Maschine) faengt er dann an die Overview-Database zu akualisieren. Wenn nun innerhalb des Pufferzeitraumes mehrere Artikel fuer die selbe Newsgruppe angekommen sind, kann der overchan diese Artikelinfos in einem open()/close()-Aufruf gleichzeitig rausschreiben und benoetigt dadurch sehr viel weniger Plattenzugriffe. Je nach Anzahl der auf dem System vorhandenen Newsgruppen und Tempo, in welchem die Artikel angeliefert werden, sind dadurch Einsparungen von ueber deutlich ueber 50% der Filezugriffe moeglich. Frage: Wie werden genau diese Dosen angelegt? Der innd schaut beim Speichern eines Artikels erst einmal nach, ob es schon eine Dose fuer diesen Zeitraum gibt. Wenn dem nicht so ist oder aber die vorhandene Dose eine bestimmte Groesse ueberschreitet (z.B. 100MB), wird eine neue Dosen angelegt: Dosen gehoeren auf ein Regal. Deswegen sucht der INN in dem Verzeichnis, das normalerweise die Verzeichnisse alt, comp, de, rec, misc usw. beinhaltet, nach Verzeichnissen, die mit "shelf." beginnen. Von denen wird das genommen, in welchem noch am meissten Platz ist, d.h. eine Verteilung auf verschiedene Festplatten ist entsprechend einfach moeglich. INSTALLATION Frage: Was muss ich beim Installieren der News in Dosen beachten? Diese FAQ kann nicht auf die allgemeine Installation von INN eingehen. Sie ist ist und bleibt umfangreich und ist nichts fuer Administratoren, die vorher noch keine andere Software installiert haben. Man schaue sich bitte im Zweifelsfall die allgemeinen INN-FAQs an, die auch bei den News in Dosen mit dabei sind. Die kurze Fassung der zu beachtenden Dinge bei der Installation sind folgende: - saugen, auspacken, "make" und "make install" wie bisher - Auf Systemebene ggf. syslog.conf und crontab anpassen - Auf INN-Ebene newsfeeds und overview.fmt anpassen sowie die Regale anlegen Die lange Fassung: Bzgl. compilieren: - Man hole sich die Sourcen und entpacke sie. - Parameter bzgl. der News In Dosen sind bis dato noch nicht im config.data eingetragen, sondern muessen in der Datei include/can.h geaendert werden. In aller Regel sind die voreingestellten Werte aber brauchbar. Es gibt leider keine einheitliche Methode rauszubekommen wieviel Plattenplatz auf einer Festplatte noch uebrig ist. R$ hat das Problem dadurch geloest, dass er es dem User ueberlaesst das Kommando df selbst anzuschauen und dann den innwatch anzupassen. Dies ist in meinem Fall leider keine grosse Hilfe. Man muss deswegen je nach OS nachschauen, wie man den Plattenplatz bestimmen kann und dann das #define STATFS in canwrite.c anpassen. Bei Solaris heisst es z.B. #define STATFS statvfs. Je nachdem muessen auch unterschiedliche #includes noch eingetragen werden. Beispiel Solaris: In der Manpage steht folgendes: --- schnipp --- statvfs(2) System Calls statvfs(2) NAME statvfs, fstatvfs - get file system information SYNOPSIS #include #include int statvfs(const char *path, struct statvfs *buf); int fstatvfs(int fildes, struct statvfs *buf); DESCRIPTION statvfs() returns a "generic superblock" describing a file system; it can be used to acquire information about mounted file systems. buf is a pointer to a structure (described below) that is filled by the function. --- schnapp --- -> in canwrite.c muessen noch die Zeilen #include und #include eingetragen werden. - Man compiliere den INN wie ueblich, konfiguriere alle Dateien in $INN/site und tippe "make install" Bzgl. konfigurieren: - Wer sich anschauen moechte, wie auf die Dosen zugegriffen wird, der kann sich die Debug-Funktionalitaet des INN zunutze machen und einen zusaetzlichen Eintrag in /etc/syslog.conf eintragen (man beachte, dass der syslog pingelig bzgl. Tabs ist. Beim Cut & Paste dieser Zeilen hier also bitte aufpassen): news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice /var/log/news/news.notice neu -> news.debug /var/log/news/news.debug Diese debug-File wird allerdings vom news.daily nicht beruecksichtigt, waechst also immer weiter an. Im Zweifeslfall von Hand kuerzen oder aber im syslog wieder abschalten. - Der crontab-Eintrag fuer news.daily sieht etwas anders aus. Da der expire so schnell ist, wird zur gleichmaessigeren Plattenausnutzung alle 4 Stunden ein expire durchgefuehrt. Einmal pro Nacht muss zusaetzlich die overview-Database und alle Logfiles gekuerzt werden. Dementsprechend sieht der crontab-Eintrag nun wie folgt aus: 5 2 * * * news /usr/local/news/bin/news.daily expireover 5 6,10,14,18,22 * * * news /usr/local/news/bin/news.daily notdaily nomail Bei diesem crontab-Eintrag sind folgende Dinge zu beachten: Nachdem die overview-Database nur einmal pro Nacht verkleinert wird, muss der nnrpd bei normalen Newslesern aufpassen, dass er keine Newsartikel zum lesen anbietet, die in der Zwischenzeit schon expired sind. Dies passiert (aus Performancegruenden) dadurch, dass der nnrpd beim lesen der overview-Database alle Eintraege ignoriert, die laut Dosenname schon expired sein muessten. Es bringt also nichts seltener zu expiren, man kann deswegen die Newsartikel nicht laenger lesen (aber man kann dadurch laenger Artikel an seine Peers verschicken). Wer tatsaechlich ein groesseres expire-Intervall haben moechte, muss eine Aenderung machen, die weiter unten erklaert ist. Die komische Uhrzeit von 2, 6, 10, 14, 18 und 22 Uhr entsteht dadurch, dass das System intern in GMT-Zeit arbeitet und deswegen in Deutschland Dosen um eine bzw. bei Sommerzeit um 2 Stunden zu Mitternacht versetzt erzeugt werden. Man beachte bitte, dass der expire kurz *nach* und nicht *vor* 2 Uhr bzw. 10, 18 Uhr gestartet werden sollte, weil um z.B. 1:55 noch nicht die Files von 2:00 Uhr zu loeschen sind. Die Option "notdaily" von news.daily wurde so modifiziert, dass tagsueber alles moeglichst schnell erledigt wird. So wird auf alle Faelle kein renumber durchgefuehrt und der expire baut das history- File nicht neu auf. - Die overview-db wird zwingend benoetigt um mit Newsclients auf Artikel in den verschiedenen Newsgruppen zugreifen zu koennen. Deswegen muss auf Newssystemen die nicht reine Verteilermaschinen sind auch zwingend das Programm overchan laufen. Die Konfigurationsdatei overview.fmt braucht zwingend am Ende den folgenden Eintrag: Xcanpos:full Siehe dazu auch die Datei newsfeeds. - In der Datei newsfeeds muessen zwei Dinge beachtet werden: * Der overchan muss immer eingetragen werden (ausser bei reinen Newsverteilersystemen), z.B. mittels eines Eintrages wie folgt: overview!:*:Tc,WO:/usr/news/bin/overchan * Die Eintraege fuer das Referenzieren auf Artikel per f bzw. n geht zwar noch, die Backends innxmit und batcher koennen damit aber nichts mehr anfangen. Stattdessen muss immer per "c" (fuer canpos) auf die Artikel gezeigt werden. Ein nntp-feed wird also mittels innxmit wie folgt versorgt: # Feed all local non-internal postings to nearnet; sent off-line via # nntpsend or send-nntp. nic.near.net\ :!junk/!foo\ :Tf,Wcm:nic.near.net ^ wichtig! hier ein "c"! Ein feed mit uucp-batches dagegen z.B. so: # A UUCP feed, where we try to keep the "batching" between 4 and 1K. ihnp4\ :!junk,!control/!foo\ :Tf,Wcb,B4096/1024: ^ wichtig! hier ein "c"! Beim innfeed muss folgendes eingetragen werden: innfeed!:!*\ :Tc,Wcm*:/usr/news/local/startinnfeed ^ ^ | wichtig! hier ein "c" ! | dieses c hier steht fuer channel und hat nichts mit den NiD zu tun (gehoert aber trotzdem dort hin) - Im Verzeichnis in welchen die eigentlichen Newsartikel abgelegt werden (heute oft /var/spool/news/articles) benoetigt man nun noch fuer die Dosen die Regale. Regale sind Directories in denen dann die Dosen angelegt werden, pro Filesystem ein Directory. Es ist dabei egal, ob die verschiedenen Festplatten per symbolic-Link, per mount oder als tatsaechliches Directory angelegt werden, hauptsache der Name beginnt mit "shelf." und einer beliebigen Folge von Buchstaben. Eine moegliche Notation waere also shelf.01 shelf.02 shelf.03 oder aber auch shelf.seagate shelf.seagatenicht shelf.quantum Wenn auf einer Festplatte mehrere Shelfs angelegt werden, schreibt der INN immer nur in das erste Directory auf dieser Platte (dies ist bis dato ein Feature und kein Bug). Dies sind alle notwendigen Aenderungen fuer das System! Frage: Ich habe schon einen INN am laufen und moechte die Artikel uebernehmen! Das ist schwierig, da das Konzept ein voellig anderes ist als bisher. Es gibt folgende Moeglichkeiten zumindest einen Teil der Newsartikel auf das neue System hinueber zu retten: - Man loescht alle Artikel und faengt von vorne an (ok, damit hat man nichts gerettet, aber so habe ich es mehrmals gemacht 8-). - Man halbiere die Einstellungen in expire.ctl und laesst sich die Haelfte der Platte leerraeumen. Danach installiere man den neuen innd (behalte aber vom alten INN noch das binary vom batcher), lege mit makehistory ein neues history-file an und spiele mit einem kleinen Script die Newsartikel wieder neu ein. Dies geht z.B. so: cd /var/spool/news/articles.old find . -type f -print | batcher.old -b1000000 test -p "rnews" Bei dieser Methode bekommt man tausende Artikel gemeldet, die das System anscheinend nicht annehmen will. Dies liegt daran, dass Crosspostings, die sich im selben Filesystem befinden, mehrmals dem innd angeboten werden und nur beim ersten Mal angenommen werden. Der Nachteil dieses Verfahrens ist, dass die Newsreader die gleichen Artikel zweimal unter unterschiedlichen Artikel-Nummern angeboten bekommen und dass das System mehrere Stunden down ist. - Man besorge sich eine neue Maschine, installiert dort die News in Dosen und lasse die alte und neue Maschine im Master-Slave-Modus laufen. Nach einer Weile ist das neue System dann auf aehnlichem Stand wie das alte und dann kann man switchen. Dieses Verfahren habe ich schon gemacht und das funktioniert prima. - Man besorge sich keine neue Maschine, installiert die News in Dosen auf dem aktuellen Newsserver in einem neuen Directory und mit anderen Syslog-Eintraegen, starte den neuen innd unter einer anderen Portnummer und lasse den neuen und alten innd wieder im Master/Slave-Modus eine Weile parallel laufen. Dies benoetigt entsprechend Plattenplatz bzw. einen kurzen Expire, ermoeglicht dann aber spaeter den transparenten Switch auf die neue Version. Dieses Verfahren habe ich selbst noch nicht verwendet, aber ich kenne jemanden, der das so gemacht hat. BETRIEB UND ADMINISTRATION Frage: Ich moechte die Expire-Zeiten auf meinem System aendern. Nachdem schon beim Start des innd die Datei expire.ctl ausgelesen wird, muss nach einer Aenderung der innd zu einem erneuten Lesen der veraenderten Daten gebracht werden. Dies passiert am einfachsten mit einem 'ctlinnd reload active "neue expire-Zeiten"'. Frage: Was macht dann eigentlich noch der Expire? Der Expire geht (wie bisher auch) das history-File durch und entscheidet, ob die einzelnen Artikel geloescht gehoeren oder auch nicht. Dies erkennt er einfach an den Dosennamen, die ja den Expirezeitpunkt benennen. Das Loeschen von Message-IDs funktioniert wie bisher auch am Datum, wann ein Newsartikel angekommen ist. Deswegen benoetigt der expire weiterhin Zugriff auf die expire.ctl-Datei, damit er dort die remember-Zeile auslesen kann. Am Ende durchlaeuft er zusaetzlich noch alle Regale und loescht dort die entsprechenden Dosen. Beim Start von expire mit der Option -x wurde frueher zwar die history nicht neu aufgebaut, trotzdem aber die Datei durchgescannt um alle zu loeschenden Artikel zu finden. Dies ist bei den NiD unnoetig, deswegen kann das Scannen entfallen und ein expire -x dauert nur wenige Sekunden. Frage: Wie funktioniert der expireover? Nachdem er expire nur mit sehr hohem Aufwand eine Liste von zu loeschenden Artikel erstellen kann, geht der expireover durch alle overview-Files und loescht dort die Eintraege heraus, die wieder (laut Dosenname) geloescht werden muessen. Da dies weiterhin eine etwas umfangreiche Aufgabe ist, wird dies nur einmal pro Nacht (wenn man will und Plattenplatz hat auch noch seltener) gemacht. Der nnrpd erkennst selbst, ob er bestimmte Artikel noch zum Lesen anbieten kann, oder ob diese auch schon expired sein muessten. Falls die overview-db korrupt werden sollte (z.B. weil eine Festplatte mit einem Regal ausgefallen ist), kann mit der neuen Option "expireover -c" explizit nachgeschaut werden, ob die jeweiligen Artikel tatsaechlich noch in den Dosen vorhanden sind. Dadurch werden sowohl gecancelte Artikel als auch auch vorzeitig geloeschte Dosen entdeckt und entfernt. Diese Option ist dem notwendigen Aufwand entsprechend langsam und sollte nur fuer recovery-Zwecke verwendet werden. Frage: Ich moechte die overview-db neu erstellen, wie? Die alte Option expireover -a gibt es nicht mehr. Stattdessen existiert ein neues Tool "makeoverview", welches in allen Dosen die Artikel durchscannt und einen identischen Output wie der innd liefert. Man kann also per "makeoverview | overchan" eine neue overview-DB erstellen. Diese overview-DB ist allerdings eventuell unsortiert und man sollte danach einen "expireover -s" darueber laufen lassen, der die .overview-Dateien sortiert. Der nnrpd wurde allerdings so modifziert, dass er auch mit unsortierten .overview-Dateien zurecht kommt. D.h. falls der innd mal ein overview!-Batch nach out.going schreibt, kann dieser per "cat overview! | overchan" noch nachtraeglich in die overview-db eingepflegt werden. Frage: Ich moechte eine zusaetzliche Partition fuer Newsspool verwenden. Dort wo schon ein (oder mehrere) shelf.xx-Directories angelegt sind einfach die neue Platte mounten oder aber per symbolic Link auf ein Verzeichnis der Platte zeigen. Dieser Link bzw. der Mount muss (s.o.) mit "shelf." beginnen. Sobald der innd das naechste Mal eine neue Dose anlegen muss (weil sie noch fehlt oder aber weil die aktuelle Dose fuer einen bestimmten Zeitraum schon voll ist) wird wieder nachgeschaut was es fuer Regale gibt und davon das mit dem meissten freien Plattenplatz genommen. Dies kann also "on the fly" gemacht werden, ein Neustart des innd ist nicht noetig. Frage: Ich moechte mehrere Filesysteme auf eine Partition zusammenlegen? Dazu muss der innd runtergefahren werden und dann die einzelnen Regale auf eine Platte zusammengeschoben werden, wobei die Dosen weiterhin in ihren urspruenglichen Directories bleiben! Danach kann der innd neu gestartet werden. Ab sofort werden immer alle Shelfs auf dieser Platte genau gleich viel Plattenplatz frei haben, so dass der innd beim Anlegen neuer Dosen immer das erste Regal benutzt. Mit der Zeit leeren sich die anderen Regale durch den Expire, so dass man nach einiger Zeit die dann leeren Regale loeschen kann. Frage: Die verschiedenen Regale werden nicht gleichmaessig mit Dosen belegt, warum? Der innd versucht nicht die Regale gleichmaessig zu fuellen, sondern er versucht auf den Regalen gleichmaessig viel Platz frei zu lassen. Wenn man relativ kleine Regale hat (nur ein paar hundert MB gross), oder man kurzfristig wegen akutem Platzmangel ein zusaetzliches Regal in Betrieb genommen hat, dann kann es sein, dass die maximale Dosengroesse mit 100MB viel zu gross ist, als dass schnell genug auf dem neuen Regal neue Dosen angelegt werden. In diesem Fall kann die maximale Dosengroesse in der Datei $INN/include/can.h ganz oben wie folgt abgeaendert werden: Vorher: #define MAXCANSIZE (100*1024*1024) /* max 100MB pro can */ Nachher: #define MAXCANSIZE (30*1024*1024) /* max 30MB pro can */ Dadurch werden nun alle 30MB eine neue Dose angelegt und neu ankommende Artikel viel schneller auf die verschiedenen Regale verteilt. Allerdings bedeuten kleinere Dosen auch mehr Dateien und damit etwas mehr Systemlast beim nun oefters auftretenden Oeffnen und Schliessen von Dateien. Frage: Ich moechte ein anderes Expire-Intervall als 4 Stunden haben. Was muss ich tun? In der Datei $INN/includes/can.h folgendes #define anpassen: #define CANTIME ((time_t)(60*60*4)) /* alle 4 Stunden eine can */ zu z.B #define CANTIME ((time_t)(60*60*8)) /* alle 8 Stunden eine can */ Nun kann der crontab auf ein entsprechend laengeres Intervall gesetzt werden: 5 2 * * * news /usr/local/news/bin/news.daily expireover 5 10,18 * * * news /usr/local/news/bin/news.daily notdaily nomail Man beachte auch die anderen Bemerkungen, die bzgl. crontab beim Punkt "Installation" aufgelistet sind. Frage: Ich bekomme nach einem unsauberen Shutdown des innd folgende Meldung: innd: found shelf.01/199712032101, delete=881179200 (61193.00) innd: truncated can at bytepos 51284764 of 51284764, recovered 50 articles innd: SERVER check history for entries of can shelf.01/199712070501! Die kurze Fassung: Solange da eine Meldung steht mit zweimal der selben bytepos (so wie hier im Beispiel) ist (fast) alles in Ordnung und die Meldung kann ignoriert werden. Die lange Fassung: Dies bedeutet, dass der innd beim Startup und Zusammensuchen der Dosen festgestellt hat, dass die Dateilaenge, die im Header einer jeden Dosen angegeben wurde nicht mit der tatsaechlichen Filelaenge der Dose uebereinstimmt (die im Header befindliche Laenge der Dose wird beim Schliessen der Dose bzw. alle paar Minuten aktualisiert). Der innd muss also davon ausgehen, dass dem System mitten im Abspeichern eines Artikels der Strom ausgegangen ist und deswegen der letzte Artikel nur unvollstaendig in der Dose abgespeichert wurde. Er versucht also ab der zuletzt gesicherten Laenge der Dose (das was im Header steht) die Artikel einzulesen und schneidet den letzten unvollstaendigen im Zweifelsfall ab. Nachdem hier also die Meldung kam, dass er erst nach dem letzten Byte getruncated hat (also gar nichts abgeschnitten hat) ist alles in Ordnung. Dies aendert nichts daran, dass der overchan hoechstwahrscheinlich genauso unsauber heruntergefahren wurde, was alles andere als in Ordnung sein duerfte: Nachdem der overchan bis zu 60 Sekunden Artikel im Speicher puffert und dann erst rausschreibt, sind diese Artikel nicht in der overview-Database gespeichert worden. Nachdem aber die overview-Database fuer die nnrpd die einzige Zugangsmoeglichkeit zum Lesen von Artikel ist, sind diese Artikel fuer Newsreader unerreichbar. Konsequenz: In den shutdown-Scripts des Rechners entsprechende Aufrufe fuer einen sauberen shutdown des innd einfuegen, bzw. den innd vorher per 'ctlinnd shutdown "reason why"' runter fahren. Frage: Was bedeutet nun eigentlich shelf.01/199805182202!0000019110 ? Dies ist die sog. canpos, d.h. die Position an der sich ein bestimmter Artikel befindet. In diesem Fall liegt der Artikel an Byteposition 19110 in der Dose mit dem Dateinamen 199805182202, welche die zweite Dose ist von denen, die am 18.5.1998 um 22:00 Uhr expiren werden. Diese Dose befindet sich auf dem Regal shelf.01. Frage: Ich moechte kurz diesen einen bestimmten Artikel lesen... Kein Problem, dafuer gibt es das neue Kommando ccat: Einfach als Parameter die canpos angeben und man bekommt den Artikel auf stdout geliefert. Bei modernen Shells kann es sein, dass das ! ein Problem darstellt. In diesem Fall dann entweder "ccat shelf.01/199805182202\!0000019110" tippen, oder aber vorher kurz per Kommando "sh" in die Bourne-Shell wechseln. Frage: Ich moechte inpaths einsetzen Es gibt ein neues Kommando nidhdr, welches u.a. dafuer geschrieben wurde: nidhdr durchsucht alle Artikel aller Dosen nach einem beliebigen Header und liefert das Resultat auf stdout. Man kann also per "nidhdr Path | inpaths -p news.domain.de" die Statistik on the fly erstellen, was sehr schnell geht: Auf entsprechender Hardware 1500 Artikel pro Sekunde und mehr. Wer nicht weiss, was inpaths ist: http://www.freenix.fr/top1000/ Frage: Ich moechte noch mehr ueber die Internas der News in Dosen wissen. Man besorge sich die Studienarbeit auf der ftp.uni-stuttgart.de und lese dort nach, was zumindest im August 1997 noch aktuell war. Danach schaue man in den Sourcecode. Wenn auch dies nichts hilft, lese man die naechste Frage in dieser FAQ. Frage: Ich habe Probleme bzw. weitere Fragen. Wer kann mir helfen? Als allererstes bitte ueberpruefen, ob die Probleme ueberhaupt etwas mit den News in Dosen zu tun haben. Ich habe das Programm nun auf verschiedenen Systemen teilweise seit Monaten im Einsatz und dort funktioniert es relativ problemlos. Sobald es aber Probleme gab, wurden natuerlich immer zuerst die News in Dosen verdaechtigt - auch wenn im Nachhinein dann Hitzeprobleme, Inkompatibilitaeten zwischen SCSI-Controller und SCSI-Platten, Konfigurationsfehler des INN im allgemeinen oder auch einfach nur der falsche Newsrechner connected wurde. Trotzdem ist es natuerlich wahrscheinlich, dass noch einige Fehler in meinen Aenderungen vorhanden sind (schlussendlich habe ich auch einige Fehler im INN gefunden) und einiges verbessert werden kann. Wenn allgemeine Probleme ausgeschlossen werden koennen oder aber es Fragen allgemeiner Natur sind, empfehle ich eine Mail an die Mailingliste nid@listserv.uni-stuttgart.de zu schicken. Ich selbst bin ueber diese Liste auch erreichbar. Falls es um andere Dinge geht, kann man mir auch direkt eine Mail per Tobias.Hennerich@swabsib.s.bawue.de zukommen lassen. Ich versuche meine Mails taeglich zu lesen, auch wenn ich dies nicht immer versprechen kann. Frage: Ich habe noch eine andere Frage. Warum steht das nicht hier in der FAQ? Bitte sich an mich wenden. Ich versuche regelmaessig die Fragen die mir per mail gestellt werden in die FAQ mit einzubauen. Frage: Sonst noch was? Ich wuerde mich freuen, wenn ich von Erfahrungen mit den NiD etwas mitbekommen wuerde. Schreibt mir, wenn Ihr die Software einsetzt und wie sie sich bewaehrt. Falls mir jemand bei der Weiterentwicklung der NiD helfen moechte, waere dies natuerlich toll. Im Moment sollte vor allem diese FAQ (evtl. auch nur teilweise) ins Englische uebersetzt werden, damit man die NiD dann endlich in news.software.nntp annoucen kann (hoechstwahrscheinlich sind es dann die NiC). Ich moechte mich bedanken (in chronologischer Reihenfolge) bei: - Barbara Burr, welche die Studienarbeit betreute und es mir dadurch ermoeglichte aus einer Idee ein Projekt werden zu lassen - Frank Scholz, der massgeblich am Namen der "Dosen" beteiligt war und der auch sonst alle meine Probleme erzaehlt bekam - Den Admins des BaWue-Nets, welche es mir ermoeglichten die erste Installation der NiD auf einem Produktionssystem auszutesten - Dem RUS-Team, welches durch die Installation der NiD auf dem offiziellen Newsserver der Uni-Stuttgart eine Referenz-Installation ermoeglichte und durch ano-ftp-server und Mailingliste auch sonst Resourcen bereit stellte