Firmware-Update bereitstellen


#1

Ich möchte darum bitten ein Firmware-Update anzustoßen. @kgbvax hat eine multi-fastd Maschine stehen, die nur darauf wartet endlich mehr connections entgegen zu nehmen. Es fehlt jedoch die Informationen bei den Knoten, die diese Maschine noch nicht kennen.

Ich möchte dazu anregen das Update in Stufen auszurollen, wie wir es später beim automatisierten Umziehen der Knoten in die neuen Domänen verwenden wollen. Es ist recht unkritisch, da keine alten Zöpfe abgeschnitten werden. Und bietet daher eine gute Alternative zum von @kgbvax vorgeschlagenen Blind-Test-Update.

Ich habe im tools-Repo ein paar Listen generiert, die dazu in den Webserver eingebunden werden können: https://github.com/FreiFunkMuenster/tools/tree/master/domaenensplit_webserver_config

Diese sind noch nicht perfekt, aber zu verbessernde Punkte sind besprochen und werden noch umgesetzt. Was außerdem noch fehlt ist die Auswertung, ob die Knoten sich auch wie gewünscht updaten. Ich habe gestern noch groß angekündigt, dass ich es nicht schaffe das entsprechende Script zu bauen. Denke aber wohl, dass ich es doch machen werde. Entweder über die Weihnachtsfeiertage oder auf dem Kongress.

Das spricht jedoch nicht dagegen das Update in Wellen auszurollen (gerne um 1-2 Tage verzögert). Ich habe einen cron laufen, der mir seit einigen Monaten stündlich die nodes.json, sowie graph.json sichert daher kann der Fortschritt auch im Nachhinein zu jedem Zeitpunkt ausgewertet werden.

@Fungur hatte in diesem Post die nötige Konfiguration des nginx Webservers gezeigt: Domänabspaltung: Warendorf

@Void Wie schaut es mit dem Zugang für mich und @Fungur aus. Als ich beim letzten Mal geschaut hatte, hatte ich noch keinen.

Eine Bitte noch:
Bitte nicht wieder mit “das ist alles nicht ausgereift” oder “wir dürfen nichts übers Knie brechen” o. Ä. kommen. Es geht nichts kaputt, wir können nur das eh schon lange geplante Update nutzen, um wertvolle Daten zu bekommen, ob das Updaten in mehreren Schritten so läuft, wie wir uns das vorstellen. Daher auch 1-2 Tage warten bevor wir die nächste Stufe zünden, da wir dann auswerten können, wie lange so ein Knoten durchschnittlich braucht, bis er wirklich die Updates gezogen hat.

Außerdem sollten wir das Update recht bald ausrollen, da wie schon geschrieben dann kgbvax-3 mehr connections entgegen nehmen kann und ich auf sn-descilla-1 die fastd connections runterdrehen kann. Ich habe, wie an anderer Stelle schon geschrieben, in den ersten 16 Tagen fast 9 TB Traffic (outgoing) auf meinem Blech gehabt. Da eine VM dort als backbone-Server konfiguriert ist, wird es tendenziell auch eher mehr werden. Daher wird das mit den 20 TB inklusiv-Traffic knapp (oder teuer).


#2

@descilla @MPW @kgbvax @FanLin @Parad0x @paulinsche @Fungur
Bitte erstellt Firmware-Signaturen für die Version 191, für die Branches ‘experimental’, ‘beta’ und ‘stable’ dann ist zumindest schon mal verifiziert dass die Signaturdateien OK sind.
Ab 3 Signaturen fange ich mit der Verteilung in experimental an.

Zugriff auf den Server gibt es wie vereinbart wenn die Firmwaresignierung sauber umgesetzt wurde, also 1-3-5 Signaturen erforderlich sind.


#3

Danke für die Antwort.

Das war irgendwie an mir vorbeigegangen. :stuck_out_tongue:


#4

