Neu zu verteilende Aufgaben bei Freifunk Rhein-Neckar

Ich ziehe meine Antworten auf Beiträge im anderen Thread mal hier hin.

Ich kann nur für mich sagen, daß „Routing auf Layer 2“ (Batman-Advanced aka batman_adv.ko) eine neue Erfahrung war. Und die Wechselwirkungen Gateway-Mode <> DHCP-Paket-Behandlung noch immer nicht „schmecken“. Und die ebtables-Filterung bei L2TP mich nachts schlecht träumen läßt … Aber klar, YMMV.

AFAIK kommt FFRN derzeit ohne Backbone aus; die Gateways/Supernodes/Exits stehen bei Hetzner und leiten direkt auf Hetzner-IPs aus?

Auch das kann man im Grunde heute (Störerhaftung ist an sich vom Tisch) anders lösen; aber @Cheatha wollte wohl eher darauf hinaus, daß ohne Finanzierung es keine (und sei es virtuelle) Hardware für Gateways oder sonstwas gibt, ohne Vereinsaktivitäten gem. Satzung mittelfristig auch keinen nicht-gemeinnützigen Verein mehr und ohne jegliche Aktivitäten mit Außenwirkung auch keine neuen Vereinsmitglieder (deren Beiträge ab 2020, Stand jetzt, erstmal die Infrastruktur tragen müßten) — oder sowas in der Art.

Natürlich macht es Sinn, sich in die technische Thematik einzuarbeiten, um für den Jahres-, und in gewissem Maße Zeiten-, Wechsel gewappnet zu sein. Aber bitte auch dies nicht aus den Augen verlieren: alle Mittel des FFRN e. V. verliert dieser nach aktuellem Stand am 31.12.2019, 24:00. Für die Zeit nach dem 01.01.2020, 00:00, muß man rechtzeitig Mittel außerhalb des FFRN e. V. aufbauen und irgendwann Anfang bis Mitte Dezember auf die daraus bezahlte neue Infrastruktur schwenken — wobei Hetzner ja nicht direkt abschaltet, also ggf. kann man das auch mit dem alten Setup weiterfahren, wenn am 01.01.2020 eine Spende eingeht und die Zahlungsunfähigkeit heilt.

Wie auch immer, neben technischen sind auch, vor allem, organisatorische Hürden zu nehmen — und ein Admin-Team durch ein mit anderen Personen besetztes Admin-Team zu ersetzen, sieht aus der Ferne nicht so sehr nach der allumfassenden Lösung aller Probleme aus.

2 „Gefällt mir“

Mit Backbone meine ich die ganzen Services, die Freifunk am Laufen halten, werden ja im Moment quasi in Personalunion administriert.

Dafuer gibt es aus meiner Sicht im Moment wieder zu viele Abmahnungen und Urteile bzgl. Elternhaftung, Haftung fuer Mitbewohner, Freunde von Kindern…
Liegt die Abmahnung erstmal im Briefkasten reicht es nicht einfach die Fuesse still zu halten und sich dann spaeter auf die abgeschaffte Stoererhaftung zu berufen, das wird teuer werden.

Allumfassende Loesung kann ja an verscheidenen Enden anfangen und bzgl. Vereinsgruendung, Satzungsaenderung…hoffe ich, dass der Vorstand irgednwie aktiv wird - hier im Forum ja bisher auch eher weniger.

Jeder sucht sich ja die Themengebiete aus, die ihn interessieren. Ich interessiere mich nicht fuer Treffen, Hackerspaces usw. usf. - davon hab ich beruflich schon genuegend.
Ich gehe aber davon aus, dass wenn hier im Forum keine Kommunikation stattfindet, nichts zu retten ist.
Es wird hier kaum kommuniziert und wenn ich meine Interessengebiete anspreche wird immer wieder darauf hingewiesen, dass diese ja nicht das Problem waeren. Das mag stimmen, muss ich aber nicht dauernd lesen, weil mir die anderen Dinge nicht am Herzen liegen. Ideal waere ja, wenn sich fuer alle Themengebiete jemand findet, die einen wollen lieber gemeinsam 841er mit mehr RAM und Flash aufruesten, die anderen von zuhause aus irgendwas machen.

