Es gibt bereits eine ansible rolle für radvd
ffmstd-des1 scheint gerade gebootet zu haben:
root@ffmstd-des1 ~ # uptime
17:03:54 up 11 min, 1 user, load average: 0,00, 0,01, 0,01
ffwaf war offline, aber offenbar ist alles wunderbar wieder hochgekommen…
Jap, ich musste den Host leider neu starten müssen, da er (und die VMs) nicht mehr erreichbar waren, d.h. alle VMs wurden neu gestartet. Ausfall lag unter einer halben Stunde (ein Hoch auf Monitoring :P). Dennoch sehr ärgerlich, zumal in den üblichen Logfiles nichts an Fehlern zu erkennen war.
Ich habe noch einen privaten Apache(+MySQL) und Mailserver auf dem Host laufen. Da ursprünglich nur eine Supernode auf meinem System laufen sollte, sah ich da kein Problem drin. Ich bin aber jetzt dabei den verbleibenden Kram in eine eigene VM zu stopfen und danach auf dem Host aufzuräumen, da nicht auszuschließen ist, dass irgendeine dieser Applikationen den Server gekillt hat.
Grüße
Simon
@paulinsche Jap, habe ich auch gesehen. 
Leider ist noch zu viel mit hochgekommen (fastd, dhcp & co.) die müssen noch rausgeworfen werden.
1 „Gefällt mir“
Zur Outage des Forums heute: Ich habe das Forum runtergefahren, um mal ein Snapshot der Platte zu machen. Danach ist es leider nicht mehr hochgekommen.
Falls jemand das mal anfassen muss: Wenn man den Rechner über die Cloud Console runterfährt ist es wohl nicht so ganz sauber.
Fix:
~discourse/.bluepill - sockes und pids löschen
/etc/rc.local
fertig
1 „Gefällt mir“
Server wieder weggehangen.
Folgendes gesehen:
Personalities : [raid1]
md3 : active raid1 sda4[0] sdb4[1]
1847478528 blocks super 1.2 [2/2] [UU]
md2 : active raid1 sda3[0] sdb3[1]
1073610560 blocks super 1.2 [2/2] [UU]
[==>..................] resync = 13.2% (142206784/1073610560) finish=422.1min speed=36771K/sec
md1 : active raid1 sda2[0] sdb2[1]
523968 blocks super 1.2 [2/2] [UU]
md0 : active (auto-read-only) raid1 sda1[0] sdb1[1]
8384448 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Versuche es zeitnah zu analysieren, bin aber gerade auf der Flucht.
Erstaunlicherweise funktioniert das Arbeiten an den Systemen auch bei Tageslicht 
Gerade durch MPW und mich durchgeführt:
- Forumbackup eingerichtet (Siehe https://freifunk-muensterland.de/wiki/doku.php?id=intern:backup)
- Zeitzone des Forum-Servers korrigiert UTC -> CET
Fast ganz Warendorf auf „das Labor“ umgestellt: Nach Absprache mit den in der lokalen Community aktiven, haben diese fast das gesamte Netz in Warendorf auf „das Labor“ umgestellt. Auch in Ennigerloh laufen entsprechenden Experiment. Erstaunlicherweise hat das „non-standard“ Netzwerk an der Freiherr-von-Kettler Schule denn sysupgrade überstanden. Damit hatte ich eigentlich nicht gerechnet.
Damit folgende Entlastung erreicht: 40 Knoten (35 online, 35 neu, 5 verschwunden) mit 104 Clients
Diese Daten sind von Samstag, 21. November 2015 15:23.
Software-Buid: https://github.com/ffmus/site-ffwaf/tree/experimental
Magst du nicht die Firmware imselben Repo führen wie alle anderen Domänen auch?
Der Branch ssh-schluesselverwaltung im Ansible ist mittlerweile soweit vorbereitet, dass ein Rollout der Schlüssel auf einen Großteil der Server möglich ist.
Hierbei muss mit etwas Vorsicht vorgegangen werden, da auch einige andere Änderungen aus der Rolle Common mit übernommen werden.
Die entsprechenden Konfigurationen der host_vars für die Server habe ich soweit möglich ergänzt.
Die noch fehlenden bitte im Branch master einpflegen.
[backbone]
c1024 Technisch OK, Zustimmung Servereigner steht noch aus
fanlin OK
parad0x OK
[supernodes]
sn-fanlin-1 OK
sn-fanlin-2 OK
fussel Technisch OK, Zustimmung Servereigner steht noch aus
sn-parad0x-1 kein Zugriff
sense OK
sn-sense-3 OK
sn-sense-4 kein Zugriff
sn-descilla-1 OK
sn-kgbvax-2 OK
sn-kgbvax-3 OK
[domaene-01]
remue-01 host_vars unvollständig
greyworm-01 OK
sense-02 OK
2 „Gefällt mir“
Eine geplante Umstellung innerhalb von bird hat nicht geklappt. Alles ist zurück gebaut. der Vollständigkeit halber hier die durchgeführten Arbeiten:
Arbeiten an bird am Gateway Parad0x
- Aktuelle config gesichert (bird.bak)
- Umstellung in der bird.conf
- Umstellung aller Bereiche auf ffnet
- ospf zu gre-greyworm1 aktiviert
- bird neu gestartet
- Routing nicht OK. Ursache: Das dynamische routing hängt in einer Schleife die vermutlich mit zusammenbrechenden Tunneln zu tun hat. -> OSPF-Config muss angepasst werden
- config aus bird.bak wiederhergestellt
- Gateway neu gestartet um alle eventuell falsch vorhandenen routen zurück zu setzen
Siehe auch https://forum.freifunk-muensterland.de/t/debian-version-backbone/232
1 „Gefällt mir“
Domäne-01 Status:
- radvd per Ansible ausgerollt
- DNS-Server auf Google gestellt
=> Domäne-01 ist jetzt nutzbar, hat aber nur eine einzige Anbindung über remue-01 zu des1.
2 „Gefällt mir“
Gibts ein aktuelles Schaubild der Server und deren zusammenhänge?
Des1 <--Layer3--> Remü-01 <--Layer2/Batman--> Sense-02
<--Layer2/Batman--> Greyworm-01
Deswegen ist leider auch alles platt, wenn wie heute morgen Remü offline ist. Sense-02 wird dann wohl kurzfristig noch einen Tunnel bekommen und Greyworm-02 an das Backbone angeschlossen werden.
Grüße
Matthias
Ich denke, dass das ipv4 des FFRL gerade ein bisschen kaputt ist: Ein ping auf die NAT-Adresse von des1 liefert:
# ping 185.66.193.52
PING 185.66.193.52 (185.66.193.52) 56(84) bytes of data.
From 194.146.118.149 icmp_seq=1 Destination Net Unreachable
Die 194.146.118.149 ist vermutlich der Router des FFRL. Am bird der des1 konnte ich leider erstmal nichts feststellen. ipv6 läuft.
Die SSH Schlüssel sind jetzt auf die folgenden Server verteilt:
c1024
fanlin
fussel
greyworm-01
parad0x
sense
sense-02
sn-descilla-1
sn-fanlin-1
sn-fanlin-2
sn-kbbvax-2
sn-kgbvax-3
sn-sense-3
Auf remue-01 konnten die Keys nicht verteilt werden, da die Host_Vars im Ansible unvollständig sind.
Die Schlüsselverwaltung wurde jetzt in den Branch master gemerged.
2 „Gefällt mir“
Ich nutze in Warendorf für ipv4 jetzt mal kurzzeitig einen lokalen Exit.
DHCP leases File auf parad0x, c1024 und fussel geflusht, um zu schauen ob sich das positiv auf unser DHCP Problem auswirkt.
Wir haben heute etwas in der bird.conf angepasst. Vorher hat er sich aus allen Interfaces die Routen geholt, jetzt nur noch explizit aus tun-, gre- und br.
@paulinsche
Wir haben wohl das lo interface vergessen, daher fehlte bird kenntnis über folgende route:
185.66.193.52/32 dev lo [direct1 05:13:04] * (240)
(Das ist die “NAT-IP” vom ffrl)
Habe lo als zusätzliches Interface, das bird kennen soll eingetragen. Jetzt sieht sieht die ffnet table bis auf den 5.9.86.151/32 Eintrag genau so aus, wie zuvor mit interface “*”;
PS: Bitte nicht “+” anstatt “*” als wildcard bei Interfaces verwenden, das hat dazu geführt, dass der Server nicht mehr erreichbar war.
1 „Gefällt mir“