Autoupdater in unterschiedlichen Rhein-Sieg-Domains (was: Frage zu Autoupdate)


#62

Status Firmware Rhein-Sieg auf dem Updateserver

altenkirchen td SU -> produktiv
hennef fastd eigener Updateserver ->produktiv
königswinter fastd config SU -> Test
lohmar td SU -> produktiv
meckenheim fastd config SU ->Test
much fastd config SU -> Test
neunkirchen fast config SU -> Test
niederkassel td SU -> produktiv
rheinbach fastd config - -> Test
ruppichteroth fast config SU -> Test
sanktaugustin td SU -> produktiv
siegburg td SU -> produktiv
sozialenetzwerke td SU -> produktiv
troisdorf td extern -> produktiv
wachtberg fastd config SU -> Test

Ich habe Roman aus Troisdorf angetickert, die connectivity des Updateservers an das fda0-Netz Wuppertal wieder herzustellen, wenn er die Zeit dazu findet.

Sobald das erfolgt ist, kann Stefan aus Troisdorf angetickert werden, die Manifeste für das Rollout zu signieren.

Königswinter, Meckenheim, Much, Neunkirchen, Rheinbach, Ruppichteroth und Wachtberg haben jetzt neue fastd-Firmware,auf LEDE-Basis, die sich noch an die FF-Wuppertal Supernodes anbindet. Damit werden auch die neueren Routermodelle unterstützt. Die Gruppen betreiben keine eigene Infrastruktur zur Trafficausleitung und in der Vergangenheit keine Beteiligung am Aufbau einer solchen. Troisdorf und Siegburg haben sich zur Ausleitung mit tunneldigger entschlossen - die nodes haben eigene public IPv6 der jeweiligen Domains (siehe Doku Thread zu Rhein-Sieg Firmware mit den pdf’s). Das Angebot, sich technisch anzuschliessen, wurde nicht angenommen, eigene Infrastruktur für autonomen Betrieb der Netze jedoch nicht aufgebaut
Alle oben genannten Communities verwenden noch die Netzkonfiguration aus der Aufbauzeit in ein und derselben Domain.
Wäre vielleicht mal Gelegenheit, sich bei Stefan aus Troisdorf für seine Arbeit in der Vergangenheit zu bedanken, die er da reingesteckt hat - davon habe ich jedoch hier in den Threads bislang nicht viel gelesen.


#63

Allen die hier mitwirken - bekannter und unbekannter weise - meinen Dank.

Das Angebot aus Toisdorf und Siegburg, sich anzuschließen muss mir entgangen sein.

Aber: Ich war gerade so weit, dass ich den fastd im Griff hatte und einen eigenen Server hätte damit aufsetzen können. Alles was dahinter liegt, hätte dann wieder einiges lernen und testen benötigt. Mir fehlt darüber hinaus noch ein Sponsor. Just in dem Moment wird ein neues Schwein durchs Dorf getrieben: Tunneldigger. Damit war mein Aufwand mit fastd obsolet. Und Zeit mich mit dem Tunneldigger und einer eigenen Infrastruktur auseinander zusetzen habe ich im Moment nicht.

Genauso wie Roman aus Troisdorf muss auch der Thomas aus Rheinbach Zeit finden.


#64

Connectivity für den Updateserver sollte wieder hergestellt sein. apache vhost überarbeitet für fda0:747e:ab29:2241::22
Wenn Stefan noch signiert, kann die stable-2.9.10fastd ausrollen.


#65

Der Server ist von den Nodes wieder erreichbar. Leider fehlt noch die Signatur der stable.manifest durch @stefan. Da im 2.6 nur seiner Signatur hinterlegt war, läuft es auch nur an, wenn er signiert hat.


#66

Hab vorhin im Slack von Stefan die Meldung bekommen, dass er die 2.9.10-stable fastd Versionen signiert hat.


#67

super, das ist ja klasse das wir jetzt die etwas älteren Firmware Router ohne Turnschuhe wieder nachholen können. Vielen Dank. Damit habt Ihr uns richtig Arbeit gespart

Und es sind auch schon alle die Treppe raufgefallen in Meckenheim


#68

Hier nochmal die Doku zu den eingebackenen Firmwarefunktionen:
Checkmesh
● CheckGW
● Nightswitch
● Ssidchanger
● speedlimit
● Blockmesh
● robinson

