UKA_PPP in RFC/Client-Box

[Michael Heydekamp]

Joachim Merkel <j.merkel at tbx.berlinet.de> wrote on 27.03.04:

> Michael Heydekamp (my-news at freexp.de) schrieb:

>>> Jetzt kann ich keine zwei gmx-Boxen einrichten,

>> Warum nicht?

>>> sondern muß eine anders nennen,

>> Wie der Boxname heißt, ist doch (bei RFC/Client) völlig egal.

> Jedenfalls gings unter ZConnect nicht und ich habe es daher
> beibehalten, vd. Namen zu verwenden, die dann einen Teil der Adresse
> bilden.

Ja klar, das ist die ZConnect-Denke.  Bei RFC/Client nennst Du die Boxen
meinetwegen "Box1" und "Box2", das hat null Einfluß auf die Adresse, die
Du dort verwendest (sollte auch in der Hilfe zum Boxnamen stehen).

> Wenn ich also zwei Accounts habe: name1 at gmx.de und name2 at gmx.de, dann
> kann ich kaum zwei Boxen mit gmx einrichten.

Bei RFC/Client schon.  Bei ZConnect müßte das BTW auch gehen, wenn man
den Schalter "Absender Username at Pointname.Domain" aktiviert.

>> Falls es Dir darum gehen sollte, die Nachrichten mehrerer Boxen mit
>> einem Anruf versenden zu können: Probiere doch mal, unter
>> "Zusätzliche Server" die Boxen, deren Nachrichten mitversendet
>> werden sollen, einzutragen.  Das war ein Szenario, das ich ohnehin
>> nochmal testen wollte.

> Das ist mir jetzt noch völlig fremd, aber liest sich erstmal gut. Ich
> will nur zwei vd. Accounts mit vd. Usernamen bei demselben Anbieter
> verwalten, die unter vd. Boxnamen unter XP erscheinen müssen.

Prinzipiell geht das - von dem oben angesprochenen "Multiserver-Netcall"
mal abgesehen - natürlich mindestens mal mit zwei Boxen und Netcall/
Spezial.  Wobei man da wieder was für UKA_PPP basteln müßte, um die
Verbindung nach dem Poll der ersten Box nicht zu trennen.

>> Hmm, wird aber wohl daran scheitern, daß die Batch derzeit nur das
>> Spool der pollenden Box beachtet.  Sie müßte im Grunde diesen Eintrag
>> in der BFG auswerten und die Nachrichten aller dort eingetragenen
>> Boxen ins UKA_PPP-Spool kopieren.

> Aha.

UKA_PPP unterstützt von sich aus natürlich keinen Multiserver-Netcall
eines Boxtyps, den es zu dieser Zeit noch gar nicht gab.  Will man sowas
haben, muß man es von außen dranflicken oder UKA_PPP umschreiben.

Und "von außen dranflicken" hieße:

FreeXP legt per Design die zu versendenden Nachrichten der Pollbox wie
die der in der Pollbox eingetragenen "zusätzlichen Server" in den box-
spezifischen Spool-Verzeichnissen ab.

Ein Client, der dieses Konzept unterstützt (und das macht UKAW mit dem
Parameter /light, UKAD hingegen nicht), würde jetzt die Nachrichten aus
allen diesen Verzeichnissen über die bei den jeweiligen Boxen
eingetragenen Mail- und News-Server versenden.

Da UKA_PPP das nicht macht, müßte die Batch dafür sorgen, daß nicht nur
die Nachrichten der Pollbox, sondern auch die der "zusätzlichen Server"
ins UKA_PPP-Spool kopiert werden.

Da muß man sich dann allerdings nochmal genau ansehen, wie man das
Unversandt-Handling sauber hinbekäme.  Das wird nicht ganz trivial.

>> Könnte man sich mal ansehen, wenn ich das Envelope-Handling einbaue,
>> da muß ich ohnehin auf BFG-Einträge zugreifen.

>> Aber zum einen ging der Versand der Nachrichten mehrerer Boxen
>> gleichzeitig unter ZConnect bisher auch nicht, und zum anderen hat
>> das immer noch nichts mit den angesprochenen (und nicht von XP
>> herbeigeführten) Unversandt-Problemen zu tun.

> Mir gehts eigentlich nur um unversandte Nachrichten und wie deren
> Abgleich nach dem Rückkopieren ins boxspezifische Verzeichnis
> mit dem <boX>.pp-File über die MID erfolgt. Lediglich darum.

Ach so, jetzt ist klar - wenn Du die MID per Filter patchst, wirst Du
diesbzgl. allerdings Probleme bekommen.  Vermutlich wird das Ergebnis
sein, daß eine Nachricht mit gepatchter MID, die nicht versandt werden
konnte, von XP als versandt betrachtet werden wird.

