Fritzbox als rustdesk-server?

[f-user]

Cool! Vielen Dank für's Testen und die Skripte! Und die MIPS info!

Die Anfrage hatte ich gesehen, aber da gab's noch keine Antwort. Und eine der anderen Anfrage wurde in der Vergangenheit mit "wenn's genug Nachfrage gibt, vielleicht" quittiert. Sieht so aus, als wären genug "Anfragen" eingegangen...

Ich nehme an, der die USB-Stick-Variante wurde gewählt, weil die 7530 nur halb so viel Speicherplatz hat, wie ihre größeren Schwestern?

Jedenfalls ein schöner Erfolg! Danke nochmal!

 

[NanoBot]

Richtig, bei der 7530 ( ohne AX ) sind vom internen Flash nur 9,7 MByte frei verfügbar, was für den Rustdesk-Server natürlich nicht reicht. Selbst für den Anrufbeantworter oder den möglichen Empfang von Faxen ist dies zu wenig, weshalb ich ohnehin einen alten 1GByte USB-Stick an der Box verwende. Auf diesem Stick befindet sich zunächst das Verzeichnis "FRITZ" mit den Unterordnern faxbox, mediabox und voicebox. Zusätzlich habe ich dann im Hauptverzeichnis des Sticks den Ordner "opt" angelegt, denn von der rustdesk-server Installation auf meiner CoreElec Box wußte ich, daß der rustdesk-server standardmäßig unter /opt/rustdesk installiert wird. Und weil der originale Ordner "/opt" auf der FB7530 einerseits leer und andererseits ro ist, habe ich dann einfach das "opt" Verzeichnis des Sticks mit "mount --rebind" drüber gelegt.

 

[f-user]

Auf jeden Fall braucht man ja wohl freetz.
Daher würde mich noch interessieren: Kann ich dann gleich auch die Variante von PeterPawn nehmen, wenn meine FB noch nicht modifiziert wurde? Die Herangehensweise dürfte wohl gleich sein (selbst kompilieren etc.), aber nachdem ich in der Vergangenheit wohl schon Programme / Skripte von ihm verwendet habe, würde ich seiner Freetz-Modifikation auch trauen bzw. davon ausgehen, daß sie einen sinnvollen Mehrwert bietet. Oder ist diese nur für (fortgeschrittene) Nutzer gedacht, die schon eingehende Erfahrungen mit freetz haben?

Was ich auf Github gelesen habe, habe ich als ersteres gedeutet, aber ich frage lieber vorher nach...

Und eine zweite Frage hierzu, die ich abklären wollte: Freetz erweitert die Möglichkeiten, d.h. alle vorhanden bleiben erhalten und die Einstellungen lassen sich auch weiterhin wie gewohnt im- und exportieren? So zumindest habe ich es verstanden.

 

[NanoBot]

Mit freetz-ng kann man sowohl bestimmte Komponenten der Firmware entfernen, als auch neue Komponenten hinzufügen. Die Entfernung von Komponenten kann entweder dazu dienen im Flash-ROM Platz für andere Sachen zu schaffen. Man kann diese Möglichkeit aber auch nutzen um Komponenten der Originalfirmware, welche man aus Gründen der Sicherheit oder der Privatsphäre nicht auf seiner Fritz!Box haben möchte, zu entfernen.

Ob freetz zwingend erforderlich ist oder ob es ausreichend wäre die Firmware mit der Variante von PeterPawn zu modifizieren kann ich gar nicht so genau sagen. Ich hatte auf meiner Box ursprünglich aus drei Gründen eine gefreezte Firmware installiert:

Ich nutze das Paket "Onlinechanged-CGI" um beim Wechsel der WAN-IP sowohl die neue IPv4-Adresse, als auch die IPv6-Adressen mehrerer Geräte in meinen LAN mit Hilfe eines Scripts bei meinem Dyndns-Anbieter zu aktualisieren. Weiterhin nutze ich das Paket "Dropbear" um einen vollständigen Zugang per SSH und SFTP auf die Box zu haben. Und außerdem nutze ich den Patch "Remove tr069 stuff" um von mir nicht authorisierte Zugriffe auf die Box durch AVM oder meinen ISP so weit wie möglich zu unterbinden.

