Systemvariablen persistieren

    Hallo zusammen,


    ich suche nach einem zuverlässigen Weg, Systemvariablen bei meiner TS-464 mit QTS 5.1 zu definieren, die auch ein Firmwareupdate überstehen.

    Aktuell habe ich aber das Gefühl, dass das nur funktioniert, wenn Mars, Venus, Uranus und Jupiter eine Linie bilden. X/


    Laut Google scheint der einzige Weg zu sein, das per autorun zu realisieren.


    Daher habe ich mich hier entlang gehangelt:
    Running Your Own Application at Startup - QNAPedia


    ...und somit folgendes gemacht:

    Code
    mount $(/sbin/hal_app --get_boot_pd port_id=0)6 /tmp/config
vi /tmp/config/autorun.sh
chmod +x /tmp/config/autorun.sh
umount /tmp/config
/etc/init.d/init_disk.sh mount_flash_config
/etc/init.d/init_disk.sh umount_flash_config


    Der Inhalt der autorun.sh wird mir nun auch in der GUI, unter System > Hardware > "autorun.sh anzeigen" angezeigt.

    Bash: autorun.sh
    #!/bin/sh
/share/CACHEDEV1_DATA/homes/user/scripts/setenv.sh

    Damit ich etwas flexibler beim Definieren von Variablen bin, rufe ich mit der autorun.sh ein anderes Skript auf, wo die eigentlichen Variablen definiert sind.

    Aber scheinbar scheitert es schon am Autostart.


    Ich bin also Dankbar für Lösungsvorschläge

    ... Skripte im Autostart ausführen zu können

    und/oder

    ... um individuelle Systemvariablen zu persistieren


    Beste Grüße

    Ben

    Ich habe auf allen NAS (von QTS 4.2.6 bis 5.1.2) die autorun mit diesem Script erstellt und es funktioniert überall, wie es soll.


    Gruss


    Edit: Eigentlich ist nur das 2. Script im ersten Post von Interesse, danach dann die autorun.sh wie gewünscht anpassen (Befehle beim Start bzw. Befehle vor Poweroff).

    Super, vielen Dank!
    Tut genau was es soll. 8)

    Nee, Moment... Das Autostartthema ist erledigt.

    Hier meine setenv.sh

    Code: setenv.sh
    #! /bin/sh
export DOCKER_DATA="/share/CACHEDEV1_DATA/Container/persistent"
log_tool -a "autorun.sh executed" -t 0 -u bf -p 127.0.0.1 -m MYNAS -N "Autorun" -G "Settings"


    Die log_tool Zeile habe ich als Kontrolle eingefügt, um zu sehen, ob das Skript durch autorun.sh ausgeführt wird.

    Der Logeintrag wird geschrieben - die Variable DOCKER_DATA aber nicht.

    Was mache ich falsch?

    4 Mal editiert, zuletzt von n0cturne () aus folgendem Grund: Ein Beitrag von n0cturne mit diesem Beitrag zusammengefügt.

    Gefällt mir 1

    Dein Problem ist im Verständnis der Funktion von Unix-Prozessen und -Variablen.


    Beispiel:

    Nimm eine beliebige Unix-Shell, ob ssh auf das NAP oder irgendein Linux ist egal, auch Mac oder WSL funktionieren. Schreibe dort das folgende Skript t.sh

    Code
    TEST=Hallo
echo $TEST

    Anschließend chmod 755 t.sh nicht vergessen.


    Jetzt ruf das Skript auf und lass dir anschließend die dort definierte Variable anzeigen:

    Code
    $ t.sh 
Hallo
$ echo $TEST

