Hi zusammen,
Wie wollen wir das nächste Release angehen. Wir haben bereits einige
wr841v10 im Einsatz die auf der Testing Firmware laufen. Der Autoupdater
läuft bei den Routern auf Stable so das die Router auf eine Firmware >
0.7 warten.
Zudem haben wir das Problem das die v10 erst mit gluon v2016.1
supported werden. Mein Vorschlag wäre wir bauen 0.7 mit der Basis
v2015.x und die v10 bleiben weiter in testing somit werden diese erst
gegen Mitte Februar in Stable kommen.
Es gab ein Vorschlag die v10 aus testing in stable zu übernehmen und das
reguläre stable auf Basis von v2015.x zu belassen. Allerding fände ich
eine Mischung von testing uns stable unschön.
Wie seht ihr das? Wie wollen wir vor gehen?
Yay!
-------- Ursprüngliche Nachricht --------
Von: redmine(a)open-mesh.org
Gesendet: 29. Januar 2016 10:43:54 MEZ
Betreff: [batman-adv - Bug #213] (Resolved) batman-adv gets confused if multiple interfaces sharing the same macaddr are bridged to multiple VLANs on the same batX interface
Issue #213 has been updated by Simon Wunderlich.
Status changed from New to Resolved
This issue has been fixed with release 2015.2
----------------------------------------
Bug #213: batman-adv gets confused if multiple interfaces sharing the same macaddr are bridged to multiple VLANs on the same batX interface
https://www.open-mesh.org/issues/213#change-697
* Author: Alessandro Bolletta
* Status: Resolved
* Priority: Normal
* Assignee: Simon Wunderlich
* Category:
* Target version:
----------------------------------------
How to reproduce this bug:
if I create 2 VLANs on the top of a bat0 interface and then I bridge bat0.x with eth0.x and and bat0.y with eth0.y, and if eth0.x and eth0.y share the same MAC address, the batman-adv routing engine gets crazy.
Infact, if I try through another host facing to bat0.x or/and bat0.y to do a batctl traceroute pointing to the MAC address of the host who shares the same MAC address, I can see that the routing path changes unexpectedly, getting right for a while and then randomly gets wrong, such as in a loop fashion.
At the moment, in order to avoid this behaviour, the best workaround I found is having different MAC addresses on *every* interface bridged on a different vlan configured the same mesh cloud interface (let's assume bat0, for example). It's not so much pratical, especially for who wants to configure (and then bridge with external interfaces) many VLAN interfaces on the batman-adv mesh.
I'm going to categorize it as a "bug", since it's a batman-adv related problem and I think it should be great if it could be solved.
---Files--------------------------------
batmanadv-vlan-loop-graph.pdf (386 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://hostname/my/account
Hi,
@Clemens: Magst du ein Feedback zu Issue #14 geben bzw. wenn es geklärt
ist das issue schließen, dann könnte ich wie geplant zum Wochenende eine
neue Firmware bauen zum Testen.
vg
Tarek
Moin,
wer kein interesse an "IT-Automatisierung" oder auch gennant
Orchestrierung, allgemeinen Konfiguration und Administration von
Computern hat,
kann hier aufhören zu lesen. Vergleichbar Puppet, Chef und weitere.
Wer jetzt noch Interesse hat,
ich hatte davor bereits Puppet als Konfigurationsmanagement angesehen
und bin dabei auf keinen grünen Zweig gekommen. Es musste sowohl am
Server als auch auf den Clients zusätzlich Software installiert
werden, dann war der Sprachsyntax für die Konfigurationen zu lernen.
Das geht nicht einfach mal so, hier muss viel Zeit investiert werden.
Nicht so bei Ansible: Der Einstieg ist denkbar einfach. Ansible wird
auf einem Server installiert (am Besten über die Paketverwaltung) als
Abhängigkeit gibt es nur eine funktionierende Python-Installation.
Dies wird allerdings auch von der Paketverwaltung übernommen. Auf den
zu verwaltenden Clients wird nur SSH benötigt.
Das war es auch schon.
Zudem ist der Syntax der Sprache der verwendeten Dateien einfach und
gut zu lesen. Obwohl die Sprache einfach gehalten ist, lassen sich
damit Konstrukte wie Variablen, bedingte Anweisungen und Schleifen
verwenden. Zudem gibt es die Möglichkeit Rollen zu erstellen, die sich
dann auf Server anwenden lassen.
Hier nochmal meine Gründe für die Verwendung von Ansible:
Sichere und einfache Verbindung über SSH
Keine Clientsoftware notwendig
Einfacher Sprachsyntax (YAML)
Flexibilität durch die Verwendung von Variablen und Rollen
Mein Ziel ist es z.b Freifunk Router mit Ansible für gewisse
gegebenheiten Automatisiert einzurichten.
Ich fange dann mal an zu lernen, mal sehen wann ich die ersten
Freifunk Router Orchestrieren kann.
http://www.admin-magazin.de/Das-Heft/2015/04/Workshop-Automatisierung-mit-A…
Hast du auch interesse Ansible zu lernen?
Melde dich gerne bei mir.
--
Gruß
pic
Xmpp: picard(a)ffnw.de & picard(a)fr32k.de
@ME https://wiki.nordwest.freifunk.net/picard
Moin zusammen,
mittlerweile gibt es vom 1043 die Version 3. Können wir hierfür ein
Image bekommen? Leider werden wohl nur noch v3 ausgeliefert.
Danke
Stefan
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
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
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
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
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
