XMOD - Fritzbox Mod

[lucky23_23]

Hallo,

ich hatte vor einiger Zeit begonnen einen kleinen Mod für meine Fritzbox zu schreiben um die Verwaltung etwas zu erleichtern.
Vorher hatte ich immer Freetz verwendet und war eigentlich auch sehr zufrieden damit. Allerdings hat mich daran immer gestört das man für jedes Paket das man installieren möchte, sich ein neues Image generieren lassen muss. Die Prolbematik dabei ist ja wahrscheinlich jedem bekannt....Speicherplatz reich nicht aus....Firmware zerschossen -> Recovery ...usw

Da ich an meiner 7170 sowieso nen USB-Stick dran hab, kam mir die Idee einfach alle Pakete auf diesen auszulagern und diese komfortabel per Webinterface zu konfigurieren. Dadurch ist es möglich Pakete einfach zu installieren und man hat keine Speicherplatz Sorgen mehr.


Installation:
1. XMOD-Paket auf den USB-Stick entpacken. Am besten per Dateifreigabe verbinden und extrahieren.

!! Der Stick muss mit FAT32 formatiert sein, da die Fritzbox von Haus aus nur FAT32 kennt. Solltet ihr allerdings bereits Freetz installiert haben, ist es auch möglich andere Dateiformate zu benutzen, je nachdem wie der Kernel konfiguriert wurde !!

2. Per Telnet auf Fritzbox einloggen.

3. In das XMOD-Verzeichnis wechseln
bei mir z.b. "cd /var/media/ftp/Intenso-Premium-00/xmod/"

4. Init Skript starten
"sh init.sh"

5. Sollte alles glatt gegangen sein, dann wurde der lighttpd-Daemon gestartet. Zu erreichen ist er standartmäßig unter Portnummer 82.
also z.b. "http://192.168.0.1:82/"

!! Es werden keine Veränderungen am System vorgenommen. Das heißt, wenn ein Fehler auftritt könnt ihr einfach neustarten und alles ist beim alten. Im Umkehrschluss bedeutet das jedoch auch, dass ihr bei jedem Stromausfall, Reboot usw. die init.sh erneut ausführen müsst. Umgehen könnt ihr das durch einen Eintrag in der debug.cfg !!


Anmeldedaten sind:
User: admin
Password: admin




System Status:




Paketverwaltung:




Paket Privoxy Status:




Paket Privoxy Configuration:




System Configuration:
Ein Feature ist es, das man schnell und einfach Parameter in den Systemdateien verändern kann. z.b. ar7.cfg , wlan.cfg , usb.cfg

Der Inhalt wird dann in einer Baumstruktur dargestellt.




Nachdem man die Änderung gemacht hat und auf Preview/Save Config geklickt hat, bekommt man nochmal die neu erstellte Config-Datei zu sehen. Zusätzlich wird per Diff-Befehl der unterschied zwischen den beiden Dateien angezeigt, damit man prüfen kann ob auch wirklich nur gewollte Veränderungen vorgenommen wurden. Erst nach klick auf "Save to Flash" werden die Systemdateien wirklich überschrieben. Bei mir ist bis jetzt noch nie ein Fehler aufgetreten. Trotzdem solltet/müsst ihr wissen, wie ihr im Ernstfall euere Box wiederherstellen könnt.

!! Ihr macht das auf eigene Gefahr. Ich übernehme für euer Handlungen keine Verantwortung. !!






Ein weiteres Feature ist die Curl-GUI. Ähnlich wie FritzLoad wird es verwendet um Datein hoch- bzw. runterzuladen. Durch verschiedene Profile ist es möglich von unterschiedlichen Quellen zu saugen. z.b. hatte ich mal ein Profil für Youtube, mit dem man die Videos downloaden konnte. Nachdem Redesign von Youtube ging das ganze natürlich nicht mehr und ich hab das dann auch nicht mehr angepasst.

Da die ganze Verwaltung per PHP läuft und kein eigener Prozess für die Steuerung der Transfers gestartet wird, muss ein Cronjob eingerichtet werden, wodurch der Taskmanager alle paar Minuten mal augerufen wird um zu sehen ob der Transfer fertig ist und ob ein neuer Transfer gestartet werden soll.

Das ganze ist für mich jedenfalls obsolet geworden, da die Fritzbox einfach zu schwach auf der Brust ist, und unter schlechten Bedingungen schon mit einem Transfer überfordert ist. Schuld daran ist vermutlich, das CURL doch einiges an Ressourcen benötigt. Aus diesem Grund verwende ich inzwischen einen kleinen stromsparenden Linux-Rechner im Netzwerk um mit JDownloader das ganze zu erledigen.

Downloads hinzufügen




Link decrypten und Status anzeigen





Transfer Status






Zum Herunterladen hier klicken (6MB)

 

[hermann72pb]

@lucky23_23: Ich bin schon bisschen länger hier, deswegen erlaube ich mir deine Idee etwas kritischer anzusehen.

