Aufgrund einer Meldung von @CyrusFox , die ich unten gleich noch anhänge ergibt es sich,
dass man alle Testkisten, die man demnaechst nicht manuell neu flashen moechte, zeitnah mal ans Netz haengen sollte, damit die auf Stand kommen sofern sie autoupdaten. Sonst halt manuell mal in der Shell autoupdater anstossen.
Edit: so oder so aehnlich wird das dann wohl zwangslaeufig auch fuer andere
Communities mit aehnlichem Tunnelbrokersetup gelten.
Wir müssen die Supernodes wegen Spectre & Meltdown auf die neuste Kernel-Version updaten. Leider beinhaltet dieser neue Kernel auch einen Bugfix welcher mit der aktuell von uns verwendeten Tunneldigger Broker bzw. Server Version inkompatibel ist. Die neuste Version des Tunneldigger Brokers kann mit alten Clients nicht mehr sprechen weil diese sich dann inkompatibel zum Kernel des Supernodes verhalten
Kurz gesagt heißt dies: Clients unter Version v1.5.5-84 werden nach dem Update nicht mehr in der Lage sein zu den Supernodes zu verbinden.
Momentan ist noch kein Datum angesetzt, da es sich aber um eine kritische Sicherheitslücke handelt sollte dies nicht weiter aufgeschoben werden.
Ein Datum für das Update wird zu einem späteren Zeitpunkt kommuniziert.
Das ist nicht ganz korrekt. Es ist immer genau ein Client in der Lage sich mit dem Supernode zu verbinden. Alle darauffolgenden Clients, die das neue Protokoll nicht beherrschen (das kann der Tunneldigger Broker erkennen), erhalten die Nachricht, dass der Broker voll ist und dass sie nicht connecten dürfen.
Theoretisch ließe sich damit die ganze Infrastruktur updaten. Halt einen Knoten nach dem Anderen
@Felix Ich denke, dass wir das im Dezember’17 ab Posting 98 in dem Serverdoku-Thread ausreichend diskutiert haben.
Und dass es nicht hilfreich ist, einer anderen Community eine „komische“ Updatestrategie zu empfehlen in ihrem Lokalbereich. (und das sage ich, obwohl ich nicht bei „Freifunk ddorf“ mitmache)
ich kann hier in dieser Sache technisch nicht den Anwalt geben (oder den forwarder), aber vielleicht schaut @CyrusFox selbst noch mal rein, bzw Du findest den EIntrag in #düsseldorf im Slack und kannst ihm selbst entgegnen…
Was ist denn dann die Bedingung, dass der naechste dran kommt ?
D.h. der Auserwaehlte connected, entschliesst sich irgendwann™ sich upzudaten, beim reboot kommt der naechste dran ? Und wenn der kein Autoupdate macht, dann bleibt die Sache stehen ? Das hoert sich nicht so robust an…
Ich hatte letzte Tage Mal die Frage in den Raum gestellt, in wie fern Spectre bzw. Meltdown für ein typisches Freifunkgateway relevant sind.
Sofern ich es verstanden habe, kann man Infos aus geschützten Speicherbereichen auslesen.
So ein Gateway hat in der Regel ohnehin nur Superuser, sei es nur root, oder mit sudo-Rechten ausgestattete Benutzer. Die können eh alles auslesen.
Einzig wenn ein Dienst gehackt wird, kommt es ggfs. zum Einsatz. An sich hat ein FF-Gateway aber keine Daten, die man nicht woanders abfischen kann.
Das ist meine naive Ansicht, würde mich interessieren, ob ich etwas übersehe.
Grüße
Matthias
PS: Werden nicht auch ältere LTS-Kernelversionen gepacht, sodass man auch eine solche weiterhin benutzen könnte? Jetzt panisch dieses Tunneldiggerupdate durchzuziehen halte ich für riskant.
Ich mache mir da eher Sorgen um Millionen von Mobilfunktelefonen, die ganz sicher keine Aktualisierungen mehr erhalten werden.
(mir fehlt hier echt der Düsseldorf-Bezug. Zumal man dort wegen der „v(x)lan“-Migration sowieso an den Updaterunden teilnehmen sollte. Sofern man nicht irgendwann in einer halb verwaisten Rest-Domaine hocken möchte.)
