December 2015 - Dev - Freifunk Nordwest

Hood System
by Stefan 15 Feb '16

15 Feb '16

Moin zusammen, da ja das Hoodsystem relativ weit fortgeschritten ist, sollten wir uns hierzu noch die ein oder anderen Gedanken zu machen;: - Releasebeitrag im Blog, schreibe ich gerne sofern ihr mir hier ein paar Anhaltspunkte noch geben könnten. Klar ist, dass die Router sich nach Ihren Koordinaten in eine entsprechende Hood verbinden - Zugriffsrechte: Wir sollten überlegen, ob es nicht sinnvoller wäre, die Hood erst zu releasen wenn auch alle Admins Zugang dazu haben. - Einteilung der Hoods, damit man den Nutzern hierdrüber auch Details nennen kann. Vielleicht fällt jemandem ja noch mehr ein -- vg Stefan

5 11

Re: [Dev] [Admin] Plan für stabiles Netz
by Jan-Tarek Butt 07 Feb '16

07 Feb '16

On 12/18/15 08:05, Bjoern Franke wrote: > Am Freitag, den 18.12.2015, 01:30 +0100 schrieb Simon Kurka: >> On 17.12.2015 08:15, Bjoern Franke wrote: >>> * Beim Treffen am Sonntag wurde mir berichtet, dass du beim FFRL >>> für >>> weitere BGP-Peerings angefragt hast. Für welche Standorte denn? >> Anfragen will. >> Jedes Gateway an alle Standorte, einschließlich Backup-Router. >> > > Alle Standorte? Eigentlich kann man sich immer nur an zwei Standorte > verbinden. Warum nur zwei ? vg Tarek

7 21

gwselector
by Jan-Tarek Butt 08 Jan '16

08 Jan '16

Hi zusammen, @Tim: ich hab dich mal in den CC genommen da ich mir gerade nicht sicher bin ob du noch auch unser dev ML bist. ich habe in den letzten Wochen am gwselector geschrieben und bin aktuell an einen Punkt angekommen wo ich mir schon seid Tagen den Kopf zermartere. Aktuell gibt es ja wie im wiki beschrieben [0] den on- / offline selector. Der online selector ist relativ trivial und auch bereits größtenteils implementiert. Bei dem offline selector überlege ich schon länger wie man den implementieren sollte und bisher ist mir noch keine überzeugende Möglichkeit eingefallen. Die Variante an der ich gearbeitet hatte, scannt nach benachbarten wlans mit der identischen ESSID und übernimmt die BSSID des Nachbar WLANs mit der besten Signal quallity und das auch nur wenn es sich um ein reinen mesh Router handelt. Nun hab ich mir gedacht das es evtl. zu Problemen kommen würde wenn jetzt z.b. temporär die vpn Verbindung eines Routers ausfällt, würde der Router automatisch die bssid des Nachbar VPN Routers übernehmen. Kommt dann wieder der vpn des ersten Routers online würde somit automatisch eine loop zwischen zwei hoods entstehen. Ich bin mit gerade nicht ganz sicher wie man das vernünftig lösen kann. vg Tarek

4 11

[Fwd: [gluon] Writing a specification for l3roamd]
by Bjoern Franke 28 Dec '15

28 Dec '15

fyi -- xmpp bjo(a)schafweide.org

1 0

gluon Release
by Jan-Tarek Butt 28 Dec '15

28 Dec '15

Hi, das nächste gluon release wird weit bis vorraus sichtlich Anfang Februar verschoben. Daher werde ich die hood Änderungen auf gluon v2015.1.x portieren. vg Tarek

2 3

Plan für stabiles Netz
by Simon Kurka 22 Dec '15

22 Dec '15

