Freetz-Trunk: Optimierungen des Webinterfaces

Die Logik passiert im webcm. Der ctlmgr stellt nur den Server. Man kann ohne Probleme ein AVM-Webinterface über den busybox httpd ansprechen. Aber da es kein Binary mehr gibt kann man nichts mehr entfernen. Somit hatte der Patch keinen Sinn mehr.

MfG Oliver
 
Und wenn ctlmgr und httpd port 80 belegen? Crash? Ist aber sowieso egal.
 
Ich denke nicht. Wer zuerst kommt malt zuerst.

MfG Oliver
 
Das hatten wir bereits ausprobiert gehabt. Wenigstens hat es funktioniert, httpd auf 83 parallel zu ctlmgr (der auf 80 lief) laufen zu lassen und AVM-Seiten darstellen. Dann hatte jemand erfolgreich versucht dem ctlmgr Port 80 zu klauen und httpd darauf zu binden. Es hat auch (wenigstens temporär) geklappt. Allerdings waren es reine Experimente, keiner wollte es dann so wirklich umsetzen, weil wir keinen Nutzen davon gesehen hatten. Soll heißen: Funktionieren würde es schon, wir würden davon aber keine Gewinne im Platz oder sonst wo sehen.

@Gero013: Wer hat denn seine Quellen von dir versteckt? War das hier in IPPF und unter FREETZ? Ich kann es mir kaum vorstellen. Hier wird es sogar ausdrücklich erwünscht, dass du dir mehrere Pakete detailiert anschaust und möglichst genau so bei dir umsetzt. Wir haben mittlerweile sehr viele Schablone / integrierte Funktionen etc. und es ist aus wartungstechnischen Gründen besser, wenn alle Pakete sich daran halten und kein Rad selbst erfinden.

MfG
 
Die Logik passiert im webcm. Der ctlmgr stellt nur den Server.
Ja, das würde ich unterschreiben :)

webcm - wäre der Content-Manager und wenn ich php bei apache als CGI-Anwendung laufen lasse, könnten die Kwältexte ähnlich wie bei AVM aussehen. webcm sorgt für die Zusammenstellung der Seiten und für das Ersetzen der Variablen - also das, was ein PHP auch machen würde.

Die CGI-Anwendung erstellt aber nur die Webseite, übermittelt sie aber nicht zum Client. Das macht der Webserver, bzw. hier eben der Control-Manager.

Wenn ich es richtig verstehe, hat der Control-Manager die Datagram-Sockets (die ctl-Dateien in /var/tmp) angelegt, bzw. hält sie offen. Vielleicht dienen die ja als Kanäle um HW-triggers verarbeiten zu können ...

Es hat jedoch noch keiner versucht webcm zu ersetzen.
Hm, ich wage zu bezweifeln, dass man die Funktionalität nachbilden kann, ohne mehr Platz zu verbrauchen. Schätze, mache Informationen wird es ohne webcm schlicht nicht geben.

Ich würde es schon als Erfolg ansehen, wenn man den JS-Wust reduzieren könnte, die Seiten skinnable gestalten würde (klar mit CSS) und eigene Seiten vom ctlmgr übermitteln könnte. Mal sehen.
Jetzt, da ich die Seiten von Adam und Eva gelesen und ausprobiert habe, bin ich auch wieder entspannter im Hinblick auf neue Experimente ;)

@Gero013: Wer hat denn seine Quellen von dir versteckt?
Nein, es war nicht hier. Es war ein recht prominenter Ersteller von Debian-Paketen ;)
Ich fand seine Arbeit so gut, dass ich ein "Howto" in einem ganz anderen Forum schrieb. Mein Geschreibsel hat vielleicht 2-3 Wochen überlebt, dann schlug die Realität wieder zu.


Hier wird es sogar ausdrücklich erwünscht, dass du dir mehrere Pakete detailiert anschaust und möglichst genau so bei dir umsetzt.
Yo - das ist auch *imho* das einzige, was im Umfeld von Opensource Sinn macht.
Aber manche sind eben so ehrenkäsig, dass sie ihre Pakete nur verwendet sehen wollen, nicht jedoch als Lehr-Beispiel für ähnliche Projekte.
Insofern wundert mich heute überhaupt nix mehr. Wenn jemand meint, sich ärgern zu müssen - bitte sehr.

Gruß Geronimo
 
