Ideen zum Nachladen für 7050

Da die letzte Diskussion über 7050
http://www.ip-phone-forum.de/showthread.php?t=132936
sich mehr in Richtung NFS und Erfahrungsaustausch entwickelt hat, mache ich hier ein neues Thema auf, wo die Ideen diskutiert werden sollen, wie man die großen Binaries vom externen Webinterface / FTP-Server runterladen und anschließend im ds-mod nutzen kann. Die Web-CGIs von gewünschten Paketen samt Konfigurationen sollen von Originalpaketen benutzt werden.

Einige Vorkenntnisse:
1. Wie man die Binaries aus der Image bei "image too big" löscht und das Image nachher ohne die Binaries aufbaut wird aus dem Posting
http://www.ip-phone-forum.de/showpost.php?p=837267&postcount=3
klar.
2. debug.cfg alleine reicht zum Nachladen der Binaries nicht aus, weil sie zu spät aufgerufen wird. Es wird ein addon-Paket benötigt, welches die Binaries aus dem Web holt, bevor die Dienste mit nachladbaren Dateien gestartet werden.

Ideen:
1. Aus der Image alle zu großen Binaries rauslöschen
2. Auf der Box unter tmp ein Verzeichnis erstellen und Patch-Variable wie folgt modifizieren:
Diese Operation kann das Nachlade-Skript übernehmen.
3. Mit dem Nachladeskript (wird irgendwo in rc.S aufgerufen) fehlende Binaries nach /var/tmp/bin nachladen.
4. Nun kann die Box die fehlenden Binaries in diesem Verzeichnis finden und von dort anstatt /sbin oder /bin (u.a.) starten.

Ist es grundsätzlich möglich?

MfG

Hermann

Ist denn zu diesem Zeitpunkt dsld schon gestartet und gibt es Verbindung zum Internet? Das konnte ich leider aus rc.S nicht eindeutig entnehmen. Ich vermute eher nicht. Und ganz früh brauche ich es auch nicht. Es sollte genügen, es vor denjenigen ds-mod Paketen zu starten, wo die Binaries ausgelagert sind. "mini-fo" ist ein Sonderfall und das lassen wir erstmal außer Betracht. Wo ich dieses rc.download_binaries paken würde:
1. Anfang von rc.mod
oder
2. Ganz am Ende von rc.S, wo rc.mod aufgerufen wird
oder
3. Ganz sauber am Anfang von static.pkg

Welche von den drei Möglichkeiten sollte man bevorzugen?

Und zum Punkt 3 habe ich dann eine Folgefrage. Ich würde gerne die ganze Geschichte als addon ausprobieren. Von addon wird erstmal ein eigenes static.pkg erzeugt. Ich vermute, dass "make" nachher einfach die beiden static.pkg (von festintegrierten Paketen und von addons) zusammenführt. Die Frage ist nur, in welcher Reihenfolge? Mir wäre es lieber, wenn die addons-Einträge ganz vorne in static.pkg stehen würden. Ob sie es wirklich tun? Oder liege ich da ganz falsch und die Reihenfolge wird irgendwie anders geregelt?

MfG

Hermann

Danke kriegaex für dein Support!

dsld wird wahrscheinlich in /etc/init.d/rc.net gestartet. Letztes wird ziemlich am Ende von rc.S nach dem Laden des dsl-Moduls wie folgt aufgerufen:
static.pkg wird genau anders rum aufgebaut, als es mir lieber wäre. Dafür heißen die Pakete auch "addons", um hinterher angehängt zu werden. Aber ich schaue es mir bei mini_fo oder anderen Paketen ab, wie man die Skripte an die passende Stelle in static.pkg bringen kann. Zunächst kann man das auch per Hand machen.

Nun habe ich eine weitere Frage. Mit den binaries wird es wahrscheinlich mit dem Umleiten der PATH-Variable funktionieren. Wie sieht es denn mit den Bibliotheken aus? Ich vermute sehr stark, dass alleine Binaries auszulagern nicht ausreicht. Die betroffenen Bibliotheken liegen unter /usr/lib. Gibt es denn auch so eine Variable wie PATH, wo die Pfade zu Bibliotheken beschrieben werden? Ich würde dann zu dem Suchpfad z.B. /var/tmp/lib von vorne hinzuaddieren.
Einige würden mir natürlich sagen, dass man lieber statisch-gelinkte Binaries kompillieren sollte. Das können aber hier im Forum sowieso nur ein dutzend Leute. Außerdem ist meine Idee, die bestehenden Pakete zu nutzen, möglichst ohne sie groß zu modifizieren.

MfG

Hermann

danke!

mit grep konnte ich es zu dem Moment nicht tun, weil Friboli gerade am rumkompillieren war. Ich hatte mir über Samba-Freigabe die beiden Dateien angeschaut gehabt und die gleichen Zeilen wie du gefunden. "Wahrscheinlich" stand dort eben deswegen, weil es mehrmals vorkommt und deswegen für mich nicht eindeutig war.

Zu den Bibliotheken. Nein, es reicht nicht aus, wenn man z.B. OpenVPN haben will. Ich lasse ja die ganzen web-cgis und sonstige Sachen in dem Image drin. Dadurch kommt schon was zusammen. Ich habe mittlerweile testweise ein Image mit ausgelagerten dropbear, dnsmasq, mc und openvpn gebaut. Es ist zwar noch nicht lauffähig, da ohne Nachladeskripte, aber nur so konnte ich ein Image mit etwa 33kB unter der Schmerzgrenze bauen.
Ausgelagert sind:
Da ich die drei Bibliotheken nicht unter Original-Frmware gefunden habe, hoffe ich, dass sie zu dropbear und openvpn gehören.

