Firmware update per remote

[kriegaex]

Welche Dienste Du stoppen willst, ist doch gar nicht boxspezifisch, sondern bestenfalls situationsspezifisch. Mal flashst Du remote, mal daheim. Mal spielst Du mit einer Firmware herum, die OpenVPN enthält, mal bist Du per SSH drin. Mir ist es lieber, jemand muß 10 Sek. opfern, um auf Buttons zu klicken, als einmal etwas abzuspeichern und es dann blind ausführen zu lassen. Das ist genauso gefährlich wie ein falscher Klick, denn es passiert, ohne daß Du daran denkst.

Aber ein Tip für die Automatisierer unter Euch: Legt Euch doch unter /tmp/flash oder sonstwie ein Skript an, das tut, was Ihr wollt. Einmal vor dem Flashen ausführen über SSH oder Rudi-Shell. Geht aber wohl auch nicht schneller als das manuelle Stoppen der Dienste.

Moment, mir fällt noch was ein: Per mount -o bind kann man direkt beim Booten prepare_fwupgrade virtuell überschreiben mit einer Variante, die so gepatcht ist, daß sie genau das tut, was Ihr wollt. Das kann entweder der gewünschte Aufruf Eures Kill-Skripts sein oder das direkte Ausführen der Stop-Befehle direkt aus dem Skript heraus.

Ich denke, damit sollten sich alle Wünsche erfüllen lassen, auch die von knox. Happy scripting!

 

[knox]

Semi-Off-Topic:
Es geht nicht darum, ob es mir gefällt!

On-Topic:
Stellt Euch doch bitte vor, ein "normaler" Anwender hat ein ds-mod mit diversen Paketen installiert. Unter Umständen scheitert dann das Update (z.B. über WebIF), weil nicht genügend RAM vorhanden ist. (Samba, OpenVPN, TOR, usw.)
Dabei denke ich vor allem an das Update durch den "normalen" Anwender über WebIF - wer sich abseits des Mainstreams bewegt, sollte natürlich wissen, was er tut.

Wenn es also erforderlich ist, die durch das Mod installierten Dienste zu stoppen, und das nicht in das AVM Script gepatcht werden soll, dann muss man den Anweder irgendwie anders darauf hinweisen. Meines Wissens nach steht das aber bisher nirgendwo.

Ich denke jedenfalls, das es ist für viele Leute nicht selbstverständlich ist und das eine Erweiterung des AVM Scriptes einfach ein schicker Komfort wäre und sicher einigen Leuten das Leben einfacher machen würde.

Dass es nicht gewünscht wird, habe ich inzwischen verstanden. Dann halt nicht.

 

[kriegaex]

Nein, Du hast es nicht verstanden. Es geht doch nicht darum, daß es nicht gewünscht wird oder aufwendig zu machen wäre, sondern darum, was die Alternative wäre. Ich habe bisher keinen Vorschlag gelesen, der beiden Seiten gerecht wird, DAUs und Profis, und dabei flexibel genug wäre, mal eine Ausnahme zu erlauben. Ich hingegen habe eine Latte an Vorschlägen gemacht, wie man bei Bedarf kriegen kann, was man möchte.

Noch ein konstruktiver Vorschlag: Wie wäre denn ein Hinweis auf der Eingangsseite des Update-Assistenten, der (rot, fett, von mir aus) darauf hinweist, daß und warum es eine gute Idee wäre, die Dienste zu stoppen. Dann sind die DAUs gewarnt, Dienste stoppen kriegen sie auch hin (eher, als ein Skript zu übermounten) und die Flexibilität für die Profis bleibt voll erhalten.

Manchmal sind die einfachen Ideen ziemlich effektiv, es muß nicht immer komplex oder gar kompliziert sein.

 

[knox]

Ich habe bisher keinen Vorschlag gelesen, der beiden Seiten gerecht wird, DAUs und Profis, und dabei flexibel genug wäre, mal eine Ausnahme zu erlauben.