$

    Du siehst, im Skript ist die Variable TEST korrekt deklariert und bekannt, aber danach in der Shell ist diese Variable nicht bekannt.


    Grund ist, dass jeder Unix-Prozess die Umgebungsvariablen lokal in seinem Speicher liegen hat (bei Erzeugung des Prozesses werden sie durch ein fork() mit dem Speicher des Parent-Prozesses kopiert). Wenn jetzt weitere Variablen angelegt werden, bleiben die lokal um Speicher, der Parent-Prozess erfährt davon aber nichts.


    Auch mit dem Schlüsselwort export änderst du nichts daran, da sich das nur auf weitere Child-Prozesse auswirkt, nicht aber auf den übergeordneten Prozess.


    Mit einem . vor dem Befehl wird für das Skript kein eigener Prozess gestartet, sondern das Skript wird im Kontext des aufrufenden Prozesses gestartet. Das hat insbesondere zur Folge, dass Variablenänderungen auch dem Aufrufer bekannt sind:

    Code
    $ . t.sh
Hallo
$ echo $TEST
Hallo
$

    Allerdings kann nur der aufrufende Parent-Prozess die Variablenübernahme erlauben. Der Child-Prozess hat keine Möglichkeit, dies zu erzwingen. Und in dem Beispiel ist die Variable TEST jetzt zwar in dem Shell-Prozess bekannt, aber keineswegs in dem Prozess, der die Shell gestartet hat.


    Für deine Anwendung in autorun.sh heißt das, die Variable DOCKER_DATA bleibt auf dein Skript beschränkt und ist dem Prozess, der autorun.sh aufruft, nicht bekannt, geschweige denn dem Prozess, der die Variable auswertet (beim Docker-Start?). Deine Idee, in autorun.sh einfach eine Variable zu setzen, ist also zum Scheitern verurteilt.


    Du musst die Variable dort setzen, wo sie gebraucht wird. Dies wird wohl irgendein Docker-Startskript sein. Jenes Skript musst du ändern. Sollte die Änderung nicht persistent sein - ich traue Qnap zu, dass das Skript bei jedem Reboot neu aufgebaut wird - dann muss autorun.sh jenes Skript ändern, z. B. mit sed, awk oder einem simplen cat.


    EDIT: Eventuell ist es einfacher, in autorun.sh die Datei /etc/profile zu ändern oder eine Datei in /etc/profile.d zu kopieren. Ob das funktioniert, hängt davon ab, wann der Docker-Prozess gestartet wird, d. h. ob die Änderung zum rechten Zeitpunkt kommt. Das musst du ausprobieren.

    Einmal editiert, zuletzt von Anthracite ()

    Danke für die Aufklärung. Ich bin Deinem Tipp gefolgt und schreibe nun per autorun.sh die Variable in /etc/profile. Leider scheint tatsächlich die autorun.sh nach der Container Station ausgeführt zu werden.


    Gibts noch andere Vorschläge, wie ich die Variable ins System bekomme?

    Hallo, ich habe ein ähnliches Thema.


    Ich würde gern Variablen verwenden wenn ich mich mit ssh -T (non-interactive) ans NAS verbinde um Befehle auszuführen. Bspw. macht das ansible bzw. der virsh Befehl (mit qemu+ssh:///NAS/system).


    Diese aber lesen - wie n0cturne schreibt - die /etc/profile leider nicht aus.


    Unter "normalen" Linux Varianten (Debian, RHEL) gibt es eine /etc/environment die vom init Prozess "gesourced" wird. Fallen euch evtl. noch Scripte ein die *nach* der autorun.sh gestartet werden? Evtl. könnte man auch die Umgebungsvariablen mittels SetEnv in der sshd_config hinterlegen [1]. Aktuell kenne ich mich hier aber noch nicht mit dem init System von QNAP aus.


    Frage an den Threadersteller um den Topic nicht zu sprengen: Was ist eigentlich dein Usecase mit den Umgebungs Variablen?


    [1] https://man7.org/linux/man-pages/man5/sshd_config.5.html

    2 Mal editiert, zuletzt von nasgemacht () aus folgendem Grund: erklären was in der sshd_config gemacht werden soll