Mit dem /opt Laufwerk könnte doch die bisherige Krücke, Dateien per NVRAM abzulegen, entfallen!? Sprich, ein custom_script.sh könnte doch dort liegen, bzw ein dort abgelegtes (primär oder zusätzlich) zur Ausführung gebracht werden. Bzw, wäre es auch hilfreich, wenn Inhalte in /opt Dateien, die in den nichtbeschreibbaren Bereichen liegen, "überscheiben" würden, so dass man in der Lage wäre, jeglichen Aufruf zu wrappen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Daten in /opt können evtl. durch verschieden große Images gelöscht werden. der NVRAM bleibt hingegen über jeden Updatevorgang hinweg erhalten, es sei denn es wird ein Reset oder ein Notflash vorgenommen.
Deshalb ist es sinnvoll das beizubehalten, zumal es ja kein Problem ist ein Skript in /opt zu rufen.
Um Aufrufe umzuleiten brauchst du bloß die PATH Variable entsprechend setzen und exportieren.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ja, ja... aber PATH könnte ja bereits initial zb /opt/bin an erster Stelle haben und für die Dinge die absolut aufgerufen werden (Startscripte) hätte dies ja keine Auswirkung.
Und an der Notwendigkeit, dass man vor einem Flash seine Änderungen sichern "sollte", würde sich auch nichts ändern.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Ja, ja... aber PATH könnte ja bereits initial zb /opt/bin an erster Stelle haben und für die Dinge die absolut aufgerufen werden (Startscripte) hätte dies ja keine Auswirkung..." sprich, die könnte man damit noch nicht überschreiben/wrappen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Deine Idee das gesamte Image in eine JFFS2-Partiton zu legen ist nicht möglich. Der gesamte Flash ist lediglich 4MB groß. Das gesamte Image ist aber unkomprimiert etwa 10 bis 12MB groß und würde wahrscheinlich nicht in eine etwa 3,3MB (wegen Bootloader, Kernel und NVRAM) große JFFS2-Partition passen bzw. es wäre nicht mehr ein MB frei. Dies geht nur bei Routern die 8MB oder mehr Flash besitzen.
Möchtet du z.B. "/etc/start_scrits" überschreiben, könntest du das Verzeichnis auch "übermounten":
mount -t tmpfs -o size=100k tmpfs /etc/start_scripts
und in diesem neuen Verzeichnis Links auf /opt anlegen. Oder du mountes die JFFS2-Partition nach /etc/start_scripts.
Aber das einfachste wird wohl sein, wenn du alle deine Start-Skripts in /opt anlegst und diese vom Custom-Skript aus startest.
Ansonsten hast du natürlich die Möglichkeit die Sourcen herunterzuladen und das Image ganz deinen Bedürfnissen anzupassen.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Das /opt Verzeichnis soll nicht das gesamte Image aufnehmen, sondern "könnte" die Möglichkeit bieten, einzelne Inhalte aus dem Image einfachst und generisch zu "überschreiben". Für Sachen die über den PATH gestartet werden, müsste halt sowas wie /opt/bin in PATH an erster Stelle sein. Bei den cgi-Scripten könnten die Scripte auf namensgleiche Versionen in /opt/cgi-bin/ abfragen und bei Erfolg dorthin verzweigen. Gleiches für die Start-Scripte.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Da da du dich ja offensichtlich gut auskennst, sollte es doch kein Problem für dich sein den dev_tree
herunterzuladen und die gewünschten Änderungen selbst einzupflegen.
Die PATH-Variable kann ich bei zukünftigen Versionen entsprechend ändern, aber alle Skripte deshalb
anzufassen halte ich nicht für nicht sinnvoll. Stelle dir doch vor du legst beispielsweise fehlerhafte
Skripte dort ab, dann fährt der Router womöglich nicht mehr richtig hoch.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ist ja nur ne Anregung... und sicher nicht für die Mehrheit der Anwender relevant. Bilde mir nur ein, dass mir das Nützen könnte, weil ja doch vieles über die Scripte abgewickelt wird und mit dem Feature wäre dann der Kasten selbst die Entwicklungsumgebung.
Wg den fehlerhaften Scripten... das Problem hat man mit dem custom_script doch auch schon!? Wenn darin Mist wäre, hat man auch ein Problem. Und für leichtere Fehlleistung könnte man der Kiste beispielsweise per Resettastertrick ein entsprechende Variable im NVRAM setzen, welches die Ausführung der Ersatzscripte aus /opt unterbindet.
Und die Scripte umzustellen ist wahrscheinlich auch kein Hexenwerk, da jedes Script halt den gleichen "Dreizeiler" am Anfang hätte, der abfrägt, ob sich `basename $0` in /opt/tralala befindet und dann den Aufruf macht oder ihn sein lässt.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mit dem /opt Laufwerk könnte doch die bisherige Krücke, Dateien per NVRAM abzulegen, entfallen!? Sprich, ein custom_script.sh könnte doch dort liegen, bzw ein dort abgelegtes (primär oder zusätzlich) zur Ausführung gebracht werden. Bzw, wäre es auch hilfreich, wenn Inhalte in /opt Dateien, die in den nichtbeschreibbaren Bereichen liegen, "überscheiben" würden, so dass man in der Lage wäre, jeglichen Aufruf zu wrappen.
Daten in /opt können evtl. durch verschieden große Images gelöscht werden. der NVRAM bleibt hingegen über jeden Updatevorgang hinweg erhalten, es sei denn es wird ein Reset oder ein Notflash vorgenommen.
Deshalb ist es sinnvoll das beizubehalten, zumal es ja kein Problem ist ein Skript in /opt zu rufen.
Um Aufrufe umzuleiten brauchst du bloß die PATH Variable entsprechend setzen und exportieren.
Ja, ja... aber PATH könnte ja bereits initial zb /opt/bin an erster Stelle haben und für die Dinge die absolut aufgerufen werden (Startscripte) hätte dies ja keine Auswirkung.
Und an der Notwendigkeit, dass man vor einem Flash seine Änderungen sichern "sollte", würde sich auch nichts ändern.
"Ja, ja... aber PATH könnte ja bereits initial zb /opt/bin an erster Stelle haben und für die Dinge die absolut aufgerufen werden (Startscripte) hätte dies ja keine Auswirkung..." sprich, die könnte man damit noch nicht überschreiben/wrappen.
Deine Idee das gesamte Image in eine JFFS2-Partiton zu legen ist nicht möglich. Der gesamte Flash ist lediglich 4MB groß. Das gesamte Image ist aber unkomprimiert etwa 10 bis 12MB groß und würde wahrscheinlich nicht in eine etwa 3,3MB (wegen Bootloader, Kernel und NVRAM) große JFFS2-Partition passen bzw. es wäre nicht mehr ein MB frei. Dies geht nur bei Routern die 8MB oder mehr Flash besitzen.
Möchtet du z.B. "/etc/start_scrits" überschreiben, könntest du das Verzeichnis auch "übermounten":
mount -t tmpfs -o size=100k tmpfs /etc/start_scripts
und in diesem neuen Verzeichnis Links auf /opt anlegen. Oder du mountes die JFFS2-Partition nach /etc/start_scripts.
Aber das einfachste wird wohl sein, wenn du alle deine Start-Skripts in /opt anlegst und diese vom Custom-Skript aus startest.
Ansonsten hast du natürlich die Möglichkeit die Sourcen herunterzuladen und das Image ganz deinen Bedürfnissen anzupassen.
Das /opt Verzeichnis soll nicht das gesamte Image aufnehmen, sondern "könnte" die Möglichkeit bieten, einzelne Inhalte aus dem Image einfachst und generisch zu "überschreiben". Für Sachen die über den PATH gestartet werden, müsste halt sowas wie /opt/bin in PATH an erster Stelle sein. Bei den cgi-Scripten könnten die Scripte auf namensgleiche Versionen in /opt/cgi-bin/ abfragen und bei Erfolg dorthin verzweigen. Gleiches für die Start-Scripte.
Da da du dich ja offensichtlich gut auskennst, sollte es doch kein Problem für dich sein den dev_tree
herunterzuladen und die gewünschten Änderungen selbst einzupflegen.
Die PATH-Variable kann ich bei zukünftigen Versionen entsprechend ändern, aber alle Skripte deshalb
anzufassen halte ich nicht für nicht sinnvoll. Stelle dir doch vor du legst beispielsweise fehlerhafte
Skripte dort ab, dann fährt der Router womöglich nicht mehr richtig hoch.
Ist ja nur ne Anregung... und sicher nicht für die Mehrheit der Anwender relevant. Bilde mir nur ein, dass mir das Nützen könnte, weil ja doch vieles über die Scripte abgewickelt wird und mit dem Feature wäre dann der Kasten selbst die Entwicklungsumgebung.
Wg den fehlerhaften Scripten... das Problem hat man mit dem custom_script doch auch schon!? Wenn darin Mist wäre, hat man auch ein Problem. Und für leichtere Fehlleistung könnte man der Kiste beispielsweise per Resettastertrick ein entsprechende Variable im NVRAM setzen, welches die Ausführung der Ersatzscripte aus /opt unterbindet.
Und die Scripte umzustellen ist wahrscheinlich auch kein Hexenwerk, da jedes Script halt den gleichen "Dreizeiler" am Anfang hätte, der abfrägt, ob sich `basename $0` in /opt/tralala befindet und dann den Aufruf macht oder ihn sein lässt.