[Frage] (mehrfaches) Mounten von Ressourcen (in einer chroot-Umgebung)

[FischersFreetz]

Hallo,
ich möchte Ordner-Strukturen, wie "USB-Laufwerk (uStor01)" oder "/proc" (in einer chroot-Umgebung) ein zweites Mal einbinden. Konkret handelt es sich um eine "gefreetzte" 7590 mit einer Firmware-Version 7.12. Das Mounten an sich ist erstmal nicht das Problem. Nach dem Einbinden verhält sich Alles zuerst erwartungsgemäß.

Aber jeweils am nächsten Morgen muss ich feststellen, dass die eingebundenen Ressourcen nicht mehr verfügbar sind. Irgendwer bzw. irgendwas muss sie "umounted" haben.Und nun stelle ich mir/euch einige Fragen:

1. Wer oder was auf der ist Box für das Mounten "zuständig"? Wo kann ich bei der Suche nach der Ursache ansetzen?
2. Warum oder wann werden Mountpoints "überprüft" und entfernt?
3. Wie kann ich Ressouren unter eigene Mountpoints ein weiteres Mal dauerhaft einbinden?

Hat jemand eine Idee, wie ich das Problem lösen könnte?

vielen Dank im Voraus
FischersFreetz

 

[FischersFreetz]

Ich habe erstmal den den Problemkreis eingrenzen können: Die mehrfachen "Mounts" werden während der Zwangstrennung aufgehoben. Irgendein Prozess stößt sich dabei an den mehrfachen Mountpoints und "räumt gründlich auf". (Wahrscheinlich/vielleicht weiß ein Prozess nicht, welchen Ordner er für den Onlinespeicher-Cache verwenden soll o.ä. und gerät ins Stolpern...)

Wie ließe sich dieses "Stolpern" verhindern?

(* Kann man eigentlich die Datei "/dev/sda1" problemlos (in die chroot-Umgebung) kopieren und diese dann einbinden? Oder ist das eine "dynamische" Datei? *)

 

[koyaanisqatsi]

Moinsen

Datei "/dev/sda1"

Nein.
Diese muss mit dem Tool "mknod" erzeugt werden.

mknod - LinuxWiki.org - Linux Wiki und Freie Software

www.linuxwiki.de

 

[PeterPawn]

Für die Lösung solcher Probleme gibt es getrennte Namespaces - und im Kernel 3.10.107, der von der 7490 verwendet wird, funktioniert das auch.

Wie man das nutzen kann, habe ich irgendwo im YourFritz-Repo mal mit einem Skript "get_page" gezeigt, das in der Lage war, eine gegebene Lua-Seite unter Nutzung verschiedener Text-Datenbanken von AVM (die liegen pro Sprache getrennt vor) mit den jeweils "sprachspezifischen Texten" zu versehen.

Dafür muß(te) auch diese Datenbank per bind-Mount an die richtige Stelle gebracht werden und damit andere Prozesse davon nicht beeinträchtigt werden, erfolgt das in einem privaten Namespace - somit sieht nur der per "unshare" aufgerufene Prozess die Änderung, weil auch er erst derjenige ist, der beim rekursiven Aufruf das "mount"-Kommando ausführt.

Da muß man ggf. etwas genauer hinschauen bzw. auch mal mit "set -x" arbeiten und es verfolgen, wenn man die Rekursion nicht auf Anhieb versteht. Deshalb wird das "debug" auch an die per "unshare" gestartete Shell-Instanz weitergereicht.

BTW: Das parallele Mounten ein und desselben Volumens (zumindest, wenn eines dieser "mount"-Kommandos einen Schreibzugriff zuläßt und es nicht alles nur r/o ist) ist - nebenbei - ein absolutes "no-go" ... nur falls die Frage nach "/dev/sda1" irgendwie in diese Richtung zielen sollte.

 

[FischersFreetz]

Für die Lösung ... gibt es getrennte Namespaces - und im Kernel 3.10.107, der von der 7490 verwendet wird, funktioniert das auch.

Es liegt hier (aber) eine 7590 (Kernelversion 3.10.104) vor. Wie sieht's dann aus?

Mit den anderen Aussagen muss ich mich erstmal auseinandersetzen...

