Sollte Das alles trotz meiner Anleitung noch nicht auf Anhieb funktionieren, so gibt es noch diverse Möglichkeiten, einen Fehler aufzuspüren.
Wichtigstes Tool hierzu ist das Programm ifstat, welches anzeigt,
welche Pakete für welche Adresse bereit liegen. Hier sollte man sich
nicht wundern, wenn die Pakete nach dem Start von ifpoll plötzlich
geschrumpft sind, das liegt nämlich daran, daß die Mails dann zu
ZIP-Files gepackt wurden.
Hier ist es sinnvoll, das Debug-Level von rfc2ftn in
/etc/smail/transports bzw. im /etc/sendmail.cf
hochzusetzen. Hierzu gibt man im entsprechenden Netz den zusätzlichen
Parameter -v bei rfc2ftn an (ggf. auch mehrfach, dann wird
das Debug-Level entsprechend höher, ich verwende meist
-vvvvvvvvvvvvvvvvvvvvv oder so). Um die Debug-Meldungen dann
wirklich in die Hand zu bekommen, schicke ich die Mail einfach mit
einer Kopie an eine nicht existente Adresse und bekomme dann den
Rückläufer mit sämtlichen Debug-Meldungen. Kommt der Rückläufer
überhaupt nicht, so kann es durchaus sein, daß irgendwelche
Permissions nicht stimmen und das System einfach wartet (man sieht das
daran, daß noch sendmail und rfc2ftn als Prozesse
laufen). Dann findet sich das aktuelle Debug-File in
/var/spool/smail/msglog. Unter /var/spool/smail
findet man dann auch die liegengebliebenen Messages. Bei Verwendung
von Sendmail werden die Log-Meldungen dagegen per syslog ins
Syslogfile geschrieben, während die liegengebliebenen Messages in
/var/spool/mqueue landen.
Analog zum Vorgehen bei Mail kann man auch bei News verfahren. Hier
gehe ich gewöhnlich so vor, daß ich in
/usr/lib/newsbin/batch/viafido (cnews)
bzw. /usr/local/lib/news/send-fidogate (INN) die
entsprechenden -v's einbaue und dann an die entsprechende Zeile
ein 2> /tmp/fgate.out anhänge, was dazu führt, daß stderr
nach /tmp/fgate.out umgeleitet wird, das ich mir dann
anschauen kann.
Ansonsten sollte man bei cnews zwischen dem Aufruf von newsrun
und run-batch nachsehen, ob der Artikel in
/var/spool/news/out.going/*/togo aufgelistet wurde und dort
anschließend auch wieder gelöscht wurde. Manchmal (je nach
cnews-Version) werden die Artikel auch in
/var/spool/news/in.coming zwischengelagert.
Bei INN sollten die Artikel sofort ins Newssystem aufgenommen werden,
und damit auch direkt im File /var/spool/news/out.going/*
erscheinen. Nach dem send-fidogate sollten sie dort verschwinden
und im Fido-Outbound landen.
Weiterhin sollte man sich alle vorhandenen Logfiles ansehen:
/var/spool/smail/log/logfile
/var/log/mail
/var/lib/news/log.*
/var/lib/news/batchlog.*
/var/lib/news/errlog.*
/usr/local/lib/news/log
/usr/local/lib/news/errlog
/var/log/inn/*
/var/log/fnet/log
/var/log/fnet/ifmail
/var/log/fnet/iflog
/var/log/fnet/ifdebug
Um die Korrektheit erstellter Pakete zu erkunden oder Probleme in
bestehenden Paketen zu finden, enthält FidoGate das Programm
pktdebug. Braucht man mehr Informationen, so sollte man sich das
DOS-Programm Inspect besorgen, welches problemlos in der Dosemu läuft
und wenn man die Verzeichnisse entsprechend freigibt und die Dosemu
dann als User uucp startet, dann kann man die .pkt-Files und
Archive sogar verändern.
Hängt CNews komplett, so bleibt einem nur ein Debugging der diversen
cnews-Shell-Scripts. Hierzu sollte man in das jeweilige Skript ein
"set -xv" am Anfang einbauen, welches genau ausgibt, welche
Zeilen des Skripts in welcher Reihenfolge und mit welchen Parametern
aufgerufen werden. Für weitere Informationen dazu empfehle ich die
Manpage der bash.
Falls nur das Posten von News-Artikeln nicht klappt, kann man auch mal
versuchen, mit Pnews aus dem Paket trn direkt zu
posten. Selbiges ist nämlich im Gegensatz zu tin ein einfaches
Shell-Skript, bei dem die Fehlermeldungen von cnews immerhin so lange
stehen bleiben, bis man sie gelesen hat (bei tin werden die
direkt wieder vom Menü überschrieben).