WebIF - Dateiname des geflashten Images

Gar nicht, das musst du händisch aufrufen....

http://fritz.box/cgi-bin/system_status

das bringt nicht wirklich den gewünschten effekt. Versteh nich wo das problem liegt. Das freetz WebIF macht es 3 Zeilen weiter oben (status.cgi) genau nach diesem Prinzip. Sicher ist das nicht die eleganteste Lösung, aber sie erfüllt ihren Zweck. Denke man sollte das nicht verkomplizieren.
 
Kann man halten wie ein Dachdecker, denke ich, nur ist system_status der Ort, an dem ich solche Infos sammeln würde, da da sowieso schon irgendwas steht, was der Ottonormaluser nicht benötigt.
 
nur da ich es in das WebIF integrieren möchte, und nicht jedesmal system_status aufrufen will, ist die im Patch enthaltene Methode die schnellste. Ins freetz WebIF guckt eh kein Ottonormaluser.

Ich bitte daher um integration in freetz!
 
Es geht viel mehr nicht darum, wo man es darstellt, sondern wo und wie man es speichert.
system_status als cgi-Skript unter /usr/bin mit untermauerten html-Befehlen zu speichern finde ich persönlich nicht ganz glücklich. Wurde es so von AVM angelegt und wird irgendwo weiter von AVM verwendet oder ist es eine reine FREETZ-Creation?
Besser wäre es, die Variablen im FREETZ-CFG-Format irgendwo im Image zu speichern. Einlesen könnte man sie dann nach der beliebten "include"-Methode von FREETZ und weiterhin in den cgi-s verwenden. Wenn wegen AVM nötig, könnte man die system_status - CGI dadrauf anpassen und ansonsten die CFG überall dort einbauen, wo man es will. Dann sehen cgi-s nicht so kompliziert aus und man kann es auch in nicht-cgi-Shell-Skripten verwenden.

MfG
 
dann müsste aber die variable kurz vor dem packen ins image, und die entsprechende variable auf der box überschrieben werden. mit welcher variable wird das drzeit in freetz so gemacht?
 
Es wird mit keiner Variable derzeit in FREETZ so gemacht. Es ist schon klar, dass man die Info über Dateiname kurz vor dem Packen haben muss. Das war aber oben bereits angesprochen, dass man die Namensgebung etwas nach vorne verschieben könnte, um dies zu erreichen. Mein Vorschlag zielt in die Richtung besserer Strukturierung beim Abspeichern / Auslesen von diesen Infos.

MfG
 
Die Idee der besseren Abspeicherung ist schon nicht schlecht, nur finde ich dies im Rahmen dieser kleinen Änderung zu diskutieren deplaziert, und dadurch sehe ich das Einbinden in Gefahr.
 
Nun, ich wiederum würde das für wirklich sinnvoll halten. Zumindest sinnvoller, als denn diese Änderung auf die Webinterfaceseite zu bringen, wobei doch die wenigsten User genau diese Info wirklich brauchen.
Somit: Eher in Richtung Hermans Vorschlag gehen, und das Ganze noch ein bisschen weiterführen, indem man eine zusätzliche Seite ins Webinterface implementiert mit allen möglichen Informationen zum Image selber.
Halte ich eindeutig mehr von.

@astrapi: Derweil kennst du ja die fwmod_custom, bis sich dahingehend was herauskristallisiert hat.
 
also mit einer zusätzlichen seite im webif kann ich mich anfreunden, vielleicht unter extras?

edit: oder die extras.cgi entsprechend anpassen, sodass sie den inhalt von system_status anzeigt.
 
Mein Vorschlag geht es ja in die Richtung: Wenn die Infos vernünftig gespeichert sind, dann ist es auch sehr leicht sie darzustellen. Man kann die Variables in erprobter und bekannter FREETZ-Manier auslesen und darstellen. Ob man nun nachher alles auf eine Seite bringt, oder die Infos streut und nur das Wesentliche als "Überschrift" zusammensetzt, kann man nachher diskutieren. Diese zusätzliche Seite könnte man am leichtesten als "web-gui-Paket" ins FREETZ integrieren. Wer es braucht, der nimmt es mit.
Aber ich betone nochmal: CGI ist die Nebensache und in 5 Minuten programmiert, wenn der Rest vorher vernünftig durchdacht und definiert wurde.