Zunächst organisatorisch:
1. Warum erfindest du das Rad neu? Es gab schon einige vor dir, die es mit PHOENIX versucht hatten. Leider ist dieser Vogel gestorben und nicht aus der Asche auferstanden, wie sie erwartet haben.
2. Deine Idee alles auf dem Stick laufen zu lassen ist nicht neu. Man muss es sich nur genau überlegen WIE man es tut und WAS man dabei nicht von vorne an falsch machen sollte. Zur Technik komme ich aber später.
3. Da ich hier schon etwas länger bin, würde ich mal so ganz provokativ behaupten, dass dein Projekt nicht länger überleben wird, wenn du es alleine betreibst, anstatt in FREETZ zu integrieren. Das haben wir wiederum an PHOENIX gesehen. Alleine die Toolchain verwendest du mit Sicherheit von FREETZ und nicht etwa deine eigene. Auch in deinen Ideen erkenne ich z.B. meine Kleinigkeiten, die ich mal auch für FREETZ mitentwickelt hatte. Also, du lässt sich von FREETZ beeinflüßen und wenigstens inspirieren. Aus diesem Grunde schlage ich dir vor deine USB-Version möglichst schnell mit FREETZ zu "verheiraten". Das würde dir folgende Vorteile bringen:
a) Du wirst nur deinen Part verwalten und sich weniger um die Pakete / Toolchain / Busybox kümmern
b) Man könnte eine Art "FREETZ-on-Stick" schaffen, wo die ganzen Strukturen auf dem Stick laufen würden
c) Man könnte ein Mischkonstrukt vorstellen in dem ein Teil / Minimum der Pakete sich als Minimalimage auf die Box installieren lassen, Rest dennoch über USB frei konfigurierbar wäre. Im Unterschied zum External, was im Prinzip in die gleiche Richtung zielt, könnte man hier komplette Pakete auf USB auslagern und nicht nur Binaries.
d) Du wärest nicht auf dich alleine gestellt und würdest keine Konkurrenz zu FREETZ aufbauen
e) Glaub mir, es gibt mittlerweile so viele Boxvarianten und Firmwareunterschiede, dass du es alleine einfach nicht schaffst zu supporten.

Jetzt zur Technik:

1. FAT als Voraussetzung ist Scheiße. Man muss auf ext2 aufbauen. Man kann sich überlegen, WIE man einen Stick bei der Installation formatiert (und es gibt Möglichkeiten dazu !!!), aber man MUSS auf ext2 setzen, sonst machst du von Anfang an einen gravierenden Fehler. Ext2-Unterstützung wird übrigens mittlerweile wieder von AVM in die neuen Images aufgenommen, soweit ich weiß.
2. Wo hast du eine 2,2MB-Busybox her? Wie hast du es geschafft sie so auszublasen? Lass es bitte und baue auf unserer Busybox von FREETZ auf. Man kann sicherlich darüber reden, dass wir irgendwo unter FREETZ eine mehr oder weniger aktuelle Binary für alle Boxvarianten hinterlegen.
3. Du scheinst einen PHP-Freak zu sein. Hat es einen besonderen Grund, dass du PHP verwendest? PHP für die Box ist etwas oversized, selbst wenn du diesen light-httpd verwendest. Ich würde lieber auf httpd von busybox aufbauen und Skripts als Shell-CGIs realisieren. Daniel hat es damals so eingeführt, es hat sich gut bewehrt und so sollte man es auch vernünftigerweise machen.
4. Direkter Editor für cfg ist schön und gut. Was passiert bei dir hierbei im Hintergrund? Wird beim jeden "ok" vom jeweiligen Wert sofort in die Datei geschrieben? Beim Flash ist es nicht so besonders klug, obwohl einfach zu realisieren. Außerdem sollte dir klar sein, dass AVM vermehrt das direkte Editieren von den cfg-Dateien einem "Eingriff" über ctlmgr bevorzugt. Und was ist mit den gehashten Werten? Werden sie bei dir entschlüsselt?
5. 6 MB für alles ist auch etwas oversized. Ich hatte mir nicht genau angesehen, worauf sie sich verteilen, dennoch es ist eindeutig oversized.

Wie gesagt, beteilige dich bitte an FREETZ anstatt eine andere Baustelle hier aufzumachen. Das würde allen deutlich mehr nutzen.

Edit: Ich hatte diagonal durch die Quellen gelesen und finde da Bittorrent-Verweise in einigen Dateien, irgendeine FancyBox und was weiß ich nicht alles... Kannst du bitte deine Quellenliste hier veröffentlichen? Ich habe leider so einen Eindruck, dass du das alles zwar ziemlich mühsam, dennoch von unterschiedlichen Ecken aus dem Netz zusammengeworfen hast. Zwar sind es meist GPL-Sachen, dennoch verdienen sie wenigstens eine Erwähnung hier, wenn du darauf aufgebaut hast. Sonst entsteht bei manchen, wie bei mir z.B. den Eindruck, du hast alles von Null auf selbstständig aufgebaut. Kannst du uns bitte aufklären, wo die vorgefertigten Vorlagen enden und deine eigenen Sachen anfangen?

Edit2: Wenigstens die etwas ältere Curl-Version ist mit unserer FREETZ-Toolchain gebaut:

Tue Mar  3 13:11:31 CET 2009    compiler: %s    /home/cliff/Desktop/freetz-1.0.2/toolchain/target/bin/mipsel-linux-uclibc-gcc

codes.txt kommt mir auch irgendwie bekannt vor. Sind das Informationen aus IPPF-Wiki?

MfG

 

[lucky23_23]

hi,

