Admintagebuch - Dokumentation der Admintätigkeiten

Wie heute besprochen habe ich die Legacy Domain Supernodes kgbvax02, kgbvax03 heute zu mitte Februar gekündigt.

2 „Gefällt mir“

iptables Regeln auf dem Blech der des* VMs angepasst. Das dort fehlerhaft konfigurierte MASQUERADE hat die Quell und Ziel Adressen an Stellen verändert, wo sie nicht verändert werden sollten. Das hat zu einer kurzen Unterbrechnung beim Monitoring auf BB fanlin geführt, was @fanlin instantan gefixt hat. :blush:

Ich habe auf remue-07 l2tp aktiviert. Der Dienst ist aktuell nicht reboot fest, weil ich sehen will, wie es sich macht. Installations-Hinweise zum Asiblelisieren, schick ich an @MPW

Auch noch anderes Zeug installiert, für den Map, aber das ist sekundär.

3 „Gefällt mir“

DNS-Server für freifunk-muenster.de, gw.freifunk-muenster.de, freifunk-muensterland.de, knoten.freifunk-muensterland.de, servers.freifunk-muensterland.de, services.freifunk-muensterland.de läuft jetzt auf der Service-VM als Master und auf den Backbones c1024, des1 und fanlin als Slaves. Mit dem Fix von @descilla funktioniert der Zonentransfer jetzt auch. Die knoten-Subdomain wird durch ein neues Skript aus den Knoteninfos (nodes.json) der Gesamtkarte 1x pro Minute generiert.

@void: Aus meiner Sicht können wir jetzt die Domänen offiziell übernehmen.

3 „Gefällt mir“

ffwaf hat jetzt den korrekten ipv4 dhcp range. Fehlt der endgültige Umzug im IPv6.

2 „Gefällt mir“

remue-07 ist gerade nach einem „batctl if del tap-ffwaf-srv4“ gestorben. Ich vermute, das übliche Problem: crash im Kernel, durch batman, wenn ein Interface entfernt wird.

remue-07 hatte tatsächlich einen Kernel-Panic:


Ich hab die VM resettet.

Domäne-14 würde jetzt die Aufteilung in mehrer Broadcast-Domänen unterstützen. Das netz auf bat0 nenne ich ab jetzt immer br-client0.

Allerdings stehen einige Probleme zu Lösung an. Problem:

Aus der site.conf

-- Prefixes used within the mesh. Both are required.
  prefix4 = '10.43.112.0/21',
  prefix6 = '2a03:2260:115:1400::/64'
  • ipv4: es werden Netze aus einem passenden Netz via DHCP vergeben. Dazu wurde ein Interface br-client1 auf ffwaf-srv4 und remue-07 angelegt und dort aus einem /28 vergeben. Um nicht mit den IP-Adressen verschwenderisch umzugehen, laufen die DHCP für das Netz im Failover-Mode. Insgesamt läuft das mit dem Routing auf remue-07 noch nicht rund, denn der bird startete nicht richtig (habe sysctrl enable bird*) ausgeführt und die Netze werden nicht in den ffnet-Tabelle übernommen, außer ich mache das (so wie ich das in Warendorf immer gemacht habe) von Hand: ip route replace 10.43.120.0/28 dev br-client1 table ffnet. Adressen aus der site.conf dürfen also nicht genutzt werden.
  • ipv6: die Knoten verbreiten weiter das IPv6-Netz, dass die Clients auf br-client1 dann nicht erreichen können, weil sie annehmen, dass es ohne Mitwirkung eines Routers geht.

Fazit: sowohl in br-client0 als auch br-client1 müssen Adressen genutzt werden, die nicht in der site.conf stehen dürfen.

Die Frage außerdem ist, wie man die beiden Netz in die Karten bekommt. An der Stelle habe ich gestern aufgehört.

Alle Änderungen findet man auf remue-07 so:

cd /etc && git diff e9405923fc063544a17f513d31b6788c12556c2f

Hellau!

1 „Gefällt mir“

Der Umzug der IPv6 Adressen in Domäne-14 wird vorbereitet. Ich habe das wie folgt realisiert:

diff --git a/bird/bird6.conf b/bird/bird6.conf
index 2bd313a..8b53572 100644
--- a/bird/bird6.conf
+++ b/bird/bird6.conf
@@ -27,6 +27,10 @@ protocol radv {
           link mtu 1280;
           prefix 2a03:2260:115:1400::/64 {
           };
+          prefix 2a03:2260:115:fe03::/64 {
+            preferred lifetime 0;
+            valid lifetime 0;
+          };
         };
3 „Gefällt mir“

Domäne-14 kann jetzt, wahrscheinlich nicht reboot-sicher mit zwei batman-Interfaces umgehen. Damit das in Zukunft auch funktioniert, müssen vermutlich neue VPN-Knoten immer angemeldet und freigeschaltet werden. Siehe dazu auch hier.

