Systemupdate via Image über Webseite

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo Zusammen,

    ich hab schon gesucht, aber ich habe noch nicht die passenden Keywörter um mein Problem zu fassen. Darum beschreibe ich es hier mit der Hoffnung, dass ihr mir helfen könntet.

    Folgendes möchte ich tun:
    Ich möchte gerne auf meinem RP einen Webserver laufen lassen. Drüber möchte ich eine img-Datei hochladen und das System soll nach einem Neustart upgedatet werden. Wie ich es Beispielsweise von meiner QNAP NAS-Platte kenne.

    Was ich mir bis jetzt Überlegt habe:
    - Das img-File könnte man via dd flashen
    - Ich muss das Root-System unmounten, um so eine Update durchzuführen. Dazu müsste ich das Image und das System uu auf einer RAM-Disk haben
    - Problem: Sollte jetzt was passieren ist alles weg - RAM-Disk halt.
    - Alternative: ein 2. Betriebsystem auf einer alternativen Partition, welches ich für das flashen boote.

    Bin ich mit den Vorstellungen auf dem Holzweg?
    Hättet ihr ein paar Tips zum googlen für mich bzw. besser ein Tutorial oder so was?

    Danke euch.

    Grüße TuhPon

  • Servus,
    das wird so nicht funktionieren ... Du kannst die SD-Karte mit dem aktuellen System während des Betriebs nicht einfach überschreiben.
    Bei z.B. OTA-Updates wird das so gehandhabt, dass das neue Image in einen freien Bereich des Flash gespeichert und anschliessend ein reboot ausgeführt wird. Vor dem eigentlichen Bootvorgang wird dann z.B. das neue Image umkopiert. Diese Funktion ist im ROM bzw. der Firmware verankert. Und genau dieser Mechanismus fehlt Dir beim Raspi ...

    //EDIT: danke für den Hinweis. Hatte ich glatt überlesen ..

    cu,
    -ds-


  • Wieso möchtest du denn jedesmal ein vollständiges Image neu flashen?
    Was wird sich in der *.img Datei zum Vorherigen geändert haben?
    Kennst du PXE? ;)

    Danke für deine Antwort.
    Die RPs werden keinen Verbindung zum Internet haben. Darum ist ein apt-get update / upgrade raus. Und es werden "Leihen" sein, welche die Administration übernehmen müssen. Darum wäre mein Gedanke das in ein Image zu packen und das Update vor Ort so einfach wie möglich zu halten.

    bei PXE benötige ich so wie ich das verstehe einen Server. da aber uu. nur ein RP in einem Netz ist, müsste ich dafür extra einen Server aus der Ferne ohne Internet aufsetzen. ::( Habe ich das so richtig verstanden?
    Coole Idee und ich schau mir das auf jeden fall an, ist aber für meine Anwendung zu Übermotorisiert.

    Danke :)
    Automatisch zusammengefügt:


    Servus,
    das wird so nicht funktionieren ... Du kannst die SD-Karte mit dem aktuellen System während des Betriebs nicht einfach überschreiben.
    Bei z.B. OTA-Updates wird das so gehandhabt, dass das neue Image in einen freien Bereich des Flash gespeichert und anschliessend ein reboot ausgeführt wird. Vor dem eigentlichen Bootvorgang wird dann z.B. das neue Image umkopiert. Diese Funktion ist im ROM verankert. Und genau dieser Mechanismus fehlt Dir beim Raspi ...

    //EDIT: danke für den Hinweis. Hatte ich glatt überlesen ..

    cu,
    -ds-

    Das *nicht* habe ich schon reingelesen ::) Aber danke.
    Das Schlagwort was ich wohl gesucht habe war wohl OTA. Dann lese ich mich da mal ein. Nachdem wir recht frei mit der Hardware sind suche ich mal ein ROM mit dieser Funktion.

    Danke euch.
    Jetzt wede ich erst mal wieder was zum lesen / nachdenken haben.
    Bei Rückfragen melde ich mich nochmal.

    Danke euch und noch einen schönen Sontag.

    Einmal editiert, zuletzt von TuhPon (9. April 2017 um 14:58)

  • Vor jedem Systemstart ein vollständiges Image neu zu flashen wird die Haltbarkeit der SD Karte extrem verringern. Die verträgt nicht unendlich viele Schreibzugriffe.
    Sowas ist eigentlich auch total unnötig nur weil sich evtl. ein paar installierte Pakete aktualisiert haben....

    Wenn die Pi's nicht mit dem Internet verbunden sind brauch das System auch nicht absolut perfekt auf dem neusten Stand sein.

    Wie kann es ein "Netz" geben wenn der Pi alleine ist?


  • Vor jedem Systemstart ein vollständiges Image neu zu flashen wird die Haltbarkeit der SD Karte extrem verringern. Die verträgt nicht unendlich viele Schreibzugriffe.
    Sowas ist eigentlich auch total unnötig nur weil sich evtl. ein paar installierte Pakete aktualisiert haben....

    Wenn die Pi's nicht mit dem Internet verbunden sind brauch das System auch nicht absolut perfekt auf dem neusten Stand sein.

    Wie kann es ein "Netz" geben wenn der Pi alleine ist?

    Da reden wir aneinander vorbei. Das soll nicht bei jedem Systemstart passieren sondern nur, wenn über die Weboberfläche (die dient generell zur Interaktion mit den Benutzer) ein Image hochgeladen wurde. Das soll dann letztendlich auch das Flashen triggern. Somit habe ich keine bedenken bzgl. SD Karte. An die Scheibzyklen habe ich auch schon gedacht.

    Es geht auch nicht darum, das alle Pakete immer auf dem neusten Stand sind. Es wird nur so sein, das darauf Software, Skripten etc. von uns laufen werden. Wenn hier ein Update nötig wäre, benötige ich eine Updatemöglichkeit für DAUs. Die Variante bei meiner QNAP finde ich da als beispiel recht gut: DAU geht auf Webseite, klickt auf "Image Upload", wählt die Datei aus und ist fertig.

    Das Pi (oder vergleichbare Hardware) wird sich in einem Internen Netz befinden und wird somit über einen Browser erreichbar sein. Jedoch nicht mit dem Internet.

    Danke für deine Antwort. :)

  • Hallo TuhPon,

    warum stellst Du die heruntergeladenen zu installierenden Update-Pakete nicht irgendwo hin? Sobald ein Raspberry Pi hiochgefahren ist, schaut er dort nach. Steht was drin, macht er ein gezieltes update/upgrade von dieser Quelle. Das ist sicherer und deutlich schneller als ein Image zu flashen.

    Außerdem hättest Du es in der Hand, selber zu bestimmen, welche Updates zugelassen werden und welche verworfen werden.

    Ich hatte mal eine Anwendung [font="Courier New"]Updater[/font] geschrieben, das in diese Richtung geht.


    Beste Grüße

    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.


  • ... sondern nur, wenn ... ein Image hochgeladen wurde. Das soll dann letztendlich auch das Flashen triggern. ...


    wie gesagt, das mit dem Flashen kannst Du imho vergessen ... aber ...
    warum archiviert ihr Eure Software nicht einfach in .deb Paketen? Dann könnt ihr die Paketverwaltung nutzen und dabei nur euren Server als gültige Software-Quelle angeben. Der Update funktioniert dann z.B. über apt-get upgrade ... oder ihr klickt einfach auf das .deb-Paket und installiert es.
    Da könnt ihr dann auch z.B. einen notwendigen reboot drüber managen.

    //EDIT: grad' gesehen ... der Vorschlag von Andreas geht ungefähr in dieselbe Richtung ...

    cu,
    -ds-

  • warum stellst Du die heruntergeladenen zu installierenden Update-Pakete nicht irgendwo hin? Sobald ein Raspberry Pi hiochgefahren ist, schaut er dort nach. Steht was drin, macht er ein gezieltes update/upgrade von dieser Quelle. Das ist sicherer und deutlich schneller als ein Image zu flashen.

    Außerdem hättest Du es in der Hand, selber zu bestimmen, welche Updates zugelassen werden und welche verworfen werden.

    Ich hatte mal eine Anwendung [font="Courier New"]Updater[/font] geschrieben, das in diese Richtung geht.

    Hallo Andreas,

    darf ich da nochmal nachfragen wie du das gemeint hast.
    Ich stelle mir das jetzt so vor, wie wenn ich ein lokales Repository für apt-get erstelle. Über die Webseite packe ich, via z.b. eine Zip-Datei, meine neuen Pakete in ein Verzeichnis (Quasi der Ort meines lokalen Repositorys) und trigger einen Reboot. Bei dem Reboot wird ein apt-get update auf dieses Verzeichnis druchgeführt und dann ein apt-get upgrade?

    Habe ich das so richtig verstanden?

    Danke dir. :)

  • Ich würde auch die Richtung von Andreas & dreamshader einschlagen.

    Du schreibst dir quasi ein Script was für dich die Installation übernimmt. Du legst dann beispielsweise nur eine *.zip irgendwo ab in der alle zu ersetzenden Dateien enthalten sind inkl. kompletter Pfade. Oder du legst halt im Script direkt fest welche Datei wohin kopiert werden soll.

    Sowas habe ich mit einem älteren Projekt auch so gehandhabt:
    Der Benutzer konnte über die Konsole einen "update" Befehl ausführen und das war ein bash Script.
    In dem Bash Script steht drin das via wget oder curl eine bestimmte URL geprüft wird und falls die entsprechende Datei neuer ist also die lokal, wird diese heruntergeladen und entpackt.
    Das kann man auch via PHP realisieren, sollte nicht allzu aufwändig sein.

    Du kannst das "update" Script auch via @reboot in die Crontab vom root Benutzer einbinden und diese Prüfung bei jedem Systemstart automatisch machen lassen. Dann brauch der DAU vorm Pi überhaupt nichts mehr machen.

    Allerdings schweigst du dich immer noch darüber aus was überhaupt aktualisiert werden soll. Das flashen eines kompletten Abbildes halte ich weiterhin für sehr fragwürdig.


  • Ich würde auch die Richtung von Andreas & dreamshader einschlagen.

    Du schreibst dir quasi ein Script was für dich die Installation übernimmt. Du legst dann beispielsweise nur eine *.zip irgendwo ab in der alle zu ersetzenden Dateien enthalten sind inkl. kompletter Pfade. Oder du legst halt im Script direkt fest welche Datei wohin kopiert werden soll.

    Sowas habe ich mit einem älteren Projekt auch so gehandhabt:
    Der Benutzer konnte über die Konsole einen "update" Befehl ausführen und das war ein bash Script.
    In dem Bash Script steht drin das via wget oder curl eine bestimmte URL geprüft wird und falls die entsprechende Datei neuer ist also die lokal, wird diese heruntergeladen und entpackt.
    Das kann man auch via PHP realisieren, sollte nicht allzu aufwändig sein.

    Du kannst das "update" Script auch via @reboot in die Crontab vom root Benutzer einbinden und diese Prüfung bei jedem Systemstart automatisch machen lassen. Dann brauch der DAU vorm Pi überhaupt nichts mehr machen.

    Allerdings schweigst du dich immer noch darüber aus was überhaupt aktualisiert werden soll. Das flashen eines kompletten Abbildes halte ich weiterhin für sehr fragwürdig.

    Danke ::)
    Ihr schlagt alle den Weg des inkrementellen Updats ein. Von der Grundidee hab ich es auch verstanden. Die Umsetzung ist freilich noch eine Andere ;;)

    Ich wollte soweit auch nichts verschweigen ;;) Was ich aktualisieren möchte werden zum einen Pakete des (Betrieb)systems Rasbian, Webserver, (uu. php und mysql), evtl. java-runtime sein. Sprich wenn hier für uns relevante Security- bzw. Funktionsupdates kommen. Zum Anderen eigene Programme, welche in c bzw. java, geschrieben sind. Aus dennen kann ich auch Pakete bauen. Des weiterne wird die auf dem Teil laufende Webseite aktualisiert werden müssen. Hier sind wir bei .html und .php-Seiten. Aber so wie ich das verstehte kann ich mir da auch ein .deb-Pakete bauen.

    Mein Ansatz das komplete Teil zu Flashen ist folgender: Ich habe etwas "Angst" davor, das sich meine Systeme fragmentieren. Ich werde später nur sehr wenig Kontrolle über die Rechner haben. Sprich, wenn ich ein inkrementelle Update einem DAU zum einspielen gebe und er das nicht tut und ich ihm eine weitere Version zukommen lasse, kann ich nicht sicher sein, das er bis dato auf dem neustem Stand war. Wenn ich jetzt Abhänigkeiten zur vorherigen Version habe befürchte ich, dass es schwirig sein könnte aus der Ferne herauszufinden welchen Stand er hat und was ich noch alles brauche um zum neusten Stand zu kommen.

    Daher die Idee mit dem Flashen, er bekommt eine Datei und gut ist. Da steht eine Versionsnummer für das gesamte System dabei, die ich leicht über die Ferne durchs Telefon abfragen kann. Past die ist gut, sonst letztes Image drüber. Den Rest kann ich bei mir im dunklen Keller vorbereiten.

    Seht ihr meine Bedenken hier als unbegründet?
    Welche Punkte sprechen den gegen das flashen des Systems um so den Versions-drift vorzubeugen?

    danke euch :)


  • ...
    Welche Punkte sprechen den gegen das flashen des Systems um so den Versions-drift vorzubeugen?

    der, dass es technisch auf dem RPi nicht machbar ist ...

    Wieso eigentlich jetzt "inkrementelles backup" ??
    Und was spricht aus Deiner Sicht dagegen die Linux Paketverwaltung zu verwenden?
    Da hast Du die ganze Versions-Verwaltung mit Abhängigkeiten auch gleich mit erledigt.

    Irgendwie kommt mir das alles noch sehr konfus vor ... :s

    cu,
    -ds-

    • Offizieller Beitrag

    Im Grunde ist das doch eine relativ einfache Angelegenheit. Auf Deinen Server im WWW schiebst Du eine Zip-Datei in der nur die von Dir selber geschriebenen Programme sind.

    Der User bekommt ein Bash-Script, nennen wirs mal update.sh.
    Mit apt-get update und apt-get upgrade ist das System schonmal auf dem aktuellen Stand.
    Jetzt noch per wget die Zip-Datei von Deinem Server laden, entpacken, alte Programme ersetzen, färtsch. :denker:
    Diese "update.sh" könnte man auch über einen cronjob regelmäßig anschubsen. Wenn keine aktuellere Zip auf dem Server, als die Installierte, dann macht er eben nur die Systemaktualisierung.

    Das nur mal so grob zusammengefasst... :s

  • Die Sache ist ja die, das du das "root"-Dateisystem nicht umounten kannst sobald davon gestartet wurde und es in Verwendung ist. Dh. man kann dann die SD Karte von der gebootet wurde nicht im laufenden überschreiben.
    Wenn man das doch möchte muss man also von "wo anders" booten sodass die SD Karte nicht eingebunden wird.
    Das wiederum lässt soweit ich weiß nur 2 Möglichkeiten zu:
    1) PXE, also übers Netzwerk booten.
    2) Über USB booten.

    Beides bringt dann aber ein weiteres Problem mit sich, bzw eigentlich sogar zwei...
    1. Wie wird entschieden wann über den alternativen Weg gebootet wird.
    2. Kann der DAU mit, für ihn merkwürdigen, langen Wartezeiten bis der Pi für ihn bedienbar ist, leben? DAU typisch wäre nämlich dass diese Individuen schnell in Panik verfallen und wild irgendwo drauf drücken oder an irgendwelchen Kabeln rütteln :D

    Nach wie vor sehe ich den Weg über eine Zip am einfachsten. Du musst dir nur eine Struktur überlegen nach der vorgegangen wird, wie zum Beispiel: *.deb werden installiert, alles andere ist in unterschiedlichen Ordnern abgelegt wo jeweils eine Txtdatei enthalten is "wohin" das/was kopiert werden soll.
    Wenn du im "Netz" von den Pi's sowieso einen Webserver hast auf den du deine "Updates" drauf hoch lädst, dann kannst du dort auch ein Verzeichnis mit einer Datei ablegen, die dann der jeweilige Pi beim booten (@reboot via crontab o.ä.) prüft... Ich machte das wie gesagt bisher so:

    Auf dem Webserver: /var/www/html/SetupPI/.version ... und da steht zB drin: 0.05
    Auf dem Pi wiederum liegt diese .version Datei ebenfalls irgendwo, am besten in /usr/local/etc/
    Das Script auf dem Pi macht dann quasi folgendes: Es läd die remote .version Datei herunter, also die vom Webserver, und vergleicht den Inhalt der Datei mit der lokalen. Ist die remote Zahl höher wird eine Zip heruntergeladen usw.. UU. reicht es auch den Timestamp der Dateien zu vergleichen, aber ich fand es besser anhand des Inhalts, das ist nicht so anfällig.

    Dieses Vorgehen kann man wie gesagt automatisieren und kann on-the-fly erledigt werden, sobald Netzwerk verfügbar ist (WLAN oder LAN).

    Wenn du wie gesagt unterschiedliche Dateien hast, könntest du dir eine Struktur überlegen die dann von einem Script dynamisch verarbeitet werden kann. Oder du legst dem Zip einfach eine Setup.sh bei die vom Pi dann ausgeführt wird, und in der drin steht was wie wo installiert werden soll - also was du dann jedesmal erneut beim erstellen der Zip in die Setup.sh rein schreibst.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!