Natürlich gibt es keine Universallösung, aber die ist eigentlich auch nicht nötig.
Zum Einen ist das ds-mod bisher eigentlich durchgängig der Linie gefolgt, komplizierte Dinge für den "normalen" Anwender so einfach wie möglich aufzubereiten, und das würde dafür sprechen, das AVM Script entsprechend zu patchen, damit alle Dienste gestoppt werden.
Zum Anderen können die Profis natürlich ganz einfach das Dienste abschalten umgehen, indem sie (z.B. beim Remote Update per Shell) das AVM Script bewusst nicht aufrufen...
Diese Lösung ist meiner Meinung nach anwenderfreundlich, flexibel und stressfrei zu implementieren.

Noch ein konstruktiver Vorschlag: Wie wäre denn ein Hinweis auf der Eingangsseite des Update-Assistenten, der (rot, fett, von mir aus) darauf hinweist, daß und warum es eine gute Idee wäre, die Dienste zu stoppen.

Ja, sicher eine gute Idee.

Manchmal sind die einfachen Ideen ziemlich effektiv, es muß nicht immer komplex oder gar kompliziert sein.

Meine volle Zustimmung. Dienste automatisch abschalten macht den "normalen" Anwendern das Updaten leichter und das weglassen des AVM Scripts als Profi würde ich nicht als kompliziert bezeichnen wollen

 

[kriegaex]

Und was, wenn ich zwar die AVM-Dienste stoppen möchte, weil das RAM kanpp wird, aber aus irgendeinem Grund noch Mod-Dienste weiter laufen lassen möchte? Beispiel: Ich kann das Herunterfahren des dsld verschmerzen, weil ich aus dem LAN update, aber ich arbeite über SSL-Tunnel, weil ich ein größeres LAN mit "Zuhörern" habe? Oder ich brauche vor dem Klick auf den Reboot-Button noch Zugriff auf die Box via Samba bzw. bin daran interessiert, den syslogd etwas übers Netz mitloggen zu lassen? Zugegeben, alles speziell, aber ich stelle mir schon wieder die Klagen der Profis vor, wenn das plötzlich nicht mehr geht.

In der Zeit, wo wir dies alles schreiben, hätte ich es vermutlich proggrammiert, aber ich möchte einfach bei solchen Entscheidungen überlegen, ob ich vielleicht jemandem schade, um anderen zu nützen, nur um denen vier Klicks zu ersparen. Die Normalos flashen sicher seltener als wir, und wir wissen uns zu helfen.

 

[MaxMuster]

Hi,

ich "stehe eher auf knox Seite" (wenn ich das mal so sagen darf). Ich würde eher andersrum warnen. Der "Normaluser", der mit laufenden Diensten beim Update Problemen haben könnte, wird auch aus meiner Sicht vermutlich nicht auf die Idee kommen, über OpenVPN oder gar dropbear und Co. ein Update Einspielen zu wollen.
Deshalb ist mein Vorschlag: Der "normale" Weg sollte sein, die Dienste zu stoppen und eventuell die "Experten" zu warnen, dass über diesen Weg dann eben kein Update per "ds-mod-Dienst" möglich ist. Dafür muss der dann selber sorgen, oder man könnte diese Art des "Expertenupdates" dann in der ds-Oberfläche integrieren.

Jörg

 

[hermann72pb]

genau, bei ds-mod-seitiger Update einfach Häckchen "dienste nicht stoppen" neben "prepare ausführen".
Obwohl, was mir gerade auffällt. Was ist z.B. mit dnsmasq? Wenn man DHCP vollständig auf dnsmasq umgestellt hat? Wahrscheinlich überlebt der Client-Rechner ohne DHCP-Anfrage und behält seine Adresse eine Weile weiter. Womöglich aber auch nicht. Alexander hat schon recht, so einfach wild einführen sollte man es nicht. Andererseits studieren gehts übers probieren.
Ich bin für die Einführung mit Abschaltmöglichkeit im ds-mod.

MfG

 

[wengi]

Hi,

