kgbvax02 wieder nominal
2 „Gefällt mir“
des1 (Testdomäne) hatte heute Morgen gegen 09:15 einen besorgten Kernel. Gegen 12:20 neu durchgestartet (habe lange geschlafen :D).
Commander hat uns seine VM frisch mit Debian 8 Jessie aufgespielt. @descilla und ich planen anhand der VM jetzt die Ansible-Rollen für das Backbone fertig zu stellen.
Das Backbone in der hosts-Datei wird dann vorläufig Fanlin, Commander und Des1 enthalten. Die anderen werden wir in eine Gruppe legacy-Backbone oder so ausgliedern.
4 „Gefällt mir“
Heute ist gegen 04:02 Uhr ffwaf-srv3 mir kernel-panic gestorben. Damit ist der Server tapfer seit dem Sat Dec 19 21:32 durchgelaufen. Der Kernel ist im batman_adv gestorben.
Gegen 16:28 Uhr wurde der Server rebootet. Allerdings war der „plötzlich“ nicht mehr reboot-fest:
- die Interface-MTU zu fanlin musste von 1280 auf default (1476) angepasst werden
- die interface.d Skripte für das mesh-interface haben angenommen, dass bird6 schon läuft. Das ist nach einem Reboot nicht der Fall. Damit war das interface nicht vollständig im up Status. In die entsprechende Zeile habe ich ein „|| true“ eingefügt.
- tunneldigger.service war nicht enabled und musste von Hand gestartet werden.
Die Redundanz hat insgesamt gegriffen. Es kann jedoch sein, dass es zwischen 16:28 Uhr (reboot) und 17:07 Uhr (Abschluss der Tätigkeiten oben) zu Störungen gekommen ist: von meinem Freifunk-Knoten aus, der mit ffwaf-srv2 verbunden war habe ich zwar nichts festgestellt, jedoch hab ich in einem Smoke-Ping von ffwaf-srv1 in dem Zeitraum Lücken.
2 „Gefällt mir“
Gesten Abend habe ich auf ffwaf-srv2/3 jeweils einen caching DNS installiert (bind9). DHCP/radv(bird) verteilen die neuen Dienste.
In dem Zusammenhang fiel auf, dass Clients an srv3 die public IPv6 Adresse des srv2 nicht erreichen konnten. IPv4 sowie IPv6 Link-Lokal waren ok. Von srv3 aus war die public IPv6 Adresse von srv2 zunächst auch nicht zu erreichen. Nach einem erfolgreichen Ping von srv2 -> srv3 war der Teil des Problems behoben. Ich habe das insgesamt mit tcpdump und Co nicht weiter einkreisen können. Nach einem reboot von srv2 trat das Problem bisher nicht wieder auf.
Im Gegensatz zu den anderen Test-Domänen sind srv2/3 über eine bridge verbunden, nicht direkt über das batman-Interface. Dabei setze ich auch das Feature bridge loop avoidance.
Die VM sn-descilla-1 hat wohl einen übern Durst getrunken und Panik bekommen. Läuft jetzt wieder.
Warendorf ist jetzt bald vollständig mit L2TP unterwegs. Entsprechenden Firmware im Stable wird gerade hochgeladen…
1 „Gefällt mir“
Habe auf sämtlicher fanlin-Hardware Kernel und Git-Sicherheitsupdates eingespielt. Reboot ist heute um 24:00.
2 „Gefällt mir“
Seit ca. gestern 23:00 schien der Grahite-Dienst im überlast zu laufen.
Das Problem konnte ich heute durch neustarten des Docker Containers beheben.
Wenn der Umzug des Graphite auf die neue Service-VM hier keine Verbesserung bringt müssen wir hier ggf. die Datenanlieferung durch die collectd-Dienste auf den Servern reduzieren (aktuell alle 10 Sek.)
1 „Gefällt mir“
Ich habe heute um 15:00 die Firmware-Version 191 auf stable gesestzt und die Manifeste aus dem Git-Repo aktualisiert.
Bis heute Abend sollte der größte Teil der Knoten bereits aktualisiert sein.
3 „Gefällt mir“
ffwaf-srv2 ist jetzt l2tp-only. Um das MainIF/MAC beizubehalten habe ich ein dummy-device angelegt, dass als erstes in die batman-bridge kommt: Name supernode.
MainIF/MAC: supernode/de:ad:be:ef:43:02
Den Trick hatte ich im großen Forum aufgeschnappt. Kürzlich hatte ich nach einem restart des fastd ein Phantom gejagt, weil immer die MAC eines anderen LT2P Interface als MainIF/MAC genutzt wurde. Ich schlage vor, das so auf allen Systemen zu übernehmen.
Ich bitte darum, die Maschinen ins Ansibel aufzunehemen. Der erste Schritt wäre die ssh-keys zu verteilen. Bitte darum deswegen mit mir Kontakt aufzunehmen!!
1 „Gefällt mir“
Updates auf fusselkater und parad0x eingespielt. Reboot heute um 23:00 bzw 24:00.
2 „Gefällt mir“
kgbvax02/03 aktualisiert und durchgestartet
2 „Gefällt mir“
ffwaf-srv1/2/3 aktualisiert. Reboot nicht nötig, da kein neuer Kernel kam. Wir fahren da 4.2.6-3~bpo8+2.
2 „Gefällt mir“
ffwaf-srv[2|3].freifunk-muensterland.net haben jetzt die ssh-keys von diversen Admins… Quelle: ffmstd-des1
1 „Gefällt mir“
Firmware-Downloader der Internetseite auf Version 191 umgestellt.
Wegen dem fehlenden ForcePull-Feature von Docker über Kommentar-“Trick” in der git-pull-Zeile ein nicht verwenden des Cache erzwungen.
P.S.: Durch den großen Community-Druck wird es das Feature in 2016 hoffentlich geben.
1 „Gefällt mir“
Service-VM angepasst:
- Karten-URLs haben /maps/-Prefix erhalten (damit wir auch andere Komponenten auf der Service-VM im Webserver verfügbar machen können),
- karte.freifunk-muensterland.org als Virtual Host in nginx nutzt dieses Prefix, so dass alte URLs weiterhin funktionieren
Michael und ich haben heute alles für die Knotenumzüge bereit gemacht:
- firmware.ffms in der alten Domäne auf 2a01:4f8:191:21e1::23 gesetzt
- das Warendorfer Manifest geändert um eine höhere Version vorzuspielen und neu signiert
- Dieses und die Firmware auf dem neuen Firmwaeserver verfügbar gemacht
- Rewrite für einen einzigen Knoten gesetzt: http://karte.freifunk-muensterland.org/map/#!v:m;n:e894f64296de
Und jetzt heißt es warten.
@FanLin: Ich nehme an, du hattest den reboot zeitgesteuert gesetzt? War bisschen witzig, als die Kiste auf einmal meinte, dass sie jetzt neu startet ;).
Nach @FanLin s Neustart liefen die DHCP-Server irgendwie nicht mehr und DNS war auch noch kaputt. Ich hatte jetzt keine Zeit mehr das zu untersuchen und hab die DHCP-Server neu gestartet und zur Sicherheit 8.8.8.8 und die üblichen dazu eingetragen.
/edit: Kurze Analyse hat ergeben, dass es vermutlich nur am DHCP lag.
Zu erledigen: Google-DNS-Server wieder rausschmeißen und DHCP automatisch starten lassen
Ja.
Auf welcher Kiste? Rebootet wurden fusselkater und parad0x. Auf beiden ist der dhcpd allerdings schon unter /etc/init.d eingetragen,