.

Aus meiner Sicht sind drei Punkte wichtig

  1. Admins, die bereit sind, den Basisbetrieb aufrecht zu erhalten
  2. Eine Finanzierung in irgendeiner Form (Verein, Spenden, etc.)
  3. Ein Konzept was FFRN überhaupt ist (Verantwortung des Vorstands, wer entscheidet was, welche Bereiche/Themen sind relevant, etc.

In allen drei Bereichen gibt es Handlungsbedarf. Wir sollten sie aber nicht ständig vermischen - das macht es komplizierter und schreckt Unterstützer ab. Ausserdem wird viel zu viel diskutiert und zu wenig gehandelt. Vorstand oder Alt-Admins sollten Thema für Thema gezielt nach Personen suchen - ich kann doch schlecht eine Spendenkampangne bei leetchi für die ggf. erforderliche Nachfolgeorganisation des FFRN starten. Klar - das kann ich, aber ich habe keinen Auftrag.

Also: BITTE KONKRETE AUFTRÄGE AUSSPRECHEN UND GGF. PERSONEN ANSPRECHEN, DIE ETWAS ÜBERNEHMEN SOLLEN.

Beispiel: Wir brauchen jemanden, der xy macht

Hat in der Vergangenheit leider nicht geklappt, wenn sie als Unterstützungsanfrage formuliert waren. Jemanden direkt ansprechen möchte ich nicht, das ist immer ein gewisses Druckmittel. Für ein Projekt, das uns allen in unserer Freizeit Spaß machen soll, finde ich das unangemessen. Ich persönlich möchte in meiner Freizeit nicht auch Teil einer Hierarchie sein und von Leuten Dinge gesagt bekommen, die ich zu erledigen habe. Das hab ich im Job schon genug. Wir breiteten hier immer wieder Aufgaben aus und baten darum, dass sich diesen jemand annimmt. Hat in der Vergangenheit leider auch nicht gut geklappt. Aber das ist, für mich, die einzig gangbare Methode ein Freizeitprojekt zu organisieren. Ich möchte hier keine Hierarchien, in denen Leute gesagt bekommen, was sie zu tun haben. Ich möchte, dass die Leute Aufgaben anbieten und andere sich bereiterklären diese zu übernehmen. Wenn sie das nicht tun, dann ist ihnen das Projekt offensichtlich nicht wichtig genug und dann möchte ich auch nicht, dass diese Personen die Aufgabe übernehmen.

Wir hatten ein Pad aufgemacht, in dem wir Aufgaben sammelten. Die Frage, wie das koordiniert wird, ist immer noch offen. Sollen wir Github Issues aufmachen? Ein Kanban-Board? Forenbeiträge? Ich finde, das ist etwas, was man unbedingt auf dem nächsten Treffen klären sollte. Das Anbieten von Aufgaben, für die sich dann niemand meldet, hat jedenfalls nicht so wirklich geklappt.

Ich möchte behaupten, dass aktuell einige Personen psychisch darauf eingestellt sind konkrete (technische) Aufgaben zu übernehmen. Die Alt-Admins, die gewisse Themen loswerden möchten, sollten dies aus meiner Sicht einfach mal neu probieren.

Ich habe auch schon mehr als einmal ausdrücklich gesagt, dass ich ein technisches Thema übernehmen würde, aber es gab bislang keinen konkreten Vorschlag.

2 „Gefällt mir“

Ich harre mal der Dinge, meine Art zu kommunzieren funktioniert hier nicht.

Wie würde eine Aufgabenverteilung konkret für dich funktionieren? Wie kommen wir von einer unvollständigen Liste an Aufgaben in einem Pad zu der Situation, dass Menschen Aufgaben annehmen? (Hattest du ja oben schon geschrieben, aber wie konkret sollte das ablaufen? Vorstand delegiert? Oder hast du einen Vorschlag für technische Hilfsmittel?)

Und wie würde das für euch Andere funktionieren? Was braucht ihr, was wollt ihr, was können wir tun um von unkonkreten Aufgaben zu erledigten Aufgaben zu kommen? Wie erreichen wir euch, dass ihr die angebotenen Aufgaben annehmt?

Für die Delegation einer Aufgabe an eine andere Person brauchen wir

a) Auswahl der Aufgabe
b) Sichtung möglicher Personen
c) Prüfung der Qualifikation der Personen für diese Aufgabe
d) Prüfung des Vertrauens in die Person in Abhängigkeit zum Schutzbedarf der Anwendung