Zuletzt bearbeitet:
@Gero013: Wir hatten dich genug gewarnt sich an AVM-WebIF dran zu trauen. Spätestens, wenn AVM bei der nächsten Firmware was ändert, bist du wieder in der Bringschuld hier was auszuliefern. Sonst stirbt dein Projekt, wie bereits Orange-Dingens bei ds-mod gestorben war. Ich glaube nicht, dass der Author von Orange-WebIF weniger Motivation hatte. Nur irgendwann war es ihm zu viel und er hat damit aufgehört.
Investiere bitte deine Kraft in andere mehr wichtigere Dinge und lass AVM-WebIF so zu sein wie es ist. Wenn du schon gerne für einige AVM-Funktionen einen eigenen WebFronted machen willst, fange bitte ganz klein und vor allem komplett von Null an. Z.B. könntest du dir das Telefonbuch oder die Anrufbeantworter vornehmen und dafür ein eigenes WebIF losgelöst von den Einstellungen entwickeln. Sozusagen ein Hausfrauen-WebIF, wo man nichts verstellen kann, dafür aber Anrufe anschauen kann, AB abfragen kann, etc. Oder etwas ähnliches in der Art. Aber nutze dafür bitte weder ctlmgr noch webcm, sondern versuche die Datenbanken/Dateien direkt anzusprechen und sie per httpd auszugeben.
Wäre das was für dich?

MfG
 
Investiere bitte deine Kraft in andere mehr wichtigere Dinge und lass AVM-WebIF so zu sein wie es ist.
Hm, habbich mich wohl wieder mal schleckt ausgekwetscht. Ich hatte nicht vor, das Original zu ändern.

Wenn du schon gerne für einige AVM-Funktionen einen eigenen WebFronted machen willst, ...
Nöö, das hatte ich auch nicht vor. Anders herum wird ein Schuh daraus.
Wenn überhaupt, würde ich eher Freetz-Seiten ins AVM-WebIF portieren.

Z.B. könntest du dir das Telefonbuch oder die Anrufbeantworter vornehmen und dafür ein eigenes WebIF losgelöst von den Einstellungen entwickeln. Sozusagen ein Hausfrauen-WebIF, wo man nichts verstellen kann, dafür aber Anrufe anschauen kann, AB abfragen kann, etc. Oder etwas ähnliches in der Art. Aber nutze dafür bitte weder ctlmgr noch webcm, sondern versuche die Datenbanken/Dateien direkt anzusprechen und sie per httpd auszugeben.
Wäre das was für dich?
Definitiv nicht.

Habe mir heute nochmal das Copyright in aller Ruhe durchgelesen - und daraufhin meine Grafik wieder entfernt. Ich habe nicht vor, Grund für Animositäten mit AVM zu sein.
Ganz im Gegenteil - ich würde gerne so arbeiten, dass es auch das OK der Orignal-Macher erlangt.

Das heißt aber für mich, dass ich die Finger von closed-Source-Quellen lasse, für die es bereits ein funktionierendes Interface gibt.
Ich hatte schon angefangen, das Format von htmltext.db zu ermitteln, aber vermutlich fällt das auch unter disassemblieren, auch wenn ich es mit try+error versucht habe.
Da im Copyright steht, dass man nichts verändern darf, werde ich meine Experimente auf die Ecken beschränken, an denen es noch kein Web-IF gibt und wozu ich keine closed-Source-Quellen untersuchen muss.
Themen, die mich an der Ecke interessieren sind einmal die Konfiguration des Switch (das schaff ich nicht alleine, würde mich also über Unterstützung von Firewall-Profis freuen) und zum anderen die Anzeige von Logdateien. Vielleicht probier ich mich auch noch an logrotate - mal sehen.

Ich weiß nicht, wie weit ich komme, aber das ist für mich erstmal der Weg, der für mich sowohl vom Weg, als auch vom Ziel her akzeptabel ist und den ich für vereinbar mit dem Copyright halte. Ob ich was hinbekomme und ob das dann auch für die Community von Wert ist - muss sich zeigen.

Gruß Geronimo

//Träumermodus on
Das genialste *imho* wäre, wenn ich es schaffe, Seiten zu erstellen, die den Weg in die offizielle FW finden und es dadurch vielleicht schaffe, dass AVM ein Interface/Tuhl für htmltext.db veröffentlicht :)
//Träumermodus off
 
