Gluon 2018.1.x Autoupdater Configverlust-Gefahr

Technik Gluon
1

Statusupdate: "Gluon-Autoupdater-Risiko"
Derzeit scheint es ein Problem zu geben, das etwa wie folgt zu beschreiben ist:

Beim Autoupdater (oder manuellem sysupgrade) besteht das signifikante Riskio eines Config-Verlustes.

Symptom ist:

  • Nach dem Update startet das Gerät „ohne alte Config“, in der Regel im Setupmode.
  • alle Parameter sind wieder default, unter anderem:
    – Hostnamen wieder auf default
    – Verlust von fastd-hostkey
    – Verlust von hinterlegtem SSH-Keys

Auftreten:

  • „ausgehend von Gluon2018.1.x“ auf „egal was“ (also nicht bei 2016/2017.x>2018, sondern im Folgeschritt)
  • ein Firmware-Manifestdownload ist im Autoupdaterlauf vorher gescheitert
    – z.B. Download abgebrochen
    – z.B. eine nicht erreichbare URL („nur IPv4, aber Wifimeshknoten“)
    – z.B. „webserver sagte 404“ oder Webserver sagte „301/redirect auf https“ ->fail
  • Wenn dann die Firmware erfolgreich von der zweiten/dritten/n-ten download-URL geholt werden kann

Folge:

  • dann scheitert mit rund 50% Wahrscheinlichkeit das Erstellen des Config-Backups
  • Der Fehler wird jedoch nicht abgefangen
  • Der Router flashed das neue Image, findet jedoch im Ram dann kein Config-backup zum Wiedereinspielen
  • Reboot erfolgt dann „ohne alte Settings“
  • Router steht (blinkend) im Configmode und
  • auch Powercycle kommt immer nur wieder in den Configmode

Gluon-Issue:

TobleMiner hat den Fehler grandios lokalisiert und es gibt auch Fixes von ihm für das Problem. Es wird nur ein paar Tage dauern, insbesondere weil noch nicht entschieden ist, wie das auf Gluon2018.1.x zurückportiert werden kann, ohne an 3 Stellen mit Patches zu arbeiten. (Es ist sowohl LEDE betroffen, also auch der GluonMaster, der wieder OpenWRT ist, es betrifft aber auch die Busybox, was wieder ein anderes Projekt ist. Und ein weiteres fehlendes Errorhandling im gluon-„autoupdater“ macht es nicht einfacher.)
Will sagen: Es ist WorkInProgress.

Was ihr derzeit tun könnt:

  • Wenn ihr ausgehend von 2018.1.x den Autoupdater anwerft, dann stellt sicher, dass möglichst alle Update-URLs erreichbar sind, egal wie (und wenn ihr netzintern noch dns-records faked und mit dem radv Dinge bastelt)
  • ihr rollt eine Firmware (mit dem bald verfügbaren Fix) mit mit setting „Bypassconfigmode“ in der site.conf. Dann ist im schlimmsten Fall ein Router „ohne Namen und default-Settings“ online auf dem niemand einen ssh-Schlüssel hat. (oder ihr hinterlegt noch SSH-Schlüssel… sicher ein weites Feld für Diskussionen in der jeweiligen Community.)
  • Wenn ihr Zugriff per ssh habt, dann korrigiert manuell die autoupdater-URL
  • Oder spielt per ssh ein geändertes /bin/sysupgrade-script ein (mein Vorschlag, ohne Gewähr, hat hier aber einige Dutzend Upgrades so erfolgreich gelaufen. Im Fehlerfall macht der Knoten einen Kaltstart und und bootet mit den alten Settings hoch. )
  • Wenn ihr derzeit plant, eine 2018.1.x auszurollen, dann stellt das ggf. noch zurück, es halt den Autoupdater betrifft, der aktiv wird, wenn dann das darauf folgende Update ansteht.
4 „Gefällt mir“
2

