Wo kann ich ein Verzeichnis erstellen was bleibt

[daewoo42]

Hallo,

bin seit 2 Tagen Besitzer einer FBF Wlan und hab jetzt schon ein kleines Problem.
Da ich auf meine alte TK ganz verzichten will, aber ich eine Funktion bei der FBF vemisse habe ich mir 2 kleine Scripte geschrieben die als Cronjob ausgeführt werden sollen.
Und zwar habe ich eine FX_Conf.tag und eine FX_conf.nacht die zu bestimmten Zeiten die FX_conf überschreiben um zu verhindern das unsere Tochter die ganze Nacht telefoniert.
Das ganze fuktioniert auch super, nur nach einen Reboot sind natürlich meine Scripte und die 2 Conf`s weg.( hatte sie im /var/flash)

Nun die eigentliche Frage:
Gibt es einen Bereich in der FBF in der man Dateien ablegen kann die auch nach einen Reboot noch da sind?

 

[crusader]

Hi,

Der einzige Ort, der ein reboot überlebt, ist die Datei /var/flash/debug.cfg.
Da diese Datei beim init der Box ausgeführt wird, kannst du z.B. die Zeile
"cat <<\\EOF > /var/tmp/FX-conf.tag" dort eintragen, danach deine FX-Conf.tag-Datei dort hineinschreiben und mit einer Zeile, in der EOF steht abschließen.

Guter Trick :idea: , aber geklaut 8)

crusader

 

[daewoo42]

Leider ist die Datei "fx_conf" im Binär-Format und 10k groß.
Ist das nicht etwas viel um das noch in debug.cfg zu packen?
zumal ich ads auch 2x brauch, Tag+Nacht
kann man mit vi über ein Script eine Datei editieren lassen?
Weil ein script läßt sich so ja problemlos erstellen

 

[haveaniceday]

Hi daewoo42,

vorab 2 x 10 kb ist ziemlich groß. Die Fritzbox hat mal gerade 64 kb für die Konfiguration.
In diesem Bereich liegt auch debug.cfg.

Für "mod-0.53" hatte ich die Keydateien von dropbear ( sind binär ) mit uuencode/uudecode in debug.cfg abgelegt.
Ich kann aber bei der Größe nicht sagen ob das geht oder Probleme gibt.

( (original fx_conf 10 k + 2 x uuencode- fx_conf 10 k + ??? reguläre konfig) <= 64 kb ?)

Kanst ja mal in das Skript "modstart" von Thread 6666 schaun. http://www.ip-phone-forum.de/forum/viewtopic.php?t=6666

Für das uuencode/uudecode benötigst du dann auch modifizierte Software und ein Script welches die Umschaltung vornimmt.
( Anspruchsvoll, da nach einem Neustart die Zeit "springt"...)

Haveaniceday

 

[crusader]

Hört sich aber nach heftigem Aufwand an.

Vielleicht sollte daewoo42 doch noch mal mit seiner Tochter reden ....

 

[daewoo42]

da lass ich es doch erst mal die Finger von und lass alles im /var/tmp und schieb es halt nach einen reboot neu rüber. (Box läuft ja eigentlich stabil)
Vielleicht gibt es ja im nächsten mod ein Verzeichnis zu Spielen in dem die Daten bei reboot erhalten bleiben. Ich brauch ja nur 20k

 

[daewoo42]

@crusader
ich sag nur teenager


eigentlich hält sich der Aufwand ja in Grenzen.
2x Cronjob - bleibt bei reboot erhalten
2x Script - lass ich über die debug.cfg erstellen ( danke für den Tip) bleibt also auch
2x fx_conf - muss ich halt nach reboot neu auf die FBF kopieren

in den scripts hab ich eigentlich nur ein killall 15 telefon, dann fx_conf kopieren und telefon neu starten, läuft auch soweit

 

[crusader]

ich sag nur teenager

Achduscheisse. Da müssen wir aber doch noch mal nachdenken:

Also ich hab in der debug.cfg gleich noch eine Zeile eingebaut, die über einen tftp-Aufruf die benötigten Files nach /var/... kopiert.
Läuft natürlich nur, falls beim reboot auch der tftp-Server läuft, aber immerhin...

crusader

 

[daewoo42]

tftp-server, da fällt mir doch gerade noch was anderes ein.
was hälst du davon:
Habe auf meiner Dreambox doch einen NFS-Server laufen, den sollte ich doch eigentlich mounten können.
Ich denke das die 120 GB reichen sollten.

 

[crusader]

Hat man da noch Töne ?
Der Mensch hat 120G im Netzwerk und wir zermartern uns das Hirn, wie wir 10k in seine debug.cfg reinquetschen.

Mit NFS hab ich allerdings noch nix gemacht. Sollte aber so gehen, denke ich.

crusader

 

[daewoo42]

so gerade mal ausprobiert
hab die debug.cfg so geändert das beim reboot ein Verzeichnis /var/nfs erstellt wird, das wird an der Dreambox gemountet, die Dateien werden nach /var/tmp kopiert, vorher hab ich noch ein sleep drin - die Festplatte mußja erst anlaufen
Hat alles funktioniert, nach dem reboot hatte ich die fx_conf.tag und fx_conf.nacht im /var/tmp liegen.
Danke für eure Tips

am besten wenn ich nach dem kopieren gleich noch umount mache

 

[Pumbaa80]

Der einzige Ort, der ein reboot überlebt, ist die Datei /var/flash/debug.cfg.

Öhm, äh, ich trau mich gar nicht zu fragen...
Wie funktioniert das technisch?
Ist das original-Image auf der Box gespeichert und wird beim reboot wiederhergestellt, oder wie? :doof:

 

[danisahne]

Der einzige Ort, der ein reboot überlebt, ist die Datei /var/flash/debug.cfg.

Öhm, äh, ich trau mich gar nicht zu fragen...
Wie funktioniert das technisch?
Ist das original-Image auf der Box gespeichert und wird beim reboot wiederhergestellt, oder wie? :doof:

Nene, das Dateisystem und der Kernel sind schon fest drauf, man kann sie aber nur mit einem Firmwareupdate (und ein paar anderen Möglichkeiten) auf einmal verändern, also nicht im laufenden Betrieb einfach mal ne Datei erstellen. Die debug.cfg ist als einzige Datei frei verfügbar, die ihren Inhalt behält, und im laufenden Betrieb veränderbar.

Edit:
debug.cfg ist ein character device, keine herkömmliche Datei

 

[Pumbaa80]

:gruebel:
Sorry, ich kenn mich nicht so furchtbar gut mit Unix aus.
Aber ich beginne zu verstehen.
Soso, ls -l zeigt fast ausnahmslos read-only, außer in /var.

Was mich wundert: Die ganzen .cfg's im /var/flash können ja mit nvi bearbeitet werden und bleiben beim reboot erhalten, oder?
Warum also verschwinden selbst erstellte Skripte?

 

[danisahne]

/var ist soweit ich weiß ein cramfs, also ein Dateisystem, dass sich im Arbeitsspeicher befindet. Darum sind da auch alle Änderungen wieder weg, wenn man die Box neustartet.

Die Dateien in /var/flash (also alle, die schon da sind; ls -l zeigt hier ein c bei den Dateirechten) sind character devices, die soweit ich weiß in einen 64K großen Flash schreiben.

 

[Pumbaa80]

Also zusammenfassend:

- Die character devices (nicht nur debug.cfg) können verändert werden und bleiben beim reboot erhalten
- Im Verzeichnis /var (außer in /var/flash) kann man 'gefahrlos' Experimente treiben, da nach einem reboot sowieso alles wieder auf Anfang ist
- In sonstigen Verzeichnissen kann man nur mittels Firmwareupdate Dateien ändern, ansonsten alles read-only

Richtig?
Wie sieht das mit SSH(dropbear) aus?

 

[danisahne]

Richtig?

Richtig

Wie sieht das mit SSH(dropbear) aus?

Meinst du die Keys vom Dropbear? Die kann man in der debug.cfg mit uuencode unterbringen. Wie das geht wurde schon öfter im Forum erklärt.

 

[Pumbaa80]

Richtig

okay, vielen Dank !

Ich meinte eigentlich, ob die Zugriffsberechtigungen mit dropbear irgendwie zu umgehen sind.
Aber bei nochmaliger Überlegung denke ich, dass das wohl eher nicht der Fall ist

 

[danisahne]

Dropbear muss wie auch telnet mit dem Dateisystem so wie es ist zurechtkommen. Sind beides Daemons, die das gleiche Dateisystem sehen. In Windows ist es auch egal, mit welchem Programm du auf deine Festplatte zugreifst, C: sieht meist gleich aus

 

[olistudent]

/var ist soweit ich weiß ein cramfs, also ein Dateisystem, dass sich im Arbeitsspeicher befindet. Darum sind da auch alle Änderungen wieder weg, wenn man die Box neustartet.

Die Dateien in /var/flash (also alle, die schon da sind; ls -l zeigt hier ein c bei den Dateirechten) sind character devices, die soweit ich weiß in einen 64K großen Flash schreiben.

Äh, du meinst ramfs, gell? cramfs war früher bei der dbox2.
Und mann kann in /var/flash auch selbst Dateien anlegen, die auch einen reboot überleben.

mknod /var/flash/test c 254 $((0x79))
echo test > /var/flash/test
reboot
mknod /var/flash/test c 254 $((0x79))
cat /var/flash/test

Und dann sollte der Inhalt der Datei kommen... ;-)

MfG Oliver