Um den rustdesk-server laufen zu lassen nutze ich jetzt die folgenden Möglichkeiten von freetz, von denen ich nicht weiß, ob man dies auch mit den Modifikationen von PeterPawn erreichen könnte:

Der SSH-Zugang ist erforderlich um das "/opt" auf dem Stick neu zu mounten. Hierbei hilft mir freetz insoweit, als das es dort den Patch "Drop noexec for (external) storages" gibt, welcher es erlaubt, ausführbare Dateien, welche sich auf einen externen Datenträger befinden, zu starten. Dies ist von AVM aus per default verboten. Ohne diesen Patch mußte ich für das "/opt" Verzeichnis das "exec" Flag durch einen remount erst extra setzen. Weiterhin mußte ich natürlich, erstmal zum Testen, die binaries per SSH als Hintergrundprozesse zu starten

/opt/rustdesk/hbbs -k _ > /opt/rustdesk/log/signalserver.log 2> /opt/rustdesk/log/signalserver.error &
/opt/rustdesk/hbbr -k _ > /opt/rustdesk/log/relayserver.log 2> /opt/rustdesk/log/relayserver.error &

Anstelle der einfachen Umleitung per ">" kann man hier natürlich auch ">>" verwenden, so das neue Einträge an die bestehenden Logfiles angehängt werden. Mit dem einfachen ">" werden die Logs bei jedem Neustart gelöscht und neu angelegt.

Desweiteren brauchte ich den SSH/SFTP Zugriff um den Inhalt der Datei "id_ed25519.pub" zu lesen, welche beim ersten Start des Rustdesk-Servers erzeugt wird. Diese Datei enthält den Key welchen die Rustdesk-Clienten benötigen, um den Server nutzen zu dürfen.

Für die Portweiterleitung wird, wie oben bereits beschrieben der "cron" Daemon benötigt. Und da weiß ich nicht, ob dieser ohne freetz überhaupt genutzt werden kann.

Und wenn alles durchgetestet ist, muß man sowohl das mounten des "/opt" Verzeichnisses, als auch den Start der beiden binaries natürlich nach einem reboot der Box automatisch ausführen lassen, wofür sich unter freetz "rc.custom" anbietet. Auch hier weiß ich nicht, ob diese Funktionalität ohne freetz mit Hilfe des Mods von PeterPawn verfügbar ist.

 

[f-user]

Vielen Dank für die ausführliche Erklärung! Die wird mir sicherlich gute Dienste leisten, wenn ich mal entweder die richtige Fritzbox oder die nötigen MIPS Binärdateien habe!

