

			FAQ zu den "News in Dosen"
			v1.0 vom 17. Dezember 1997

		   Tobias.Hennerich@swabsib.s.bawue.de


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.

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

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

- Eine rasche Aenderung des Expires zur Behebung von akutem
  Festplattenmangel ist 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: 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. Ich weiss von einem erfolgreichen Compilerlauf
unter Linux, aber das System ist noch nicht 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 liesst 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 Reader 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 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
einer bestimmten Menge an Daten 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.



Frage: Was muss ich beim Installieren der News in Dosen beachten?

Diese FAQ kann nicht auf die allgemeine Installation von INN
eingehen. Sie ist sehr komplex und 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 can.c anpassen.
  Bei solaris heisst es z.B. #define STATFS statvfs. Siehe Manpage!

- Man compiliere den INN wie ueblich, configuriere alle Dateien in
  $INN/site und tippe "make install"

Bzgl. konfigurieren:

- Wer sich anschauen moechte, wie auf die Dosen zugegriffen werden,
  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

- Die Konfigurationsdatei overview.fmt braucht zwingend am Ende
  den folgenden Eintrag:

	Xcanpos:full

  Wer will, kann den Eintrag "Xref:full" auskommentieren, um den
  Xcanpos kommt man aber nicht herum (deswegen ist in $INN/samples
  die Datei auch entsprechend vorbereitet). Ausserdem muss der overchan
  unbedingt gestartet werden, siehe dazu auch die Datei newsfeeds.

- In der Datei newsfeeds muessen zwei Dinge beachtet werden:

  * Der overchan muss immer eingetragen werden, 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"!

- 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 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 lege mit makehistory ein neues history-file an und spiele mit
  einem kleinen Script die Newsartikel wieder neu ein. Dies geht
  z.B. so (aus dem Kopf, nur einmal selbst gemacht und damals nicht
  mitgeloggt, sorry):
  
  	cd /var/spool/news
	find . -type f -print | xargs cat | 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 (Option -p) 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.



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



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.



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.



Frage: Ich moechte eine zusaetzliche Platte 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 Platte 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: 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 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.



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 gibt, 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?

Die FAQ ist noch sehr jung. Ich werde versuchen regelmaessig die
Fragen die mir per mail gestellt werden in die FAQ mit einzubauen.
