Sieht gut aus, aber ich würde nur den stable branch drin lassen. Bei 40 Nodes in Meckenheim besteht sicher kaum Bedarf für so viele branches.
BTW: Die veralteten Images von Anfang 2016 sollten vom Server genomen werden. Es ist nicht sinnvoll, die noch zu installieren. Zumindest für Rheinbach brauche ich die nicht.
Sobald sie soweit sind, direkt auf dem Updateserver. Backup Meckenheim 2.6 ist gemacht - Ich wechsele aus, sobald der neue Durchlauf durch ist - hab bei Community wieder auf su-me umgestellt, der Einfachheit halber.
Kosmetische Änderung im github drin.
Mich interessiert allerdings mehr eine Rückmeldung zur stable-2.9.10 (fastd)- baue die anderen Regions auch noch - auch wenn gleiche supernodes, gleiche ports, gleiche Netze verwendet werden.
ich habe einen wr1043n v5 mit dem Image aus Index of /meckenheim/stable/sysupgrade geflasht. Der Router verbindet sich im WLAN-Mesh mit meinen Routern, der Autoupdate funktioniert allerdings nicht.
root@su-rhb-tl-wr1043n-v5-03:~# autoupdater
Downloading 'http://[2a03:2260:3017:100::2]/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://[2a03:2260:3017:100::2]/meckenheim/stable/sysupgrade
Downloading 'http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade/stable.manifest'
Connecting to fda0:747e:ab29:2241::22:80
Connection error: Connection failed
There seems to have gone something wrong downloading the manifest from http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade
Downloading 'http://firmware.freifunk-rhein-sieg.net/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://firmware.freifunk-rhein-sieg.net/meckenheim/stable/sysupgrade
Downloading 'http://firmware.ffsu/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://firmware.ffsu/meckenheim/stable/sysupgrade
No usable mirror found.
root@su-rhb-tl-wr1043n-v5-03:~#
Auch mit Anbindung über WAN-Port funktioniert das Autoupdate nicht.
root@su-rhb-tl-wr1043n-v5-03:~# autoupdater
Downloading 'http://[2a03:2260:3017:100::2]/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://[2a03:2260:3017:100::2]/meckenheim/stable/sysupgrade
Downloading 'http://firmware.ffsu/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://firmware.ffsu/meckenheim/stable/sysupgrade
Downloading 'http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade/stable.manifest'
Connecting to fda0:747e:ab29:2241::22:80
Connection error: Connection failed
There seems to have gone something wrong downloading the manifest from http://[fda0:747e:ab29:2241::22]/meckenheim/stable/sysupgrade
Downloading 'http://firmware.freifunk-rhein-sieg.net/meckenheim/stable/sysupgrade/stable.manifest'
Failed to establish connection
There seems to have gone something wrong downloading the manifest from http://firmware.freifunk-rhein-sieg.net/meckenheim/stable/sysupgrade
No usable mirror found.
Dann werdet ihr auf den Supernodes wohl mal den (lokalen) DNS reparieren (oder überhaupt mal „präparieren“ müssen.)
Zumindest kann man da solche probleme vermutlich sehr elegant lösen. (Ja, der DNS kann auch woanders laufen, und RDNS gibt’s auch noch… viele Wege nach Rom…)
Ich habe hier ein Siegburg Image aufgespielt mit Tunneldigger. Die Namensauflösung funktioniert dabei teilweise. Die Adressse firmware.ffsu kann auch dieses Image nicht auflösen, dafür funktionieren URLS aus dem Internet.
# nslookup firmware.ffsu
Server: 127.0.0.1
Address: 127.0.0.1#53
** server can't find firmware.ffsu: NXDOMAIN
** server can't find firmware.ffsu: NXDOMAIN
Ich hoffe, dass es jemanden gibt, der bei Euch die Supernodes betreut.
Faktisch müsst ihr eine Domainauflösung notfalls zerwingen. Das kann aber auch notfalls Berta Meier mit ihrem 842er… radvd einen rdns announcen, einen dnsmasq laufen lassen, der zumindest ein paar sinnvolle AAAA-Records ausspuckt, wenn die Frage nach obigen FQDNs ankommt.
(Und ja, wenn man’s falsch macht, dann kann man damit auch viel sabotieren. Aber das ist ja in Gluon-Domains immer so. Die Möglichkeiten Dinge so kaputtzumachen, dass der Durchschnitts-Handynutzende kaum noch etwas sinnvoll tun kann: nahezu unendlich.)
Jungs, es geht erstmal um die Basisfunktion der Firmware, noch nicht ums Autoupdate. Wenn die nodes produktiv mit den fastd 2.9.10 laufen, kann ich Stefan triggern, die manifests zu signieren und die IPs/configs des updateservers angehen.
Auf dem Updateserver ist auf eth2 die fda0 Adresse gesetzt, aber es läuft wohl kein fastd
eth2 Link encap:Ethernet HWaddr 00:0c:29:67:24:04
inet6 addr: fe80::20c:29ff:fe67:2404/64 Scope:Link
inet6 addr: fda0:747e:ab29:2241::22/64 Scope:Global
Die Pfade für die vhosts stimmen nicht mehr - aber das interessiert erst, wenn die Basisfunktionen der images sauber laufen. Für die Domains ist bislang noch keine Lede basierte Firmware gebaut worden - also erstmal Basics wie fastd-vpn, lan/wifi Meshing, load und evtl. Memory Leaking
Ein Schritt nach dem anderen.
und nochmal: die fastd images laufen über Wuppertal mit fastd. Die SU-Domains laufen mit Tunneldigger über eigene Domains und laufen eigenständig. Das Angebot, über die Siegburger Supernodes per tunneldigger zu gehen, wurde in der Vergangenheit nicht angenommen, sonst hätten wir bei Rhein Sieg mehr Domains mit public IP statt fda0… und würden hier nicht backport-mässig die alten fastd images auf Lede neu bauen.
Wenn die Nodes die Server in der jetzigen Konfiguration nicht finden, dann kann man nach einem Autoupdate Stefan so lange triggern, wie man lustig ist. Sie werden dann wieder in dem Zustand sein, in dem sie jetzt auch schon sind.
Es geht hier nicht darum, nachzuweisen, dass ein v2017.1.x auch dann noch zu einem stable release wird, wenn man ein paar Zeichen in der site.conf austauscht.
Es geht hier darum, eine Konfiguration zu finden, die nach einem Autoupdate der bestehenden Nodes auch weiter updates zieht, was mit dieser Konfiguration mit fastd über Wupper nicht der Fall ist.
LEDE ist mit 2017.1.x das kleinste - kein Problem. Meine Router laufen alle mit einem LEDE. Ob in der site.conf nun mck oder rhb steht, spielt eher eine untergeordnete Rolle.
Was den Umstieg auf Tunneldigger etwas kritisch macht - nicht technisch kritisch, ist, dass den Nutzern erklärt werden muss, dass es keien Verschlüsselung mehr gibt. Das ist der einzige Grund bei Umstieg auf Tunneldigger und den Supernodes zu zögern.
Du kannst aber nicht Schritt2 vor Schritt1 machen.
Wenn Du per Autoupdater eine stable-Firmware ausrollen möchtest, dann sollte zumindest klar sein, dass möglichst wenig Router auf der Strecke bleiben.
Dafür braucht es dann eben eine abzuarbeitende Checkliste.
(Oder ging es beim Start dieses Threads nur darum, eine durchaus „fertig exstierende Firmware“ zu verteilen? Wenn ja, dann hätte das evtl. klarer kommuniziert werden müssen.)
es gibt hier im Rhein-Sieg-Kreis etwa ein Dutzend Communities für die die Firmware mit angepassten site-Konfigurationen zentral gebaut werden. Manche Communities haben nur wenige Router. Von dm Dutzend sind nur noch sechs übrig geblieben. Der Rest ist - aus mir nicht bekannten Gründen - seit Februar 2017 unter den Tisch gefallen. Die Router laufen noch mit über ein Jahr alter Firmware. (Zum Glück gehe ich sein 2016 einen weitgehent eigenständigen Weg, sonst wären unsere 120 Router in Rheinbach auch verwaist.)
Meckenheim hat in der letzten Zeit einige Router ausgerollt und dabei festgestellt, dass alte Router nicht aktualisiert werden und die Firmware veraltet ist.
Aktuell ist bei anderen Communities 2.9.9 bzw .10. Wobei die 2.9.10 auf 2017.1.4 und LEDE basiert und bereits auf 248 Nodes läuft. Jetzt geht es nur darum diese auf für Meckenheim u.a. zu bauen etwas 80 alte Nodes einzufangen. Das letzte Release dieser verwaiste Router hieß stable-2.6, einige laufen noch auf 2.5 oder früher.
Da aber dereine Updateserver nicht mehr läuft oder zumindest dort keines Updates mehr ausliefert, wo die verwaisten Router sie erwarten und die stable.manifest vom Februar 2017 nicht signiert wurde, geht es jetzt darum eine aktuelle Firmware zu backen, die die Router wieder einfängt und auf neue - funktionierende - Updateserver legt.
Ob diese neue Firmware mit einem v2016.2.7 oder v2017.1.4 gebaut wird, ist egal. Aber: LEDE läuft schon auf über 300 Nodes
Wichtig ist erst mal, die Nodes wieder unter Kontrolle zu bekommen. Da könnte man gleichzeitig auf Tunneldigger schwenken, aber: Niemals an zwei Schrauben gleichzeitig drehen.
Wenn die Waisenkinder eingesammlte sind - wbbei ich dies nicht wörtlich meine - , kann man über Tunneldigger und andere Supernodes nachdenken. Und ein BATMAN Umstieg vin IV auf V kommt erst in Frage, wenn dieses Geisterrouter unter Kontrolle sind. Wobei mir im Moment nicht klar ist, wie das gehen sollte, da IV und V angeblich inkompatibel sind.