Gluon vs. Zentralität

Moin.

:smile:

Nun, Gluon als Firmware ist nicht die einzige Möglichkeit ein eigenes Netwerk zu bauen. Ich denke der User hat halt eine andere Überzeugung von der verwendeten Softwareinfrastruktur.

Vergleichbar mit Automarkenenthusiasten. Welche Marke nun wirklich besser ist …? Aber fahren können sie alle.

Gruß

Vergleiche hinken immer an irgendeiner Stelle :o)
Mit Freifunk und Gluon ist es eher so, als dass sich die Frage stellt, besorge ich mir einen bewehrten Auto-Bausatz, steck den zusammen und pack noch das ein oder andere Accessoir nach meinem Geschmack dran, oder geh ich zur Autoverwertung meines Vertrauens und bau mir selber von Grund auf ein Auto zusammen?

Guten Rutsch

Moin

Nun Ja, auch darüber könnte man trefflich streiten. :smile:

Aber vielleicht sollten wir @Emploi einfach mal fragen, was er denn nun wirklich gemeint hat. :smile:

Ach ja, mein Beitrag zielte eher auf soetwas ab, z.B.: https://forum.freifunk.net/c/opennet-initiative-e-v

Gruß

Also unser System arbeitet (fast) absolut dezentral. Die einzige zentrale Instanz ist der Registrator, der die Knotennummer vergibt und somit auch die IP. Ansonsten arbeitet das Netz absolut unabhängig von zentralen Instanzen und jeder Knoten sucht sich einen Weg ins Internet. Sofern er mal eine Knotennummer bekommen hat, ansonsten ist nach ein paar Hundert Schluss.

Zentrale DHCPs gibt es nicht. Ein WLAN (Hotspot) = ein DHCP… Handshake oder Fake-Handover geht damit natürlich nicht, es sei denn jemand baut dafür mal ne App, damit das Endgerät das regelt.

Es würde theoretisch reichen, wenn auch nur ein Einzelner seinen Anschluss am Freifunkrouter freigibt, der Rest macht bmxd. Es bräuchte also keine großen Gateways, wenn die Störerhaftung mal wegfällt.

Man fragt sich natürlich dann Richtung Bunderegierung, wie man auf einen 841er eine Vorratsdatenspeicherung umsetzen soll, mit den paar freien Bytes im Flash und RAM, denn jeder Router kann ja jederzeit „sein Internet“ freigeben. Als Privatperson.

Gibt es die Möglichkeit bei gluon auch, dass wenn zentrale DHCPs oder Internet Exitpoints ausfallen, noch irgendwas geht oder das einzelne Knoten einfach so (wie ursprünglich gedacht) das Internet freigeben?

1 „Gefällt mir“

Zwei Knoten die sich sehen bilden bereits eine Wolke und sind bereits ohne zentralen Registrator operabel. Ein Gateway ins Internet wird nicht benötigt. Ist mindestens eines vorhanden so wird es genutzt. Jeder Knoten kann Gateway werden und einen Internetanschluss frei geben.

Unter Vorbehalt der üblichen Verdächtigen wie lokalen Konfigurationen einzelner Communities und bewusst unter dem Setup und Zielsetzung in meiner Vorstellung da keine weiteren Vorgaben gemacht waren.

1 „Gefällt mir“

Ich denke die Dezentralität von Gluon wird erst dann wirklich vollständig wenn auch IP4 dezentral verteilt werden kann.

Der ddhcpd von @sargon sieht da sehr vielversprechend aus:

Hallo,

Falls es hilft: https://kbu.freifunk.net/2016/05/Seid_dezentral/ - hatte ich mal aufgeschrieben.

Gruß, yanosz

1 „Gefällt mir“

Ich glaub ich flashe mir auch mal so ein Testgerät, um ein paar Vorurteile abzubauen…

Das sind schon ein paar Punkte.
Beim Ansatz von @Emploi finde ich gut, dass lokale meshes ohne Uplink auch mit IPv4 funktionieren. Im Moment kann ich der Hervorhebung dieses Netzdesigns als besonders dezentral jedoch nicht folgen, denn es wird mit dem Registrator eine zentrale Vergabestelle eingesetzt. Gibt es mehr Informationen zu dem Netz und wo kann ich die finden? Wird auch Batman genutzt? Ich würde gern mehr darüber lernen.