Mit LD_LIBRARY_PATH habe ich es inzwischen auch gefunden. Etwas wundert mich allerdings das Ziel /mod/lib. Auf meiner 7050 mit derzeitigem ds-mod ist dieses Verzeichnis leer. Zeigt es vielleicht doch auf irgendeine mir unbekannte Weise auf /lib? Aber das ist eigentlich egal. Die Hauptsache, dass die Box nachher in den Verzeichnissen LD_LIBRARY_PATH auch sucht.

Zu Recovern und Box-Zerschießen bin ich mir schon bewußt. Ich gehe recht langsam vor und teste es erstmal auf der laufenden Box im /var/tmp (mit PATH hat es funktioniert). Außerdem habe ich eine zusätzliche 7050 zum spielen.

MfG

Hermann

Das heißt, wenn ich diesen LD_LIBRARY_PATH um /var/tmp/lib vor dem /mod/lib erweitere, also in etwa so:
dann wird nach Bibliotheken erstmal in /var/tmp/lib gesucht.

Jetzt habe ich eine generelle Frage zu PATH-Variable. Ich habe gesehen, dass diese Variable an -zig Stellen in dieversen Skripten und cgi-s absolut gesetzt wird. In etwa
Laufe ich hier die Gefahr, dass die Setzung meines Pfades zu /var/tmp/bin gnadenlos während des Betriebes von einem der Skripte oder CGI-s überschrieben wird? Oder liege ich hier falsch? In rc.mod wird PATH-Variable um einiges erweitert. Diese Einstellung bleibt auch erhalten und wird nicht mit anderen Skripten überschrieben.

Ich wusste nicht, dass /var/mod/lib physikalisch im RAM liegt. Aber wenn es so ist, dann macht es die Sache einfacher.
Ich habe gerade festgestellt, dass das Gleiche für /var/mod/bin und /var/mod/sbin gilt. Das heißt, ich brauche gar nicht die Verzeichnisse anzulegen und PATH-Variablen "verbiegen", alles ist schon vorbereitet. Einfach binaries nach bin oder sbin paken und libs in lib. rc.mod definiert diese Pfade, von daher sollte alles dort gefunden werden.

MfG
Hermann

Erste zum Teil erfolgreiche Versuche

Nun habe ich meine Ideen zum Teil implementiert. download-Skript ist samt cfg-Datei und cgi in erster Fassung fertig. Ich konnte es sogar in ds-mod fest integrieren. Dateien werden schön runtergeladen, erst danach starten die Pakete. Man sieht es sogar an der langsam aufbauender Paketliste von ds-mod. Zum starten konnte ich allerdings nur dnsmasq bringen. openvpn habe ich noch gar nicht getraut zu starten, dropbear wird nicht gefunden, sowie mc.bin. Ursachen sind die Symlinks, die in diesem Fall ins Leere zeigen. Ich hatte mal gehoft, dass zumindest mc -> mc.bin nicht absolut ist, sondern es dabei in allen Pfaden gesucht wird. Dem ist es leider nicht so.
Gelernt haben wir daraus Folgendes: Es reicht nicht die Dateien (binaries oder libs) einfach zu löschen und zu hoffen, dass sie anderswo gefunden werden.
Abhilfe: Ich werde anstatt gelöschten Dateien nun symlinks auf ihre neue Orte unter /mod/bin usw. anlegen. Und hoffen, dass es dann klappt.
Positiv anzumerken ist, dass die Box auch mit nicht gefundenen Binaries trotzdem stabil läuft. Ich teste es noch weiter.

MfG

Hermann

Alle Symlinks mühsam eingefügt. Nun geht alles erstmal ohne Probleme. Mit toten Verweisen ist mir die Box in etwa nach 3 Stunden abgeschmiert. Mal sehen wie lange sie jetzt hält.
Wie erkenne ich eigentlich, dass Speicher überläuft, von dem hier immer befürchtet wird? Die grüne Anzeige auf der DS-MOD-Titelseite bleibt in etwa zwischen 17 und 18 MB. Theoretisch ist es weit vom Limit entfernt.
Als Bild ist meine gebastelte CGI und Startlog bei.

MfG

Hermann

Naja, damit sieht es etwas enger aus. Ob es so schlimm ist, weiß ich nicht.

MfG

Hermann

Da mein Downloader an sich gut funktioniert, frage ich einmal pauschal, ob Interesse besteht, es als Paket zu machen. Fast alles nötige habe ich im Prinzip da: Skript, rc.datei, datei.cfg, datei.cgi (s. oben). Das einzige, was hier fehlt, man muss diesen Downloader an die erste Position von static.pkg bringen. Entweder macht man es per Hand, oder jemand hilft mir dazu ein Skript zu schreiben.

Ich denke solche webbasierte Download-Möglichkeit beim Start der Box (bevor die Pakete geladen sind!) würde schon einen oder anderen hier interessieren. Nicht nur dafür, wofür ich es verwende. Dann kann man in debug.cfg die wget und chmod Zeilen ersparen.

Natürlich bleiben noch tausende anderen Fragen offen: wie man z.B. die Binaries und Libs aus dem Image nach dem make-Durchlauf automatisch rausnimmt, damit Image ohne Fehlern erstellt werden kann. Die kann man aber nach und nach automatisieren.

MfG

Hermann