Fastd mit ansible-ffms: Howto?

wusel · 4. November 2019 um 15:24

Kann mich jemand erhellen, wie man fastd-Domains mit ansible-ffms baut? Ich bräuchte noch ein Auffangbecken für Altlasten … Danke

MPW · 4. November 2019 um 20:34

Das bauen wir gerade noch. Du wärst ein guter Testkandidat .

Guck dir als Einstieg mal dieses Commit an: https://github.com/FreiFunkMuenster/ansible-ffms/commit/d2b368260a4198e30a3869793b6fa6bf7c0f83b4

RobWei · 4. November 2019 um 20:41

Also ich habe das auf rowe und corny schon ausgerollt. Test-Firmware baut.

wusel · 4. November 2019 um 21:59

Cool; was bedeutet „port base“? Ist das wieder „+ $community“ zu verstehen? (Unser altes Netz läuft auf 10000, dafür bräuchte ich das.)

EDIT: Also in host_vars/host in der domaenenliste der Domäne „fastd: true“ und group_vars/gateways „fastd: port_base:“ setzen und das war’s schon? Ausrolling

RobWei · 4. November 2019 um 22:13

Genau

MPW · 5. November 2019 um 05:24

Wo werden jetzt eigentlich die Identifikationsschlüssel generiert und gespeichert?

RobWei · 5. November 2019 um 05:42

Die liegen zurzeit immer nur auf den jeweiligen Gateways in /etc/fastd/{DOM_ID}/keys/ .

Läuft übrigens nach Justierung der MTU auf Knotenseite.

MPW · 5. November 2019 um 16:51

Das ist noch nicht optimal. Kann man die aus Ansible heraus in den Vault speichern? Sonst funktioniert das Domänenroulette nicht mehr richtig.

Auf was muss man die einstellen? Hast du mal abgeschaut, was andere Communities so nutzen?

RobWei · 5. November 2019 um 17:21

1406 um IPv6 mit salsa2012 nutzen zu können.

Ich habe nichts gefunden, meines Erachtens kann man die aber ruhig einmal generieren und dann händisch eintragen.

wusel · 5. November 2019 um 17:40

Hmm, ich stolpere grade über „TASK [collectd : deploy collectd.conf]“:

fatal: [fastd-ham02]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'server_id'"}
fatal: [fastd-fra01]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'server_id'"}

Config: https://github.com/wusel42/ansible-ffms-ffgt, roles kommt aus https://github.com/wusel42/Ansible-Freifunk-Gateway (wir machen lokalen Exit für v4 & v6, Adressen müssen im eigenen AS per OSPF propagiert werden, aus $Gründen mit instance id 10).

Ich denke, das steigt hier aus (bei „hostvars[host].domaenenliste[domaene[0]].server_id“), aber wo muß das gesetzt werden?

{% if "domaenenliste" in hostvars[host] %}
	Host "{{domaenen[domaene[0]].ffv4_network | ipaddr(hostvars[host].domaenenliste[domaene[0]].server_id)
 | ipaddr('address') }}"
{% else %}
	Host "{{domaenen[domaene[0]].ffv4_network | ipaddr(hostvars[host].server_id) | ipaddr('address') }}"
{% endif %}

BTW: ohne „use_wlan_slovenija_tunneldigger: true“ legt sich „gateways_l2tp“ auf die Nase, da das iproute-Package unter Ubuntu iproute2 heißt, wie wohl auch ab Debian 10. (Setup auf 18.04 LTS-VMs.)

RobWei · 5. November 2019 um 18:24

