Admintagebuch - Dokumentation der Admintätigkeiten

Reicht zum routen, wir wollen kein Fastd damit machen. Danke für’s Einschalten. Ich frage Tunnel beim FFRL für die Kiste an.

Mehr geht netto bei Hetzner auch nicht durch. Ist die Frage, was hier netto durchgeht, müssen wir einfach mal testen.

Des2 war kaputt. Nach dem Neustart des Netzwerkes gestern waren die Schnittstellen nicht mehr im Batman drin. Ich war zu faul die bei dreien alle einzeln einzuhängen und habe reboot getippt.

Das scheint mir noch ein Fehler in der Multidomänen-Konstruktion zu sein. Ich erstelle dazu mal einen Bug, damit wir das nicht vergessen: #31

Grüße
Matthias

Ein Netzwerk-Restart löscht auch die Bridges und baut sie neu wieder auf. Danach nicht dann natürlich die L2TP-Interfaces nicht in den Bridges und wir können die auch nicht einfach wieder hinzufügen, da nicht erkenntlich ist, welches L2TP-Interface in welche Bridge gehört. Für mich bleibt damit nur ein Restart des Tunneldiggers nach jedem Netzwerk-Restart als Lösung.

Ein automatischer Restart des Tunneldiggers durch den Netzwerk-Restart ist meiner Meinung nach nicht sauber möglich. Es würde ins post-up einer Bridge passen, aber da wir mehrere Bridges haben, würde dann der Tunneldigger mehrfach kurz hintereinander restartet werden, was wahrscheinlich zu Problemen führen wird.

Also bleibt für mich eigentlich nur: Immer wenn manuell Netzwerk-Restart ausgeführt wurde, auch manuell Tunneldigger restarten (und auch isc-dhcp-server restarten - der hat ggf. sonst auch Probleme). In den Ansible-Rollen ist das schon eingebaut gewesen.

Der Legacy-Gateway-Server parad0x wurde heute abgeschaltet und neu installiert.
Michael und ich haben anschließend das neue Ansible Playbook backway.yml auf parad0x ausgerollt um diesen als Gateway inkl. FFRL-Anbindung zu konfigurieren.
Dabei wurden einige kleinere Fehler im Ansible behoben. Einen größeren Fehler in bird haben wir nicht mehr behoben und das Problem vertagt. Sobald bird läuft (ipv4) ist der Server nicht mehr erreichbar. Wir vermuten ein Config-Fehler mit falscher Default-Route. Damit der Server auch nach Reboot noch erreichbar ist haben wir den bird-Dienst disabled.

P.S.: (sn-)parad0x-01 aus Dom5 wurde nicht verändert

Möglicherweise liegt es daran, dass der Server seine IP Adresse mittels DHCP erhält. Also ich meine nicht, dass das der Fehler ist, sondern dass der Fehler vermutlich mit diesem Umstand zusammenhängt. Es ist der erste Server, den wir mit Ansible konfigurierten der so konfiguriert ist.

@Parad0x, @Fungur und ich haben heute Nachmittag das Problem mit birdv4 gelöst. Das Protokoll direct fehlte. Außerdem haben wir noch die IPV6 für die FFRL-Tunnel auf dem Gateway Parad0x korrigiert.

Die Tunnel stehen jetzt, das Routing sieht gut aus. Als nächstes wird das Backway ans restliche Backbone-Netz angeschlossen.

@MPW und ich haben die neuen Backway-Rollen weiter gerade gezogen, so dass sie auch für normale Gateways funktionieren. Entsprechend wurde backways.yml in gateways.yml umbenannt und auf den L2TP-Domänen-Gateways ausgerollt.

Parad0x wurde als zusätzlicher Server für die Domänen 12, 13 und 16 konfiguriert, um die Backway-Funktionalität weiter zu testen.

1 „Gefällt mir“

Wir haben gestern @Fanlin s Gateway Backbone wieder in Betrieb genommen. Der Durchsatz an Greyworm sollte jetzt wieder auf dem Niveau von vor einigen Wochen liegen. An einer Erweiterung der Serverkapazitäten wird gearbeitet. Wir warten derzeit auf einen neuen Tunnel aus dem Rheinland.

3 „Gefällt mir“

Ich habe auf Greyworm mal einen Switch “interconnect” erzeugt.
Mit ffservice kann ich zu den VMs auch Netzwerk Interfaces hinzufügen.

1 „Gefällt mir“

Moin,

ich habe das IPV6-Routing in den Fastd-Domänen repariert. Dazu hab ich folgendes geändert:

  • bat-Interfaces im OSPF auf stub gesetzt, das verursacht sonst komische, unnötige Effekte.
  • ip -6 rule add from [FF-IPV6] hinzugefügt
  • Regeln mit Präferenzen versehen, alle haben jetzt 16000 nur die suppress_prefixlength hat 16500