MfG
 
Man kann die Variables in erprobter und bekannter FREETZ-Manier auslesen und darstellen.

Mach das mal bitte an einem Beispiel fest.
 
@astrapi: Du hast Recht, wir haben es lang genug diskutiert. Nun sind die Taten gefragt.
Anbei ist der erste Schuss meinerseits, um das oben diskutierte Thema etwas handfester zu implementieren. Gemacht sind folgende Sachen:
1. Generierung des Zeitstempels und Image-Namen ist etwas nach vorne geschoben, wie oben empfohlen. Sonst würde sich die Katze am Schwanz beißen.
2. Wie gewollt wird Name vom Image verarbeitet, wobei ich es inzwischen auch für wenig sinnvoll halte. Und wo ich da beim namen schon sowieso dabei war, hatte ich Testweise noch einige weitere Rohparameter eingefügt.
3. Anstatt Namen würde evtl. ein benutzerdefinierter String vielleicht mehr Sinn machen. Dies hatte ich nebenbei ins "menuconfig" verbastelt. Einfach unter "Advanced Options" schauen.
4. Wie versprochen werden Daten im FREETZ-typischen "Importformat" unter /etc/freetz_info.cfg abgelegt. Es sieht dann in etwa so aus:
Code:
export FREETZ_INFO_BOXTYPE='7170'
export FREETZ_INFO_FIRMWAREVERSION='04.76'
export FREETZ_INFO_SUBVERSION='freetz-devel-3574M'
export FREETZ_INFO_LANG='de'
export FREETZ_INFO_MAKEDATE='20090815-033050'
export FREETZ_INFO_IMAGE_NAME='7170_04.76freetz-devel-3574M.de_20090815-033050.image'
export FREETZ_INFO_COMMENT='hermanns image'
5. cgi-s oder sonstige Darstellungsmöglichkeiten sind noch nicht implementiert. Aber sie sind leicht nachzupflegen wie eben "die Erweiterung des Angebotes". Ich meine, dass man dort z.B. noch Pakete abspeichern könnte oder ausgelagerte Dateien oder noch etwas.


Ich bitte die Spezialisten unter uns mein Patch unter die Lupe zu nehmen und ggf. in trunk einzupflegen. An sich sind es keine gravierenden Änderungen, die das Erstellen vom Image in irgendeiner Weise behindern sollten oder nachher die Stabilität auf der Box.

MfG
 

Anhänge

  • freetz_info.patch.bz2
    1 KB · Aufrufe: 3
Freetz-Info v1.1

Ich erlaube mir ein Doppelpost, weil ich meine Version des hier diskutierten Vorhabens etwas erweitert hatte, sodass man die Statusinfos nun auf einer separaten Seite in FREETZ anschauen kann.

Bitte diese Version ebenfalls nur als ersten Schuss betrachten. Man kann die Infos sicherlich erweitern / verändern. Und über die Doppelspeicherung solcher Infos wie Firmware-Bezeichnung sollte man sich ebenfalls noch Gedanken machen.

Ich bitte unsere Developer und alle Interessenten diese Info-Erweiterung zu testen, damit es baldmöglichst ins FREETZ einfließen kann, wenn natürlich dafür Interesse besteht.

Insbesondere sind für mich Tester ohne external und ohne Benutzerstring von Interesse. Mich würde interessieren, ob alles trotz fehlenden Infos läuft.

MfG
 

Anhänge

  • freetz_info.jpg
    freetz_info.jpg
    54.8 KB · Aufrufe: 40
  • freetz_info_v1_1.patch.bz2
    1.9 KB · Aufrufe: 6
frisch ausgecheckt und nur den patch angewendet:

Code:
[B]Fehler:[/B] Kein Skript für das die Statusanzeige 'infos/mod/infos'.

Ansonsten aber klasse!!!
 
Ach, dieses "svn diff" und co bringen mich um. Da soll noch infos.cgi rein. Ich hab sie zwar mit "svn add" eingefügt, aber wahrscheinlich nicht so ganz richtig. Ich lese mal unser WIKI dazu. Da stand es irgendwo drinne...

