Closed MAnantharaman closed 6 years ago
Meine Punkte, warum ich das so nicht umsetzen werde (nicht böse sein):
[ -v debug ] && stderr= || stderr="2>/dev/null"
"-v" ist kein POSIX-Standard (die "ash" der BusyBox kennt es gar nicht erst) und den Test, ob eine Variable gesetzt ist oder nicht, kann man ohne größere Probleme auch POSIX-kompatibel machen (bis hin zum "set -u" und dem Abfangen beim Versuch, auf die Variable zuzugreifen - das ist dann schon "der harte Weg").
Ansonsten fange ich ja die Fehler bereits ab und gebe - sofern "-d" beim Aufruf angegeben wurde und ich "debug=1" setze - eigene Fehlernachrichten aus ... ob man jetzt diese präferiert (weil sie mit etwas mehr Text erläutern, bei welchem Schritt das Problem auftrat) oder ob man lieber die originalen Fehlernachrichten der aufgerufenen Kommandos hätte (die nicht zwangsläufig aussagekräftiger sind, solange man nicht parallel noch sehen kann, welches Kommando sie verursachte - nicht jedes Kommando (auf jedem System) liefert ausführliche Fehlermeldungen und ein "access denied" ist ohne Kenntnis des aufgerufenen Kommmandos einigermaßen sinnlos), ist wohl eher Geschmackssache.
Ich will auch nicht über weitere Optionen für das Skript nachdenken ... wer parallel noch die ausgeführten Kommandos sehen will, der ruft einfach die Shell für das gesamte File mit "-x" auf und sieht jedes einzelne Statement vor seiner Ausführung.
Aus der Fehlernachricht "Error mounting ext2 image for the new filesystem." (diese solltest Du ja erhalten haben) auf ein Problem mit dem "mount"-Kommando zu schließen (sofern man das als nicht-privilegierter Benutzer aufgerufen hat und das eigene System auch noch so eingestellt ist, daß da "mount" nicht durch ein Skript mit entsprechenden Hinweisen ersetzt ist und "normale" Benutzer es nicht verwenden können, weil kein "Bereinigen" von Optionen und automatisches Aufrufen mit "sudo" erfolgt - das sind also schon einige Voraussetzungen, die da erfüllt sein müssen, damit der Fehler überhaupt genau an dieser Stelle auftritt), bleibt wohl Aufgabe des Aufrufers.
Bei anderen wird nämlich bei einem nicht-privilegierten Benutzer (hängt halt auch wieder vom eigenen System ab) vermutlich schon das "mkfs" davor nicht funktionieren, denn bei meiner Tumbleweed-Installation ist das z.B. in "/usr/sbin" enthalten und damit auch nicht jedem zugänglich.
Ich kenne jedenfalls auch genug Leute, die von den Ausgaben auf "stderr" eher verwirrt werden (genau deshalb gehen die ja nach "/dev/null" und werden von mir mit eigenen Nachrichten abgefangen im Fehlerfall) ... erst recht dann, wenn die "Quelle" des Fehlers (also das tatsächlich gerade ausgeführte Kommando in so einem automatischen Ablauf) weiterhin im Dunklen bleibt.
Bleibt vielleicht noch die Aufgabenstellung, explizit in der Beschreibung (im IPPF) zu betonen, daß diese ganzen Skript-Dateien am besten als Superuser aufgerufen werden ... wenn ich das tatsächlich nicht erwähnt haben sollte, denn ich habe die Dateien ja auch auf Raspbian getestet und da braucht man eben auch das "sudo" (entweder für das einzelne Skript oder gleich für die gesamte Shell-Session).
Ansonsten hat das mit dem "Einfangen" der Box durch "eva_discovery" wohl eher nicht so funktioniert, wie Du dachtest ... es wäre mir jedenfalls neu, daß das Kennwort für den FTP-User in EVA durch ein Firmware-Update geändert wurde oder wird. Damit sollte da immer noch der Benutzer "adam2" mit Kennwort "adam2" korrekt sein (deshalb gibt es auch gar keine Möglichkeit, das im "eva_to_memory" irgendwie zu konfigurieren, iirc) und wenn damit keine Anmeldung möglich ist, ist es wohl der falsche FTP-Server.
Kein Problem, war ja nur ein Vorschlag:-) Du bist der Eigentümer - und unumstrittener Meister der FRITZ!Box.
Das mit FTP-Passwort hast sich erledigt: Beim nächsten Reboot tat es wieder - vielleicht habe ich wirkich die falsche IP im Einsatz gehabt ...
ABER: Auch wenn ich dann mehrmals reproduzierbar die Box beim Reboot abfange und die SIAB-Image hochladen konnte - auf Port 8010 war Funkstille! Lässt sich natürlich nur schwer auf der Box debuggen, so lange man keinen Zugriff darauf hat:-(
Ansonsten bzw. Zurück zum Issue (den Du natürlich gerne schließen kannst): Sind denn solche Vorschläge generell unerwünscht? Dann gebe ich Ruhe:-) Sonst habe ich wahrscheinlich ab und an schon weitere VorschlägeB-)
Gruß, Martin
Ich diskutiere jeden Verbesserungsvorschlag gerne aus ... aber ich habe eben auch (meist im IPPF) schon ein paar Überlegungen, die mich bei einigen Entscheidungen geleitet haben, erläutert. Steht ein Vorschlag - ohne gute Begründung - diesen Überlegungen entgegen, bin ich natürlich erst einmal skeptisch.
Aber ich mache definitiv auch nicht alles richtig und vieles, was sich hier im Repo findet, ist mehr Proof-of-Concept als "richtiges" Skript zum Nachnutzen für alle. Wenn sich da also Verbesserungen ergeben und daraus auch noch Pull-Requests werden, schaue ich mir jeden (aber wirklich auch jeden) davon genau an und übernehme alles, was passend erscheint - sofern es eben für alle (oder zumindest für viele) Relevanz hat (da halte ich es ganz mit Mr. Spock).
Wenn man die Auswirkung des "add_startup_skript" sehen will, muß das mit "-d"-Switch aufgerufen werden (macht das "build..."-Skript schon so, iirc) und dann schreibt das auch bei seiner Ausführung die komplette Ausgabe auf "stderr" (und zwar inkl. der ausgeführten Kommandos, weil parallel noch ein "set -x" eingesetzt wird) in eine temporäre Datei, die am Ende in das TFFS (Node 141 - das ist "calllog" und sowohl in einer Export-Datei (in Hex) als auch in einem TFFS-Image aus den "erweiterten Supportdaten" enthalten) gesichert wird. Ist diese Datei leer, weiß man zumindest, daß es nie bis zu diesem Punkt gekommen ist mit der Abarbeitung.
Ich habe beim Zusammenstellen solcher Skripte natürlich in der einen Partition immer eine Version installiert, bei der ich schon einen Shell-Zugang habe (den kann man ja auch ohne SIAB, direkt im Image, einrichten) und von der aus ich nach dem Umschalten und Booten aus dieser Version dann die Stellen in der inaktiven YAFFS2-Partition kontrollieren kann.
Es gibt aber auch noch ein paar Stellen in der Support-Datei, wo man sich Veränderungen ansehen kann ... ist dort z.B. die Ausgabe von "mount" enthalten, müßte man darin auch die Zeile für das "bind"-Mount der "rc.S" finden, wenn das funktioniert hat und auch die automatisch editierte "rc.S" sollte unter dem Namen "init_rc_replacement" in der Auflistung des "/var/tmp"-Verzeichnisses in der Support-Datei sichtbar sein, wenn die Skripte bis zu dem Punkt gekommen sind, wo diese Datei erstellt wird.
So kann man sich aus ein paar "Markern" dann auch einigermaßen zusammenreimen, wo es klemmen könnte und vielleicht gibt ja schon die Existenz und der Inhalt der "calllog" Auskunft.
Ich habe diese Datei auch nur deshalb gewählt, weil sie vom Export des FRITZ!OS in hexadezimaler Form direkt ausgegeben wird ... man kann natürlich auch jeden anderen TFFS-Node (unbenutzt sollte er aber schon sein) verwenden (dann braucht man eben das Image aus den erweiterten Support-Daten) oder man schreibt das Log (meinetwegen als Broadcast-Stream per UDP o.ä., wobei man dazu wieder passende Applets der BusyBox braucht) über das Netzwerk irgendwo hinein. Der eigenen Phantasie sind nur wenige Grenzen gesetzt ...
Ergänzung: Seitdem ich die Binärdateien in "bin" und die fertigen Images in "first_aid" in eigene Repositories ausgelagert habe, die nur noch als "submodule" eingebunden werden, haben manche auch ihre Probleme beim Erstellen eigener Images, weil die "submodules" nicht automatisch mit geklont werden. Man sollte also nach dem Auschecken diese beiden Unterverzeichnisse des YourFritz-Repos noch einmal prüfen, daß da tatsächlich auch die notwendigen Dateien enthalten sind - und vor allem sollte man immer aktuelle Versionen klonen, weil diese Änderung noch nicht sooo alt ist und ggf. da noch andere Pfade zu den Skript-Dateien verwendet wurden, denn auch da habe ich etwas "organisiert" und die Dateien in Unterverzeichnisse in "toolbox" verschoben.
Nach langer Zeit bin ich wieder an meiner 7490 - und wollte natürlich gleich das tolle neue build_shellinabox_implant_image ausprobieren - und bekam als Ausgabe (also das gewünschte Image) nur 0 Byte:-0 Dass liegt darann, daß auf meinem ArchLinux moutn nur von root genutzt werden kann - aber diese Meldung war in /dev/null verschwunden. Beiliegend ein Vorschlag, wie man etwas mehr (= hilfreiche) Fehlermeldungen bekommen kann. YourFritz.diff.zip
Am Rande: Ich machte dann weiter und auch das aktuelle eva_discover fing die Kiste beim Reboot (das hatte e sfrüher nicht getan) - aber dann scheiterte eva_to_memory - weil wohl in 6.93 das bisherige EVA-Passwort adam2 nicht mehr gilt:-0
Gruß, Martin