Auch bei batman/gluon-Netzen sind lokale mesh-Wolken ohne Uplink direkt funktionsfähig, wenn man mit ipv6-only arbeiten kann (Mir ist bewusst, dass die meisten handies das als nicht funktionierende Verbindung betrachten). Setzt eine Community eine zentrale IP-Vergabestelle ein, geht das auch per IPv4. Ansonsten wird der ddhcp hier viel helfen, sobald er einsatzbereit ist. :slight_smile:

Bisher scheint die Zentralitätskritik sich nicht auf das Projekt selbst sondern auf den Netzwerkansatz (Batman + Gateways/Supernodes) zu richten. Ist das wirklich der Kern, oder gibt es noch andere Dinge daneben?

@anon5732352, Den Artikel Seid_dezentral finde ich super und verstehe den in erster Linie als Zielvorstellung für einen besseren Umgang in Freifunk und einen Aufruf zu ursprünglichen Werten aus der Hackercommunity zurückzufinden und damit zu mehr Beteiligung. Auf gluon geht der Artikel explizit nicht ein, was ich aus Sicht des Artikels zwar gut finde, er hilft mir aber dadurch nicht dabei zu verstehen, was an gluon als zentral empfunden wird. Dieses Verständnis ist aber genau das Ziel dieses Threads.

1 „Gefällt mir“

ja, die gibt es, allerdings derzeit nicht ohne gefrickel auf der Konsole. Alle benötigten Programme sind aber an Bord.

Hallo,

Danke für die Blumen :-).
Soweit ich Kritik an Gluon wahrnehme, betrifft sie vor allem „3. Schafft keine Autoritäten – Herrscht nicht als Administratoren über das Freifunk-Netz“.

Die Gluon-Standard-Architektur (batman-adv over Layer2-VPN) führt häufig dazu, dass es eine Gruppe von ein paar Adminbistratoren gibt, die über alle Gateways und damit macht über das komplette Netz herrschen.

Seltener haben Sie zudem Zugriff auf alle Nodes (SSH-Key wie Freifunk-NRW, oder autoupdater) und können damit relativ unbemerkt Zugriff auch auf private Netze nehmen in denen die Knoten hängen.

Edit:
Manchmal kommt Kritik auch von anderer Seite: Hin- und wieder verstehen die Leute Dezentralität als technische Redundanz und vermissen sie, wenn Netze mit Gluon-Standard-Architektur von wenigen Servern abhängen.
Seltener wird bemägelt, dass Gluon eine Black-Box ist und das Wissen um die Konfiguration in Gluon selbst zentral bei wenigen liegt - der Hands-On-Imperativ gehe verloren.

Edit(2)
Gefühlt kommt die Kritik häufig troll-artig und die Kritiker sind sich selbst nicht so ganz sicher, woher die Forderung nach Dezentralitat kommt und was sie bedeutet. Ich hatte den Artikel damals geschrieben um klarzustellen, was ich unter Dezentralität im Sinne von Freifunk verstehe.

Gruß, yanosz

1 „Gefällt mir“

Moin

Also iwie verwirrt mich der Kontext dieser Beiträge zu obiger Überschrift.

Vielleicht ist es ja auch mein Verständnis, was GLUON ist? ich dachte das GLUON die Firmware für die geigneten WLAN-Router des Freifunks ist.

Von daher stellt sich mir inzwischen die Frage, worum geht es dann hier?

Freifunk vs. Zentralität?
Dezentralität vs. Zentralität?
Infrastrukturverwaltung (Administration) vs. Zentralität?

Gruß

1 „Gefällt mir“

Für mich ist gluon ein Open Source Projekt, welches ein gleichnamiges Framework zum Bauen von Freifunk-Firmwares erstellt. Alle diese mit gluon erstellten Firmwares haben Gemeinsamkeiten (Nutzung von Batman, Gateway-Architektur bei der das gesamte Netz ein großer Switch ist).

Wenn ich also höre, dass gluon zentral sei, dann kann ich das in obige Definition erstmal nicht einordnen (hosting bei github, PR, viele Beteiligte aus unterschiedlichen Communities und Regionen) und frage deshalb, was damit gemeint ist.

Wenn es die L2-Netzarchitektur ist, die gateways braucht, dann kann ich das nachvollziehen. Da kann man etwas tun (z.B. wird an der Unterstützung anderer Netze gearbeitet indem das Babel-Protokoll integriert wird.).
Ich wollte nur nicht voraussetzen, dass es darum geht - immerhin wäre es alarmierend, wenn ein open-source projekt als zentralistisch wahrgenommen werden würde…

Moin