Irgendwie funktioniert es dadurch auch auf sn-parad0x-01, welche keine IPV6 hat. Genau verstanden habe ich noch nicht warum. Theoretisch dürfte es keinen Unterschied machen. Aber scheinbar wird das Paket sonst irgendwie zu früh in die Standardtabelle geleitet, wo es nicht verarbeitet werden kann.

http://blog.ine.com/2013/09/06/modifying-traceroute-replies/

Die Präferenzen sind noch nicht ausgerollt, der Rest schon.

Grüße
Matthias

2 „Gefällt mir“

DHCP-Server der Fastd-Domänen neu gestartet: Keine IPv4 in Dom06

Das ist ein Bug im Ansible: https://github.com/FreiFunkMuenster/ansible-ffms/issues/32

TLS auf forum.freifunk-muensterland.de mal auf Stand gebracht.
Kein Login mehr über http

https://www.ssllabs.com/ssltest/analyze.html?d=forum.freifunk-muensterland.de

5 „Gefällt mir“

Ich habe eben in unserer Wordpress-Installation das Plug-In Podlove Podcast Publisher sowie die Themes Twenty Thirteen, Twenty Fourteen und Twenty Fifteen aktualisiert.

3 „Gefällt mir“
  • Firmware für Domäne 12 und Domäne 13 im Firmware Assistenten freigeschaltet.
  • Einträge für die Unterdomänen im Kreis Steinfurt erstellt. Diese verweisen aber auf die Firmware von Domäne 03 bzw. Domäne 04.
5 „Gefällt mir“

Ich habe das WordPress-Plugin “WP to Twitter” von Version 3.2.6 auf 3.2.8 aktualisiert.


Ich habe im primären Menü (sprich in der horizontalen Menüleiste) die vier letzten Punkte umsortiert, sodass nun diese Reihenfolge steht:

Communities - Presse - Wiki - FAQ

Vorherige Konfiguration: Wiki - FAQ - Communities - Presse

Desweiteren habe ich die Standard-Themes Twenty Thirteen, Twenty Fourteen und Twenty Fifteen deinstalliert. Als Fallback unseres Themes The Box FFMS fungiert weiterhin das Theme “The Box”


Ich habe im Untermenü von “Mitmachen” die Links unter “Icons, Logos, etc. / GitHub” und “Quellcode / Github” korrigiert. Zuvor verwiesen beide irrtümlicherweise auf https://github.com/FreiFunkMuenster. Nun verlinkt ersterer Punkt auf https://github.com/FreiFunkMuenster/media-ffms und zweiterer auf https://github.com/FreiFunkMuenster/site-ffms

3 „Gefällt mir“

Habe in domäne-14/15 ein paar mal gebootet, weil ich mir zunächst nicht anders zu helfen wusste:

Mein Hoster hatte ffwaf-srv3 wieder angestellt, und der behauptete schön ein Router zu sein und verbreitete auch schick die alten Prefixe. Diese sind inzwischen ausgetimed.

Für die Zukunft:

tshark -i wlan0 -f icmp6 -Y "icmpv6.type == 134" -T fields -E separator=, -E quote=d -e ipv6.src -e icmpv6.opt.prefix -e icmpv6.opt.prefix.length -E header=y -e icmpv6.opt.prefix.preferred_lifetime -e icmpv6.opt.prefix.valid_lifetime

So sieht man schön, welche Router, welche prefixe anbieten…

Beim reboot von remue07 stelle ich fest, dass die l2tp-vpn interfaces nicht ins batman eingetragen werden. Ich hab die schlicht einfach von Hand eingetragen: läuft eigentlich in letzter Zeit (>60 Tage) ohne crash/problem.

Auf ffwaf-srv4 gab es ein routing-problem für einige ipv4 Adressen: 10.43.112.64/27 (soll: 10.43.120.64/27) wurde auf das br-client1 Interface, nicht in das bat0 Interface geroutet.

2 „Gefällt mir“

Habe die PDF-Funktion im Wiki aktiviert und die Settings des Docker für Dokuwiki angepasst. Leider funktioniert es noch nicht. Abhängigkeiten fehlen. Ich mache die Tage weiter.

4 „Gefällt mir“

Barristan ist jetzt einsatzbereit. @Fungur hatte Dienstag das noch fehlende Kernelmodul kompiliert und ich habe heute noch 7/8 der Kerne abgeschaltet:

for i in `seq 1 7`; do echo 0 > /sys/devices/system/cpu/cpu$i/online; done

Ich werde jetzt die Firmware der Domäne-10 so ändern, dass das das Standardgateway wird und dann können wir mal testen, wie die Kiste so performt.

Habe die Regel auf fanlin/c1024 wieder eingetragen: Mir war aufgefallen, dass ipv4 regelmäßig von android Geräten, die das mit der MTU im DHCP nicht fressen, nicht richtig getan hat.

Bitte darum das in diese Rollen einzutragen!

1 „Gefällt mir“

Ich habe 4 Beiträge in ein neues Thema verschoben: MSS / MTU korrekt setzen