@KiRKman:
Die Busybox selbst zu kopieren, ist ein einzelnes Kommando ... das wird es (von mir jedenfalls) nicht für modfs geben, auch nicht als Option. Es ist und bleibt für mich ein Unterschied, ob modfs (also der von mir bereitgestellte Funktionsumfang) nur Shell- und Lua-Skripte ändert (wo jeder nachlesen kann, was da passiert) oder ob da Binärdateien in der Firmware ausgetauscht werden.
Sollte ich jemals fertig werden und irgendwann mal signierte Binärpakete anbieten können/wollen, kann man das noch einmal überdenken ... zumindest in Bezug auf SIAB. Der "Ausflug" bei modfs-Starter war auch nur deshalb (vor mir selbst) vertretbar, weil es eben keine wirklich permanente Änderung war, die da vorgenommen wurde ... deshalb gab es ja auch die Möglichkeit, das wieder komplett aus der Box zu entfernen.
Bei der Busybox macht so ein installierbares (und dann auch wieder entfernbares) Paket nur wenig Sinn (müßte dann mit bind-Mount arbeiten und das ist ohne Restart nicht wieder zu entfernen) ... aber wie gesagt, das ist ein einzelnes cp-Kommando in der Pause vor dem Einpacken oder im Extremfall 7 Zeilen in einem eigenen "modscript":
Code:
# MODFS_MODSCRIPT
# SUPPORTS install
# NAME replace Busybox
# DESCRIPTION en
# replace busybox with statically linked version from modfs
# EOH
[ $4 == install ] && cp -a bin/VR9/busybox $2/bin/busybox
(auch wenn da ein paar wenige Unsauberkeiten enthalten sind).
Die Integration von SIAB beschränkt sich eigentlich auch auf das Kopieren der Dateien an die richtigen Stellen (das kann copy_binaries problemlos mitmachen) und das Erstellen eines passenden Files in /etc/init.d (wenn das als Service gestartet werden soll). Auch das Start-Skript kann ja durchaus von copy_binaries mit ausgepackt werden, nirgendwo steht, daß jede einzelne Modifikation von einem gesonderten "modscript" umgesetzt werden muß (wenn das so wäre, hätte ich da mehr als 50 Skripte). Man muß sich doch nur sein ganz persönliches Archiv-File mit den Binärdateien erstellen und kann das dann immer wieder auspacken.
Das "Patchen" ist doch nur dann erforderlich, wenn man Dateien der originalen Firmware abändern will oder muß ... das ist beim
Hinzufügen weiterer Dienste weder erforderlich noch immer sinnvoll.
Selbst der Austausch der Busybox ist doch eigentlich Aufgabe von "copy_binaries" ... warum ich das nicht freiwillig einbaue, habe ich schon mehrfach erläutert. Für mich übernimmt man dann auch die Verantwortung für Updates solcher bereitgestellten Binärdateien und das sollte erstens jeder selbst schaffen und zweitens will ich dafür nicht verantwortlich sein.
Wenn ich mich nicht irre, gibt es sogar irgendwo weiter vorne im Thread ein Kommando, mit dem man aus dem bin-Verzeichnis vom "modfs" die Busybox in sein eigenes tar-File für die Verwendung mit "copy_binaries" packen kann. Das ist das Maximum an "Hilfestellung", zu dem ich in diesem Zusammenhang bereit bin. Das ist ein wenig so, wie bei den nur in Binärform verfügbaren Grafik-Treibern unter Linux oder bei bestimmten Fonts bzw. dem Flash-Player usw. ... es wird einem zwar ziemlich genau gesagt, was man wie machen könnte, aber die Initiative dazu, es wirklich auszulösen, muß immer noch vom Nutzer ausgehen.
-Das Folgende hatte ich im Thread für die Gebrauchsanleitung geschrieben, da der am Ende frei bleiben soll von längeren Beiträgen und mir kein besserer Platz einfällt, verschiebe ich den Inhalt mal von dort nach hier - es geht im Prinzip nur darum, wie "modfs" heruntergeladen und beim ersten Mal gehandhabt werden könnte/sollte und was ich in der/den nächsten Version(en) gerne ändern würde, damit es sich weiterentwickeln/-verwenden läßt.
-@eisbaerin:
Zur Frage der verwendeten Kommandos ... ich würde es (auch wenn es in #1 im modfs-Thread vielleicht noch anders steht, da ging ich auch nie davon aus, daß das Archiv (bei anderen) dauerhaft auf der Box liegen würde) direkt nach dem Download auspacken und damit - bei dauerhafter Speicherung - auf die "Lagerung" des tgz-Files verzichten (der Platzbedarf ist sicherlich nicht der entscheidende Punkt).
Damit sind dann auch eigene Änderungen an den Dateien oder eigene Zusätze persistent ... sicherlich nicht immer erwünscht, aber wohl doch der häufigere Fall.
Damit würde sich dann die "Installation"/"Vorbereitung" und auch das "Update" auf folgende Kommandos zubewegen:
Code:
mkdir /var/media/ftp/modfs
wget -O- http://yourfritz.de/modfs.tgz | gunzip -c | tar -C /var/media/ftp/modfs -x
Der Vorteil wäre, daß spätere eigene Ergänzungen (z.B. eben Dateien binaries[...].tgz für eine oder mehrere Box-Versionen beim "copy_binaries" oder auch eine "custom_modscripts") in diesem Verzeichnis erhalten bleiben und nur die Änderungen/Fehlerkorrekturen am Skript (und natürlich den abhängigen Dateien wie den Nachrichten oder dem Inhalt von bin) wirksam werden. Dieser Speicher unter /var/media/ftp müßte nach meinem derzeitigen Kenntnisstand wirklich auf jedem unterstützten Modell verfügbar sein ... lediglich seine Größe ist bei den kleineren Modellen geringer. Die (derzeit) 2,5 MB für "modfs" sollten da noch frei sein ... selbst wenn es (maßvoll) mehr werden sollte, wenn da noch ein paar Binaries dazukommen, um Abhängigkeiten von der existierenden Firmware zu verringern.
Beim "Namensschema" werde ich bei "modfs-
version.tgz" bleiben und auch der Pfad (Basisverzeichnis yourfritz.de) wird sich sicherlich nicht ändern, wenn man den Download von dort machen will. Ich sehe leider keine Lösung, wie man den Inhalt des GitHub-Repos direkt auf die Box bekommt, da dort wohl immer HTTPS für den Download erforderlich ist (ansonsten gibt es Redirects im Hintergrund) und eine unmodifizierte AVM-Firmware enthält nur ein wget-Applet, das kein HTTPS beherrscht, während die AVM-eigene Alternative "httpsdl" (wohl auch wegen verschiedener Redirects) nach meinen Tests gar nicht mit github.com klarzukommen scheint. Jedenfalls wird der Alias "modfs.tgz" auch künftig auf die letzte/aktuelle Version zeigen, selbst wenn die älteren Versionen noch existieren sollten. Eine Index-Seite (als Auflistung der vorhandenen Versionen) wird es auf yourfritz.de aber vermutlich auch nie geben, mit etwas Pech wird an dieser Stelle (also beim Aufruf von yourfritz.de ohne "deep link" auf irgendwelche Dateien) in Kürze sogar auf das GitHub-Repo weitergeleitet (@andiling: ich denke noch).
Wenn man mal davon ausgeht, daß die meisten am Ende "modfs" inzwischen wohl doch mehr als einmal anwenden werden, ist der "alte Weg" über die volatile Speicherung in /var/mod vielleicht nicht mehr die allererste Wahl.
Bei passender Beschreibung könnte ich mir sogar noch vorstellen, einen kleinen "Update-Check" für das Skript einzubauen, damit man sich - bei Interesse - automatisch die letzte Version holen kann und die Kommandos nicht jedesmal von Hand eingeben muß.
Das stünde dann in einer Reihe mit den geplanten (ebenfalls zu "modfs" externen) Zusatz-Skripten, die verschiedene inzwischen "gelernte" Rahmenbedingungen abfragen sollen und damit die (interne) Prüfung der Voraussetzungen für die Anwendung von "modfs" (die ja auch schon 18 Monate alt sind und inzwischen habe ich ja auch einiges dazugelernt/gefestigt beim Aufbau der 7490, auf die ich mich in erster Linie stütze) in Version 0.4 dann ersetzen sollen - es reicht eben aus, diese Voraussetzungen einmalig abzuprüfen, weil sich die Box ja auch bei wiederholtem Aufruf eher nicht verändert.
Dieses Auslagern macht es dann aber erst wirklich möglich, solche zusätzlichen Prüfungen - wie auf das Vorhandensein von Swap-Space oder das optionale vorherige Ausführen von "prepare_fwupgrade" - hinzuzufügen, ohne jedesmal komplette "regression tests" für das gesamte "modfs"-Skript machen zu müssen.
Im Prinzip will ich den ursprünglich mit dem einen großen Skript eingeschlagenen Weg wieder rückgängig machen und eher wieder auf kleinere spezialisierte Teil-Lösungen, die von einer "großen Klammer" zusammengehalten werden, zurück. Da kam ich zwar mal her bei der allerersten Variante, aber es fehlte diese "Klammer" und man merkte schnell, daß die meisten mit dem "wenn das, dann das" in der Beschreibung wenig anfangen konnten.
Mit dem derzeitigen Stand/Aufbau ist jedenfalls der Übergang auf HTML-basierte Auswahl von Einstellungen fast undenkbar ... gibt es kleinere spezialisierte Skript-Dateien, können die auch aus einer Lua-Seite heraus aufgerufen werden (nichts anderes macht ja z.B. der "guibootmanager", wenn er von reboot.lua aufgerufen wird). Man muß dann halt nur die bereits ausgewählten Einstellungen von einem Skript zum nächsten übergeben ... aber das bietet dann auch (fast automatisch) die Möglichkeit, beim nächsten Update die alten Einstellungen erneut zu verwenden, solange sie noch irgendwo gespeichert sind.
Ich hoffe in diesem Zusammenhang vor allem stark, daß es niemand als Affront auffaßt, wenn ich Änderungen einbaue, die bestehende Anleitungen dann auch zu einer weiteren Änderung zwingen ... das würde ich sicherlich nicht als "Selbstzweck" machen, aber übergroße Rücksicht, damit die Beschreibung noch stimmt, darf/sollte es dann auch nicht geben, wenn eine solche Änderung eines Verbesserung verspricht (selbst wenn die sich nicht sofort manifestiert - solange das Ziel klar formuliert ist, ist das (für mich) auch legitim).