hier mal ein kurzer Bericht:
ich habe gerade meine 7170 per ssh von ds26-15 auf ds26-15.2 aktualisiert.

Dazu habe ich
- Das Image auf meinen Webserver im INet gelegt.
- Die Box rebootet, um ein "sauberes" System zu haben.
- Alle unnötigen ds-mod Dienste beendet (callmonitor, openvpn, wol,...).
- Unter /var/tmp/fritzup.sh das Script von kriegaex angepasst und gestartet.

Dann kommt:

/ $ /var/tmp/fritzup.sh
killall: capiotcp_server: no process killed
killall: pbd: no process killed
voipd: stopped.
/bin/prepare_fwupgrade: line 87: avmike: not found
killall: printserv: no process killed

killall: udhcpd: no process killed
killall: dproxy: no process killed
killall: ftpd: no process killed
disable watchdog
killall: capiotcp_server: no process killed
killall: pbd: no process killed
killall: telefon: no process killed
killall: voipd: no process killed
killall: avmike: no process killed
killall: printserv: no process killed
killall: igdd: no process killed
killall: usermand: no process killed
rmmod: userman: Success

killall: ctlmgr: no process killed
killall: udhcpd: no process killed
killall: dproxy: no process killed
killall: ftpd: no process killed
killall: checkservices: no process killed
killall: thttpd: no process killed
killall: mailer: no process killed
killall: avmike: no process killed

Danach ist die Verbindung abgebrochen.
ca. 10 Minuten gewartet und ich hatte die Box auf aktuellstem Stand.
Alle Einstellungen blieben erhalten. Sogar der VPN-Server mit allen Anpassungen läuft auf Anhieb wieder.

Vielen Dank für Eure Anleitung.

wengi

PS: Natürlich habe ich das Image auf dem Webspace wieder gelöscht

 

[kriegaex]

Ja, das Protokoll zeigt erwartungsgemäß, wie prepare_fwupgrade zweimal durchlaufen wird, um Dienste zu stoppen: erst einige, dann später nochmal alles, was übrig ist und die zuvor bereits angefaßten zur Sicherheit nochmal. Deshalb kommen einige Namen doppelt vor, wobei man ja in diesem Protokoll im wesentlichen nur die Fehlerausgaben des kill- bzw. killall-Befehls sieht. Die erfolgreichen Kills erzeugen gar keine Ausgaben. Daß irgendwann die Verbindung abbricht, ist auch normal, denn die Netzwerkdienste werden ja heruntergefahren.

 

[bofh]

...Die allgemeine Grundregel, daß man vor einem "echten" Firmware-Update die DS-Mod-Dienste stoppen soll, soweit möglich, sollte bekannt sein,...

Das war mir leider ueberhaut nicht bekannt (obwohl ich vor jahren mit dem firtzmoden auf na fritzboxfon angefangen hab...)
(fuer mich klinkt das genause wie das tehma /tmp und die sun maschinen bei denen das /tmp auch im ram liegt... (kein problem wenn mans weis...)

Noch ein konstruktiver Vorschlag: Wie wäre denn ein Hinweis auf der Eingangsseite des Update-Assistenten, der (rot, fett, von mir aus) darauf hinweist, daß und warum es eine gute Idee wäre, die Dienste zu stoppen.

DAFUER!

gruss bofh

 

[kriegaex]

Keiner weiß alles, auch wenn er seit Jahren dabei ist. Wenn man per Bootloader flasht, spielt es z.B. auch keine Rolle. Aber wenn man per AVM-Oberfläche aktualisiert, was ja bisher fast alle getan haben und wogegen auch weiterhin nichts spricht (außer daß man weniger Kontrolle über den Vorgang hat), wenn man nicht gerade eine Speedport hat, werden die DS-Mod-Dienste auch nicht heruntergefahren, und alle haben es bisher überlebt. Jetzt gibt es seit ein paar Tagen eine neue Funktion im Mod, und schon wird wild darüber diskutiert, wie schlimm es doch sei, daß es dort nicht automatisch passiert. ;-) (Ich meine nicht Dich, bofh.) Es wäre nämlich seit Jahren möglich (und nicht weniger oder mehr sinnvoll als heute) gewesen, prepare_fwupgrade zu patchen und keiner hat es getan. Aber andererseits muß ein Entwickler auch damit leben, daß die Konsumenten seiner Arbeit neue Features nicht mit Freude zur Kenntnis nehmen, sondern sie zum Anlaß nehmen, immer noch mehr zu wollen. Das ist wohl menschlich, bedeutet aber nicht, daß jedem Wunsch entsprochen werden muß. Ich bitte weiterhin um ein bißchen Verständnis dafür, ich mache mir schon auch Gedanken und begründe ja auch meistens ausführlich (s.o.), wieso ich nicht jede Idee umsetze. Manchmal ist der Auwand mir zu hoch, manchmal habe ich andere Prioritäten oder schlicht zu wenig Zeit. Und dann gibt es noch den Fall, daß ich es so, wie es jetzt ist, einfach besser finde.

 