20171101_ff_rsk_firmware.pdf (1,2 MB)

PS: bei check-client-mesh immer als Wert node -1 nehmen. Bei nur einer Clientnode also 0 setzen.


#69

Mein Test-Router mit der alten Meckenheim Firmware 2.6 hat sich bereits aktualisiert. Dürfte recht schnell gehen, auch wenn die alte Software noch den älteren Update-Mechanismus haben könnte.


#70

Königswinter+Meckenheim stable 2.9.11 fastd liegen zum manuellen Testen auf dem Updateserver


#71

@Byggvir bitte teste auch immer die neuen Firmwares die @alladin backt, weil manchmal auch da Fehler für eine Community drin sind und dann besser nochmal getestet werden bevor sie signiert werden.


#72

Hallo, ich habe die Firmware auf einem 1043n v4 (ohne WAN) und 842nd v2 (mit WAN) installiert. Sieht alles sauber aus.

Der autoupdater erreicht aber nur den fda0:747e:ab29:2241::22 dort fehlen noch Signaturen. (Images von http://images.freifunk-rhein-sieg.net/)

BTW: Meine 842 stürzen gerne ab, wenn ich Images mit scp auf den Router nach /tmp/ kopiere. Meist brauche ich zwei Anläufe.


#73

Die FW wurde ja auch noch nicht signiert.


#74

Ich habe selbst eine Testinstallation auf einem 1043nv5 gemacht (community-strings Rheinbach), mit client gecheckt, ist in der Map aufgetaucht…

Gerade die fastd stable 2.9.11 auf dem updateserver signiert für:
Königswinter, , Meckenheim, Much, Neunkirchen, Rheinbach, Ruppichteroth und Wachtberg


#75

nodeupdates gehen am einfachsten per ssh im Router.
cd /tmp
wget http:// linkzumfirmwareupdatefile
sysupgrade firmwareupdatefile


#76

Also in Meckenheim sieht es gut aus.


#77

Mit wget ist es bei den 842nd v2 auch nicht stabiler. Wenn die Datei vollständig herunter geladen ist, bootet der Router gerne und das Spiel geht von vofne los.


#78

Das hatte ich mit den TDF Images auch schon.
Der Autoupdater lief dann aber problemlos durch.
Ich glaube der räumt vorher einiges an Speicher leer.


#79

Ich habe noch ein paar alte Fehler gefunden:

  • Die Uhrzeit stimmt nicht. Dies liegt daran, dass die Adressen der NTP_Server nicht aufgelöst werden können. Dies wird auch in allen rsk Anpassungen der Fall sein, die im Script zu Beginn versuchen die Uhrzeit zu aktualisieren.

Es sollte ein Zeitserver im FF-Netz installiert werden und die IPv6 Adresse diese Servers in der site.conf eingetragen werden. Dies funktioniert unabhängig von anderen Rahmenbedingungen.

  • http://[2a03:2260:3017:100::2] ist bei mir nicht erreichbar.
  • autoupdater -f läuft über http://[fda0:747e:ab29:2241::22]

#80

Statt in den fda0 Aufbaunetzen Behelfsstrukturen aufzubauen, macht eine Migration in eigene Domains mit Public IPv6 mehr Sinn. So wie zuletzt für Altenkirchen und Niederkassel bereits umgesetzt.
Der Bau der fastd Firmware mit Anbindung an die Wuppertaler Supernodes sollte in der Hauptsache die Verwendung neuer Routerhardware ermöglichen.
Die configs sind also jetzt schon darauf abgestellt, eine Migration zu tunneldigger mit eigener Traffic-Ausleitung zu FFRL anzugehen.
Die jetztige Struktur erlaubt kein Wachstum - die Communities Königswinter, Meckenheim, Much, Neunkirchen, Rheinbach, Ruppichteroth und Wachtberg liegen alle in ein und demselben Netzsegment.


#81

Ein eigener Zeitserver ist keine Behelfsstruktur, sondern in größeren Netzen eine Selbstverständlichkeit. Es ist wenig sinnvoll diesen Traffic auf öffentliche Zeitserver zu lenken.

Selbst wenn es nur um die Verwendung neuer Routerhardware geht, funktionieren sollte es trotzdem.

Die kleinen Communities müssten erstmal Leute haben, die dies aufsetzen können.