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
Hi,
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
Aktuell bin ich noch dabei den gwselector zu ende zu schreiben. Auf den 32c3 wird es wahrscheinlich zum release kommen. Sobald der gwselector fertig ist. Würde ich ausführlich auf die Mail antworten. bei Puppet muss auch noch ein wenig was gemacht werden, bevor die erste hood wirklich in produktiv betrieb gehen kann. Dann können wir uns auch Gedanken über den changelog machen und ein Verwaltungskonzept. vg Tarek
Hi, danke für die Antwort. Vielleicht könnte man die User auch schon einmal über die anstehenden Neuerungen vorab Informieren dass diese sehen, dass sich was tut. Bezüglich Puppet, vielleicht lässt sich ja hier abends irgendwann mal eine telko vereinbaren, für die, die hiermit noch nichts gemacht haben. Meiner Meinung nach ist es wichtig, dass alle Admins vor dem Release hier Erfahrungen haben. Am 26. Dezember 2015 14:28:19 MEZ, schrieb Jan-Tarek Butt <tarek@ring0.de>:
Hi,
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
Aktuell bin ich noch dabei den gwselector zu ende zu schreiben. Auf den 32c3 wird es wahrscheinlich zum release kommen. Sobald der gwselector fertig ist. Würde ich ausführlich auf die Mail antworten. bei Puppet muss auch noch ein wenig was gemacht werden, bevor die erste hood wirklich in produktiv betrieb gehen kann.
Dann können wir uns auch Gedanken über den changelog machen und ein Verwaltungskonzept.
vg Tarek
------------------------------------------------------------------------
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-- vg Stefan
Hi,
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 Okay, ich glaube aber für den Endnutzer der Webseite reichen erstmal die Punkte, dass wir die Serververwaltung per Puppet automatisieren und unser nordwest-gebiet unterteilen in kleinerer hoods, um die grundlast (die deutlich mehr als linear zur netzgröße wächst) deutlich zu reduzieren. vielleicht noch der Hinweis, dass wir übergangsweise die hoods voneinander isoliert, d.h. ohne routing dazwischen betreiben werden, weil wir erstmal die hoods für sich laufen haben wollten und das andere zeitlich nicht soooo drängt.
- Zugriffsrechte: Wir sollten überlegen, ob es nicht sinnvoller wäre, die Hood erst zu releasen wenn auch alle Admins Zugang dazu haben. Zu den Servern werden die admins - denke ich - direkt wieder zugang bekommen, allerdings ganz klar unter der auflage bei problemen sehr sehr besonnen und systematisch bei etwaigen fehlern die Suche zu betreiben. Da die config weitestgehend über puppet läuft, wäre eine manuelle änderung auf einem server in einem bereich, den Puppet nicht verwaltet wieder eine richtig unangenehme fehlerquelle. Und Puppet sollte sich normalerweise darum kümmern, dass das system dauerhaft in dem definierten funktionsfähigen zustand läuft. Insbesondere, da der Puppetagent regelmäßig (ala cron Dienste und configs checkt und ggf. startet und wiederherstellt.
Was den Puppetmaster anbetrifft, würde ich den Zugang *zunächst* streng handeln, bis wir eine art mini-schulung mit denjenigen, die Zugang haben wollen, durchgeführt und eine vernünftige versionsverwaltung für die konfigurations-dateien auf dem server aufgebaut haben. Puppet grundsätzlich ist nicht sonderlich schwer, aber es hat hier und da - wie jedes system - ein paar fallstricke. In einem ersten Schritt würde ich vorschlagen, dass diejenigen interessierten zugang zum Git-repo bekommen, in dem momentan die config entwickelt wird. dieses enthält zur zeit auch vertrauliche daten wie zB die fastd-private keys der server und openvpn-cert-dateien, weshalb es derzeit nicht öffentlich ist. wie das dann zukünftig gehandelt wird, müssten wir dann mal überdenken (vllt. mit privaten git submodules für die sensiblen daten?)
- Einteilung der Hoods, damit man den Nutzern hierdrüber auch Details nennen kann.
Unter hood.ffnw findet sich der hoodgen (hood-generator) den ich entwickelt habe und mit welchem man die grenzen, bssid, pubkeys und server der hoods festlegen kann. Tarek hatte bisher wimni ganz grob erstmal 3 waagerechte streifen angedacht, einen um Oldenburg, einen um Wittmund und einen um Osnabrück. Für den start ganz sinnvoll, denke ich, ggf. muss das später nochmal geändert werden.
Vielleicht fällt jemandem ja noch mehr ein -- vg Stefan
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi, es soll auch ersteinmal nur eine ganz grobe Zusammenfassung für die Nutzer geben. Die detaillierten Vorgehensweisen kann man ja später einmal beschreiben. Bezüglich der server geht es mir auch in erster Linie um die neuen supernodes. Wir haben es ja hier häufiger gehabt das einfach mal eine defaultroute verschwunden war, obwohl diese auch im jetzigen Setup mit Scripten getestet werden. Nur für den Fall, das ein Supernode spinnt. Kann man die Karte auch eventuell in einer netten visuellen Darstellung exportieren? So eine Grafik eignet sich ja auch für Blogeinträge :-) Am 26. Dezember 2015 19:53:12 MEZ, schrieb Eike Baran <derbaranator@gmail.com>:
Hi,
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 Okay, ich glaube aber für den Endnutzer der Webseite reichen erstmal die Punkte, dass wir die Serververwaltung per Puppet automatisieren und unser nordwest-gebiet unterteilen in kleinerer hoods, um die grundlast (die deutlich mehr als linear zur netzgröße wächst) deutlich zu reduzieren. vielleicht noch der Hinweis, dass wir übergangsweise die hoods voneinander isoliert, d.h. ohne routing dazwischen betreiben werden, weil wir erstmal die hoods für sich laufen haben wollten und das andere zeitlich nicht soooo drängt.
- Zugriffsrechte: Wir sollten überlegen, ob es nicht sinnvoller wäre, die Hood erst zu releasen wenn auch alle Admins Zugang dazu haben. Zu den Servern werden die admins - denke ich - direkt wieder zugang bekommen, allerdings ganz klar unter der auflage bei problemen sehr sehr besonnen und systematisch bei etwaigen fehlern die Suche zu betreiben. Da die config weitestgehend über puppet läuft, wäre eine manuelle änderung auf einem server in einem bereich, den Puppet nicht verwaltet wieder eine richtig unangenehme fehlerquelle. Und Puppet sollte sich normalerweise darum kümmern, dass das system dauerhaft in dem definierten funktionsfähigen zustand läuft. Insbesondere, da der Puppetagent regelmäßig (ala cron Dienste und configs checkt und ggf. startet und wiederherstellt.
Was den Puppetmaster anbetrifft, würde ich den Zugang *zunächst* streng handeln, bis wir eine art mini-schulung mit denjenigen, die Zugang haben wollen, durchgeführt und eine vernünftige versionsverwaltung für die konfigurations-dateien auf dem server aufgebaut haben. Puppet grundsätzlich ist nicht sonderlich schwer, aber es hat hier und da - wie jedes system - ein paar fallstricke.
In einem ersten Schritt würde ich vorschlagen, dass diejenigen interessierten zugang zum Git-repo bekommen, in dem momentan die config entwickelt wird. dieses enthält zur zeit auch vertrauliche daten wie zB die fastd-private keys der server und openvpn-cert-dateien, weshalb es derzeit nicht öffentlich ist. wie das dann zukünftig gehandelt wird, müssten wir dann mal überdenken (vllt. mit privaten git submodules für die sensiblen daten?)
- Einteilung der Hoods, damit man den Nutzern hierdrüber auch Details nennen kann.
Unter hood.ffnw findet sich der hoodgen (hood-generator) den ich entwickelt habe und mit welchem man die grenzen, bssid, pubkeys und server der hoods festlegen kann. Tarek hatte bisher wimni ganz grob erstmal 3 waagerechte streifen angedacht, einen um Oldenburg, einen um Wittmund und einen um Osnabrück. Für den start ganz sinnvoll, denke ich, ggf. muss das später nochmal geändert werden.
Vielleicht fällt jemandem ja noch mehr ein -- vg Stefan
_______________________________________________ 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
-- vg Stefan
Moin Karten bin ich Experte drin ;) Brauche nur roh Daten Gruß Johannes Von meinem iPhone gesendet
Am 26.12.2015 um 20:24 schrieb Stefan <stefan@osnabrueck.freifunk.net>:
Hi,
es soll auch ersteinmal nur eine ganz grobe Zusammenfassung für die Nutzer geben. Die detaillierten Vorgehensweisen kann man ja später einmal beschreiben.
Bezüglich der server geht es mir auch in erster Linie um die neuen supernodes. Wir haben es ja hier häufiger gehabt das einfach mal eine defaultroute verschwunden war, obwohl diese auch im jetzigen Setup mit Scripten getestet werden. Nur für den Fall, das ein Supernode spinnt.
Kann man die Karte auch eventuell in einer netten visuellen Darstellung exportieren? So eine Grafik eignet sich ja auch für Blogeinträge :-)
Am 26. Dezember 2015 19:53:12 MEZ, schrieb Eike Baran <derbaranator@gmail.com>:
Hi,
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 Okay, ich glaube aber für den Endnutzer der Webseite reichen erstmal die Punkte, dass wir die Serververwaltung per Puppet automatisieren und unser nordwest-gebiet unterteilen in kleinerer hoods, um die grundlast (die deutlich mehr als linear zur netzgröße wächst) deutlich zu reduzieren. vielleicht noch der Hinweis, dass wir übergangsweise die hoods voneinander isoliert, d.h. ohne routing dazwischen betreiben werden, weil wir erstmal die hoods für sich laufen haben wollten und das andere zeitlich nicht soooo drängt.
- Zugriffsrechte: Wir sollten überlegen, ob es nicht sinnvoller wäre, die Hood erst zu releasen wenn auch alle Admins Zugang dazu haben. Zu den Servern werden die admins - denke ich - direkt wieder zugang bekommen, allerdings ganz klar unter der auflage bei problemen sehr sehr besonnen und systematisch bei etwaigen fehlern die Suche zu betreiben. Da die config weitestgehend über puppet läuft, wäre eine manuelle änderung auf einem server in einem bereich, den Puppet nicht verwaltet wieder eine richtig unangenehme fehlerquelle. Und Puppet sollte sich normalerweise darum kümmern, dass das system dauerhaft in dem definierten funktionsfähigen zustand läuft. Insbesondere, da der Puppetagent regelmäßig (ala cron Dienste und configs checkt und ggf. startet und wiederherstellt.
Was den Puppetmaster anbetrifft, würde ich den Zugang *zunächst* streng handeln, bis wir eine art mini-schulung mit denjenigen, die Zugang haben wollen, durchgeführt und eine vernünftige versionsverwaltung für die konfigurations-dateien auf dem server aufgebaut haben. Puppet grundsätzlich ist nicht sonderlich schwer, aber es hat hier und da - wie jedes system - ein paar fallstricke.
In einem ersten Schritt würde ich vorschlagen, dass diejenigen interessierten zugang zum Git-repo bekommen, in dem momentan die config entwickelt wird. dieses enthält zur zeit auch vertrauliche daten wie zB die fastd-private keys der server und openvpn-cert-dateien, weshalb es derzeit nicht öffentlich ist. wie das dann zukünftig gehandelt wird, müssten wir dann mal überdenken (vllt. mit privaten git submodules für die sensiblen daten?)
- Einteilung der Hoods, damit man den Nutzern hierdrüber auch Details nennen kann.
Unter hood.ffnw findet sich der hoodgen (hood-generator) den ich entwickelt habe und mit welchem man die grenzen, bssid, pubkeys und server der hoods festlegen kann. Tarek hatte bisher wimni ganz grob erstmal 3 waagerechte streifen angedacht, einen um Oldenburg, einen um Wittmund und einen um Osnabrück. Für den start ganz sinnvoll, denke ich, ggf. muss das später nochmal geändert werden.
Vielleicht fällt jemandem ja noch mehr ein -- vg Stefan
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
-- vg Stefan _______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Wo mache ich das? Komme ich da aus dem Internet ran oder muss ich dafür im Freifunk Netz sein ?! Habe erst im Januar wieder Zugriff darauf da ich gerade unterwegs bin Von meinem iPhone gesendet
Am 26.12.2015 um 22:09 schrieb Eike Baran <derbaranator@gmail.com>:
Karten bin ich Experte drin ;) Brauche nur roh Daten
beim klick auf "export to json" enthält das erzeugte json ein array mit koordinaten-paaren, die jeweils die south-west und north-east ecke jeder definierten Box einer Hood enthalten
Gruß, Eike
_______________________________________________ Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi, ich bin gerade dabei mit Tim am hood konzept weiter rum zu feilen. Die Ergebnisse bzw. Diskussion sind hier einsehbar [0]. vg Tarek [0] https://wiki.nordwest.freifunk.net/Entwicklung/hoodsystem/ideen
Hi, Stefan hat gerade ein weteren evtl. sehr hilfreiches repo von den Münchner gefunden. Die haben bereits alles bzgl. puppet und hierra im git. https://github.com/freifunkMUC/puppet-ffm vg Tarek
Am Samstag, 26. Dezember 2015, 13:57:00 CET schrieb Stefan:
Vielleicht fällt jemandem ja noch mehr ein
Hi, ich habe hier eine Übersicht angelegt in der wichtige Dokumente zum Hood-Thema zusammengestellt sind: https://pad.ffnw.de/p/hoods LG Clemens
Hi,
ich habe hier eine Übersicht angelegt in der wichtige Dokumente zum Hood-Thema zusammengestellt sind: https://pad.ffnw.de/p/hoods
Magst du das in ein freifunk.net pad packen das ffnw.de pad ist extrem lahm... und läst sich nicht öffnen. vg Tarek
participants (5)
-
Clemens John -
Eike Baran -
Jan-Tarek Butt -
Johannes Rudolph -
Stefan