| ||||||||||||||||||||||||||||||||||||||||
BinkD Success Story
Nachdem DSL Ende März 2003 bei mir zu Hause gelegt worden ist, habe ich
nach anfänglichem Versuchen schnell eine HTTP-BBS aufzubauen, das Handtuch geschmissen und mich zunächst anderen Projekten gewidmet, u.a. die Aktivierung von BinkD auf meinem NT-Rechner
BinkD Quellen Ein passendes BinkD Paket für Win32 habe ich schnell gefunden. FileBases durchsuchen oder Google-Search. Für mich unter Win32 habe ich das Paket Ein weiterer Link für Binaries unterschiedlichster Betriebssysteme ist zu finden unter: Update 14.8.05 v0.9.6 http://ambrosia60.dnsalias.net/files/div27/i-util/BINKD096.ZIP - BinkD v0.9.6 Sources http://ambrosia60.dnsalias.net/files/div27/i-util/BND32096.ZIP - BinkD v0.9.6 Win32 executable http://ambrosia60.dnsalias.net/files/div27/i-util/BNDMAN.ZIP - BinkD HTML manual Update 14.8.05 v0.9.7 http://ambrosia60.dnsalias.net/files/div27/i-util/BINKD097.ZIP - BinkD v0.9.7 Sources http://ambrosia60.dnsalias.net/files/div27/i-util/BND32097.ZIP - BinkD v0.9.7 Win32 executable Update 14.8.05 v0.9.8 http://ambrosia60.dnsalias.net/files/div27/i-util/BINKD098.ZIP - BinkD v0.9.8 Sources ftp://cvs.happy.kiev.ua/pub/fidosoft/mailer/binkd/ - Release versions (by Pavel Gulchouck 2:463/68) Versionen bis einschl. 0.99 Eine Anmerkung noch zu den Sources: Die Sources sind ein wenig unübersichtlich. Die neueste Version aus obigem FTP Verzeichnis liefert eine Version 0.9.7 als letzte "stable version". In einigen anderen Quellen sind Hinweise auf eine Version 0.9.8, 0.9.9 und sogar auf Versionen 1.0x. Ein stable 0.9.9 Paket liefert aber keine Win32 msv Version .... Update Binaries: 17.9.08 v1.0a-515 BinkD v1.0a-515 Win32 binary Versionen: OS/2 (v0.9.3 - v0.9.9a), Win32 (v0.9.3 - v1.0a-515), *NIX (v1.0-snapshot) Nachdem ich beide Pakete ausgepackt hatte, waren 2 Files wesentlich:
BinkD Grundkonfiguration Die BinkD.CFG habe ich einmal von oben nach unten durchgearbeitet und hatte somit schon ein laufendes BinkD Outbound System .... Somit war die 1. Hürde geschafft. ;-) Mittels DirectUpdate (DynamicIP Updater) hatte ich bereits 2 DNS Namen aktiviert: ambrosia60.dyndns.org und ambrosia60.dnsalias.net. Meinem Hub habe ich dann einen Nodelist-Line Update-Request geschickt, er möge doch bitte die Änderung in die Nodelist übernehmen. Von beiden Addressen habe ich die "stabilere" gewählt:
,1120,AMBROSIA60.dnsalias.net,Offenbach,Ulrich_Schroeter,49-69-83003542,9600,
CM,XA,MO,X75,H16,V32T,VFC,V34,IBN,U,RPK,ENC
Am darauffolgenden Freitag war die Änderung dann in der Nodelist aktiv.Meinen Linkpartnern habe ich eine Netmail zukommen lassen, sie möchten doch bitte ihre BinkD Line Einstellung für mein System überprüfen und ggf. einen Eintrag für ambrosia60.dnsalias.net mit unserem Sessionpassword zu aktivieren. In den meisten Fällen ging das auch Problemlos. In einigen Fällen zeigte es sich aber, dass BinkD beim Aufbau der Test-Session Password Errors meldete... Wie sich herausstellte, behandelt BinkD Sessionpasswords case-sensitive, unterscheidet also ob Passworte in Gross- oder Kleinbuchstaben geschrieben werden .... anders als bei den meisten regulären FTN-Mailern .... BinkD Nodelist Anders wie bei regulären FTN-Mailern, kann BinkD nicht auf eine Standard St.Louis-Format Fidonet Nodelist zugreifen, sondern benötigt ein spezielles Format in der die Einträge in etwa wie folgt gelistet sind: Node <aka> <dns-host or ip[:port]> - <aka> reguläre FTN-AKA i.e. 2:244/1120 <dns-host or ip:port> DNS-Name oder IP-Addresse, optional Port wenn nicht Standard 24554 <-> Steht für ein nicht vorhandenes PasswordIn der FileBase von meinem Uplink (RC24, Werner Blatt) habe ich in dem FileEcho I-BINKD eine BINKD-Nodes Nodeliste gefunden, die wohl auch ständig aktuallisiert wird. Mittels Include Anweisung habe ich diese Nodeliste dann in die BINKD.CFG _vor_ den eigenen manuellen Link-Eintragungen eingebunden (nachfolgende Anweisungen überschreiben vorherige Anweisungen in der BINKD.CFG). Somit konnte ich nun die meisten meiner Link-Partner als IP-Nodes identifizieren, da BinkD nun fortan beim Scanning entsprechende Nodes auflistete. Beim Outbound Handling musste ich allerdings noch die regulären Binkley Modem- und ISDN-Lines ein wenig umkonfigurieren, so dass diese Lines ab sofort nicht mehr meine Link-Partner anwählten, sondern die Verbindung der BinkD Line überliessen. Eine Konfiguration der Modemflag-Settings für das Nodelistflag IBN vor die entsprechenden Modemflags und ISDN Flags mit höherer Priorität schaffte hier Abhilfe: Fastlist Config: [...] TypeDef X75 32 TypeDef IBN 128 Binkley XE Modem Config: BitType Modemtrans 128 / /IP <-- Verhindert die ISDN-Anwahl wenn Node auch IBN Flag hat ModemTrans 32 ATD/ /X75 ModemTrans 64 / /UNK Modemtrans 16 / /MODEMJetzt waren die Grundvoraussetzungen geschaffen, dass die BinkD Line sich ähnlich der regulären FTN-Mailer verhielt - liegt Mail für ein System an, das unter der entsprechenden Nummer auch ein IBN Flag in der Nodelist gelistet hat, wird primär die IP-BinkD-Line zur Versendung des Pakets benutzt. BinkD.TXT Nodelist Update Die BINKD.TXT Nodelist kann entweder über das FileEcho I-BINKD (bei allen grösseren FileServer Systemen innerhalb R24) bezogen werden, oder man erstellt sich die Datei BINKD.TXT aus der jeweils aktuellen Raw-St.Louis-Nodelist selbst. Hierzu gibt es das PHP Script: BNLPHP10.ZIP binkd_nodelister.php version 1.0 (PHP), (c) 2007 by Ulrich Schroeter BinkD FileRequest Jetzt komme ich zu den langwierigeren Konfigurations Problemen. Da BinkD selbst keine direkte FReq. Unterstützung eingebaut hat, muss man sich eines FileRequestProzessors bedienen der mittels eines BinkD "EXEC" Aufrufs nach dem SRIF Standard aufgerufen werden kann. Da ich Allfix in meinem FTN-System für die FileEcho Unterstützung eingebaut habe und Allfix in der Version 5.13 auch einen eingebauten FReq.Prozessor besitzt, lag es nahe Allfix dafür heranzuziehen. Für Win32 bin ich davon ausgegangen, dass eine Win32 Version benötigt wird. Also Allfix/Universal. Also Allfix/Universal ausgepackt, Setup aufgerufen. Freq.Prozessor Einstellungen konfiguriert. In BINKD.CFG eine entsprechende Zeile: exec "!e:\\bink\\line.22\\freq.cmd *S" *.reqeingetragen und die FREQ.CMD entsprechend erstellt: [Inhalt FREQ.CMD] q: cd\allfix SET ALLFIX=Q:\Allfix allfix Rp -SRIF %1Beim Freq. wurde zwar die *.REQ Datei erkannt und der Exec Aufruf gezündet, aber eine Antwort-Datei *.RSP wurde nicht erstellt ... Mittels Echo Debug Zeilen war ersichtlich, dass Allfix/Universal zwar gestartet wurde, aber Allfix/Universal ausser der Aufrufzeile nichts ins Allfix.Log schrieb ... Nachdem ich nun mit meinem Uplink 'zig Versuche unternommen hatte den Freq. zum Laufen zu bekommen, hatte ich dann einen manuellen Aufruf mit einer SRIF-Datei, die ich unter Novell aus dem Binkley-Outbound (!) wiederhergestellt hatte h:\bink\out\out\00f40457.srf durchgeführt. Und siehe da, Allfix/Universal erwartete einen Tastendruck, weil ich für Allfix/Universal noch keinen Key hatte ... ;-( Key - geht doch einfach - einfach unter www.allfix.com einen Allfix/Universal generieren lassen ... DENKST'E Für WWW.ALLFIX.COM existieren keine IP-Addressen mehr ... ;-( Die Domain ALLFIX.COM ist zwar noch registriert, aber sämtliche DNS-records sind entfernt ... ;-( Weder eMail noch HTTP Zugang sind Online ... Also war's nichts mit Registrierung .... OK. Nicht verzagen ... Der Versuch mit der entsprechenden DOS Version führte zum gewünschten Ergebnis ... Anschliessende Online-Test-Frequest-Versuche mit der DOS Version lieferten jeweils die gewünschten Files .... Hint: Um Allfix einen schnelleren Zugriff auf die FileBase zu ermöglichen, sollte man statt nur der Liste der für den Freq. unterstützten Verzeichnisse ein Fixutil Index durchführen. Der entsprechende Befehl für den Aufruf zur Indexerstellung während der regulären Fileverarbeitung lautet: fixutil CompileRequestIdx Hint2: die Domain ALLFIX.COM ist Offline. Bob Seaborn (1:140/12) hat aber noch einen Mirror der Allfix WebSite unter http://www.nwstar.com/allfix am Laufen. Jeddoch funktionierten bei mir die Menüs nicht und auch ist keine Registrierung möglich ... ;-( [Update 19.9.08] www.allfix.com wird nach 139.142.226.133 aufgelöst, aber die Seite bleibt leer ... :( Registrierungs Link (aus den Sources des NWSTAR.COM links): REGISTRATION SITES In der Zwischenzeit arbeite ich mit dem Filerequest-Processor: VIREQ/32
Da aber diese Version unter Win32 beim CDP Function Request ein Problem aufweist, habe ich mir selbst ein VIREQ Derivat (VIREQCLP) zusammengebastelt, dass nun im Einsatz ist. Für die Filebase Index Erstellung benutze ich VIIDX32.EXE aus obigem Paket.
Die modifizierte Aufruf Batch für BinkD (CDP-Node aware): [Inhalt FREV.CMD] q: cd\allfix copy e:\bink\line.22\binkd.cfg e:\bink\line.22\sik_cfg\binkd.cfg copy %1 e:\bink\cdp\dbg rem allfix Rp -SRIF %1 rem q:\allfix\vireq32.exe %1 q:\allfix\VIREQCLP.EXE %1 e: BinkD DynamicIP Alternativen Wie weiter oben beschrieben hatte ich mit dem Produkt DirectUpdate angefangen. Nachdem BinkD lief, ich auf der Kiste auch Webserver aktiviert hatte, musste ich immer wieder feststellen, dass sich die IP-Addresse in Abständen von teilweise 10 min. regelmässig änderte ;-( Teilweise änderte sich die IP gerade dann, wenn kurz zuvor die letzte Änderung an die DNS-Server weitergereicht wurden. So entstanden immer wieder "Löcher" von Nicht-Erreichbarkeit, über den ganzen Tag hinweg. Das wollte ich nicht stehen lassen. Da ich direkten Zugriff auf einen W2K-DNS-Server im Internet habe, der Dynamic IP Änderungen rein theoretisch bearbeiten könnte versuchte ich mich zunächst damit DirectUpdate auf einen "Generic W2K" Update einzurichten. Die angeforderten Parameter überforderten mich aber, so dass ich diesen Versuch sehr schnell fallen liess. Von anderer Seite erhielt ich den Tip bei "dnsalias.net" mal zu schauen ... Die hätten die 10 min. Sperre nicht, die z.Bsp. Dyndns.Org und Dnsalias.Net haben ... Also Anmeldung bei "dnsalias.net" und laut Client Liste, Unterstützung des DirectUpdate's Aktivierung von "dnsalias.net" unter DirectUpdate. Aber, was ich auch konfigurierte, ein Update kam nicht zustande .... ;-( Das war 2003. Nach der Exkursion via Gnudip und fidosoft.de, letzteres wurde 2005 gekapert, landete ich doch wieder DirectUpdate und Dnsalias.net. [Da Deaktivierung von Perl, gilt die gesamte nachfolgende Sektion nicht mehr]
Bei "dnsalias.net" stiess ich dann auf GNUDip ... ein Perlscript getriebener
Client für Win32. Auch gibt es Clients für OS/2 und Linux ... ;-)
Also Reaktivierung bei "dnsalias.net" Installation des Win32 GNUDip Clients ... Nun hatte der GNUDip Client es aber auch in sich ... Der erste Perlaufruf (config.bat) lieferte einen GPF ;-( Der zweite Aufruf führte dann zur interaktiven Konfiguration. Der manuelle Aufruf von gdipc.bat lieferte aber nur eine Parameterliste ... Also Parameter gesichtet, welche benötigt werden könnten. Der Parameter -g lieferte als Description: Client is behind a gateway. Genau das ist bei mir der Fall ... aber keinen Hinweis darauf, was es genau damit auf sich hat ... Im weiteren Verlauf der Tests stiess ich auf den Aufrufparameter -g sendport:recvport ] aber wieder kein Hinweis was es nun mit den Ports auf sich hat ... In dem File CLIENTS.HTML das im Win32 Archiv enthalten war fand ich ganz am Ende nachfolgenden Hinweis: "You must configure the NAT box to redirect some external UDP port to a UDP port on the internal machine running the client. You provide these port numbers to the client using the -g option. This option will also cause the client to request the GnuDIP server to send the external address of the NAT device (which the server sees as the other end of the client connection) back in the reply to the update request."Damit hatte ich nun einen Bezug, dass das Problem ein Firewall-Problem war. Der Hinweis auf den UDP Port "sagte" mir was. In der Firewall-Konfiguration lassen sich TCP oder UDP Ports von Extern nach Intern "mappen". Die Protocol Infoseite auf dnsalias.net http://www.dnsalias.net/html/protocol.html liefert dann wiederum einen Hinweis auf den Standard Port der normalerweise dafür benutzt wird: Port 3495 Nachdem ich im Firewall die Translation "Orig UDP Port 3495 Reciving UDP Port 3496" aktiviert hatte, meldete der GNUDip Client erstmals einen Update der aktuellen IP Addresse beim DNS-Server ... ;-) Da der Perlscript bislang noch durch manuellen Aufruf in einer DOS-Box gestartet wurde, verfiel ich auf die Idee, diesen Dienst zu einem Service umzustellen. Im NT4 Resource-Kit gibt es ein Tool SRVANY mit dem man beliebige Programme als Dienst einrichten kann. Als Application Parameter kann man so ein Script starten, das letztendlich auch den GNUDip Client startet. Ein Problem bleibt aber noch: Stoppt man nun diesen Service bleibt das Perlscript weiterhin aktiv! Eine Modifikation des Perlscripts in der Loop-Schleife zusätzlich nach einem Semaphore-File Ausschau zu halten, und wenn das Semaphore-File existiert die Loop zu beenden, löste das Problem. Nun konnte der Service mittels eines weiteren Scripts StopServ.CMD gestoppt werden und der Perlscript nach endlicher Zeit auch beendet werden:
GNUDIPS.CMD (modifizierte GNUDIP.BAT für NT4 Service)
zusätzlich (relativ am Anfang des Scripts bei den Variablendeklarationen)
my $semap = 'C:/gdipc/gdipcs.txt';
in der Schleife:
# repeat forever ...
while (1) {
. . .
# wait before spawning again
Win32::Sleep($wait);
# kill previous interation if still running
$process->Kill(255);
zusätzlicher Block (hier wird die Semaphore-Datei überprüft, bei Vorhandensein Loop-Exit ...)
if (open(SEMAP,"$semap")) {
close(SEMAP);
exit;
} else {
close(SEMAP);
}
Die Datei StopServ.CMD enthält nachfolgende Zeilen:
NET STOP GNUDIP Stoppt Service <Servicename> unter NT4 echo.>>C:\GDIPC\gdipcs.txt Semaphore-Datei zum Beenden des Perlscripts anlegen Beim NT4 Reboot würde nun aber die Semaphore-Datei "stehen" bleiben ... Aus diesem Grund muss der Service-Start auch mit einer Prozedur gestartet werden. Hier die Prozedur für den Start des GNUDip Services: SERVICE.CMD c: cd\gdipc if not exist gdipcs.txt goto skipd del gdipcs.txt :skipd gdipcs.cmd -f I:\.GnuDIP2.txt -g 3495:3496 -d 60 -l i:\logfiles\gdipc.log -w 1 exitDer Parameter -d 60 bewirkt nun, dass der Client jede Minute eine Überprüfung der IP Addresse durchführt und ggf. die Addresse beim DNS Server updatet. Nachdem dieser Script eingerichtet und gestartet wurde ändert sich die IP Addresse nurmehr 1x täglich ... ;-) Success. [GNUDIP ersetzt durch DynamicUpdate] BINKD Links BinkD Documentations BinkD FAQ BinkD man page BinkD binaries (Link 1) (binkd.grumbler.org) BinkD binaries (Link 2) (www.dreamlandbbs.com R50) BinkD User Guide (incl. complete Cfg description) Eingesetzte Software (Updated Sept. 2008) FTN-System unter einem Windows 2000 Server Maximus FileBase (DOS), Background Maintenance auf einem DOS-PC Windows 2000 Server Apache 2.0.45, PHP 4.x (Win32) BinkD v0.9.7 (Win32) (older version) BinkD v0.9.9 (Win32) (older version) BinkD v1.0a-515 (Win32) (newest version) (binkd_nodelister.pl v1.0 (Perlscript), (c) 2002 by Jerry Schwartz and Write by Night) BNLPHP10.ZIP binkd_nodelister.php version 1.0 (PHP), (c) 2007 by Ulrich Schroeter VIREQCLP/16 Filerequest-Processor VIREQ/32 (c) 1998-2001 by Volker Imre, Derivat (c) 2008 by U.Schroeter DirectUpdate v4 Win32, Dynamic IP DNS-Update, Shareware Ulrich Schroeter, Mai 2003 Updated: Mai 2008
| ||||||||||||||||||||||||||||||||||||||||