Nachtrag: Wenn sämtliche Autoupdater-URLs verfügbar sind (und sowohl ausreichend gesigntes Manifest-files, wie das gesuchte Images liefern), dann funtioniert es auch derzeit mit der 2018.1-7 zuverlässig (abgebroche Downloads „wegen schlechtem Mesh“ außen vor).

Zumindest ein 841v9 hat hier über mehrere Tage hinweg ssh-getriggert immer wieder updates gezogen. Nach etwas über 2500 Firmwareupgrades habe ich es aufgegeben, auf einen Fail zu hoffen. (Und ja, der Knoten hing ganz normal per WAN im Internet und hat sich die Firmware vom Firmwareserver der Domain gezogen, also mit allen Unwägbarkeiten, die in einer normal laufenden Domain auftreten.)

Mein besagter obiger Hotfix des sysupgrade-scripts hat einen Test-Router in allen (nämlich 73 von 182 Update-Anläufen) vor dem Config-Verlust retten können.

3

Mit der v2018.1-10-g0cb9888 scheint das Problem gelöst zu sein nach meinem derzeitigen Stand.
Ich habe auf einem alten 841v9 scriptgesteuert jetzt erfolgreich ohne Störungen 96 mal die Firmware geupdated, ohne dass die Config verloren gegangen wäre. SSH-Schlüssel und Knotenname sind immer noch drauf. (und das Flashen selbst hat auch funktioniert.)

1 „Gefällt mir“
4

Mit anderen Worten, …

- LEDE_COMMIT=aaecfecdcde549e9e1aa09d1d5e5d0d43d5c9b49
+ LEDE_COMMIT=309414ee8d6cf2e31476133606b2e390b0efbac5

… ein Update auf neuereres LEDE löst das Problem? (Die zwei Commits davor hatten AFAICS keinen funktionalen Inhalt.)

5

Korrekt.
da ist die gefixte libuclient drin.
Das allein reicht als Fix.
Seit gestern nachmittag 245 autoupdater-Runs, 0 Fails bislang.
Fehler ist (für mich) damit behoben in „v2018.1-10“

2 „Gefällt mir“
6

FTR, jener LEDE-Commit aktualisiert auch den Kernel, und der dann gezogenen Kernel macht ext3 karpott, i. e. x86-basierte Images kriegen dann evtl. Probleme. (Quelle: #gluon @ hackint).

Das nur zur Warnung, falls noch jemand meinte, das sysupgrade-Problem ‚mal eben schnell‘ lösen zu können :wink:

1 „Gefällt mir“
7

Daher ist das ja auch seit 10h gefixt in gluon-v2018.1-11-g6a3d555.

1 „Gefällt mir“
8

bitte sowas nie ohne die commit id, sonst weiß man nicht exakt was gemeint ist - in diesem Fall gibt es zwei mögliche commits

EDIT: Danke!

3 „Gefällt mir“
9

Der Fix ist nun auch im Gluon Release v2018.1.1 enthalten.

3 „Gefällt mir“
10

Moin,
wir haben Gluon 2018.1 (release) basierte Firmware.
Ich habe in der site.conf 3 Adressen. 2 davon waren jetzt eine weile nicht erreichbar (es handelt sich um Server die ich nutze um sie nur gezielt für einzelne knoten erreichbar zu machen wenn sie „gerettet“ werden müssen).
Ich habe jetzt alle DNS Einträge auf den gleichen Server umgebogen, so dass alle erreichbar sind. Ich muss aber natürlich davon ausgehen, dass Router die schon 8 Tage oder so online sind sicher mal den versucht haben bei einem der anderen server ein manifst zu ziehen. Tritt der Fehler hier auf, oder ist er geheilt sobald es geklappt hat und ein manifest ohne änderungen festgestellt wurde?

11

das ist meiner Einschätzung nach so der Fall.

12

auf welche dr beiden Möglichkeien beziehst du dich?

13

diese