Fortsetzung der Diskussion von Knoten lokal mit Software einer anderen Lokalen Vereinigung betreiben:
@pberndro @anon88999732: Können wir die o.g. images auf die ffe/firmware Seite bringen?
Oder fehlt es an Qualitätschecks, bevor man die builds offiziell hochlädt?
Nein, die müssen schon selbst gebaut werden. Außerdem wird IBSS in Gluon 2019 eingestellt.
Damit sinnvoll neue Firmware rausgebracht werden kann, muss zuerst geprüft werden, ob noch alles funktioniert, dann muss eine aktuelle Gluon-Firmware ohne Domainconfig gebaut werden und alle Router darauf geupdatet. Dann wird eine Gluon-Firmware mit zwei Domänen ausgeliefert und dem scheduled domain switch, damit man auf 802.11s wechseln kann. Und wenn dann noch alles funktioniert, müssen die Router mit dem Geolocator in einzelne Domains gesplittet werden und auf den Supernodes mehrere fastd-Instanzen eingebaut werden. Ansonsten ist das Netz so oder so zu nichts mehr zu gebrauchen.
Da hat der Laie dann doch eine deutlich vereinfachte Vorstellung… Danke für die Aufklärung!
Es wurde einfach zu lange nichts gemacht. Der Grund war, dass es Probleme mit dem zu kleinen Speicher einiger Geräte gibt. Wir hätten trotzdem neue Firmware ausliefern sollen, denn es sieht so aus, als würde gerade das Betreiben von alter Firmware zusammen mit neuer Firmware noch größere Probleme verursachen. Und mittlerweile ist der kleine Speicher so kritisch, dass man nicht mehr 400 Nodes in einem Batman-Netz betreiben kann. Deshalb muss es in mehrere Netze gesplittet werden. Und da Freifunk Essen nur zwei Supernodes oder so hat, müssen auf den Supernodes mehrere fastd-Instanzen laufen. Erschwerend kommt hinzu, dass einige Router hinter Firewalls aufgestellt wurden, die nur über Port 10000 mit den Supernodes kommunizieren dürfen. Die werden aus dem Netz fliegen, weil die fastd-Instanzen nicht alle auf dem gleichen Port laufen können.
Wegen dem Speicherproblem habe ich einen Artikel in der c’t veröffentlicht.Organspende | c't | heise magazine
Dann sollten wir jetzt einmal zusammen (!!!) eine neue Strategie entwickeln.
Wer nimmt denn an den monatlichen Treffen teil und kann uns Feedback geben?
Dann braucht Freifunk Essen erst einmal einen neuen Firmwarebäcker (der sich auch mal auf den Treffen blicken lässt). Wer ist dazu bereit?
Ich greife bei dem Übergangsprozess gerne unter die Arme.
Mit dem Treffen ist das so eine Sache…
Ich habe mal einen CI Build aufgesetzt:
Ich kanne mich mit dem Build nicht so aus, aber ich habe jetzt mal auf Verdacht ein paar Build Artifacts gesammelt: https://git-lab.de/gluon/build/-/jobs/2561/artifacts/browse
Kann mir jemand sagen, ob das Build Ergebnis ausreichen ist?
Theoretisch lässt sich das auch auf alle Build Targets erweitern.
Und man könnte die bisherigen Versionen damit einmalig bauen.
Gibt es eine Stelle, wo man fertige Build Resultate auslagern könnte?
@phaus Das Bauen ist nicht das Problem, sondern das Maintainen und Testen der Firmwares. Aktuell muss für Essen folgendes gemacht werden:
Einer der Gründe, wieso keine Updates gemacht wurden, war, dass es erhebliche Load-Probleme mit neuerer Firmware gab, da die Speicherauslastung größer wurde und die Domäne viel zu groß war. Da aber mittlerweile so viele Router weggestorben sind, ist das Problem vielleicht nicht mehr aktuell.
Das hört sich ja wie ein kompletter Neuanfang an.
Ich habe mich mal bei Chris Fiege von Freifunk Braunschweig gemeldet.
Er hatte vor einiger Zeit einen Blogpost über ein Testsetup geschrieben (Für alle, die den Post nicht kennen Freifunk CI - Stratum 0 ).
Wäre zumindest ein Schritt in Richtung testbarkeit von Releases.
Ich kann mir vorstellen, dass der Build nur ein kleinerer Teil ist. Allerdings halt auch ein Teil, der > 1h an Wartezeit bedeutet. Ein erster Schritt für sinnvolle Releases ist halt das schnelle bauen von einer Testfirmware ;-).
Ich bin aber für jeden Input dankbar. Ich komme zwar aus einer CI/CD Welt, aber das testen von HW Fimware Images ist definitiv etwas neues für mich 
Ich sehe bei dem vorgestellten Testbed keines der realen Probleme gelöst.
Solang es um gluon-releases mit maximal ein paar einfachen Community-Anbauten geht:
Mehr ist es nicht in der Praxis. Zumindest hier hat das in den letzten 5 Jahren in mehreren Communities völlig ausgereicht.
Oder anders: In einer Community in der es seit Jahren(?) keine frische Firmware gibt mit einem CI-HW-Testbed zu kontern: Kann man natürlich machen, wenn man Spass dran hat. Klingt aber nach Schritt 3 vor Schritt 1.
(Gna, warst schneller, dann häng’ ich mich einfach mal hier dran 
)
Second that. Die Firmware via Jenkins o. ä. nach jedem git push automatisiert zu bauen: kann man machen (been there, did that), zielführender ist aber IMHO ein anderer Trigger, um nicht für jeden Übersetzungschange einen 2h-Compilerlauf zu starten.
Die resultierende FW kann man dann entweder automatisiert von Testknoten ziehen lassen (latent eher keine gute Idee, schon ob der Flash-Lebensdauer) oder gezielt manuell in einen Kanal pushen, in dem das eine Handvoll unwichtige aber observierte Knoten tun (»rawhide« bei uns, wobei das tatsächlich das ungetestete Kompilat ist — einfach restaurierbare Knoten sind hier klar zu bevorzugen ).
An denen dann gucken, ob noch alles tut, was tun sollte (Grundfunktion, Status-Seite, ggf. sysupgrade via Mesh). Dann anhand einer Gluon-VM ggf. den Setupmode durchspielen, je nach Änderungen auch an einem realen Knoten (841/4020). Wenn keine Leichen unter den Teppich zu kehren sind: Kandidat für »experimental« (mehrere Knoten im Feld, auf die andere aktive Freifunker ein Auge haben und Anomalien berichten).
Ich hätte noch nichtmal Angst um den Flash eines 841ers (oder meinetwegen ArcherC5), ich weiss inzwischen, dass ich sie auch bei mehr als 900 sysupgrades nicht kaputtbekomme.
Eine automatische Deploy-Chain nach jedem Commit im Gluon inkl. passender Buildbot-Signaturen für das Sysupgrade wäre hier auch nur eine Fingerübung.
Ich sehe nur keinen Sinn darin.
Es ist nur wirklich müßig, so etwas zu tun, denn als Community hilft die gewonnene Erkenntnis „baut nimmer“ oder „läuft nimmer“ kaum weiter.
Weil man seitens der Gluon-Entwickler mit an Sicherheit grenzender Wahrscheinlichkeit ein „Dann bau erstmal ohne Anbauten, nur mit Plain-Gluon“ zurückbekommt.
Man könnte natürlich noch ein CI-Testbed für Plain-Gluon bauen. Aber das das ist zumindest hier lokal nicht Scope der Community, mangels Vernetzung mit den Gluon-Leuten auf den passenden Kanälen.
Sprich: Auch für Essen würde ich schlicht davon abraten, wegen der vertanen (CPU-)Zeit auf der Buildmaschine.
Wenn jemand wirklich so ein Testbed bauen möchte, dann wäre es sinnvoller, sich direkt im Gluon-Projekt damit einzubringen.
Solang es um gluon-releases mit maximal ein paar einfachen Community-Anbauten geht:
- Smoketest und Setup-Validierung (Configmode-Texte) in einer x64-vm, validierung von sysupgrade.
- smoketest auf maximal einem singleband und einem dualband Gerät und schauen ob Wifimesh funktioniert, dann evtl. noch ntp und sysupgrade auf einem wifimesh-only-Node.
Wie sehen solche Smoke Tests denn aus?
Was davon lässt sich in einer VM realisieren und was davon geht nur per Hardware?
Second that. Die Firmware via Jenkins o. ä. nach jedem
git pushautomatisiert zu bauen: kann man machen (been there, did that), zielführender ist aber IMHO ein anderer Trigger, um nicht für jeden Übersetzungschange einen 2h-Compilerlauf zu starten.
Davon habe ich auch nichts geschrieben. Es ist mittlerweile ganz gut machbar, dass z.B. nur bestimmte Branches oder einfach nur Tags komplett gebaut und deployed werden.
Es hängt halt ein wenig von den Anforderungen ab. Die versuche ich gerade herauszufinden ;-).
Die resultierende FW kann man dann entweder automatisiert von Testknoten ziehen lassen (latent eher keine gute Idee, schon ob der Flash-Lebensdauer) oder gezielt manuell in einen Kanal pushen, in dem das eine Handvoll unwichtige aber observierte Knoten tun (»rawhide« bei uns, wobei das tatsächlich das ungetestete Kompilat ist — einfach restaurierbare Knoten sind hier klar zu bevorzugen
Gibt es zu diesem Vorgang etwas an Dokumentation? Oder mal einen groben Ablauf wie man das selbst mal ausprobieren kann?
Generell: Wo sind die hauptsächlichen Painpoints. Wenn es die Buildzeit nun nicht ist…
An denen dann gucken, ob noch alles tut, was tun sollte (Grundfunktion, Status-Seite, ggf. sysupgrade via Mesh). Dann anhand einer Gluon-VM ggf. den Setupmode durchspielen, je nach Änderungen auch an einem realen Knoten (841/4020).
Danke. Das hilft schon mal. Da gucke ich jetzt mal weiter.
Wenn keine Leichen unter den Teppich zu kehren sind: Kandidat für »experimental« (mehrere Knoten im Feld, auf die andere aktive Freifunker ein Auge haben und Anomalien berichten).
Das wäre IMHO der zweite Schritt. Dazu bräuchte es halt auch einen geeigneten Test Kanal - also wo überhaupt neue Firmwares verteilt werden können. Oder gibt es soetwas schon?
Wie von Wusel beschrieben:
Ein paar Knoten, auf einem eigenen Release-Kanal mit einem Namen, der Neugierige abschreckt. z.B. „BROKEN“.
Die Geräte mit Zugriff „in Armlänge“ (sorgt dafür, dass man den nie braucht).
Die Geräte bekommen den Build samt minimum-Signatur in ihren download-Folder des update-Servers und müssen sich das vollautomatisch ziehen.
Und nach 2 Tagen schaut man mal, ob die a) die FW geholt haben und b) ob sie nicht verschwunden sind. Und wenn doch, dann schaut man mal bei der VM was als letztes auf der Console steht.
Und wenn alles o.k. dann forced man mal Setupmode. Oder man sagt mal auf der Shell „firstboot“, um zu schauen, ob die auch als FreshInstall mit sinnvollen Werten hochkommen. Auf einer VM macht’s meist mehr spass, weil man da das Image per shellscript tauschen kann für solche Versuche.
Deswegen haben wir bei FFMUC drei Releasezweige. Experimental für alle die ihre Router selber wieder zum Laufen bekommen, welcher eine Signatur benötigt und direkt vom Buildserver kommt.
Dann testing und stable.
Der Zaunpfahl war hier leider nicht deutlich genug.
Haufenweise haben Leute die Experimental installiert, „weil es ja die neuste ist“. Mit dem Effekt, dass es dann böses Blut gab, jedes Mal wenn die von Hand eingreifen mussten, weil z.B. die Knoten nach dem autoupdater im Setup-Mode glandet sind…
Will sagen: Der Experimental-Zweig MUSS einen abschreckenden Namen haben. „BROKEN“ oder „WACKELIG“…
Deswegen haben wir die Erklärung und auf der Firmwareseite muss man es extra bestätigen.
Hätte ja gerne direkt geantwortet, aber aus dem UM-Netz ist das Forum gerade nicht erreichbar?
wusel@luggage:~$ traceroute forum.freifunk.net
traceroute to forum.freifunk.net (185.66.195.242), 30 hops max, 60 byte packets
[…]
4 81.210.137.136 (81.210.137.136) 18.746 ms 19.081 ms 19.016 ms
5 de-bfe18a-rd02-ae0-0.aorta.net (84.116.191.146) 23.560 ms 23.888 ms 23.870 ms
6 de-fra01b-rc1-ae65-0.aorta.net (84.116.191.125) 24.708 ms 22.412 ms 22.284 ms
7 de-fra03b-ri1-ae10-0.aorta.net (84.116.132.178) 19.306 ms 21.314 ms 20.725 ms
8 213.46.179.50.aorta.net (213.46.179.50) 19.343 ms 22.093 ms 20.539 ms
9 * * *
10 * * *
11 * * *
[…]
Somit also per Mail:
»Es hängt halt ein wenig von den Anforderungen ab. Die versuche ich gerade herauszufinden ;-).«
Ja, viele Wege führen nach Rom; ich hab’ einfach ein Script, welches den ganzen Kladderadatsch durchbaut und gut. Initial hatte ich nur 841 + VM gebaut (spart ja doch einiges an Zeit und Platz), mittlerweile fällt aus einem Build i. d. R. komplett alles raus.
»Gibt es zu diesem Vorgang etwas an Dokumentation? Oder mal einen groben Ablauf wie man das selbst mal ausprobieren kann?«
Es wird gebaut, und dann die Manifeste für „rawhide“ bis „stable“ angelegt und vorsigniert; per „promote.sh“-Skript wandert ggf. ein Build von Stufe X nach Stufe X+1 („rawhide“ → „experimental“ → „testing“ → „stable“; parallel dazu gibt’s derzeit noch „tng“, bei dem in der site.conf per sed die Batman-Version auf v15 gesetzt und fastd durch Tunneldigger ersetzt wird: das Setup, auf welches wir „demnächst“ schwenken wollen.)
Alle Autoupdate-Zweige sind Autoupdate-fähig, sodaß es Geräte im Netz gibt, die auf „rawhide“ stehen und sich ggf. binnen weniger Stunden automatisch auf den neuesten Build aktualisieren (das testet das Autoupdate-Procedere automagisch mit, birgt aber auch ein hohes Risiko des Brickens). Sprich: alles Gluon-Bordmittel soweit
»Generell: Wo sind die hauptsächlichen Painpoints. Wenn es die Buildzeit nun nicht ist…«
Umständlich für mich ist das Testen des Setup-Modes; grundlegender Test kann per VM erfolgen, für alles mit WLAN braucht’s aber dann doch einen echten Knoten, zudem muß im Nachgang auch die jeweilige Funktion getestet werden (Privates Netz; WiFi-Mesh an/aus; …).
»Das wäre IMHO der zweite Schritt. Dazu bräuchte es halt auch einen geeigneten Test Kanal - also wo überhaupt neue Firmwares verteilt werden können. Oder gibt es soetwas schon?«
Siehe oben, »experimental« ist quasi der Alphatest-Kanal (FW konnte auf mind. 1 Gerät erfolgreich geflasht werden, wohl kein Totalausfall), »testing« der Betatest-Kanal (FW hat mehrere Geräte nicht gebrickt, also mal in (semi-)produktivem Umfeld ausprobieren; vorzugsweise werden hier auch Speizialfeatures (Nachtabschaltung, Config-Override, …) benutzt und von den Betreibern überwacht).
Nach $variabler_Zeit in »testing« entscheidet dann ein Gruppen-Bauchgefühl, ob die Firmware nach „stable“ geschoben wird, wo das Netz sich i. d. R. binnen 24h dann drauf aktualisiert.
Wie gesagt, $hier wird nicht nach Releases neu gebaut; die getesteten Binaries werden durch die Unterverzeichnisse des Firmwareservers „nach oben“ (stable) geschoben, das jeweilige Manifest, was ja auch schon zur Bauzeit erstellt wurde, dabei auch nur umbenannt und den Erfordernissen entsprechend signiert. Damit heißen unsere „stable“-Firmwares so nur auf dem Firmware-Server, aber irgendwas ist ja immer. In einer separaten Datei werden die benutzten Hashes der Repos gespeichert, sodaß ein rebuild einer bestimmten Version prinzipiell möglich wäre (GPL und so); es käme aber wegen anderem Buildhost und anderen Zeiten kein binär identisches Image raus.
Works for us HTH,
-kai