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
Ich glaube zwar, dass Wittmund + Oldenburg = 200 Peers nicht ganz hinkommt (vermute mehr).
Ansonsten +1 Am 16.03.2016 10:53 schrieb "Stefan via Dev" dev@lists.ffnw.de:
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 _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Zitat von Stefan via Dev dev@lists.ffnw.de: hört sich sehr gut an!
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.
hier noch mal gucken ob das passt.
Funktioniert OSPF für v6 nun? Ansonsten wie schon per Jabber besprochen: +1
Hey,
noch nicht ganz, pingbar sind die v6 Ip´s aber ein Trace geht nicht durch. Unerklärlich grad :D
Sonst lüpp alles!
Am 17.03.2016 um 12:31 schrieb Bjoern Franke via Dev:
Funktioniert OSPF für v6 nun? Ansonsten wie schon per Jabber besprochen: +1 _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
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.
Hier sollten wir noch mal überlegen, ob es evtl. möglich ist die Router mit einer Firmware <= 0.9 einfach am neuen Netz laufen zu lassen. Wenn wir die fastd keys und Ports nicht ändern sollte das keine Probleme stellen.
Vorteil dabei wäre das wir dann in Zukunft bei folgenden Server Umstellungen nicht auch ein älteres Setup berücksichtigen müssen.
vg Tarek
Hey,
könnte man ggf. übernehmen, jedoch hätten wir dann wieder Altes und neues Netz irgendwie vermischt. Ich persönlich würde dass nicht empfehlen. Das neue Netz ist wirklich sehr strukturiert aufgebaut.
Wir müssten den 04 nur am Netz lassen, damit offline Router eine neue Firmware noch erhalten können.
Die Umstellung auf dieses Setup sollte relativ einfach unstellbar sein und binnen 1 Woche alle Gateways ungestellt.
Vom Netzaufbau wären wir soweit fertig. Der Sourcecode ist jetzt erstmal in meinem Namespace zu finden: https://git.nordwest.freifunk.net/stefan6/puppet
Am 17. März 2016 20:15:36 MEZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
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.
Hier sollten wir noch mal überlegen, ob es evtl. möglich ist die Router mit einer Firmware <= 0.9 einfach am neuen Netz laufen zu lassen. Wenn wir die fastd keys und Ports nicht ändern sollte das keine Probleme stellen.
Vorteil dabei wäre das wir dann in Zukunft bei folgenden Server Umstellungen nicht auch ein älteres Setup berücksichtigen müssen.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Donnerstag, 17. März 2016, 20:49:15 CET schrieb Stefan via Dev:
Vom Netzaufbau wären wir soweit fertig. Der Sourcecode ist jetzt erstmal in meinem Namespace zu finden: https://git.nordwest.freifunk.net/stefan6/puppet
Hi,
bitte zieht die Sachen unbedingt direkt an den richtigen Namespace, sprich in die Puppet gruppe und nicht in irgendwelche zwischen Namespaces. Es ist jetzt schon schwer genug durchzublicken.
Viele Grüße Clemens
Hey,
dann hätten wir aber auf einmal mehrere puppet-data Module z.B. Das scheint mir ja auch nicht zielführend zu sein ;)
Stefan
Am 18.03.2016 um 15:58 schrieb Clemens John via Dev:
Am Donnerstag, 17. März 2016, 20:49:15 CET schrieb Stefan via Dev:
Vom Netzaufbau wären wir soweit fertig. Der Sourcecode ist jetzt erstmal in meinem Namespace zu finden: https://git.nordwest.freifunk.net/stefan6/puppet
Hi,
bitte zieht die Sachen unbedingt direkt an den richtigen Namespace, sprich in die Puppet gruppe und nicht in irgendwelche zwischen Namespaces. Es ist jetzt schon schwer genug durchzublicken.
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Am Freitag, 18. März 2016, 16:02:22 CET schrieb Stefan via Dev:
dann hätten wir aber auf einmal mehrere puppet-data Module z.B. Das scheint mir ja auch nicht zielführend zu sein ;)
Darum sollen die Änderungen ja auch direkt in die existierenden Repos in den master branch einfließen. Sprich die Änderungen müssen in das existierende Repo in den master branch gemerged werden.
Viele Grüße Clemens
Am Freitag, 18. März 2016, 16:02:22 CET schrieb Stefan:
dann hätten wir aber auf einmal mehrere puppet-data Module z.B. Das scheint mir ja auch nicht zielführend zu sein ;)
Hi,
stefan und ich habe gerade telefoniert und bringen das im Laufe des Abends unter einen Hut.
Viele Grüße Clemens
Hey zusammen,
der gesamte Code ist nun im Puppet Namespace. Clemens hatte sich angeboten, heute Abend oder die Tage einmal die Configs zusammenzufassen. Mit der Datenstruktur sind derzeit schon 2 Gateways seit 4 Tagen problemlos am Laufen.
Stefan
Am 18.03.2016 um 15:58 schrieb Clemens John via Dev:
Am Donnerstag, 17. März 2016, 20:49:15 CET schrieb Stefan via Dev:
Vom Netzaufbau wären wir soweit fertig. Der Sourcecode ist jetzt erstmal in meinem Namespace zu finden: https://git.nordwest.freifunk.net/stefan6/puppet
Hi,
bitte zieht die Sachen unbedingt direkt an den richtigen Namespace, sprich in die Puppet gruppe und nicht in irgendwelche zwischen Namespaces. Es ist jetzt schon schwer genug durchzublicken.
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey,
da wir nun einen funktionierenden Puppet Stand haben nun unsere Ideen zum weitern Vorgehen:
Im ersten Schritt würden wir eine Firmware bauen, in der 08 die Hood für Wittmund, Wilhelmshaven bildet. Zusätzlich würde eine Hood für Osnabrück aufgebaut, die auf 03 läuft und auf 10. Durch diesen Split würden 500 Router wegfallen.
Als defaulthood würden dann 04, 06, 11 und 12 definiert. Diese 4 Server würden dann mit den verbleibenden Routern klarkommen.
Wir würden durch die Ausgliederung auf einen Schlag das Netz halbieren, was Zielführend sein sollte.
Johannes und Ich haben den hoodselector hier schon getestet, dieser läuft auch problemlos.
Am 18. März 2016 17:17:22 MEZ, schrieb Stefan via Dev dev@lists.ffnw.de:
Hey zusammen,
der gesamte Code ist nun im Puppet Namespace. Clemens hatte sich angeboten, heute Abend oder die Tage einmal die Configs zusammenzufassen. Mit der Datenstruktur sind derzeit schon 2 Gateways seit 4 Tagen problemlos am Laufen.
Stefan
Am 18.03.2016 um 15:58 schrieb Clemens John via Dev:
Am Donnerstag, 17. März 2016, 20:49:15 CET schrieb Stefan via Dev:
Vom Netzaufbau wären wir soweit fertig. Der Sourcecode ist jetzt
erstmal in
meinem Namespace zu finden: https://git.nordwest.freifunk.net/stefan6/puppet
Hi,
bitte zieht die Sachen unbedingt direkt an den richtigen Namespace,
sprich in
die Puppet gruppe und nicht in irgendwelche zwischen Namespaces. Es
ist jetzt
schon schwer genug durchzublicken.
Viele Grüße Clemens
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hoi,
da wir nun einen funktionierenden Puppet Stand haben nun unsere Ideen zum weitern Vorgehen:
Im ersten Schritt würden wir eine Firmware bauen, in der 08 die Hood für Wittmund, Wilhelmshaven bildet. Zusätzlich würde eine Hood für Osnabrück aufgebaut, die auf 03 läuft und auf 10. Durch diesen Split würden 500 Router wegfallen.
Klingt gut.
Als defaulthood würden dann 04, 06, 11 und 12 definiert. Diese 4 Server würden dann mit den verbleibenden Routern klarkommen.
Wir würden durch die Ausgliederung auf einen Schlag das Netz halbieren, was Zielführend sein sollte.
Wie soll dann die weitere Ausgliederung aussehen, auf welchen Server kommt OL?
Johannes und Ich haben den hoodselector hier schon getestet, dieser läuft auch problemlos.
Was passiert denn mit Routern, die keine Geokoordinaten haben und wo der Autolocator ggf. nicht funktioniert (auf'm platten Land)?
gruß bjo
Am 24.03.2016 um 11:07 schrieb Bjoern Franke via Dev dev@lists.ffnw.de:
Hoi,
da wir nun einen funktionierenden Puppet Stand haben nun unsere Ideen zum weitern Vorgehen:
Im ersten Schritt würden wir eine Firmware bauen, in der 08 die Hood für Wittmund, Wilhelmshaven bildet. Zusätzlich würde eine Hood für Osnabrück aufgebaut, die auf 03 läuft und auf 10. Durch diesen Split würden 500 Router wegfallen.
Klingt gut.
Als defaulthood würden dann 04, 06, 11 und 12 definiert. Diese 4 Server würden dann mit den verbleibenden Routern klarkommen.
Wir würden durch die Ausgliederung auf einen Schlag das Netz halbieren, was Zielführend sein sollte.
Wie soll dann die weitere Ausgliederung aussehen, auf welchen Server kommt OL?
Im ersten Step bleibt Oldenburg in der Default Hood und wird später separiert. Nach dem ein Großteil in anderen Hoods ist und wir freie Server Kapazitäten haben.
Johannes und Ich haben den hoodselector hier schon getestet, dieser läuft auch problemlos.
Was passiert denn mit Routern, die keine Geokoordinaten haben und wo der Autolocator ggf. nicht funktioniert (auf'm platten Land)?
Das hatte Tarek schon mal beschrieben. Das ist die Aufgabe des Hoodselectors der macht das an Hand von mehreren Prüfungen. Wenn keine Koordinaten vorhanden sind, wird das Umfeld gescannt nach eventuell anderen Freifunk Routern. Ist dieses Erfolgreich so wird die Hood des anderen Routers übernommen. Identifizierung an Hand der BSSID Wird nix gefunden wird die Default Hood ausgewählt. Im Zweifelsfall falls keine Hood bestimmt werden kann, so landet der Router in der Default Hood.
Gruß Johannes
Default Hood, muss man dazu sagen, bedeutet: wähle zufällig irgendeine Hood. Es ist daher mehr ein default case, keine eigene Hood. Am 24.03.2016 11:13 schrieb "Johannes Rudolph via Dev" dev@lists.ffnw.de:
Am 24.03.2016 um 11:07 schrieb Bjoern Franke via Dev <dev@lists.ffnw.de :
Hoi,
da wir nun einen funktionierenden Puppet Stand haben nun unsere Ideen zum weitern Vorgehen:
Im ersten Schritt würden wir eine Firmware bauen, in der 08 die Hood für Wittmund, Wilhelmshaven bildet. Zusätzlich würde eine Hood für Osnabrück aufgebaut, die auf 03 läuft und auf 10. Durch diesen Split würden 500 Router wegfallen.
Klingt gut.
Als defaulthood würden dann 04, 06, 11 und 12 definiert. Diese 4 Server würden dann mit den verbleibenden Routern klarkommen.
Wir würden durch die Ausgliederung auf einen Schlag das Netz halbieren, was Zielführend sein sollte.
Wie soll dann die weitere Ausgliederung aussehen, auf welchen Server kommt OL?
Im ersten Step bleibt Oldenburg in der Default Hood und wird später separiert. Nach dem ein Großteil in anderen Hoods ist und wir freie Server Kapazitäten haben.
Johannes und Ich haben den hoodselector hier schon getestet, dieser läuft auch problemlos.
Was passiert denn mit Routern, die keine Geokoordinaten haben und wo der Autolocator ggf. nicht funktioniert (auf'm platten Land)?
Das hatte Tarek schon mal beschrieben. Das ist die Aufgabe des Hoodselectors der macht das an Hand von mehreren Prüfungen. Wenn keine Koordinaten vorhanden sind, wird das Umfeld gescannt nach eventuell anderen Freifunk Routern. Ist dieses Erfolgreich so wird die Hood des anderen Routers übernommen. Identifizierung an Hand der BSSID Wird nix gefunden wird die Default Hood ausgewählt. Im Zweifelsfall falls keine Hood bestimmt werden kann, so landet der Router in der Default Hood.
Gruß Johannes
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey,
ich denke das ist eine relativ einfach gestrickte Version der Umstellung.
durch das Vorgehen hätten wir aber auf Schlag 500 Router aus dem alten netz weg.
Am 24. März 2016 11:18:22 MEZ, schrieb Simon Kurka via Dev dev@lists.ffnw.de:
Default Hood, muss man dazu sagen, bedeutet: wähle zufällig irgendeine Hood. Es ist daher mehr ein default case, keine eigene Hood. Am 24.03.2016 11:13 schrieb "Johannes Rudolph via Dev" dev@lists.ffnw.de:
Am 24.03.2016 um 11:07 schrieb Bjoern Franke via Dev
<dev@lists.ffnw.de
:
Hoi,
da wir nun einen funktionierenden Puppet Stand haben nun unsere
Ideen
zum weitern Vorgehen:
Im ersten Schritt würden wir eine Firmware bauen, in der 08 die
Hood
für Wittmund, Wilhelmshaven bildet. Zusätzlich würde eine Hood für Osnabrück aufgebaut, die auf 03 läuft und auf 10. Durch diesen
Split
würden 500 Router wegfallen.
Klingt gut.
Als defaulthood würden dann 04, 06, 11 und 12 definiert. Diese 4 Server würden dann mit den verbleibenden Routern klarkommen.
Wir würden durch die Ausgliederung auf einen Schlag das Netz halbieren, was Zielführend sein sollte.
Wie soll dann die weitere Ausgliederung aussehen, auf welchen
Server
kommt OL?
Im ersten Step bleibt Oldenburg in der Default Hood und wird später separiert. Nach dem ein Großteil in anderen Hoods ist und wir freie
Server
Kapazitäten haben.
Johannes und Ich haben den hoodselector hier schon getestet,
dieser
läuft auch problemlos.
Was passiert denn mit Routern, die keine Geokoordinaten haben und
wo
der Autolocator ggf. nicht funktioniert (auf'm platten Land)?
Das hatte Tarek schon mal beschrieben. Das ist die Aufgabe des Hoodselectors der macht das an Hand von
mehreren
Prüfungen. Wenn keine Koordinaten vorhanden sind, wird das Umfeld gescannt nach eventuell anderen Freifunk Routern. Ist dieses Erfolgreich so wird die Hood des anderen Routers übernommen. Identifizierung an Hand der BSSID Wird nix gefunden wird die Default Hood ausgewählt. Im Zweifelsfall falls keine Hood bestimmt werden kann, so landet der Router in der Default Hood.
Gruß Johannes
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hey,
Ich würde erst mal eine hood z.b. Osnabrück oder wittmund ausrollen wollen um sicher zugehen, das eine hood mit mehr als 5 test Routern nicht zusammen bricht.
Ich weiß aktuell überhaupt nicht wie es Server seitig aus sieht aber wenn eurer seits der Status kommt das die hoods serverseitig einsatzbereit sind können wir ja zügig lost legen :)
Aktuell wird das ausrollen des hoodselectors durch ein kernelbug blockiert siehe thread: [Dev] Fwd: Nondeterministic image breakage [observed on TL-WR841N v5]
Sobald das Problem behoben ist oder ein funktionierender workaround existiert kann die nächste Firmware released werden.
vg Tarek
Hey zusammen,
wir haben jetzt seit knapp 2 Wochen 7 Testrouter auf einer Hood am laufen. Seit Dienstag laufen weiter 4 Geräte mit Hoodselector.
Von den Servern ist soweit alles fertig bis auf 2 Kleinigkeiten. Die schauen Simon und ich uns am Dienstag an - geht hier nur um DNS Foo. interne Urls wie autoupdater.ffnw werden jetzt auch zentral über das Powerdns auf srv01 abgebildet.
Wir warten hier im Endeffekt auf eine FW :) Nun zu meiner Frage: Könnten wir in der 0.9 direkt die Defaulthoods definieren und die erste hood? Die 1.0 sollte ja dann das fertige Hoodsystem enthalten.
Am 25. März 2016 02:03:24 MEZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hey,
Ich würde erst mal eine hood z.b. Osnabrück oder wittmund ausrollen wollen um sicher zugehen, das eine hood mit mehr als 5 test Routern nicht zusammen bricht.
Ich weiß aktuell überhaupt nicht wie es Server seitig aus sieht aber wenn eurer seits der Status kommt das die hoods serverseitig einsatzbereit sind können wir ja zügig lost legen :)
Aktuell wird das ausrollen des hoodselectors durch ein kernelbug blockiert siehe thread: [Dev] Fwd: Nondeterministic image breakage [observed on TL-WR841N v5]
Sobald das Problem behoben ist oder ein funktionierender workaround existiert kann die nächste Firmware released werden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Nun zu meiner Frage: Könnten wir in der 0.9 direkt die Defaulthoods definieren und die erste hood? Die 1.0 sollte ja dann das fertige Hoodsystem enthalten.
Nein, es muss erstmal der hoodselector mit einer default hood ausgerollt werden, um alle router mit dem hoodselector aus zustatten. Grund dafür ist das wenn direkt ein hood file mit anderen hoods released wird, entsteht der Fall das vpn Router vor mesh routern updaten und sich eine hood zuweisen, somit würden mesh Router ohne update offline bleiben. Wir sollten uns hier nach wie vor an die Milestons halten. Diese wurden von mehren Personen gut durch dacht und eine "Hauruck Aktion" kann schlimme folgen haben siehe das release 0.8 wo durch ungenügende test zu voreilig ein kernel bug mit released wurde.
Schöne Grüße Tarek
Hi,
ja, da gebe ich dir Recht. Also würde der Hoodselector mit den Defaulthoods in 0.8.1 released und in der nachfolgenden Version die ersten Hoods?
Hört sich gut an :)
Am 25. März 2016 11:28:27 MEZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Nun zu meiner Frage: Könnten wir in der 0.9 direkt die Defaulthoods definieren und die erste hood? Die 1.0 sollte ja dann das fertige Hoodsystem enthalten.
Nein, es muss erstmal der hoodselector mit einer default hood ausgerollt werden, um alle router mit dem hoodselector aus zustatten. Grund dafür ist das wenn direkt ein hood file mit anderen hoods released wird, entsteht der Fall das vpn Router vor mesh routern updaten und sich eine hood zuweisen, somit würden mesh Router ohne update offline bleiben. Wir sollten uns hier nach wie vor an die Milestons halten. Diese wurden von mehren Personen gut durch dacht und eine "Hauruck Aktion" kann schlimme folgen haben siehe das release 0.8 wo durch ungenügende test zu voreilig ein kernel bug mit released wurde.
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Moin
Wie wir sie nennen ist mir egal. Ob 0.8.1 oder 0.9
Wenn ich den Fehler richtig beobachte haben sie ja nun eine Lösung gefunden und in Kürze Gluon 2016.1.3 releasen
https://github.com/freifunk-gluon/gluon/issues/669
Dann könnten wir sehr zeitnah eine neue Firmware verteilen mit dem Hoodselector
Gruß
Johannes
Am 25.03.2016 um 11:32 schrieb Stefan via Dev dev@lists.ffnw.de:
Hi,
ja, da gebe ich dir Recht. Also würde der Hoodselector mit den Defaulthoods in 0.8.1 released und in der nachfolgenden Version die ersten Hoods?
Hört sich gut an :)
Am 25. März 2016 11:28:27 MEZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de: Hi,
Nun zu meiner Frage: Könnten wir in der 0.9 direkt die Defaulthoods definieren und die erste hood? Die 1.0 sollte ja dann das fertige Hoodsystem enthalten.
Nein, es muss erstmal der hoodselector mit einer default hood ausgerollt werden, um alle router mit dem hoodselector aus zustatten. Grund dafür ist das wenn direkt ein hood file mit anderen hoods released wird, entsteht der Fall das vpn Router vor mesh routern updaten und sich eine hood zuweisen, somit würden mesh Router ohne update offline bleiben. Wir sollten uns hier nach wie vor an die Milestons halten. Diese wurden von mehren Personen gut durch dacht und eine "Hauruck Aktion" kann schlimme folgen haben siehe das release 0.8 wo durch ungenügende test zu voreilig ein kernel bug mit released wurde.
Schöne Grüße Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
ja, da gebe ich dir Recht. Also würde der Hoodselector mit den Defaulthoods in 0.8.1 released und in der nachfolgenden Version die ersten Hoods?
Ne, es wird aktuell eine 0.8.1 mit geplanten kernel patch und geolocator patch geliefert und dann die 0.9 mit dem hoodselector. Anschließend folgt 1.0 mit der ersten hood. So ist aktuell der plan.
Schöne Grüße :) Tarek
Am 25.03.2016 um 12:54 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
ja, da gebe ich dir Recht. Also würde der Hoodselector mit den Defaulthoods in 0.8.1 released und in der nachfolgenden Version die ersten Hoods?
Ne, es wird aktuell eine 0.8.1 mit geplanten kernel patch und geolocator patch geliefert und dann die 0.9 mit dem hoodselector. Anschließend folgt 1.0 mit der ersten hood. So ist aktuell der plan.
Ja können wir auch so machen. Also warten wir gerade nur auf das Gluon Release, Richtig?
Schöne Grüße :) Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
gibt's hier von deiner Seite weitere Erkenntnisse, wann wir ungefähr eine 0.8.1 bekommen könnten? :)
Am 25. März 2016 14:51:57 MEZ, schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Ja können wir auch so machen. Also warten wir gerade nur auf das Gluon Release, Richtig?
Jop, hab heute auch schon auf das issue reagiert.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
gibt's hier von deiner Seite weitere Erkenntnisse, wann wir ungefähr eine 0.8.1 bekommen könnten? :)
Nein der bug ist nach wie vor offen.
https://github.com/freifunk-gluon/gluon/issues/669
vg Tarek
Hi,
Default Hood, muss man dazu sagen, bedeutet: wähle zufällig irgendeine Hood. Es ist daher mehr ein default case, keine eigene Hood.
Das ist so noch nicht implementiert. Aktuell verbindet sich der Router noch zu einer default hood. Die default hood besteht aus den aktuellen Servern.
vg Tarek
-
Bjoern Franke -
Clemens John -
Jan-Tarek Butt -
Johannes Rudolph -
picard -
Simon Kurka -
Stefan