auch ich verfolge das geschehen hier schon längere zeit. Ich bin mir durchaus bewusst das es nicht klug ist, das rad neu zu erfinden und die Community zu zersplitten. Das hatte ich auch nie beabsichtigt, als ich mit dem Projekt angefangen hab.

Will allerdings noch kurz stellung zu deinen Aussagen geben.

1. Natürlich hab ich mir den Phoenix mod angesehen. Aber soweit ich das erkennen kann, ist das mehr oder weniger eine linux distri für die mips cpu kompiliert. Knapp 300mb dafür das ich paar dienste starten kann, und das auf der Fritzbox? Da halte ich meinen Ansatz schon sinnvoller, indem ich nur die gewünschten Pakete in Ordnern verteil habe, inklusive der benötigten Libraries.
So ist z.b. das installieren/deinstallieren kein thema...


3. Muss schon gesagt werden das Freetz wirklich einen super job macht. Pakete anklicken, downloaden , kompilieren und fertig sin die binaries. Aber wie gesagt, dadurch das man ständig die firmware flashen muss um ein neues paket zu installieren, halte ich das prinzip für die größeren boxen mit usb anschluss für nicht optimal. Für die kleinen ohne USB ist es natürlich unumgänglichl.

Meine Vision war es, das man sich nur das gewünschte Paket als Zip-Datei herunterladen tut und es per Web Interface auf die Fritzbox hochladen/installieren kann. Wäre nix weiter als ein einfaches extrahieren in den richtigen ordner nötig. Auch das Backup/Restore der Einstellungen wäre kein Problem, da für jedes Paket eine XML-Datei mit den vorgenommenen Einestellungen erstellt wird. Dateien zusammensuchen, speichern, fertig.
Das Prinzip wird so ziemlich bei jedem Content Mangement System verwendet.


zur Technik
1. naja da kann man nix machen, wenn die box standartmäßig nur FAT32 kennt. Um das zu ändern, müsste man ja auch die Firmware wieder mit Freetz flashen, wobei der Gewinn gegen Null ginge. Aber wenn, wie du gesagt hast durch die neuen AVM Images ext2 unterstützt werden würde, hätte sich das auch erledigt. Am Rande bemerkt finde ich das verwenden von FAT32 auch nicht besonders tolle, ging aber eben nicht anders.

2. Ich bin nicht so der Profi im kompilieren von Programmen und deshalb hab ich einfach das genommen welches meinen Anforderungen genügte. Soweit ich mich noch erinnern kann, hab ich jenes gewählt, weil es start-stop-daemon und diff enthielt, andere eben nicht.

3. Da ich beruflich auch viel PHP programmiert habe, war es die Programmiersprache der Wahl. Für mich wäre es viel zu aufwendig ähnliches mit Shell skripten, cgi ... usw zu programmieren auch wenn es möglich wäre. An der Geschwindigkeit von Lighttpd und PHP kann ich jedenfalls nix aussetzen. Für das gebotene besitzt PHP eine angemessene Geschwindigkeit. Als Vorteil von PHP sehe ich z.b. den einfachen Umgang mit Datenbanken(SQLITE), leicht lesbarer syntax, vielzahl von Klassen vorhanden.

Einen Flaschenhals den ich entdeckt habe ist, das das aufrufen von shell programmen aus php heraus lange dauert. Ob das jetzt an der exec Implementierung von PHP liegt oder an den Programmen kann ich nicht beurteilen.

4. Den Befehl ctlmgr hab ich mir auch angesehen. Aber weißt du wie man damit werte setzen kann? Ich hab jedenfalls keine Möglichkeit gefunden.

Das Prinzip des ganzen ist, das die Cfg einglesen wird und in ein PHP-Array zwischengespeichert wird. Diese Temporäre Datei liegt dann normalerweise im /var/tmp - Verzeichnis. Dadurch kann sehr schnell darauf zugegriffen werden. Alle Änderungen die man macht, werden ausschließlich in der Temporären Datei durchgeführt. Beim Flashen wird das PHP-Array wieder zurück in den avmcfg syntax transformiert und schließlich damit die originale Cfg überschrieben.

Die gehashten Werte werden nicht entschlüsselt. Es wird der reine Inhalt der Cfg übernommen ohne etwas zu ändern.

5. Naja, man muss die Kirche auch mal im Dorf lassen. Entpackt hat das ganze 15 MB.
14 MB gehen an die Paket Binaries + Libraries
1,2 MB geht an den Htdocs ordner, wo sich der eigentliche Mod befindet. Davon werden wahrscheinlich 3/4 des Speichers von Icons, Images und Javascript-Komponenten verwendet.


Um eines klar zu stellen, das ganze Projekt war für mich mehr oder weniger ein Experiment um:
- die linux infrastruktur etwas besser kennenzulernen
- um zu sehen Performance der Box auszutesten
- spass am programmieren

Veröffentlicht hab ich das Projekt nur, weil ich denke das vielleicht jemand damit was anfangen kann und mal bisl feedback darüber zu erhalten ob der ansatz überhaupt sinnvoll ist bzw. was ihr darüber denkt.
Würde es natürlich sehr begrüßen wenn man teile davon im freetz weiterverwenden könnte.

 

[RalfFriedl]

