Moin,
in abspreache mit Stefan bastel ich gerade am ersten Hoodfile.
Ich bin über den Punkt Mesh BSSID gestolpert.
Aktuell ist diese bei uns "02:CA:FF:EE:BA:BE" und für die Default Hood
kann diese auch so bleiben.
Kann ich einfach nach freidünken für Hoods andere BSSID vergeben, oder
gibt es da vorgaben die ich noch nicht kenne`?!
Ansonsten mach ich einfach:
02:CA:FF:EE:BA:BE -> Default Hood
02:CA:FF:EE:BA:B0 -> Hood Osnabrück
02:CA:FF:EE:BA:B1 -> Hood Butjardingen/Friesland/Wilhelmshaven/Wittmund
und die später folgenden Hoods werden weiter hochgezählt.
02:CA:FF:EE:BA:B2
02:CA:FF:EE:BA:B3
02:CA:FF:EE:BA:B4
02:CA:FF:EE:BA:B5
02:CA:FF:EE:BA:B6
02:CA:FF:EE:BA:B7
02:CA:FF:EE:BA:B8
02:CA:FF:EE:BA:B9
Meinungen / Wünsche / Kritik / Lob / Tadel / Zustimmung / Ablehnung?!
Keine Reaktion deute ich mal als Zustimmung
Gruß
Johannes
Hallo Tarek,
ich habe die MTU-detection wie besprochen als Daemon implementiert und
würde sie jetzt gerne testen.
Kennst Du jemanden mit einem DSLite-Anschluss und genau diesem Problem,
bei dem ich mich temporär
auf dem Router einloggen (ssh) könnte ?
Gruß Tim
Hey zusammen,
in den vergangenen Tagen hat sich bei den Hoods sehr viel im Hintergrund
getan - mittlerweile haben wir eine Firmware gebaut - als Testing
natürlich - mit der sich die Router ohne Probleme im neuen Hood-Netz
verbinden und Clients dort alles machen können.
Den Source für die einzelnen Module werden Simon und ich heute
nocheinmal updaten und auf Gitlab rüberziehen.
Die Puppet Module sind soweit fertiggeschrieben und funktioniert - im
nächsten Schritt sollten wir alle auf einen Nenner kommen, wie wir das
Netz gut & strukutiert umstellen können.
Ich hatte mir hier schon meine Gedanken gemacht und mit dem ein oder
anderen kurz gesprochen. Mein Vorschlag wäre folgender:
Wir würden srv08 & srv03 als eigenständige Hoods vorbereiten, Wittmund
und Oldenburg darauf umziehen, sodass im alten Setup etwa 200 Peers frei
werden. Danach können wir jedes Gateway (srv06, 10, 11, 12) nach und
nach vom Netz nehmen und auf Puppet umstellen. Dadurch hätten wir
kurzerzeit 2 Netze, jedoch blieben alle Router online.
Als weiteren Schritt sollten wir darüber nachdenken, den srv04
ersteinmal so online zulassen, damit sich alte Router hier weiterhin
verbinden können und ein Firmware Update auf > 0.6.2 erhalten. Später
wenn keinerlei Peers mehr vorhanden sind, könnte dieser auch umgezogen
werden.
Das dynmaische Routing mit OSPF läuft auch schon, sprich die Server
erkennen ob diese einen direkten Exit zum Rheinland haben oder nicht.
Ist letzteres der Fall, würde die Default Route auf den am wenigsten
genutzten Exit umgestellt.
Ich hoffe, dass viele meine Meinung hier teilen, denn diese Umstellung
haben wir bei dem Batman 2014 > 2015 Update schon so vollzogen und das
Ganze war ja vo Erfolg gekrönt.
Viele Grüße,
Stefan
Hi,
ich leite das mal eben auch hier weiter...
---------- Weitergeleitete Nachricht ----------
Betreff: Merging User-Repo
Datum: Freitag, 18. März 2016, 21:54:30 CET
Von: Clemens John <clemens.john(a)floh1111.de>
An: dev(a)simon.kurka.cc, stefan(a)osnabrueck.nordwest.freifunk.net
Hi Simon und Stefan,
ich habe die Repos von Simon, die Stefan heute ins Gitlab gezogen hat, als
Submodule im Puppet Repo hinzugefügt und das Data Repo gemerged. Das Network
Repo habe ich komplett ersetzt. Beim User-Repo treten allerdings Konflikte auf,
bei denen ich nicht genau weiß, was am sinnvollsten ist. Simon wenn du dort
einmal nachsehen könntest wäre das super.
Der Master von diesem Repo: https://git.nordwest.freifunk.net/ffnw-puppet/
puppet-user-new soll in den Master dieses Repos: https://
git.nordwest.freifunk.net/ffnw-puppet/puppet-user gemerged werden.
Der passende Merge dazu geht folgendermaßen:
# git clone --recursive git@git.nordwest.freifunk.net:ffnw-puppet/puppet.git
# cd puppet/environments/production/modules/user/
# git checkout master
# git remote add simon git@git.nordwest.freifunk.net:ffnw-puppet/puppet-user-
new.git
# git fetch simon
# git branch simon-user simon/master
# git merge simon-user
Referenzen:
http://blog.caplin.com/2013/09/18/merging-two-git-repositories/
Beim Mergen treten allerdings Konflikte auf die du dir einmal ansehen und
auflösen müsstest. Über kurze Rückmeldung würde ich mich freuen. Wenn wir damit
durch sind dürften alle Repos umgezogen sein.
Viele Grüße
Clemens
-------------------------------------------------------------
Ahoi,
ich habe die osterliche Zeit genutzt, um ein fpm-cook-recipe für
batman-adv-dkms zu schreiben. Im Repo haben wir nun ein 2016.0-DKMS-
Paket für amd64:
# [freight] adding batman-adv-dkms_2016.0-2_amd64.deb to pool
vg
bjo
--
xmpp bjo(a)schafweide.org
Hallo Leute,
ich hab man 'ne ganz blöde Frage:
Wie wird bei den Routern die Namensauflösung durchgeführt ?
Die resolv.conf zeigt auf localhost. Der dnsmasq scheint nichts zu tun.
Wenn ich z.B. nslookup srv06.ffnw.de ausführe, bekomme ich kein Ergebnis.
Server: 127.0.0.1
Address 1: 127.0.0.1 localhost
nslookup: can't resolve 'srv06.ffnw.de': Name or service not known
Wie wird von den fastd-servern die IP ermittelt, wenn in der
Konfiguration nur der Name steht ?
Irgendwas übersehe ich hier ;-)
Gruß Tim
Hey,
ich hatte gerade schon kurz mit Tarek gesprochen. Ich fände es sinnvoll, wenn die nächste Firmware direkt die 0.9 sein würde, in der ein Autolocaterfix und der Hoodselector implementiert sein würden.
Eure Meinung dazu?
@Tarek: Denkst du noch an die Implementierung des site_codes, je nachdem welche Hood gewählt wurde das dieser auf die in der hood.json Datei definierten Namen geswitched wird? Dadurch können wir nachher einfacher im Monitoring nach Hoods selektieren.
--
vg
Stefan
