Admintagebuch - Dokumentation der Admintätigkeiten

Fixed. apt-transport-https musste installiert werden. wollte erst nicht, habe dann alle repos außer die hetzner deaktiviert, ging dann, dann wollte http://repo.universe-factory.net noch einen neuen key haben, jetzt alles wunderbar.

1 „Gefällt mir“

Habe gerade die Knoten gleichmäßig(er) auf die Server verteilt. Dabei gab es Probleme. service fastd restart scheint wohl nicht ganz sauber zu laufen. Außerdem braucht er ewig, bis er wieder Verbindungen aufbaut.

Daher wie folgt:
echo "peer limit 75;" >> /etc/fastd/vpn/fastd.conf && sleep 1 && service fastd stop && sleep 2 && service fastd start && sleep 2 && service fastd status
Die sleep’s kann man ggf. weglassen. Wollte aber nicht ein weiteres mal daneben landen und die Sekunden hatte ich dann noch. :wink:

Edit: Limit nach erfolgreicher Verteilung natürlich wieder entfernt:
sed -i '$ d' /etc/fastd/vpn/fastd.conf && sleep 1 && service fastd stop && sleep 2 && service fastd start && sleep 2 && service fastd status

auf c1024 und fanlin kam sowas:

Jan 28 19:02:45 c1024 kernel: [155005.551278] nf_conntrack: table full, dropping packet
Jan 28 19:02:45 c1024 kernel: [155005.551564] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.558042] net_ratelimit: 3483 callbacks suppressed
Jan 28 19:02:50 c1024 kernel: [155010.558066] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.568828] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.570022] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.572894] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.573704] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.573901] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574166] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574432] nf_conntrack: table full, dropping packet
Jan 28 19:02:50 c1024 kernel: [155010.574439] nf_conntrack: table full, dropping packet

net.netfilter.nf_conntrack_max war in /etc/sysctl.conf korrekt gesetzt, jedoch war ein viel geringerer Wert (32k) in Verwendung. Das lag vermutlich daran, dass der Wert Hash-Wert (warum auch immer) zu klein gesetzt war/wurde. Wert in /sys/module/nf_conntrack/parameters/hashsize neu gesetzt und Einstellungen mit /sbin/sysctl -p neu geladen. Nun glühen die Leitungen wieder. :blush:

1 „Gefällt mir“

Der Hash Wert ist nur Optimierung, das sind IMHO die Zahl der Hash Buckets.
Ich glaube nf_conntrack_max ist der falsche Parameter?

1 „Gefällt mir“

Abstimmungsergebnis umgesetzt und den Link zum Firmware-Download-Assistenten umgelenkt: Neuer Firmwaredownloader

1 „Gefällt mir“

@MPW und ich haben die Firmware-Download-Umgebung angepasst:

  • Links im Wordpress angepasst
  • Beim Inhalt von http://firmware.freifunk-muensterland.org alle Hinweise auf Testbetrieb entfernt
  • Webserver
  • Docker für den Firmware-Downloader angehalten und gelöscht
  • nginx-Weiterleitungen zum Firmware-Verzeichnis entfernt
3 „Gefällt mir“

Zusammen mit @Parad0x habe ich gerade die Domäne-14 ins Ansible gesteckt und auf Remue-07 ausgerollt. Zusätzlich wurden für ffwaf-srv4 Tunnel auf Fanlin angelegt.

Zu meinem Bedauern hat sich @paulinsche für Ubuntu statt Debian entschieden, sodass er diesen Host alleine aufsetzen und verwalten muss. Die Tunnel stehen jedenfalls bereit.

1 „Gefällt mir“

Ich habe 2 Beiträge in ein neues Thema verschoben: Debian oder Ubuntu auf den Servern

greyworm-3 wie gewüscht neu gestartet.

Dabei noch folgendes auf greyworm-5 gesehen:

Die Graphite-Statstiken für domäne-05 sind jetzt gefixt.

1 „Gefällt mir“

Fastd-Verbindungen in Domäne 03 wieder gleichmäßig verteilt.

@Fungur und ich haben heute Nacht die bind-Rolle angepackt um für freifunk-muenster.de und freifunk-muensterland.de selbst DNS-Einträge zu setzen.

Dazu haben wir zunächst die bestehende bind-Rolle in bind_services für die Service-VM und bind_gateway für den Teil, der auf den Gateways läuft, aufgeteilt und geprüft, dass alles noch läuft.

Danach haben wir die automatische Serialisierung der Zonen per Linux-Zeitstempel eingebaut. Das führt leider dazu, dass auf der Service-VM jedes mal in Ansible eine Änderung durchgeführt wird. Dies lässt sich nicht verhindern, da man nicht zuverlässig prüfen kann, ob irgendwo sich irgendwas verändert hat. Die Einträge sind also immer gelb, das ist aber auch nicht weiter schlimm.

Zuletzt haben wir angefangen die Zonen knoten, server und services jeweils für freifunk-muenster.de und freifunk-muensterland.de mit ein paar Beispieleinträgen zu füllen.

Es muss jetzt noch der Zonentransfer an die Backbone-Server konfiguriert werden, wir brauchen von @void eine Liste mit allen derzeitigen Einträgen und dann, wenn alles läuft, kann bei der domainfactory der Eintrag geändert werden.

Grüße
Matthias

1 „Gefällt mir“

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“