Neu zu verteilende Aufgaben bei Freifunk Rhein-Neckar

[TomH]

@chrisSL

Betrieb eines Gateway-Servers auf Basis eines bestehenden Servers
[Aus meiner Erfahrung liegen Welten zwischen Installation und Betrieb eines beliebigen Servers. Da wir grundsätzlich funktionierende Infrastruktur besitzen und die aktuell primär betreut und gepatcht und nicht neu installiert oder repariert werden muss, würde ich hier zunächst einen Betriebs-Admin suchen. Ein neues Gateway zu installieren ist ein Thema, wenn man das bestehende Konzept verstanden hat.]

Also ich habe mit der auf GitHub bereitgestellten Ansible Rolle mal kurz (wirklich nur ne Stunde) probiert ein Gateway aufzusetzen, aber das hat nicht geklappt. Es ist nicht durchgelaufen und ich musste Schritte teilweise manuell machen oder noch Abhängigkeiten installieren die nicht mitinstalliert wurden und so weiter. Dann ging es und sah am Ende auch gar nicht mal so schlecht aus.
Aber mein Test Client hat sich nicht verbunden, da ich dann aber auch keine Zeit mehr hatte mir da irgendwelche Details anzuschauen ist mein aktueller Stand nur, reibungslos läuft es bei mir nicht im ersten Versuch durch.
Mein Problem dabei war aber vor allem, das ich noch keine genaue Idee dazu habe wie das alles miteinander spielt um am Ende ein funktionierendes Netzwerk dazustellen.
Was ich zum Beispiel nicht weiß ist, ob ich einfach ein anderes IPv6-Prefix nehmen kann. Das musste ich halt zum Beispiel machen, da anders als bei den v4 Adressen dieses eben global ist, ich aber natürlich keinen Zugriff auf das von ffrn verwendete habe.

@chrisSL

Dann reichen wir die Frage an @NurticVibe weiter:

@NurticVibe ist, falls du es nicht mitbekommen hast, nicht mehr hier im Forum aktiv: Rücktritt letzter Admin - #19 von NurticVibe

Und ja, es hängen aktuell alle Server, Firmware,… und sowieso alles an @NurticVibe.
Man müsste halt mal mit wirklich netten Leuten die sich vorstellen könnten in Zukunft aufgaben zu übernehmen bei ihm anklopfen, ob er nicht vielleicht bereit wäre sich mal mit diesen zusammenzusetzen um in einem persönlichen Gespräch ein paar Fragen zu beantworten. Das wäre halt schon sehr wichtig. Ansonsten könnte man aber auch mal @leah fragen ob sie bereit wäre mal eine kleine Frage-/Erklärrunde zu veranstalten. Seit ihrem Rücktritt hat sich ja nicht so viel bis vermutlich nichts an den Grundlagen verändert. Aber dadurch, das sie eben keinen Zugriff auf das ganze mehr hat, kann sie halt nichts auf den Servern zeigen.

Achso, aber diejenigen die die Gateway Wartung, Installation und dergleichen übernehmen, @chrisSL, sollten durchaus ein neues Gateway aufsetzen können und verstehen was und wie das ganze da so abläuft. So irre groß ist das aktuelle Ansible Setup überhaupt nicht. Das kann man durchaus noch nachvollziehen. Und wenn das bisher funktioniert hat heißt das ja, das im Prinzip alles drin was wie konfiguriert ist. Aber wesentlich einfacher wird die Einarbeitung natürlich, wenn diejenigen mal mit einem der Admins oder Ex-Admins reden könnte.

[wusel]

@chrisSL

gibt es Infrastruktur, auf welche Du @TomH einen Zugriff gegen kannst, die die nötige Rechenleistung und Kapzität zum Bauen der Firmware hat? Das ist aus meiner Sicht etwas, dass auf Vereins-Hardware gemacht werden sollte.

Just FTR: generell denke ich auch, daß Buildinfrastruktur eine (Finanzierung-) Aufgabe des e. V. wäre. »Für den Übergang« könnte das Bauen aber auch auf unserem Buildhost (FFGT) oder einer VM/einem Container dort (zwecks Abschottung/wegen anderer bevorzugter Umgebung) geschehen. Zur Info, ein kompletter Build schluckt ca. 62 GB, heutige Server sollte das nicht jucken, bei VMs mag das anders aussehen. Das baut mit 20 Kernen und 64 GB verfügbarem RAM direkt auf dem Blech rd. 2,5h vor sich hin, auf redundant-drehenden Rost (sprich: noch echte Platten und keine SSDs), ohne „make clean“. From scratch sind das eher so 4+ Stunden, IIRC. Wir haben früher in einer 8-vCPU-VM per Jenkins gebaut, aber zumindest bei Gluon habe ich den Eindruck, viel parallele Jobs beschleunigen den Vorgang doch spürbar, sodaß wir derzeit ohne VM- oder Container-Overhead direkt auf dem Blech bauen lassen; YMMV.

@chrisSL

Noch offen: Wer hat Interesse und die Fähigkeit für den:
Betrieb eines Gateway-Servers auf Basis eines bestehenden Servers

Ich bin ja faul; die fastd-Geschichte habe ich, basierend auf Vorarbeit von Freifunk Nord, per puppet standardisiert; für den laufenden Umstieg auf Tunneldigger kommt Ansible, basierend auf der Vorarbeit der Kollegen im Münsterland, zum Einsatz.
Das hilft nur bedingt zu verstehen, wie ein B.A.T.M.A.N.-Advanced-basiertes Netz funktioniert, aber eliminiert viele der kleinen Stolperfallen.

Die Kollegen aus Lippe haben damit recht kurzfristig eine temporäre Infrastruktur hochgezogen, das laufende Mesh dahin migriert, die alte Infra neu gemacht (Ubuntu 16.04 => 18.04) und wieder zurückgeschwenkt. Gerade bei geringer Manpower ist Automatisierung (== Wiederholbarkeit) richtig und wichtig, ich kann das Euch nur ans Herz legen.

(Falls andere Stricke reißen, kann sich Eure zukünftige Admin-Crew auch gerne mit – eher generellen, da ich die FFRN-Infra nicht weiter kenne – Fragen an mich wenden, as time permits helfe ich gerne aus.)

@TomH

Mein Problem dabei war aber vor allem, das ich noch keine genaue Idee dazu habe wie das alles miteinander spielt um am Ende ein funktionierendes Netzwerk dazustellen.

Lt. site.conf nutzt FFRN noch fastd; damit ein Client Dein Gateway connecten kann, muß jenes in der site.conf der Firmware drinstehen mit dem passenden fastd-Public-Key, dessen fastd-Secret-Key der fastd auf Deinem Gateway nutzen muß. Für einen Test brauchst Du also eine neue Firmware mit (vorzugsweise: nur) Deinem/den neuen Gateway(s) drin (und anderem V6-Setup, korrekt). Aber derlei vieleicht dann weiter in einem anderen Thread.

[leah]

Ach ja was ich vergessen habe, Ressourcen wären als VM vermutlich verfügbar. Aber wie gesagt, ich hab da schon länger nicht mehr drauf geguckt wie das Ressourcen Mäßig aussieht.