Nun gut. Dann lasst uns die Sache doch mal von der anderen Seite her beleuchten. Vielleicht ist es auch gut das diese (obige) Frage gestellt wurde.

So wie ich den Freifunk-Gedanken verstehe, ist es so, daß wir ein autonomes (WLAN-Netz) schaffen, welches auch ohne Internetanbindung funktionieren KANN. Allein auf Grund der Meshfähigkeiten der Knoten.

Nehmen wir nun mal an, es gäbe ein flächendeckendes Meshnetz und das Internet, sprich die Uplinks würden komplett wegfallen.

Ist eine Kommunikation dann noch möglich? Und wenn ja, wie? Interne Dienste (eigene Server zuhause) sind ja meist nicht gewünscht, oder werden auf Grund unzureichender Internetanbindungen oder Adminwissen, in Abrede gestellt.

Wie gesagt, es geht hier um ein theoretisches Szenario, welches vielleicht einfach mal als real angenommen werden könnte.

Warum gerade diese Denke? Nun, genau das würde doch die Situation der Dezentralität darstellen, oder nicht? Keine fremdadministrierte Backbones oder Gateway`s. Freifunk pur.

Gruß

Hallo,

Das ist ein schwieriger Punkt: Was im Allgemeinen damit gemeint ist, kann ich nicht sagen, da „Dezentralität“ imho ein schwieriges Ziel mit vielen Nuancen ist.

Einerseits macht Gluon einen sehr guten Job die Entwicklung transparent zu gestalten. Andererseits ist Gluon vom Funktionsumfang so gut, dass es von vielen in den Communities als Black-Box gesehen wird. Hat jemand eine Idee, ist die Frage häufig „wird dies von Gluon unterstützt“ und nicht: „wie kann ich es selber bauen“.
Das hat wenig mit Dezentralität zu tun; nur noch mit der Motivation dahinter: Ein System so offen zu gestalten, dass es verstanden wird.

Der Build ist ggf. ein kleiner Problemfall:
Viele communities bieten builds zum Download an - nur wenige eine Doku dazu, wie Gluon mit ihren Settings zu bauen ist. Das führt schon ein wenig weg von der Dezentralität.

Hui - imho können wir das Problem nicht allein technisch lösen:

Ich find es wichtig, die Einstiegshürde sehr niedrig zu halten und Leute zu ermuntern eigene Communities zu gründen oder große Communities zu spalten. Je mehr Leute Freifunk-Netze bauen können, desto weniger Macht haben Administratoren und Buildmaster.

Für den Betrieb eines Gateways in einem Gluon-Netz wird idR know-how benötigt (ansible, debian o.a., VM-Hosting,…), dss erstmal wenig mit Freifunk zu tun hat und die Eintiegshürde höher legt. (Vgl. auch Architektur-Babel – Freifunk Köln, Bonn und Umgebung)

Gut - :wink:

Gruß, yanosz

1 „Gefällt mir“

Hallo,

Meiner Meinung nach denkst Du recht technisch. Ich find’s gut über die User-Experience eines Freifunk-Netzes nachzudenken; aber Freifunker sind nicht nur Nutzer: Die Freifunk-Community ist eine Gruppe, in der Mitglieder verschiedene Rollen und Funktionen haben.

Natürlich hat die Art und Weise wie Freifunk genutzt wird, Einfluss darauf, welche Rollen es gibt und welche Konflikte entstehen.

Dass eigene Dienste zu Hause nicht gewünscht seien, hab’ ich bislang noch nicht wahrgenommen - ist aber auch nicht der springende Punkt.
Auch der Gedanke ist wieder recht technisch: Natürlich kannst Du im Freifunk-Netz Dienste anbieten. Interessant ist, es so zu tun, dass sie verwendet werden und andere ähnliche Dienste anbieten können.
So lange das Netz dezentral ist, musst Du keine Autorität oder Bürokratie um Erlaubnis fragen.

Gruß, yanosz

1 „Gefällt mir“

stimmt. Die Doku zum Build steht an zentraler Stelle auf Getting Started — Gluon 2016.2.2 documentation. Man nimmt ein gluon und ein site-repository von der community und baut drauf los. Im Ergebnis hat man die Firmware. Welche Dokumentation fehlt Dir?

Wenn sich ein Kritikpunkt auf das technische Thema der Netzarchitektur bezieht, dann kann es dafür schon rein technische Lösungen geben. Allgemein stimme ich Dir jedoch zu: wahrscheinlch trägt Technik nur einen Teil bei und ein großer anderer Teil sind Werte.

Wenn das Netz geeignet gebaut ist, dann ja. IPv6-only kann man in einem gluon-Netz auch in so einem Szenario kommunizieren. (oder mit fest vergebenen IP-Adressen)

Hallo,

Die drei Zeilen, die Du mir gerade geschrieben hast, sollten irgendwo stehen. Zusätzlich noch eine Erklärung, wo das site-repository genau ist, und warum welches Setting dort wie gesetzt (oder ggf. auch nicht gesetzt) ist.
Nett ist auch eine Verlinkung der Job-Definitionen eines CI-Servers - falls es einen gibt.

Aber, wie gesagt: Das Problem ist eher klein. Es hilft einfach anderen, die sich Deine Community als Vorlage nehmen um ein solches Netz zu bauen. Gluon an sich ist schon recht gut dokumentiert.

Edit:
Huch - 2. Teil vergessen:

Ich denke, die Netzarchitektur alleine ist nicht das Problem - sondern eher die Rollen die daraus entstehen:

Es ist irgendwo eine Frage der User-Experience: Wie kann sich jemand in einer Community beteiligen - wie kann jemand eine eigene Community gründen? Wie vermeiden wir Administratoren und eine Bürokratie?

Hieraus folgt denn Technik: In dem sie so gestaltet ist, dass es möglichst keine einzelnen, systemerelvante Komponenten gibt, die von wenig Leuten (aka Administratoren) verwaltet werden. Das Problem bei Gluon ist, - wie geschrieben - dass es eine Netz-Architektur mitbringt, in der es schnell einzelne, systemrelevante Gateways gibt.

Gruß, yanosz

P.S. Evtl. sollten wir uns mal direkt darüber austauschen - ich hab’ aber auf absehbare Zeit kein Projekt in Frankfurt :-/

Das sehe ich nicht so. Gluon macht ein Layer2-Netzwerk auf - und ist damit voll funktional. Zwei Router in Reichweite bringen, Clients anstöpseln und mittels zeroconf ip4, ipv6 oder netbeui / ipx whatever nutzen. Dezentraler geht es doch kaum. Wer möchte kann so z.B. direkt dukeNukem spielen - ohne Adminkenntnisse, einfach Rechner anstöpseln.
Wer ins globale Netz will braucht dafür ein Gate - da tut es auch eine Fritzbox.

Dass die Communities anders angebunden sind liegt an der Störerhaftung und dass man Wolken über das Netz verbinden will. Oder einen Mapserver haben will. Alles keine Anforderungen die von gluon selbst kommen.

2 „Gefällt mir“

Hallo,

Ich find Deine Argumentation schwierig. Soweit ich Dich meinst, gehst Du davon aus, dass die zeroconf ip4, ipv6 oder netbeui / ipx Usable sind, eine hinreichend gute User-Experience (UX) bieten und von vielen genutzt werden werden.

„in der es schnell einzelne, system relevante Gateways gibt.“ ist meine Beobachtung: In den Communities, die ich kenne und die Gluon einsetze, passiert genau das.
Häufig werden mdns / avahi / bonjour Multicast - also die Grundlage Deines Setup-Vorschlags - via ebtables abgeklemmt um die Performance zu verbessern.

Anders gesagt: Ich hab’ noch nicht wahrgenommen, dass es eine Community gibt, die einzelne, systemrelevante Gateways mit Admins vermeidet, indem sie eine Gluon-basierte Firmware released, die grundsätzlich verschiedene VPN-Anbieter unterstützt. Solche Ideen kenn’ ich eher aus Communities, die kein Gluon verwenden.

Das heißt nicht, dass es nicht technisch anders möglich wäre. Gluon macht es schlicht recht einfach solche Netze zu bauen, wodurch sie entstehen; mein Argument ist rein empirisch.

Für mich ist Dezentralität nicht rein technisch. Ich finde es falsch zu sagen, dass eine Technik für sich dezentral ist. Dezentralität ist immer Technik+Menschen.

Gruß, yanosz

Edit:
P.S. Ich denke, wenn Du auf die Technik guckst, hat Dezentralität hat viel mit User-Experience (UX) zu tun: Wird die Technik in der Regel so verwendet, dass sich Administratoren bilden? Über welche Teile herrschen Sie dann?
UX ist zwar eine Eigenschaft der Technik, steht aber nicht im leeren Raum: Feststellen kannst Du sie nur mit Menschen :wink: