Wie kann ich eigene binaries beim booten starten ?

[Nanobot]

Ich möchte testweise auf meiner Zgemma Box einen Rustdesk-Server installieren. DIe binaries für arm_v7 lassen sich auch problemlos manuell starten.

Jetzt sollen diese binaries beim booten automatisch gestartet werden. Ist es ausreichend, ein entsprechendes Script im Ordner /etc/init.d zu speichern und ausführbar zu machen ? Oder sind dazu weitere Einstellungen erforderlich ?

C.U. Nanobot

[vanhofen]

Ich möchte testweise auf meiner Zgemma Box einen Rustdesk-Server installieren. DIe binaries für arm_v7 lassen sich auch problemlos manuell starten.

Jetzt sollen diese binaries beim booten automatisch gestartet werden. Ist es ausreichend, ein entsprechendes Script im Ordner /etc/init.d zu speichern und ausführbar zu machen ? Oder sind dazu weitere Einstellungen erforderlich ?

C.U. Nanobot

Erstelle dein eigenes init-Script und lege es nach /var/etc/init.d
Das wird dann beim Start mit ausgeführt und wird bei einer Settingsübernahme auch mitgenommen.

Eigene Sachen immer nach /var!

[Nanobot]

Also muß das Script nach /var/etc/init.d

Ich muß jetzt nur noch probieren, die vorhandenen Scripte zu einem gemeinsamen Script zusammen zu fassen, welches dann auf die Parameter "start", "stop" und "restart" reagiert, denn so ist es bei den anderen Scripten ja auch gemacht. Da kann ich ja bei den in /etc/init.d vorhandenen Scripten abgucken.

Bisher nutze ich "StartRustdeskServer.sh"

Code: Alles auswählen

#!/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"

Code: Alles auswählen

#!/bin/sh

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

Falls es jemand interessieren sollte: Die vorkompilierten Binaries des rustdesk-servers für die Platform Arm_v7 laufen sowohl auf der ZGemma H7x, als auch auf der Axas E4HD 4K Ultra HD problemlos. Nur das mit dem Autostart muß ich noch hinkriegen, daher die Frage, wie ich das richtig mache.

C.U. Nanobot

[Don de Deckelwech]

Hi,
ok, laut Wikipedia ist Rustdesk eine Fernsteuersoftware ala Teamviewer.
Aber was bringt mir das auf einer STB genau? Kannst du das mal kurz erklären, muss kein Roman werden, nur deinen Anwendungsfall kurz skizziren, danke.

Ciao,
DdD.

[Miky]

Eigene Sachen immer nach /var!

Zur Erklärung: Scripte die nicht unter /var liegen sind nach einem Update verschwunden.

[vanhofen]

@Nanobot, nach einem Verzeichniswechsel musst du nicht eine Sekunde schlafen. Ganz sicher nicht.
Nimm das raus.

[Nanobot]

@Don De Deckelwech
Es gibt in Deutschland nur einen öffentlichen Rendevous-Server für Rustdesk. Wenn der mal temporär ausfällt, können keine Verbindungen hergestellt werden. Um dies zu vermeiden empfiehlt sich der Betrieb eines eigenen Servers, was zudem weitere Vorteile hat:

Ein eigener Server kann so konfiguriert werden, daß sich nur Clienten, welche den richtigen Key kennen, dort anmelden können. Zudem wird mit gesetztem Key der gesamte Traffic verschlüsselt. Außerdem kann man bei Betrieb eines eigenen Servers sehen, welche der in der Favoritenliste eingetragenen Peers gerade online sind, während dies am öffentlichen Server nicht der Fall ist.

