RE: v1 Abschaltung, Updatedateien für altes v1

[Adrian Schmutzler]

Hallo,

jetzt nochmal in Ruhe:

> -----Original Message-----
> From: franken-dev [mailto:franken-dev-bounces at freifunk.net] On Behalf Of
> Christian Dresel
> Sent: Dienstag, 27. November 2018 23:09
> To: Mailingliste franken-dev <franken-dev at freifunk.net>
> Subject: v1 Abschaltung, Updatedateien für altes v1
> 
> Hallo zusammen
> 
> wie schon auf der großen ML bekannt wurde, werde ich am Samstag alle v1
> Hoods auflösen. Folgendes wird passieren:
> 
> * Alle Hoods bis auf default werden aufgelöst

Im alten Skript wird ja auch auf die Trainstation verwiesen:
https://github.com/FreifunkFranken/VPNkeyXchange/blob/master/index.php

D.h. du solltest erst die Datei ändern, sodass sie auf die ID 1 statt der 0 verweist, und dann die Trainstation löschen. Je nachdem, wann du das machst (vor oder nach dem Löschen der normalen Hoods), fällt die Trainstation zunächst in die "alte" Default oder nicht.

> * nue2gw3 wird nach default verschoben

Auch hier kommt es auf das Timing an: Wenn du erst die Hoods löschst, und dann das Gateway verschiebst, dann sind zwischenzeitlich 500 Router auf nue1. Keine Ahnung, ob das für den Server ein Problem ist. Wenn du erst das GW verschiebst, dann löschst hat Erlenbach kurzzeitig kein Gateway.

Man sollte also "gleichzeitig" folgendes tun:
- Die Hoods löschen (zumindest die normalen, Trainstation ist extra Thema)
- die hoodid von nue2gw3 auf 1 ändern
- die hoodid von nue1 auf !=1 ändern (damit nur ein GW in der großen Hood bleibt)

> * alle readonlys werden entfert (mit Ausname vom Netmon und nue2gw3)
Router, nicht Gateways, wie besprochen

> * alle anderen v1 Gateways fliegen aus dem keyxchange (bitte dann danach
> auflösen und IPs freigeben)
erst, wenn sie sicher aus sind und nicht mehr on kommen. Lieber länger in der DB lassen, kostet nichts.
Ich werde im Lauf der Woche alle GW mit Mac-Adresse AAAAAAAAAAAA versehen. D.h. du kannst dann alles löschen, was readonly hat, aber MAC != AAAAAAAAAAAA.

> * Alfred wird auf nue2gw3 installiert und am Netmon beendet
Ja. Bitte lieber kurz keine Daten schicken als beides gleichzeitig betreiben.
Auf Kommandozeilenlänge etc. achten, sind ja deutlich mehr Daten als bei V2.

> * Vorschaltseite wird aktiviert (aktuell
> http://fff-nue2-gw3.fff.community:81/ wer Verbesserungen hat, bitte html
> Code zuschicken)
> 
> Als letzter Punkt bleibt dann noch die Updateurl die bei v1 ja
> bekanntlich fe80::ff:feee:1 ist.
Ist diese IP sicher NUR für Updates verwendet? Bitte alle noch mal nachdenken.

> Aktuell zeigt diese IP auf die Netmon VM. Das Problem ist diese VM
> wollen wir mittelfristig ja los werden.
> 
> Ich schlage daher vor, da für das sysupgradescript ja nur die aktuelle
> Firmware und nicht die ganze History bereit gehalten werden muss, die
> aktuelle Firmware auf nue2gw3 abzulegen und diese IP auch an ihn zu binden.
Ja. Aber bitte dev.* dann nicht einfach abschalten, bevor wir die alten Images "irgendwo" gesichert haben.

> Dann ist v1 netztechnisch (Layer 2, Batman wie auch immer...) komplett
> unabhängig von der Netmon VM. Die letzte Abhängigkeit ist dann nur noch
> der keyxchange den man aber extra angehen muss.
> Sollte es eine neue Firmware geben, muss ich diese halt händisch
> nachführen.

Für die paar verbliebenen V1->V2-Updates muss die FW auch nicht dauernd aktualisiert werden. Ich hab beim V1-Update auch noch ne alte FW hinterlegt.

> 
> Alternativ würde sich ein reverse Proxy anbieten, ich bin mir hier aber
> unsicher wie das von http (im Batman) zu https geht, ich habs nicht
> hinbekommen. Falls jemand lieber den reverse Proxy haben will, muss
> https://dev.freifunk-franken.de/ auch per http erreichbar gemacht werden
> (ich denke das muss man über nue1 tun wo ich kein root habe, alleine auf
> der NetmonVM scheint das nicht zu gehen ich hab da aber auch nicht den
> großen Einblick was da an den Apache VHosts gestrickt ist)

Auf nue2gw3 werfen und gut is. Das Proxy-Zeug ist nur ne zusätzliche Fehlerquelle.


> 
> Gibt es etwas, was ich nicht bedacht habe? Einwände?
> 
> Vielleicht kann man in diesem Atemzug auch gleich überlegen wo man die
> dev.freifunk-franken.de und vllt. sogar den keyxchange hosten möchte.
> Wer will sich darum kümmern? Ansprechpartner?

Es wurde ja an anderer Stelle mal diskutiert, dass man die netmon-VM mal plättet und dann neu macht. Langfristig wäre es wohl gar nicht schlecht, da den KeyXchange wieder hin zu tun. Wir bräuchten dann quasi nur eine Lösung für eine Übergangszeit, was die Wahl des Servers dafür deutlich vereinfacht.

Sollte eine VM für KeyXchange und/oder dev.* eingerichtet werden, würde ich mich hierfür als Admin (mit) anbieten und auch mit beim Umbau helfen.

Grüße

Adrian

> Auch wenn wir jetzt ein neues v2 Release anstreben brauchen wir dafür
> erstmal einen Updateserver (fd43 und im keyxchange in jede Hood
> eintragen und so...). Ich denke wir müssen das jetzt wirklich mal
> angehen, daher jetzt mal mein Aufruf da was auf die Beine zu bekommen.
> 
> mfg
> 
> Christian
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 834 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20181128/134bd121/attachment.sig>