Also der schalter für das fastd (https://github.com/wusel42/ansible-ffms-ffgt/blob/master/host_vars/fastd-fra01#L22) muss in den Block zu der jeweiligen Domäne in der „domaenenliste“ (https://github.com/wusel42/ansible-ffms-ffgt/blob/3f74714bb789cfa8594318fbe57276f718c844bc/host_vars/fastd-fra01#L16)

wusel · 5. November 2019 um 19:23

Ah, jetzt (Groschenfallgeräuch einspiel) … Sorry. Jetzt rennt’s weiter, aber irgendwas habe ich wohl noch übersehen/›weggekürzt‹:

TASK [gateways_fastd : override haveged service]
*******************************************************************************************
ERROR! The requested handler 'restart haveged' was not found in either the main handlers list nor in the listening handlers list

RobWei · 5. November 2019 um 19:26

Stimmt… das wollte ich noch einbauen… folglich habe ich es einfach per Hand neugestartet.

wusel · 5. November 2019 um 19:33

I see Andere Frage:

root@fastd-fra01 ~ # modprobe -v batman-adv
insmod /lib/modules/4.15.0-20-generic/kernel/net/llc/llc.ko 
insmod /lib/modules/4.15.0-20-generic/kernel/net/802/stp.ko 
insmod /lib/modules/4.15.0-20-generic/kernel/net/bridge/bridge.ko 
insmod /lib/modules/4.15.0-20-generic/kernel/net/batman-adv/batman-adv.ko 
root@fastd-fra01 ~ # dmesg | grep batman
[62564.433276] batman_adv: B.A.T.M.A.N. advanced 2017.4 (compatibility version 15) loaded

Da hatte ich beim jeweiligen Host, nach Beispiel für testkarte, „2013.4.0“ gesetzt, wieso wurdet das nicht gezogen?

wusel@ysabell:/data/wusel/ansible-ffms-ffgt$ grep -r batman_ *
gateways.yml:    - { role: batman_install, tags: "batman_install", when:  "domaenenliste is defined"}
group_vars/gateways:#batman_version: "2013.4.0"
host_vars/fastd-ham02:batman_version: "2013.4.0"
host_vars/karte:#batman_version: "2017.4"
host_vars/fastd-fra01:batman_version: "2013.4.0"
host_vars/testkarte:batman_version: "2018.1"
mapserver.yml:    - { role: batman_install, tags: "batman_install"}

corny456 · 5. November 2019 um 20:09

Die Variable hat sich geändert nachdem @citronalco die rolle überholt hat.

batman:
  version: "2013.4.0"

Müsste es sein.

Aufpassen das du

github.com

FreiFunkMuenster/ansible-ffms/blob/master/group_vars/all#L732


    ffv6_network: 2a03:2260:115:7700::/64
    map_scale: 1.1
    map_show_contact: false
    map_max_age: 14
    firmware: domaene77/


# Nummer der Routing Tabelle, die auf den Servern verwendet wird
routing_table: 42


# Batman Einstellungen
batman:
  # Bandbreite, die Batman annoncieren soll
  downstream: 1024Mbit
  # Bandbreite, die Batman annoncieren soll
  upstream: 1024Mbit


# Parameter für das eigene Freifunk-Netzwerk
ff_network:
  # Eindeutige AS-Nummer des Netzwerk
  #as_number: 65251
  as_number: 209894

nicht überschreibst wenn du das in der host_vars/* setzt.

wusel · 6. November 2019 um 04:34

Supi, das klappt … fast: batman-adv-2013.4.0 baut nicht mehr unter Kernel 4.15 — aber die Gluon-Fraktion hat das Problem gelöst: um Batman Kompatibilitätslevel 14 unter Kernel 4.15 zu bauen, nutzt man statt der offiziellen die Gluon-Sourcen. Vgl. https://github.com/void-linux/void-packages/issues/5029 — konkret:

   cd /usr/src/
   ls
   git clone https://github.com/freifunk-gluon/batman-adv-legacy.git batman-adv-2013.4.0
   dkms add -m batman-adv -v 2013.4.0 && dkms build -m batman-adv -v 2013.4.0 && dkms install -m batman-adv -v 2013.4.0 --force

Damit baut das Modul zwar, leider hakt es dann doch auf Ansible-Ebene:

TASK [batman_install : DKMS-Modul batman-adv entfernen] *************************************************************************
fatal: [fastd-fra01]: FAILED! => {"changed": true, "cmd": "dkms remove batman-adv/2013.4 -k 4.15.0-20-generic", "delta": "0:00:00.059328", "end": "2019-11-06 05:21:58.600296", "msg": "non-zero return code", "rc": 3, "start": "2019-11-06 05:21:58.540968", "stderr": "Error! There are no instances of module: batman-adv\n2013.4 located in the DKMS tree.", "stderr_lines": ["Error! There are no instances of module: batman-adv", "2013.4 located in the DKMS tree."], "stdout": "", "stdout_lines": []}
fatal: [fastd-ham02]: FAILED! => {"changed": true, "cmd": "dkms remove batman-adv/2013.4 -k 4.15.0-20-generic", "delta": "0:00:00.059653", "end": "2019-11-06 05:21:59.747588", "msg": "non-zero return code", "rc": 3, "start": "2019-11-06 05:21:59.687935", "stderr": "Error! There are no instances of module: batman-adv\n2013.4 located in the DKMS tree.", "stderr_lines": ["Error! There are no instances of module: batman-adv", "2013.4 located in the DKMS tree."], "stdout": "", "stdout_lines": []}

Aber im Grunde tut’s:

root@fastd-ham02 ~ # modprobe -v batman-adv 
insmod /lib/modules/4.15.0-20-generic/updates/dkms/batman-adv.ko 
root@fastd-ham02 ~ # dmesg | grep batman
[145073.192830] batman_adv: loading out-of-tree module taints kernel.
[145073.193966] batman_adv: module verification failed: signature and/or required key missing - tainting kernel
[145073.205204] batman_adv: B.A.T.M.A.N. advanced 2013.4.0-64-g90b4d15-dirty (compatibility version 14) loaded

MPW · 6. November 2019 um 10:43

Ich denke nicht, dass wir noch Entwicklungsarbeit in die Unterstützung von Batman 2013 stecken werden. Aber wenn du ein paar optionale Schalter einbauen möchtest, würden wir die als PRs aufnehmen.

wusel · 6. November 2019 um 10:53

Mal gucken; ich wollte es hier kurz dokumentiert haben, just in case. batman v14 riecht schon komisch, ich brauch’s auch nur noch einmal für ein Übergangssetup, da die Umstellung (auf L2TP & v15) sich hinzieht.

EDIT: Oh, das war einfach, Version 2013.4.0 wurde als 2013.4 erkannt und entsprechend macht’s beim remove dann bumm. Siehe PR.

wusel · 7. November 2019 um 00:31

Ist nur ein Trigger geworden, batman.version auf 2013.4.0 setzen, siehe PR.

Aber das hier verfolgt mich

TASK [collectd : deploy collectd.conf] ******************************************************************************************
fatal: [fastd-fra01]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'server_id'"}
fatal: [fastd-ham02]: FAILED! => {"changed": false, "msg": "AnsibleUndefinedVariable: 'dict object' has no attribute 'server_id'"}

host_vars/fastd-fra01:

vm_id: 6
server_id: 5

[…]
domaenenliste:
   "00":
      dhcp_start: 10.255.140.16
      dhcp_ende: 10.255.143.254
      server_id: 5
      fastd: true

Kopfkratz

corny456 · 7. November 2019 um 09:09

Ich glaub Dom00 War kaputt…
Versuch mal 01.

Aus der server_id innerhalb der domänenliste werden die IPs berechnet. Wir haben da immer 2 fürs 1. Gateway 3 fürs 2. Gateway usw. drin stehen. (ID 1 wird nicht genutzt wegen next node und so…) Die braucht also nur innerhalb der Domäne unique sein. Versuch mal ne kleinere ID.