[Sammlung] Fragen, Probleme, Lösungen zum Thema "modfs-Starter"

Micha0815 schrieb:

frage ich mich, inwiefern man eine einfache Option/Package neben Telnet integrieren könnte?

Zum Vergrößern anklicken....

Wie ich schon im Beschreibungsthread (in #3) geschrieben habe ... es ist alles nur eine Frage des Inhalts der zusätzlichen "filesystem.image" im tar-File für das Update.

Dazu bräuchte es wohl ein TFTP-Binary und ggfs. die CISCO-FW neben einer *.cfg und *.sh auf der FB? (Ein für den AB oder WEB-DAV angedoggeter USB-Speicherstick sollte imho dazu unterstützend genügen?)

Zum Vergrößern anklicken....

Da dafür bereits eine umfangreichere Busybox ausreichend ist (der dort enthaltene tftpd kann über inetd oder udpsvd gestartet werden), sollte das kein größeres Problem sein. Warum das Ablegen von auf der FRITZ!Box auszuführender Software auf dem NAS-NAND oder auf einem USB-Stick keine allzu gute Idee ist, habe ich allerdings in #20 versucht zu schreiben ... nicht einmal das Ablegen von Firmware für Telefone ist dort ausreichend sicher. Solange es nur um (sich ändernde) Konfigurationsdateien ohne Credentials geht, mag das noch angehen ... dann ist das nur eine Frage der Geduld und wenn Du bereits weißt, wie die korrekten Dateien für das Telefon aussehen müssen, ist das in - sagen wir mal spaßeshalber - zwei Stunden erledigt. Ansonsten sollte man diese Dateien auch mit in den "festen" Teil der Firmware integrieren, wo kein NAS-Zugriff möglich ist.

Voraussetzung ist funktionierende Zusatzsoftware ... die entweder statisch gelinkt ist (was der Freetz-Trunk m.W. für die Busybox sogar unterstützt) oder mit kompatiblen Libs umgehen kann. Im Großen und Ganzen benutzt die Busybox offenbar keine Funktionen in der C-Library, die von der AVM-Version nicht unterstützt werden, denn eine Busybox mit der "originalen Freetz-Toolchain" hat sogar weitgehend funktioniert - allerdings habe ich natürlich nicht jedes einzelne Applet ausführlich getestet. Theoretisch könnte also sogar die schon eingebaute Busybox im tar-File von meinem Server (die wird ja bisher noch nicht verwendet und ist nur als "Vorsichtsmaßnahme" mit drin) als tftp-Server verwendet werden, auch wenn die dynamisch gelinkt ist.

Du müßtest also als erstes mal probieren, ob (per ShellInABox) mit der vorhandenen Busybox (zu finden unter /var/custom/bin/busybox, wenn die Erweiterung aktiviert wurde) die notwendigen Funktionen umzusetzen wären. Ist das der Fall, braucht es nur ein passendes "mksquashfs" (aus dem modfs-Archiv) für das Einpacken eines modifizierten Verzeichnisbaums mit der passenden rc.custom-Datei und das Ersetzen der SquashFS-Datei unterhalb von /wrapper - das Problem wäre damit bereits gelöst. Auch ein Skript zum einfachen Austauschen der "filesystem_custom.squashfs" gegen eine eigene Variante wäre sicherlich eine denkbare Erweiterung - existiert so ein Skript, nehme ich das auch gleich noch mit in das tar-File auf yourfritz.de auf.

---

-

nicht gleich zu dolle "Schlitten-Fahren" mit mir, falls ich die Main-Unterschiede zw. modfs und modfs.starter nicht hinreichend erkannt habe!

Zum Vergrößern anklicken....

Mache ich wirklich einen so "unfreundlichen Eindruck"? Ich hoffe mal nicht ... man kommt sich ja vor wie der Grinch in dieser Jahreszeit. :mrgreen:

Wenn ich mich weigere "Rezepte" zu veröffentlichen (selbst das ShellInABox hier verstößt eigentlich gegen meine Prinzipien, aber man muß wohl mit der Zeit gehen), hat das ja nichts damit zu tun, daß ich nicht weiter helfen will ... ich will bloß nicht in Konkurrenz zu diversen anderen Websites und den Autoren dicker Bücher treten, die die grundsätzliche Handhabung der Kommandozeile unter Linux beschreiben und ich setze einfach voraus, daß jeder mit entsprechendem Bedarf an Basis- oder weiterführenden Informationen erst einmal selbst eine Internet-Suche bemüht, wenn weitere Fragen auftauchen.

Diese einfach sofort hier zu stellen, weil man schon von irgendwem eine Antwort erhalten wird, empfinde ich eben auch als "Armutszeugnis" für manchen Fragesteller, weil es für mich deutlich zeigt, daß solche Leute dann die Zeit der vielen Hilfewilligen hier einfach nicht wirklich zu würdigen wissen, selbst wenn sie ganz artig immer mit "vielen Dank" reagieren - das verkommt dann auch etwas zur Floskel und zu "Medienkompetenz" gehört es eben auch (so wie es die Boardregeln eigentlich auch "anmerken" in Punkt 4), daß man erst einmal prüft, ob sein eigenes Anliegen nicht bereits behandelt wurde.

Wenn dann bereits in der Fragestellung bemerkt wird, man hätte "bereits gesucht und nichts gefunden" (ich will keine Beispiele herausheben, aber ich denke, wir alle kennen diese Fragen zur Genüge) und dasselbe Thema wurde (im Extremfall) eine Seite zuvor schon behandelt, dann darf/muß man auch mal seinem Kopfschütteln schriftlichen Ausdruck verleihen in dem (meist sicherlich vergeblichen) Versuch, beim Gegenüber bei der nächsten analogen Situation zumindest ein kurzes Zögern vor dem Drücken auf "Speichern" zu provozieren.

Das mag dann als Antwort auf die konkrete Fragestellung nicht allzu hilfreich sein, aber wenn bei einer Suche nach "FRITZ!Box VPN zwei Boxen" am Ende viel zu viele Suchtreffer gelandet werden, weil man bestimmte Themen immer und immer wieder "durchkaut", macht das das Auffinden von relevanten Informationen für die wirklich Kompetenten bei einer Suche eben auch nicht leichter.

Das ist dann keine "Unfreundlichkeit" ... das ist pure Notwehr. Man könnte sich sicherlich auch einfach hinsetzen und solche Fragen dann kurzerhand ignorieren, das hält einige dann nicht einmal davon ab, nach nicht einmal 24 h schon ihr Bedauern zu äußern, daß offenbar hier die notwendige Kompetenz zur Lösung ihres persönlichen Anliegens - entgegen anderslautender Hinweise in anderen Foren - wohl doch nicht vorhanden ist (wieder spare ich mir den Link auf einen kürzlich erst in diesem Sinne veröffentlichten Beitrag).

Aber schon die Zeit, die man mit dem Lesen solcher "basic questions" "vergeudet" (und die dritte Frage zu genau demselben Thema innerhalb von 72 h ist für mich die gedankenlose Inanspruchnahme fremder Ressourcen, auch wenn hier jeder freiwillig liest und antwortet), könnte man für viele andere schöne Sachen investieren - auch für solche, die andere vielleicht nachnutzen möchten.

Jeder, der irgendwelche Sachen für die Allgemeinheit veröffentlicht, macht das ja wohl, damit es andere dann auch wirklich nachnutzen können - schon der unterschiedliche Aufwand zwischen "nur mal schnell für mich" und "ordentlich dokumentiert, auch für andere" ist so immens, daß es sonst einfach keinen Sinn ergibt, etwas zu veröffentlichen.

Wenn man dann etwas genervt wirkt bei offensichtlichem "Versagen" eines Fragestellers (unter dem Aspekt "Medienkompetenz"), dann ist das nicht einmal in jedem Fall irgendwie "böse gemeint" - ich hoffe mal, daß ich nicht allzu oft den Eindruck des "Schlittenfahrens" mit jemandem vermittele - es ist nur selten tatsächlich meine Absicht. Es gibt allerdings durchaus Ausnahmen (bisher drei Leute von den vielen hier), aber die landen dann tatsächlich in meinem "killfile" in Form der "Ignorieren"-Liste, nachdem die Angelegenheit (aus meiner Sicht) ausdiskutiert wurde.

Neu starten ... dürfte eher ein Problem des ctlmgr und/oder des dsld/kdsld sein.

Bei mir nimmt er jedenfalls das richtig geschriebene Kommando an und synchronisiert auch etwas besser als üblich:
Anhang anzeigen 85021

Peter8Dev schrieb:

1. Die ShellInABox gilt nur für die aktuell "geimpfte" Firmware im Flash. Ein Firmwareupdate muss, nehme ich an, wieder geimpft werden. Richtig? Ich bin nur ein wenig verwirrt von den Begriffen "Einmal-Impfung" und "permanente" Änderungen. Aber damit ist wohl gemeint, das die Änderungen einen Neustart überstehen. (Oder ist auch hier etwas "Magic" am Werk die mehr macht als ich verstanden habe)

Zum Vergrößern anklicken....

Korrekt ... das "Einmal-Impfung" bezog sich mehr auf den Unterschied zur "Pseudoimage-Methode", wie sie im LCR-Thread diskutiert und auch bei antary.de (was komischerweise fast immer vor dem IPPF gefunden wird bei einer Suche über Google) beschrieben ist - da das dort nur bis zum nächsten Neustart funktioniert, sollte das "Impfen" als eine "Einmal-Immunisierung für lebenslange Funktion" (wenn man das Update als Übergabe an die nächste Generation verstehen will) von ShellInABox verstanden werden.

Die Änderung erfolgt immer nur in der Filesystem-Partition des gerade laufenden Systems, für eine Änderung des inaktiven müßte man das "mount"-Kommando mit der "remount"-Option in /var/install in ein passendes anderes Kommando abändern.

Damit hat jedes System in der Box seine eigenen "Erweiterungen" - habe ich in #3 auch versucht so zu beschreiben.

2. Die rc.custom Datei kann nur vor dem Einspielen in die Fritzbox verändert werden und kann nicht nachträglich bei einem neuen Befehl einfach beschrieben werden oder? Oder kann ich "einfach" das SquashFS mit schreibrechten neu mounten?

Zum Vergrößern anklicken....

Nein, ein SquashFS-Image ist eine "read-only"-Angelegenheit, dafür mit sehr hoher Kompression und damit großen Sparpotential beim Speicherplatz. Aber die Verwendung von SquashFS ist ja auch nicht "Pflicht" ... man könnte da auch ein beschreibbares Image mit einem passenden Dateisystem-Format verwenden. Andererseits existiert ja eine mksquashfs für die Box selbst und so eine Datei sollte (schon aus Sicherheitsgründen) nicht unbedingt dynamisch geändert werden (müssen).

Mal sehen, wenn ich nachher Langeweile habe, baue ich vielleicht noch ein Skript, was eine Verzeichnisstruktur aus /var/media/ftp (wo man das testen kann) in ein SquashFS-Image überführt und das dann auch gleich in der yaffs2-Partition austauscht. Das war im Prinzip auch als Bestandteil von "YourFritz" praktisch schon fertig (da allerdings wird pro Paket ein SquashFS-Image verwendet und die Anzahl der "loop devices" im AVM-Kernel ist begrenzt, was dann die Anzahl der optionalen Pakete auch automatisch limitierte), aber es ist wahrscheinlich sogar die bessere Idee, alle installierten Zusätze zu einem gemeinsamen Image zu packen.

Wobei - wenn man ohnehin auf dem NAND-Flash unterhalb von /var/media/ftp arbeiten will, braucht man ja nur das Start-Skript (das, was von /var/install in die /wrapper/sbin/flash_update kopiert wird) entsprechend anpassen - dann muß man nur damit leben, daß eben der NAND-Flash nur einmal pro Box vorhanden ist (bei anderen Modellen als x490 auch noch mit 22 MB ziemlich dürftig ausfällt) und damit irgendein anderer Mechanismus eingebaut werden muß, wenn man zwei unterschiedliche Systeme in der Box hat/haben will und die Erweiterungen nicht nur aus Interpreter-Code bestehen bzw. nicht auf beiden Systemen laufen sollen.

Ich bleibe aber dabei, daß man sich mit dem NAND-Flash und NAS-Zugriff mehr Probleme an Land zieht (das geht schon beim Owner von neuen Dateien los), was die potentiellen Sicherheitsrisiken angeht. Da das eigentlich mein Hauptaugenmerk ist, wäre es etwas schizophren einfach zu schreiben, daß es mit Programmen von /var/media/ftp genauso gut geht ... geht es eben nach meiner Überzeugung nicht bzw. nur dann, wenn man zusätzliche Sicherheitsvorkehrungen trifft.

PS: Es ist ja auch beileibe nicht so, daß die Verwendung/der "Mißbrauch" von /wrapper nun so fürchterlich neu und überraschend ist, denselben Mechanismus verwendet der "bootmanager" seit über 15 Monaten schon zum (automatischen) Speichern von Einstellungen des laufenden Systems in der eigenen Wrapper-Partition. Nur das Ändern des (nach dem Flashen nutzlosen) AVM-Skripts für den verzögerten Start eigener Erweiterungen ist hinzugekommen ... diese Verzögerung kann man natürlich auch anders umsetzen und dann einfach warten, bis auch der NAND-Flash gemountet ist (der ist zuverlässiger als ein Stick, der auch mal fehlen kann bei einem Start) und man von dort irgendwelche Programme starten kann. Aber die 22 MB bei den kleineren Boxen, auch noch abzgl. des Speichers für TAM, Klingeltöne und DECT-Bilder, sind nun auch nicht soo viel freier Platz. Da ist die ebenfalls in der Beschreibung schon angetextete Aufteilung dann zumindest eine Überlegung wert. Jedenfalls kriegt man im besten Falle sogar mehr als 90 MB im Flash auch bei den kleineren Modellen zusätzlich unter (~ 25 MB frei in der aktuellen yaffs2-Partition, 48 MB in der inaktiven yaffs2-Partition und noch mal um die 20 MB unterhalb von /var/media/ftp), wobei man dann beim Update die Daten aus der inaktiven yaffs2-Partition irgendwo sichern müßte. Aber mit diesem Speicher macht man selbst aus einer 7412 für lau als 1&1-Kabelmodem ein recht nettes "embedded system" - immerhin meines Wissens auch mit einem Dualcore-VR9, wohinter sich so manche andere FRITZ!Box verstecken kann und was - je nach Anwendungsfall - auch einen RasPi schlagen sollte.

Hast Du event. ADSL, während es bei mir VDSL ist?

Hast Du an der DSL-Firmware irgendetwas verändert?

Bliebe noch ein Werksreset, falls Du den DSL-Teil so "vergurkt" hast (vorgestern ging es ja wohl noch und da hast Du dann sicherlich auch irgendwo gedreht), daß der dsld/kdsld gar nicht richtig mit dem ctlmgr bei den Einstellungen zusammenspielen will.

Ansonsten wäre es nett, wenn Du dazu in einen eigenen Thread ausweichst, das hat mit "ShellInABox" wahrscheinlich eher wenig bis nichts zu tun ... jedenfalls sehe ich den Zusammenhang nicht. Mein eigener Test und Text dazu sollte eigentlich nur bestätigen, daß der Wert nach wie vor existiert (auch wenn das anhand der dsl_line_settings.lua schon klar war, wollte ich das "-2" als Offset noch probiert haben) - ansonsten ist das ein anderes Thema.

Das würde ich beim LCR schon eher TSB überlassen ... ich hatte zwischendrin mal Kontakt zu ihm aufgenommen, um ihm "modfs" schmackhaft zu machen bei den Boxen, wo es funktioniert - die Resonanz war für mein Empfinden nicht allzu enthusiastisch und das Installationsmaterial, das er mir zugeschickt hatte, war mir mit mehreren zusätzlichen Downloads im Verlauf des Installationsprozesses (wenn mein Trockentest stimmte) dann zu kompliziert und unsicher (und ggf. nach Pseudo-Update mangels dsld gar nicht zu realisieren), um daraus selbst (als "nicht-Nutzer" des LCR) ein modscript für modfs zu bauen - zumal das nach meinem Verständnis auch irgendwo einen beschreibbaren Speicher brauchen würde oder bei jedem Start aufs Neue alles downloaden müßte. Das sauber zu automatisieren, ist irgendwie nicht mein Tisch und da das nach meinem Verständnis "paid licenses" sind, wäre ein wie auch immer geartetes Engagement meinerseits an dieser Stelle fehl am Platze. Wenn TSB den Weg über das wrapper-Verzeichnis bei NAND-Boxen gehen mag und irgendwelche Nachfragen dazu haben sollte, wird er sich sicherlich selbst bei mir melden.

Bei FHEM habe ich das Problem, daß es m.W. keine Version für eine FRITZ!Box gibt, die mit der OpenSSL-Version 1.0.1 arbeiten mag ... und da ich die Benutzung des FHEM (möglichst noch mit extern freigegebener Oberfläche) ohne TLS-Verschlüsselung für ein Sicherheitsrisiko halte, habe ich da jede Aktivität ebenfalls eingestellt. Auch die Ansage im FHEM-Forum war überdeutlich: http://forum.fhem.de/index.php?topic=25066.0 - ich hatte mich sogar extra dort angemeldet, um für eine Fortsetzung "zu werben" ... auch da war die Resonanz so unterdurchschnittlich (und ich nutze das schon wieder nicht selbst), daß ich mich am Ende gefragt habe, warum ich mir das antun soll, wenn es ansonsten niemanden interessiert.

Also wird es von mir wohl noch ein Paket für dropbear anstelle von ShellInABox und vermutlich auch für SoftEther als Ergänzung zu einem der beiden geben, aber für den LCR und FHEM bin ich selbst eher nicht zuständig. Wenn ich die als Beispiele aufgeführt habe, dann eher als "Ermutigung" für deren ursprüngliche Autoren, die nach meinen Begriffen etwas zu schnell aufgegegen hatten (allerdings ist mir schon bewußt, daß es neben den NAND-Modellen auch noch jede Menge andere/ältere Boxen gibt, wo meine Lösung ohnehin nicht funktioniert).

@Micha0815:
Das ist es eben, was ich überhaupt nicht verstehe ... das ist hier weder ein elitärer Klub (dessen Kreise man stören könnte) noch wird hier jemand irgendwie "am Nasenring" durch die Gegend geführt. Wenn Du tatsächlich diesen Eindruck gewonnen haben solltest, verstehe ich beim besten Willen nicht, wie Du darauf kommst.

Wenn ich Dich nicht "auslassen" wollte bei der VPN-Problematik, wo es immer "rein in die Kartoffeln, raus aus den Kartoffeln" ging (sinngemäß: "Eigentlich ist mir das alles viel zu kompliziert ... also lasse ich es lieber bleiben, dafür bin ich nicht schlau genug, ABER ... eines wüßte ich schon noch gerne ..."), dann versuch(t)e ich das auch zu erklären. Es ist für jemanden, der Hilfestellung bieten möchte, auch sehr frustrierend (jedenfalls geht es mir so), wenn man Zeit in Antworten und Erklärungsversuche investiert und dann "zu kompliziert" oder "verstehe ich ohnehin nicht" als Reaktion kommt. Zwar kann man das Gegenüber schwerlich dazu zwingen, die nötige Standfestigkeit zu zeigen ... aber man darf es versuchen. Wenn Du das dann als "Nasenring-Ziehen" siehst, tut mir das eigentlich nicht einmal leid.

Ich weiß bei Deinen Reaktionen nie so genau, ob das nun am Ende "beleidigt" ist oder ob wir nur sehr unterschiedliche Auffassungen von Humor bzw. themenbezogenem Meinungsaustausch haben.

"Ich störe Deine Kreise lieber nicht." oder "Hätte ich geschwiegen ..." sind für mich schwer zu interpretieren in diesem Kontext und das ist hier ganz deutlich ein Thread, der extra dafür von mir eingerichtet wurde, damit man über die Lösung diskutieren kann oder auch Fragen dazu stellen kann - da verstehe ich den Sinn hinter der Bemerkung: "nur würde ich dann einen Pachtantrag bei Novice für diesen Thread stellen, dass nur noch kompetente Leute, mit entsprechendem Linux-Qualifikations-Nachweis hier Fragen stellen dürfen." überhaupt nicht mehr.

Ich habe aber auch keine Lust, mich immer wieder durch irgendwelche schriftlichen Kotaus zu arbeiten ... zeig' Rückgrat und vertritt Deine (begründbare) Meinung mit passenden Argumenten und es ist gar nicht notwendig immer wieder zu betonen, daß Du so gar keine Ahnung haben würdest. Stelle die Fragen, so Du welche hast, in ordentlicher Form (einen Link, wie man es nicht machen sollte, habe ich Dir an anderer Stelle schon hinterlassen) und alles ist in Ordnung ... sicherlich freut man sich auch über entsprechende Anerkennung, aber die Unterstellung, man (bzw. ich) würde das als eher elitäre Veranstaltung hier sehen und betreiben, ist einfach falsch.

Wir hatten einmal die Diskussion über Rezepte, Küchenchefs und wie jeder von uns beiden das sieht ... daher bin ich in #22 nur noch einmal auf Deine Bemerkung

Micha0815 schrieb:

und nicht gleich zu dolle "Schlitten-Fahren" mit mir, falls ich die Main-Unterschiede zw. modfs und modfs.starter nicht hinreichend erkannt habe!

Zum Vergrößern anklicken....

eingegangen, weil ich diese schon nicht verstehen kann. Wenn Dich die darauf folgende Erläuterung, warum nicht jeder Beitrag von mir vor Freundlichkeit nachgerade trieft, jetzt so sehr getroffen hat (und dabei zielte der nicht einmal direkt auf Dich, er sollte mehr die Grenzen, die ich mir selbst gesetzt habe, aufzeigen), dann kann ich es auch nicht ändern. Ich finde auch beim wiederholten Lesen nichts, was ich anders schreiben würde ... wenn Du Dich also von diesem Text hier "ausgeschlossen" oder "nur ungern in meinem Thread gelitten" siehst, verstehe ich Dein Problem nicht.

Frohes Fest ...

Micha0815 schrieb:

Bzw. nur auf beschwerlichen Umwegen? (die Quelle aus dem orginären modfs-Archiv fehlt ja erstmal?)

Zum Vergrößern anklicken....

Was heißt das genau?

Das

Micha0815 schrieb:

originäre modfs-Archiv

Zum Vergrößern anklicken....

steht noch genau an derselben Stelle, wo es vorher auch schon stand.

OT: Das kommt mir wie ein Reparurleitfaden zum Zündkerzen-Wechsel vor ... Motorhaube-Öffnen->Zündkerze lokalisieren->Motor Ausbauen->Zündkerze Wechseln -aber vorher Vergewissern ob Linksgewinde- ->Motor wieder Einbauen ... falls falsche Zündkerze/schlechtes Kerzenbild ... Vorgang wiederholen.OT/OFF

Zum Vergrößern anklicken....

Das ist gar nicht als Leitfaden gedacht und es soll auch modfs nicht ersetzen. Ich zitiere mich einfach einmal selbst:

PeterPawn schrieb:

So eine ShellInABox-Version hat natürlich auch ihre Nachteile [...] - sie ist eigentlich von mir auch eher als "Einstieg" in eine FRITZ!Box mit originaler AVM-Firmware und damit ohne Telnet-Zugang gedacht. Immerhin hat das gegenüber SSH den Vorteil, daß kein spezieller Client benötigt wird und ein Browser mit JavaScript-Unterstützung vollkommen ausreichend ist. Dieser "temporäre Charakter" ist auch der Grund, warum ich gar nicht in Erwägung gezogen habe, die ShellInABox-Instanz "nur bei Bedarf" zu starten, was ja als CGI auch problemlos möglich wäre oder sie gar in die Reste der ShellInABox-Integration von AVM wieder einzubetten.

Für eine dauerhafte Verwendung (auch wenn diese Modifikation mit ShellInABox ebenfalls schon dauerhaft ist) empfehle ich nach wie vor die Verwendung von modfs, da gibt es irgendwann auch mal eine verbesserte Version von mir.

Zum Vergrößern anklicken....

An der Vorgehensweise für das normale "modfs" hat sich eigentlich nichts geändert, nur braucht man jetzt nicht unbedingt das Pseudo-Image aus dem LCR-Thread, das erst alle Dienste abschießt und sie dann mehr schlecht als recht wieder startet - dieses Vorgehen hielt ich von Beginn an nicht für die sinnvollste Lösung, das habe ich auch mehrfach betont.

Insofern ist das "modfs-Starter" (ich habe mir bei der Namensgebung schon etwas gedacht) mit der von Dir abgegebenen Beschreibung vielleicht doch nicht so treffend charakterisiert. Es geht gar nicht darum, den Motor auszubauen - es geht darum, erst einmal die Wagentür und die Motorhaube zu öffnen, damit man an die Zündkerze herankommt und die dabei als erstes zu beantwortende Frage, ob man die Wagentür aufbrechen sollte oder doch lieber zum passenden Schlüssel greift.

Den anschließenden Zündkerzentausch kannst Du dann nach einem beliebigen Ratgeber vornehmen ... wenn Du die hier besprochene Lösung als irgendetwas "Abgeschlossenes" betrachten solltest (außer dem Nebeneffekt, daß man überhaupt einen permanenten Shell-Zugriff erhält, wenn man das Image mit ShellInABox von meinem Server verwendet), hast Du das einfach falsch verstanden.

Ich hatte auch schon versucht zu erläutern, daß man entweder meinen Vorschlag für /var/install und die im SquashFS-Image enthaltene rc.custom verwenden kann oder sich etwas vollkommen anderes ausdenken kann. Nicht einmal die Verwendung von SquashFS ist obligatorisch, das ist nur drin, weil ich es eben ohnehin bei mir verwende und um Platz zu sparen. Man kann genausogut die notwendigen Dateien direkt im Wrapper-FS ablegen und anstelle des SquashFS-Images ein bind-Mount machen oder auf die Verwendung von /var/custom komplett verzichten und direkt aus /wrapper/irgendwas starten. Ich verwende/bevorzuge halt bei allen Modifikationen das /var/custom (ist vielleicht schon in dem einen oder anderen Beitrag mal aufgetaucht), weil ich dann einfach durch Auslassen des Mountens unterhalb dieses Punktes sämtliche Anpassungen auf einen Schlag abschalten kann und sich das nicht über mehrere Skripte oder Verzeichnisse verteilt. Es gibt keine "Pflicht", es ebenso zu machen.

Der "Witz" an der Lösung ist auch nicht das eingebettete ShellInABox im meinem "Image" - das war einerseits ein Beispiel und als "Abfallprodukt" noch ein einfacher Einstieg in eine Shell auf der Box (eben modfs-Starter) - der Kern der Sache ist das Starten eigener Programme/Skripte über die /etc/inittab in der Wrapper-Partition und das dafür notwendige "Timing", damit der Start dann an der richtigen Stelle des Init-Prozesses erfolgt (man kann nämlich nicht einfach weitere Zeilen nach dem Start der rc.S in die inittab einfügen).

Wenn der Scrollback-Buffer von ShellInABox nicht ausreichend groß dimensioniert ist, kann man ja gerne mal darüber reden, ob man den nicht vergrößern könnte - auch das OnScreen-Keyboard kann man sicherlich an die deutsche Tastaturbelegung anpassen und ich persönlich verwende sogar eine SIAB-Instanz, die eine inverse Darstellung (white on black) bietet, wie ich es seit Jahren von Terminals gewohnt bin.

Ansonsten kann man das natürlich auch dazu benutzen, eigene Erweiterungen tatsächlich ohne "modfs" und damit in die komplett originale AVM-Firmware zu integrieren, dahin zielte ja wohl Deine Frage nach dem TFTP-Server in der FRITZ!Box. Das vorliegende tar-Archiv von meinem Server kann man dafür zwar als Vorlage nehmen, wie man es machen könnte, aber davon, daß man es irgendwie direkt modifizieren könne, habe ich niemals etwas geschrieben - eher das genaue Gegenteil wurde von mir in #29 (nach bestem Vermögen jedenfalls) propagiert. Dort wurde auch von mir erläutert, daß man so etwas eben erst einmal in /var/media/ftp zusammenstellt und testet, bis es wie erwartet funktioniert (da kann man nämlich ändern) und dann kann man darüber nachdenken, es in ein SquashFS-Image zu packen oder man läßt es sein.

Wer so etwas umsetzen will, nimmt sich das tar-File vom Server, entpackt es lokal und ändert die /var/install so ab, daß dort ein Inhalt nach /wrapper/sbin/flash_update geschrieben wird, der dann eben kein SquashFS-Image mountet und direkt aus /var/media/ftp irgendwelche Zusätze ausführt. Dazu muß man weder das SquashFS-Image anfassen noch muß man es verwenden, wenn man aus dieser Datei in /var/media/ftp dann eben irgendetwas unternimmt, um den "normalen Telnet-Daemon" zu starten. Das mache ich in dem von mir angebotenen Archiv absichtlich nicht - die Gründe habe ich dargelegt. Es ist absolut unmöglich, ein einzelnes Image zu erstellen, daß jedes Bedürfnis jedes potentiellen Anwenders abdeckt ... dazu habe ich nicht einmal im Ansatz den Ehrgeiz und daher wird es von mir max. drei konkrete Umsetzungen dieser Idee für die Öffentlichkeit geben. Welche das sein werden (SIAB, dropbear, SoftEther), habe ich auch schon irgendwo geschrieben.

Wenn irgendjemand es nach wie vor einfacher findet, ein Pseudo-Image zur Aktivierung des Telnet-Daemons bis zum nächsten Start der Box zu verwenden (bei NOR-Boxen funktioniert das hier ja gar nicht), dann bleibt ihm das unbenommen ... die "alte Methode zum Zündkerzenwechsel" funktioniert weiterhin und nur weil es jetzt eine Fernbedienung für die Tür (und in der Konsequenz für die zerstörungsfreie Entriegelung der Motorhaube) gibt, muß das niemanden davon abhalten, das Seitenfenster mit einem Stein einzuwerfen oder mit einem Brecheisen einzuschlagen.

C&P funktioniert nur eingeschränkt, da der programmgesteuerte Zugriff auf das Clipboard aus Sicherheitsgründen nicht ohne weiteres funktioniert, das änderte sich im Laufe der Zeit immer mal wieder und die heute aktuellen APIs dafür sind in Firefox erst seit Version 41 verfügbar: https://developer.mozilla.org/en-US/docs/Web/API/Document/execCommand#Browser_Compatibility

ShellInABox ist schon älter als diese Version und da das Low-Level-Handling der Tasten von der Terminal-Emulation im JavaScript-Code übernommen wird (sonst könnte man einige Kombinationen im Terminal nicht verwenden), wirken auch die bekannten Tastenkombinationen (Ctrl-V für "paste") nicht so, wie man es kennt. Das Kopieren/Einfügen über den eingeblendeten "Menüeintrag" (das ist ja nicht wirklich ein Menü des Browsers, das ist eine "div" von ShellInABox) erfordert eben den Zugriff auf das Clipboard von JavaScript aus, wenn es sich dabei nicht um Text aus dem eigenen Fenster handelt. Das sollte allerdings auch beim Firefox funktionieren (also Markieren von Text, Kopieren über rechte Maustaste und dann Einfügen dieses Textes) - alles andere erfordert Anpassungsarbeiten am JS-Code von SIAB. Wer sich dazu berufen und in der Lage fühlt, kann ja das entsprechende Ergebnis gerne teilen ...

Es wird (vielleicht) tatsächlich mal eine Version geben, wo man mit einem Rutsch durch ein einziges Image nach dem Neustart unter Verwendung eines Browsers sich ein erweitertes FRITZ!OS zusammenkonfigurieren kann. Das soll/wird dann aber auf die Kommandozeile verzichten ... so ein "Zwischenschritt" ist in meinen Augen dann nichts Halbes und nichts Ganzes. Wenn jemand mit der Kommandozeile nicht sicher umgehen kann, dann sollte man ihm gleich ein GUI anbieten, wo er (fast) nur noch klicken muß.

Auch sonst wäre es dann sicherlich sogar besser (meiner Meinung nach jedenfalls), wenn man das komplette modfs gleich mit in das SquashFS packt - dann braucht es den gesonderten Download nicht. Dann noch eine Erweiterung des "install"-Skripts aus dem tar-Archiv, damit da eine Aktualisierung einer älteren Version richtig arbeitet und man kann mit einem neuen Image auch eine ältere modfs-Version aktualisieren.

Das sind alles kleinere Änderungen, die ich gerne auf dem Server bereitstelle, wenn sie jemand vornehmen sollte - ich komme im Moment leider nicht dazu, für mich hat es derzeit Vorrang, bei der 06.50 der 7490 ein Problem mit dem WLAN zu suchen (daher im Moment auch keine Anstalten meinerseits, das install-Skript irgendwie zu erweitern für "Updates").

Es sollte ein Vorschlag sein und ein Beispiel, was man auf diesem Weg machen kann ... daß man das auch noch ausbauen kann, ist vollkommen klar - meine Prioritäten liegen im Moment halt woanders, schon das GUI der 06.50 braucht bei mir diverse zusätzliche Patches, die ich immer aufgeschoben hatte, bis das Release veröffentlicht wird. Jetzt ist es soweit und mich nervt es z.B. unendlich, daß man nicht mehr den Benutzernamen direkt im Login-Link angeben kann und immer erst mit der Mouse irgendwo hinklicken muß (das ist für mich als Keyboard-Fan die reinste Folter). Auch die fehlende Möglichkeit, das "captive portal" an eigene Bedürfnisse anzupassen, ärgert mich. Das sind alles Sachen, die (für mich) dringender sind ... das andere geht erst einmal, wenn auch vielleicht nicht auf die denkbar bequemste Art und Weise.

eines mit etwas kuriosen Datum

Zum Vergrößern anklicken....

Das mit dem Datum ist tatsächlich kurios ... ich schaue noch einmal nach, aber da wird m.E. die Ausgabe von /etc/version auf der Box verwendet - solange das andere Filesystem gemountet werden kann, was bei 2x 06.50 nicht das Problem sein dürfte. Ich sehe mal rein, ist ja eines der von mir bereitgestellten Modscripts für modfs, wo das dann enthalten ist.

Das mit dem Aus- und Einpacken eines Dateisystems mag ja nicht ganz trivial sein, aber da braucht es dann eben schon wieder die passenden Binärdateien und wenn man das im Einzelnen Schritt für Schritt erläutert und vielleicht auch noch ein, zwei passende Skriptdateien dazupacken will, kann/muß/sollte man auch gleich noch die fertigen Binaries mit in das Image aufnehmen (so ein originales AVM-Image enthält eben keine derartigen Utilities).

Da stellt sich dann irgendwann die Frage, wo man die Grenze ziehen will. Das sind eben alles "Zusatzteile" für's (Software-)"Modding" ... und solange es keinen Mechanismus in der FRITZ!Box für "kumulative Installationen" solcher Zusätze gibt (das nennt sich bei anderen Distributionen dann "Paket-Verwaltung"), ist das nicht trivial, weil man alles zusammenwerfen müßte und eben jeder andere Sachen braucht und/oder haben will. Während der eine dringend einen SSH-Server will, möchte der nächste "dnsmasq" und der übernächste braucht "OpenVPN". Das sind alleine mit diesen drei Paketen schon sieben verschiedene Images, die man bereitstellen müßte, wenn man auch noch denjenigen entgegenkommen will, die mehr als eines der Pakete brauchen (im Extremfall alle drei).

Nicht ganz umsonst ist Freetz eben eine Build-Umgebung für eine komplette eigene Firmware und keine Paket-Verwaltung. Wenn man so etwas als "Baukasten" und nicht als Monolithen auf die Beine stellen will (und das ist nach wie vor mein Ziel, weil es auf NAND-Boxen machbar ist), dann kommt man da alleine ohnehin nur sehr langsam vorwärts.

Setzt man dann keine Prioritäten (und verzettelt sich in vielen Kleinigkeiten), rinnt einem die Zeit durch die Finger. Es ist nicht so, daß ich nichts zu Ende bringen kann und will ... aber das, was von mir als Beispiel gedacht ist, will ich in der Regel nicht in alle möglichen Richtungen ausbauen (oder ich sage das von Beginn an auch so, daß da Erweiterungen geplant sind).

Das, was heute "modfs" ist und macht (inkl. der Möglichkeiten für Updates und Downgrade), war eigentlich auch niemals so gedacht ... die Idee hinter den Modscripts war ja eigentlich auch nur das "Angebot", daß sich jeder seine eigenen Skripte dort schreiben kann und so das System auch ohne Freetz im Rahmen der bestehenden Möglichkeiten (die natürlich kleiner sind als bei einer kompletten Build-Umgebung) anpassen könnte. Ich habe bei mir jede Menge zusätzliche Modscripts (allerdings installieren einige davon zusätzliche Binärpakete, die ich mir zusammengestellt habe), ich habe aber bisher noch von niemandem gehört (auch nicht per E-Mail und da bin ich im Gegensatz zur PM hier durchaus noch zu erreichen), der seinerseits ein allgemein nutzbares Skript erstellt hätte und das nun gerne veröffentlicht bzw. sogar in das modfs-Download-File integriert hätte.

Ich fände es z.B. wirklich gut und eine Entlastung, wenn sich jemand anderes ebenfalls der Fragen annehmen und an meiner Stelle antworten würde. Wenn dann mal eine Erklärung nicht ganz stimmt, man noch einen Kommentar abgeben will oder jemand anderes einen anderen (ggf. sogar besseren) Vorschlag hat, dann kann man das ja immer noch "ausdiskutieren" und unterschiedliche Entwürfe/Vorgehensweisen gegeneinander abwägen und sich vielleicht sogar gemeinsam für einen guten Weg entscheiden.

Das ist für mich das "Community-Prinzip" ... von mir gibt es eben keine "closed source"-Geschichten, die man downloaden und ausführen muß. Das wäre teilweise sogar effektiver als für jeden lesbarer Shell-Code, aber das ist für mich eine Frage des Prinzips und eben auch eine Voraussetzung für gemeinsames Arbeiten in einer Community. Als einzelner "Vortänzer" fühle ich mich alles andere als wohl ... viel lieber gehe ich hin und suche neue Möglichkeiten, als die bereits gefundenen dann - jenseits von Beispielen - in konkrete Projekte zu gießen. Ich will eigentlich (mit den bisher veröffentlichten Teilen) nur Anregungen und ggf. Unterstützung bei Problemen geben, wenn jemand anderes mit seiner Umsetzung nicht klarkommt. Mein Fernziel ist etwas anderes ...

Ein komplettes Projekt hochzuziehen (egal ob ein kleines oder ein großes) ist für einen Einzelnen immer ein Drahtseilakt ... einerseits dauert es ewig, bis man etwas sieht - wenn man nicht kleinere Steps auf dem Weg zum Ziel in anderem Zusammenhang ebenfalls verwenden kann und sich so peu a peu seinen "Baukasten" zusammenstellt. Andererseits muß man dann eben aufpassen, daß man nicht zuviel mit diesen "Bausteinen" spielt und dann zwar im Lego-Land ankommt, aber das eigentliche Ziel in immer weitere Ferne rücken sieht.

Deshalb auch meinerseits schon mehrfache Aufrufe, einfach mitzumachen ... selbst jemand, der "nur" HTML kennt und ein Formular designen kann, ist doch geradezu dafür prädestiniert, an einem "allgemeinen Image" mitzuarbeiten, mit dem man verschiedene "Dienstprogramme" auf einer FRITZ!Box nachrüsten könnte - das geht beim "Komplettbackup" los, zieht sich über das Zurücksetzen von "Nicht autorisierten Änderungen" bis zum Ändern von Brandings, "provider additive"-Einstellungen und anderen bei AVM versteckten Einstellungen.

So ein Image habe ich vor 4-5 Monaten mal angeregt ... damals noch im LCR-Thread. Die Reaktionen waren so, daß ich mir jeden weiteren Gedanken in dieser Richtung selbst verboten habe ... einfach deshalb, weil man als einzelner "Urheber" dann sofort wieder die Verpflichtung erbt, das auch entsprechend zu warten und/oder zu erweitern, wenn weitere Wünsche kommen (womit wir dann wieder beim erwähnten "Verzetteln" sind). Kann man das auf mehrere Schultern verteilen, ist das eine vollkommen andere Situation - dann kann man solche Sachen auch tatsächlich "anbieten".

Mir ist auch bewußt, daß es für viele dieser Möglichkeiten schon andere Tools gibt (auch wenn das alles ziemlich verstreut ist an Informationen), aber die Situation hat sich bei vielen Benutzern eben auch geändert und an die Stelle des Windows-PCs für das ruKernelTool oder der Linux-Maschine für Freetz tritt in vielen Haushalten das Android-Tablet oder das Smartphone und für diese Geräte gibt es solche Möglichkeiten bisher eben nicht. Sicherlich hat auch AVM nicht ganz zufällig dem neuen FRITZ!OS eine Oberfläche spendiert, die auch auf solchen Geräten bedienbar ist ... so ganz neu sind solche Ideen und Forderungen ja auch nicht, hier hatten wir schon vor 1,5 Jahren in der Diskussion, daß der "klassische PC" immer weiter ausstirbt und dann auch solche Geschichten wie das Freetz-GUI an Wert verlieren, wenn man sie nicht von Tablets/Smartphones mit HTML5 anstelle von uralten Frames ordentlich bedienen kann.

Ich weiß nicht genau, ob meine Zurückhaltung, meinerseits das "modfs-Starter"-Prinzip in diverse Richtungen zu erweitern, jetzt besser zu verstehen ist ... es mag tatsächlich "Bedarf" dafür geben, aber ich werde es nicht schaffen, so etwas alleine umzusetzen und insofern sind auch solche Änderungswünsche, wie Du sie geäußert hast unter dem Aspekt eines direkten Starts von modfs aus dem ShellInABox-Beispiel heraus, nur eine mögliche Richtung.

Setze ich das jetzt zu eilfertig um (weil ich es auch richtig und nötig finde), kommt der nächste mit einem anderen Wunsch ... da kann es dann m.E. nur "alle oder keiner" geben und daher gibt es von mir eben auch nur genau das, was ich ohnehin selbst machen wollte und was ich für notwendig erachte. Wenn jemand mit guten Argumenten mir Änderungen an bestehenden Lösungen nahelegt, setze ich die auch noch um ... genauso wie Fehlersuchen in den eigenen "Schöpfungen" eine Selbstverständlichkeit sind.

Alles andere, was zu einem ausgedehnten "Fluß-Delta" an möglichen Wünschen und Lösungen führt, lehne ich dann ab, wenn ich es warten bzw. erst mal implementieren soll. Möchte das jemand anderes machen, kann er/sie auf meine Unterstützung (im Rahmen meiner Möglichkeiten) bauen.

Auch wenn so ausführliche Erklärungen vielleicht sogar mehr Zeit in Anspruch nehmen, als schnell irgendetwas in die Tastatur zu hacken, ist das m.E. trotzdem der bessere (und für mich richtige) Weg. Ich will niemanden vor den Kopf stoßen ... aber ich kenne auch meine Grenzen und werde mich nicht ohne Not "übernehmen" bei dem Versuch, es jedem recht zu machen.