Muss die Realität mal in die Skripte gießen und dann einen Reboot versuchen.

Habe gerade, auf meinem Virthost u.a. folgende Sicherheitsupdates (qemu & qemu-kvm betreffend) eingespielt: DSA-3469, DSA-3470 & DSA-3471.
Reboot des Virtualisierungshost, damit Backbone und alle Supernodes FanLin-…, heute 23:00 MEZ.

1 „Gefällt mir“

Wir haben heute die DNS Server für freifunk-muensterland.de auf unsere eigenen Server umgestellt.
Bis die Umstellung über alle Domänenserver verteilt ist kann es bis zu 72 Stunden dauern.

Als offizielle DNS Server sind die Service-VM und unsere drei Backbone Server eingetragen.

3 „Gefällt mir“

Die DNS Umstellung hat gestern aus irgendeinem rund nicht gezogen … die Einstellungen waren weg …
Ich habe die Nameserver heute noch mal neu eingetragen.

@kgbvax
Bitte in besondere die Einträge für das Forum gegenchecken.

Ich habe mit @paulinsche die Warendorf-Server jetzt doppelt an die Service-VM angebunden, mit Domäne 14 und Domäne 15. Das ist jetzt aber nur manuell konfiguriert, noch nicht mit Ansible. Bevor wir das in Ansible packen, müssen wir noch mal genau überlegen, wie wir Multi-Domänen-Servern machen wollen, insbesondere wie klein die Domänen sein sollen. Ggf. müssen wir die IP-Adressbereiche noch einmal überdenken.

Auf Backbone-Fanlin gab es wieder massig nf_contrack-Fehlermeldungen.

b 13 19:21:19 fanlin kernel: [330857.367266] net_ratelimit: 3591 callbacks suppressed
Feb 13 19:21:19 fanlin kernel: [330857.367309] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.367326] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.367869] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.373665] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.374429] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.375797] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.376220] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.376223] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.376586] nf_conntrack: table full, dropping packet
Feb 13 19:21:19 fanlin kernel: [330857.377009] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.368183] net_ratelimit: 3102 callbacks suppressed
Feb 13 19:21:24 fanlin kernel: [330862.368186] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.368328] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.370576] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.370893] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.371659] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.372218] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.372970] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.375949] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.375958] nf_conntrack: table full, dropping packet
Feb 13 19:21:24 fanlin kernel: [330862.377050] nf_conntrack: table full, dropping packet

Maximales Limit für Verbindungen hochgesetzt. Bzw. config neu laden lassen, da es schon drin stand. Es zeigte sich, dass dieser Wert beim Neustart nicht automatisch gesetzt wird.

Das Modul nf_conntrack wird wohl beim Start nicht direkt geladen, bzw. nicht bevor sysctl gestartet wurde. Daher habe ich jetzt nf_conntrack in /etc/modules gesetzt, das sollte das Problem beheben. Müssen wir beim nächsten Neustart überprüfen und dann ins Ansible packen.

Edit: Ich habe diese Änderung natürlich auf allen drei Backbone-Servern gesetzt.

2 „Gefällt mir“

remue-07 ist heute irgendwann gestorben. Nach dem reset via virt-manager hat sich erfreulicher weise rausgestellt, dass im Prinzip alles wieder gekommen ist. Die l2tp-vpn Interfaces mussten von Hand wieder rein, obwohl in den Skripten drin steckt dass sie da rein sollen…

Und weil der Server gerade leer war, habe ich ein apt-get update && apt-get upgrade durchgeführt… Und weil ich dachte, dass ich auf beiden dom14-Server mal die gleichen batman-versionen laufen lassen könnte (v2015.2), wollte ich das manuell installieren, dabei aber festgestellt, dass es im jessie keinen 4.2 Kernel mehr gibt, sondern einen 4.3er und der mit batman 2015.2 ausgestattet ist.

3 „Gefällt mir“

Da die Reihenfolge nicht ganz deterministisch ist, in der die Interfaces geladen werden, haben wir das Hinzufügen einmal bei bat0 und einmal im Interface vermerkt. Das funktioniert bisher zuverlässig.

3 „Gefällt mir“

Habe gerade auf bb-fanlin, in der vnstatd.conf, den Parameter MaxBandwidth von 100 auf 1000 gesetzt. Jetzt sollte das gemeckere im syslog (Info: Traffic rate for “eth0” higher than set maximum 100 Mbit (30->413, r428 t427), syncing.) aufhören.

EDITH:
Habe auf bb-Descilla und bb-Commander den Parameter ebenfalls angepasst.

1 „Gefällt mir“

Andere Variante wäre die Interface nicht mit “auto” hochzufahren, sondern z.B. in rc.local in der gewünschten Reihenfolge. Vor allem Bridges brauchen schon mal ihre Zeit, bis sie meinen, dass sie oben sind …

1 „Gefällt mir“

/etc/modules?
Erscheint mir aber irgendwie der falsche Ort.