PersonalINN.Manager enthält ein schematisches Flußdiagramm von PersonalINN, um einen besseren Überblick über seine Komponenten zu ermöglichen. Um das Flußdiagramm in einem Fenster zu öffnen, wählen Sie im Menü Info den Befehl Flußdiagramm.
Im folgenden finden Sie detaillierte Erläuterungen des Flußdiagramms zu den Themen:
Konventionen im FlußdiagrammBenötigen Sie genauere Informationen zu einem bestimmten Programm oder einer Konfigurationsdatei von PersonalINN, dann ziehen Sie die entsprechende UNIX-Handbuchseite zu Rate.
Alle ausführbaren Programme befinden sich in /usr/local/inn/bin. Ausnahmen sind PersonalINN.Manager (installiert in einem Anwendungsverzeichnis), ip-up und ip-down (nicht zu PersonalINN gehörig und installiert in /etc/ppp), Alexandra (nicht zu PersonalINN gehörig und exemplarisch für einen Newsreader nach Wahl des Nutzers) und alle ausführbaren Programme, die zu NEXTSTEP gehören (markiert durch den grau hinterlegten Bereich am Fuße des Diagramms mit dem NeXT-Logo auf der rechten Seite).
Alle Textdateien befinden sich in /usr/local/inn/etc. Ausnahmen sind die Dateien innerhalb eines Verzeichnisses (markiert durch einen grauen Umriß), die Dateien mit einem expliziten Pfad (der relativ zu /usr/local/inn ist), und alle Dateien, die zu NEXTSTEP gehören (markiert durch den grau hinterlegten Bereich am Fuße des Diagramms mit dem NeXT-Logo auf der rechten Seite).
Alle Verzeichnisse befinden sich in /usr/spool/news. Die einzige Ausnahme ist das run-Verzeichnis, das als Zahnrad im Diagramm abgebildet ist und sich in /usr/local/inn befindet).
Die Verbindungsarten zwischen den Dateien sind durch unterschiedliche Striche markiert:
Bitte beachten Sie, daß im Interesse der Übersichtlichkeit unwichtige Verbindungen nicht eingezeichnet sind.
Wenn Sie PersonalINN.Manager benutzen, um PersonalINN zu konfigurieren, macht er Einträge in einige der Konfigurationsdateien von PersonalINN und in Systemdateien von NEXTSTEP. Diese Verbindungen sind ebenfalls nicht eingezeichnet. Bei den Dateien handelt es sich um:
newsfeedsEine Menge grundlegender Konfigurationseinstellungen zur Anpassung von INN an das Betriebssystem, auf dem es läuft, sind in den kompilierten Programmen fest eincodiert; um auch in sh- und perl-Skripten benutzt werden zu können, sind diese Einstellungen ebenfalls in innshellvars bzw. innshellvars.pl aufgelistet. Weitere grundlegende Konfigurationswerte, die innd nur liest, wenn es gestartet wird, sind in inn.conf enthalten; innshellvars und innshellvars.pl importieren diese Werte mit Hilfe des Programms innconfval.
Wird der Computer hochgefahren, wird rc.news (als Nutzer news) gestartet aufgrund eines Eintrags in rc.local. rc.news überprüft die Integrität des News-Systems (und schickt eine Email an den/die newsmaster, falls es Probleme feststellt), führt, soweit notwendig, Aufräumarbeiten durch, und startet inndstart. inndstart läuft su root, um die Umgebung zum Start von innd vorbereiten zu können (Ports und Sockets öffnen usw.); dann startet es innd (als Nutzer news).
innd ist das zentrale Programm von PersonalINN und läuft die gesamte Zeit. Aus Sicherheitsgründen kann es nur über Sockets angesprochen werden, die sich im run-Verzeichnis befinden. Das run-Verzeichnis ist nur für Mitglieder der Gruppe news zugänglich und bildet daher einen Firewall für innd. Außer den Sockets enthält das run-Verzeichnis mehrere PID- und Sperrdateien, um die Integrität des News-Systems zu gewährleisten. PersonalINN-Shell-Skripte, die Sperrdateien in das run-Verzeichnis schreiben müssen, können das mit Hilfe des shlock-Programms.
Wenn über PPP eine TCP/IP-Verbindung zum Internet hergestellt wird, wird das ip-up-Skript ausgeführt, das seinerseits newsxstart startet. Solange newsxstart nicht durch eine BLOCK.autostart-Datei im run-Verzeichnis blockiert wird (die PersonalINN.Manager schreibt, um den Start von news.daily und newsxstart zu blockieren), startet es newsx in periodischen Abständen entsprechend den Einstellungen in PersonalINN.Manager, die in pinn.conf abgespeichert werden. Wenn die TCP/IP-Verbindung unterbrochen wird, wird newsxstart durch ip-down beendet. Solange die TCP/IP-Verbindung besteht, kann newsx auch manuell durch PersonalINN.Manager gestartet werden.
newsx riegelt sich im run-Verzeichnis ab und nimmt eine Verbindung zu dem in newsfeeds spezifizierten NNTP-Newsserver auf, wobei es vorgibt, ein Newsreader zu sein. Wurde während der Konfiguration ein Paßwort spezifiziert, existiert password.provider, und newsx benutzt das dort aufgeführte Paßwort für die Verbindung. newsx holt alle in active aufgelisteten Newsgruppen (außer control, junk und Newsgruppen mit der Top-Level-Hierarchie für lokale Newsgruppen, die in newsfeeds abgespeichert ist). Für jede Gruppe schreibt newsx die höchste Artikelnummer der Artikel, die es geholt hat, in incoming/ provider.name (provider.name ist dabei der in newsfeeds spezifizierte Newsserver) und beginnt dann beim nächsten Start mit dem ersten noch nicht geholten Artikel. newsx durchsucht auch die lokale history-Datenbank (die aus history, history.hash, history.dir und history.index besteht) nach Message-IDs von bereits lokal abgespeicherten Artikeln. Findet es dort eine Message-ID eines ihm jetzt als neu angebotenen Artikels, dann holt es den Artikel kein zweites Mal, um Duplikate zu vermeiden. (Beachten Sie, daß dies stets der Fall sein wird für lokal geschriebene Artikel, die zuvor von newsx zu dem spezifizierten Newsserver gepostet wurden, da der Newsserver diese Artikel stets ebenfalls als neue Artikel auflisten wird.)
newsx fügt newsx in die Path:-Kopfzeilen der Artikel ein, die es holt. Dann pumpt es die Artikel, die es geholt hat, in rnews, das die Daten so konvertiert, daß sie für innd so aussehen, als ob sie direkt von einem anderen Newsserver gefüttert würden; dann sendet es sie an innd. Falls innd in diesem Moment pausiert oder abgedrosselt ist, warten newsx und rnews, bis innd nicht mehr pausiert oder abgedrosselt ist. Falls innd in diesem Moment nicht läuft, sichert rnews die Artikel stattdessen in einem oder mehreren Batchdateien (jede maximal 1MB groß), die es im articles-Verzeichnis ablegt (aber nicht in den Unterverzeichnissen von articles). Das nächste Mal, wenn die news.daily-Wartungsroutine läuft, wird rnews erneut aufgerufen, schaut, ob in articles noch Batchdateien gespeichert sind, und füttert sie gegebenenfalls in innd. Falls die Kopfzeile eines Artikels beschädigt oder falsch ist, speichert rnews den Artikel im tmp-Verzeichnis, wo er für ein paar Tage erhalten bleibt.
innd fügt die Xref:-Kopfzeile zu den empfangenen Artikeln hinzu, speichert sie in den entsprechenden Unterverzeichnissen (jede Newsgruppen-Hierarchie entspricht einem Unterverzeichnis) des articles-Verzeichnisses in Textdateien mit Artikelnummern als Dateinamen (das ist die sogenannte traditional spool-Methode; INN 2.2 bietet noch andere Methoden an, die auf sehr große Newsserver zielen), speichert die Message-IDs, die Ankunftszeit der Artikel und den Pfad der entsprechenden Artikeldateien in der history-Datenbank und sichert die höchste der Artikelnummern einer Newsgruppe in active. Gesteuert durch die Einträge in newsfeeds sendet es die Artikel ebenso zu overchan, das die Kopfzeilen-Daten der Artikel in der overview-Datenbank speichert (in dem in overview.fmt festgelegten Format), um einen schnelleren Zugriff auf sie zu ermöglichen. Da newsfeeds alle Artikel, die einen newsx-Eintrag in ihrer Path:-Kopfzeile haben (den newsx in alle von ihm geholten Artikel eingefügt), davon ausschließt, zu filechan gesandt zu werden, gelangt keiner der Artikel, die newsx geholt hat, dorthin.
Im Gegensatz hierzu werden lokal verfaßte Artikel (siehe unten) auch zu filechan gesandt, wenn innd sie empfängt. filechan schreibt die lokalen Pfade der entsprechenden Artikeldateien (und ihre Dateigröße) in outgoing/provider.name (außer bei Artikeln für control, junk und Newsgruppen mit der Top-Level-Hierarchie für lokale Newsgruppen, die in newsfeeds abgespeichert ist). Auf diese Weise werden alle lokal verfaßten Artikel (bzw. die Pfadnamen der entsprechenden Artikeldateien), die ins Internet gesandt werden sollen, in outgoing/provider.name aufgelistet.
newsx liest outgoing/provider.name und postet die aufgelisteten Artikel zu dem in newsfeeds spezifizierten Newsserver, wobei es wiederum vorgibt, ein Newsreader zu sein. Nachdem die Artikel erfolgreich gepostet wurden, löscht newsx sie von outgoing/provider.name.
Wenn Sie einen Newsreader (wie zum Beispiel Alexandra) auf Ihrem Computer oder lokalen Netzwerk starten und mit ihm eine Verbindung zu PersonalINN aufbauen, generiert innd eine Instanz von nnrpd, die alle weiteren Anfragen dieses Newsreaders bearbeitet. Diese Übergabe wird konfiguriert durch die Dateien incoming.conf (listet alle Hosts auf, die als Newsserver gelten, und folglich mit innd und nicht mit nnrpd verbunden werden sollen) und nnrp.access (stellt die Zugriffsrechte und Beschränkungen für den Newsreader-Zugang ein). In PersonalINN listet incoming.conf keine Hosts auf, so daß alle Verbindungen als Newsreader-Verbindungen zu nnrpd interpretiert werden (innd wird in PersonalINN von newsx, und nicht direkt von einem anderen Newsserver), während nnrp.access grundsätzlich allen Newsreadern Zugang gestattet (da PersonalINN typischerweise vom Internet aus nicht zugänglich ist).
nnrpd erhält Informationen über die verfügbaren Newsgruppen und die Anzahl der Artikel in ihnen von active, über die verfügbaren Artikel in den Newsgruppen (definiert durch deren Message-ID) von der history-Datenbank, und über Artikel-Kopfzeilen (Betreff, Autor usw.) von der overview-Datenbank. Auf Anfrage (via NNTP) stellt es dem Newsreader diese Informationen zur Verfügung. Wenn der Newsreader einen Artikel anhand von dessen Message-ID bestellt, befragt nnrpd die history-Datenbank nach dem Pfad der Artikeldatei, die dem Artikel mit der gewünschten Message-ID entspricht, öffnet die Datei und sendet ihren Inhalt an den Newsreader; wenn der Newsreader einen Artikel anhand von dessen Artikelnummer bestellt, kann nnrpd die Datei sofort öffnen und ihren Inhalt an den Newsreader senden.
Wenn der Newsreader einen Artikel postet, erzeugt nnrpd eine Message-ID und einige andere Kopfzeilen für ihn, und sendet ihn an innd auf dieselbe Weise wie rnews (siehe oben). innd fügt die Xref:-Kopfzeile hinzu (die nnrpd nicht setzen kann, da es nicht weiß, welche Artikelnummer innd vergeben wird), speichert den Artikel in dem entsprechenden Unterverzeichnis des articles-Verzeichnisses, aktualisiert active und die history-Datenbank und speichert die Kopfzeilen des Artikels in der overview-Datenbank (siehe oben). Da der Artikel lokal verfaßt wurde und daher keinen newsx-Eintrag in seiner Path:-Kopfzeile enthält, sendet innd den Artikel (sofern er nicht in control, junk oder eine Newsgruppe mit der Top-Level-Hierarchie für lokale Newsgruppen gepostet wurde, die in newsfeeds abgespeichert ist) auch zu filechan, das ihn in outgoing/provider.name auflistet (siehe oben), so daß newsx ihn ins Internet posten wird.
Entnimmt nnrpd den Informationen in active, daß die Newsgruppe, in die der Artikel gepostet wird, moderiert ist, sendet es ihn stattdessen als Email an newsgruppe@moderators.isc.org, von wo aus er zu dem Moderator dieser Newsgruppe weitergeleitet wird.
In PersonalINN ist PersonalINN.Manager das zentrale Programm für die Administration und Wartung des Systems. Es speichert seine eigenen Konfigurationsdaten in pinn.conf und riegelt sich mit der Sperrdatei LOCK.pinn im run-Verzeichnis ab.
Um eine Liste der auf dem in newsfeeds spezifizierten NNTP-Newsserver verfügbaren Newsgruppen zu holen, benutzt PersonalINN.Manager das Programm getlist, das die active- und newsgroups-Dateien (die eine Liste der verfügbaren Gruppen bzw. die Beschreibung dieser Gruppen enthalten) von diesem Newsserver holt. Während newsgroups unverändert lokal abgespeichert wird, kombiniert PersonalINN.Manager die Inhalte von newsgroups und active in feed und feed.new, die die Namen und Beschreibungen aller verfügbaren bzw. aller neuen Newsgruppen in einem für PersonalINN.Manager geeigneten Format enthalten.
Um Newsgruppen zu PersonalINN hinzuzufügen bzw. von ihm zu entfernen, bearbeitet PersonalINN.Manager die active-Datei entsprechend und lädt sie danach erneut in innd.
Um Verfallsperioden zu ändern, bearbeitet PersonalINN.Manager die expire.ctl-Datei.
Wenn lokale Newsgruppen erstellt werden, speichert PersonalINN.Manager sie in local in demselben Format wie bei feed und feed.new, und fügt sie zu active hinzu; die Top-Level-Hierarchie für lokale Newsgruppen wird in newsfeeds geschrieben.
Um die Organization:-Kopfzeile zu ändern, bearbeitet PersonalINN.Manager die inn.conf-Datei. innd muß danach neu gestartet werden, damit diese Einstellung wirksam wird.
Um PersonalINN zu überprüfen und zu reparieren, verwendet PersonalINN.Manager die Hilfsprogramme inncheck, makehistory und makeactive.
Informationen über die Dateien, die PersonalINN.Manager bei der Konfiguration von PersonalINN bearbeitet, finden Sie oben.
ctlinnd ist die klassische Kommandozeilen-Oberfläche von INN und INNs Entsprechung zu PersonalINNs PersonalINN.Manager. Das Programm wird zudem von mehreren Skripten benutzt, die mit innd kommunizieren müssen; news.daily, newsx und scanlogs benutzen ctlinnd, um innd zu pausieren, wenn sie dies müssen.
Logdateien werden in das log-Verzeichnis geschrieben. Während einige Programme direkt in das log-Verzeichnis schreiben, benutzen innd, nnrpd, rnews und newsx das Programm syslogd entsprechend der Einträge in syslog.conf (Kanäle local0 und local1). nnrpd liest pinn.conf, um zu entscheiden, ob es die Hostnamen oder die IP-Adressen der Hosts, die sich mit ihm verbinden, in die Logdatei schreiben soll (diese Verbindung ist im Flußdiagramm nicht eingezeichnet).
Emails, die PersonalINNs Programme dem/den newsmaster(n) senden wollen, werden via innmail versandt; die tatsächlichen Email-Adressen für den/die newsmaster sind in dem aliases-Verzeichnis der NEXTSTEP-NetInfo-Datenbank gespeichert.
Wenn rc.news innd startet, startet es auch innwatch, das entsprechend den Einträgen in innwatch.ctl PersonalINN alle 10 Minuten überprüft. Es prüft (mittels inndf) den verbliebenen freien Platz auf der/den Festplatte(n), auf der/denen PersonalINN installiert ist, schaut nach neuen kritischen Fehlermeldungen in der Logdatei news.crit, und testet (mittels ctlinnd), ob innd noch läuft. innwatch riegelt sich in dem run-Verzeichnis mit den Dateien LOCK.innwatch und innwatch.pid ab; außerdem sichert es die letzte Prüfzeit in innwatch.time, so daß es in der Lage ist, nur diejenigen Fehler zu berichten, die seit der letzten Überprüfung aufgetreten sind. Wenn innwatch einen Fehler entdeckt, sendet es sofort eine Email an den/die newsmaster, und drosselt innd via ctlinnd ab, falls dies aufgrund zu geringen Festplattenplatzes nötig wird (das sollte allerdings nicht dadurch passieren, daß PersonalINN Artikel holt, da newsx das Holen von Artikeln bereits einstellt, wenn der Festplattenplatz unter 20 MB sinkt, während innd erst bei weniger als 18 MB verfügbarem Platz abgedrosselt wird); steht erneut ausreichend Festplattenplatz zur Verfügung, läßt innwatch innd auch wieder laufen.
Einmal am Tag, entsprechend der Einstellung in crontab.local, startet cron news.daily. Falls news.daily durch eine BLOCK.autostart-Datei im run-Verzeichnis blockiert wird (die PersonalINN.Manager schreibt, um den Start von news.daily und newsxstart zu blockieren), beendet sich das Programm sofort wieder; andernfalls riegelt es sich im run-Verzeichnis ab, reinigt das tmp-Verzeichnis und löscht nicht mehr aktuelle Dateien in outgoing und incoming; schließlich startet es rnews, um eventuell noch vorhandene Batchdateien (siehe oben) in innd zu speisen.
news.daily ruft innstat auf, um einen Statusreport von PersonalINN zu erstellen. innstat befragt ctlinnd nach dem Status von innd, benutzt inndf, um den verbleibenden Festplattenplatz auf der/den Festplatte(n) festzustellen, auf der/denen PersonalINN installiert ist, und überprüft Existenz und Größe der Dateien in den incoming-, outgoing- und log-Verzeichnissen als auch die Existenz von Sperrdateien im run-Verzeichnis.
Danach startet news.daily scanlogs. scanlogs riegelt sich im run-Verzeichnis ab, faßt wichtige Meldungen aus den Logdateien mit Hilfe von innreport zusammen (das durch innreport.conf und innreport_inn.pm konfiguriert wird), und rotiert dann den Inhalt der Logdateien sowie der active-Datei in die Backupdateien in dem OLD-Unterverzeichnis des log-Verzeichnisses.
Danach startet news.daily expire, das die history-Datenbank nach Artikeln durchsucht, die älter sind, als es expire.ctl für die betreffende Newsgruppe erlaubt. Unter Zuhilfenahme eine temporären Datei namens expire.rm pumpt expire die Pfade dieser Artikel in expireover, das die entsprechenden Einträge in der overview-Datenbank löscht, und in expirerm, das nach einer Überprüfung auf Fehler fastrm benutzt, um die Artikeldateien tatsächlich aus dem articles-Verzeichnis zu löschen. Falls alles geklappt hat, wird expire.rm in expire.list umbenannt und im log-Verzeichnis gespeichert. expire selbst löscht die entsprechenden Einträge in der history-Datenbank; allerdings läßt es die Einträge dort 30 Tage länger bestehen als die Artikeldateien selbst, um so newsx zu ermöglichen, selbst dann zu verhindern, daß Artikel ein zweites Mal geholt werden, wenn sie schon verfallen waren.
Nach dem Löschen verfallener Artikel numeriert news.daily active mit Hilfe von ctlinnd neu und ruft innstat ein zweites Mal auf, um einen abschließenden Statusreport zu geben.
Schließlich sendet news.daily eine Email mit dem Ergebnis des Löschvorgangs und den Berichten von innstat und innreport an den/die newsmaster (falls es in dem crontab.local-Eintrag dazu konfiguriert wurde). Die Zeit, zu der news.daily seine Arbeit beendet hat, wird in .news.daily gespeichert; das erlaubt rc.news zu überprüfen, ob die tägliche News-Routine regelmäßig ausgeführt wurde, wenn PersonalINN gestartet wird.