Nun muß ein solcher Server auf einem Gerät laufen, welche 24/7 eingeschaltet ist aber nicht zu viel Strom verbraucht. Somit bietet es sich an, ihn ggf. auf einer Fritz!Box laufen zu lassen, was derzeit aber nur bei Modellen mit Arm CPU möglich ist. Da ich eine 7530 und eine 7690 besitze läuft der Server bei mir dort. Ein Bekannter möchte jetzt auch einen eigenen Server betreiben, hat aber eine 7590 (mips). Aber er besitzt zwei Axas E4HD Ultra 4k, welche bekanntlich die Arm_v7 Architektur nutzen und eine dieser beiden Boxen ist 24/7 eingeschaltet. Daraus resultiert die Idee, den Rustdesk-Server auf dieser STB laufen zu lassen.

@Miky
Mir ist klar, daß der Ordner "/opt/rustdesk" und die darin enthalteten Dateien nach einem Update weg sind, sofern man nicht selber etwas an den Update-configs ändert. Aber derjenige, auf dessen Box das Ganze laufen soll macht sowieso nie Updates seiner STBs. Der ist sogar zu faul regelmäßig einen neuen Sendersuchlauf zu machen

@vanhofen
Klar, das sleep 1 ist nur ein Überbleibsel aus meinen ersten Tests, welche ich damals zunächst auf einer 7530 gemacht hatte. Inzwischen läuft der Server bei mir auf einer 7690 und das sleep 1 kann natürlich raus.

C.U. Nanobot

P.S.: Hinzugefügt, daß es in Deutschland nur einen öffentlichen Server gibt.

[Gorcon]

Warum keinen Raspberry Pi dafür nutzen?

[Nanobot]

Weil man in meinem Fall den Rasberry Pi erst kaufen müßte und er zusätzlich, wenn auch relativ wenig, Strom verbrauchen würde.
Die Fritz!Box bzw. die Axas-Box sind dagegen schon vorhanden und laufen sowieso 24/7. Ansonsten könnte man den Server natürlich auch auf ein Rasberry Pi laufen lassen, denn auch der nutzt ja eine Arm CPU.

[Nanobot]

So, ich habe eben mal probiert ein geeignetes Startscript für den RustDeskServer zusammen zu basteln:

Code: Alles auswählen

#!/bin/sh

case "$1" in
	start)
	cd /opt/rustdesk
	/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 &
	;;

	stop)
	killall hbbr > /dev/null
	killall hbbs > /dev/null
	;;

	restart)
	killall hbbr > /dev/null
	killall hbbs > /dev/null

	cd /opt/rustdesk
	/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 &
	;;

	*)
        echo "usage: start | stop | restart"
        exit 1
        ;;
esac

Beim manuellen Aufruf macht dieses Script was es soll. Bei meinem ersten Versuch, es mit dem Namen "rustdeskserver" nach /var/etc/init.d zu schieben und dann zu rebooten wurde es aber offenbar nicht ausgeführt, denn hbbs und hbbr laufen nicht. Ich teste das Script im Moment zwar nicht mit dem NI Image, sondern mit dem BPanther Image, und dort ist /etc, im Gegensatz zum NI, nur ein Link nach /var/etc, aber das sollte ja keinen Unterschied machen. Die Rechte hatte ich versehentlich auf 766 und habe sie jetzt auf 755 geändert, weil es bei den anderen Init-Scripten auch so ist.

Daher jetzt zwei Fragen zum besseren Verständnis:

Wenn ich das Script manuell starte gebe ich ja die Parameter start, stop oder restart mit. Woher weiß der init Vorgang beim booten was er machen soll, wenn solch ein Parameter nicht vorhanden ist ? Nimmt er dann automatisch immer den ersten "case", oder nimmt er immer den "case" mit dem Namen "start", oder wie funktioniert das ?

Muß ich dieses Script unter Umständen irgendwie in eines der Verzeichnisse unter "(/var)/etc/rc.d/rc.x" für die einzelnen runlevel verlinken, damit es in Abhängigkeit vom runlevel überhaupt ausgeführt wird ?

C.U. Nanobot

[Nanobot]

