Administratives Tagebuch

Nachdem wir vermehrt Probleme gemeldet bekommen haben und diese ebenfalls bestätigen konnten rollen wir auf die vorherige batman-adv version zurück.

  • gw*.darmstadt.freifunk.net
  • batman-adv: auf Version 2016.3 downgraded

Wir haben noch eine weitere VM als GW hinzugefügt.

Die Teilausfälle der IPv4-Konnektivität konnten wir auf die von batman-adv eingesetzte Distributed ARP Table eingrenzen, weshalb wir nun einen weiteren Versuch für einen Workaround ausrollen.

  • gw*.darmstadt.freifunk.net
    • batman-adv: erneut auf 2016.4 aktualisiert
    • batman-adv: Distributed ARP Table deaktiviert

Für weitere Kapazitäten stellen wir kürzlich bereits gw03 bereit, nun folgt ein weiteres. Dies sollte Kapazitäten und Balance verbessern. Die experimentelle Firmware vom 27.11. kennt bereits gw03, die vom 29.11. dann auch gw06. Mit 0.9.1 werden die neuen Gateways auch für Knoten auf dem stable und beta Update-Channel bereitstehen.

1 „Gefällt mir“

Ein Beitrag wurde in ein neues Thema verschoben: Wozu ldap.darmstadt.freifunk.net?

  • api.darmstadt.freifunk.net
    • Subdomain auf www1.darmstadt.freifunk.net umgezogen, leider bekommen wir aufgrund von Letsencrypt Ratelimits derzeit keine neuen Zertifikate, daher ist dieser Dienst derzeit nicht verfügbar. Das betrifft bspw. unsere Präsenz auf https://www.freifunk-karte.de.

    There were too many requests of a given type :: Error creating new cert :: Too many certificates already issued for: freifunk.net

2 „Gefällt mir“
  • gw01.darmstadt.freifunk.net
    • auf Kernel 4.8 aktualisiert
      • durch aktivierte Signaturprüfung im Kernel bevorzugt dieser signierte Module beim laden, weshalb wir hier derzeit mit der in-tree Version von batman-adv (2016.3) statt der selbstgebauten (2016.5) auskommen müssen.
1 „Gefällt mir“
1 „Gefällt mir“
  • gw*.darmstadt.freifunk.net
    • auf Kernel 4.8.15 aktualisiert, der in seiner Debian-Paketierung einen Patch enthält, der das Problem von CVE-2016-9919 behebt.
    • batman-adv auf v2016.5-1-g205dc83 aktualisiert
  • forum.darmstadt.freifunk.net
    • Discourse auf 1.8.0.beta1 aktualisiert
1 „Gefällt mir“
  • gw01.darmstadt.freifunk.net
    • auf Kernel 4.9.2 aktualisiert, derzeit in Evaluation, in kürze dann ggf. auch auf den verbleibenden Gateways
  • forum.darmstadt.freifunk.net
    • Discourse auf 1.8.0.beta4 aktualisiert
    • Docker Storage Driver von devicemapper auf overlay2 migriert; Discourse wies auf den fehlenden Support hin:

Your Docker installation is not using a supported storage driver. If we were to proceed you may have a broken install.
aufs is the recommended storage driver, although zfs/btrfs and overlay may work as well.
Other storage drivers are known to be problematic.
You can tell what filesystem you are using by running “docker info” and looking at the ‘Storage Driver’ line.

If you wish to continue anyway using your existing unsupported storage driver,
read the source code of launcher and figure out how to bypass this check.

1 „Gefällt mir“
2 „Gefällt mir“

Wir stellten gerade Paketverlust von ~30% auf rumple.darmstadt.freifunk.net, einem unserer geclusterten VM-Hosts fest. Dabei wurde in regelmäßigen Abständen die NIC zurückgesetzt. Dieses Problem betrifft gw05/gw06 und besteht mindestens seit Beginn des Wochenendes und eskalierte heute sehr auffällig. Wir haben daraufhin einen Neustart der Maschine eingeleitet

e1000e 0000:07:00.1 eth0: Reset adapter unexpectedly

Da es sich um ein VM-Cluster auf Basis von DRBD handelt musste der Partner-Node belle.darmstadt.freifunk.net ebenfalls neugestartet werden. Das führte zu einem weiteren kurzzeitigen Ausfall von gw02/gw03.

Update 0:50 Uhr:
Die Netzwerkkarte auf rumple.darmstadt.freifunk.net zeigt erneut den gleichen Defekt. Wir fahren gleich zur Colocation und tauschen die Karte aus.

Update 1:55 Uhr:
Die Netzwerkkarte wurde erfolgreich ausgetauscht, der Betrieb ist wieder hergestellt. Wir beobachten die Situation noch weiter.

Update 4:07 Uhr:
Der Server ist nicht mehr erreichbar, wir werden morgen versuchen die Ursachen und unsere Möglichkeiten zu ergründen. Bis dahin sind wir auf 400 eingehende VPN Verbindungen eingeschränkt, weshalb manche Knoten keine Verbindung zum Netz aufbauen können.

Update 17:40 Uhr:
Der Server läuft nun ohne die PCIe Netzwerkkarte und wir haben auf die internen Netzwerkinterfaces umgestellt. Wir beobachten nun die weitere Entwicklung.

3 „Gefällt mir“
  • www1.darmstadt.freifunk.net
    • vhost/map.darmstadt.freifunk.net
      • Durch den Absturz des Servers wurde ein Teil der Kartensoftware unvollständig ausgerollt, dies wurde nun manuell korrigiert.
  • gw*.darmstadt.freifunk.net
    • Peerlimit für VPN Verbindungen von 100 auf 130 angehoben, d.h. wir haben nun Platz für 520 VPN Verbindungen.
2 „Gefällt mir“
  • *.darmstadt.freifunk.net
    • Prometheus Node Exporter eingerichtet
  • www1.darmstadt.freifunk.net, forum.darmstadt.freifunk.net
    • nginx Metriken bereitgestellt, werden derzeit noch nicht abgefragt
  • elsa.darmstadt.freifunk.net
    • Prometheus und Prometheus Alertmanager eingerichtet
    • Wir testen derzeit Rules und Alerting in #ffda-mon auf irc.hackint.org
  • ns*.darmstadt.freifunk.net
    • CAA Record für darmstadt.freifunk.net hinterlegt, die Zertifikatausstellung auf non-wildcard Zertifikate von Letsencrypt beschränken soll. Das bedeutet, dass wir für jede Zertifikatsausstellung die erprobten Validierungssschritte von Letsencrypt durchführen müssen.

@ CAA 0 issue “letsencrypt.org
@ CAA 0 issuewild “;”
```

1 „Gefällt mir“