[MaxMuster]

Moin Alexander,
ich glaube, da bist du vielleicht etwas "überempfindlich" ;-) Ich habe hier zumindest keine Diskussion darüber bemerkt, das irgendetwas "schlimm" wäre. Ich war eher der Meinung, dass hier fundiert und sachlich darüber diskutiert wurde, ob es sinnvoll sei, dsmod Dienste automatisch zu beenden.
Dass dadurch zum Ausdruck käme dass wir "Konsumenten [d]einer Arbeit neue Features nicht mit Freude zur Kenntnis nehmen" sehe ich dabei nicht, zumindest ist es sicher nicht die Absicht der "Poster" gewesen...

Jörg

 

[kriegaex]

Ich schere nicht alle über einen Kamm, aber es ist nun einmal unbestreitbare Tatsache, daß neue Features hier regelmäßig neue Begehrlichkeiten und Kritik wecken. Ebenso ist es Fakt, daß dann viele glauben, beleidigt sein zu müssen, wenn man begründet nein sagt. Das hat nichts mit Empfindlichkeit meinerseits zu tun, sondern ist einfach so und zeigt eher die Empfindlichkeit anderer. Dabei spreche ich hier allgemein, nicht speziell von diesem Thema, obwohl es ja auch hier so war, daß über das automatische Stoppen von DS-Mod-Diensten erst im Zusammenhang mit dem neuen Button in ds26-15.2 geredet wurde, nicht etwa vorher (das Thema existiert schon länger).

Du hast im übrigen Recht, hier im Thema wird ziemlich gesittet und sachlich diskutiert, dem widerspreche ich gar nicht. Empfindlich bin ich an einer Stelle, das gebe ich gern zu: Ich fühle mich oft in Situationen gebracht, in denen ich unter Rechtfertigungsdruck gerate, d.h. ich begründe, weshalb etwas momentan so implementiert ist, dann kommen noch fünf "Ja-Abers", und am Ende liefere ich die begründete Beründung für die begründete Begründung. Diese Spirale kostet viel Zeit, und das liegt maßgeblich auch mit an mir, denn ich lasse ungern etwas offen stehen, sondern gehe dann auch wieder auf die Gegenargumente ein. In anderen Diskussionen habe ich einfach mal versucht, die Klappe zu halten und bekam dann hinterher PNs mit dem Inhalt, ich sei mir wohl zu fein, nochmal zu antworten. Wie man es macht, ist es falsch. Ich würde es gern allen recht machen, aber das geht nicht. Trotzdem bin ich naiv genug, es immer wieder zu versuchen. Aber ich will nicht mein Problem zu Deinem machen, entschuldige.

 

[McNetic]

Hi,