Die Binaries stammen überwiegend von (Anfang) 2009, die Libraries sind zum Teil neuer. Meine Vermutung ist, daß sie nicht selbst erstellt sind, sondern von irgendwo zusammen gesammelt. lighttpd stammt von kontr-olli, rrdtool (eines der neueren Programme) ist mit Freetz erstellt. Die anderen Programme sind möglicherweise mit älteren Versionen von Freetz erstellt.

Die Busybox ist so groß weil sie, ebenso wie curl, statisch gelinkt ist.

Aufgrund des FAT-Systems gibt es keine Symlinks, sondern Dateien sind doppelt. libc.so.6 ist identisch mit libc.so.0 und allenfalls mit etwas Glück zu irgend etwas nützlich. Auch andere Libraries sind einfach nur so im Image, ohne daß sie von einem der Pakete verwendet werden.

PHP ist eine sinnvolle Programmiersprache für Web-Anwendungen im Allgemeinen, aber Freetz wird nicht auf PHP für das Web-Interface umsteigen, weil damit die Unterstützung der kleinen Boxen nicht mehr möglich wäre. Insgesamt sehe ich keine größeren Ansatzpunkte für eine Verbindung mit Freetz, und auch keine Konkurrenz zu Freetz.
Eher ist die Nähe zu PHOENIX da, wobei ich da nicht den Überblick habe, ob hier etwas vorhanden ist, was in PHOENIX nicht da ist.

Ein anderer Punkt, der eine gewisse Nähe zu PHOENIX zeigt ist dieser:

Das ganze ist für mich jedenfalls obsolet geworden, ...

 

[hermann72pb]

@Ralf: Die Idee an sich FREETZ so modular zu bauen, dass es selbst oder eben ein Teil seiner Pakete auch vom USB-Stick laufen kann finde ich nicht so ganz verkehrt. Zwar haben wir momentan in FREETZ sowohl USB-Root als auch External, beide Sachen waren jedoch für etwas andere gedacht und erfordern etwas mehr "Handarbeit", um sie zum Laufen zu bringen und nachher auch zu warten.
Ich hatte mir vor kurzem zwei kleine Linux-basierte Systeme angeschafft: QNAP-NAS und Xtreamer-Multimediabox. Beide basieren auf Linux, beide haben busybox für beide gibt es so eine Art FREETZ-Mod für Tüftler. Allerdings gibt es da einige Hauptunterschiede zu FREETZ:
1. Die beiden Mods werden nicht direkt ins Image intergriert, sondern auf dem sdx-Datenträger installiert (sei es USB-Stick, oder eben Festplatte, die NAS sowieso hat)
2. Beides beruht auf IPKG, was so eine apt-get-ähnliche Behandlung a-la Debian erlaubt. Dadurch kann man Pakete sozusagen on-the-fly ändern, ohne, dass man etwas auf dem Hauptsystem ändert (sprich Image neu flashen).
3. Man braucht zunächst mal keinen Cross-Compiler, was die erste Hürde für die möchtegern-Tüftler deutlich tiefer legt.

Man muss allerdings dazu sagen, dass beide Systeme an sich wahrscheinlich mehr "offen" sind als AVM-eigene. Z.B. kann man unter QNAP IPKG zunächst mal ganz offiziell als AddOn installieren und erst dann dadrinne alle IPKG-Pakete gesondert verwalten.

Es gibt auch gewisse Nachteile von der Methode, das muss man schon ehrlich sagen:
1. Beide Systeme fahren eine ziemlich alte Busybox. Sie sind da höchstens bei Version 1.3, obwohl man einige Geräte erst seit Sommer 2010 offiziell kaufen kann. Da fahren wir mit unserer busybox 1.17 ziemlich vorne.
2. Ich kenne mich mit IPKG nicht so besonders aus, es scheint aber so zu sein, dass da erst dann Pakete vorliegen, wenn jemand freundlicherweise sie durchkompilliert hat und auf IPKG-Server diese Version hochgeladen hat. Ich hatte z.B. keine CURL als Binary für QNAP gefunden und musste sie selbst kompilieren. Im Unterschied zur unseren Fritz!Box ging es aber erstaunlich gut auf dem System selbst (gcc, make und co waren als IPKG-Pakete vorhanden). Sonst sind aber die IPKG-Pakete veraltet und werden nur sparlich gepflegt. Da haben wir mit unserem FREETZ die Nase deutlich vorne.
3. Die ganzen rc-Skripte sind bei beiden Systemen eine pure Katastrophe. Ich hatte zwar unsere auch kritisiert, letzte Zeit hat cuma sie aber mehr oder weniger auf den Punkt gebracht und basierend auf modlibrc "stadardisiert". Sowas gibt es weder bei QNAP nocht bei Xtreamer.