Allerdings meinte ich mit "PeterPawn's Variante" nicht sein modfs (das ist für diese Operation wohl nicht geeignet), sondern wirklich seine Variante von Freetz, die er YourFreetz genannt hat (https://github.com/PeterPawn/YourFreetz). Inzwischen habe ich allerdings festgestellt, daß seine Variante auf Freetz und nicht auf Freetz-NG beruht. Der angegebene Link (freetz.org) führt zwar zum Github von Freetz-NG, aber der commit-Vergleich wird mit freetz (original) geführt. Wg. ersterem dachte ich, YourFreetz wäre ein Freetz-NG-Ableger...

Insofern hat sich diese Frage wohl erübrigt - wobei, vielleicht gibt es ja trotzdem einen Grund, YourFreetz dem Freetz-NG vorzuziehen?

 

[PeterPawn]

Bringt nichts - dieser Fork dient(e) nur als Quelle für von mir bereitgestellte Binaries, damit erfülle ich die Bedingungen der GPL für solche Pakete.

Mittlerweile gehe ich da aber (bisher nur für mich) auch andere Wege und benutze meinerseits die vom OpenWRT bereitgestellten Pakete mit Binärdateien.

Da aber auch die älteren Binärdateien in meinem yf_bin-Repository noch von so einigen Leuten benutzt werden, um damit ihre Firmware zu modifizieren (es gibt ja mittlerweile auch für andere Modelle als diejenigen mit VR9-Chipset noch ein paar Angebote meinerseits), gibt es dieses Repository auch weiterhin, selbst wenn da keine "taufrischen" Pakete enthalten sind.

 

[f-user]

Danke für die Erläuterung.

Das erleichtert die Entscheidung wenn es soweit ist.
V.a., da openwrt für die 7490 nicht nur nicht als release (nur als snapshot) verfügbar ist (meiner Interpretation nach also nicht so wirklich offiziell unterstützt wird), sondern meinem Verständnis nach (und, wenn ich deine Erläuterungen in einem heise Beitragsforum richtig deute, quasi durch dich bestätigt) bleibt bei openwrt das Fritz!OS anders als bei freetz-ng nicht erhalten. Nicht, daß ich den Smart-Home-Kram bräuchte, aber die DECT/Telefon-Sachen hätte ich schon ganz gern behalten... und überhaupt alles neu einrichten müssen möchte ich die über die Jahre vorgenommenen Einstellungen auch nicht..

Somit speichere ich mal ab: Wenn, dann freetz-ng.

Und danke auch, daß du dein Wissen und deine Erkenntnisse hier und anderswo teilst!
Gleiches gilt natürlich aber auch für Nanobot!

 

[f-user]

Nun habe auch ich es geschafft, den RustDesk-Server auf der Fritzbox zum Laufen zu bekommen.

Durch einen glücklichen Umstand bin ich an eine 7530 gekommen, nachdem ich eigentlich auf eine 7690 und dann die noch bessere 5690 Pro fixiert war.

Wie dem auch sei, dank @NanoBot's Anleitung habe ich es geschafft, den RustDesk-Sever einzurichten, allerdings nicht ganz ohne Hindernisse.

Das generelle Kompilieren und Installieren von Freetz habe ich erst an einer anderen Fritzbox getestet, damit die 7530 nicht aus Versehen zu Schrott wird.

An zwei Stellen bin ich dann bei der RustDesk-Server-Einrichtung auf Freetz hängengeblieben.

Zum einen war mir nicht ganz klar, ob es sich bei der IP-Adresse in @NanoBot's OpenRustdeskPorts.sh-Skipt (https://www.ip-phone-forum.de/threads/fritzbox-als-rustdesk-server.318700/post-2551824) um eine "interne" default-IP oder die in der AVM-Weboberfläche (ggf.) selbst vergebene IP-Adresse der Fritzbox handelt. Nach einigem Testen habe ich dann herausgefunden, daß es sich um letztere IP-Adresse handelt.
Viel länger, stundenlang, um genau zu sein, hat mich allerdings ein zweites Problem aufgehalten. Nämlich, daß das Skript zur Starten des RustDesk-Servers beim Fritzbox-Start, das in die rc.custom-Maske in der Freetz-Weboberfläche eingetragen wird, nie ausgeführt wurde. Und das, obwohl es sich manuell per puTTY einwandfrei ausführen ließ, ebenso die rc.custom-Datei selbst. Nur eben nicht selbstständig nach dem Booten.

Zwischenzeitlich habe daher mal ein Freetz-Abbild mit "external stuff" (oder so) erstellt und das Skript in rc.external eingefügt, was aber auch nichts gebracht hat. Eventuell, weil ich den dort bereits vorhandenen Code drin gelassen habe?

Jedenfalls bin ich dann nach zig Neustarts und Internet-Suchen auf die Idee gekommen, vor das Skript bei rc.custom ein "sleep" einzufügen (angefangen bei 60). Dann hat es endlich geklappt. Letztendlich bin ich bei "sleep 10" gelandet. Ob zwischen 5 und 10 Sekunden Verzögerung noch weitere Werte funktionieren, habe ich dann nicht mehr getestet. Hierbei war dann die "neu entdeckte" Rubrik der Logs mit dem rc_custom.log hilfreich, um zu sehen, bei welchen Werten der USB-Stick verfügbar war.

Das "mount --rebind" habe ich allerdings weggelassen. Mir ist nicht ganz klar, warum das nötig ist. Mit dem Pfad zum USB-Stick funktioniert es auch.
Von dort wird dann bei mir das Skript aufgerufen, das die beiden RustDesk-Server-Dateien ausführt und das ich schon lokal auf dem Rechner verwendet habe. Ebenso habe ich die key-Dateien vom Rechner übernommen, damit ich nicht in allen Clients den Schlüssel ändern muß.

Getestet habe ich mit piTTY (terminal-Befehle) und FileZilla ("Datei-Browser" zum Hochladen von Dateien bzw. Ändern von Datei-Berechtigungen (temporär, Ausführen von rc.custom von puTTY aus)).

Nochmals vielen Dank an @NanoBot für die gute Pionierarbeit. Ohne diese hätte ich das ziemlich sicher nie geschafft.

 

[NanoBot]

Ich starte ( da wird Peter Pawn jetzt schimpfen, weil es eine Sicherheitslücke darstellt ) den Rustdesk-Server über die aktivierte freetz Funktion "Automatisch autorun.sh und autoend.sh ausführen". Damit diese Funktion verfügbar ist, muß der Patch "udevmount" ausgewählt sein. Die Datei autorun.sh muß im Hauptverzeichnis des USB-Sticks liegen und sieht so aus:

#!/bin/sh

mount --rebind /var/media/ftp/FRITZ_USB/opt /opt
sleep 2

/etc/init.d/rc.crond start > /dev/null
sleep 2

cd /opt/rustdesk
sleep 2
/opt/rustdesk/hbbs -k _ > /opt/rustdesk/log/signalserver.log 2> /opt/rustdesk/log/signalserver.error &
/opt/rustdesk/hbbr -k _ > /opt/rustdesk/log/relayserver.log 2> /opt/rustdesk/log/relayserver.error &

Der Vorteil dieser Methode mit autorun.sh besteht darin, daß das Script erst dann gestartet wird, wenn der USB-Stick erkannt und gemountet worden ist. Hierdurch ist der sleep Befehl, welchen du in der rc.custom verwenden mußt, überflüssig.

Der Befehl "mount --rebind ..." ist tatsächlich nicht erforderlich. Stattdessen kann man die rustdesk Dateien an beliebiger Stelle auf dem USB-Stick plazieren und muß dann nur die Pfade anpassen. Ich verwende ihn nur, weil der Rustdesk-Server Version für arm7 von den Installscripten per default unter dem Pfad "/opt/rustdesk" installiert würde. Zwar kann man die Scripte für die automatische Installation auf der Fritz!Box gar nicht nutzen, aber ich wollte deren Verhalten soweit wie möglich "nachahmen". Und da sich auf der 7530 unter "/opt" keine Dateien befinden, bot es sich an, so vorzugehen. Den Patch "Drop noexec for (external) storages" hast du vermutlich beim Bauen von freetz angewendet, denn nur dann kann man ausführbare Dateien auf dem Stick starten. Da der Stick bei mir FAT32 formatiert ist, brauchte ich mich nicht um die Zugriffsrechte kümmern.

Ich lasse den crond nicht automatisch von freetz starten, sondern erledige dies in obigen Script. Hierdurch startet der crond nur und erst dann wenn der USB-Stick erkannt und gemountet worden ist. Dies funktioniert bei mir problemlos, weil ich den crond ausschließlich zum Aufruf des Scripts zum Öffnen der Ports mit pcplisten nutze.

Im nächsten Schritt werden der Signal- und der Relayserver als Hintergrundprozesse gestartet. Dazu muß man aber vorher mit "cd" das Verzeichnis wählen, in welchem sich die rustdesk Dateien befinden, sonst findet der Server die Keydateien id_ed25519 und id_ed25519.pub nicht. Die "sleep 2" Befehle habe ich nur zur Vorsicht eingefügt; ob sie wirklich erforderlich sind oder nicht, habe ich nie getestet.


Wie ich feststellen mußte passiert es alle paar Tage manchmal, daß der Signalserver oder der Relayserver sich spontan beenden. Warum dies passiert, konnte ich bisher nicht feststellen. Um die beiden Server bei Bedarf per ssh komfortabel beenden und neustarten zu können, nutze ich diese beiden Scripte, welche ich im Hauptverzeichnis des USB-Sticks plaziert habe:

StartRustdeskServer.sh

#!/bin/sh

cd /opt/rustdesk
sleep 1
/opt/rustdesk/hbbs -k _ > /opt/rustdesk/log/signalserver.log 2> /opt/rustdesk/log/signalserver.error &
/opt/rustdesk/hbbr -k _ > /opt/rustdesk/log/relayserver.log 2> /opt/rustdesk/log/relayserver.error &

und StopRustdeskServer.sh

#!/bin/sh

killall hbbr > /dev/null
killall hbbs > /dev/null

C.U. Nanobot

 

[f-user]

Danke für die neuen Infos!

Ich wollte gerade hinzufügen, daß ich den Wert für "sleep" von 10 auf 30 erhöhen mußte, weil ich von v7.29 auf v8.0 umgestiegen bin. Offenbar dauert der Bootprozess soviel länger...

..und da habe ich erst deinen neuen Eintrag gesehen.

Zufälligerweise ist auch heute zum ersten Mal bei mir auch erst der eine, und dann beim Nachschauen mittels puTTY auch der zweite Server beendet gewesen bzw. worden. Einen Grund fällt mir nicht ein, außer daß ich vorher auf der AVM-Weboberfläche war. Vielleicht war das zuviel für die CPU...?

Ich hatte mal versucht, die Binärdateien so zu kompilieren, daß sie in ein anderes Verzeichnis ihre sqlite-Dateien schreiben. Dann würde ich die nämlich auf den Fritz-NAS-Speicher schreiben lassen und könnte dann die Binärdateien direkt in die Firmware einbauen und den USB-Stick weglassen. Aber solange mir erstes nicht gelingt, geht das leider nicht. Wenn die nämlich nicht schreiben können, laufen sie zwar, aber nicht funktionstüchtig und werden von den Clients nicht als existent erkannt. Leider haben die Entwickler noch keine Befehlsoption hinzugefügt, die ermöglicht, den Ort für die Datenbank selbst festzulegen.
Vielleicht habe ich auch nur die falsche Syntax für das Zielverzeichnis gewählt, die rustdesk erwartet. Mir ist auch nicht klar, ob der Verzeichnisbaum ausgehend vom eigenen oder vom Stammverzeichnis aus einzutragen ist. Das müßte ich noch einmal testen. Im Übrigen sind die selbst-kompilierten armv7-Binärdateien deutlich kleiner als die bereitgestellten auf Github.

Bislang lasse ich die beiden Binärdateien auch über ein Skript aufrufen, aber wenn ich das per puTTY aufrufe, werden sie wieder beendet, sobald puTTY beendet wird. Ist das der Grund für das " &" am Ende der Befehlszeile in deinem Skript, daß das nicht passiert?

Danke auch für die Ausführungen zu /opt.

Ich denke, ich werde auch deine neue Start-Variante übernehmen.

Auch bin ich inzwischen froh, daß ich eine 7530 bekommen habe, denn ich habe gesehen, daß A) die 7490 aus dem Support geflogen ist und B) die 7690 und die 5690 Pro deutlich mehr Strom verbrauchen (zumindest laut den Angaben, die man so finden kann).

 

