- Dev - Freifunk Nordwest

Review und Milestones für die Hoods
by Clemens John 08 Jan '16

08 Jan '16

Hi, ich habe heute Nachmittag ein (Code-)Review des aktuellen Standes bezüglich der Hoods gemacht. Den Puppet-Teil habe ich dabei allerdings ausgeklammert. Ich habe mir insbesondere die Bereiche Hoodgen, Hoodfile und Gwselector angesehen. Das sieht ja schon echt gut aus! Um den Überblick zu behalten habe ich ein Dokument mit Dokumentation zum aktuellen Stand erstellt: * https://pad.ffnw.de/p/hoods-umsetzung-v1 Ich habe außerdem für alle drei Bereiche Tickets mit Punkten angelegt, die mir aufgefallen sind. Diese habe ich in Milestones gesammelt: * Hoodgen: https://git.nordwest.freifunk.net/baranator/hoodgen/milestones/1 * Hoodfile: https://git.nordwest.freifunk.net/ffnw/packages/milestones/4 * Gwselector: https://git.nordwest.freifunk.net/ffnw/packages/milestones/3 Mir hilft das zumindest den aktuellen Stand zu verstehen. Bisschen Probleme hatte ich da noch beim Fallback-Modus des Gwselectors aber da hilft Tarek mir evtl. nochmal. Oder müssen wir uns den Fallback allgemein nochmal ansehen? Viele Grüße Clemens

2 1

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

Aufgaben für die Puppet Umstellung
by Jan-Tarek Butt 06 Jan '16

06 Jan '16

Hallo zusammen, diese Mail soll eine liste von Entwicklungsaufgaben beinhalten die in eigene Projekte gefasst werden können. Falls jemand zeit und Lust hat, sich einzelne aufgaben raus zu picken kann sich gerne melden. Projekt 1: packages für unser debian ffnw repo erstellen. Unter der Domain http://repo.ffnw.de/ führen wir ein eigenes ffnw repo. Folgende Packages werden für das repo benötigt: "fastdtop" und "fastd-statistics". Ein benötigtes python module ist "npyscreen" dazu müsste auch ein package gebaut werden. Die o.g. tools bieten den admins Unterstützung zur Fehler Analyse. link zu den tool quellen: https://github.com/ffrl/ff-tools/tree/master/fastd "batctl" Version 2015.1. Batctl ist das verwaltungs tool für Batman-adv link zu den tool quellen: https://downloads.open-mesh.org/batman/stable/sources/batctl/ Wichtig ist die version batctl 2015.1 Eine kurtze doku zum erstellen von packages findet ihr hier: https://wiki.nordwest.freifunk.net/Admin-Bereich/services-doku/packages Zitat von Bjo: Für "Wie baue ich das Paket selbst" studiere bitte die Debian- Paketerstellungsseminare 1-3 (oder auch: Wie man PKGBUILDs lieben lernt). Projekt 2: Manifest identisch dem firmware manifest für die hoodfiles ertellen. Es wird ein Makefile für das erstellen eines Manifests der hood.json datein benötigt hier ist es wichtig das ähnlich wie bei gluon auch unterschiedliche branches existieren können also z.B. stable und testing. In dem Makefile sollte dann denke ich auch noch ein json validator eingebaut sein. Beides sind aufgaben die meinerseits nach dem gwselector anstehen. Besonders das 2.Projekt ist für die Umstellung auf puppet essentiell und würde eine Verzögerung bis voraussichtlich ende Jannuar / Mitte Februar erzeugen. vg Tarek

3 3

Fwd: [Diskussion-KtT] Vortrag: Einführung in git
by Jan-Tarek Butt 05 Jan '16

05 Jan '16

Hi, für die, die Interesse haben sich in der Entwicklung zu beteiligen. Es wird im Mainframe (der Oldenburger Hackerspace) ein Vortrag zur Einführung in git geben. Git ist ein versions-verwaltungs-programm was ein essentielles Entwicklungstool bei uns ist. vg Tarek -------- Forwarded Message -------- Subject: [Diskussion-KtT] Vortrag: Einführung in git Date: Sun, 3 Jan 2016 20:48:55 +0100 From: Sebastian Reichel <sre(a)kreativitaet-trifft-technik.de> Reply-To: Allgemeine Diskussion Kreativität trifft Technik e.V. <diskussion(a)kreativitaet-trifft-technik.de> To: KtT Diskussion <diskussion(a)kreativitaet-trifft-technik.de> Hi, Der nächste Vortrag findet am folgenden Samstag, den 09.01.2016 um 19:00 statt. Thema ist dieses mal eine Einführung in Git. Diese soll zunächst in Vortragsform erfolgen, um dann an den Notebooks der Teilnehmer git zu installieren und mit diesem zu arbeiten. Termin 09.01.2016 19:00 Thema: Einführung in Git Referent: sre https://www.kreativitaet-trifft-technik.de/talk/git.html -- Sebastian