Basierend auf diesen Erfahrungen kann ich nur sagen, dass man im Falle von FREETZ sehr wahrscheinlich nicht so einfach auf IPKG umsteigen kann. Wir haben eine große Anzahl der Box- und Kernelvarianten. Auf der anderen Seite sind einige Ideen, die in der ähnlichen Kleinlinux-Welt Ihre Verwendung finden nicht so ganz schlecht und können in FREETZ übernommen werden. In dem Zusammenhang mit dieser XMOD/PHOENIX-Geschichte könnte man folgendes lernen:
1. Es wäre nicht schlecht eine Art FREETZ-Lite zu generieren, die ohne Flash-Integration entweder im RAM oder auf einem Stick laufen würde. Dies würde die erste Hürde von FREETZ-Anfänger deutlich tiefer legen. Die Aufgabe von dieser Lite-Version wäre nicht nur um so eine Art DEMO-FREETZ darzubieten, sondern z.B. unsere tollen Update-/Diagnose-Sachen da rein zu integrieren.
2. Generell FREETZ und AVM-Basisinstallation etwas besser trennen und damit ermöglichen, dass FREETZ komplett auf einem USB-Stick laufen kann. Allerdings weder USB-Root (wo alles, inklusive AVM-binaries auf dem Stick liegt) noch External (wo eine unübersichtliche Mischung zwischen Flash/USB herrscht)
3. FREETZ-Pakete so gestalten, dass sie auch vom USB-Stick (oder einem anderen Medium) komplett laufen.
4. Dynamische Pakete endlich wieder "reaktivieren", sodass man Pakete on-the-fly Installieren/Deinstallieren kann.

MfG

 

[RalfFriedl]

@hermann72pb
Ich habe auch nicht die Idee als solche kritisiert, sondern Details der Ausführung. Mit anderen Worten, es gibt noch Potential für Verbesserungen.

Zm NAS-System (nebenbei, würdest Du dieses QNAP-NAS als gut, günstig und erweiterbar betrachten?):
1. Wie Du schon schreibst, hat ein NAS hat ein Festplatte angeschlossen, da braucht man sich nicht so viel Mühe zu geben, alles in einen kleinen Flash-Baustein zu bekommen. Da kann man auch einzelne Dateien ändern ohne deswegen ein komplettes Image aufzuspielen. Der Zugriff darauf ist (hoffentlich) schneller als auf den USB-Anschluß selbst der neueren Boxen, und da gibt es immer noch die kleinen Boxen, bei denen es gar keinen USB-Anschluß gibt.
2. Die Idee, auch für Freetz einen Paket-Manager zu verwenden, hatte ich auch schon mal. Sie stieß damals aber auf wenig Resonanz.
3. Auch hier schwirren genug Programme durch die Gegend, die man nicht selbst erstellen muß. Siehe die Binaries in diesem XMOD. Die meisten davon sind vermutlich mit den Freetz Werkzeugen erstellt.

Zu den Nachteilen: Es sind keine Nachteile der Methode.
1. Auch AVM verwendet eine alte Busybox. Wir ersetzen sie trotzdem durch eine neue. Siehe auch 2.
2. Auch Freetz unterstützt zunächst keine Programme, ob alt oder neu.
Es gibt erst dann Pakete für Freetz, wenn jemand freundlicherweise die entsprechenden Dateien erstellt hat und ins Freetz-SVN hochgeladen hat. Mit anderen Worten, Freetz mag aktueller sein, aber das liegt nicht an der Methode, sondern daran, daß sich jemand die Arbeit macht.
Es gibt übrigens inzwischen auch gcc und make für die Box. DEr Grund, warum die kaum verwendet werden, liegt an der Hardware der Boxen.
3. Auch gute rc-Skripte sind etwas, was jemand erstmal erstellen muß.

Früher zu Zeiten von ds-mod war es sogar so, daß vorkompilierte Binaries herunter geladen wurden. Mit der Vielzahl der verschiedenen Kombinationen wurde das aber etwas mühsam. Außerdem ist es mit der fertigen Toolchain in Freetz wirklich kein Problem, die Programme selbst zu erstellen.

Zu den weiteren Vorschlägen gilt das Gleiche, es muß sich nur jemand finden, der es auch macht. Speziell dynamische Pakete gibt es als Idee schon seit vielen Jahren.

 

[hermann72pb]

@Ralf:
a) QNAP ist schweineteuer, das ist richtig. Als ich mir eine richtige NAS anschaffen wollte, die keine Schwanhälse, wie z.B. unsere Pseudo-NAS der Fritz!Box hat, hatte ich das als eins der Hauptkriterien betrachtet. Zu dem damaligen Zeitpunkt (Ende 2009) hat aber mein Modell von QNAP am besten abgeschnitten, was die Übertragungsgeschwindigkeit im Netz betrifft. Der zweite Punkt war: Es muss linuxbasiert sein, damit ich sie selbst erweitern kann, wenn ich es will. Als Zusatzfeature gefällt mir an meinem QNAP noch der Stromverbrauch, der im iddle-Modus der Festplatte lediglich bei 7 Watt liegt. Und das sind keine imaginären Werte, es ist tatsächlich von mehreren User gemessen / bestätigt. Von daher bin ich mit meinem QNAP ziemlich zufrieden. Qualität hat ihren Preis. Bei unseren Boxen kann man es übrigens auch sagen.
Ähnliche Bewegungsgründe hatten mich zum Xtreamer bewegt, wobei sich hier die Aspekte etwas verschoben hatten und eine passive Kühlung z.B. eine übergeordnete Rolle spielte. Ich wollte Xtreamer nicht mehr als NAS missbrauchen, da ich eine NAS bereits hatte, von daher hatte ich es für gut befunden, dass mein Modell zunächst mal überhaupt keine Festplatte hatte.
Der Hauptbewegungsgrund bei der Anschaffung von diesen beiden Geräten bestand darin, dass ich zu einem eine Vernünftige Zenrallstelle zum Abspeichern von diversen Daten im Netwerk haben wollte, die schnell genug wäre auch Videos / Filme / TV Sendungen als .ts über Netzwerk ruckelfrei zu übertragen, zum anderen aber auch ein "Anzeigegerät" hätte, um die Inhalte auf dem Fernseher darzustellen.
b) Ich weiß, dass deine Kritik nur konstruktiv gemeint ist...
c) Zu dem Punkt, dass sich jemand finden muss: Da gebe ich dir Recht. Das ist das Hauptproblem. Ich habe selbst leider immer weniger Zeit und immer mehr Baustellen mit alten offenen Wunden, wie FREETZMOUNT, AVM-FTPD usw., die leider aufgrund letzter AVM-Aktivitäten einer dringenden Anpassung bedürfen. Selbst dafür finde ich kaum Zeit, geschweige etwas Neues aufzumachen. Deswegen war meine Meckerei hier auch nur dazu gedacht lucky23_23 dazu zu bewegen lieber etwas dem FREETZ beizutragen als eine neue Baustelle aufzumachen, deren Ausmaß ich mir nur schwer vorstellen kann. Es bleibt natürlich nur ihm selbst überlassen, ob und wie weit er es tut.