[NanoBot]

Bislang lasse ich die beiden Binärdateien auch über ein Skript aufrufen, aber wenn ich das per puTTY aufrufe, werden sie wieder beendet, sobald puTTY beendet wird. Ist das der Grund für das " &" am Ende der Befehlszeile in deinem Skript, daß das nicht passiert?

So ist es. Das "&" Zeichen am Ende der Zeile bewirkt daß ein gestarteter Tochterprozess, in diesem Fall also hbbs bzw. hbbr, im auch dann im Hintergund weiterläuft wenn der Elternprozess beendet wird.

Bezüglich der spontanen Beendigung der beiden Serverprozesse bin ich am überlegen, ob ich sie per crond in bestimmten zeitlichen Abständen regelmäßig stoppen und neustarten sollte. Aber solange man nicht weiß, wieso es zu der spontanen Beendigung kommt weiß ich natürlich nicht, ob dies helfen würde oder nicht.

 

[f-user]

&-Zeichen: Ok, danke, so etwas hatte ich mir gedacht. Aber da in der letzten Zeile auch noch ein "&" war aber danach ja kein Prozeß mehr gestartet wird, dachte ich, das würde eventuell verhindern, daß beim Schließen des Terminal auch die Prozesse beendet werden.

Das regelmäßige Beenden und Neustarten wäre aber ungünstig, wenn man gerade RustDesk benutzt. Ich hätte eher an einen Skript-Zusatz (oder ein gesondertes Skript) gedacht, der das Skript automatisch neustartet, wenn einer der Prozesse nicht mehr läuft - oder so. Etwas in der Art ist mir irgendwann einmal untergekommen, aber da ich selbst nicht programmieren kann (d.h. mir den nötigen Code selbst ausdenken), müßte mal überlegen bzw. nachschauen, in welchem Zusammenhang mir so etwas untergekommen ist.

 