Hallo zusammen, für das Hood-Setup sind zunächst 4 Hoods vorgesehen, eine fünfte soll folgen. Jede Hood soll mit zwei georedundanten Gateways ausgestattet werden. Mindestens einer von beiden Gateways sollte ein Dedicated Server sein. Um eine hochwertige und ausfallsichere Internetanbindung zu gewährleisten, soll jedes Gateway nach Möglichkeit alle zur Verfügung stehenden Internet-Exits nutzen können. Dafür stehen uns im Wesentlichen zwei Partner zur Verfügung: Freifunk Rheinland e. V. mit 6 Routern auf 3 Standorte verteilt und einer Gesamtbandbreite von 26 GBit/s sowie der Freie Netze e. V. in Berlin. AirVPN sollte nicht weiter genutzt werden, um weitere IP-Konflikte mit dem InterCity-VPN zu vermeiden. Mit IPv4 steht uns das private 10.18.0.0/16 Netz zur Verfügung. Osnabrück hat ein weiteres Netz 10.33.0.0/16 reserviert, das derzeit als Event-Netz in Osnabrück benutzt wird. Genutzt werden soll das Erstere. Jedem Gateway soll ein /22 (1024 Adressen) zugewiesen werden. Damit sind theoretisch 64 Gateways möglich, abzüglich Netzen für Dienste etc. Über Freifunk Rheinland erhalten wir das öffentlich geroutete Netz 2a03:2260:1001::/48. Jedem Gateway soll ein /54 zugewiesen werden. Jedem Client (als „Endkunden“) stünde dann theoretisch ein /64 zur Verfügung. Auch hier wären 64 Gateways abzüglich Netze für Dienste möglich, wie auch 1024 /64 Netze pro Gateway. Die eindeutige IPv6 Adresse kann weiterhin über SLAAC vom Client selbst gewählt werden. Hier wird die 48 Bit MAC-Adresse in den bis zu 64 Bit IPv6 Netz verarbeitet. Mit den übrigen 16 Bit des /64 kann der Client Spaß haben... who cares. Die Vergabe der ULA fd74:fdaa:9dc4::/48 kann aufgrund gleicher Netzgröße analog erfolgen. Derzeit stehen 7 Server als Gateway zur Verfügung. Um die 4 Hoods voll zu machen, brauchen wir noch einen Dedicated Server. Gibt es Vorschläge / Kontakte / Möglichkeiten? (Bedingung: Nicht Nürnberg, also nicht bei netcup.) Die Zuordnung sieht momentan wie folgt aus. Es wurde darauf geachtet Gateway-fähige Server in Privatbesitz am Standort des Eigners zu lassen. ffol: - srv03 (bytemine fra) - srv12 (myLoc dus) ffwtm: - srv10 (bytemine fra) - srv04 (netcup nürnberg) ffos: - srv06 (myLoc dus) - srv11 (bytemine fra) default: - srvXX () - srv08 (netcup nürnberg) Gibt es begründete andere Vorschläge? -- Viele Grüße, Simon

5 6

Re: [Dev] [Admin] Plan für stabiles Netz
by Jan-Tarek Butt 21 Dec '15

21 Dec '15

On 12/18/15 11:06, Clemens John wrote: > Am Donnerstag, 17. Dezember 2015, 00:29:34 schrieb Simon Kurka: >> Gibt es begründete andere Vorschläge? > > Ich habe die Folgebeiträge auch etwas überflogen und meine Anmerkung dazu ist: > bitte geht Schritt für Schritt vor und verliert euch nicht. > > Das Format zum Austausch der Hood-Daten muss natürlich alle Eventualitäten > vorsehen. Aber bei der konkreten Umsetzung sollte im ersten Schritt > ausschließlich die Umstellung des derzeitigen Systems auf das Hood-System > erfolgen. Also dass sich die Router aus einer bestimmten Region nicht mehr zu > einer zufälligen Supernode verbinden, sondern zu der ihrer Region > zugewiesenen. Es reicht 1 Hood mit einer Supernode, einem Exit-Gateway und 200 > Routern. Das bestehende Netz wird schritt für schritt in hoods aufgeteilt. Der Anfang wird wahrscheinlich in Wittmund/Whv gemacht. Aktuell bin ich gerade dabei ein Programm zu schreiben was die Supernode Zuteilung auf den Routern macht. > Wenn das auch nur annähernd Problemlos klappt (ich erinnere nochmal an die > Probleme mit dem Batman Update im Sommer), dann können wir alle anderen Punkte > wie Redundanz, Ausfallsicherheit, Peerings, Transitnetz etc. ganz in Ruhe > nachziehen. Hier mussten auf ein schlag alle Router auf eine Version updaten. vg Tarek

1 0

puppet module
by picard 20 Dec '15

20 Dec '15

moin, ich habe grade durch die puppet module geschaut, das schaut schon mal super aus! fehlen noch module? vnstat munin munin-node vim mc nginx vermisse ich noch gibt es eine liste? -- Gruß pic @ME https://wiki.nordwest.freifunk.net/picard

4 9

puppet
by Jan-Tarek Butt 20 Dec '15

20 Dec '15

Hi, aktueller stand ist das Eike heute Abend noch mal das OpenVPN Modul überarbeiten möchte. Simon hat sich in den letzten tagen in bir eingelesen und würde wohl gerne ein puppet modul für die Rheinland Anbindung realisieren wollen. Ich würde beginnen die Firmware soweit fertig zu stellen so das wir spätestens zum Kongress die ersten hoods aufbauen können. Ich würde vorschlagen das wir Morgen wenn es Eike und Simon zeitlich passt gegen 18Uhr eine Telko machen um gemeinsam weiter zu abernten und fragen zu klären. @Eike Simon: würde euch das passen? vg Tarek

5 11

dns
by Jan-Tarek Butt 16 Dec '15

16 Dec '15

Hi, die dns Konfiguration ist nun auf allen Superneodes fertig. es sollte jetzt überall aus dem Netz folgende domains aufrufbar sein: netmon.ffnw autoupdate.ffnw hood.ffnw und gesondert als speedtest: wget -O - speedtest.ffnw nun beginne ich mit der Implementierung des Gateway selectirungs Scripts für die einzelnen hoods. Sobald das ok für die IP configuration in puppet da ist wird morgen srv08 über puppet eingerichtet und die erste test hood in betrieb genommen. (vorausgesetzt es entstehen keine unerwarteten Fehler). Es sind jetzt noch ~14 Tage bis zur Deadline (10 Tage bis Congress beginn). Meinem Gefühl nach liegen wir gut im Zeitplan. vg Tarek

1 0