Beim Vergleich des BPanther und des NI Images habe ich festgestellt, daß beim BPanther Image die Datei rcS schon längere Zeit kein Script, sondern eine Binärdatei ist. Vermutlich ist diese Besonderheit die Ursache dafür das mein eigenes Script unter /var/etc/init.d nicht wie erwartet ausgeführt wird. Nun gibt es beim BPanther aber die Scripte /var/etc/voremu.sh und /var/etc/vorneutrino.sh. Also habe ich die Befehle zum Start des Rustdesk-Servers einfach in die Datei voremu.sh eingetragen und es funktioniert: Der Server wird beim booten automatisch mit gestartet.

Da mein Bekannter, bei welchem ich den Rustdesk-Server einrichten soll ohnehin nur das BPanther Image auf seiner Axas-Box hat, ist mein Problem für den Moment gelöst. Ob die Nutzung eines eigenen Startscriptes unter init.d beim NI Image so funktioniert wie ich es erwarten würde werde ich bei Gelegenheit mal testen. Ich darf halt meine eigene Box nur dann neu starten, wenn gerade niemand fernsehen will.

[vanhofen]

Ich hatte echt vergessen, wie das Zeug tickt.

Du musst das Script nach /var/etc/init.d legen und dann zwei Symlinks erzeugen:

Code: Alles auswählen

cd /var/etc/init.d
ln -sf your-script S01your-script
ln -sf your-script K99your-script

Mit den Ziffern kannst du die gewünschte Reihenfolge festlegen, wenn du mehrere eigene Scripte hast.

01 == früh
...
99 == spät

[Nanobot]

Ich habe diese Thematik mal gegoogled und verstehe es folgermaßen:

Das Script in /etc/init.d muß im Ordner etc/rcx.d/ in Abhängigkeit des runlevels x verlinkt werden. Hierbei muß man entweder S(01-99)yourscript als Namen wählen, wenn das Script beim Wechsel in diesen runlevel etwas starten soll oder K(01-99)yourscript, wenn es etwas stoppen soll, zum Beispiel beim Herunterfahren oder Neubooten der Box. Die Zahl 01-99 regelt dabei bei einem Wechsel in den entsprechenden runlevel die Reihenfolge, in der die verlinkten Scripte abgearbeitet werden.

Ich habe aber offenbar eine wesentlich einfacher Methode gefunden, welche ich aber noch nicht getestet habe: Im NI Image gibt es, im Gegensatz zum BPanther, die Datei /etc/rc.local. Und dies wäre dann für mich die einfachste Methode, meine eigenen Binaries beim Booten der Box zu starten. Ich melde mich dann nochmal zurück, wenn ich diese Methode getestet habe.

[Janus]

Wie zuvor schon erwähnt, ist /var/usw./ die bessere Alternative, weil dort Deine eigenen 'Arbeiten' bei einem Update nicht überschrieben oder gelöscht werden.

[jokel]

Ich habe aber offenbar eine wesentlich einfacher Methode gefunden, welche ich aber noch nicht getestet habe: Im NI Image gibt es, im Gegensatz zum BPanther, die Datei /etc/rc.local. Und dies wäre dann für mich die einfachste Methode, meine eigenen Binaries beim Booten der Box zu starten. Ich melde mich dann nochmal zurück, wenn ich diese Methode getestet habe.

beste wahl

ps welche version hast du im einsatz .. 1.1.13 .. ?

[Nanobot]

@jokel
Du meinst sicher die Version des Rustdesk-Servers, und dies ist die im Moment aktuelle Version 1.1.14 mit der Architektur "linux-armv7". Diese Version läuft auf einer FB7530 (mit USB-Stick), einer FB7690, einer ZGemma H7C und einer Axas E4HD Ultra 4k (jeweils mit BPanther Image) bisher ohne Probleme. Ich hatte auf der FB7690 auch mal probiert, die Architektur "linux-arm64v8" zu verwenden, welche aber einen segfault wirft, weshalb ich dann wieder auf die armv7 zurück gewechselt habe.