[PeterPawn]

Aber solange mir erstes nicht gelingt, geht das leider nicht.

Das sollte sich alles mit einem passenden bind-Mount für das Verzeichnis, wo die standardmäßig gespeichert werden, regeln lassen. Schau Dir mal die "Theorie" von solchen Mount-Vorgängen an. Lediglich die erste Verzeichnisebene (hier /opt, soweit ich weiß) muß schon existieren, der ganze Rest läßt sich dann passend zur Laufzeit einrichten. Wenn man eine "tiefere" Verzeichnisebene braucht, die man nicht auf dem NAS-Speicher haben will (man kann natürlich auch ein Verzeichnis opt unter /var/media/ftp anlegen und das dann direkt über /opt mounten), dann mountet man unter /opt eben erst mal ein tmpfs und erzeugt dort den benötigten Pfad, in den man dann an der passenden Stelle wieder das Verzeichnis auf dem NAS-Speicher einblendet. Man braucht sich um wiederholte Mounts für ein tmpfs auch keine Gedanken zu machen - jedes davon belegt nur soviel Hauptspeicher, wie die darin erzeugten Inodes und Daten benötigen, also praktisch gar nichts, wenn man darin nur irgendwelche passenden Pfade erzeugt.

Wer das also auch ohne USB-Stick realisieren will, braucht nur etwas wie das hier:

