Newsserver 'inn'

HOWTO rebuild history database & overview

Leider kommt es immer mal wieder dazu, dass nach einem Crash o.ä. die history und/oder overview database vom Newsserver dahin ist. Das äussert sich dann z.B. in Fehlermeldungen wie diesen:

innd: tradspool: could not open [...] File exists
innd: SERVER cant store article: File exists

Dann sollte man die Datenbanken neu aufbauen. Die Erfahrung hat gezeigt, dass es sinnvoll ist, die Datenbanken komplett neu aufbauen zu lassen, da sonst weitere Inkonsistenzen möglich sind. Dazu verwende ich das nachfolgende Verfahren, auch wenn dies vielleicht overkill ist. Ich übernehme natürlich keine Garantie für die Funktionalität (bei mir hat's bisher immer geklappt) oder dass es nicht schon Tools gibt, die das einfacher erledigen.

Das hier gesagte gilt für den Newsserver 'inn' unter Linux. Achtung: im makehistory bzw. makedbz vom inn 2.3.2 sind bugs; Nutzern dieser Version empfehle ich ein update auf Version 2.3.4 (Version 2.3.3 hat einen Bug in Verbindung mit PERL)!
Desweiteren gehe ich davon aus, dass alle notwendigen Dateien zum Newsserver im home-Verzeichnis des Users 'news' liegen (also ~news) - gegebenenfalls muss man halt etwas anpassen.

Hier also jetzt meine Vorgehensweise - möge dieses HOWTO anderen Nerven und Zeit sparen:

1. alle at- & cronjobs etc. disablen, die auf News zugreifen könnten
2. Newsserver beenden: z.B. via /etc/init.d/inn stop oder su -c "rc.news stop" news
3. [optional] überprüfen, ob das Medium in Ordnung ist: badblocks -sv /dev/$DRIVE
4. Filesystem auf logische Konsistenz prüfen: fsck /dev/$VOLUME (ggf. mit -C0 oder -f oder weiterer Parameter) bzw. xfs_check /dev/$VOLUME. Achtung: Das Volume muss dazu natürlich unmounted und danach remounted werden!
5. als User news einloggen: su - news (falls man remote administriert, empfiehlt sich, das in einer "screen"-session zu machen)
6. alten overview löschen oder umbenennen: mv ~/spool/overview ~/spool/overview.`date -I`
7. neues, leeres Verzeichnis dafür anlegen: mkdir ~/spool/overview
8. alte history löschen oder umbenennen (~/db/history und ~/db/history.*)
9. neue, leere history-db anlegen: cd ~/db && touch history && makedbz -i
10. ... und aktivieren: mv history.n.dir history.dir && mv history.n.index history.index sowie mv history.n.hash history.hash oder mv history.n.pag history.pag
11. history-db & Index aus spool neu mit Inhalt füllen: makehistory && makedbz - das kann schnell mal eine halbe Stunde oder länger dauern!
    [TO-DO: Auftauchen der Meldung Duplicate message-id "[...]" in history text untersuchen]
12. ... und aktivieren: mv history.n.dir history.dir && mv history.n.index history.index sowie mv history.n.hash history.hash oder mv history.n.pag history.pag
    (nein, das ist kein Fehler - das ist tatsächlich noch mal das Gleiche wie bei Punkt 10! :)
13. overview aus spool neu aufbauen: makehistory -O -x (grosses "O" wie "Omega"!) - auch hier ist wieder Geduld angesagt ... ca. doppelt so lange wie Punkt 11
14. Newsserver wieder starten: rc.news
15. "renumber"durchführen (geht erst jetzt, da neuere inn-Versionen dies aus der overview-db generieren und nicht mehr aus dem spool!):
    for NEWSGROUP in `cat ~/db/active | cut -f 1 -d " "`; do ctlinnd renumber $NEWSGROUP; done
16. Jetzt sollte man die Zeit des "last fetched" für die einzelnen NewsGroups auf einen Wert vor dem Crash setzen. Diese liegen je nach Installation woanders - z.B. unter ~/receive.$SERVERNAME. Erkennbar sind die Dateien daran, dass es je eine pro NewsGroup gibt, sie auch so heisst wie die Gruppe, ca. 34 Byte gross ist und einen Inhalt ähnlich "got 0 offered 0 sent 0 rejected 0" haben sollte. Die Zeit des "last fetched" entspricht einfach dem Datum der Datei selber, so dass man dies einfach mit touch ändern kann. In o.g. Beispiel wäre das also im Superverzeichnis der receive's möglich mit folgendem (statt "*" kann man auch einen entsprechende Gruppenmaske einsetzen - z.B. tui-net.*):
    for NEWSSERVER in `ls receive.* -1d`; do touch -t 197001010000 $NEWSSERVER/*; done
    Das setzt das "last fetched" auf den frühestmöglichen Zeitpunkt - 1970-01-01. Wenn man einen Server mit expiring hat, der schneller expired als der Server von dem man fetched, sollte man diese Zeit allerdings besser auf kurz vor dem Crash setzen, weil sonst schnell mal mehrere tausend bereits local expired postings noch mal auftauchen könnten (je nach Einstellungen in der expire.ctl).
    Nutzer von "suck" sollten sich diese Prozedur sparen können, da "suck" andere Info verwendet, um die Zeit des "last fetched" festzustellen. In wie weit man bei "suck" nach einem Crash eingreifen muss habe ich leider nicht überprüft. :(
17. Das war's eigentlich. Die folgenden vier Schritte empfehle ich aber trotzdem noch durchzuführen - insbesondere für die Paranoiden :)
18. News holen. Einfach wie sonst auch immer. Dabei die news.err im Auge behalten: tail -f ~/log/news.err
19. news.daily ausfüren: news.daily delayrm expireover lowmark (bitte hier die eigenen Parameter verwenden!)
20. Für besonders Paranoide (wie z.B. mich): "last fetched" nochmals zurücksetzen (keine Angst - wenn man das jetzt auf den gleichen Wert wie oben setzt, kommen keine doppelten Artikel zustande)
21. News holen.
22. die am Anfang ggf. abgestellten jobs reaktivieren
23. nun heist es: "resume normal operation" - finally ... done. (mit Punkt 23 - hat hier jemand was anderes erwartet? ;-)