Freifunk Gateway Installation mit puppet

Nach langem hin und her konnte sargon das Rätzel lösen. Ein : zu viel und ein ; zu wenig brachte den entscheidenen Anstoß.

Unfassbar. Das hat mich fast 3 Wochen gekostet. Aber irgendwann wir man blind und sieht nur noch den Code…

1 „Gefällt mir“

Hallo,

warum willst du Alfred umbedingt auf dem Gateway selbst haben? Es ist bekannt dafür, das System instabiler zu machen. Das eigentliche Routing läuft auch so und Details für die Karte kannst du von einer anderen VM ziehen.

Warum nutzt du 7.9 statt Debian Jessie 8.2? Funktioniert denn das Routing an sich?

Grüße
Matthias

in Freiburg wird und wurde gerade viel auf Debian gebaut … generell zu den verwendeten Softwareteilen - die allesamt selbst auf den Maschinen gebaut werden:

https://cccfr.de/wiki/freifunk:debian
das gateway tralala is da nur am rande beschrieben, der rest aber brauchbar erklärt

FTR, wir basieren unsere Server i. d. R. auf Ubuntu LTS, da Debian 7 etwas arg alt und Debian 8 etwas zu neu war Ende letzten/Anfang diesen Jahres.

Alfred baut IIRC nicht, weil das Makefile die Capabilities-Lib nicht findet, ich patche daher stumpf das Makefile (in ffgt-gln-gw-puppet/alfred.pp at master · ffgtso/ffgt-gln-gw-puppet · GitHub):

  exec { 'patch-makefile':
    command => "/bin/sed -i -e 's/export CONFIG_ALFRED_CAPABILITIES=y/export CONFIG_ALFRED_CAPABILITIES=n/g' Makefile",
    cwd => "/opt/alfred/",
    require => [Package['build-essential'],Package['pkg-config'],Package['libgps-dev']];
  }

Damit baut’s dann; aber z. T. tauchen die GWs dennoch nicht für Meshviewer auf, ich hab’s mittlerweile aufgegeben, da hinterherzusuchen.

Tricky kann auch sein, daß es Alfred-debs gibt, die aber von bat0 ausgehen, ffnord-puppet-gateway setzt aber auf bat-$community; dann startet batadv-vis, nicht aber alfred, IIRC.

Frage ist aber: warum an/mit Alfred aufhalten, bzw. auch, was ist bei Dir ein ‚Gateway‘? Wir haben z. B. Mesh und Routing mittlerweile getrennt und konfigurieren die Systeme nur noch per puppet, die ffnord-Skripte dienten da als willkommene Basis. Bis auf das Problem mit dem Bau von Alfred tat das IIRC für ein All-in-One-System (fastd, tinc, GRE für Uplink) sehr schnuckelig; gw05 und gw06 laufen damit bei uns noch, IIRC, aber nur noch für Müritz (gw06 war vormals shared, zwei Meshes).

Ebenso ist der Statistikkrempel auf eigene VMs ausgelagert, wovon nur eine, DER Alfred-Master (von dem es zumindest AFAIK nur max. einen im Mesh geben darf), im Mesh ist. Die zweite VM greift per ssh auf die erste zu, um die Daten aus alfred/batadv-vis zu ziehen. Das ist z. Zt. leider noch nicht puppetisiert, da Altsysteme; bei allen neuen Systemen ist der Ansatz aber, sie via puppet installierbar zu machen. Auch, um das Kopfmonopol loszuwerden …

Ach so, wir setzen nach wie vor batman-adv v14 ein.

Insofern: bei konkreteren Fragen kann ich gerne versuchen, zu helfen :slight_smile:

Ich verstehe den Unterschied „nicht der 1. im Netz“ nicht so gan, die Konfiguration ist doch identisch (bis auf die IPs)?

class { 'ffnord::params':
  router_id => "10.169.1.1", # The id of this router, probably the ipv4 address
                            # of the mesh device of the providing community
  icvpn_as => "65534",      # The as of the providing community
  wan_devices => ['eth0']   # A array of devices which should be in the wan zone
}
ffnord::mesh { 'mesh_ffmue':
      mesh_name    => "Freifunk Mueritz",
      mesh_code    => "mueritz",
      mesh_as      => 65534,
      mesh_mac     => "de:ad:be:ef:00:00",
      mesh_ipv6    => "fd39:e4e3:eee1:0aa9::/64",
      mesh_ipv4    => "10.169.1.1/21",
      mesh_mtu     => "1406",
      range_ipv4   => "10.169.0.0/16",
      mesh_peerings => "/root/mesh_peerings.yaml",
      fastd_secret => "/root/fastd_secret-mue.key",
      fastd_port   => 10169,
      fastd_peers_git => 'https://github.com/ffgtso/fastd-peers-gt.git',
      dhcp_ranges => [ '10.169.0.128 10.169.3.254',
                       '10.169.4.2 10.169.7.254'
                     ],
      dns_servers => [ '10.169.1.1',
                       '10.255.0.1'
                     ]
      }
ffnord::icvpn::setup {
  'mueritz_bgp1':
    icvpn_as => 65534,
    icvpn_ipv4_address => "10.207.0.138",
    icvpn_ipv6_address => "fec0::a:cf:0:8a ",
    icvpn_exclude_peerings     => [mueritz],
    tinc_keyfile       => "/root/tinc_rsa_key-mueritz.priv"
}
class { 'ffnord::alfred': master => false }
class { 'ffnord::etckeeper': }

Wie gesagt, Gütersloh ist mittlerweile über ffgt-gln-gw-puppet aufgesetzt, Müritz wird demnächst folgen; aber obiges ist die Konfiguration eines der beiden Müritz-GWs.

Moin, Zur info: Ich habe auch getestet bei der installation und ich glaube es liegt nicht an alfred

Bei dem ausführen des puppet scripts wird kein interface bat-ffnord angelegt, das ist das ganze Problem, denke ich.

seltsamerweise funktionierte es auf dem anderen baugleichen GW problemlos und auch in einer Debian 7.8 VM im ffnord-example wird alles problemlos installiert („boxcutter/debian78-i386“) und das Netzwerkintereface wird erfolgreich angleegt.

@anon68922371: ich denke du solltest die (passwort bereinigten) install scripte hier noch posten also dein vorbereitungsscript und das puppet manifest