MfG

 

[RalfFriedl]

Es war auch kein Vorwurf, daß Du oder jemand anders zu wenig tut. Ich wollte nur darauf hinweisen, daß es nicht an einem Mangel an Ideen liegt, daß manche Dinge nicht umgesetzt werden.

Im Gegensatz zu Dir sehe ich auch weniger Berührungspunkte zwischen lucky23_23 und Freetz. lucky23_23 verwendet gerne PHP. Ich verwende auch gerne PHP, aber nicht für Freetz. Das Freetz Interface auf PHP umzustellen geht nicht, weil wir dann die kleinen Boxen nicht mehr unterstützen können, und ein zweites Interface parallel halte ich nicht für sinnvoll.

 

[linuxkasten]

Ja, es gibt eine Vielzahl verschiedener Konfigurationen. Das bedeutet aber nicht, dass eine Art Paketverwaltung sinnlos wäre. Es wäre nur recht aufwendig, die Pakete auf einem zentralen Server zu sammeln (wegen der genannten Vielzahl an Konfigurationen). Stattdessen könnte jeder die Pakete selbst erzeugen (auch nach dem Flashen). Dann hätte man immer noch den Vorteil, nicht jedesmal neu flashen zu müssen. Die bestehenden Paket-Makefiles können dabei weiterverwendet werden, nur müssen die fertigen Binaries dann noch irgendwie verpackt werden.
Den Paketmanager könnte man als normales Freetz-Package im menuconfig anbieten (auch nicht-Usb Boxen können ja z.B. per NFS über weiteren Speicher verfügen).

 

[RalfFriedl]

Das sehe ich auch so. Es ist das, was als dynamische Pakete schon seit Jahren als Idee vorhanden ist.

 

[lucky23_23]

Es natürlich schwierig einen Kompromiss zu finden.
Den auf der einen Seite werden die Boxen immer leistungsfähiger, auf der anderen Seite darf man auch die kleinen nicht vergessen, da die wohl einen großteil der benutzer ausmachen.

Ich sehe da durchaus einige zusammenhänge zum Freetz.
Ohne die Freetz Toolchain zum kompilieren der Programme ist das ganze natürlich nicht realisierbar. Das bedeutet das Freetz immer notwendig sein wird um Programme zu kompilieren und firmwares für die kleinen boxen zu erzeugen. Für die größeren boxen seh ich es aber als verschwendung an, wenn man nicht versucht sich das leben etwas einfacher zu machen. Durch eine moderneres System/Oberfläche könnte man sich viele neue Möglichkeiten vorstellen.

- einfaches CMS einrichten. Datenbanklayer ist bereits vorhanden. Habe den Layer von Joomla 1.0 von MySQL auf SQLITE umgeschrieben. Theoretisch könnte man damit auch direkt Joomla darauf laufen lassen. Denke jedoch das man mit der Geschwindigkeit keine freude haben wird.

- Adress/Telefonverwaltung. Adressdaten z.b. von Outlook importieren und mit den Anruflisten, Gebühren Informationen der Box verknüpfen. Das ganze auch auf Grundlage einer Datenbank, mit all den üblichen Vorteilen (Filterung, Sortierung, Geschwindigkeit...). Habe mir hierzu noch keine weitreichenden Gedanken gemacht. Sehe aber durchaus Potential.

- Erweiterungen leicht implementieren.
Wenn man sich mal ein umfangreiches Framework geschrieben hat, ist es in kürzester Zeit möglich, neue Funktionen zu implementieren.

Zum Beispiel hab ich eine Möglichkeit eingebaut HTML-Formulare automatisch erzeugen zu lassen. Alle Feldinformationen werden in einer seperaten xml-datei abgespeichert, wodurch sie sauber von der Logik getrennt sind. Dadurch ist es nicht nötig sich um die formatierung, eingabeprüfung usw... zu kümmern. Das ganze müsste natürlich noch etwas verfeinert werden, funktioniert allerdings bereits zufriedenstellend.


...

@ ralfRiedl
Das Zitat mit dem obsolet hast du aus dem zusammenhang gerissen. Ich bezog mich damit nur auf die CURL-GUI.