Sorry, wenn ich mich einmische, aber inzwischen wird ja das ganze FritzLoad-Projekt (welches ausschließlich aus cgi-Skripten besteht) von dem internen AVM-Webserver auf Port 80 aufgrund ein paar "mount -o bind"-Befehle gewuppt, was u.a. den hübschen Nebeneffekt hat, dass FritzLoad komplett über die Standard-AVM-Fernwartung per https zu erreichen ist.

Ist das keine Alternative für das Freetz-WebIF?
 
Das sollte nicht die Schwierigkeit sein, auch Haralds TSB läuft schon seit Jahren fast problemlos auf AVM's Webinterface.

BTW: Generell wär ich auch dafür, alles über Port 80 anzubieten. Wenn jemand jetzt spontan eine Idee hat, wie man php-Seiten und die Autorisierung des freetz-WebIF in den ctlmgr einbinden kann, stände dem grundsätzlich wohl nichts im Wege.
 
Da das Freetz Interface kein PHP verwendet, und auch nicht verwenden wird wegen des Platzbedarfs von PHP, ist diese Frage nicht so wichtig.
Für die Autorisierung könnte man versuchen, an den Anmelde-Status von AVM dran zu kommen, oder eine eigene Session Verwaltung einzubauen.
Wenn man sich wirklich diese Arbeit machen will, und die Versionen auf den verschiedenen Boxen nicht zu unterschiedlich sind.
 
PHPXmail nutzt PHP und ist momentan in das Freetz-WebIF integriert. Prinzipiell wäre aber eine PHP-Integartion nicht schlecht, um auch PHP-Anwendungen über https/external zu administrieren - evtl über ein Wrapper-Script á la webcm.
 
Und viel viel grösser werden dann die Images? ;) Ich denke simpel zu gross. Vor allem auf den Boxen, die keine 16MB Flash haben, und dann am besten noch ohne USB-Stick
 
Reden wir gerade aneinander vorbei? Ich meine natürlich PHP optional, so wie es jetzt auch über den httpd gelöst ist. Nur eine optionale Integration in den ctlmgr wäre auch nicht schlecht ;-).
 
Ja, dann redeten wir aneinander vorbei ;)
 
PHPXmail nutzt PHP ...

Ich spreche nicht davon, daß wir kein PHP auf der Box hätten, sondern daß wir es nicht aus Voraussetzung für das Web-Interface verpflichtend auf jede Box packen wollen/können.
Und wenn wir schon ein Web-Interface ohne PHP brauchen, wäre es doppelte Arbeit, zusätzlich ein Web-Interface in PHP zu erstellen.
Weiterhin haben wir auch schon (mehrere) Web-Server, mit denen PHP funktioniert. Warum sollte man dann noch versuchen, PHP in den ctlmgr zu integrieren? Zumal es möglich ist, daß AVM in der nächsten Firmware etwas grundlegendes ändert und es dann wieder nicht mehr funktioniert. Ein Argument wäre noch der eingesparte Speicherplatz, aber wenn man schon PHP verwendet, hat man vermutlich genug Platz auf einem externen Datenträger.
 
Ich bin grundsätzlich ein Gegner von mehreren parallel laufenden Webservern, wenn man es auch mit einem machen könnte. Hauptsächlich aber ging es mir um die Erreichbarkeit von Aussen über den ssl-Standardport des ctlmgr.

Und von Voraussetzung und Verpflichtung war hier keine Rede, es geht immernoch um eine optionale Integration von PHP für entsprechend benötigte Programme/Pakete.
 
Eie Erreichbarkeit von Außen erreichst Du schon durch den Aufruf der vorhandenen CGI-Skripte, ohne alles in PHP doppelt machen zu müssen.
 
Jetzt steh ich auf'm Schlauch, wie du das meinen könntest :confused: ...
 
Wenn es Dir auf den Zugriff von Außen ankommt, muß Du deswegen nicht alles in PHP neu machen. Es reicht, die vorhandenen CGI-Skripte vom AVM Webserver aufrufen zu lassen.
 
Das Prinzip ist mir klar, aber mir geht es hier nicht um die Freetz-CGI-Skripte, sondern um PHP, dafür gibt es (soweit ich weiss) noch keine CGI-Wrapper-Scripte.
Ich verstehe immer noch nicht was du mit "doppelt machen" meinst. Ich spreche nicht davon, alle Freetz-CGI's nach PHP zu portieren, davon war nie eine Rede. Ich möchte vorhandene PHP-Skripte (z.B. PHPXMail) über den ctlmgr ansprechen können. Mehr nicht.
 
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.