Admintagebuch - Dokumentation der Admintätigkeiten

Die Server fanlin, sn-fanlin-1, sn-fanlin-2 sind jetzt wieder in Betrieb.
Auf dem Server fanlin haben wir den fastd mal direkt abgeschaltet gelassen.

2 „Gefällt mir“

Server “greyworm” bereitgestellt mit Debian 8.
An @Parad0x übergeben zwecks Einrichtung Proxmox und 2x VM für SN.

1 „Gefällt mir“

sn-sense-2 ist unkonfiguriert, daher wäre dies ein guter Kandidat für die zweite VM in Domäne-1.

Ich ziehe den in der hosts-Datei daher jetzt rüber.

Wiki auf den aktuellen Stand gebracht. Falls Probleme auftreten, die ich beim Testen nicht gefunden habe, dann gerne direkt bei mir melden.

Mein Root hat wieder IPv6 (siehe https://forum.freifunk-muensterland.de/t/ipv6-traffic-faellt-lokal-raus-sn-descilla-1/128/ ). Vermutlich lag das Problem an der gesetzten forwarding.conf. Zur Sicherheit habe ich jedoch die iptables Regeln auf meinem Root angepasst, sodass keine v6 Pakete mit einer v6 Source Addresse aus dem FFMS Addressbereich mehr rausgehen können. Außerdem läuft ein TCPdump auf genau diese Filterung, ist bis jetzt aber noch nichts aufgeschlagen.

Für die FFMStd Domäne werfe ich gerade rudimentäre Statistiken auf mein Graphite/Grafana: http://5.9.86.151:3000/dashboard/db/ffmstd

Soll mittelfristig auf den FFMS Server geworfen werden, ist im Moment aber wohl zu umständlich.

Arbeiten an greyworm

  • Admin-Interface des Hosters → Netzwerkkonfiguration → auf Virtualisierungs-IP umgestellt
  • SSH-Key von sebastian und vax hinterlegt
  • vi ~/.ssh/authorized_keys
  • chmod 600 ~/.ssh/authorized_keys
  • Installation von Proxmox auf bestehendem Debian 8 nach Anleitung: Install Proxmox VE on Debian Jessie - Proxmox VE
  • Postfix-Konfiguration: Internet-Site
  • Arbeiten nach Wiki-Anleitung durchgeführt
  • Pool ffms und ffms-testumgebung angelegt
  • Benutzer kgbvax und parad0x angelegt
  • Neue VM greyworm-01 angelegt
  • Debian 8 darauf installiert

ToDos

  • Alarmierung bei Raid- und anderen Fehlern
  • Optional: SSL-Zertifikat ausstellen und installieren (Siehe Wiki-Eintrag) Bis dahin nur über das Webinterface einloggen, wenn Zertifikat ‎5f279f6c9a3f876e806201e77f283f1e9609451c genutzt wird
  • Neue VM ins ansible schreiben (domaene-01 / greyworm-01 / 89.163.247.45 )

Netzwerkkonfig in den VMs

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 89.163.247.45
netmask 255.255.255.255
pointopoint 146.0.42.1
gateway 146.0.42.1

1 „Gefällt mir“

Klasse und danke, dass du dich darum gekümmert hast! Kannst du uns eine VM für Domäne-01 klarmachen und unsere Schlüssel drauf tun, dann sind wir für die Domäne-01 komplett?

Ich vermisse übrigens Admin Log Einträge was die Maschine angeht.

Es ist noch WIP!

Heute wurde einiges am ansible entwicklerzweig erweitert. @descilla @MPW @Parad0x

  • Die Konfiguration der Interfaces (virtuelle/zusätzliche aber nicht eth0) wurde in einzelne Rollen gesplittet
  • DHCPv6 repariert
  • Domaene-01 mit den Interface- und DHCP-Rollen versehen
  • Globale Variable für Mitglieder Admin-Team angelegt
  • Diverse SSH-Schlüssel in keyfiles/ abgelegt
  • SSH-Schlüssel-Verwaltung erstellt (V1 nur mit Admin-Team. Einzel-Zugriffe folgen noch)
  • VM greyworm-01 der Domäne-01 hinzugefügt
  • Startup-Fehler von bat0 behoben (fastd restart was required before, when interfaces were restarted)
  • Rolle hostnames repariert
  • Neben den vorhandenen vim und wget die Default-Tools vnstat und tmux definiert

All diese Änderungen wurden auf die 3 Hosts der Domäne-01 angewendet. Die Domaene-01 ist somit mit 3 SNs besetzt. Die Anbindung an das Backbone rückt näher.
Abschließend wurde bemerkt, das IPv6 auf greyworm-01 noch nicht richtig läuft.

Sonstiges

  • WIKI-Einträge der Systemlandschaft angepasst
1 „Gefällt mir“

Ins Admin Tagebuch gehören alle Änderungen IMHO.

Was vermisst du? Sebastians Bericht umfasst soweit ich mich erinnere alles, was wir gestern gemacht haben.

Ich habe tcpdump auf meinen VMs gestern wieder abgeschaltet, kein Paket wollte flüchten.

Außerdem werden jetzt bei der burse statistiken wie folgt erfasst:

  • Interfaces
  • eth0, eth1, mesh0, client0
  • jeweils errors, octets, packages
  • cpu-0 (Prozessorauslastung)
  • load
  • memory
  • ping
  • auf heise.de, google.de, simon-wuellhorst.de
  • jeweis ping, droprate, stddev

Da ffmstd momentan noch autonom ist, respektive nicht ans FFMS-Backbone angeschlossen ist, werden die Statistiken momentan noch auf meine graphite Instanz geworfen, hier zu beschauen: http://5.9.86.151:3000/dashboard/db/ffms_burse

Edit: Zum Erfassen der Statistiken läuft collectd. Über ein bash script lasse ich die nötigen Befehle ausführen: http://simon-wuellhorst.de/freifunk/collectd/install_collectd.sh . Da der Openwrt-Paketserver nur über IPv4 erreichbar ist, wird in der opkg.conf der Umweg über den IPv6-Broker sixxs.org konfiguriert.

Ergebnisse der Adminrunde 02.11.:

  • Batman-adv kann nun über Ansible mittels dkms gebaut werden
  • Problem: Batman wird durch die Rolle nicht automatisch geladen, das muss noch gelöst werden
  • @Parad0x hat eine Arbeits-VM eingerichtet, auf der in zukunft gemeinsame tmux-Sitzungen stattfinden können, durch die Rolle common sind dort bereits alle Schlüssel hinterlegt.
  • Paulo hat OSPF erklärt, Testweise Tunnel zwischen den beiden VMs des1 und des2 der Pilotdomäne gebaut aber wieder deaktiviert, da es ungeklärte Routingprobleme auf des2 gab
  • Burse hängt jetzt an des1, da des2 derzeit tot und erst von @descilla wieder belebt werden muss

Grüße
Matthias

@descilla hat Des2 neu gestartet. Routing ist immer noch kaputt, die öffentliche IPv4-Adresse ist nicht pingbar. Diagnose folgt später.

Ich habs mal gefixt, in der bird.conf fehlte in den Templates für die internen, sowie ffrl Tunnel der verweis auf die passende Tabelle (table ffnet;). Ping geht nun wieder, den Rest habe ich noch nicht getestet.

Die Burse hängt nun wieder an Des2. Das Tunnelinterface für IP-Routing zwischen Des1 und Des2 habe ich nun auf Des2 deaktiviert.

OSPF gibt den Kernel für ffnet immer die Defaultroute Des1, das ist Quatsch und funktioniert nicht. Da müssen wir uns das OSPF nochmal anschauen ;).

