Ich habe doch geschrieben, dass ich die Erklärung nicht verstanden habe. War diese Aussage so schwer zu verstehen?
Der 1043n-v5 ist am 21. Januar wahrscheinlich nicht mit autoupdate installiert worden. Eine Unterstützung und funktionierendes Autoupdate für den 1043n-v5 gibt es erst seit dem 17. Januar im gluon 2017.1.4
Für die 6 RSK Domains
- Siegburg
- Lohmar
- Soziale Netze
- Sankt Augustin/Menden/Hangelar
- Altenkirchen
- Niederkassel
ist die config in bezug auf Pakete nicht aktualisiert, da die kompilierten Kernelmodule auf dem Updateserver wechselnde Positionen haben und dieser wie der Lede Packagetree eh manuell eingetragen werden muss.
Für die 6 Domains, die über die Siegburger Supernodes zu FFRL ausgeleitet werden, funktioniert autoupdate, wie man auch unschwer an den ausgerollten stable-2.9.10 updates der letzten 48 Stunden ablesen kann.
DNS funktioniert auf IPv6 des Updateservers innerhalb der Domains - die ReserveURLs sind eingebaut, um Alternativen zu haben.
Die Firmwarefiles / Packages/Module liegen physikalisch zusammen mit auf dem Updateserver von Troisdorf, der von Roman betrieben wird.
Glücklicherweise muss ich mich etwas korrigieren: Ich habe mir ein Image von Lohmar (stable 2.9.10) auf einen Router gespielt. (Per sysupgrade auf einem Router mit meiner Firmware. Das ergibt einen kleinen Mix, sollte aber nicht stören.)
In diesem Image funktioniert - im Gegensatz zu den Rheinbacher Knoten - die Namensauflösung und die Uhrzeit. Der Router ist allerdings der Router mit dem WAN-Port ans Internet angeschlossen. Zu ‚wlan mesh only‘ Nodes gibt es noch kleine Unterschiede, will ich jetzt nicht ausprobieren. Einen autoupdate konnte ich durch ändern der /lib/gluon/release erfolgreich provozieren.
Soweit ich es im Moment überblicke nutzt „lohmar“ andere Firewallregeln.
Die anderen Server: http://firmware.ffsu und http://[2a03:2260:3017:100::2] funktionieren nicht. Fehlermeldung:
- Failed to establish connection bzw.
- Connection error: Connection failed
Unter Index of /meckenheim/stable hat sich jedoch seit fast einem Jahr nichts getan.
Aber: Die 11 Nodes mit stable.2.5 müssten sich längst aktualisiert haben. Es sei denn, dort ist ein andere Updateserver drin.
Leider finde ich kein stable-2.5 mehr. Also habe ich mir ein stable 2.6 von Meckenheim auf einem 842nd v2 installiert: Als Updateserver ist [fda0:747e:ab29:2241::22] eingetragen, den es aber nicht gibt.
root@su-rhb-test-wr842ndv2-1:~# autoupdater
Connecting to [fda0:747e:ab29:2241::22] ([fda0:747e:ab29:2241::22]:80)
wget: can't connect to remote host: No route to host
There seems to have gone something wrong downloading the manifest from http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade
No usable mirror found.
Um nicht jeden Router anzufassen müsste also der Server [fda0:747e:ab29:2241::22] wieder her.
So. Schluss für heute.
Wir reden hier über Meckenheim.
Auf dem Server http://firmware.freifunk-rhein-sieg.net/ gibt es etwas mehr „Domains“ als nur 6. Alles was nicht in der obigen Liste steht, scheint verweist zu sein.
- altenkirchen
- hennef
- königswinter
- lohmar
- meckenheim
- much
- neunkirchen
- niederkassel
- rheinbach
- ruppichteroth
- sanktaugustin
- siegburg
- sozialenetze
- sozialenetzwerke
- troisdorf
- wachtberg
Unter den Waisen ist auch Meckenheim. Die Frage ist nun, wie kommt man von 2.6 oder früher auf 2.9.10?
Firmware für Meckenheim auswählen im Downloader:
Firmware Downloader Webfrontend
Troisdorf baut die meisten Firmware-Versionen ohne eigene Community - die leiten ihren Traffic dann über die Wuppertaler Supernodes aus, benutzen Fastd.
Für seine eigenen Domains baut Troisdorf die Firmware und leitet über tunneldigger auf eigene Supernodes.
Für die 6 oben gelisteten RSK-Domains bauen wir die Firmware selbst und leiten den Traffic über tunneldigger an die Siegburger Supernodes aus. Die Firmware-Versionssteigerungen bei diesen Domains ist migrationsmässig hochgezählt worden - der Sprung von openwrt zu LEDE dann mit 2.8 auf 2.9. Doku dazu in eigenen Threads hier im Forum.
Rheinbach baut auch selbst - war fastd über Wuppertal - keine Ahnung, wie jetziger Stand.
Alle nodes mit lediglich einer fda0… Ipv6 Adresse in der map deuten auf fastd und Standard Wuppertal Supernodes. - betreiben keine eigene Infrastruktur für die Ausleitung des Traffic.
Was die „Verwaisten“ Firmwares angeht muss ich leider auch passen. Mir fehlt die Zeit die Site und die Build Configs dafür neu zu erstellen. Irgendwer hat das Site Repo auf git gelöscht in dem diese ganzen Configs waren.
Entweder erklärt sich @alladin bereit diese mit zu bauen, oder die jeweiligen Communitys müssen selber bauen. Der Firmware Server auf freifunk-rhein-sieg.net steht hierfür bereit und die Images können dort dann gerne auch hochgeladen werden.
Sign-Keys habe ich auch noch also könnte ich die Firmware dann auch signieren für ein Autoupdate.
Die Nodes können sich nicht mehr aktualiseren, weil der Server weg ist.
Bevor ich mich nochmals wiederholen muss: Die Nodes können sich nicht mehr aktualiseren, weil der Server weg ist.
Dieser Vorschlag löst das Problem überhaupt nicht, denn dort sind die alten Images stable-2.6 vom 14. Februar 2017 abgelegt. Offenbar gibt es keine neueren für Meckenheim.
Jetzt weiß ich allerdings auch, warum 11 Nodes noch auf stable-2.5 sind und sich nicht aktualisiert haben. Die stable.manifest ist nicht signiert worden.
Gesucht wir eine Möglichkeit, die die 40 Meckenheimer Nodes (und noch mindestes 30 weitere im gleichen Zustand) zu aktualisieren, ohne zu jedem Node laufen zu müssen und die Firmware neu zu installieren (manuell). Turnschuh-Administration ist keine Lösung.
Einem Server die Addresse [fda0:747e:ab29:2241::22] zu geben ist noch die leichteste Übung und die Images drauf zu spielen.
Damals, Februar 2017, war nur ein Signing Key in Nutzung. Wenn ich es richtig sehe, sind jetzt zwei Unterschriften erforderlich; und ich bin mir nicht sicher, ob es die gleichen sind wie im Februar.
Benötigt wird:
- eine neue Firmware, die
- unter der Adresse [fda0:747e:ab29:2241::22]
- in der Filestruktur von Februar 2017 liegt und
- mit dem damals gültigen Schlüsseln signiert ist.
Bei den Punkten 1 bis 3 kann ich helfen. Bei 4 nicht.
BTW: Rheinbach nutzt noch fastd und hat zwei eigene Nodes als Update-Server, signiert die Manifeste selbst.
Das bauen eines Images ist noch da kleinste Problem.
Ich brauche jemanden, der das Manifest signiert.
der Update-Server auf der Adresse ist nicht weg, sondern die Anfragen landen beim default host im falschen Verzeichnis - direkt bei troisdorf statt in der Verzeichnisliste - dadurch greifen die Pfade ins Leere
Hat noch wer die Meckenheim site-configs auf der Platte liegen oder muss neu zusammengesucht werden?
Neu erstellen geht sicher schneller als suchen. Ich treffe mich am Montag mit @hbauer. Bis dahin habe ich auch einen Vorschlag für eine neue site.conf.
Das müsste ich können
1 „Gefällt mir“
wäre vielleicht der richtige Zeitpunkt, um Meckenheim von Wuppertal runterzunehmen und auf die Siegburger Supernodes mit eigener Domain aufzusetzen ? 
1 „Gefällt mir“
alter github fork Meckenheim 2016.1 conf
Mein Fork der site ist noch da 
Hab’ mal ne 2017.1.x config gebaut mit den alten Werten inkl. fastd support
site Meckenheim 2017.1.x
Das wird es vermutlich sein
Kann bitte mal jemand in einem laufenden Meckenheim Router nachschauen, ob aktuell
‚su-ff-mesh‘ oder ‚su-mck-mesh‘ als meshid verwendet wird?
su-ff-mesh
Danke - habe ich im Hauptrepo so angelegt:
RSK github tag Meckenheim 2017.1.x
Kann das mal jemand gegenchecken? Wenn’s O.K. ist, kann ich images bauen, sobald Niederkassel durchgelaufen ist.
Ich habe auch eine site angelegt und eine Mix aus der Vorlage und meiner site für Rheinbach gebaut. Zusätzliche Update Server, ssh-key und einen zusätzlichen Signing key.
Für dein Update habe ich alle branches außer stable entfernt. Probability auf 1,00 erhöht und verlange nur noch eine statt zwei Signaturen.
https://github.com/Byggvir/ffrsk-site/tree/v2017_1_x-Meckenheim
@alladin Soweit ich es gesehen habe, gibt es ein paar Syntaxänderungen in der site.conf zu beachten. Der mesh mit fastd wird seit ??? anders definiert als Anfang 2017.