Ffdon baut neu auf

Technik Ansible
1

Hallo beisammen,

ich baue unser Netz für Freifunk-Donau-Ries neu auf - zu viele Leichen…

@MPW
Nun habe ich noch sehr altes Ansible-Halbwissen
und deshalb zwei Fragen zum Start über eure Vorstellungen:

Vorweihnachtliche Grüße aus Donauwörth
und
Alles Neu macht der Advent

2

Moin,

Ich würde Deb10 empfehlen.

Wenn du Fragen hast, immer her damit oder kommt mittwochs ab 20:30 Uhr auf unseren Mumbleserver (mumble.ffmsl.de).

Viele Grüße
Matthias

3

Danke für das Angebot, die Fragen kommen bestimmt.
-> erstes Handycap mit github:
„Sie haben diese Repo bereits geforkt“
Ich möchte meinen alten Stand noch aufbewahren.

  1. Ansatz:
    Im Fork einen Branch erzeugen und danach euren Stand mit meinem Master synchronisieren.
    Ich habe keine Ahnung ob das geht…
4
  1. Ansatz, viel einfacher
    aktuellen Foŕk clonen und als "Backup-Repo wieder in Github einstellen
    aktuellen Fork vernichten und erneut forken
5

Ist das eine Frage oder Feststellung? :wink:

Du kannst den alten Master-Zweig auch umbenennen.

6

Hab schon den ersten Hänger:

git clone git@github.com:FreiFunkMuenster/ansible-ffms.git
Cloning into ‚ansible-ffms‘…
Warning: Permanently added the RSA host key for IP address ‚140.82.118.4‘ to the list of known hosts.
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Was bedeutet der User git?

Wenn ich den weglasse hab ich das gleiche Problem bei:

git submodule update --init roles

Grüße

7

mit git@ checkst du via SSH aus. Ohne via HTTPS.

Einfach deinen SSH Key in deinem GitHub Profil hinterlegen und ab geht’s…

8

danke, hat sich eben erledigt - ich hab natürlich mein geforktes Repo genommen …

9

Könnte ich bitte eine Klartext-Vorlage der passwords.yml bekommen?

10

Für die Gateways ist nur die erste Zeile kea_postgres_pw relevant.

11

danke, das klappte soweit.

in /roles/gateways_l2tp/tasks/main.yml
Clone tunneldigger (ffrl fork)
klont Ihr: https://github.com/ffrl/tunneldigger

Aus meiner Sicht gibt es das Repo so nicht (mehr).
Wo geht es für mich weiter?

Ansible bleibt an dieser Stelle einfach mal stehen.

Ersetzt das Paket „iproute2“ das nicht mehr vorhandene Paket „iproute“ in Buster?

Grüße

12

IIRC nutzt FFMS den slowenischen Tunneldigger, insofern mag der andere Pfad nicht gepflegt sein.

13

use_wlan_slovenija_tunneldigger: true
in die host_vars-Datei des jeweiligen Gateways packen. Dann wird die aktuelle tunneldigger-Rolle ausgerollt.

14

Das sollten wir dann zum Standard machen, wenn es das andere ohnehin nicht mehr gibt.

15

bei mir fehlte durch das Ausmisten nur der Schalter in der entsprechenden host_vars-Datei.

Und die nächste Frage:

Die Münchner betreiben

  • redundante Gateways
  • auf dem GW einen isc-DHCP mit genau einer Range je Domäne

Ihr (ffms) betreibt

  • redundante Gateways
  • splittet aber die IPv4-Range auf die beteiligten Gateways auf.

Kann es sein dass die Münchner (ungeNATtete) ÍPv4-Kommunikation über die Gateway-Grenze hinweg verzichten?
Ich weiß schon, dass ich die Frage an den falschen stellen …
Ich hörre aus München nur ein „Batman tut das“
Edit:
In München war es ein Experiment, das immer noch glücklich läuft, da
bei der Adressvergabe ein durch den ISC-DHCP ein Ping und einen ARP-Lookup auf die Adresse abgesetzt wird um zu prüfen und eine Lease-Time von 10 Minuten eingesetzt wird, um die Auswirkungen eines Net-Split gering zu halten.

Schränkt Ihr Port 67+68 UDP hierfür ein. um nicht zwei Antworten auf DHCP zu bekommen?

Oder anders gefragt:
Ich möchte evtl. weiterhin das Netz 10.86. /16 (noch aus Intercity-Zeiten) benutzen und muss etwas anders als Ihr mit dem 10. /8 er-Netz mit den IP-Adressen haushalten - muss ich die Ipv4-Range splitten?