Downloader-Paket für ds-mod

[size=+2]D[/size][size=-2]ie Firmwares für unsere Fritz!Boxen werden immer größer und die ds-mod Pakete immer umfangreicher, sodass es irgendwann mal nicht mehr in den Flashspeicher der Box passt. Außerdem wollen viele jenes oder anderes Programm erstmal im RAM-Speicher der Box ausgiebig testen. In beiden Fällen kommt man oft auf die Idee die Binaries von einem privaten oder gemeinsamen Server im Web auf seine Box zu runterladen. Bis jetzt hat man es überwiegend mit debug.cfg gemacht. Nun will ich diesen Teil der Handarbeit einem oder anderem hier im Forum abnehmen und etwas bequemer machen.
[/size]
Der hier anzubietende Downloader macht nichts anderes, als man in den alten guten Zeiten (viele haben es sicherlich noch in Erinnerung) mit debug.cfg gemacht hat: Datei xy vom Server holen, ins RAM der Box packen und Dateiattribute setzen. Einige Besonderheiten des Downloaders:
- HTTP oder FTP Server kann benutzt werden. Beim FTP-Server benötigt man Benutzer- und Passwort-Daten
- Vor dem Download wird der Server angepingt. Im Unterschied zur üblichen unendlichen Schleife, können hier die Anzahl der pings und die Pausen dazwischen bestimmt werden.
- Es können mehrere Dateien nacheinander heruntergeladen werden.
- Dateien müssen gezippt werden und als dateiname.gz auf dem Server vorliegen (Danke an gnieder für diese Idee)
- Auf der Box sollen Dateien ins RAM gepackt werden (alles was unter /mod oder /var/tmp liegt). Achtung! Keine Idiotenprüfung hier!
- Den Dateien sollen Attribute (z.B. 755) verpasst werden.

02.01.2008 Version 0.2 ist nun fertig. Näheres in CHANGELOG (im Archiv drin) oder in den Screenshots (ein Bild sagt mehr als Tausend Worte). Da Downloader schon im Mod verankert ist, muss nicht viel mehr getan werden: Hauptarchiv in "dl" unausgepackt hinlegen und make-Archiv im Modhauptverzeichnis entpacken (danach weiß der Mod, dass es die Version 0.2 gibt). Ansonsten hoffe ich, dass es in 15.3 einfließt.

Nachtrag 16.07.2007 Seit ds-mod 26-15.1 ist Downloader der Bestandteil des Mods und kann über make menuconfig unter Webpaketen ausgewählt werden. Deswegen ist Kleingedrucktes nicht mehr so relevant.

[size=-2]Kriegaex hatte mir empfohlen das Package erstmal als Addon zum Testen zu veröffentlichen. Das ist die einfachste Möglichket den Downloader zu testen. Dafür die angehängte Datei addon.tar.bz2 ins Addon entpaken:

Code:

[b]Linux:[/b] linux@linux:~/ds26-14.4$ [b]tar -xvjf addon.tar.bz2[/b]
[b]FriBoli:[/b] bofh@bofh-debian:~/ds26-14.4$ [b]unp addon.tar.bz2[/b]

und einmal make durchlaufen lassen. make precompiled ist für dieses Package nicht erforderlich.
Die Addon-Version kann leider nicht ohne Weiteres zum Nachladen der "ausgeschnittenen" binaries und libraries benutzt werden, wie in [1] diskutiert wurde. Dafür ist noch etwas "Handarbeit" erforderlich. Zu einem müssen die Binaries aus dem Image entfernt werden. Zum anderen muss der Downloader vor den anderen Paketen gestartet werden, was als addon erstmal nicht möglich ist.

Nachtrag 02.05.2007 für ds-mod 26-14 Für experimentierfreudige biete ich hier alternativ eine erweiterte Möglichkeit den Downloader in ds-mod 26-14.4 nachträglich "quasifest" zu integrieren. Dafür soll die Datei make-downloader.tar.bz2 ins Verzeichnis make von ds-mod entpackt werden:

Code:

[b]Linux:[/b] linux@linux:~/ds26-14.4$ [b]tar -xvjf make-downloader.tar.bz2[/b]
[b]FriBoli:[/b] bofh@bofh-debian:~/ds26-14.4$ [b]unp make-downloader.tar.bz2[/b]

Achtung! Dabei wird die Originaldatei Config.in im make-Verzeichnis gnadenlos überschrieben. Die veränderte Datei basiert auf Config.in für ds26-14.4. In allen anderen Fällen ist eine vorherige Sicherung von Config.in erforderlich. Dann sollte Downloader der Datei Config.in manuell hinzugefügt werden. In etwa an der Stelle:

Code:

