@eisbaerin:
Willst Du mich veralbern oder willst Du mich nur provozieren?
Was ist an #1360 "hoch wissenschaftlich"?
Da ist ein Verweis auf das entsprechende "modscript" im Beitrag und eine Erläuterung, wann die "/etc/profile" bei einer Shell
überhaupt zum Einsatz kommt (was sie ja deutlich von der "rc.user" unterscheidet). Was diese "mod_profile" ansonsten macht, steht in #1 ... ich kann auch nichts dafür, daß es seit Xenforo keine Tabellen mehr gibt und somit das "Lesen" dort entsprechend schwerer geworden ist.
Woher weißt Du eigentlich so genau, daß
@full2000 jemand ist, der in Deinen Augen nur als "einfacher Nutzer" durchgeht und welche Formulierung in #1360 ist es denn genau, die Du Deinerseits für "hoch wissenschaftlich" hältst und damit als Erklärung für ungeeignet ansiehst? Ist das nicht auch etwas überheblich gegenüber den (unterstellten) (Un-)Fähigkeiten von anderen?
Ansonsten kann ich Dir aber auch gerne noch mit Informationen weiterhelfen, was ich mir bei bestimmten Änderungen gedacht habe.
Die Frage
(Warum ist das so tief verschachtelt???)
wäre dann damit zu beantworten, daß ich dabei davon ausgehe, daß unter "/var/custom" ein komplettes Image gemountet wird (quasi als "System im System"), welches selbst wieder über eine zum Wurzelverzeichnis nach LSB analoge Struktur aufweist. Dazu gehört dann ein "/etc"-Verzeichnis, in dem die "systemweiten Einstellungen" liegen, genauso, wie ein zusätzliches "bin"-, "sbin"-, "usr/bin"-, "usr/sbin"- und "lib"-Verzeichnis ... auch für diese ergeben sich beim Mounten dieser "virtuellen Wurzel" unter "/var/custom" dann entsprechende Pfade, die "so verschachtelt" sind.
Kann man die nicht hinterher noch übermounten?
Logisch kann man ... aber die Frage ist ja: "Sollte man auch?" - wenn man die "/etc/profile" ohnehin "übermounten" will, braucht man die gesamte Modifikation nicht. Warum habe ich das abgesetzt? Weil ich mich auch auf verschiedenen Modellen und Versionen nicht gesondert darum kümmern will, was AVM da in der "/etc/profile" ansonsten noch so macht (z.B. den Aufruf von "getcons" in der ersten Session) und ob sich das irgendwann irgendwie ändert ... und weil ich lange nicht auf jeder Box dieselben Inhalte in einer solchen "Erweiterung" der "/etc/profile" stehen haben will - was ebenfalls die direkte Modifikation der "/etc/profile" nur als zweitbeste Lösung erscheinen läßt. Bei der Verwendung des Konstrukts:
Code:
[ -f /var/custom/etc/profile ] && . /var/custom/etc/profile
wird hingegen ganz sauber auf die Existenz einer solchen Erweiterung getestet (die kann meinetwegen überall liegen ... packt man sie auf einer Box mit einem "wrapper"-Verzeichnis dort hinein, ist sie sogar persistent änderbar auf VR9-Modellen) und nur wenn sie vorhanden ist, werden die dort eingetragenen Kommandos auch "inkludiert" - was hier wieder entscheidend ist, weil eine Sub-Shell automatisch dazu führen würde, daß vorgenommene Einstellungen mit der zusätzlichen Instanz auch wieder "sterben".
BTW: Eine einfache Gebrauchsanweisung für das "mod_custom_images" suche ich auch noch.
Da kann ich Dir (auch wenn Du das nur mal "beiläufig" fallen lassen wolltest) leider auch nicht wirklich weiterhelfen ... aus Deiner Formulierung muß ich ja wohl schließen, daß Dir
diese Erläuterungen nicht "einfach" genug sind - an "nicht ausführlich genug" wird es ja hoffentlich nicht liegen. Aber die einzige Chance, die ich dann meinerseits sehe, wäre die Beantwortung
konkreter Fragen zu den Teilen, die Du (oder jemand anderes) nicht verstanden ha(s)t aus der verlinkten Beschreibung - aus diesem Kontext der Verwendung eines solchen "custom images" ergibt sich dann auch noch einmal eine ausführlichere "Begründung" für die überbordende "Verschachtelung", die ggf. die oben abgegebene Erklärung dazu ergänzen kann.
Einfacher als eine aus dem Chinesischen ins Deutsche übersetzte Gebrauchsanweisung wird das vermutlich immer noch zu lesen sein ... ansonsten steht es jedem (der den Inhalt verstanden hat) ebenso wieder frei, mit gutem Beispiel voranzugehen und meine "hochwissenschaftliche Erklärung" (falls diese Klassifikation für #644 auch gelten sollte) so umzusetzen, daß auch der "einfache Nutzer" (wer auch immer das sein mag und wie gut der sich genau auskennt - ich kenne ihn halt nicht, aber Du ja offenbar dann doch) etwas davon hat. Hat so jemand selbst Schwierigkeiten mit dem Verständnis, habe ich mich (sofern es tatsächlich um von mir geschriebene Sachen geht und nicht um "Wie bediene ich die Konsole und was ist denn dieses Vieh, von dem alle immer schreiben, wenn sie Dateien bearbeiten wollen?") bisher m.W. auch noch nie geweigert, weitere Erläuterungen oder Hilfestellungen zu geben.
Ich verwende jedenfalls genau so einen Mechanismus auch bei mir (gut, mit ein paar anderen Anweisungen in der E99-custom, weil ich noch die Signatur von Images über "tr069fwupdate" prüfen lasse, aber das Prinzip ist noch genau dasselbe):
Code:
root@FB7490:~ $ l /etc/init.d/ | grep wrapper
lrwxrwxrwx 1 root root 30 Thu Nov 9 18:41:40 2017 E99-custom -> /wrapper/etc/init.d/E99-custom
lrwxrwxrwx 1 root root 30 Thu Nov 9 18:41:40 2017 S02-config -> /wrapper/etc/init.d/S02-config
lrwxrwxrwx 1 root root 37 Thu Nov 9 18:41:40 2017 S03-early-syslogd -> /wrapper/etc/init.d/S03-early-syslogd
lrwxrwxrwx 1 root root 28 Thu Nov 9 18:41:40 2017 S03-path -> /wrapper/etc/init.d/S03-path
lrwxrwxrwx 1 root root 30 Thu Nov 9 18:41:40 2017 S20-config -> /wrapper/etc/init.d/S20-config
lrwxrwxrwx 1 root root 29 Thu Nov 9 18:41:40 2017 S50-rdate -> /wrapper/etc/init.d/S50-rdate
root@FB7490:~ $ l /wrapper/etc/init.d/
drwxr-xr-x 1 root root 2048 Sat Jun 4 06:29:49 2016 .
drwxr-xr-x 1 root root 2048 Sun Jul 3 23:27:00 2016 ..
-rw-r--r-- 1 root root 29802 Mon May 30 17:36:03 2016 E99-custom
-rw-r--r-- 1 root root 3284 Mon May 30 14:31:18 2016 S02-config
-rw-r--r-- 1 root root 2681 Mon May 30 14:42:41 2016 S03-early-syslogd
-rw-r--r-- 1 root root 2074 Mon May 30 14:46:59 2016 S03-path
-rw-r--r-- 1 root root 1639 Mon May 30 14:51:51 2016 S20-config
-rw-r--r-- 1 root root 2304 Mon May 30 14:57:05 2016 S50-rdate
root@FB7490:~ $ mount -t squashfs
/dev/loop0 on / type squashfs (ro,relatime)
/dev/loop1 on /var/custom type squashfs (ro,relatime)
/dev/loop2 on /var/bintools type squashfs (ro,relatime)
root@FB7490:~ $ l /var/custom
drwxr-xr-x 7 root root 83 Sat Jun 4 06:16:11 2016 .
drwxr-xr-x 20 root root 2400 Wed Feb 21 01:59:47 2018 ..
drwxr-xr-x 2 root root 103 Tue Aug 15 01:48:54 2017 bin
drwxr-xr-x 4 root root 77 Sat Jun 4 06:16:02 2016 etc
drwxr-xr-x 2 root root 2892 Mon Sep 25 17:51:20 2017 lib
drwxr-xr-x 2 root root 39 Mon Aug 14 14:46:56 2017 sbin
drwxr-xr-x 6 root root 74 Mon Aug 14 14:50:53 2017 usr
root@FB7490:~ $ l /var/custom/etc/init.d/
drwxr-xr-x 2 root root 91 Mon Aug 14 14:23:36 2017 .
drwxr-xr-x 4 root root 77 Sat Jun 4 06:16:02 2016 ..
-rwxr-xr-x 1 root root 7606 Mon Aug 14 14:23:36 2017 rc.alive
-rwxr-xr-x 1 root root 6191 Sun Apr 17 02:11:41 2016 rc.dropbear
-rwxr-xr-x 1 root root 6629 Sun Apr 10 14:19:02 2016 rc.shellinaboxd
-rwxr-x--- 1 root root 5841 Sat Apr 9 16:38:24 2016 rc.startup
root@FB7490:~ $ cat /var/custom/etc/profile
export TMP=/var/tmp
tmphome=$(sed -n -e "s|^\($USER\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\([^:]*\):\(.*\)\$|\6|p" $(realpath /etc/passwd))
[ ${#tmphome} -gt 0 ] && export HOME=$tmphome
export LD_LIBRARY_PATH=/var/custom/lib${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH
export PATH=$HOME/bin:$HOME:/var/custom/bin:/bin:/var/custom/usr/bin:/usr/bin:/var/custom/sbin:/sbin:/var/custom/usr/sbin:/usr/sbin
und muß damit an den wichtigsten Erweiterungen, die ich in jeder Version haben will, in aller Regel gar nichts mehr ändern, weil die Dateien für die Wrapper-Partition bei mir vom "modfs" genauso in diese Partition kopiert werden, wie die zusätzlichen Symlinks (und weitere Dateien, die ich immer im SquashFS-Image haben will) über "copy_binaries" mit entpackt werden aus dem TAR-Archiv, welches dabei bekanntlich zum Einsatz kommt (der Name "copy_binaries" ist hier ja etwas irreführend, aber auch dessen Funktion ist in #1 "beschrieben").
Wie man schon an meiner "/etc/profile" aus dem "custom image" oben sehen kann, macht es sogar wieder absoluten Sinn (der Name des Mountpoints hängt ja - zumindest bei der Verwendung von E99-custom - auch vom Namen des Images ab), die Pfadangaben für die Suche nach zusätzlichen Programmen oder Bibliotheken (LD_LIBRARY_PATH), die man ja vermutlich innerhalb so einer interaktiven Session benutzen will, gerade aus dem Image heraus ebenfalls zu setzen (auch wenn man hier sogar noch das "/var/custom" durch etwas mehr Code und am Ende durch eine variable Angabe hätte ersetzen können), weil die schlicht spezifisch für die Dateisystemstruktur in diesem Image sein können.
Und auch wenn ich die Binaries in solchen Images tatsächlich immer mal wieder erneuere, sofern ich dort Änderungen vorgenommen habe (deshalb sind die auch in einem solchen "custom image" und nicht direkt im SquashFS-Image des FRITZ!OS, weil man sie dann auch austauschen kann, ohne das gesamte System zu erneuern) ... die verwendeten Skript-Dateien zum Einrichten der Umgebung für einen Service und zum Starten desselben, ändern sich in aller Regel nicht - man sieht es schon an den Datumsangaben bei den verwendeten Skripten. Damit brauche ich diese Dateien (also die eigenen "Images") auch nicht bei jedem FRITZ!OS-Update anzupassen ... es reicht vollkommen, sie (wenn sie wirklich im Wrapper liegen und nicht ohnehin in "/var/media/ftp", wo sie dank Signaturprüfung genauso sicher sind) jeweils wieder in die Wrapper-Partition kopieren zu lassen.
Daher finden sich auch durchaus recht "alte" Dateien in einem solchen Image ... aber auch vieles von dem, was ich entweder als Skript im YourFritz-Repo habe oder als Änderung/Erweiterung von Freetz in meinem Fork im GitHub - die hier enthaltenen Dateien (zumindest die veröffentlichten, aber es gibt nur wenige "private") kann sich also auch jeder selbst bauen, wenn er meine Patches für Freetz benutzt. Ich mag es eben (wie man im Anhang sehen kann, weil sonst der Beitrag wieder mal jenseits der 50k-Zeilen landen würde), wenn ich mich auf der Box auch mal mit einem "Midnight Commander" bewegen kann ... weil der Komfort bei der "ash" eben doch etwas eingeschränkt ist.
In einem zweiten "custom image" (bintools.custom) habe ich sogar eine "Entwicklungsumgebung" mit dem GCC (und den "bintools", daher der Name) auf der FRITZ!Box (auch wenn die auf der 7580 deutlich mehr Spaß macht als auf der 7490) ... da die wiederum deutlich seltener gebraucht wird, als die "normalen Erweiterungen", liegt sie eben in einem zweiten Image vor und wird nur auf den Boxen gemountet (den Mechanismus zur Auswahl habe ich bei der "E99-custom" mehr als ausführlich beschrieben), wo (bzw. sogar wenn, weil das auch nicht immer der Fall ist) sie vonnöten ist. Das ist dann ein Beispiel dafür, warum es Sinn macht (oder zumindest machen kann), das auch so "ausführlich" und konfigurierbar zu machen, anstatt einfach ein jeweils für die Box passendes Image mit allen notwendigen Zusatzprogrammen "am Stück" zu mounten ... wenn es so einfach wäre, könnte man auch immer gleich alles in das SquashFS-Image des FRITZ!OS packen, wie es AVM und Freetz (mal abgesehen von "externals", was aber eher Platzgründe hat als dem "Segmentieren" der Erweiterungen dient) machen. Auch das ist sicherlich ein Weg, aber einer, gegen den ich mich entschieden habe, weil ich einfach zuviele Boxen zu betreuen habe und nicht für jedes dieser Geräte eine "Spezial-Firmware" haben will.