Läuft jetzt soweit erstmal.

/edit: Das Tunnelinterface zu löschen hat wohl nicht gereicht, also jetzt OSPF auf Des2 deaktiviert, hoffe, dass es jetzt stabil läuft für die Bursianerinnen.

Hallo,

beim heutigen Admintreffen waren @descilla, @Parad0x, @Fungur und ich dabei.

Wir haben heute zwei Sachen geschafft:

  • batctl wird automatisch gebaut
  • die ansible-ffms-VM (148.251.208.168 / 2a01:4f8:191:21e1::168) als neue Arbeitsumgebung in Betrieb genommen

Es ist etwas seltsam, dass nach einem frischen reboot bat0 eine IP-Adresse hat, obwohl es in br0 hängt. Das dürfte eigentlich nicht sein. Ein networking stop & start behebt das. Sonst will Alfred wohl auch nicht, @Fungur sucht nach dem Grund in seiner VM.

Der nächste und letzte Arbeitspunkt bevor die Knotenmigration beginnt, ist OSPF. Das muss aber natürlich gründlich getestet werden.

Grüße
Matthias

Ich hab heute einen großen Fortschritt beim Verständnis der Batman-Architektur gemacht, den ich euch nicht vorenthalten möchte.

Wir hatten oft Probleme bat0 mit ifup zu starten. Das liegt daran, dass man dieses Interface nicht klassisch hochfahren kann, sondern es kommt automatisch hoch, wenn man das Kernelmodul batman-adv geladen hat und dann ein anderes Interface mit batctl if add Batman übergibt. Dann wird bat0 gestartet.

Klassischer Weise geschieht dies vom fastd aus, indem nach dem Start von fastd das mesh-vpn per batctl übergeben wird.

Dies führt zu einer unschönen Verkettung, die gar nicht nötig ist. Man kann mit

ip link add bat0 type batadv

bei neueren Batmanversionen das bat0 direkt erzeugen und dann die Gretaps und ggfs. das mesh-vpn hinzufügen.

Die Brücke br0 braucht man nicht. Man kann direkt die Konfiguration auf static setzen und die 10.43.X.X und die IPv6 vergeben.

Dann löst man das Problem, dass bat0 manchmal nicht in br0 hängt und die Konfiguration wird deutlich einfacher. Auf den Hardware-Routern (also Knoten) ist es sehr praktisch mit Brücken zu arbeiten, da man hier ggfs. die verschiedenen Ethernets-Ports überbrücken möchte, ohne an der VLAN-Konfig des internen Switches rumzuspielen. Auf den Gateways nicht.

Daher testen wir das jetzt in der Domäne-01 mal und zünden die Brücke an :). Die interne IP-v4 und IP-v6 wird dann direkt auf’s bat0 gelegt.

Grüße
Matthias

/edit: Hab die Brücken angezündet und alles im Ansible-Zweig entwicklungszweig angepasst, funktioniert :slight_smile:

1 „Gefällt mir“