[size=-2]Config.in[/size]
...
menu "Testing"
# Included by jamvm for a cleaner menu structure
# source make/classpath/Config.in
source make/debootstrap/Config.in
[b][color=red]source make/downloader/Config.in[/color][/b]
source make/fuse/Config.in
...

Der Vorteil dieser Methode besteht darin, dass man den Downloader nun nach make menuconfig unter den Testpaketen auswählen kann und dass er jetzt vor den meisten ds-mod-Paketen startet.
Die Startreihenfolge ist in der Datei make/downloader/downloader.mk auf "S30" festgelegt und kann nach Bedarf vor dem make angepasst werden.
Damit make erfolgreich durchlaufen kann sollte man die Datei downloader-0.1-dsmod.tar.bz2 (im Anhang) ins dl-Verzeichnis legen.
[/size]
In [2] ist beschreiben, wie man Schritt-für-Schritt vorgehen sollte, um die Binaries und Bibliotheken z.B. für eine 7050 auf den Server auszulagern. Das Ganze kann auch mit einem Vorbereitungsskript Outsourcer automatisiert werden. Outsourcer ist kein Paket und zur Zeit ( 01.07.2008 ) noch nicht im Freetz erhalten.

Etwas zur Stabilität der Box. Es ist nicht ratsam viele Pakete auszulagern und sie nachher ins RAM der Box runterzuladen. Bei bestimmten Voraussetzungen kann es zu Instabilitäten und regelmäßigen Rebooten der Box kommen. Wenn man die Sache jedoch nicht übertreibt, und nur 2-3 Pakete auslagert, sollte sowas eigentlich nicht vorkommen.

Da es einige Probleme mit syslogd gegeben hat, verweise ich auf [3], wo das Problem diskutiert und gelöst wird.

Ein paar Postings tiefer gibt es erfolgreiche Konfigurationen für Downloader.

Danksagungen: Vielen Dank an gnieder für Bereitstellung seiner privaten addons, an kriegaex, olistudent und danisahne für Support.

Viel Spass beim Testen!
Rückmeldungen und Verbesserungsvorschläge sind willkommen.

Auf einem normalen weg erstmal nicht. Ich hatte es mehr als Paket gebaut mit dem richtigen rc.downloader. Den muss man dann "umbiegen", wenn nicht überhaupt komplett weg nehmen and {start}-Abschnitt in debug.cfg kopieren. Dann verliert man jedoch die Möglichkeit, per Knopfdruck (start des Dienstes) das Downloaden während des Betriebes zu Initialisieren (vielleicht will das jemand). Außerdem die Variante mit debug.cfg ist nicht so gut, weil zu dem Zeitpunkt ds-mod noch gar nicht "hoch" ist. Gerade deswegen hatte ich die unendliche while-Schleife durch quasi-for-Schleife ersetzt. Mit debug.cfg würde man gar nicht auf ds-mod Interface zugreifen können, während downloader aktiv ist. Wenn man dabei Wartezeit und Wiederholversuche zu hoch treibt, dann kann es schon lange dauern, wenn der Server down ist, oder Fehlerangaben in den Parametern sind.

MfG

zu 2.
Mit Überschreiben existierender Datei ist so eine Sache. Vielleicht will man das ja bewust machen. Wenn schon, dann führe ich dort noch ein Hacken auf der CGI mit "Datei überschreiben" und setze es per default auf "no".
Markierung könnte man auch machen, vielleicht sogar zusätzlich.
Übrigens andere Frage, die hier vielleicht etwas OT ist, aber zu deinen Vorschlägen mit debug.cfg gut passt. Warum ist noch keiner auf die Idee gekommen, für debug.cfg eine Eingabemaske in ds-mod zu machen? Man kann doch zunächst debug.cfg per cat auslesen und anschliesend genau so abspeichern.

MfG

das bringt nichts. Die Reihenfolge wird in static.pkg festgelegt. Diese static.pkg wird während des make-Vorgangs gebaut. Ich habe bereits makefiles für downloader, wenn man es in mod als static-Package integrieren würde. In diesem make-config-file legt man die Startreihenfolge fest. Ich habe z.B. S30 dort festgelegt. add-on Pakete sehen meineswissens dagegen kein make vor. Wenn die Datei static.pkg während des make gebaut wird, werden zunächst darein "feste" Pakete nach ihrer Reihenfolge SXX reingeschrieben. Danach werden add-on Pakete abgearbeitet. D.h. add-on Pakete stehen immer hinter den "festen" Paketen. Du kannst downloader in static.pkg an die passende Stelle aufnehmen und dann das Image neu aufbauen (make mit Optionen). Oder eben rc-script in debug.cfg aufnehmen.