4 6

Puppet Datenstruktur
by Eike Baran 04 Jan '16

04 Jan '16

Hallo, tl;dr: wer ahnung von puppet hat, möge sich mal das schaubild unter https://wiki.nordwest.freifunk.net/Puppet ansehen und beurteilen bzw. ggf. verbessern/alternativen vorschlagen. Alle anderen dürfen natürlich gerne aus Interesse mitlesen oder es ignorieren, ich wollte nur mal die aktuellen Überlegungen kommunizieren. wie ihr ja wisst, sind wir nun seit einigen Wochen dabei, die Verwaltung der Server durch Puppet übernehmen zu lassen. Grundsätzlich bietet Puppet dafür auch tolle Möglichkeiten, jedoch bin ich nun auch an einigen Stellen an Puppets, bzw. genauer gesagt Hieras Grenzen gestoßen. In Kürze ist Hiera eine art Datenbank, die auf *.yaml-Dateien basiert und die Konfigurationsdaten für die sogn. Puppet-Module enthält, welche wiederum jeweils eine Funktionseinheit eines Servers darstellen (zB apt-Paket und dessen Konfiguration). Die Puppet-Module enthalten also entsprechende Templates für die Konfigurationsdateien, die genauen, teils universellen (zB MTU, ssh-keys oder interface-namen), teils serverspezifischen Werte (zB Adressbereiche oder fastd-private-key). Gemäß einer definierbaren Reihenfolge (einer HIERArchie) läd hiera bei einem puppet-Durchlauf nun die korrekten werte aus der datenbank. So schaut hier zunächst, ob es node-spezifische Werte (in den srvXX.ffnw.de.yaml-Dateien) gibt. Falls nein, geht es in der Hierarchie eine ebene abwärts und es werden die allgemeingültigen Werte (aus der Datei common.yaml) geliefert. Wie gesagt, grundsätzlich klingt das sehr fein, der Teufel steckt aber in den Details: Es gibt im Grunde 3 verschiedene Lookup-Typen in hiera: hiera(), hiera_merge() und hiera_hash(). Verwendet wird meist der erste, welcher genau einen Treffer zu dem gesuchten key liefert, nämlich den, der in der Hierarchie am weitesten oben steht. Dummerweise gibt es Situationen, da reicht das nicht bzw. führt zu redundanzen und doppelt eingetragenen werten, die natürlich, was die Wartung angeht, scheiße sind. Beispiel: Für die Konfiguration von dhcp über dnsmasq muss in Hiera ein Datensatz liegen, der im yaml-Format etwa so aussieht: dnsmasq: dhcp_range_start: 192.168.0.10 dhcp_range_end: 192.168.0.100 lease_time: 15m Hierbei sind die Grenzen des Ranges natürlich serverspezifisch, die lease_time aber tendenziell auf allen Servern gleich und würde in der serverspezifischen hiera-datei diese nur künstlich aufblasen. Mit hiera_hash() kann man nun folgendes tun: man definiert in common.yaml: dnsmasq: lease_time: 15m und in srvXX.ffnw.de.yaml: dnsmasq: dhcp_range_start: 192.168.0.10 dhcp_range_end: 192.168.0.100 Ruft man nun in einem Modul hiera_hash('dnsmasq') auf, erhält man ein Objekt, was den obigen vollständigen Datensatz enthält. Dabei entsteht in den einzelnen serverspezifischen *.yaml keine Redundanz/potenzielle Fehlermöglichkeit. Leider ist die hiera_hash()-Funktion sowie eine zusätzliche Einstellung des 'deeper merging', die hierfür in bestimmten Fällen benötigt wird, noch recht neu und wird in vorhandenen Puppet-Modulen aus der Puppet-Forge auch nur selten verwendet. Ein aktuell von uns verwendeter "workaround" ist nun, die dnsmasq-Konfiguration vollständig in common.yaml unterzubringen und zwar in dieser Form: dnsmasq: dhcp_range_start: "%{hiera('range_start')}" dhcp_range_end: "%{hiera('range_end')}" lease_time: 15m und in der srvXX.ffnw.de folgendes zu speichern: range_start: 192.168.0.10 range_end: 192.168.0.100 Damit hat man die lease_time nicht mehr in den serverspezifischen werten und die start- und endadresse wird mit einem verschachtelten lookup eben aus dieser datei geholt. (Das Beispiel hier ist kein gutes, weil gerade dnsmasq über genau diese funktion verfügt, aber es ist hier ja nur für das verständnis). Aber auch dieser Ansatz hat seine grenzen: Diese verschachtelte hiera()-Funktion kann nur Strings, d.h. keine Nummern, keine Booleans oder gar Objekte liefern, ebenso ist das Verhalten, wenn die verschachtelte Abfrage keinen Treffer findet, so, dass die übergeordnete Abfrage sehr wohl Erfolg hat und dann mit einem leeren String arbeitet, was manchmal sehr problematisch sein kann. Neben dieser - ich nenn sie mal - hiera-eingeschränkter-lookup-problematik gibt es noch eine zweite, die unangenehm sein kann: Man definiert in der Datei <environment_name>/manifests/sites.pp, welcher server, welche Puppet-Module bekommen soll, mit sogn. include-anweisungen der Form: include dnsmasq include ntp include ... Das gilt dann entweder nur für einen Server oder für alle oder für diejenigen, deren fqdns ein bestimmten Regex matchen. Anschließend müssen dann auch für alle die genannten module valide daten in hiera hinterlegt werden, sonst schlägt der durchlauf fehl. Dort nun Gruppen für Supernodes und andere Aufgaben anzulegen ist - was ich bisher weiß - nur auf Umwegen möglich, es gibt hier aber die Methode, den Befehl hiera_include statt der obigen, klassichen Include-direktiven zu verwenden, das sieht dann so aus: hiera_include('classes') Und nun kann man wiede per hiera in common.yaml oder anderen Dateien der Hierarchie Klassen angeben, also zb: classes: - ntp - dnsmasq Das schöne hierbei ist, dass diese Klassen tatsächlich gemerged werden, d.h. sowohl die Klassen, die in common.yaml angegeben sind als auch die, die in srvXX.ffnw.de angelegt sind, werden "in einen topf" geschmissen und dann alle eingebunden. Wodurch man nun recht bequem einzelnen servern nur bestimmte Module zuweisen kann. Was nun noch fehlt, ist ein Mechanismus, um Servern bestimmte Rollen zu geben, zB "webserver" oder "supernode" oder "webserver und supernode", ohne hier wiederum die gemeinsamen hiera-werte in die serverspezifischen yaml-dateien knallen zu müssen, sondern sie in einer gemeinsamen webserver.yaml oder supernodes.yaml zusammenzuhalten. Hierfür habe ich mir das auf der Wiki-Seite dargestellte Rollen-Konstrukt überlegt, das ähnlich wie bei der Nginx-Config mit "available" und "enabled" ordnern arbeitet und zum aktivieren einer Rolle aus "available" nach "enabled" symlinkt. Desweiteren möchte ich zukünftig dann klar zwischen Modulen aus der Forge und selbstentwickelten trennen, wobei die selbstentwickelten künftig nicht mehr das in den hiera-dateien eingebettete "%{hiera(KEY)}", sondern hiera_hash()-basierte Abfragen nutzen sollen, wann immer Daten aus unterschiedlichen Ebenen gemischt werden müssen, da diese bisherige methode die genannten großen Probleme mit sich bringt. Die Forge-Module werden dann auch nicht mehr in $codedir/environments/{dev,prod}/modules, sonder in $codedir/modules liegen - damit ist dann leichter unterscheidbar, was selbstgebaut ist und was nicht und es kommt nicht zu etwaigen problemen, wenn zB in dev ein Forge-Modul geupdatet wird, aber selbiges in prod vergessen wird, sondern alles greift immer auf exakt dasselbe Modul zu. Soviel dazu, wie gesagt, wenn es Möglichkeiten gibt, die genannten Probleme zum umschiffen, ohne hier mit etwas gewöhnungsbedürftigen Symlink-Konstrukten herunmzubasteln, gerne her damit, ich hänge da nicht dran, sehe derzeit nur keine gleichwertige Alternative. Viele Grüße, Eike

2 1

srv08
by Jan-Tarek Butt 04 Jan '16

04 Jan '16

@Eike ich bin gerade mal eine manuelle Konfiguration eines supernodes durch gegangen am beispiele von: https://wiki.freifunk-franken.de/w/Freifunk-Gateway_aufsetzen http://wiki.freifunk.net/Hamburg/Gateway https://wiki.mag.lab.sh/wiki/Freifunk_Fulda/Gateway was für das br-mesh interface gefehlt hat war das package "bridge-utils" Ich habe das package bei fastd mit in Module untergebracht. Zusätzlich hab ich mal angefangen aufzuschreiben was zum betrieb eines Gateways notwendig ist. https://wiki.nordwest.freifunk.net/Technik/gateway vg Tarek

2 3

[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