Direktes Update von Gluon 2016.2.x auf 2019.x.x möglich?

Moin zusammen,

ich stecke nicht mehr so tief in der Materie, daher nur kurz die Frage kann man von 2016.2.x (letzter commit im 2016.2.x Branch) direkt auf 2019 updaten oder muss man 2018 als Zwischenschritt durchführen? Hat das schon jemand gemacht?

Gruß
Christian

Bisher an einem Knoten aus versehen gemacht, (sogar vom 2016.2.6). Hat funktioniert. War aber auch nur ein 841. Also keine Garantie das es auf anderen Geräten auch klappt.

Nur mit relevanten Einschränkungen, mir sind zwei Probleme bekannt.

TP-Link CPE (alle Modelle); TP-Link WBS (alle Modelle):
Neues Flashlayout, benötigt Zwischenupdate.

x86 (alle)
Neue Datenträgergröße nicht unterstützt, macht VM mit zu kleinen Disks unbrauchbar.
Bei zu kleinen physikalischen Datenträgern, ich meine <64MB oder <138MB

Guter Einwand, die hatte ich nicht auf dem Schirm, danke!

Was kann man da machen? Erst auf 2018 und dann auf 2019?

Eigentlich nur austauschen. Die Layoutänderungen der anderen Nodes waren bei gleicher Flash-Größe, die x86-Images hingegen haben sich also grundlegend vergrößert.

Wie meinst du das austauschen?

Bei VM-Setups die Disk austauschen und bei Futros das Image auf der CF-Karte.
Austauschen also im Sinne von „neu machen“.

Oha also klammern wir das erstmal aus. Da muss der Aufsteller dann mitwirken…

Da die Communities zu denen ich Kontakt habe, alle Tunneldigger verwenden, gibt es keine Offloader (weil nicht notwendig).
Wir (VfN NRW e.V.) fanden es jedenfalls einfacher, die überschaubare Menge an Geräten manuell umzustellen. Hauptsächlich waren das Setups, wo Freifunk nur in vorhandene WLAN-Lösungen als zusätzliche SSID eingespeist wurden (Beispiel: http://map.rs.freifunk.net/#/de/map/00199951251a).

Tunneldigger haben wir im Moment nicht.

Wir schielen eher auf wireguard. Aber weder das eine noch das andere kann jemand bei uns bisher…

Ich auch, auch Babeld interessiert mich. Soweit ich das aber verfolgt habe, sind wir von einer Batman-Migration noch ziemlich weit entfernt.

Vom Aufwand ist Tunneldigger aber gleich bis weniger kompliziert aufzusetzen:

https://bitbucket.org/code-orange/netstack-guestgw-vm

https://bitbucket.org/code-orange/django-cdstack-tpl-guestgw

Das ist zumindest die Setup-Vorlage. Die Doku ist noch im Anfangsstadium, also wohl etwas kompliziert ans laufen zu bekommen.

Beim VfN NRW e.V. ist das so im Einsatz, dort ist Tunneldigger und parallel Fastd verfügbar. Wireguard ist in Arbeit, sobald die Implementierung in Gluon abgeschlossen / stabil ist.

Ich murmele hier einfach nochmal ansible-ffms

Ja JAAAAAAAAAAA :slight_smile:

Bei meinem Delorean ist die Batterie leer :slight_smile:

Dafür gibt’s doch die Gelben Engel? Scherz beiseite: nimm’ ein paar Mini-VMs und probier’s aus. Damit kommst Du zu einem lauffähigen L2TP-Setup, kannst gucken, wie das verdrahtet ist, und mit dem zeitabhängigen Domainswitch sollte auch so ein Schwenk von fastd auf L2TP machbar sein. (Und vom eingesparten Strom kannst Du dem Delorean eine neue Batterie kaufen ;))

Am besten die x86 Image Zeilen aus dem Manifest löschen und danach erst signieren. Damit das Update zumindest zum Download bereit steht

betrifft das x86 Problem jetzt eigentlich nur VMs, oder auch echtes Blech?

Sowohl als auch.

Also wir haben bei x86 auf Blech, also Futros, keine Probleme festgestellt. Duzende sind einfach so aktualisiert worden, da gab es keine Probleme.

Sie vergessen halt die VLANs, das kann man aber per SSH wieder konfigurieren.

VMs machen wir meist einfach neu. Das Vergrößern der Abbilder funktioniert nicht zuverlässig.

Same here; VMs gingen „spektakulär“ kaputt (hingen im virtuellen BIOS), aber echtes Blech hat es überstanden (1GB Speicherkarte).

Ok das wäre dann unkritisch. Die einzige VM im Netz betreibe ich und die ist schon auf 2019.