Aber generell zu diesem RAM-Ersatz für fehlenden Flash-Platz. Es ist doch nicht so triviall. Box bleibt ab und zu hängen. Ich versuche den Übeltäter zu finden und die Anzahl der ausgelagerten Pakete zu reduzieren. Vielleicht wird es stabiler. Komischerweise hat es am ersten Tag die 24 Stunden (wenn sogar nicht 36) komplett durchgehalten. Und je weiter es geht, desto weniger Zeit braucht die Box, um sich aufzuhängen.
Aber du kennst das selber, gnieder. Du lässt doch auch deine Boxen alle 24 Stunden neu starten.

MfG

und wenn du es nicht nur als addon ausprobieren willst mit allen oben beschriebenen Einschränkungen, kann ich noch make-files posten. Dann kannst du die Startreihenfolge besser definieren.

MfG

@ao: Nimm dir als Beispiel die configdatei von gnieder von dort:
http://www.ip-phone-forum.de/showpost.php?p=840604&postcount=14

ao schrieb:

("image size 228xxx bytes too big")

Zum Vergrößern anklicken....

Aber 230kB zu groß ist echt zu viel. Irgendwas machst du falsch. Hier wird dir sogar die kleinere libgcc_s.so aus dem Mod nicht helfen. Vergleich einfach deine config und die von gnieder und diskutiere es bitte im oben genannten Thread.
Zu dem Downloader musst du natürlich berücksichtigen, dass die Idee daran besteht die "dicken" binaries und libs zu ersetzen. Was auf jeden Fall ins Flash muss sind die ganzen cgi-s und alles drum und dran. Das braucht zwar nicht viel Platz, aber trotzdem frisst einige Kilobytes. Deswegen mach dir bitte nicht die falschen Hoffnungen, alles auf die Box zu kriegen. Wie ich schon hier mehrmals gesagt hatte: 2-3 Pakete "ja", aber nicht mehr.

MfG

Was kann man auslagern

Damit man nicht solange überlegt, was man den auslagern kann, damit "Image too big" endlich nicht im Wege steht, poste ich hier zwei Beispiele für meinen downloader, die ich getestet hatte. Wichtige Bemerkung: Erste Konfiguration funktioniert bei mir zuverlässig nur mit dem abgeschalteten syslog. Sonst hängt die Box nach einigen Stunden.

Configuration 1:
AVM Firmware: 14.04.31; ds-mod: 0.2.9_26-14
fest integrierte Pakete: callmonitor, downloader, syslog, virtualip, wol
nachladbare Pakete: dnsmasq, dropbear, openvpn, mc
Downloader config:
Probleme mit dieser Konfiguration: DHCP funktioniert nicht ganz richtig, weil dnsmasq doch lieber fest integriert sein sollte.

Configuration 2 (26.05.2007):
AVM Firmware: 14.04.33; ds-mod: 0.2.9_26-14
fest integrierte Pakete: callmonitor, downloader, dnsmasq, syslog, virtualip, wol
nachladbare Pakete: dropbear, openvpn, mc
Downloader config:
Bei dieser Konfiguration hatte ich rausgefunden, dass die MC-Hilfe doch einiges am Platz kostet und habe sie ausgelagert. Ob es alleine ausgereicht hat, oder ob 33-Firmware etwas kleiner ist (was ich vermute), so oder so hatte ich doch auf der Box Platz für dnsmasq und liblzo2.so.2.0.0 gefunden. Image kommt dabei wirklich knapp an die Grenze (3kB fehlen nur). Diese Konfiguration habe ich gebaut und am 18.05.07 geflasht. Eine feste Integration von dnsmasq hat tatsächlich das Problem mit DHCP gelöst.

Configuration 3 (15.07.2007):
AVM Firmware: 14.04.33; ds-mod: 0.2.9_26-15.1
httpd als websrv Ersatz und das Löschen von iggd bringen die fehlenden kBytes für dropbear im Flash. Dafür fliegt liblzo2 wieder raus. mc-Hilfe fliegt per menuconfig-Austrag komplett raus.
fest integrierte Pakete: dropbear, callmonitor, downloader, dnsmasq, syslog, virtualip, wol
nachladbare Pakete: openvpn, mc
Downloader config:

MfG

Ausprobiert habe ich es nicht, aber gehen sollte es theoretisch auch mit dem USB-Stick anstatt RAM. Wenn man den Stick vorher erfolgreich gemounted hat und wenn man das Verzeichnis auf dem Stick als Ziel für downloader angibt. Es könnte allerdings bei der Zuweisung von Rechten scheitern.
Sonst hat morph027 eigentlich Recht. Dafür war es nicht gedacht.

MfG