Die Organisation von Treffen mit Raum ist so eine Aufgabe. Klappt prima.

Als nächstes würde ich z. B. den Betrieb eines Webservers inkl. einer App vorschlagen. Wer kennt sich mit html, nginx, Graphana, Discourse, etc. soweit aus und würde sich um die regelmäßige Wartung zunächst einer dieser Anwendungen kümmern? Zu tun sind Updates der Software, ggf. Debugging, Sicherstellen des Betriebs, etc.

Betreibe seit 2006 privat Webserver mit nginx & php-fpm / neuerdings auch Node und seit ca 20 Jahren Server auf Linuxbasis. Von Graphana, Discourse usw habe ich allerdings keine Ahnung. Sollte aber kein rocket science sein. Lets Encrypt nutze ich privat auch bzw certbot.

Würde anbieten, das zu übernehmen.

Wow, das ging ja schnell. Klasse.

Wenn noch weitere Personen an diesem Thema Interesse haben, dann bitte ebenfalls melden. Es sollten schon zwei sein, die sich ggf. auch gegenseitig unterstützen bzw. vertreten können.

[Nur zur Sicherheit: ich kann diesen Job selbst nicht vergeben, sondern jetzt wäre es an Leah, etc., Dich mal zu einem kleinen Workshop zu laden und eine Einweisung zu geben.]

Weil das so prima funktioniert hat, schmeiße ich das nächste Thema in den Raum:

Neue Firmware bauen, testen und auf der Webseite zum Download bereitstellen
[Ich vermute bei diesem Thema ist viele automatisiert, aber jemand sollte sich in die Abläufe einarbeiten und verstehen, was FFRN-spezifisch ist, wie die Compile-Pipeline aussieht und wie man am sinnvollsten vorgeht, um ein neues Release bereitzustellen. Zunächst wird es hier wohl um “verstehen-wie” und nicht “machen-selbst” gehen.]

Ich baue privat OpenWRT-Images und beruflich habe ich auch mit Firmware zu tun. Könnte ich also auch einen Teil übernehmen. Trotzdem wäre es schön, wenn sich die Last auf mehrere Schultern verteilen würde, da ich auch nicht unbegrenzt Zeit habe.

1 „Gefällt mir“

Also ich habe das mal probiert und grundsätzlich ist das wirklich nicht schwer. Man muss halt die Release Notes von Gluon verfolgen, Anpassungen an der site-config vornehmen und dann das ganze kompilieren und die einzelnen Release durch die einzelen Brachne laufen lassen und hoffen das sich die Leute melden wenn was kaputt geht (und bevor es in stable angelangt ist!).

