Die Aussage im verlinkten Blog-Eintrag bei 3CX:
Important: On newer firmware versions this procedure is not possible anymore.
kann man allerdings gar nicht genug unterstreichen.
Eine Änderung der "ar7.cfg" über eine Shell-Session mit anschließendem "reboot"-Kommando funktioniert - ziemlich sicher - in der überwiegenden Anzahl aller Versuche NICHT.
Der "ctlmgr" verwaltet eine Kopie dieser "ar7.cfg" in seinem Speicher und verzögert Änderungen anderer Komponenten an deren Inhalt (sofern sie über ihn erfolgen, was bei der Anwendung von "nvi" schon mal definitiv nicht der Fall ist) auch gerne mal, um so mehrere Schreibzugriffe zusammenfassen zu können (das geht in den Flash-Speicher, der nur eine begrenzte Lebensdauer hat und so mit allerlei Cache-Mechanismen versucht - auch auf verschiedenen Ebenen - die "Schreibbelastung" einzelner Zellen gering zu halten) und nicht bei jeder Kleinigkeit sofort die gesamte Datei neu schreiben zu müssen. Denn der Inhalt dieser (durchaus recht großen) Datei wird als "deflated stream" (mit zlib komprimiert) immer als Ganzes geschrieben und so zieht wenigstens nicht jede kleine Änderung in der Datei bzw. an einer einzelnen Einstellung in dieser, eine komplett neue Version der "ar7.cfg" nach sich.
Wer das nicht glauben kann oder will, braucht nur mal - bei laufenden "ctlmgr" wohlgemerkt - die eigene "ar7.cfg" löschen im TFFS (wirklich schlaue Tester legen sich trotzdem noch eine Kopie vor dem Löschen an und zwar auf einem Datenträger mit persistenter Speicherung - man weiß ja auch nie, ob die Box nicht vor dem oder beim Schreiben durch den "ctlmgr" abstürzt) ... das geht mit einem
echo clear_id 113 > /proc/tffs ganz einfach und danach kann man sich (solange der "ctlmgr" noch keine neue geschrieben hat) auch mittels
cat /var/flash/ar7.cfg oder mit dem AVM-eigenen
checkempty <filename> davon überzeugen, daß da tatsächlich nichts mehr in der "Datei" steht (die "Gänsefüßchen" sind dem Umstand geschuldet, daß es sich nicht um eine reguläre Datei, sondern um einen Datenstrom aus einem speziellen Treiber (eben dem TFFS-Treiber) handelt).
Erst wenn man jetzt den "ctlmgr" beendet (mit
ctlmgr -s) und dieser dabei den gecachten Inhalt der "ar7.cfg" wieder restauriert, steht da auch wieder etwas in der Datei. Wobei auch nicht (exakt) bekannt ist, ob der "ctlmgr" intern noch ein Flag führt, das anzeigt, ob die Datei seit dem letzten Schreiben geändert wurde ... vorsichtshalber sollte mal also vor dem Beenden des "ctlmgr" noch mit irgendeinem "ctlmgr_ctl w ..."-Kommando dafür sorgen, daß es tatsächlich etwas zum Schreiben gibt - sonst braucht man die "Vorsichtshalber-Kopie" schneller, als man denkt.
Überschreibt man aber einen der TFFS-Nodes, während der "ctlmgr" nicht aktiv ist (das Beenden habe ich ja schon oben angeführt, starten kann man ihn einfach wieder mit einem neuen
ctlmgr), klappt das auch wieder zuverlässig. Nur sollte man den "ctlmgr" nicht zu lange gestoppt lassen (andere Komponenten brauchen ihn und fangen an zu heulen (wie ein Wachhund), wenn er zu lange abwesend ist) ... was dann wieder nicht dazu paßt, daß die meisten sicherlich bei der Benutzung von "nvi" nicht die allerschnellsten wären.
Also taugt "nvi" nur noch sehr bedingt zum Editieren solcher Dateien und man verwendet (je nach Gusto) vielleicht besser ein anderes Skript. Meinen Vorschlag dafür findet man hier:
https://github.com/PeterPawn/YourFritz/blob/master/tffs/fritzos_scripts/tvi - wobei die "Erkennung" von Nodes, die für den "ctlmgr" relevant sind, nur anhand der Endung ".cfg" erfolgt und nicht 100% korrekt ist, denn es gibt auch Dateien, die nicht auf dieses ".cfg" enden (auch wenn die dann wohl nicht vom "ctlmgr" gecacht werden).
Neben der korrekten Behandlung (Stop, Speichern, Starten) für das "ctlmgr"-Problem vermeidet das Skript auch gleich noch unnötige Schreibzugriffe auf das TFFS (anders als "nvi", was die Datei in jedem Falle zurückschreibt in den Node), wenn sich der neue Inhalt nicht vom alten unterscheidet ... es gibt ja auch "Anleitungen", wo das "nvi" nur zur Anzeige des Inhalts von TFFS-Nodes empfohlen wird (dafür gäbe es bei mir dann "tcat", wobei das keine seitenweise Anzeige beinhaltet und damit z.B. mit "more" kombiniert werden müßte - wer allerdings ein aktuelles "modfs" verwendet, findet in dessen BusyBox auch das "less"-Applet, was bei AVM m.W. fehlt).
Ob man jetzt für so eine Änderung tatsächlich die gesamten Einstellungen einer FRITZ!Box durch Ex- und Import (mit zwischenzeitlicher Änderung) wiederherstellen sollte, liegt sicherlich auch wieder im Auge des Betrachters. Angesichts der Tatsache, daß in so einer Export-Datei nicht wirklich ALLE Einstellungen enthalten sind und man dann nach dem Import wieder "von Hand" nacharbeiten muß an verschiedensten Stellen, wäre sogar die Änderung über ein speziell dafür angefertigtes Image (Beispiele hier:
FRITZ!Box-Kennwort vergessen ... was nun? (Mail-)Recovery a la AVM oder besser nicht? bzw. hier:
https://github.com/PeterPawn/YourFritz/tree/master/toolbox) in meinen Augen (auch ich darf ja Betrachter sein) noch einfacher und schneller - zumindest dann, wenn die notwendigen Vorkenntnisse ohnehin bereits vorhanden sind.
Die "handwerklichen Arbeiten" sind jedenfalls in unter 10 Minuten zu erledigen ... auch auf einem "Live-System" vom USB-Stick (wenn der Rechner und der Stick nicht allzu lahm sind). Gerade das "build_reset_tainted_image" ist praktisch (für VR9-Boxen, GRX-Modelle brauchen ein SquashFS als Root-Filesystem - da kommt aber (hoffentlich in Kürze) auch noch etwas für) schon komplett ... anstelle des "echo clear_id" braucht es nur ein "mknod" ("tmpfs" ist bereits gemountet) und einen passenden "sed"-Aufruf (der Link für dieses Applet wird auch erstellt) und das Ganze ist schon erledigt (den Rest macht dann ja das Skript) - man muß das Image jetzt nur noch in den Speicher laden und starten lassen (zumindest wenn man "vor Ort" ist).
Vielen herzlichen Dank! Nun frage ich mich: Wie konnte ich nur so blind sein und das übersehen?
