PeterPawn
commented
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.
MAnantharaman
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