Edit: Kannst du bitte im folgenden Verzeichnis der build-Umgebung schauen:

Code:
root/usr/lib/cgi-bin/mod

Dort sollte neben logs.cgi und mounted.cgi nun noch infos.cgi liegen. Und sie sollte 755 als Rechte haben.
Ich weiß auch nicht, was dort beim patch-Erstellen schief gegangen ist.

Edit2:
Das sind definitiv die Rechte. Ich hatte es gerade bei mir nachvollzogen. infos.cgi fehlen Ausführungsrechte. Deswegen wird es nachher im Image nicht gefunden.

Kann bitte jemand von SVN-Gurus unter uns mir sagen, wie ich ein patch so erstellen kann, dass auch die Rechte stimmen. "svn add" und "svn diff" ohne Parameter helfen hier leider nicht...

Edit3:
Wie eben mit Oliver diskutiert: Das ist ein generelles problem von "patch". Es versteht eben die Rechte von "svn diff" nicht, obwohl sie im patch eigentlich drin stehen.
Nach dem Ausführen des patches ist also noch ein chmod erforderlich:
Code:
[COLOR="Red"]chmod 755 root/usr/lib/cgi-bin/mod/infos.cgi[/COLOR]

MfG
 
Zuletzt bearbeitet:
Jups, richtig funktionieren tut das nur nach einem svn ci von einem System aus, wo die Rechte richtig gesetzt sind.
 
Abgesehen von den fehlenden Rechten, die man zum patch zusätzlich setzen muss, sehe ich irgendwie kein grosses Interesse seitens Community an der Info-Erweiterung. Nur zwei Downloads...
Sollen wir die Sache irgendwie weiter verfolgen? Soll ich es als Feature-Ticket in unserem trac verewigen, damit es nicht in Vergessenheit gerät? Oder vergessen wir es so einfach für immer?
Wie ich schon sagte, man kann es auch mit anderen Infos füttern. Die Basis (wie man es realisieren kann) steht mehr oder weniger fertig.

MfG
 
Is ja schon gut, meld mich ja schon. Mir is der Thread halt grad erst über den Weg gelaufen. Ich inds jedenfalls ne gute Idee.
Besonders was den kompletten Dateinamen angeht, weil auch ich diverse Images habe die sich vom Namen her erstmal nur an der Uhrzeit unterscheiden aber dennoch total verschieden sind.
 
Ich würde den Dateinamen da eigentlich nicht gerne sehen. Und ich erkläre warum an einem Beispiel, wie ich die Firmwares erstelle.
Ich erzeuge manchmal ganz viele Images mit demselben trunk, für dieselbe Box mit derselben Firmwareversion. Einige haben vsftp+curl und noch Tausende Sachen am Bord und werden teilweise externalisiert, andere sind dagegen strickt gehalten mit AVM-FTP und möglichst vielen patches (ohne mediaserver, ohne AVM-VPN). Alle diesen Images heißen in diesem Fall ähnlich, sodass man sie nur anhand des Zeitstempels kaum unterscheiden kann. Und jetzt rate mal, was ich anschließend mache? Ich benenne die Dateien um, damit die Namen mir mehr sagen (z.B. xyz_mitvsftp_datum.image). Diese Namensänderung können wir natürlich nicht abfangen. Somit kriegst du in der Infoanzeige nur den Namen angezeigt, mit dem dieses Image angelegt wurde.

Aus diesem Grund hatte ich da "Benutzerstring" eingeführt. Man kann diesen Benutzerstring beim Erstellen der Firmware im "menuconfig" konfigurieren. Und genau da rein kann man z.B. schreiben "schlankes Image mit AVM-FTP".

Man könnte ansonsten da in irgendeiner Form eine Kurzfassung von .config irgendwie noch mitschleppen. Z.B. die Information über die angewendeten Patches. Denn das sind solche versteckte Infos, die (neben external) nicht sofort zu sehen sind.

MfG
 
Ich beobachte dieses Vorhaben auch schon länger, und höffe, dass das irgendwann in den Trunk eingepflegt wird.
Über den Dateinamen kann man sich tatsächlich streiten, ich würde es jedoch trotzdem gerne im WebIF stehen haben. Man könnte es ja als "Ursprünglicher Firmware-Name" bezeichnen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.