$Id: inn.faq,v 1.3 2004/01/17 12:16:48 eumel Exp $ INN als lokaler Newsserver "Das InterNetNews Paket ist ein komplettes Usenet System. Es beinhaltet innd, ein NNTP Server, und nnrpd, ein Newsreading Server". So umschreibt es das "Internet Software Consortium" (ISC), auf dessen Homepage http://www.isc.org/ INN und anderen Produkte wie BIND oder DHCP vertrieben werden. Die Programmierung des INN geht in den Anfang der 90er Jahre zurueck. Als historisches Posting wird news:3632@litchi.bbn.com vom 18.06.1991 angesehen, in dem vom Entwickler des INN, Rich Salz, Betattester fuer INN gesucht werden. INN wurde ab 1996 vom ISC staendig weiterentwickelt und liegt in der aktuellen Version 2.3.5 vor. INN eignet sich sowohl fuer grosse Server oder Feeds als auch fuer den Hausgebrauch als "Leafsite". Bevor wir beginnen: INN laeuft sowohl auf Pentium 100 als auch auf Pentium 1000. RAM-Speicherbedarf liegt bei 64 MB (typisch 128 MB) und Plattenplatz je nach Auswahl der Gruppenliste und Dauer der Haltezeit. Als Richtlinie gilt in etwa: full Feed (40.000-80.000 Gruppen) = 200-400 GB taeglich Big8 Feed (5000 Gruppen) = 250-900 MB taeglich de.* Feed (500 Gruppen) = 20-30 MB taeglich Physikalische Grenzen gibt es beim Newstransport in der zur Verfuegung stehenden Bandbreite und der Drehgeschwindigkeit der Festplatte, auf die die Newsartikel geschrieben werden. Bei beiden Parametern gibt es ein Spektrum von Moeglichkeiten. Sei es die Anbindung via STM1 (155 MBit/sec) oder ISDN (64 kBit/sec), sei es ein SCSI-3-Plattenarray fuer 20.000 Euro oder eine IDE-Festplatte fuer 59,50. INN wird auf allen Systemen funktionieren. Auch vom Betriebssystem her bietet sich eine Fuelle von Moeglichkeiten: Linux, FreeBSD, Solaris ... Wir beschreiben die INN-Konfiguration auf einem SuSE-8.2-System mit aktuellem Kernel (2.4.20) und aktuellen C-Compiler (gcc 3.3). Das INN-System soll von den Sourcen installiert werden. Startup: Wir besorgen uns die INN-Sourcen von ftp://ftp.isc.org oder einem Mirror (ftp://ftp.arcor.de/pub/mirrors/ftp.isc.org/isc/inn/) und entpacken diese auf unserem System: # wget ftp://ftp.arcor.de/pub/news/software/server/inn/inn-2.3.5.tar.gz # tar xvfz inn-2.3.5.tar.gz # cd inn-2.3.5/ Wir entschliessen uns fuer eine Komplettinstallation unter /usr/local/news. Dazu benoetigen wir den User "news" und die Gruppe "news". Da diese meist mit falschem Homedir existiert, loeschen wir diese am besten und legen sie neu an: # userdel -r news # useradd -u 9 -g news -d /usr/local/news -s /bin/bash -m news Die Gruppe "news" muss in /etc/groups existieren und die gewuenschte Shell muss in /etc/shells mit vollstaendigem Pfad aufgelistet sein. INN setzt die Installation eines Mail Transport Agents voraus, um systemeigene Mails oder Moderatormails verschicken zu koennen. Ueblicherweise ist das sendmail oder postfix - installiert unter /usr/sbin/sendmail. Wenn wir spaeter Filter implementieren wollen, muessen wir Perl-Support bei der INN-Konfiguration bekanntmachen. Eine gute Auswahl von Configurationsparamentern waeren: # ./configure --with-perl --with-largefiles --mandir=/usr/local/man --enable-uucp-rnews Perl-Support (fuer die Filter ... Perl ist doch installiert?) Largefiles (fuer Dateien ueber 2 GB, die von INN verwaltet werden) man-dir (fuer Ablage der Man-Pages fuer den INN) Wenn INN nichts zu beanstanden hat, wird der Vorgang nach einer Weile beendet mit: Please check the following files before running make, to ensure that everything was set correctly. Makefile.global include/config.h include/paths.h innfeed/innfeed.h Weitere Anpassungen sind eigentlich nicht noetig. Make a make: # make Auch dieser Vorgang sollte ohne Fehler abschliessen. Sollte es doch zu Schwierigkeiten kommen, werden diese im Abschnitt "Schmerzbehandlung" weiter unten aufgelistet. # make install Das kompilierte INN-System wird nach /usr/local/news installiert. Es schliess ab mit der Meldung: Do not forget to update your cron entries, and also run makedbz if you need to. If this is a first-time installation a minimal active file has been installed. You will need to touch history and run "makedbz -i" to initialize the history database. See INSTALL for more information. Die folgende Option ist variabel. Syslog-Files fuer News kann man vom INN oder vom System verwalten lassen. Wenn wir uns fuer ersteres entscheiden, aendern wir die /etc/syslog.conf ab und legen unsere eigenen Logfiles an: /etc/syslog.conf Vorher: # all news-messages # # these files are rotated and examined by "news.daily" news.crit -/var/log/news/news.crit news.err -/var/log/news/news.err news.notice -/var/log/news/news.notice Nachher: # all news-messages in one file # news.notice /usr/local/news/log/news.notice news.crit /usr/local/news/log/news.crit news.err /usr/local/news/log/news.err Achtung: Die Eintraege in der syslog.conf sind durch mehrere getrennt, es sind keine Leerzeichen! Wir legen unsere eigenen Syslogdateien an, geben ihnen die korrekten Permissions und starten den syslogd neu; # touch /usr/local/news/log/news.notice # touch /usr/local/news/log/news.err # touch /usr/local/news/log/news.crit # touch /usr/local/news/log/news # chown news:news /usr/local/news/log/news.* # killall -HUP syslogd Wir wechseln zum User "news" ueber und sollten uns in seinem Homeverzeichnis befinden: # su - news # pwd /usr/local/news Wir wechseln in das Verzeichnis "db" und sollten folgende Dateien dort vorfinden: news@eumobil:~/db> ls -l insgesamt 8 -rw-r--r-- 1 news news 225 2003-12-31 16:36 active -rw-r--r-- 1 news news 0 2003-12-31 16:38 active.times -rw-r--r-- 1 news news 333 2003-12-31 16:36 newsgroups Dies stellt eine Minimalauswahl an Newsgruppen dar (control + junk). Wir besorgen uns ein aktuelles active und newsgroups file von ftp://ftp.isc.org/usenet/CONFIG/ (Vorsicht, die Dateien sind teilweise sehr gross) oder vom FTP-Server unseres Providers: ftp://ftp.arcor.de/pub/news/uucp.gnuu.de/ news@eumobil:~/db> wget ftp://ftp.arcor.de/pub/news/uucp.gnuu.de/active news@eumobil:~/db> wget ftp://ftp.arcor.de/pub/news/uucp.gnuu.de/newsgroups Im active File wird die Artikelnummerierung fuer den aeltesten und den neuesten Artikel pro Gruppe festgehalten sowie den Status jeder Gruppe (moderiert/nicht moderiert/lokale Postings erlaubt) Im newsgroups File finden wir eine Kurzbeschreibung jeder Gruppe. Wir wollen nur Artikel aus der Hierarchie de.* und vorhalten, setzen die Artikelnummerierung auf 0 zurueck und fuegen diese Gruppe dem active-file zu: news@eumobil:~/db> grep "^de\." active.1 | awk '{print $1, "0000000000 0000000001", $4}' >> active news@eumobil:~/db> grep "^de\." newsgroups.1 >> newsgroups Wir legen eine leere History an und erstellen eine neue Historydatenbank: news@eumobil:~/db> touch history news@eumobil:~/db> makedbz -i -f history Unser db-Verzeichnis sieht jetzt etwa so aus: news@eumobil:~/db> ls -l insgesamt 604 -rw-r--r-- 1 news news 24039 2003-12-31 17:00 active -rw-r--r-- 1 news news 238248 2003-12-31 16:56 active.1 -rw-r--r-- 1 news news 0 2003-12-31 16:38 active.times -rw-r--r-- 1 news news 0 2003-12-31 16:48 history -rw-r--r-- 1 news news 43 2003-12-31 16:48 history.dir -rw-r--r-- 1 news news 0 2003-12-31 16:48 history.hash -rw-r--r-- 1 news news 0 2003-12-31 16:48 history.index -rw-r--r-- 1 news news 30420 2003-12-31 17:02 newsgroups -rw-r--r-- 1 news news 311794 2003-12-31 16:56 newsgroups.1 Newskonfiguration: Wir begeben uns in das Verzeichnis ~news/etc. Dort finden wir die von INN vorinstallieren Konfigurationsdateien. Zentrale Konfigurationsdatei ist die inn.conf. Normalerweise sind dort erstmal keine Einstellungen notwendig - INN hat schon alle Pfade und Programmdefaultparameter bei der Installation gesetzt. Es bleibt uns bloss noch die Modifizierung an unser System: inn.conf organization: Inhalt des Organization-Headers aller Artikel, die ueber unseren Server gepostet werden, sofern die Postings nicht schon einen solchen Header besitzen. Der Konfigurations-Eintrag kann geloescht werden. ovmethod: Speichermethode fuer die Overviews. Default ist tradindexed - alle Overviewdaten werden in Textdateien nach einer internen Verwaltung des INN abgelegt. Weitere Methoden sind buffindexed - Speicherung der Overviews im CNFS-Format. CNFS-Dateien muessen dazu angelegt und in der buffinedexed.conf bekanntgegeben werden. ovdb - Speicherung der Overviews in einer Berkeley DB. Die Datei ovdb.conf dient der Konfiguration. pathhost: Pfadeintrag fuer den Path-Header von Artikeln, die unseren Newsserver durchlaufen. Der Pathhost ist normalerweise der Rechnername, sollte aber ein "Fully qualified domain name" (FQDN) sein, falls die Artikel unseres Newsservers ins Usenet gelangen sollen. Verschiedene Provider bieten FQDNs an. Unser Rechner soll "paul.news.arcor.de" heissen und so setzen wir auch den Pathhost. domain: Defaultdomain fuer Mailversand, in unserem Beispiel: "news.arcor.de", da der Rechner "paul" heisst. usecontrolchan: Setzen wir auf "true", damit Steuernachrichten von einem extra Prozess verarbeitet werden. complaints: Mail-Adresse fuer den X-Complaints-To-Header. An diese Adresse sollen Beschwerden ueber unsere Newspostings geschickt werden. Der Eintrag ist variabel, z.B.: paul@arcor.de fromhost: FQDN unseres Newsservers ("paul.news.arcor.de") Im Sektor "Logging" koennen wir einige Defaultparameter aendern: logcancelcomm: true logcycles: 30 nntplinklog: true timer: 300 Mit dem INN-Timer koennen wir spaeter feststellen, ob fuer unseren INN noch genug Systemresourcen zur Verfuegung stehen (Siehe INN-Report). Weitere Aenderungen sind in der inn.conf erst einmal nicht notwendig. Die Datei storage.conf: In dieser Datei definieren wir Art und Groesse unseren Newsspools. Verschiedene Speichermethoden stehen zur Verfuegung: method timehash - Jeder Artikel wird in eine einzelne Datei geschrieben, die im Pfad ein Extrakt aus der Ankunftszeit des Artikels auf dem Server traegt. method timecaf - Mehrere Artikel werden in eine Datei nach demselben Abbild wie in "timehash" geschrieben. method tradspool - Ablage der Artikel in einzelne Files, wobei die Artikelnummer der Filename ist und der Gruppenname die Verzeichnisstruktur des Spools bildet. method cnfs - Ablage der Artikel in "Cyclic News File System" (CNFS). Wir entscheiden uns fuer CNFS, weil es die schnellste Speichermethode darstellt und kein Expire notwendig ist. Die Buffers werden fortlaufend beschrieben, wobei das Beschreiben der Buffers von vorn beginnt, sobald das Dateiende des Buffers erreicht ist (cyclic). Diese Buffer muessen von uns erstellt werden: # dd if=/dev/zero of=/usr/local/news/spool/a1 bs=1k count=500000 # dd if=/dev/zero of=/usr/local/news/spool/a2 bs=1k count=500000 2 Cycbuffers von je 500 MB Groesse. Diese machen wir in der cycbuff.conf dem INN bekannt. Unser Server soll spaeter 500 MB fuer die Hierarchie "de.*" bekommen und 500 MB ist fuer die Hierarchie "ffm.*" und dem "Rest". Es ist sehr wichtig, dass wir diesen "Rest" definieren, da der INN sonst die Artikelverarbeitung anhaelt, wenn er fuer einen Artikel keine Speicherklasse findet. Der Inhalt der Datei cycbuff.conf: cycbuff:a1:/usr/local/news/spool/a1:500000 cycbuff:a2:/usr/local/news/spool/a2:500000 metacycbuff:DE:a1 metacycbuff:RE:a2 Speichermethoden werden den Speicherklassen in der Datei storage.conf zugewiesen. Dort legen wir auch fest, welche Newsgruppen in welche Klasse gehoeren. Der Inhalt der Datei storage.conf: method cnfs { newsgroups: de.* class: 1 options: DE } method cnfs { newsgroups: * class: 2 options: RE } Mit CNFS ist wie schon erwaehnt kein Expire notwendig. Der Inhalt der Datei expire.ctl beschraenkt sich auf /remember/:10 Artikel sollen nach dem Loeschen aus dem Spool noch 10 Tage in der History verbleiben, damit sie uns nicht erneut angeboten werden. Die Datei control.ctl: Die Verwaltung von Usenet-Hierarchien wird mittels Versendung von Steuernachrichten durchgefuehrt. Dazu koennen Gruppen neu eingerichtet (control.newgroup), geloescht (control.rmgroup) oder eine Liste aktueller Gruppen pro Hierarchie (control.checkgroups) vom jeweiligen Hierarchie-Maintainer versendet werden. In der Datei control.ctl wird das Verhalten unseren Newsservers bei Eintreffen einer solchen Steuernachricht festgelegt. Definierte Aktionen sind: doit (Fuehr die Steuernachricht aus) drop (Schmeiss die Steuernachricht weg) log (Schreib die Steuernachricht in ein Logfile) mail (Mail die Steuernachricht an eine Adresse) verify (Vergleich die Steuernachricht mit dem PGP-Key des Maintainers) Da wir die Hierarchie de.* und ffm.* vorhalten wollen, muessen wir auf unserem Rechner PGP installieren und uns die public Keys der Hierarchie Maintainer besorgen: # yast2 -i gpg # su - news Bei SuSE 8.2 ist aber normalerweise GnuPG schon installiert. Wir besorgen uns die public PGP-Keys entweder von der zentralen Stelle: ftp://ftp.isc.org/pub/pgpcontrol/PGPKEYS oder den 2 Usenet-Hierachien, die wir vorhalten wollen: news@eumobil:~> cd .gnupg news@eumobil:~> wget http://www.dana.de/mod/pgp/dana.asc news@eumobil:~> wget ftp://ftp.arcor-online.net/pub/news/PGPKEY.FFM Die public Keys werden unserem public Keyring hinzugefuegt, indem wir sie selbst signieren: news@eumobil:~/.gnupg> gpg --import dana.asc news@eumobil:~/.gnupg> gpg --import PGPKEY.FFM Unser Keyring sollte dann in etwa so aussehen: news@eumobil:~/.gnupg> gpg --list-keys gpg: siehe http://www.gnupg.org/de/faq.html für weitere Informationen /usr/local/news/.gnupg/pubring.gpg ---------------------------------- pub 1024R/D3033C99 1996-05-18 uid de.admin.news.announce pub 1024R/1B9E000D 2002-10-09 ffm.admin Wir laden uns eine signierte Steuernachricht herunter und pruefen die Funktionsweise von PGP: news@eumobil:~/.gnupg> wget ftp://ftp.arcor.de/pub/news/ffm.checkgroups.pgp news@eumobil:~/.gnupg> pgpverify < ffm.checkgroups.pgp ffm.admin Wenn wir auf das pgpverify den Output "ffm.admin" bekommen, ist PGP mit INN funktionstuechtig. In der control.ctl sollten folgende Zeilen zu finden sein: # all:*:*:drop checkgroups:*:*:mail ihave:*:*:drop sendme:*:*:drop sendsys:*:*:log=sendsys senduuname:*:*:log=senduuname version:*:*:log=version # newgroup:*:*:mail rmgroup:*:*:mail # checkgroups:moderator@dana.de:de.*:verify-de.admin.news.announce newgroup:moderator@dana.de:de.*:verify-de.admin.news.announce rmgroup:moderator@dana.de:de.*:verify-de.admin.news.announce # checkgroups:ffm.admin@arcor.de:ffm.*:verify-ffm.admin newgroup:ffm.admin@arcor.de:ffm.*:verify-ffm.admin rmgroup:ffm.admin@arcor.de:ffm.*:verify-ffm.admin ## Die anderen Eintraege koennen geloescht werden. Die Datei moderators: Hier spezifieren wir die Mailadresse, an die Artikel fuer moderierte Newsgruppen gesendet werden sollen. Einige Defaulteintraege sind schon vorhanden, insbesondere der Wildcard-Eintrag "*:%s@moderators.isc.org", an den alle Artikel gemailt werden, sofern weiter oben keine andere Rule matcht. Wir benoetigen: ffm.*:%s@moderators.arcornews.de de.*:%s@moderators.dana.de *:%s@moderators.isc.org Die anderen Eintraege koennen geloescht werden. Die Datei incoming.conf: In der Datei incoming.conf werden Newspeers eingetragen, die zu uns einen Server-Server-Connect aufbauen duerfen (Feed). Es reicht uns der Defaulteintrag: streaming: true # streaming allowed by default max-connections: 8 # per feed peer ME { hostname: "localhost, 127.0.0.1" } Es sind 8 parallele Streamingconnections von unserem Peer "ME" erlaubt. Die Verbindungen koennen von localhost oder 127.0.0.1 gestartet werden. Die Datei newsfeeds: In dieser Datei werden alle Channels aufgelistet, an die hereinkommende Newsartikel weitergeleitet werden sollen. Wir wollen alle Artikel unserem lokalen Newsspool zufuehren, Steuernachrichten extern verarbeiten und eigene Artikel in ein Batchfile "uucp.gnuu.de" schreiben, welches wir spaeter mit einem anderen Programm bearbeiten. Der Inhalt der Datei newsfeeds: ## ME:!*/!local,!collabra-internal:: # controlchan!\ :!*,control,control.*,!control.cancel\ :Tc,Wnsm:/usr/local/news/bin/controlchan # # uucp.gnuu.de/news.arcor.de\ :*,!junk,!local.*,!control.*\ :Tf,Wnb:uucp.gnuu.de Die Datei hat also den Aufbau: site/exclude_path1,exclude_path2...\ :newsgroups-pattern/distribution\ :flag,flag:parameter Flags sind zum Beispiel Feed-Typen (Tc=Channelfeed, Tf=Filefeed) und Write-Items (Wnb=Artikelpfad Artikel-Groesse) (siehe man newsfeeds). Die Datei readers.conf: Wir legen fest, wer alles mit welchen Rechten auf unseren Newsserver mit einem Newsreader zugreifen darf. Gegeben sei ein Netz 192.168.0.0/24, von dem aus jeder mit Schreib- und Leserechten auf alle Gruppen zugreifen darf. Inhalt der Datei readers.conf: auth "localhost" { hosts: "localhost, 127.0.0.1, stdin" default: "" } auth "homelan" { hosts: "192.168.0.0/24" default: "" } access "localhost" { users: "" newsgroups: "*" access: RPA } access "homelan" { users: "" newsgroups: "de.*,ffm.*" access: RP } Wie zu erkennen ist, liegt die Struktur in der Zuordnung von Hosts im Eintrag "auth" und den dazugehoerigen Permissions (Lesen/Schreiben/Gruppenliste). Fertig! Wir checken ein letztes Mal die Konfiguration und koennen unseren Newsserver zum ersten Mal starten: news@eumobil:~/etc> inncheck -pedantic /usr/local/news/db/active:0: mode 644, should be 664 news@eumobil:~/etc> chmod 664 /usr/local/news/db/active news@eumobil:~/etc> rc.news start Starting innd. Scheduled start of /usr/local/news/bin/innwatch. news@eumobil:~/etc> ctlinnd mode Server running Allowing remote connections Parameters c 10 i 50 (0) l 1000000 o 1011 t 300 H 2 T 60 X 0 normal specified Not reserved Readers separate enabled Perl filtering enabled Unser erster Artikel: Bei der Erstellung des active-Files im Verzeichnis ~news/db/ haben wir nur die Hierarchie de.* angelegt. Wir moechten aber auch die Hierarchie ffm.* vorhalten. Dazu ist uns die pgp-signierte Steuernachricht dienlich und wir lernen das Verarbeiten von Steuernachrichten. Methode 1: Wir deaktivieren das Rejecten von aelteren Newsartikeln, erstellen die Gruppe ffm.admin und feeden den Testartikel zu unserem Newsserver: news@eumobil:~/etc> cd ~/.gnupg/ news@eumobil:~/.gnupg> ctlinnd param c 0 news@eumobil:~/.gnupg> ctlinnd newgroup ffm.admin m news@eumobil:~/.gnupg> echo "ffm.admin Es spricht der Admin. (Moderated)" >> /usr/local/news/db/newsgroups news@eumobil:~/.gnupg> rnews < ffm.checkgroups.pgp In ~news/log/news.notice sollten wir einen Eintrag der Art Jan 1 19:59:17 eumobil controlchan[5553]: control_checkgroups, ffm.admin@arcor.de ffm.admin@arcor.de @030261320000000000000000010000000001@, eumel.gnuu.de, doit, 1 finden. Es wurde ein Mail an die Adresse "usenet" geschickt. Ueblicherweise ist das ein Mailalias auf den Account "root". In dessen Mailbox sollte ein Mail mit dem ausgefuehrten checkgroups angekommen sein: | Subject: checkgroups by ffm.admin@arcor.de # The following newsgroups were missing and should be added. Es folgen Anweisungen, welche Gruppen bearbeitet werden muessen und welche Eintraege ins newsgroups-file zu machen sind. Methode 2: Wir extrahieren die Gruppenliste aus dem Testartikel oder beziehen die Gruppenliste neu, fuegen diese der Datei ~/db/newsgroups hinzu und parsen die Liste an das Programm docheckgroups. Dessen Output verarbeiten wir wie im usenet-Mail aus Methode 1: news@eumobil:~/.gnupg> cd ~news/db/ news@eumobil:~/db> wget ftp://ftp.arcor.de/pub/news/ffm.checkgroups news@eumobil:~/db> grep "^ffm\." ffm.checkgroups >> newsgroups news@eumobil:~/db> grep "^ffm\." ffm.checkgroups | /usr/local/news/lib/docheckgroups | sh Die Erstkonfiguration unseren Newsservers ist beendet. Wir koennen auf die noch leeren Gruppen mit einem Newsreader zugreifen und Artikel zum Beispiel nach de.test posten. Diese werden in der Datei /usr/local/news/spool/outgoing/uucp.gnuu.de gebatcht. Wie geht es weiter? News Senden und Empfangen mit Newsx Newsx ist laut Beschreibung des Autors auf http://www.kvaleberg.com/newsx.html ein NNTP Client fuer Unix. Es kann zu einem entfernten Newsserver connecten, dort Artikel posten oder abholen und in lokale Batchfiles ablegen. Diese Batchfiles koennen wir hervorragend mit unserem INN verarbeiten. Wir besorgen uns die neuesten Sourcen von Newsx und uebersetzen diese unter Angabe unseres Newsverzeichnisses und den Include-Sourcen vom INN: # wget --passive-ftp ftp://ftp.kvaleberg.com/pub/newsx-1.6.tar.gz # tar xvfz newsx-1.6.tar.gz # cd newsx-1.6/ # ./configure --with-newshome=/usr/local/news --with-newsinclude=/usr/local/src/inn-2.3.5/include --with-rnews=/usr/local/news/bin/rnews # make # make install Das Programm sollte unter /usr/local/bin installiert sein. Als User "news" koennen wir nun unsere lokalen Artikel an einen entfernten Newsserver schicken, auf den wir Lese- und Schreibrechte haben. Sollte dieser Newsserver Username/Passwort verlangen, koennen wir Informationen in eine Datei ablegen. Inhalt der Datei /usr/local/news/auth.newsx: paul password Die Batchfiles finden wir in den Verzeichnissen /usr/local/news/spool/incoming und /usr/local/news/spool/outgoing. newsx rufen wir einfach von der Kommandozeile auf. Dazu verwenden wir das Batchfile uucp.gnuu.de unseres Newsservers und loggen uns mit unserem Account auf news.arcor.de ein: # su - news news@eumobil:~> newsx -a /usr/local/news/auth.newsx --groups 'de.test' --maxart "50" --max-path '999' uucp.gnuu.de news.arcor.de Wir moechten nur 50 Artikel aus der Gruppe de.test mit unbegrenzter Path-Laenge abholen (Default waere 1 Patheintrag) und unsere eigenen Postings verschicken. Die abgeholten Artikel befinden sich nun im incoming-Verzeichnis des INN. Mit rnews gelangen sie in unser Newssystem: news@eumobil:~> rnews -U Der Erfolg laesst sich in ~news/log/news und ~news/log/news.notice verfolgen. Nun koennen wir auch mehr Artikel aus mehr Gruppen abholen. newsx kann dabei recht lang aktiv sein. Wir begrenzen das Fetching auf 1500 Artikel pro Gruppe, holen nur eine Teilhierarchie hat und deaktivieren das Abweisen von Artikeln, die aelter als 7 Tage sind: news@eumobil:~> ctlinnd param c 0 news@eumobil:~> newsx -a /usr/local/news/auth.newsx --rnews --groups 'de.comm.*' --maxart "1500" --max-path '999' uucp.gnuu.de news.arcor.de newsx speichert alle verarbeiteten Gruppen und ihre letzte Artikelnummer in der Datei /usr/local/news/spool/inhosts/uucp.gnuu.de. Bei Bedarf laesst sich diese Datei leicht manipulieren (Gruppen loeschen, Nummerierung runtersetzen, damit Artikel nochmal geholt werden). Whats happened? Der Debugswitch -d verhilft dem Programm zu mehr Output, falls keine Fehler angezeigt, aber auch keine Artikel abgeholt werden. news@eumobil:~> newsx -a /usr/local/news/auth.newsx -d --rnews --groups 'de.comm.*' --maxart "1500" --max-path '999' uucp.gnuu.de news.arcor.de Das Programm meldet sich zum Schluss wie folgt: rnews status is 0 omitted 1 article already in spool, 0 as crossposts posted 0, fetched 39 articles in 66 groups at 21405 net cps News Senden und Empfangen mit UUCP Um unseren Newsserver mit dem Usenet zu verbinden, braeuchten wir einen IHAVE-Feed. Da dies fuer Leafsites mit NNTP unueblich ist, koennen wir unseren Newsserver mit einem UUCP-System verbinden, der die Artikel von einem anderen UUCP-System bezieht, z.B. uucp.gnuu.de. Dieser Rechner bekommt die Newsartikel vom Usenet, verpackt diese in Batchfiles, die mit dem Unix-to-Unix-Copy-Protokoll zu unserem Rechner verschickt werden und dort wieder an das dortige Newsystem verfuettert werden. Dieses Verfahren nennt man "Store-and-Forward"-Methode, da die Newsartikel auf verschiedenen Stationen zwischengespeichert werden, ehe sie ihr Endziel erreichen. Die Laufzeiten koennen so von einigen Minuten bis zu mehreren Stunden oder Tagen liegen. Die Einrichtung des UUCP-Feeds kann man der UUCP-FAQ entnehmen. Man benoetigt einen Account auf www.arcor.de, mit dem man das Produkt "UUCPNEWS" kaufen kann (siehe http://www.arcornews.de). Ueber die Konfigurationsseite des UUCP-Servers koennen wir uns eine Auswahl an Newsgruppen bestellen (siehe http://www.gnuu.de). Installation von Taylor-UUCP: Der User "uucp" ist bei SuSE-Linux schon vorinstalliert. Wir loeschen den User und legen ihm mit neuem Homedir an: # userdel -r uucp # useradd -u 10 -g uucp -d /usr/local/uucp -s /bin/bash -m uucp Wir beziehen die Sourcen zu Taylor-UUCP von einem GNU-Mirror und installieren das Programm nach /usr/local/uucp: # wget ftp://ftp.arcor.de/pub/gnu/uucp/uucp-1.07.tar.gz # tar xvfz uucp-1.07.tar.gz # cd uucp-1.07/ # ./configure --prefix=/usr/local/uucp --mandir=/usr/local/man # make && make install # mkdir /usr/spool # mkdir /usr/local/uucp/spool # chown uucp:uucp /usr/local/uucp/spool # ln -s /usr/local/uucp/spool /usr/spool/uucp Im Konfigurationsverzeichnis von Taylor-UUCP gilt es ein paar Angaben zum verwendeten Protokoll und anzurufenden System zu machen: # su - uucp uucp@eumobil:~> pwd /usr/local/uucp uucp@eumobil:~> mkdir conf uucp@eumobil:~> mkdir conf/uucp uucp@eumobil:~> cd conf/uucp Die Datei sys: Hier wird festgelegt, welches Hauptsystem zu welcher Zeit angerufen wird und welche Kommandos ausgefuehrt werden duerfen. Der Inhalt der Datei sys: call-login * call-password * system uucp.gnuu.de commands rnews command-path /usr/local/news/bin time any Die Datei port: Wir verwenden UUCP via TCP/IP und das ist der Inhalt der Datei port: port tcp type tcp Die Datei config: Diese Datei beinhaltet den Nodenamen unseres Systems, wie es beim gegenueberliegenden UUCP-System bekannt ist. Bsp: nodename 6913304010000 Die Datei call: Hier werden Accountinformationen fuer das anzurufende System gespeichert: uucp.gnuu.de 6913304010000 password Um rnews vom INN aus dem UUCP-System aufrufen zu koennen, brauchen wir dazu die richtigen Permissions: -r-sr-x--- 1 news uucp 230107 2003-12-31 16:36 /usr/local/news/bin/rnews Diese sollten von der INN-Installation eigentlich richtig gesetzt sein. Nofalls kann man sie per Hand nachtraeglich aendern: -D # chmod 4550 /usr/local/news/bin/rnews # chown news:uucp /usr/local/news/bin/rnews Defaultmaessig werden die Batches auf uucp.gnuu.de mit gzip gepackt. Im Verzeichnis /usr/local/news/bin/rnews.libexec gibt es ein entsprechendes unzip-Programm. Wenn andere Packer verwendet werden sollen (szip, bzip2), so muessen in diesem Verzeichnis aequivalente Entpacker installiert werden. Nun koennen wir die Newsartikel von uucp.gnuu.de abholen: # su - uucp # /usr/local/uucp/sbin/uucico -s uucp.gnuu.de Den Erfolg der Uebertragung koennen wir in folgenden Logfiles beobachten: /usr/local/news/log/news /usr/local/news/log/news.notice /usr/local/uucp/spool/Log UUCP-Uebertragung schlaegt fehl? Die Batches werden in ~uucp/spool/.Failed/ zwischengespeichert. Nach Beseitung des Fehlers koennen wir die Dateien erneut ins UUCP-System zur Weiterbearbeitung geben: uucp@eumobil:~/spool> mv .Failed/uucp.gnuu.de/D./* uucp.gnuu.de/D./ uucp@eumobil:~/spool> mv .Failed/uucp.gnuu.de/X./* uucp.gnuu.de/X./ uucp@eumobil:~/spool> ../sbin/uuxqt -s uucp.gnuu.de Eigene Artikel nach aussen senden. Bis jetzt haben wir nur Artikel aus dem Usenet empfangen und vielleicht Artikel auf unseren Newsserver gepostet, die wir jetzt in die Welt hinaus senden moechten. Diese Artikel befinden sich im Batchfile /usr/local/news/spool/outgoing/uucp.gnuu.de Wir rufen als User "news" sendbatch auf und uebergeben das Newsbatch dem UUCP-System auf unserem Rechner: -D # su - news # sendbatch uucp.gnuu.de Das Batchfile ist ohne Optionen nicht gepackt. Will man gzip oder andere Packer verwenden, erweitert man am besten das Programm sendbatch um einige Optionen unterhalb der Option -c) und speichert es als "my.sendbatch" ab, damit es von spaeteren Updates verschont bleibt: -g) COMP="; exec /usr/bin/gzip -9" ECHO="echo '#! gunbatch'" continue ;; -gbzip2) COMP="; exec /usr/bin/bzip2" ECHO="echo '#! bunbatch'" continue ;; -gszip) COMP="; exec /usr/bin/szip" ECHO="echo '#! sunbatch'" continue ;; Die aufgefuehrten Packprogramme muessen natuerlich an der Stelle auch installiert und fuer den User "news" ausfuehrbar sein. Weiterhin ist im Programm sendbatch auf Pfad des UUCP-Spools und Pfad zum Programm uux zu achten: UUSPOOL=/usr/local/uucp/spool UUX=/usr/local/uucp/bin/uux UUXFLAGS="- -r -n -gd" Inhalte der Dateien fuer andere Packer: ~news/bin/rnews.libexec/bunbatch: #! /bin/sh exec /usr/bin/bzip2 -d -c ~news/bin/rnews.libexec/sunbatch: #! /bin/sh exec /usr/bin/szip -d Die Dateien muessen als Shellscript ausfuehrbar sein: news@eumobil:~> chmod +x bin/rnews.libexec/*batch Uebergabe der Newsbatches ans lokale UUCP-System: news@eumobil:~> my.sendbatch -g uucp.gnuu.de Uebergabe der UUCP-Batches ans entfernte UUCP-System: -D # su - uucp uucp@eumobil:~> sbin/uucico -s uucp.gnuu.de uucico uucp.gnuu.de - (2004-01-02 01:30:33.41 24923) Calling system uucp.gnuu.de (port TCP) uucico uucp.gnuu.de - (2004-01-02 01:30:33.72 24923) Login successful uucico uucp.gnuu.de - (2004-01-02 01:30:35.85 24923) Handshake successful (protocol 't') uucico uucp.gnuu.de news (2004-01-02 01:30:36.23 24923) Sending rnews (D.0001) (553 bytes) Herzlichen Glueckwunsch, die ersten Newsartikel haben unseren Rechner verlassen. Daily Workers: Das Eintragen von Cronjobs zur immerwiederkehrenden Verarbeitung von Prozessen macht nicht wirklich Sinn, wenn unser Rechner nicht staendig laeuft und eine permanente oder "on demand" Verbindung zum Internet hat. news@eumobil:~> crontab -l # Taeglich nach Mitternacht INN-Report erstellen und zumailen 5 0 * * * cd $HOME/log; /bin/cat news news.notice | $HOME/bin/innreport -nohtml -f $HOME/etc/innreport.conf # Taegliches Expire (alte Overviews loeschen, Logfiles rotieren/packen) 5 3 * * * $HOME/bin/news.daily delayrm lowmark # Stuendliches Abholen und Senden der News mit newsx 55 * * * * /usr/local/bin/newsx -a /usr/local/news/auth.newsx --rnews --groups 'de.comm.*' --maxart "1500" --max-path '999' uucp.gnuu.de news.arcor.de Statt des letzten Cron-Eintrages kann es auch die UUCP-Variante sein: # Stuendliches Packen der Newspatches und Uebergabe ans UUCP 55 * * * * $HOME/bin/my.sendbatch -g uucp.gnuu.de Croneintrag fuer UUCP: uucp@eumobil:~> crontab -l # Stuendliches Einloggen am UUCP-Server udn Abarbeitung der Batches 05 * * * * $HOME/sbin/uucico -s uucp.gnuu.de Wenn der Rechner nur zeitweise online ist, empfiehlt sich der Aufruf der Programme in Startdateien des pppd (/etc/ppp/ip-up) oder die manuelle Ausfuehrung. Schmerzbehandlung: Die folgenden Fehlerbilder sind entweder bei der Installation aufgetreten oder der INN-FAQ entnommen (siehe Linksammlung am Ende). Einige Fehler wurden auch aus news:de.comm.software.newsserver und news:news.software.nntp analysiert und die Loesung hier aufbereitet. Fehler: INN startet nicht, Im Logfile steht "cant bind..." innd hat die Permissions "news:news" und kann sich nicht an den priveligierten Port 119 binden. Als Hilfsprogramm gibt es "inndstart", welches mit s-bit fuer User "root" installiert sein soll. news@eumobil:~/bin> ls -l inndstart -r-sr-x--- 1 root news 139942 2004-01-03 13:30 inndstart Im Gegensatz kann INN nicht als User root gestartet werden. Der Logeintrag dazu waere in news.crit: | inndstart: ran by UID 0, who isn't news (9) Fehler: Die Logfiles in ~news/log/ bleiben leer. INN startet nicht und die Ursache kann nicht gefunden werden. In der Konfigurationsdatei des syslogd (/etc/syslog.conf) fehlen die Eintraege fuer news, oder sie werden falsch/doppelt vergeben. Die Logfiles muessen die Permissions "news:news" haben. syslogd ist nicht neu gestartet worden (killall -HUP syslogd) Fehler: INN laeuft, nimmt aber keine Artikel an. Im Logfile findet sich die Meldung "innd: SERVER cant store article" Moegliche Ursache ist ein Konfigurationsfehler in der storage.conf. Der hereingefeedete Newsartikel kann keiner Storage-Klasse zugeordnet werden. Bei der Verwendung von CNFS sollt der Output von cnfsstat ungefaehr so aussehen: news@eumobil:~/log> cnfsstat -a Class DE for groups matching "de.*" Buffer a1, size: 488 MBytes, position: 57.0 MBytes 0.00 cycles Newest: 2004-01-03 16:51:00, 0 days, 0:15:05 ago Oldest: 2004-01-01 21:50:54, 1 days, 19:15:11 ago Class RE for groups matching "*" Buffer a2, size: 488 MBytes, position: 142 kBytes 0.00 cycles Newest: 2004-01-03 13:50:51, 0 days, 3:15:14 ago Oldest: 2004-01-01 19:59:17, 1 days, 21:06:48 ago Eine weitere Moeglichkeit sind fehlende Teile des Newsspools (Partitionen aus cycbuff.conf nicht gemountet oder fuer User "news" nicht schreibbar), CNFS-Buffers moeglicherweise korrupt (muessen neu angelegt werden). Fehler: INN startet nicht, im Logfile steht "SERVER internal no control and/or junk group". In ~news/db/active fehlen die Gruppen junk und/oder control. Das sind interne Verwaltungsgruppen, die der INN dringend benoetigt: control 0000000000 0000000000 n control.cancel 0000000000 0000000000 n control.checkgroups 0000000000 0000000000 n control.newgroup 0000000000 0000000000 n control.rmgroup 0000000000 0000000000 n junk 0000000000 0000000000 y Fehler: Nach dem Abholen der News mit newsx/uucp werden die Batches nicht an den INN verfuettert, INN laeuft aber. Wenn die Batches schon in ~news/spool/incoming liegen: news@eumobil:~> rnews -U Fehlerhafte Batches oder Batches, die von INN abgelehnt werden wegen eines Fehlers, werden nach ~news/spool/incoming/bad verschoben. Nach Beseitigung des Grundes, koennen die Batches wieder nach incoming verschoben werden. Fehler: news.daily wird taeglich oder nach Rechnerstart aufgerufen. Trotzdem wird die History immer groesser und groesser. Beim Expire wird eine vollstaendige Kopie der Historie in ~news/tmp erstellt. Dafuer sollte dann auch Diskspace auf der Partition frei sein oder man expired auf einer anderen Partition, auf der genug Speicherplatz frei ist: news@eumobil:~> news.daily delayrm lowmark expdir=/usr2/tmp In der Datei ~news/etc/expire.ctl sollte der Wert fuer remember auf einen ueberschaubaren Zeitraum stehen: /remember/:7 Dies stellt NICHT die Vorhaltezeit der Artikel dar sondern der Zeitraum, in der ein Artikel mit derselben Message-ID dem Server nochmals angeboten werden kann und der INN diesen Artikel dann annimmt, sofern sich der Artikel mit der Message-ID nicht schon im Spool befindet. Artikel, die expired oder gecancelt sind, werden durch einen Sperreintrag in der History noch x (remember) Tage belegt, damit sie nicht erneut eingeliefert werden koennen: news@eumobil:~> grephistory '' /dev/null Fehler: Das Abholen der Gruppenliste beim ersten Connect mit einem Newsreader schlaegt fehl. Offenbar sind gar keine Newsgruppen vorhanden. Konfigurationsfehler in der Datei ~news/etc/readers.conf. Beim Connect vom Clientrechner gibt es keine matchende Rule fuer den Readeraccess. Fehler: Die Message-ID unserer Newsartikel endet auf ".local" oder einen anderen internen Rechnernamen, der weltweit nicht eindeutig ist. In der Datei ~news/etc/readers.conf ergaenzen wir in der access-Rule fuer unser Heimnetzwerk die Zeile "domain" mit dem FQDN: access "homelan" { users: "" newsgroups: "de.*,ffm.*" access: RP domain: "paul.news.arcor.de" } Fehler: Der Path-Eintrag unserer Newsartikel endet auf ".local" oder einen anderen internen Rechnernamen, der weltweit nicht eindeutig ist. In der Datei ~news/etc/inn.conf ergaenzen wir die Zeile "pathhost" mit dem FQDN: pathhost: paul.news.arcor.de Fehler: Ich habe kein FQDN. Was ist das eigentlich? Der FQDN, Fully qualified domain name, ist der vollstaendige Name unseres Rechners, der weltweit eindeutig sein muss. Solange wir nur News im eigenen Netz zu Hause lesen und so keinen Kontakt zum Internet herstellen, genuegt ein Rechnername aus der Topleveldomain ".local" oder wir koennen den Rechnern nennen wie wir wollen. Wenn wir unseren INN mit dem Usenet verbinden, brauchen wir aber den FQDN zur Bildung eines gueltigen Path-Namens und zur Generierung eindeutiger Message-IDs. Arcor hat zur Verwendung eines eigenen FQDN den Namensraum unterhalb von "news.arcor.de" reserviert. Wenn wir den Benutzernamen "paul" haben, heisst unser FQDN "paul.news.arcor.de". Fehler: Alle mit newsx/uucp hereingeholten Artikel werden zwar in den Spool einsortiert, aber auch gleichzeitig ins Outgoing gebatcht. Variante1: Wir pathexcluden fuer den Outgoing Feed den Path fuer den Incoming Feed: uucp.gnuu.de/news.arcor.de\ :*,!junk,!local.*,!control.*\ :Tf,Wnb:uucp.gnuu.de An den Feed zu uucp.gnuu.de werden keine Artikel gesendet, die uucp.gnuu.de (der Sitename selber) und news.arcor.de im Path haben. Variante2: Da sich der Path der externen Feeds auch mal aendern koennen, koennen wir den Eintrag in newsfeeds um OOriginator-Flag ergaenzen. Postings an diesen Feeds muessen dann einen X-Trace-Header besitzen, der im ersten Feld mit dem Originator-Eintrag matcht: uucp.gnuu.de/news.arcor.de\ :*,!junk,!local.*,!control.*\ :Tf,Wnb,O*paul.local:uucp.gnuu.de Fehler: Es werden keine Artikel rausgefeedet. Das Batchfile in ~news/spool/outgoing/uucp.gnuu.de bleibt leer. news@eumobil:~> ctlinnd flush uucp.gnuu.de Wenn danach die Datei immer noch leer bleibt, sollte die Config von INN neu geladen werden: news@eumobil:~> ctlinnd reload all configs Bleibt auch dann das Schreiben von Postings in die Batchdatei aus, sollten wir pruefen, ob der Eintrag in der Datei newsfeeds stimmt. Da wir in inn.conf den Eintrag "nntplinklog: true" gesetzt haben, sollten in ~news/log/news alle Sites aufgelistet sein, an die der Artikel gefeedet wird: Jan 3 22:22:13.335 + not-for-mail 533 uucp.gnuu.de Fehlt der Sitename zum Outgoing Feed, ist der Fehler in der Datei newsfeeds zu suchen. Fehler: Nach einem Rechnercrash sind alle Newsgruppen scheinbar leer. Die Newslogs melden keine Fehler. Overviews beschaedigt, Artikelnummerierung fehlerhaft: news@eumobil:~> makehistory -O -x -F news@eumobil:~> ctlinnd renumber '' Fehler: Nach einem Rechnercrash sind nicht nur die Newsgruppen leer oder es erscheinen andere Artikel, auch neue Artikel werden nicht mehr angenommen wegen "Can't store history file...". History und Overviews sollen neu erstellt werden: news@eumobil:~> ctlinnd throttle 'rebuild history' news@eumobil:~> cd db news@eumobil:~/db> rm history* news@eumobil:~/db> makehistory -F -b -f history -I -O news@eumobil:~/db> makedbz -i -f history news@eumobil:~/db> ctlinnd go 'rebuild history' Fehler: Die mit einem Newsreader abgerufenen Artikel passen nicht zu den in den Headern erwaehnten Verfassern, Gruppen und Subjects Overviews beschaedigt (vor allem bei ovdb). news@eumobil:~> makehistory -O -x -F Fehler: Benutzer sollen per Username/Passwort authorisiert werden. Irgendwie funktioniert das nicht. Wir benoetigen eine Textdatei mit den Benutzernamen und Passwoertern der User. Dabei ist Feld 1 der Benutzernamen und Feld 2 das verschluesselte Passwort. Die Felder sind durch Doppelpunkt getrennt: paul:YcSJuJPw7UsNM Verschluesselte Passwoerter lassen sich leicht aus Klartextpasswoertern mit einem Programm erstellen, welches die Routine crypt() enthaelt, z.B.: http://home.arcor.de/cgi-bin/crypt.pl?password=foo Wir benoetigen ausserdem 2 Eintraege in der Datei readers.conf: auth remote { auth: "ckpasswd -f /usr/local/news/etc/nnrpd.passwd" } access remote { users: "*" newsgroups: "*" access: RP } Fehler: Unser Rechner ist zu klein/zu alt/zu schwach. INN soll auf einen neuen Rechner umziehen. INN wird auf dem neuen Rechner wie in der FAQ neu installiert. In der Datei ~news/etc/inn.conf setzen wir ausserdem: xrefslave: true In der Datei ~news/etc/incoming.conf erlauben wir das Feeden vom alten Rechner: peer oldinn { hostname: "paulold.paul.local, 192.168.0.132" } Wir deaktivieren das Abweisen von Artikeln, die aelter als 7 Tage sind: news@eumobil:~> ctlinnd param c 0 Auf dem alten Rechner verarbeiten wir jetzt alle Artikel in ein Batchfile und feeden das an den neuen Rechner. Durch den xrefslave-Eintrag bleibt uns die Artikelnummerierung erhalten: news@eumobil:~> cd db news@eumobil:~> perl -ne 'chomp; ($a,$b,$_) = split " "; print "$_\n" if $_' history \ | tr . / > ~/spool/outgoing/list news@eumobil:~> innxmit paulneu list Wenn alle Artikel gefeedet sind, deaktivieren wir den "xrefslave"-Eintrag in der inn.conf uns starten INN neu. (to be continued) Links: INN-Homepage http://www.isc.org INN-FAQ http://www.eyrie.org/~eagle/faqs/inn.html INN4Windows http://members.verizon.net/~vze4y7p6/inn/ Taylor-UUCP http://www.airs.com/ian/software.html NEWSX http://www.kvaleberg.com/newsx.html