Und zu der MID, die die unversandte Nachricht inzwischen trägt, wird XP
keine Nachricht in der Datenbank finden und mit einer Fehlermeldung
reagieren.

Stimmt, ist ein Szenario, mit dem man das Unversandt-Handling sabotieren
kann.

> Nach meinen Erfahrungen verschwinden Nachrichten dann, wenn
> sie nach dem Rückkopieren nicht mehr als unversandt identifiziert
> werden, was bei mir an dem geänderten Domain-Tail der MID: lag.
> Ich bin darüberhinaus nicht gerade ein Fan dieser Rumkopiererei,

Das hat UKA_PPP ja zwangsläufig schon immer gemacht (zumindest in eine
Richtung, aber nicht wieder zurück).  Nur daß es früher selbst sogar
noch für die UUZ-Konvertierung zuständig war.

Sicher wäre es schöner, UKA_PPP würde direkt auf das XP-Spool zugreifen,
aber das käme eben einem Umbau von UKA_PPP gleich.

>>> (mit ein paar netten Features zugegeben) und bin immer noch der
>>> Meinung, passender für eine Standard-Installation wäre vermutlich,
>>> das mal in ein UKA_PPP-Skript umzuschreiben sich damit auch
>>> komplett die Box- Daten aus der .bfg zu holen.

>> Genau das geht aber nicht, weil UKA_PPP - jedenfalls im derzeitigen
>> Zustand - Parameter wie den Boxnamen gar nicht auswertet und keine
>> Ahnung hat, wo die Spoolverzeichnisse von XP liegen.

>> Das wäre ein Totalumbau von UKA_PPP, den ich eigentlich nicht
>> vorhatte.

> Ich dachte eher an ein XP angepaßtes, erweitertes Installationsskript
> für eine Standardinstallation.

UKA_PPP müßte sich aber die Daten bei jedem Netcall neu holen.  Nur bei
der Installation reicht nicht (und auch da wüßte UKA_PPP ja erstmal
nicht, wo die BFGs lägen, es sei denn, man hält sich an die Konvention
von RFC/Client und sagt einfach "eine Verzeichnisebene darüber").

Wobei mir gerade einfällt, daß UKA_PPP mit einem $homedir arbeitet (was
wohl das XP-Verzeichnis ist), und ich grad nicht weiß, wo es das immer
überhaupt hergehabt hat.

>> Eher hielte ich es noch für sinnvoll, sich mit dem Fixen von ein,
>> zwei alten Bugs in UKA_PPP zu beschäftigen.

> Tja, sollte man vielleicht KHW wegen des Source mal anschreiben.

Ich denke nicht, daß er andere Sourcen hat als die, die wir auf dem FTP-
Server finden.  Er hat mir mal geschrieben, daß er da dringend mal
aufräumen müsse, aber das ist schon ein paar Jahre her. ;)

>>> Ob man sich mit dem Batch und der Dokumentation wirklich
>>> neue und bleibende Verbesserungen schafft, weiß ich nicht.
>>> Ist vielleicht besser als vorher, aber unter einer Standard-
>>> Installation verstehe ich noch was anderes, als hinterher in
>>> .$cf und .$do herumzukramen.

>> Braucht man doch auch gar nicht.  Gerade die User, die eine
>> Standard-Installation von UKA_PPP betreiben, brauchen überhaupt gar
>> nix "herumzukramen".  Das ist ja gerade das Schöne.

> Du mußt doch den Kram erstmal einrichten.
> Im Prinzip sollte das Vorgehenen doch so sein, daß UKA_PPP
> ausgepackt wird und RFC/Client unter XP eingerichtet wird.
> Zusätzlich wäre ein Konfigurationsskript erforderlich, daß
> diese Angaben für UKA - automatisch - übernimmt.
> Vermutlich ist das mit einem Skript für X_Skript zu umständlich,
> aber im Prinzip verstehe ich nur darunter eine Standard-Installation.
> Die führt nicht unbedingt weiter zu der von Dir ausgewählten
> Batch-Anbindung. Insofern wäre vielleicht der Unterschied
> wichtig, was eine Standard-Installation aus XP und was eine
> aus UKA_PPP-Sicht wäre.

Ja gut, ich verstehe unter "Standard" im Moment die seit jeher von
UKA_PPP her bekannte Art der Installation.

Du sprichst eher von einer "richtigen" Anpassung an RFC/Client, aber die
hatte ich nicht im Blick.

> Nur wenn wir reden über eine Standard-Installation aus Sicht von
> XP reden, ist die mit UKAD derzeit besser gelöst.

Das ist klar, weil UKAD den Boxtyp direkt unterstützt.  Nur geht z.B.
Multibox auch damit nicht.


        Michael