Ich habe mal für GSoC 2018 ein Projektvorschlag für ein gluon basierendes Gateway erstellt. Das ist ein erster Vorschlag, ich würde mich über Kommentare dazu freuen.
Zur Motivation:
Im Moment müssen wir die Softwareinfrastruktur zwei mal pflegen: einmal für die Knoten (gluon) und einmal für die Gateway, bei denen viele Communities selbstgebackenes verwenden. Wenn man beides vereint müsste man z.B nicht mehr jede Community alle gluon Änderungen manuell nachpflegen.
1 „Gefällt mir“
Hallo,
ich möchte mal eine kleine Anmerkung zu Dezentralität machen.
Wenn jeder als Software nur noch Gluon einsetzt ist das für mich auf Dauer nicht mehr richtig Dezentral, da ja dann alle von Gluon abhängen.
Es gibt schon eine Anleitung unter Freifunk MWU Gateway Doku — Freifunk MWU Gateway Doku 0.1 beta Dokumentation
Ist Gluon nicht eigentlich „nur“ ein Firmware Build Tool oder habe ich das immer Falsch Verstanden?
Die Idee ist nicht, eine Anleitung zu schreiben, sondern eine Gatewayfirmware, analog zur Knotenfirmware. Denn im Moment bastelt da jede Community (basierend auf ähnlicher Software und Guides wie dem von dir genannten) die Änderungen in gluon nochmal serverseitig nach.
Von einem kalifornischen Flachcomputer gesendet.
1 „Gefällt mir“
Welche Gluon Änderungen muss man denn ständig nachbauen?
Mir ist da zumindest nichts bekannt, und unsere Gateways laufen
schon eine halbe Ewigkeit mit der gleichen Konfiguration.
Einerseits finde ich die Idee toll, aber andererseits hat man dann anstatt
ahnungslose Knotenbetreiber (Stichwort: Blackbox) die nur AN/AUS können,
noch ahnungslose Gateway Betreiber.
Ich weiß nicht ob man das gut finden sollte 
Aber was ich toll fände, wäre wenn es für sämtliche Distributionen ein „gemeinsames“
Software-Repository gäbe, sodass man per „apt install batman-2017-xyz tunneldigger gateway-tools“
alles nötige automatisch installiert, und nur noch die default Konfigurationsdateien entsprechend
der Community anpassen muss. So würde sich das ganze gefrickel auf ein minimum reduzieren,
und man müsste sich nur noch um Eckdaten kümmern, wie den DHCP-Adressraum und IP-Adressen/Namespaces usw…
1 „Gefällt mir“
Nichtmal das gibt es derzeit, was dazu führt, dass man die Build-Umgebung auf jedem Supernode mitschleppen muss.
Aber ja, natürlich will man ein Gluon-basiertes Gateway.
Und zwar mit der der Argumentation von @MisterCrumble, nur mit der exakt gegenteiligen Schlussfolgerung:
Ein Gluon-Gateway würde
- in Domains mit potentiell „überlasteten“ Admins eine Abhilfe zu schaffen mit einer stabileren Grundlage. Dort wo die Admins jedes Mal angefressen reagieren, wenn man sie öffentlich darauf hinweist, dass gerade DHCP, IPv4-Exit oder IPV6-Inbound klemmt. Und sie dann mit langen Reaktionszeiten nur „Reboot“ machen und dafür sogar noch Lob erhalten.
- es Menschen einfacher machen, eine Domain zu forken und dezentralere Strukturen zu bauen (die heute den Sprung schlicht nicht wagen, weil ihnen das mit dem GRE, dem Bird und den Routingtabellen etc zu viel Magie ist)
- es Menschen erlauben, die das obige zwar hinbekommen, aber dafür zu viel Zeit aufwenden (Maintenance, Monitoring von potentiell wackeligen Setups), wieder mehr „Freifunk“ (im Sinne von „Funk vor Ort“ und „Funk von Dach zu Dach“ zu machen.
- es erleichtern, lokale Gateways zum Ausleiten aus lokalen Wolken zu bauen, ggf. abhängig vom Ziel-AS auch BoSE.
1 „Gefällt mir“
Ja sehr schade, man könnte sich für ein Software Repository ja mal zusammen absprechen?
Also die Schlussfolgerungen 2-4 fände ich auch noch legitim für so ein Setup, aber beim ersten
würde ja dann im Problemfall genau das gleiche passieren > AUS/AN fertig ist die laube.
Weiß auch nicht ob Gluon so das richtige Werkzeug dazu wäre.
Ich habe aber auch nicht verstanden was an Handarbeit gemeint war.
Wenn es nur das batman-adv Kernelmodul war, dann würde es imo mehr Sinn machen, dafür das alte Paket zu reparieren und für den Rest Docker-Container anzulegen.
Aber ich bin der letzte der sich über eine Möglichkeit für einen Gluon-Supernode beschweren wird.
Im Moment besteht (zumindest bei uns in Kiel) das Gatewaysetup aus Puppetskripten. Diese müssen gewartet werden und an neuere Debianversionen angepasst werden. Auch wenn updates eingespielt werden verändern sich die Systeme im laufe der Zeit und werden immer einzigartiger, mit allen möglichen „Marotten“. Wenn es ein Gluon Supernode image gäbe könnte man das bei bedarf anpassen und nur booten, und hätte damit wesentlich weniger mutable state
1 „Gefällt mir“
Ich sehe im Moment nicht den Sinn, warum ein Server mit Speicher im Gigabyte Bereivh mit einem abgespeckten Betriebssystem für kleine Geräte mit Speicher im Megabyte-Bereich betrieben werben sollte. Die Server meshen auch selten über WLAN, alledings müssen alle Netzwerkarten in diesem Image unterstützt werden.
Das mit den Lantreibern ist weniger ein Problem, da kommt Gluon von Hause aus mit einem guten Satz. Zumal virtuo ja dabei ist.
Ich baue z. B OpenVPN inzwischen lieber auf Lede (in VMs), einfach weil es für die Aufgabe effizient ist.
Wenn es nur eine Aufgabe in einer VM gibt, ist das durchaus in Ordnung.