Moin,
unser Alfred-Master läuft für alle Domänen auf der Service-VM.
Das Mergeskript findest du hier: tools/merge_map_data.py at master · FreiFunkMuenster/tools · GitHub
Als @fungur das programmiert hat, konnte der MeshViewer das noch nicht.
Grüße
Matthias
Moin,
es ist etwas ruhig geworden um das Projekt, aber heute hab ich den nächsten Schritt zur Restrukturierung des Repos gemacht, sodass es von anderen Communities leichter genutzt werden kann.
Die Rollen, also der Teil, der für andere Communities auch interessant ist, liegt jetzt in: GitHub - FreiFunkMuenster/Ansible-Freifunk-Gateway
Dieses Repo kann dann als submodule in eure Konfiguration eingebunden werden. Das ansible-ffms-Repo dient nur noch als Vorlage für die Konfiguration. Es kann einmal geforked werden, oder ihr könnt eure Konfiguration auch bei null beginnen lassen.
Ich bin selbst total blutiger Anfänger, was git submodules angeht, aber so könnt ihr anfangen:
git submodule add https://github.com/FreiFunkMuenster/Ansible-Freifunk-Gateway.git roles/
git submodule update --init roles
Später müsste das submodule dann nur gelegentlich aktualisiert werden, um von neuen Rollen und Funktionen profitieren zu können.
Wie man da jetzt Bugfixes pusht und als PR einreicht, müssten wir dann nochmal rausfinden.
Grüße
Matthias
Also wenn du mal Zeit und Lust hast: ich habe eine neue VM bereitgestellt. Wenn noch mehr Leute zuschauen möchten, sollte das Ganze vielleicht öffentlich gemacht werden.
Habe einen Mumble-Server aufgesetzt dafür.
Ansonsten gerne wie in der PN besprochen.
Gibt es Schwierigkeiten mit mumble.ffrl.de?
Ich habe dort extra die maximale Bandbreite „pro Client“ reduziert, damit auch Leute mit schlechter Anbindung zuhören können.
(Der Server recodiert ja leider nicht, wenn also ein Client mit 230kBit/s sendet … mono… dann muss das entsprechend auch zeitnah per evtl. überbuchtem UMTS wieder empfangen werden.)
Nein bzw. ich habe den vom ffrl noch nicht benutzt. Meiner ist vielleicht unnötig, wollte das aber einfach mal testen.
BTW: Hat es das Screen-Capture von der vorherigen Session und ggf. der Audio-Mitschnitt eventuell auf irgendeine Webseite/Blog/Whatever geschafft? Falls ihr sie nochmal brauchen solltet, dann suche ich die heraus.
(Oder waren die „aus Gründen“ nicht nutzbar und nicht heilbar? Wenn es vermeidbare Probleme drin gewesen sein sollten, dann sollte man das evtl. im nächsten Anlauf besser machen.)
Meines Wissens nach nicht.
Ich bin auch der Meinung, dass das eher weniger bringt und dass man sich selbst mit kleinen Übungen damit beschäftigen sollte, wie wir es auf dem Freifunktag in Köln gemacht haben.
Gibt es einen Vorschlag zu einem neuen Termin?
Es wäre toll, wenn der Fokus auf der Praxis läge incl „was checken wenn Leute sagen dass es klemmt“
Oder anders: Rechtfertigung warum Ansible und nicht x oder y: einfach überspringen.
Moin,
nächste Woche machen wir nochmal eine kleine Übung und konfigurieren einen unserer neuen Server: 09.10. 20:30 Adminschulung: Gateways konfigurieren lernen - Des2 - #6 von MPW - Infrastruktur / Backbone - Freifunk Münsterland
Aber das ist schon eher gezielt für den Aufbau unserer Infrastruktur gedacht und es steht die Einarbeitung von neuen Admins für das Münsterland im Vordergrund. Aber gerne darf jeder zuhören und mitmachen, der möchte.
Zu der Fehlerfindung eine Übung zu machen, das ist so eine Sache. Da müsste man sich glaube ich ganz konkrete Fehlerbilder überlegen und diese erzeugen, ähnlich wie Oli es für die Freifunk Routing Days gemacht hatte. Nur so theoretisch bringt das glaube ich nicht so viel.
Grüße
Matthias
Moin,
ich find das Projekt klasse. Hat jemand das Playbook mal so abgeändert das andere VPN-Exits z.B. in Schweden mit OpenVPN konfiguriert werden können?
Viele Grüße
Bernd
Moin,
habe das gerade mal durchlaufen lassen.
Soweit sieht eigentlich alles gut aus. Ich nutze aber den isc-dhcp-server. Firmware mit Tunneldigger habe ich auch gebaut. Verbindung zum Node ist da. Der Client bekommt auch eine IP das Gateway kann ich anpringen, ich komme aber nicht über FFRL ins Internet.
Die Tunnel scheinen alle da zu sein, aber ich komme nicht weiter:
root@host1 ~ # ping 8.8.8.8 -I tun-ffrl-fra1
PING 8.8.8.8 (8.8.8.8) from 100.64.9.137 tun-ffrl-fra1: 56(84) bytes of data.
^C
— 8.8.8.8 ping statistics —
2 packets transmitted, 0 received, 100% packet loss, time 999ms
Habt ihr eine Idee, wo es bei mir klemmen könnte?
Ich glaube nicht, dass du über die Tunnel-IP ins Internet pingen kannst. Dann müsste das FFRL-Backbone natten. Du musst das mit der Nat-IP vom loopback-Interface rausschicken.
Einfacher ist es von außen die Loopback-IP zu pingen. Wenn das geht, ist das schon die halbe Miete.
Grüße
Matthias
Ich glaub ich bin zu doof.
Evtl mag mal jemand auf meine Configs schauen:
Was mir noch aufgefallen ist: Bei mit ist nach dem Durchlauf (und Neustart) nochimmer der alte Kernel ( 3.16.0-4-amd64) installiert. Außerdem passen batctl und batman-adv nicht zusammen:
root@host1 ~ # batctl -v
batctl 2016.4 [batman-adv: 2014.3.0]
Bin ich komplett auf dem Holzweg?
Zeig mal bitte die Fehlermeldung von Ansible. Ohne die kann man da nur
schwer Fehler finden.
Grüße
Matthias
PS: Ich würde erstmal die Statistikrollen wie collectd auskommentieren. Das senkt die Anfangshürde.
Moin,
es gab keine Fehlermeldung, das war ja das, was mich wunderte. Ansiblie ist sauber durchgelaufen.
Vermutlich war irgendwas anderes Faul. Ich hatte Ansible auf einem Raspberry bei mir daheim laufen. Habs jetzt auf einer VM im Internet laufen gehabt und das scheint geklappt zu haben.
Ich habe jetzt noch ein Problem:
Der 1. Knoten verbindet sich korrekt via L2TP. Geschwinidkeiten sehen soweit auch alle klasse aus.
Wenn sich jetzt aber ein 2. Knoten verbinden will, dann klappt das nicht:
Tue, 12 Dec 2017 14:33:12 INFO New tunnel (id=102 uuid=60e32760257c) created.
Tue, 12 Dec 2017 14:33:12 DEBUG Executing hook 'session.up' via script '/srv/tunneldigger/broker/scripts/addif_domain01.sh ['102', '1', 'l2tp1021', '1446', '80.149.42.151', '37143', '20202', '60e32760257c']'.
Tue, 12 Dec 2017 14:33:12 DEBUG Hook '/srv/tunneldigger/broker/scripts/addif_domain01.sh' script stderr:
Tue, 12 Dec 2017 14:33:12 WARNING Cannot find device "l2tp1021"
interface l2tp1021 does not exist!
Am Knoten liegt, denke ich mal, nicht. Wenn ich den 2. Knoten zuerst einschalte, dann funktioniert dieser. Der Knoten, der sich danach meldet dann aber nicht mehr.
Habt ihr eine Idee?
Es kann durchaus mal passieren, dass es zweimal durchlaufen muss.
Zu dem anderen Problem, zeig mal das syslog zu der Zeit und die Ausgabe von
brctl show
Grüße
Matthias
im Syslog wird dazu nichts geloggt.
Ich sehe gerade das das Log mit dieser Meldung geflutet wird:
Dec 12 18:00:09 host1 bird: KRT: Received route 0.0.0.0/0 with strange next-hop 51.254.208.1
Sollte damit damit aber nichts zu tun haben, oder?
root@host1 ~ # brctl show
bridge name bridge id STP enabled interfaces
br01 8000.02caffee0102 no l2tp1011
Via ifconfig kann ich nur das erste L2tp-Interface sehen, keine weiteren…
Vielen Dank schonmal für Deine Hilfe!!
Ifconfig ist tot, immer
ip a s
benutzen.
Ich hatte das ehrlich gesagt noch nie, dass ein Tunnel ging, aber ein zweiter nicht. Guck mal ob du ein /sys/log/tunneldigger.log hast. Vielleicht steht da etwas sinnvolles drin.
Und was meldet eigentlich der Knoten im logread?
Grüße
Matthias
Logread sieht gut aus, soweit ich das sehen kann:
Thu Aug 3 03:42:11 2017 daemon.debug td-client: Broker usage of vpn3.freifunk-einbeck.de:20001: 85
Thu Aug 3 03:42:11 2017 daemon.info td-client: Selected vpn3.freifunk-einbeck.de:20001 as the best broker.
Thu Aug 3 03:42:12 2017 daemon.info td-client: Tunnel successfully established.
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Network device 'mesh-vpn' link is up
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Thu Aug 3 03:42:12 2017 daemon.notice netifd: Interface 'mesh_vpn' is now up
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.919070] batman_adv: bat0: Adding interface: mesh-vpn
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.924664] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1364) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Thu Aug 3 03:42:13 2017 kern.info kernel: [ 34.949736] batman_adv: bat0: Interface activated: mesh-vpn
/sys/log/tunneldigger.log gibts leider nicht… Komisch das ganze…
Ich habe es so verstanden, dass es mit dem bugefixten Tunneldigger auch nicht mehr geben wird.
(Finde ich persönlich zwar auch schade, aber ich bin da vermutlich zu altmodisch…)