Bevor ich die signiere, hat die überhaupt noch jemand im Dauertest? @Alucardo hat z.B. das Paket aktualisiert, wir haben einiges an der site.conf geändert usw. Kurz gesagt, die stabile Version ist 169, bis zu 191 gab es also 22 Änderungen.

Da ich die Änderungen mitverfolgt habe, verantworte ich jetzt mal die Signierung von beta und experimentell und werde die stabile Version erst signieren, wenn wir beta getestet haben.

Mit der aktuellen Version von ecdsautil ist das Skript auch nicht kompatibel:

diff --git a/sign.sh b/sign.sh
index 5bee72c..d7866d7 100755
--- a/sign.sh
+++ b/sign.sh
@@ -54,7 +54,7 @@ awk 'BEGIN   { sep=0 }
 # Signatur erstellen und Manifest-Datei mit der neuen Signatur 
 # aktualisieren 
 
-ecdsautil sign "$upper" < "$SECRET" >> "$lower"
+ecdsasign "$upper" < "$SECRET" >> "$lower"
 (
        cat  "$upper"
        echo ---

Und ich habe keine Schreibrechte auf das Repo:

ERROR: Permission to FreiFunkMuenster/manifest-ffms.git denied to MPW1412.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Grüße
Matthias


#5

@MPW Zugriffsrechte sind gefixt


#6

Wie genau muss ich vorgehen?


#7

#8

@VOID scheinbar hast du mich vergessen :frowning:
Bitte schalte mich auch für das Repo frei. Danke


#9

@FanLin fehlt auch.


#10

Was muss denn noch unternommen werden, damit die Firmware für die einzelnen Domänen ebenfalls gebaut wird und dann hier landet: https://freifunk-muensterland.de/site-ffms/ ?


#11

Es sind jetzt fünf Signaturen drunter, ich würde vorschlagen, dass @void das jetzt schon mal für experimental freischaltet.


#12

Macht es beim ersten Mal doch zunächst einmal alle, um das System gut zu starten.


#13

@void soweit ich sehen kann habe ich noch immer keinen Zugriff :disappointed_relieved:


#14

Bist jetzt auch Firmware Entwickler, hast also zugriff.


#15

Danke @Sandzwerg
Signieren klappt. Exp. und stable sind jetzt auch von mir signiert.


#16

Beim Ausführen des Scripts erhalte ich ein “permisssion denied error 403” um die Ohren"". Muß ich auch noch Entwickler werden? @Sandzwerg


#17

Ja, bist du nun. Alternativ: Neue Gruppe nur für das Repo?


#18

Hiermit bitte ich darum zeitnah Zugriff auf den Firmware-Server zu bekommen, auch wenn die Firmwaresignierung noch nicht in Gänze implementiert ist. Der Grund ist, dass es sich in meinem Augen recht schwer gestaltet ein Konzept für eine Blackbox zu entwickeln. Ich möchte mich gerne auf dem Firmwareserver umschauen, um die Vorbereitungen für den automatisierten Umzug fortführen zu können. Ich verspreche, dass ich keine Änderungen oder Eingriffe am Server vornehmen werde(, solange ich dazu nicht vom Adminteam beauftragt werde).

Im Admin-Team hat imho jeder denselben Level-of-Trust. Verschieden ist die Erfahrung die ein jeder mitbringt. Außerdem gibt es verschiedene Ansichten zum Thema “zu viele Köche verderben den Brei”. Da ich jedoch die Absicht erklärt habe, keine Änderungen am Server vorzunehmen und auch noch nicht zu viele Köche in der Küche sind (derzeit nur @void, so weit ich weiß), bitte ich darum diesem Vorschlag nachzukommen und mir (oder einem anderen, der sich mit den Umzugs-Mechanismen beschäftigt) Zugang zum Firmwareserver zu gewähren.


#19

@descilla hört sich für mich logisch und gut an. Von daher unterstütze ich deinen Wunsch.


#20

Du brauchst keinen Root-Zugang, oder?