Ich warte jetzt einfach mal ab und schaue was noch für Resonanzen kommen. Eines ist klar, sollte sich niemand dafür interessieren, so werde ich das Projekt auch nicht fortführen, da es für mich komplett ist.

Hackt jetzt bitte nicht auf lauter kleinigkeiten rum, sondern seht es einfach als experiment um zu zeigen, das in der Fritzbox noch einiges an Potential steckt.

 

[hermann72pb]

@lucky23_23: PHP muss nicht sein, um die Vorlagen zu erstellen. Man kann auch mit cgi-s auf Shell-Basis hervorragend fahren. Da gebe ich Ralf Recht: PHP ist dafür oversized, auch für neuere Boxen. Schau dir einfach unsere FREETZ-WebIF-Struktur an: Sie ist simpel, basiert auch auf Vorlagen und nutzt mittleweile auch CSS, dafür "reden" die cgi-s direkt mit dem System und nicht über den PHP-Umweg.
Genau so sehe ich es mit den Datenbanken, selbst wenn sie "lite" sind. Klar ist es besser Datenbanken anstatt config-Dateien zu haben, die Frage dabei ist allerdings, ob auch SQLite dafür nicht oversized ist. AVM nutzt mitlerweile vermehrt datenbankähnliche Verwaltung. Sobald ich es mir aber vorstellen kann, ist es ziemlich simpel gestaltet und speziell auf Fritz!Box zugeschnitten.
Allgemein sollte es auch klar sein: Fritz!Box wird nie einen richtigen Web-Server ersetzen. Wenn du etwas Vernünftiges performant darstellen willst musst du zu einem externen Provider / eigenem WebServer wechseln. Da bekommst du Apache und MySQL und zwar nicht Lite, sondern im vollen Umfang. Fritz!Box ist eine Telefonanlage, die einige Nebenaufgaben zwar noch nebenbei erledigen kann, man muss jedoch nicht mit der Anzahl und Bedeutung von diesen Nebenaufgaben die Box in den Wahnsinn treiben.
Es macht Sinn PHP zum Programmieren zu nutzen, wenn du etwas Plattformunabhängiges programmieren willst. In diesem Fall versuchst du jedoch das falsche Werkzeug dafür zu nutzen, boxspezifische Sachen zu ändern.

Zu dem Resonance. Du kannst natürlich hier etwas mehr Werbung treiben und a-la PHOENIX die Luftblase so stark auspusten, dass du hier bei sehr vielen Skriptkiddies Interesse zu deinem Projekt erweckst. Du solltest allerdings berücksichtigen, dass du dir damit keine Freude machen wirst, denn du wirst uns von FREETZ die problematischsten möchtegern Tüftler abwerben. Wir werden dir dafür sogar dankbar sein. Du selbst wirst allerdings diese Kundschaft früher oder später bereuen. Denn sie ist meistens ziemlich jung, lernunfähig, faul und manchmal sogar einfach doof. Wenn du dir darüber einen Urteil selbst verschaffen willst, lese einfach Postings im PHOENIX-Thread durch und vergleiche sie mit den ähnlichen Sticky-Unterthreads unter FREETZ.

MfG

 

[lucky23_23]

ok, mit dem php geb ich euch recht. Es ist einfach Geschmackssache wieviel Ressourcen man für sein Webinterface ausgeben will. Ich bin eben PHP-Programmierer und sehe eben mehr die möglichkeiten und nehme es in Kauf das manches nicht ganz so schnell geht. Für den normalen Benutzer muss es nur funktionieren und schnell gehn.

Muss auch zugeben, das ich prinzipiell nix gegen ein cgi interface habe.

Aber bei einem sind wir uns wahrscheinlich einig.
Das der jetzige Weg zum hinzufügen von Programmen über die Firmware nicht immer der beste ist und es durchaus bessere Möglichkeiten gäbe.

 

[hermann72pb]

Das ja, sonst hätte ich diese Diskussion gar nicht gestartet... Deswegen sollten wir deine Idee vielleicht in zwei Unterthemen spalten:
1. So eine Art FREETZ-Lite / FREETZ-USB, welches separat auf einem externen medium / im RAM läuft und zunächst keine oder nur seltene Image-Updates erfordert. Man kann es noch weiter unterteilen:
a) Eine Installationroutine verschaffen (so eine Art FREETZ-Lite), die elementare FREETZ-Basics auf Stick / ins RAM packt, und das Starten von diesem FREETZ-Lite von dort ermöglicht
b) Paketverwaltung so anpassen, dass Pakete sich separat auf einem zu definierenden Medium installieren lassen
c) Eine Möglichkeit schaffen Pakete dynamisch "on-the-fly" zu installieren / nachzuinstallieren
2. PHP und Datenbanken. Eine etwas mächtigere Alternative zu FREETZ-WebIF, die auf PHP und SQLite basiert. Damit du hier bisschen mehr Resonance bekommst, würde ich an deiner Stelle überlegen es als FREETZ-Paket anzubieten. Klar, muss man dafür Abhängigkeiten in menuconfig einstellen, aber wenigstens theoretisch wäre sowas als FREETZ-Paket denkbar. Sobald es als Alternative zum Haupt-Web-IF bleibt, sehe ich da kein Problem. Wir hatten doch auch bereits Orange als AVM-WebIF-Alternative gehabt, warum dann nicht PHP-FREETZ-WEBIF? Wenn du auf dynamik und USB-Variante besonders stehst, kannst du im Paket von vorne an eine Variable dafür vorsehen, wo deine PHP-Sachen liegen. Dann kann der Benutzer entscheiden, ob er sie ins Flash packt oder eben auf USB.