Aktuell wird die Firmware ja wohl auf einem Server von @NurticVibe kompiliert. Mein Problem ist, das ich akutell nur vServer habe die zu wenig Speicherplatz haben. Ich habe bisher jetzt noch nicht für alle möglichen Architekturen das Zeug kompiliert, aber schätzungsweise braucht man schon 100GB+ Festplattenspeicher für das Ding. Und mein alter iMac und mein Laptop sind auch eher dafür ungeeignet. Ich habe das jetzt testweise mal auf einem extra vServer gemacht. Da müsste man mal abklären wo man das kompilieren könnte, wenn ich da was machen soll.
Auch habe ich das Problem, das ich außer einem Offloader und einem DIR-505 keine Router habe die man nutzen könnte um mal selber vorab zu testen. Wobei ich keine Ahnung habe ob @NurticVibe aktuell sowas macht, oder ob er es nur durch die einzelnen Kanäle jagt und hofft das sich bei Problemen jemand meldet.

1 „Gefällt mir“

@leah 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. Wird auf fw.ffrn.de direkt gebaut oder ist das nur ein Host zur Auslieferung?

@sur5r: Falls es aktuell keinen geeigneten Compile-Server gibt (weil das bislang @NurticVibes eigene Hardware war): Könntet ihr dann über den Vorstand einen Server bereitstellen?

@tomH prima, dass Du Dich in das Thema eingearbeitet hast. Die Stable-/Beta-Update scheinen aktuell eher selten zu erfolgen (während Nighly zuletzt am 01.07. gebaut wurde). Ich glaube ein Großteil der Arbeit ist, ein Gefühl für die Relevanz der Updates zu bekommen und sie auf Experimental bereitzustellen. Es müssten sich ein paar User bereiterklären, mit unterschiedlichen Geräten Experimental zu fahren und Dir Feedback zu geben (bzw. das kommt von selbst, wenn’s nicht läuft ;-).

Ich wäre bereit ein weiteres Thema in die Runde zu werfen - wer hat Interesse und die Fähigkeit für den: 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.]

Ich fahre für sowas Server von DigitalOcean hoch. Keine Ahnung wie lange so ein Build dauert aber ein Server mit 8 GB Ram, 160 GB SSD und 4 virtuellen CPU Cores kostet $0.060/hr. Man zahlt 0,05$ pro GB/Monat wenn man Snapshots speichert, das sind gestoppte Server. Wenn man sie löscht, zahlt man natürlich gar nichts. Ich habe einen Wireguard-Server dort, den ich bei Bedarf hochfahre und er kostet mich 2 Cent pro Monat wenn ich ihn nicht nutze. Man könnte eine Minimalkonfiguration zum Bauen bzw. ein Script für die aktuellen Checkouts in so einem Snapshop speichern und bei Bedarf dann anwerfen, die Images woanders hochladen und den Server wieder löschen. Für einen neuen Build fängt man dann mit einem frischen Snapshot wieder an.

Ich weiß nicht wie oft die Builds gemacht werden und wie lange sowas durchschnittlich dauert. Wenn man keinen bestehenden Server nutzen kann, wäre das auf jeden Fall eine Idee und günstiger als Amazon und co.

@JevermeisteR Wir sollten hier nicht zu detailliert auf mögliche Infrastruktur-Varianten und Lösungen eingehen. Es geht hier/jetzt primär darum jemanden zu finden der sich da einarbeitet und ggf. die vorhandene Infrastruktur nutzen kann, um das Rad nicht neu zu erfinden. Mittelfristig kann das dann natürlich optimiert werden.

Noch offen: Wer hat Interesse und die Fähigkeit für den:
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.]

Da das scheinbar noch nicht ganz klar geworden ist. Ich habe keinen Zugriff mehr auf die Server. So gar nicht. Da kann ich dir nicht helfen.

Dann reichen wir die Frage an @NurticVibe weiter:

Gibt es einen Build-Server, auf den @tomH Zugriff bekommen kann? Und @JevermeisteR eventuell ebenfalls - zur Unterstützung und Redundanz.

Die Frage, ob und wie @JevermeisteR Zugriff auf die Webserver erhalten kann, ist auch noch nicht beantwortet.

Ich vermute es hängt alles an @NurticVibe … oder wer hätte ansonsten noch Zugriff?

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.

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

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.

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

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.

1 „Gefällt mir“

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.

1 „Gefällt mir“