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.
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
Ich gehe nicht davon aus, dass die UX in einem rein denzentralistischem Netz ideal ist - eher im Gegenteil. Gerade unbedarfte Anwender sind darauf angewiesen, dass die Technik von sich aus funktioniert. Das ist in dezentralen Netzen die dann eventuell die Dienste missen lassen die Comfort bieten - sei es jetzt google als Dienstefinder oder schlicht dns - meist nicht der Fall.
Witzigerweise ermöglicht aber gluon ein Setup für unbedarfte im kleinen Rahmen - wie gesagt, einstöpseln und das Spielen kann wie bei einer Lan-Party beginnen.
Ich möchte einfach nur dem, meinem Gefühl nach, im Raum stehenden „Gluon ist zentralistisch“-Aussage widersprechen.
Natürlich ist eine Netzstruktur die sich auf einzelne wenige Gateways stützt zentralistisch. Das ganze so zu bauen ist aber eine Entscheidung der Menschen vor Ort. Wie man das dann technisch realisiert ob mittels gluon, batman, olsr oder wie auch immer ist dann für diese Betrachtung zweitrangig.
Betrachtet man aus rein technischer Sicht, so ist gluon für einen zentralen Ansatz ziemlich schlecht geeignet, weil es nicht gut skaliert - oder möchte jemand ernsthaft eine Community mit 20000 Nodes auf gluon bauen und dann auch selbst nutzen?
Edit:
Ich glaube übrigens, dass sich die Kritik derjenigen, die gluon Zentralismus vorwerfen eigentlich gegen die Einfachheit richtet. Man kann einfach kopieren und es funktioniert, ohne dass man wissen muss warum. Ein paar wenige tragen alle Bausteine zusammen die sie für richtig halten und die Masse kopiert sie, ohne sich dort wirklich intensiv damit auseinander zu setzen. Dadurch die Einstiegsschwelle sehr niedrig - jeder Depp kann einen Node betreiben und wenige Firmwarebauer haben die Macht über xxx Nodes.
Aber auch das ist keine eigentliche Eigenschaft von gluon, sondern eine Entscheidung der Community vor Ort. Sie könnte Nodes ja auch erst nach intensivem Einsteigerkurs raus geben oder den autoupdater per default deaktivieren.
Das ist schwierig - da stimme ich Dir nicht zu.
Es gibt natürlich ein Know-How Unterschied zwischen unbedarften Anwendern und gestanden Freifunkern. Dezentral bedeutet nur, dass jemand mit entsprechendem Know-How als gestandener Freifunker mitmachen kann, ohne „eine Erlaubnis“ (z.B. SSH-Account auf dem Gateway, Commit-Rechte im zugh. ansible-Repo, …) zu benötigen.
Die Herausforderung liegt darin, ein Netz zu bauen, indem sich alte Hase sofort zu recht finden und mitmachen können und gleichzeitig die jungen Hüpfer heranzuführen.
Z.B. finde ich es sehr gut, wie die Berliner ihren Konfigurationswizzard entwickeln. Ziel ist es, den Router auch für mehrere VPN-Anbieter einsetzen zu können, wobei der Benutzer in etwa so viel verstehen muss, wie bei der Konfiguration einer Fritzbox.
Ich denke, dass ist ein gutes Beispiel dafür, wie einzelne, systemrelevante Gateways mit Admins vermieden werden können. Ich sehe nicht, dass es hier Einschränkungen bei Nutzung von DNS oder google gibt, oder die UX signifikant eingeschränkt wird.
Ich finde diesen Usecase für die Communities nicht wirklich prägend - im Gegensatz zu Konflikten die entstehen, wenn Admins für Gateways verantwortlich gemacht werden: Hierran können sich Communities recht gut aufreiben.
Ok - mein Eindruck ist, dass wir die die Dinge in diesem Thread recht differenziert sehen und niemand auf diese Weise trollt.
Das sehe ich nicht so. Wie eine Technik verwendet wird, wird schon von der Technik beeinflusst (UX). Gluon macht es einfach, wenige, systemrelevante Gateways zu bauen, wodurch sie häufig entstehen.
Stell Dir vor, der Berliner Wizzard wäre fertig, und Nodeaufsteller könnten sich dafür entscheiden IPPredator, hide.me, VPN-You-Name-It zu verwenden.
Dann wäre es schwierig für eine Community, das Netz auf wenige, systemrelevante Gateways zu beschränken: Sie müsste in ihrer Firmware viele VPN-Provider auspatchen und zugleich die Nutzung einer nicht-modifzierten Firmware unterbinden.
Das ist ein schwieriger Punkt. Technische Skalierbarkeit hat für mich erstmal wenig mit Dezentralität zu tun.
Dezentralität ist: Welche Bürokratie / Autorität herrscht über was und kann die Zugang verhindern?
Technische Skalierbarkeit ist: Wie groß kann das Netz werden - unabh. davon wer es beherrscht?
Ich denke, Gluon hat vielen Communities geholfen sehr gut geholfen sich zu gründen und zu starten. Es wird - so gesehen - auf dezentrale Art verwendet. Niemand beherrscht alle Communities. Gleichzeitig skaliert es gut, weil immer mehr Community-Netze mit Gluon an den Start gehen.
Andererseits gibt’s immer wieder Gateway-Administratoren und Konflikte. Hier können wir besser werden.
Da kann ich Dir nicht so recht folgen. Für mich ist Einfachheit eine positive Eigenschaft; gerade in einem komplexen Gesamtsystem. KISS (Keep-It-Simple-Stupid) ist ein weit verbreitetes Paradigma.
Das Problem entsteht eigentlich dann, wenn die Einfachheit damit erkauft wird, dass eine Infrastruktur und Administratoren Services anbieten, die die Dinge einfach machen. Damit wird das System nicht „simple“, sondern nur einige Use-Cases darin. Diese Kritik nehme ich häufig war.
Die Motivation hinter Einfachheit und Dezentralität ist imho die gleiche: Einen guten Einstieg in ein Thema bieten.
Einfachheit: Die Hürde ist niedrig, viele haben die Chance Dinge zu bauen
Dezentralität: Niemand kann verhindern, dass jemand Dinge baut.
Aber Vorsicht:
D.h. „Technische Dezentralität“ bewirkt genau das Gegenteil. Soweit Dich verstehe, denkst Du auch in die Richtung, wenn Du schreibst:
Ich finde es wirklich wichtig, zwischen Redundanz, verteilten System oder auch „technischer Dezentraltität“ und Dezentralität im Sinne der Hackerehtik zu unterscheiden. Beide können hier zu genau gegensätzlichen Dingen führen!
Meine Wahrnehmung nach kommt Freifunk aus der Hacker-Kultur und der Begriff aus der Hacker-Etihk passt recht gut. Auch wenn viele hier - nachvollziehbarer Weise (sic!) - recht viel Spaß daran haben, interessante verteilte Systeme zu erforschen.
Ich finde wir bewegen uns hier in einem sehr spannden Themenfeld: Wie sollte die UX von Freifunk aussehen, damit alle gut Freifunk machen können.
Welches Wissen können wir von Freifunkern erwarten?
Welche Themenfelder wollen wir erschließen?
Welche Dinge führen zu Konflikte?
Gruß, yanosz
P.S. Sorry für die Wall of Text … ich seh’ gerade nicht, wo ich noch kürzen kann.
hmm… mir fällt beim korrigieren der Typos gerade auf, dass es schwer wird, sich im Editor zu orientieren, zu quoten und Argumente zusammen zu fassen … das wird langsam konfus.
Vorschlag wir lassen die Diskussion hier irgendwo stehen und setzen sie im Real-Life fort … ich hatte auf dem letzten Freifunk-Tag einen Workshop dazu gemacht - evtl. mag’ jemand anderes Impulse setzen? Evtl. auf dem WCW?
Einverstanden. Ich denke es wurden für die Eingangsfrage, wie denn das ist mit Gluon und der Denzentralität genug Impulse geliefert um selbst seine Schlüsse daraus zu ziehen.
Ein Urteil ob und wenn ja wie weit der Gluon-Ansatz denn nun der Zentralität unterliegt müssen wir ja nicht fällen, das muss jeder und jede Community für sich tun - dezentral eben.
Es gibt verschiedene Herangehensweisen. Die „reine Lehre“ besagt nun einmal, daß „Freifunk“ „dezentral“ sei. Das ist mit der grundlegenden Arbeitsweise von „Gluon-Netzen“ inkompatibel; „in Gluon-Netzen“ gibt es systembedingt wenige, eher zentrale „Gateways“. In „traditionellen“ Freifunk-Netzen hingegen ist potentiell jeder Freifunk-Router auch ein Gateway in andere Netze (wie z. B. das Internet).
Heißt technisch: die Accesspoints/„Hotspots“ dürfen keine einheitliche SSID haben (was praktisch bedeutet, man muß jeden Hotspot einmal händisch pro Gerät aktivieren), (TCP-) Verbindungen (z. B. SSH) brechen bei jedem AP-Wechsel (i. e. alle 50-100m) zusammen.
Demgegenüber zielt das batman_adv-basierte Gluon-Setup darauf ab, daß in einem (ggf. großen) geographischen Bereich genau eine SSID benutzt werden kann und über zentrale Systeme im Hintergrund die „Illusion“ eines zusammenhängenden Netzes geschaffen wird. Sprich: im Optimalfall läufst Du 2 km durch eine Fußgängerzone und Dein Radio-Stream über das (Gluon-) Freifunknetz bricht nicht ab.
Beide Extreme (1-AP-Microzellen vs. stadtweite SSID und damit 1000+ Geräte in einer verteilten „Collision-Domain“) sind im Endeffekt nicht das, was „man“, sei es Nutzer oder Anbieter, möchte. Eigentlich möchte man libre-mesh.org haben, aber das setzt in real existierenden Umgebungen voraus, daß $jemand den Netzausbau plant (hier Mesh, dort Inseln). Was, BTW, auch wieder eine Zentralinstanz instantiiert
Die Popularität verdankt „Gluon“ imho der Einfachheit: eine Firmware, auf die Hardware geflasht, und der Freifunk-Knoten ist für jeden Einsatzfall an jedem Ort (im Zielgebiet) gerüstet. (Sofern die Community nicht auf die rückständige und widersprüchliche händische fastd-Token-Freischaltung besteht.) Jeder Eventualitätneue Knoten erweitert wirklich „die WLAN-Wolke“, auch in gerade in Fußgängerzonen. Wie immer erkauft man sich diese Einfachheit auf der einen Seite mit Komplexität auf der anderen (Overhead/„Grundrauschen“).
Wichtig ist aus meiner Sicht, ein freies Netz zu haben, und das erfüllt Freifunk sehr gut. Dezentralität ist die nächste, darauf aufbauende und nachrangige Forderung. Bei IPv4 ist das Thema Dezentralität übrigens völlig egal. Nochmal im einzelnen:
Zum Thema „freies Netz“: Wenn der Provider absichtlich jeden Tag die IP-Adresse ändert, damit man keinen Server betreiben kann und absichtlich bestimmte Ports sperrt, damit bestimmte Protokolle nicht laufen und VoIP auch verboten ist, so ist das ein schönes Beispiel für ein unfreies Netz. Die Folge ist, dass wenn man ein Foto von Händi A nach Händi B schicken will, gewöhnlich irgendwelche zentralen Server wie WhatsApp oder Facebook dazu benutzt, d.h. man sendet das Bild erstmal in die USA, dort wird es auf eine schlechtere Auflösung runterskaliert, und dann darf der Empfänger es sich von seinem Account runterladen. Das ist idiotisch! Mit Freifunk kann man theoretisch eine Email o.ä. dirket von Rechner A nach Rechner B schicken ohne irgendeinen blöden Smarthost wie GMX dazwischen, der die Größe der Nachricht auf 15 MB beschränkt, willkürlich Nachrichten als „Spam“ markiert, oder wie Web.de, von dem man nur alle 15 Minuten Mails abrufen kann.
Zum Thema „Dezentralität“: Dieser Punkt wird erst im Falle von Naturkatastrophen oder politischen Instabilitäten relevant. Wenn ich in Hamburg wohne und in Berlin tobt gerade der Krieg, oder ich wohne in Berlin und Hamburg ist gerade überflutet, dann wäre es gut, wenn sich DNS-Server, Email-Smarthost, SIP-Server usw. in meiner Stadt, besser noch: innerhalb meiner Knotenwolke befinden. Sonst will ich mit meinem Nachbarn kommunizieren, aber obwohl die Leitung noch steht, kommt trotzdem nichts mehr an. Für Deutschland sind Überlegungen zur Dezentralität vor allem relevant im Hinblick auf Überwachung und Zensur.
Zum Thema „IPv4“: Gähn. IPv4 braucht man noch für alte Software, die nicht mehr weiterentwickelt wird, z.B. Emule. Auch in irgendwelchen Banken und Versicherungen, wo es möglicherweise eine „Never touch a running system“-Policy gibt, wird man sich hüten, alles auf IPv6 umzustellen. Alte Ataris und andere Museumsrechner sollte man weiter mit IPv4 betreiben, denn eine Umstellung auf IPv6 wäre ein Stilbruch. Auch die Webserver der Bild-„Zeitung“ und der ARD laufen noch ausschließlich mit IPv4, da sie von reaktionären Institutionen betrieben werden. All diese Anwendungen sind aber historische Anwendungen; für die obigen Überlegungen sind sie ohne Bedeutung. Wenn ich frei und dezentral kommunizieren will und IPv6 zur Verfügung steht, brauche ich kein IPv4.
Die Zukunft von IPv4 stelle ich mir übrigens als eine große Tabelle vor, bei der jeder IPv4-Adresse eine IPv6-Adresse zugeordnet ist, zu der dann mittels LISP getunnelt wird. Weil dann jede Adresse einzeln vergeben werden kann, wird es auch wieder leicht, eine zu bekommen.