... nur falls die Frage nach "/dev/sda1" irgendwie in diese Richtung zielen sollte.

Das war eher ein laienhafter Gedankenansatz als eine wirklich zielgerichtete Überlegung.

 

[PeterPawn]

Wie sieht's dann aus?

Ausprobieren ... ich habe gar kein Auto, Senorita. Beziehungsweise keine 7590 in diesem Falle ...

 

[FischersFreetz]

Ausprobieren ...

Hab' ich gemacht... und es funktioniert.

Ein (mehrfaches) Mounten in einer chroot-Unmgebung (hier lighttpd) gelingt mit getrennten Namespaces bei Verwendung von unshare ... - Danke an PeterPawn für die entsprechenden Hinweise - z.B.:

unshare --mount /bin/bash -c "mount mountoptionen; /etc/init.d/rc.lighttpd start"

Eine Beschreibung zur Anwendung von "unshare" findet man z.B. [ hier ] oder [ da ].

Ich habe zum Starten des lighttpd-Webservers dazu die "rc.lighttpd" noch wie folgt angepasst (vgl. hier Zeile 69 ff):

...
case $1 in
...
start)
        if [ -n "$LIGHTTPD_MOUNT" ]; then
            if [ "$2" = "private_ns_mount" ]; then
                mount -o bind,private "$LIGHTTPD_MOUNT" "$LIGHTTPD_DOCROOT/$(basename $LIGHTTPD_MOUNT)"
            else
                unshare --mount --propagation=private /bin/sh $0 "$1" private_ns_mount
                exit $?
            fi
        fi
        modlib_start
        ;;
...

"$LIGHTTPD_MOUNT" habe ich als neue Variable in die "/mod/etc/conf/lighttpd.cfg" eingetragen. Mit ihrer Hilfe kann man das Mounten steuern (wenn sie leer ist, erfolgt kein Mounten, sonst legt sie den Ordner fest, der eingebunden werden soll).

Gibt es eigentlich eine Möglichkeit, den privaten Mount-Namespace des "chroot-Containers" von "außen" im Nachhinein einzusehen bzw. zu bearbeiten?

---------------------------------------------------------------------
Beim Ausprobieren stellte ich noch eine Ungereimheit bei Verwendung der "/etc/init.d/rc.lighttpd" fest:

#> /etc/init.d/rc.lighttpd status
running
#>  /etc/init.d/rc.lighttpd load
lighttpd web server is disabled.
#> /etc/init.d/rc.lighttpd status
running

 

[FischersFreetz]

Das "unshare Mounten" eines Verzeichnisses in der chroot-Umgebung hat sich an sich bewährt. Jedoch so "unsichtbar", d.h. ohne Einfluss auf die restliche Umgebung, ist diese Lösung aber doch nicht.

Ich habe feststellt, dass nach einem Onlinechanged-Ereignis (Zwangstrennung bzw. Neu verbinden), die Verbindung zum Onlinespeicher nicht wiederhergestellt werden kann, wenn der "unshare Mount" aktiv ist.

AVM System > Ereignisse (nach reconnect mit lighttpd gestartet)
21.06.20 17:07:31 Verbindung zum Online-Speicher konnte nicht hergestellt werden. Fehler: Verzeichnis Online-Speicher kann nicht angelegt werden.
21.06.20 17:07:30 Running onlinechanged: onlineipv6
21.06.20 17:07:30 Verbindung zum Online-Speicher konnte nicht hergestellt werden. Fehler: Verzeichnis Online-Speicher kann nicht angelegt werden.
21.06.20 17:07:29 Running onlinechanged: online
21.06.20 17:07:29 Internetverbindung wurde erfolgreich hergestellt. IPv4 wird über DS-Lite genutzt. AFTR-Gateway: aftr.hhb1902aihr001.versatel.de, IPv4-MTU: 1500, Breitband-PoP: hhb1902aihr001, LineID: 1UND1.DEU.DTAG.HNYMB.
21.06.20 17:07:29 IPv6-Präfix wurde erfolgreich bezogen. Neues Präfix: xxxx:xxxx:xxxx:xxxx::/xx
21.06.20 17:07:29 Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
21.06.20 17:07:28 Information des Anbieters über die Geschwindigkeit des Internetzugangs (verfügbare Bitrate): 51300/11136 kbit/s
21.06.20 17:07:20 Verbindung zum Online-Speicher konnte nicht hergestellt werden. Fehler: Verzeichnis Online-Speicher kann nicht angelegt werden.
21.06.20 17:07:19 Running onlinechanged: offlineipv6
21.06.20 17:07:19 Verbindung zum Online-Speicher konnte nicht hergestellt werden. Fehler: Verzeichnis Online-Speicher kann nicht angelegt werden.
21.06.20 17:07:19 Verbindung zum Online-Speicher beendet.
21.06.20 17:07:16 Running onlinechanged: offline
21.06.20 17:07:15 Internetverbindung wurde getrennt.
21.06.20 17:07:15 Internetverbindung IPv6 wurde getrennt, Präfix nicht mehr gültig.

freetz onlinechanged.log
2020-06-21 17:07:16 [8111]: [offline] approved
2020-06-21 17:07:16 [8111]: [offline] executing /etc/onlinechanged/00-get_ip
2020-06-21 17:07:16 [8111]: [offline] executing /etc/onlinechanged/webdav_net
2020-06-21 17:07:16 [8111]: [offline]  * webdav_net offline status_onlinev6
2020-06-21 17:07:16 [8159]: [offlineipv6] waiting
2020-06-21 17:07:17 [8111]: [offline]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:19 [8111]: [offline]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:19 [8111]: [offline]  * 7
2020-06-21 17:07:19 [8111]: [offline]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:19 [8111]: [offline]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:19 [8111]: [offline] executing /tmp/flash/onlinechanged/onlinechanged-cgi
2020-06-21 17:07:19 [8111]: [offline] finished

2020-06-21 17:07:19 [8159]: [offlineipv6] approved
2020-06-21 17:07:20 [8159]: [offlineipv6] executing /etc/onlinechanged/00-get_ip
2020-06-21 17:07:20 [8159]: [offlineipv6] executing /etc/onlinechanged/webdav_net
2020-06-21 17:07:20 [8159]: [offlineipv6]  * webdav_net offlineipv6 status_offline
2020-06-21 17:07:20 [8159]: [offlineipv6]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:20 [8159]: [offlineipv6]  * 7
2020-06-21 17:07:20 [8159]: [offlineipv6]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:20 [8159]: [offlineipv6]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:20 [8159]: [offlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
2020-06-21 17:07:20 [8159]: [offlineipv6] finished

2020-06-21 17:07:29 [8370]: [onlineipv6] waiting
2020-06-21 17:07:29 [8366]: [online] approved
2020-06-21 17:07:29 [8366]: [online] executing /etc/onlinechanged/00-get_ip
2020-06-21 17:07:29 [8366]: [online] executing /etc/onlinechanged/webdav_net
2020-06-21 17:07:29 [8366]: [online]  * webdav_net online status_onlinev4
2020-06-21 17:07:29 [8366]: [online]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:29 [8366]: [online]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:30 [8366]: [online] executing /tmp/flash/onlinechanged/onlinechanged-cgi
2020-06-21 17:07:30 [8366]: [online] finished

2020-06-21 17:07:30 [8370]: [onlineipv6] approved
2020-06-21 17:07:30 [8370]: [onlineipv6] executing /etc/onlinechanged/00-get_ip
2020-06-21 17:07:30 [8370]: [onlineipv6] executing /etc/onlinechanged/webdav_net
2020-06-21 17:07:30 [8370]: [onlineipv6]  * webdav_net onlineipv6 status_onlinev4v6
2020-06-21 17:07:31 [8370]: [onlineipv6]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:31 [8370]: [onlineipv6]  * rmdir: '/var/media/ftp/Online-Speicher': Device or resource busy
2020-06-21 17:07:31 [8370]: [onlineipv6] executing /tmp/flash/onlinechanged/onlinechanged-cgi
2020-06-21 17:07:31 [8370]: [onlineipv6] finished

Wird vor den reconnect der lighttpd-Webserver bzw. der "unshare Mount" beendet, dann wird die Verbindung zum Onlinespeicher wiederhergestellt.

Kann mir jemand dieses Verhalten erklären? Oder noch besser:
Kann mir jemand einen Tipp geben, wie dieser unschöne Seiteneffekt abgestellt werden könnte?