"Grundsatz-Artikel" zum Thema: Wie geht es weiter mit "modfs" und wann kann ich damit auch die Labor-Version ohne Fehler modifizieren?
Angeregt durch
Nicht daß das modfs da irgendwas durcheinandergebracht hat.
(und ähnliches, auch per E-Mail, das oben war nur der letzte Beitrag dazu, den ich auf die Schnelle finden und verlinken konnte) möchte ich mal ein paar Gedanken loswerden ...
Ich will es noch einmal explizit festhalten, falls es zuvor nicht so richtig deutlich wurde ... an die 06.98-Reihe kann und will ich "modfs" nicht so anpassen, daß eine gemeinsame Version sowohl die Versionen davor als auch die 06.98-Labor oder gar die 07.0x unterstützt. Die von mir festgestellten Unterschiede habe ich bereits irgendwo aufgelistet, der abweichende Kernel und die andere C-Library sind so tiefgreifende Änderungen, daß eine "one for all"-Version das nur noch unübersichtlicher machen würde.
Diesen Problemen kann man - jenseits des reinen Patchens von Lua-Dateien, was auch schon in mehreren Patches (bzw. "modscripts") jeweils in mehreren Versionen enthalten ist, weil sich im Laufe der Zeit bei AVM etwas dazu änderte - nur mit statisch gelinkten Binaries entgegentreten oder mit der Integration der kompletten uClibc in Version 0.9.33.2, die wegen einiger identischer Symlinks für Bibliotheken aber auch nicht so ganz ohne ist und doch eher mit einem zweiten "lib"-Verzeichnis zu lösen wäre.
Ich habe eben absolut keine Lust, vor der Veröffentlichung der Quellen durch AVM selbst auszukaspern, was AVM da genau konfiguriert hat und was nicht, wenn die C-Lib, die BusyBox oder der neue Kernel übersetzt werden. Ich habe zwar auch dazu noch nicht explizit bei AVM angefragt, aber ich vermute mal, die Haltung "Wir veröffentlichen OpenSource-Quellen nur für Release-Versionen." wird sich nicht geändert haben ... worauf auch immer die basieren soll (die GPL kann es kaum sein, die sagt etwas anderes, denn auch Labor-Versionen werden von AVM "verbreitet").
Daß AVM da lange nicht so kooperativ ist, wie man immer tut, ist ja auch nicht erst seit heute bekannt und bei mir zumindest hat man es inzwischen geschafft, daß ich mir sinnlose Anfragen und den Ärger bei entsprechenden Antworten (die ja nicht mal "abschlägig" sind, sondern eben einfach behaupten, das hätte schon alles seine Richtigkeit, was da im OSS-Paket enthalten ist) gar nicht erst mehr antue.
Wer sich also unbedingt für die neue Labor-Reihe erwärmen kann/möchte/muß, der muß sich - so er "modfs" dafür verwenden will - auch um die Anpassung an diese Labor-Reihe kümmern - auch um ggf. notwendige Änderungen bzgl. der Anzeige von VPN-Verbindungen in der Übersichtsseite (darum geht's im oben verlinkten Beitrag/Thread). Bis einschließlich 06.92 sind mir (seit der Korrektur für die internationale Firmware im April 2017) keine Probleme bei der Release-Version bekannt und m.W. hat sich die Lua-Seite zur 06.93 (die gibt es ja auch nur für die 7490) hin auch nicht verändert - wenn das bei der 06.98 anders sein sollte und daraus mit dem Patch eine falsche Übersichtsseite entsteht (so ja meine Vermutung aus dem "vergangenen Jahr" weiter oben), muß man das selbst suchen, auf diesen einen Patch verzichten oder eben ganz auf "modfs" verzichten.
Ich selbst will eine "modfs"-Version "ab 06.98" auch nicht als Branch im Repo aufmachen, weil dann wieder neue Unklarheiten entstehen, wie man das unterscheidet oder richtig verwendet, wer mit welcher Version genau Probleme hat(te), usw. - wenn AVM nicht von sich aus die notwendigen Informationen bereitstellt (möglichst auch noch unaufgefordert), dann muß man eben auf die Benutzung der Labor-Reihe oder auf die Benutzung von "modfs" verzichten. Damit kann jeder selbst entscheiden, was ihm wichtiger ist ... die Teilnahme an der Labor-Reihe und der Test neuer Funktionen oder seine eigenen Modifikationen der Firmware. Wenn AVM sich beim Feedback zur Labor-Reihe dann selbst ins Fleisch schneidet, weil die Leute "mit Ahnung", die ihre FRITZ!Box meist recht gut kennen und sie modifizieren wollen oder gar müssen, von der Labor-Reihe praktisch ausgeschlossen werden, könnte man sich dort vielleicht auch überlegen, ob die eigene Position so in alle Ewigkeit fortbestehen soll (wobei ich da wenig Hoffnung habe) oder die Quellen (es würde ja schon die Konfiguration reichen, weil man die dann nicht mühsam selbst auspendeln müßte) dann doch zeitnah (und vor dem Release) veröffentlicht werden.
Da das Modifizieren auch auf den GRX5-Modellen ziemlich anders laufen müßte (hatten wir ja auch schon, auch wenn mein "Versprechen" jetzt bald ein Jahr alt wird), bin ich inzwischen tatsächlich im Zweifel, ob man das in dieser Form wirklich weiterführen sollte ... derzeit tendiere ich eher dazu, in die originale Firmware von AVM einfach nur noch als wichtigsten Schritt einen eigenen Public-Key einzubauen (der "frische" Branch "framework" im YourFritz-Repo wird die dazu entwickelten Skript-Dateien aufnehmen) und ein paar Hilfsmittel (statisches OpenSSL, signimage-Skripte) und den Rest dann über passende "Zusatz-Images" machen zu lassen, wo die enthaltene "/var/install" dann die Aufgaben von "modfs" (Entpacken, Ändern, Packen, wobei das Entpacken gar nicht notwendig wäre, wenn man nur noch die laufende Version ändert, wie das bei "modfs" am Beginn ja auch war) im Batch-Betrieb übernimmt und auf den ganzen Dialog-Kram einfach verzichtet.
Das macht es deutlich mehr "straight forward" und alte Probleme wie "memory pressure" sollten bei den GRX-Modellen eigentlich auch nicht mehr auftreten bzw. lassen sich mit passenden Einstellungen auch verhindern (zumindest als "oops"). Da man dabei sogar die anderen Dienste abschießen lassen kann (nach dem Upload eines neuen Images im GUI ist ohnehin ein Neustart angesagt, weil der größte Teil der Dienste schon gekillt wird, bevor die "/var/install" überhaupt zum Zuge kommt), ist das Speicherplatzproblem noch einmal kleiner und vermutlich nicht mal bei den VR9-Modellen mit 128 MB RAM ein richtiges Thema (sonst müßte man halt das Abreißen des "USB-Stapels" (aka USB-Stack) beim Update noch verhindern, wie es für WAN über Mobilfunk o.ä. ja schon geschieht).
Wobei ich die kleinen Modelle halt nicht alle selbst testen kann, aber für diese "Möhren" gibt es ja i.d.R. auch keine Labor-Reihe und wer dort (vor FRITZ!OS 7) noch "modfs" verwenden möchte, hat ja noch die aktuelle/alte Version.
Ich habe zwar mal gesagt, daß es "modfs" auch für neue Modelle und Versionen geben soll/wird, aber das muß ja vielleicht doch nicht in der bisherigen Form sein ... man kann ja auch "außerhalb der FRITZ!Box" erst einmal entsprechende Images erstellen (und dabei unterstützt einen dann das "modfs 2.0" bzw. das neue "YourFritz" - das war/ist ja das ursprüngliche Ziel) und selbst signieren, die dann auf der Box nur noch die vorprogrammierten Aktionen ausführen - dann braucht man nicht mal mehr zwingend einen Shell-Zugang, wenn man z.B. nur OpenVPN benutzen will.Das kann dann auch weiterhin deutlich unterhalb der "Schwelle" laufen, die eine eigene Freetz-VM und/oder eine eigene Toolchain (ob Freetz oder nicht) erforderlich macht ... abgesehen davon hat Freetz natürlich bis zum Erscheinen der AVM-OSS-Pakete dasselbe Problem.
Wenn diese Aktionen in so einem eigenen Image dann auch darin bestehen können, in einer eigenen Firmware-Erweiterung (aka Plugin-Image, denn genau so soll das am Ende arbeiten und dafür braucht es nur den richtigen "Manager", der diese Plugins findet und den Rest dann schon AVM's "tr069fwupdate" überläßt) Programme auszutauschen (also Updates zu machen) oder hinzuzufügen (vielleicht sogar zu löschen, wobei man da auch drauf verzichten könnte - dann muß man das eben wieder neu aus den Paketen zusammenstellen), dann können diese Erweiterungen sogar FRITZ!OS-Updates überleben, solange man nur dafür sorgt, daß die paar (wenigen) Voraussetzungen für diesen "Manager" auch beim Update mit einer originalen AVM-Firmware
automatisch wieder eingebaut werden (und sei es erst beim nächsten Start, weil schon zuviele Prozesse tot sind).
Dann würde sich zwar die eigene Modifikation wie ein Virus oder ein Wurm verhalten, den man nur mit Recovery auch wieder los wird, aber das könnte ich auch vor mir selbst vertreten - wie es prinzipiell geht, hatte ich ja schon mal gezeigt mit dem "autoudpate" (dessen Benutzung bei der 6490 war je mehr "Abfallprodukt"). Man braucht nur in der "post_install" zu prüfen, ob von der AVM-Version der "/var/install" in einem Update-Image zusätzliche Kommandos zum Speichern der neuen Firmware hinten angefügt wurden und dann weiß man genau, daß da gerade ein AVM-Update stattgefunden hat (bzw. stattfinden wird).
Dann kann man entweder gleich das AVM-Filesystem noch ändern, bevor es überhaupt installiert wird (bei GRX-Modellen, wo es den Wrapper nicht gibt) oder man hängt selbst noch weitere Kommando an und aktiviert in dem Wrapper (bei Modellen mit einem solchen) nach dem Kopieren der Dateien noch die notwendigen Routinen, um sich beim nächsten Start wieder in das AVM-SquashFS-Image einzuklinken. Vielleicht leidet darunter die Dualboot-Möglichkeit etwas (in der YAFFS2-Partition ist i.d.R. kein Platz für zwei Root-Images und das gerade als rootfs gemountete kann man nicht einfach überschreiben und müßte wohl die zweite Partition dafür nehmen) - aber im Notfall könnte man sogar (wenn im NAS-NAND genug Platz vorhanden ist) das neue SquashFS-Image da erstellen und erst beim nächsten Booten noch in die Wrapper-Partition kopieren, bevor das rootfs in der "inittab" mit "pivot_root" ersetzt wird.
Der entscheidende Unterschied zum bisherigen "modfs" (und zu Freetz erst recht) wäre es halt, daß die originale AVM-Firmware nur noch minimal geändert wird (selbst die Patches für irgendwelche Korrekturen des AVM-GUI könnte man ja durch "bind"-Mounts mit einer gepatchten (Datei-)Version ersetzen, so viele Dateien sind das ja nicht) und die Modifikationen, die ihrerseits Binärdateien brauchen, nur noch "neben" der AVM-Firmware existieren und so eine Art abgetrenntes Subsystem ergeben (ggf. sogar mit der alten uClibc als DSOs, bis man die AVM-Bibliotheken verwenden kann, ansonsten eben statisch gelinkt). Vielleicht kommt es ja bei den GRX-Modellen sogar mal so weit, daß jemand (aus der OpenSource-Szene) die Spezifikationen für den "VM-Betrieb" in die Hand kriegt und man wirklich das AVM-System und ein eigenes getrennt betreiben kann. Der Puma7 soll ja ebenfalls Virtualisierung unterstützen.
Wie gesagt ... das wäre(n) die Grundidee(n) und die meisten Zutaten dafür sind inzwischen auch vorhanden oder zumindest als PoC getestet für andere Zwecke (z.B. in "toolbox"). Wenn jemand Interesse daran hat, bei der Umsetzung dieser Ideen zu helfen, ist er/sie/es herzlich willkommen ... ich nehme aber auch jede (schlüssige) Kritik an der Idee gerne zur Kenntnis und diskutiere das aus. Vielleicht findet man gemeinsam ja sogar noch bessere Lösungsansätze - die von mir skizzierten basieren aber inzwischen alle auf vorhandener Software bzw. existierenden Lösungen, die nur passend abgewandelt werden müssen, auch wenn das noch nicht alles zu einem großen Ganzen zusammengesetzt ist.
Wenn es in Freetz Bestrebungen geben sollte, die neue Kernel-, uClibc-ng- und BusyBox-Version vor dem Release von FRITZ!OS 7 zu unterstützen, dann kann man darüber nachdenken, auch noch ein "modfs" (quasi als Retro-Version) für FRITZ!OS 7 zu bauen - aber ich vermute mal stark (mehr ist das aber auch nicht als eine Vermutung), daß da die Zahl der Mitstreiter so gesunken ist, daß FRITZ!OS 7 (und das OSS-Paket von AVM dazu) am Ende das Rennen machen werden. Die Freetz-BusyBox ist ja inzwischen neuer als die neue Version von AVM, nur weiß wohl niemand, was AVM selbst bei der 1.24.2 an Optionen verwendet und man wird wohl nicht umhinkommen, dieselben Funktionen/Applets/Optionen als Minimalumfang zu unterstützen, wenn man nicht irgendwann feststellen will, daß die Freetz-BusyBox das Problem und nicht die Lösung ist, wie es bei der uClibc in den frühen 06.35/06.36-Labors der Fall war, als AVM auf den Kernel 3.10.73 wechselte.
Jedenfalls gibt es inzwischen in der Freetz-Toolchain ja ein paar Einstellmöglichkeiten, die das Erstellen von Binaries für solche Fälle (wo die Dateien eben nicht in den AVM-Baum integriert werden, sondern woanders lagern können/sollen) deutlich erleichtern ... einige dieser Programme gibt es ja im "binaries"-Branch des YourFritz-Repos zum Download, die sind alle auf einen Basis-Pfad "/var/custom" als "Wurzelverzeichnis" ausgerichtet, damit man sie in einem solchen "Plugin-Image", das dort halt gemountet wird, ohne große Probleme einsetzen kann und sie trotzdem ihre Bibliotheken oder "Hilfsdateien" irgendwie finden, ohne sie im AVM-Dateisystem zu suchen.
Zwar muß man bei allen diesen Programmen im Moment noch auf die Konfigurationsmöglichkeiten wie im Freetz-GUI verzichten, aber das würde ich eben ohnehin "extern" machen (lassen) und auf der Box selbst gar nichts mehr groß konfigurieren. Das spart nicht nur die Notwendigkeit eines Interfaces dafür, es reduziert auch die Angriffsmöglichkeiten - ein nicht vorhandenes GUI (bzw. eines, das keine Einstellungen bietet, höchstens Protokolle oder Anzeigen) kann auch nicht gehackt werden. Allerdings sind dann Änderungen halt aufwändiger ... aber nicht nur für den Besitzer, auch für einen Angreifer.
. Einfach die 32 Zeilen von