mount -t tmpfs tmpfs /opt
mkdir /opt/rustdesk
mount -o bind /opt/rustdesk /var/media/ftp/rustdesk

Jedenfalls solange es nichts vorher in /opt gab - denn das würde danach nicht mehr vorhanden sein für das System. Dabei können dann natürlich unter /var/media/ftp/rustdesk problemlos die Binaries und weitere Verzeichnisse (u.a. für die Logs, wobei ich die eher ins tmpfs unter /var/log schreiben lassen würde, auch wenn sie dann beim Neustart weg sind) liegen. Ja, sogar "feste" Symlinks unterhalb von /opt im SquashFS-Image, die auf Verzeichnisse im NAS-Speicher verweisen, sollten funktionieren, solange sie bereits beim Image-Build hinzugefügt werden. EDIT: Dabei muß man dann natürlich wieder dafür sorgen, daß der NAS-Speicher auch "executable" ist, wenn man die Binaries dort ablegt.

Es gibt also eigentlich gar keine Notwendigkeit, den Binaries irgendwie die Speicherung der Daten an einer anderen Stelle beizubringen - anstatt die Binaries an die Dateisystemstruktur anzupassen, kann man genauso gut die passende Dateisystemstruktur erzeugen, die von den Binaries "erwartet" wird. Dann muß man halt das Ganze wieder über einen passenden Service anschubsen - das ist ohnehin besser (dann kann man nämlich darauf verzichten, irgendwelche Skripte von USB-Speicher zu starten) und man kann sogar noch ohne Kopfstände mit 10 oder 30 Sekunden dafür sorgen, daß die Services in der richtigen Reihenfolge gestartet werden. Würde ich das implementieren wollen, wären das drei Services - einer zum Einrichten der passenden Umgebung (der muß auch nicht erneut gestartet werden, wenn er beendet ist) und für jedes der beiden Server-Binaries jeweils einen weiteren, die auf die Einrichtung der Umgebung durch den ersten warten. Wovon man diesen dann wieder abhängig macht (ich würde ihn zu den Netzwerk-Services zählen wollen), muß man nur gucken.

Und den automatischen Neustart, wenn einer der Services unerwartet beendet wurde, erhält man damit auch gleich noch - schaut man in die AVM-Services, sind mind. die Parameter Restart und RestartSec auch im AVM-systemd implementiert. Was die bedeuten, findet man in der systemd-Hilfe: https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html

 

[f-user]

