Hallo!

Ich habe nun schon über Monate hinweg etliche Stunden investiert, um den Reconnect zum Funktionieren zu bekommen - leider bisher erfolglos. Ich habe JD2 auf einem Debian 9 System laufen, das auch gleichzeitig der LAN-Internet-Gatewax-Router ist. Zum Reconnect ist die Eingabe von zwei Kommandos nötig:
a) "poff" zum Trennen der PPPoE-Verbindung und
b) "pon dsl" zum Aufbau einer PPPoE Verbindung mit dem konfigurierten dsl Profil.
Beide Kommandos funktionieren und dem User-Account unter dem JD2 ausgeführt wird stehen die nötigen Rechte zur Verfügung.

Es gibt einige Gründe, weshalb ich keine Optionen sehen kann, das noch hinzubekommen:
1. Der übliche Ansatz, eine Konfiguration mit der GUI zu erstellen und auf den Headless-Server zu übertragen ist einfach nicht möglich, bzw. inpraktikabel. Warum? Weil der Server auf dem JDownload2 laufen soll eben auch gleichzeitig der Router ist. Und dort sollen lediglich die zwei Kommandos unter Debian 9 ausgeführt werden, eben "poff && pon dsl". Es ist offensichtlich, dass diese Konfguration, auf einem anderen System gar nicht funktionieren kann, wei es sich dabei um lokale Kommandos unter Debian 9 handelt, und auch keine Weboberflöche zur Verfügung steht und auch keine solche genutzt werden soll.

Der JDownloader lässt aber scheinbar das Abspeichern einer Reconnect-Konfiguration nur zu, wenn der Reconnect-Test erfolgreich ausgeführt wurde - zumindest sieht die GUI danach aus, auch weil es leider keinen Save-Button gibt. Wie kann ich bei der Reconnect GUI sicher sein, dass die Zeile die ich dort tippe tatsächlich auch in der Konfig gespeichert wird?

Was ich versucht habe war, den JDownloader auszutricksen:
Ich habe auf einem beliebigen Computer den Reconnect auf "Drittwanwender-Reconnect" gestellt und als Kommandos "poff && pon dsl" eingetragen. Natürlich hat das auf einem anderen System als dem Debian-Router selbst keine Funktion; um aber dennoch erfolgreich den Reconnect-Test auszuführen habe ich einfach den Test gestartet und währenddessen über SSH den Router manuell getrennt und wieder verbunden. Der JDownloader wurde ausgetrickst und hat den Test als erfolgreich quittiert.
Danach habe ich die erkennbar für den externen Reconnect nötigen Config-Files auf den Server nach cfg kopiert, also:

ExternBatchReconnect.json
ExternReconnect.json
jd.controlling.reconnect.ReconnectConfig.json

Leider bekomme ich nach wie vor nur die wenig hilfreiche Fehlermeldung in der Art von "Reconnect ist zu oft fehlgeschlagen" angezeigt.

Wäre die nächste Frage ja: "Warum?". Leider gibt es scheinbar auch kein Log zum Reconnectvorgang. Jedenfalls konnte ich im Log-Ordner Nichts sehen, was danach aussah..

Insgesamt muss ich sagen, ist der momentane Zustand was den Reconnect angeht für die Verwendung auf einem headless-Server leider als nicht funktionsfähig anzusehen, weil:
1. Die indirekte Konfiguration viel zu unsicher ist. Das Web-UI braucht dringend eine einfach Zeile, wo man selbst die nötigen reconnect-commands eingeben kann
2. Das Rüberkopieren der Konfiguration vom GUI auf das Headless-Server-System logischerweise nicht möglich ist, weil es sich dabei nahezu immer um systemspezifische Kommandos handelt, die auf einem alternativen System (welches dann eine grafische Oberfläche hätte, um die "normale" UI zu verwendenm, so gar nicht anwendbar sind
3. Es gibt anscheinend kein Log; keine Chance zum Debugging. Ich habe null Ahnung was passiert, bzw nicht passiert, wenn dem JD2 angeblich gerade ein Reconnect fehlschlägt. Werden die Kommandos überhaupt ausgeführt? Usw.
4. Die eigentliche Java Oberfläche (also nicht im Web-UI) ist leider auch nicht üblichen Usability-Standards entsprechend, was die Reconnect-Seite angeht. Man braucht als User ein Feedback, dass die Daten die man eingegeben hat auch (1.)übernommen, (2.)als nutzbar akzeptiert und (3.)dauerhaft gespeichert wurden. Leider gibt es alle Drei nicht.

Meinen Erfahrungen nach also, ist der komplette Vorgang zur Herstellung eines Reconnects für ein Headless-System nicht nur völlig intransparent, sondern er wird zusetzlich erschwert, durch unklare Eingabemethodik, durch die laut Plan vorgesehene nur indirekt mögliche Einflussnahme (Kopieren von GUI zu Web-UI), und durch das Fehlen einer Möglichkeit zu sehen was eigentlich passiert.


Bitte bessert Dies dringend nach, ich sehe sonst keine Chance den Reconnect jemals zum Ĺaufen zu kriegen.

[barkle]

Hast du bei deinen Aufrufen von pon und poff absolute Pfade verwendet?
pon und poff liegen in /usr/bin und sind Shellscripte. Dort könnetst du Kontrollausgaben einbauen um zusehen ob und wie weit die Scripte abgearbeitet werden.

Hallo!
Also ExternReconnect.json sah bisher so aus:

{
"WAIT_FOR_RETURN_SECONDS" : 6,
"COMMAND" : "poff && pon dsl",
"DUMMY_BATCH_ENABLED" : true,
"PARAMETER" : null
}

Ich habe es jetzt mal geändert, zu

"COMMAND" : "/usr/bin/poff && /usr/bin/pon dsl",

, falls die absoluten Pfade notwendig sind.
Ob es auch funktioniert sehe ich ja erst später, wenn ich zufällig Mal mitbekomme, dass gerade eine Trennung durch JD2 stattfand; gezielt provozieren kann man es ja nicht (Ein Button zum manuellen, sofortigen Reconnect wäre auch eine sehr nützliche Funktion im Web-UI!)
Auch habe ich es schon über die ExternBatchReconnect.json versucht, die sieht so aus:

{
"BATCH_COMMAND" : "poff && pon dsl\n",
"TERMINAL" : "/bin/bash",
"WAIT_FOR_RETURN_SECONDS" : 0,
"EXECUTE_IN" : "/home/jd"
}

(und dazu noch in jd.controlling.reconnect.ReconnectConfig.json "activepluginid" : "ExternReconnect", auf "activepluginid" : "ExternBatchReconnect", geändert, wobei ich nicht weiß, ob das so überhaupt richtig ist)

Mit Kontrollausgaben in den pon/poff Skripten bin ich mir nicht so sicher: Da JD2 ja im Hintergrund läuft, landen die Ausgaben ja nicht in der Konsole, wie könnte ich sie dann sehen? Einfach in ein Textfile umleiten? Das birgt ja wieder ein eigenes Fehlerpotential..
Danke!

Edit:
Das Ändern der Pfade auf absolut hat leider nicht geholfen, eben kam die Meldung wieder :(
Ich habe auch probeweise mal ein "touch test123" als Command eingefügt, aber konnte im Anschluss keine Datei dieses Namens irgendwo auffinden. Für mich sieht es aus, als würde das Command welches in ExternReconnect.json eingetragen ist gar nicht erst ausgeführt werden.
Könnte es evtl. damit zusammenhängen, dass Java eine bestimmte Konfiguration braucht, um einem User der nicht Root ist die Ausführung von externen Files durch JD2 zu erlauben?

[Jiaz]

&& ist teil von Bash/Konsole und kein normales Kommando
Am einfachsten du erstellst ein Bashscript,zb

vi /pfad/script.sh

#!/bin/bash
poff && pon dsl
sleep 10

chmod +x /pfad/script.sh

und dann dieses als externes Tool nutzen.
Kontrollausgaben zum Beispiel so

#!/bin/bash
echo "start" >>/tmp/script.out
poff && pon dsl
sleep 10
echo "done" >>/tmp/script.out

oder eben auch via touch

[Jiaz]

Originally Posted by Richtso

Einfach in ein Textfile umleiten? Das birgt ja wieder ein eigenes Fehlerpotential..

Welches Fehlerpotential? Logausgaben in Textdateien ist doch das normalste der Welt?!

[Jiaz]

Originally Posted by Richtso

Bitte bessert Dies dringend nach, ich sehe sonst keine Chance den Reconnect jemals zum Ĺaufen zu kriegen.

Der Weg den Reconnect über GUI einzustellen (muss ja nicht erfolgreich sein) und dann die entsprechenden Konfigurationen zu kopieren sollte eigentlich ohne Probleme funktionieren. Ich denke eher das der eigentliche Auffruf des Tools nicht klappt weil zb && nicht außerhalb von Bash/Scripten genutzt werden kann. Fertige mal ein Script an, welches den Reconnect durchführt und welches man normal in der Konsole starten kann, dann kann ich gerne bei der Einrichtung auf dem Headless JDownloader behilflich sein via Teamviewer. Kontaktiere uns einfach via support@jdownloader.org.

[Jiaz]

Originally Posted by Richtso

Hallo!

Ich habe nun schon über Monate hinweg etliche Stunden investiert, um den Reconnect zum Funktionieren zu bekommen - leider bisher erfolglos.

Warum Monate und etliche Stunden investieren und nichtmal ein paar Minuten hier nachfragen Ich bin zuversichtlich das wir das mittels Teamviewer relativ schnell gelöst bekommen

Originally Posted by Jiaz

&& ist teil von Bash/Konsole und kein normales Kommando
Am einfachsten du erstellst ein Bashscript,zb

vi /pfad/script.sh


chmod +x /pfad/script.sh

und dann dieses als externes Tool nutzen.
Kontrollausgaben zum Beispiel so



oder eben auch via touch

Danke dir!

Ich habe die commands nun in ein Skript gepackt, und rufe dieses aus ExternReconnet.json auf - nun funktioniert es endlich!
Ich kann mir aber nicht wirklich erklären weshalb, denn ich hatte doch in der ExternReconnect.json zuvor auch schon ein einfaches "touch test123" als command versucht, und das wurde auch nicht ausgeführt (Die Datei wurde nicht erzeugt). Aber nuja, hauptsache es geht.

Was ich mit Fehlerpotential bezüglich der Ausgabe in Files meinte war vor Allem ein eventuelles Problem mit Rechten - wenn die Datei (warum auch immer) irgendwo landen würde, wo mein JDownloader2-User (der ja nicht root ist) nicht schreiben darf, dann würde es ja auch nicht klappen.

Der Grund dass ich schon so lange mit dem Problem "lebe" ist der, dass ich denke man sollte doch erst mal versuchen seine Probleme selbst zu lösen, bevor man die Zeit Anderer in Anspruch nimmt (zumindest dann, wenn es sich bei diesen Anderen um Personen handelt, die sowieso schon andauernd massenweise Fragen beantworten ). Ich fand es aber auch sinnvoll diesen Thread zu eröffnen, um ein paar Anregungen zu geben, wie man die Bedienung des JD2 bezüglich des Reconnect verbessern könnte. Ich denke z.B. nur das Hinzufügen einer Zeile im WebIf, wo man das beim Reconnect auszuführene Kommando bzw. Skript direkt eintippen kann hätte hier im Forum geschätzte 100 Threads zum Thema weniger zur Folge.

Also Danke nochmal! Super dass es jetzt läuft. Dann wird es wohl demnächst um Details gehen, wie diverse Skripte die den JD optimieren

[Jiaz]

Originally Posted by Richtso

Was ich mit Fehlerpotential bezüglich der Ausgabe in Files meinte war vor Allem ein eventuelles Problem mit Rechten - wenn die Datei (warum auch immer) irgendwo landen würde, wo mein JDownloader2-User (der ja nicht root ist) nicht schreiben darf, dann würde es ja auch nicht klappen.

Verständlich Aber das Problem wäre ja dann *Hausgemacht* Natürlich sollte man in ein TempFile/Ort schreiben wo der Nutzer auch entsprechende Rechte hat

[Jiaz]

Freut mich das es nun geklappt hat JDownloader gibt dem ausführenden Prozess nicht die Umgebungsvariablen weiter und daher musst du nötige Binaries mit vollem Pfad angeben.
Bei dem Script klappt das, da ja im Script selbst dann die Bash referenziert ist und diese ja dann den Lookup zu den Binaries macht. Ein simples 'touch' jedoch weiß JDownloader nicht welches Programm damit gemeint ist

[Jiaz]

Originally Posted by Richtso

Ich fand es aber auch sinnvoll diesen Thread zu eröffnen, um ein paar Anregungen zu geben, wie man die Bedienung des JD2 bezüglich des Reconnect verbessern könnte. Ich denke z.B. nur das Hinzufügen einer Zeile im WebIf, wo man das beim Reconnect auszuführene Kommando bzw. Skript direkt eintippen kann hätte hier im Forum geschätzte 100 Threads zum Thema weniger zur Folge.

Hierfür gibt es bereits ein Ticket. Jedoch nutzt das Reconnect-System noch ein *Legacy* Konfigurationssystem, welches nicht nach *Extern* oder Profieinstellungen angebunden werden kann. Sprich dieses muss zunächst auf das neue Konfigurationssystem umgebaut werden und dann erscheinen die entsprechenden Felder von selbst in den Profieinstellungen und dann kann man auch *schöne GUI* im Webinterface dafür bauen

[Jiaz]

Originally Posted by Richtso

Also Danke nochmal! Super dass es jetzt läuft. Dann wird es wohl demnächst um Details gehen, wie diverse Skripte die den JD optimieren

Nichts zu danken! Das nächste mal einfach fragen Kostet ja nix und ich antworte dann sobald ich Zeit finde