ich möchte auch gerne meine Meinung zum Thema abgeben: Mich hat das prepare_fwupgrade auch schon gestört. Zum Einen, weil es natürlich völlig dilletantisch irgendwelche Prozesse per killall abzuschießen versucht - selbst solche, die es auf keiner FBox jemals gegeben hat, soweit ich beurteilen kann. Zum anderen aber auch, weil ich auch der Meinung bin, dass es nur konsequent wäre, wenn man neue Dienste auf der Box einrichtet, dass diese dann ähnlich behandelt werden sollten wie die vorhandenen. Gerade für die unbedarfteren User wäre das auf jeden Fall sinnvoll. Aber auch ich habe das stark vermisst, als ich für den dsmod entwickelt habe, und teilweise 10 Mal am Tag die Box geflasht habe. Daher würde ich auch dafür plädieren, den Mechanismus zu überarbeiten.

Mein Vorschlag an dieser Stelle wäre, das ganze paramtrisierbar zu machen: Standardmässig sollten alle Dienste, die im 'Normalfall', d.h. Update aus dem LAN über die Weboberfläche, nicht benötigt werden, auch beendet werden. Darüber hinaus würde ich eine einfache Option anbringen 'DSMod-Dienste nicht automatisch beenden', dann werden diese nicht angefasst. Ideal wäre dann noch so was ähnliches wie vorgeschlagen, dass man praktisch ein Userscript einbinden könnte, oder evtl eine Oberfläche, wo man für die Dienste einzeln auswählen kann, ob sie beendet werden sollen.

Das soll jetzt aber keine Kritik sein, und auch keine Aufforderung, das oder etwas ähnliches zu implementieren, ich will erstmal dafür sorgen, dass ein etwas größeres Meinungsbild entsteht. Wenn ich wieder mehr Zeit habe, könnte ich auch selbst sowas implementieren - ist momentan aber schwierig.

Gruss, Nico

 

[hermann72pb]

Ich fasse mal die Wunschliste zusammen:
1. Häckchen "DSMod-Dienste nicht automatisch beenden", welches default leer ist (entspricht "alle Dienste beenden"). Im Hintergrund werden ds-mod Dienste per default beendet.
2. Userscript für FW-Update, welches per default nicht existiert und bei Bedarf angelegt werden kann. Vielleich sollte dieses Skript nur beim Update aus dem mod berücksichtigt werden (dann muss man nicht viel im AVM-prepare rumpatchen).

Alexander nimmt unsere Wünsche in seine Prioritätsliste gaaanz unten auf. Und wir warten geduldig und nerven ihn nicht weiter. Wenn McNetic Zeit findet, hilft er Alexander dabei.

Damit ist die Diskussion beendet!

MfG

 

[kriegaex]

Technische Anmerkung zu killall in prepare_fwupgrade

So dilettantisch ist das gar nicht im AVM-Skript: Erst mal werden alle Dienste, die einen Stop-Parameter haben, auch so angehalten. Falls sie keinen haben, ist killall ja das richtige Mittel. Daß in einem zweiten Durchgang nochmall alles mit killall -9 gestoppt wird, ist auch gut, denn so können auch Dienste, die sich aufgehängt haben, abgeschossen werden. Daß dabei auch einige Dienste sind, die gar nicht auf jeder Box existieren, stört nicht weiter und soll wohl vermeiden helfen, das Skript bei jeder Box und für jede FW-Version einzeln anzupassen - verständlich und für uns vorteilhaft, weil im Fall des Falles einfacher zu patchen.

Wünsche sind angekommen und wurden an den Nikolaus weitergeleitet. Dort liegen sie erst mal - wer weiß...

 

[McNetic]

Naja, vielleicht ist 'völlig dilletantisch' ein wenig übertrieben. Für mich sieht das ganze Ding aber wie eine ziemliche Frickelei aus: es ist total unübersichtlich da kaum formatiert, es schiesst wirklich irgendwelche Prozesse ab - ich zumindest kann auf meiner 7170 beispielsweise keinen thttpd, dproxy oder udhcpd entdecken - selbst wenn es denn irgendwann mal oder auf irgend welchen anderen Boxen geben würde, wär das noch unsauber. Ich denke, dass diese Datei (wie wohl auch einiges anderes) relativ unbesehen aus einem anderen embedded-Projekt übernommen (ich sag ja gar nicht geklaut ;-)) wurde.