Danke PeterPawn für deine Ausführungen und Tips!

Ich war gestern zu müde, um als blutiger Amateur das so genau und oft zu lesen, daß ich das wirklich alles nachvollziehen könnte - und selbst jetzt bin ich noch nicht dort.

Aber ein Wort ist dann doch gleich hängen geblieben, so daß ich dann doch wieder aufstehen und den Rechner noch einmal anschalten mußte, um das zu testen, was mir deswegen als Idee gekommen ist: Symlinks.

Außerdem hatte ich schon beim ersten Lesen den Eindruck, daß ein Mißverständnis vorliegen könnte.

Diese ganze Akrobatik, zu der ich mich gezwungen sehe, liegt, zusätzlich zu meiner Amateurhaftigkeit, in der Tatsache begründet, daß der poplige 8,5 MB Fritz-NAS-Speicherplatz der 7530 viel zu klein ist für die Rustdesk-Binardateien. Dazu noch die nicht vorhandene Möglichkeit, den Binärdateien per Befehlsoption einen anderen Pfad zum Schreiben von Daten zu geben in einer Umgebung in der sie nicht schreiben dürfen... Auf einer 7690 oder 5690 Pro wäre das kein Problem, da wäre der Fritz-NAS-Speicherplatz mehr als ausreichend - auch auf einer 7490 - wenn denn rustdesk server für MIPS kompilierbar wäre...

Aber: Dank deiner Ausführungen hast du mich auf die lösende Idee gebracht: Symlinks.

Jetzt ist alles ganz einfach: Die Binärdateien mit in die Freetz-Firmware schreiben (z.B. unter /opt/...) und dann im Fritz-NAS-Speicher je einen Symlink auf diese erstellen und diese dann aufrufen. Ergebnis: die Datenbanken werden jetzt auf dem beschreibbaren Fritz-NAS-Speicher abgelegt und die Binärdateien brauchen nicht mehr auf einem Stick zu sein, weil ihr tatsächlicher Ablageort keine Schreibrechte mehr braucht.
Kein "sleep" mehr nötig um auf das Einhängen eines USB-Sticks zu warten, nur noch je 1 Zeile in crontab und rc.custom - wobei natürlich andere Ausführungsvarianten, wie sie NanoBot vorgeschlagen hat, möglich wären.

Eigentlich ganz einfach...

(Natürlich hat das ganze den Nachteil, daß bei einer neuen Version des RusDesk Servers die Freetz-Firmware neu erstellt werden muß.)

Jetzt muß ich mich nur noch mit dem Systemd-Thema beschäftigen, um die Binärdateien bei (ungewollter) Beendigung wieder automatisch starten zu lassen.

Das größte "Problem" ist jedoch jetzt gelöst!.

Vielen Dank also noch einmal für die Ausführungen und Hinweise!

 

[f-user]

Heute habe ich mich dann doch endlich mal an das Systemd-Thema gewagt. Mehr aus Interesse und "proof of concept" denn aus Notwendigkeit, denn die Rustdesk-Server-Programme sind bei mir bislang nur das eine Mal abgestürzt, so daß ein automatisches Neustarten lassen nicht wirklich ein Thema war.

Als Amateur und Nutzer einer Systemd-freien Distribution war es wieder mal eine hakelige Angelegenheit, immerhin mit Erkenntnisgewinn.

Ich habe mich an einer Anleitung orientiert, die natürlich für Rechner gedacht war.

Es ging schon damit los, daß bei der Fritzbox kein /etc/Systemd/System-Verzeichnis existiert. Das hätte ich wohl "erstellen" können (habe ich auch mal bei einem der vielen Versuche), habe aber letztendlich doch mit /lib/Systemd/System gearbeitet. Die dort vorhandenen .system-Dateien habe ich mir auch mal angeschaut und die Reihenfolge der Einträge z.T. für meine .system-Dateien übernommen.

Desweiteren gibt es bei der Fritzbox systemctl nicht, dort ist es svctl.

Beim ersten Versuch wurden die erstellten Dienste als nicht existent betrachtet.

Dann habe ich erst einmal einiges auskommentiert. Nach vielen Tests hat sich herausgestellt, daß es beim Fritzbox-Systemd die Option "WorkingDirectory" nicht gibt. Dies hat wiederum die gleichen Konsequenzen, die dazu führen, daß ich Symlinks verwende.

