@dippydipp: Leider muss ich dich da korrigieren. In Metelen stehen wir gerade am Start und dort wird überlegt zu fördern. Die Gemeinde Wettringen plant einen weiteren großen Ausbau durch die Gemeinde finanziert - wir bremsen dort gerade um nicht auf die Nase zu fallen. In vielen Teilen der Kreises haben wir da genau die gleichen Probleme. Abgesehen von vielleicht Steinfurt zentral.
Wenn du mit „alt“ die Supernodes der „Legacy-Domäne“ meinst, die sind halt noch im Betrieb. Momentan haben wir ein Delta von ~100 Connections. Wenn mehr wegbrechen, können sich nicht mehr alle Nodes verbinden.
Es gibt ja auch das Modell mehrere Domänen über eine VM abzuspeisen. Aber da sind wir momentan noch nicht und das hat auch keine Priorität. Ich verstehe auch nicht wo das Problem ist, die Server haben i. d. R. sehr kurze Laufzeiten. Wenn zu viel Überkapazität vorhanden ist, kann man die auch sehr schnell wieder abstoßen. Auch ist die Konfiguration eines Bleches/Hypervisors nicht so umfangreich, wie landläufig angenommen. Wenn man libvirt verwendet ist man da recht schnell durch.
@dippydipp @Dezi Klar Förderung und so ist super. Leider wird hier meist unter Förderung verstanden lokal Router zu spenden oder Zugang zu interessanten Aufstellorten zu ermöglichen. Generell werden lieber Knoten aufgestellt und neue Gebiete erschlossen, auf die Infrastruktur hat keiner bock. Ich auch nicht, ich würde lieber Karten und Statistiken machen.
Daher versuche ich diese Argumente auszublenden. Für mich persönlich sind daher zwei andere Kriterien relevant für die Priorisierung: Hat die Wunsch-Teil-Domäne die passende Größe (~ 150-250 Knoten)? Besteht Motivation innerhalb der Sub-Community? Paradebeispiel ist hier „Das Labor“ aka Warendorf. @paulinsche hat hier vom Infrastruktur-/Admin-Team letztendlich nur die Anbindung ans Backbone gebraucht. (Und die hat er uns auch noch beigebracht.)
Klar ist @paulinsche ein Ausnahmetalent und voll drin im Thema Infrastruktur & Routing. Aber auch der Wunsch den Weg gemeinsam zu gehen, respektive bei der Konfiguration der Domäne dabei zu sein oder wie in diesem Fall das Angebot ein Blech zu sponsorn sind schon toll. Allein die Frage, wie man dem Admin-Team zuarbeiten kann/soll wäre schon extrem hilfreich. Vor allem aus dem Gesichtspunkt, dass Freifunk eine dezentrale Bewegung sein sollte und daher auch das Wissen über die Technik möglichst breit verteilt werden sollte.
Ich hab ja nichts gegen Blech.
Was ich nicht so perfekt finde sind Aussagen wie “brauchen Blech” ohne das sich irgendjemand mal 20 Minuten hingesetzt hat und das einmal durchgeplant hat. Dabei kommen wir dann auch bei den Annahmen mal auf einen Nenner.
Ich habe mitte des Jahres mal ein Tabelle mit nem Plan gemacht, die kram ich mal raus, vielleicht wird das dann klarer.
Ich persönlich sehe derzeit keinen Bedarf an Blechen. Mit den gerade angemieteten Kapazitäten können wir drei bis vier neue Domänen je zwei bis drei Gateways betreiben. Wenn das läuft, gerne mehr. Derzeit nicht. Das ist meine Meinung dazu.
Grüße
Matthias
@descilla Gerne würde ich mehr noch für die Infrastruktur machen. Allerdings bin ich Realist genug, dass ich die Konfiguration eines Servers NIE lernen werde. Ich kann auch keinen Waver in meiner Garage herstellen.
Was ich als “meine Aufgabe” ansehe und was ich auch (meines Erachtens ) kann, ist Freifunk vor Ort publik zu machen, Vortäge zu halten und die Leute zu motivieren mit zu machen. Support zu leisten und Leute beim optimalen Aufstellen der Router und deren Konfiguration zu unterstützen. Die Politik und die Stadt zum unterstützen von Freifunk zu bewegen,. Gelder einzusammeln z.B. für Bleche, Homepages zu erstellen und zu gestallten. Flyer, Logos, Fahnen und Aufkleber zu erstellen und zu drucken.
Und ab und an hab ich zwischendrin eine Familie, Freunde und andere Hobbies.
@scroom hat ja schon Angeboten sich langsam in das Thema “Serverbetreuung” einzuarbeiten wenn es seine Berufliche Tätigkeit wieder zu lässt. Die nächsten Ferien sind sicher nicht weit! Ich denke er würde dies auch für den Rest des “Kreis Coesfeld” machen. Zumindest so lange bis eine neue Community entsteht. Richtig @scroom?
Aber bis dahin ist einfach keine Zeit mehr! Und wenn, wie Du @descilla selbst schreibst gar nicht so viel arbeit ist einen Supernode zu clonen, dann lasst uns doch einfach los legen. Oder gibt es ein Argument was das verhindert? Dann lasst uns drüber sprechen.
Der aktuelle Zustand, und an der Stelle muss ich mich leider wiederholen, ist eine Nutzung der Freifunk Münsterland Software gar nicht möglich. Meine Knoten sind sicherheitshalber (bevor jemand denkt er käme mit Freifunk ins Internet) offline. Es kann also gar nicht schlimmer werden.
Für die Admin-Runde heute Abend steht auf der Agenda:
- Konfiguration des Backbones Fanlin
- Neuinstallation des Blechs remü.
Im Anschluss - ich denke nicht, dass wir damit heute Abend durchkommen - können Supernodes für den Kreis Coesfeld konfigurieren.
Ich schlage dafür vor eine Supernode auf remü zu konfigurieren und eine Supernode auf greyworm zu packen. Was denken die anderen?
Was mich an deinem Vorstoß motiviert: Es scheint so als würden da einige Knoten auch per Hand umgezogen werden können bzw. es kommen viele Neue erst hinzu. Denn bis das automatische Umziehen der Knoten - sind wir mal realistisch - funktioniert, wird es noch ein bisschen dauern. Zum einen muss der Workflow noch erprobt werden, zum anderen gibt es Unstimmigkeiten bzw. Querulieren zwischen einigen, die in diesen Prozess eingebunden sind.
In Lüdinghausen hat @scroom, in Rorup @prototyp oder ich und in Dülmen hab ich die Knoten größtenteils irgendwie im Zugriff oder weis wem die gehören. Damit bekommen wir sicher über 80% der Knoten im Kreis.
In den anderen Orten im Kreis Coesfeld sind nur einige wenige Router, die wir entweder per Homepage oder Sozial Media erreichen.
Anderenfalls erkläre ich mich auch bereit rum zu fahren und die Knotenbetreiber vor Ort anzusprechen, so dass wir den Kreis im derzeitigen Zustand relativ schnell hin bekommen sollten. Das ist ein Beitrag den ich leisten kann.
BTW: Ich würde dann alle Knoten mit FF-DLM-xxx, FF-LH-xxx, FF-rorup.net-xxx usw benennen. Das hilft vielleicht auch später bei der Identifizierung bei einem weiteren Split.
Das ist für die Knoten ohne Geoinformationen relevant. Ich habe ja das Script geschrieben, mit dem ich die Knoten je administrativer Einheit zähle, das wollte ich demnächst so anpassen, dass dort die Knoten-IDs einer gewünschten Einheit rausfallen.
Bevor ihr hier alle in Euphorie verfallt, weise ich nochmal kurz darauf hin, dass wir noch keine komplett funktionierende Bird-Syntax haben um eine Domäne per OSPF an zwei Backboneserver anzuschließen.
@dippydipp Klar würde ich, wenn ich zeitlich wieder besser dastehe und mich eingearbeitet habe, für den ganzen Kreis Coesfeld und auch darüber hinaus, mitarbeiten. Ich hoffe, dass ich schon bald wieder mehr Zeit habe und ihr dann auch Lust habt mich anzulernen.
Ansonsten fände ich es natürlich Klasse, wenn wir bald eine neue Domäne Coesfeld bekommen würden. Auch da die Stadt ihre 45 Knoten bald online bringen möchte!
Ich finde das ehrlich gesagt alles ziemliche unnötiges Gepfusche.
Lass und doch mal eine Domäne fertig machen und dann geht’s schnell weiter.
In Anlehnung an den Post von fungur ( Domänabspaltung: Warendorf )habe ich mal einen ersten Satz der Switch-Anweisungen für den Webserver für den Kreis Coesfeld erstellt. Dabei bedeutet Level 0, dass der Knoten direkt mit einem VPN Server verbunden ist, Level 1 ist einen Mesh-Hop entfernt, Level 2 ist 2 Mesh-Hops entfernt, usw…
https://github.com/FreiFunkMuenster/tools/tree/master/domaenensplit_webserver_config
Konkret:
- Die Knoten “irgendwie von Hand” übertragen zu wollen.
- Die nächste Domäne anzufangen wenn die Nullserie noch nicht fertig ist
Achso, ja ich wollte damit nur sagen, dass es sein kann, dass die Domäne eher steht als das Automatisch-Knoten-Umzieh-Teil. Und wenn jemand mit den Hufen scharrt, bitte, dann ab aufs Rad und Knoten umstellen.
Zu 2.: Das sehe ich nicht so. Deswegen habe ich ja gerade diesen Thread gestartet. Wir wollen ja möglichst einen Stapellauf erreichen. Bis auf das Routing/Anschluss ans Backbone ist bereits alles durch Ansible automatisiert. Und beim Routing macht @MPW gerade echte Fortschritte.
Ich habe 8 Beiträge in ein neues Thema verschoben: Knoten in der richtigen Reihenfolge umziehen
Hallo @scroom,
mein 841 hat sich soeben auf den Weg Richtung Kreis Coesfeld, Gemeinde Nordkirchen gemacht. Ich habe um eine besondere Schneckenpost gebeten
Ludger
Hallo,
jetzt wo ein Großteil der Arbeit geschafft ist und wir denke ich das nötige Wissen zum Routing etc zusammen haben, habe ich mir auch mal ein paar Gedanken gemacht, wie es in den nächsten Wochen weitergeht.
Der Ruf nach einer feineren Aufspaltung ist generell richtig. In anderen Communities gilt mittlerweile die Faustregel, nicht mehr als 200 Knoten pro Domäne. Wir haben 1200 Knoten, also bräuchten wir grob sechs Domänen.
Was wir haben:
- Domäne-01: Münster
- Domäne-02: Coesfeld
Ich würde jetzt noch erstmal genau drei weitere Domänen nach demselben Schema bauen:
- Kreis Steinfurt
- Münster-Süd
- Kreis Borken
Die sechste Domäne ist dann die Münsterland-Domäne, die sicherlich noch 1-2 Monate betrieben werden muss. Das ist natürlich erstmal recht grob und wie @descilla schon angemerkt hat, haben einige dieser Gebiete schon zu viele Knoten.
Ich denke trotzdem, dass wir nicht direkt einzelne Städte rauspicken sollten, denn dann wird es irgendwann schnell eng mit den Blechen. Wenn wir die fünf fertig haben, wird es erstmal deutlich besser laufen.
Und dann sollten wir die Infrastruktur nochmal optimieren. Und zwar nicht mehr pro Domäne zwei bis drei eigene VMs, sondern dann mit Multibatman auf einer VM arbeiten. Dann kann man wirklich pro Gemeinde, pro Stadt, teilweise pro Stadtteil eine eigene Domäne machen, ohne, dass das ins Geld geht.
Für die fünf oben angesprochenen haben wir noch genug Kapazitäten und danach wird dann auch in der Münsterlanddomäne schon wieder die ein oder andere VM frei, sodass wir dann mit Multibatman experimentieren können. Zusätzlich sollten wir dann auch mit L2TP experimentieren, das entlastet die Gateways deutlich und erlaubt eine höhere Knotenzahl pro Gateway bei deutlich höherem Durchsatz.
Das so als Ausblick über den Tellerrand. In den nächsten zwei Wochen sollte gestet und migriert werden. Der Teil der Arbeit, auf den ich Einfluss nehmen kann, ist fast fertig, jetzt muss das Migrationsteam anfangen die Knoten zu schubsen.
Grüße
Matthias
Mein (Gegen-)Vorschlag, Münster-Süd raus (und erstmal in Münster rein) und dafür Steinfurt 1 und Steifurt 2 als Domänen. Außerdem sollten wir schauen, ob wir das mit dem Multi-Fastd schnell automatisiert bekommen. Ich denke wir sollten wirklich nicht mehr als maximal 100 fastd Connections über eine fastd Instanz laufen lassen. Denn bei mehr Connections gibt es dort massiv overruns.
Ich weiss nicht ob man eine räumliche Zuordnung überhaupt planen muss (oder sollte).
Wie wäre es einfach opportunistisch jeweils “die nächste Ecke” zu nehmen die am meisten Nutzen (im Sinne von Legacy Entlastung) aus einem Split zieht? Das ändert sich doch eh laufend und wenn wir’s größer planen gibts ein großes “ich, ich, nimm mich” Palaver. Coesfeld ist ein Beispiel dafür. EIne ad-hoc Entscheidung die ich persönlich für falsch halte. Was nicht heissen soll das es nicht hilft aber wenn sollten wir auf größere Happen schiessen, einfach um das Netz zu entlasten. Und da hilft Coesfeld wenig.