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
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
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
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
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
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
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
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
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