Der hbbr-Dienst wurde nämlich schon recht früh in meinen Tests wie erwartet ausgeführt, der hbbs-Dienst hingegen immer als gescheitert angezeigt. Der Dienst zum Öffnen der Ports (der allerdings lediglich auf das Skript verweist) wird als inaktiv angezeigt Das scheint aber ok zu sein.

Letztendlich mußte ich den hbbs-Dienst auch auf ein Skript verweisen lassen, damit er korrekt ausgeführt wird. Ich vermute mal, daß das daran liegt, daß das Fritzbox-System keine WorkingDirectory-Option hat und deshalb hbbs trotz Aufruf über den Symlink in dem Verzeichnis ausgeführt wird, in dem die Binärdatei auch tatsächlich liegt, wo sie aber keine Schreibrechte hat - siehe frühere Einträge. Also habe ich (ungern) den Dienst auf ein Skript verwiesen, das mittels "cd " Befehl dann doch das machen kann, was die wohl die "WorkingDirectory"-Systemd-Option sonst erledigen würde - und zwar die Ausführung der Binärdatei im Verzeichnis des Symlinks und damit in einem Verzeichnis mit Schreibrechten. Damit läuft dann der Dienst auch korrekt.


Das Aufrufen mittels Systemd funktioniert also prinzipiell. Ob dadurch ein Absturz des Rustdek-Servers korrigiert wird, werde ich vermutlich aber nie erfahren, weil das Problem vorher nur einmal aufgetreten ist und ich erst einmal herausfinden muß, ob ein Absturz samt Neustart auch irgendwo festgehalten wird. Das ich zufällig "live" mitbekomme, daß der Dienst auf einmal nicht mehr geht und dann kurz darauf doch wieder (und das keine andere Ursache als Absturz und Neustart des Dienstes) ist wohl unwahrscheinlich.

Wie auch immer, vielen Dank für die Tips und Hilfestellungen. Sie haben erst dazu geführt, daß ich das in Erwägung gezogen und mich daran gewagt habe.


Die hbbr.system-Datei sieht (stellvertretend für die anderen beiden) so aus bei mir (der Befehl verweist auf den Symlink in dem Verzeichnis mit Schreibrechten (hbbr braucht aber keine); da das aber nicht wirklich so funktioniert wie gewollt wg. der fehlenden WorkingDirectory-Systemd-Option, hätte ich den Befehl auch auf das /opt/...-Verzeichnis lenken können, in dem die Binärdatei sich tatsächlich befindet):

[Unit]
Description=RustDesk Relay Server.

[Service]
After=network.target
Type=simple
ExecStart=/var/media/ftp/rustdesk-server/hbbr -k _
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

 

[fritzboxnewbee]

@ F-user
vielen Dank für das Thema Fritzbox als rustdesk -server, habe es mit Interesse mehrfach gelesen oder studiert, leider mit der Erkenntnis, daß ich ich nicht alles wissen und verstehen kann und am Ende doch nicht schlauer geworden bin . Liegt vielleicht an meinen Erfahrungen mehr mit Windows als mit Linux. Kann zwar die Fritzbox ein wenig verändern ( GPON-Seriennummer anpassen) aber etwas drauf laufen lassen ist mir ein Rätzel mit 7 Siegeln.
Deshalb kurze Frage , habe mir den rustdesk-server auf einem Rechner im Heimnetz ( Windows 2024) eingerichtet , läuft und die anderen im Netz funktionieren auch alle über diesen meinen eigenen rustdesk server nun. Leider muss der Rechner immer an sein ...., schade da die Fritzbox ja auch immer läuft.
Mit der Zeit der Eigentümer Wechsel sind auch die Internetzugänge geändert, so das nun ungenutzt eine 6490 eine 7490 und eine 7590 rumstehen und die 6850 und 5590 nun ihren Dienst tun. Kann ich eine der beiden bezüglich der AVM Hardware für den rustdesk-server überhaupt nutzen, und wenn ja gibt es vielleicht eine Anleitung für Beginners wie oder kann ich ein Image dafür von Dir bekommen ?