MfG

 

[lucky23_23]

hab mir mal ein paar gedanken gemacht.

Man könnte ein Basispaket anbieten, das man auf dem Stick extrahiert, danach kurz ein Setupskript ausführt. Dadurch wird dann der Webserver hochgefahren und das Interface zur Verfügung stellt. Jetzt mal unabhängig ob mit PHP oder CGI oder sonstwas geschrieben.

Im Webinterface gibt es dann so eine Art von AppShop, wo alle verfügbaren Programme aufgelistet sind. Kurze Beschreibung, Dokumentationslinks evtl. kleinen Screenshot. Durch draufklicken wird das Paket runtergeladen und installiert. Dann gäbs 2 Möglichkeiten

1. Alles statisch zu linken. Hat den Vorteil das man alles in einem Ordner hat. Bräuchte es nur entpacken und wäre fertig.

2. dynamisch zu linken. Hier wirds schon schwieriger, da man eine Art Paketmanager bräuchte. Mit PHP würde ich es so machen, das ich in jedem Paket eine kleine XML-Datei reinlegen würde wo neben Informationen zum Paket (Author,Website...) auch die benötigten Libraries mit angegeben werden. Dann bräuchte man noch eine Routine zum Installieren und Deinstallieren die sich darum kümmert. Wäre glaubich kein großes Ding. Wie man das mit CGI machen würde, weis ich net.

Ich kann es leider auch nicht beurteilen, ob es nicht in einem Verwaltungschaos für die Pakete ausbrechen würde wegen den verschiedenen Kernelversionen und Konfigurationen. Wenn man das mit der Toolchain automatisieren könnte, das die pakete für alle Kernelversionen und den gängisten Konfigurationen gebaut werden würde, wäre das eigentlich auch kein thema. Im Webinterface werden nur die Pakete angezeigt, die zu der Kernelversion passen und man hat evtl. die möglichkeit sich eine konfiguration auszusuchen.


Auch wäre es cool eine Art Gesamtpaket anzubieten, indem alle Programme mit drin sind. Hat dann wohl einige MegaByte, aber Speicherplatz ist heutzutage vernachlässigbar. Gerade für Anfänger wäre das klasse.

Für die kleinen Boxen bleibt alles beim alten.

 

[hermann72pb]

@lucky23_23: Es gibt schon sowas und nennt sich IPKG und es gibt auch IPKG-WebIF (als Zusatzpaket). Zumindest habe ich es beim Xtreamer und QNAP gesehen. WebIF-Zusatz besteht mehr oder weniger aus zwei CGI-Dateien, die man in irgendein Web-Verzeichnis packen sollte, von dem sie per Web erreicht werden können. Zwar benutzt sowohl QNAP als auch Xtreamer lighthttp (oder wie immer das Ding richtig heißt, ich hasse diese künstliche Zusammensetzungen von Wörtern), man könnte aber durchaus auch mit dem busybox-eigenen httpd an der Stelle klar kommen.
Deswegen sollte man auch hier nicht das Rad neu erfinden, sondern sich eher Richtung IPKG bewegen. Daniel wollte dies mit seinem NG-Mod machen, aber das ist seit Jahren eingeschlafen. Von daher wäre er wahrscheinlich keinem Böse, der das übernehmen würde.
Was man allerdings bedenken sollte: auch IPKG bedeutet sehr viel Verwaltungsaufwand. Wahrscheinlich sogar viel mehr, als wir jetzt haben. Und ich weiß nicht, wer das stämmen sollte.
Damit wir Schritt-für-Schritt uns die Problemstellung betrachten, würde ich vorschlagen, dass man zunächst zwei von einer großen kompletten Umstellung auf IPKG unabhängige Sachen erledigt:
1. Basis-Paket auf Stick. So eine Art FREETZ-Lite. Man kann alleine damit sich schon lange beschäftigen.
2. Jemand macht sich Mühe IPKG und IPKG-WebIF erstmal für FREETZ zu kompilieren und vielleich als FREETZ-Paket zu intergireren. Zunächst ist das Ding komplett leer und ist nur für sich da. Danach nimmt man sich 2-3 Pakete zur Probe, die eher allgemeiner Natur sind und nicht so tief in die Fritz!Box-eigene Umsetzung greifen (z.B. Curl, MC, etc.) und testet an, ob und wieviel Aufwand es bedeutet diese 2-3 Testpakete für alle Boxen anzubieten.

Parallel wäre es eine Überlegung Wert allgemein in FREETZ eine etwas ausführliche /mod/etc/packages (oder wo wir sie auch immer platzieren und wie wir sie auch immer nennen) einführen. In dieser Datei wird dann genau definiert, wo ein Paket sein "Zuhause" hat. Stratlevels könnte man dort z.B. auch behandeln. Die Datei kann z.B. wie folgt aussehen:

openvpn   40    /var/media/ftp/uStor01/freetz
mc        40    /
vsftpd    40    /var/media/ftp/uStor01/freetz

usw.

MfG