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

vpn_mesh Parameter übernommen - habe bei den anderen Domains nur tunneldigger laufen.

Location für images/packages ist der zentrale Updateserver (siehe site.conf)

authorized keys backe ich nur für Umstellungen ein - Paketeinträge sind aber drin.

auth keys 2 stück: erster kommt beim build drauf und der zweite triggert dann später den Rollout

updated site

Mal schauen:

1 „Gefällt mir“

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.

stable-2.9.10 Meckenheim fastd im Test

1 „Gefällt mir“

Wo finde ich die Images? Dann würde ich sie auch mal auf zwei oder drei Routern installieren.

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.

@Byggvir: Check bitte mal den site_seed für Rheinbach: in v2017_1.x_Rheinbach

Die configs müssten jetzt wieder komplett und auf 2017.1.x-Stand sein im github

Status:

altenkirchen ->SU
hennef ->extern
königswinter ->config angelegt
lohmar ->SU
meckenheim ->config angelegt, baut
much → config angelegt
neunkirchen ->config angelegt
niederkassel → SU
rheinbach → config angelegt
ruppichteroth → config angelegt
sanktaugustin → SU
siegburg → SU
sozialenetze → alias
sozialenetzwerke ->SU
troisdorf → TDF,
wachtberg → config angelegt

Meckenheim stable-2.9.10 images und packages liegen auf dem Updateserver bereit zum Testen.

Firmware Downloader

oder direkt in’s Verzeichnis auf dem Update-Server

Hallo

Wir uns auf eine einheitliche Schreibweise der Branches verständigen.

Mein Vorschlag wäre statt v2017_1_x- oder v2017_1.x_ bitte v2017.1.x- zu nehmen. Gluon verwendet „.“ als Trenner.

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.

Heute Abend kann ich die Images testen.

1 „Gefällt mir“

Hallo zusammen,

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.

Namensauflösung für firmware.ffsu bzw. firmware.freifunk-rhein-sieg.net funktioniert nicht.

Server fda0:747e:ab29:2241::22

  • Antwortet nicht auf einen Ping.
  • wget ergibt: Connection error: Connection failed

Server 2a03:2260:3017:100::2

  • Ping ergibt: permission denied.
  • wget ergibt: Failed to establish connection.

Kurzfassung: Nicht brauchbar.

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…)

Kurze Frage: Wer ist „ihr“?

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.

1 „Gefällt mir“

ah, o.k. Es war mir nicht klar, was der aktuelle scope war.
Wir sind also noch in der Phase „Smoketest“, oder einen weiter „sysupgrade manuell“.

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.

1 „Gefällt mir“

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.)

Guten Abend,

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.