Eulenkarte - mapconfig

@PetaByteBoy hint: ffdus war draussen, da das Generator-Script wohl die Trennzeichen nicht in Leerzeichen verwandelt hatte.

die erste Zeile von
/etc/fastd/dus/fastd.conf lautete
bindany:10010default;

Ich habe das jetzt manuell angepasst, ich fürchte aber, dass die gen.sh das beim nächsten mal wieder kaputt geht.
Vermutlich (!) ist dieser commit rausgefallen. Und ich weiss nicht, wie ich den wieder hineinbekommen sollte, bzw von welchem Repository die derzeit aktive gen.sh gecloned ist.

Ich weiss nicht, ob das jetzt funktioniert, die erste Zeile habe ich durch die Zweite ersetzt.

#       replace /etc/fastd/$3 BIND ${7//_/}
        replace /etc/fastd/$3 BIND "$(echo $7 | sed 's/_/ /g')"

Abgesehen davon wäre ich massiv unzufrieden, wenn es nicht gelänge, die Datenbank („Teil des Netzes“, Offline-Nodes) der alten Karten und die Datenbank der bisherigen Prometheus/Grafan-Installation herüberzuholen.
Nich nur, weil mir dann etwas fehlt, sondern weil auch andere Leute bei uns mit diesen Daten wirklich arbeiten, um die Infrastruktur Umbauten in den Geflüchtetenunterkünften (Auswirkungen von Kanaloptimierungen etc) zu monitoren.

Und als dritte Post:
ich habe auf den map1 jetzt mal 2 CPUs je 2 HT-cores geworfen plus 4GB Ram.
Scheint dem Ding erheblich Beine zu machen.

Immerhin redest du im Konjunktiv. Ich bin dabei. Hab’s gestern nicht mehr geschafft. Jetzt kopiere ich die 4.4 GB an Daten rüber.

Super! Vielen Dank für den Einsatz!

Tja…

No space left on device

Musste „resizefs“ machen. Das Image hatte ich schon vergrößert von 8 auf afaik 30GB, wollte aber die Kiste selbst nicht runterfahren für das vergrößern. (Keine Ahnung, ob das nicht auch OnTheFly geht)

Geht online, aber die Swap-Partition ist im Weg…

Daten sind drüben. Auch die raw.jsons. Leider werden 90% der Knoten als neu angezeigt. Ich werde es aber so belassen. Im Notfall sagen die Statistiken einiges.

Sie werden bei jedem Server-Neustart wieder als „neu“ angezeigt für den Reboot-Zeitpunkt.

Ist zwar eher was für Debugging „Zur Lindung“, kann aber wegen Düsseldorf-Intern nicht jeder lesen:
Welchen Angaben soll ich jetzt vertrauen, diesen hier:
http://map.ffdus.de/#!v:m;n:60e327c70a3c

Oder diesen hier:
https://karte.ffdus.de/#!v:m;n:60e327c70a3c

Auf der „map“ ist der Knoten online, auf der „karte“ seit 10 Stunden keine Antwort. Nur das Client-Datenvolumen auf der map passt eher zum Status „offline“.

Der Router ist zwar online, aber hat keine guten Verbindungen oder die sind stark überlastet.

Oder aber er hat sich aufgehangen. Das passiert manchmal.

Oder aber der Bug „MoW aktiv, aber kein Gerät angeschlossen → undefinierter Zustand“ ist wieder da.

Hmm… immer noch Probleme mit der karte.ffdus.de?
Da ich einige Instabilitäten bei „meiner“ Unterkunft hier habe, wäre eine zuverlässige Karte praktisch.

Die Mettmanner Map sieht auch mager aus:
https://met.karte.neanderfunk.de/#!v:m

Petabyteboy arbeitet dran.
Die Problematik mit dem Kartenserver sollte sich jetzt dahingehend verbessern, dass es -wenn dieses Setup nun durch ist und die alten Daten herübergerettet sind- zwei unabhängige Karteninstanzen gibt.
Eine produktiv, eine development.

Fehler war diesmal „nicht hinreichend validierte externe Pull requests“.
„sieht gut aus“ heisst eben leider nicht „funktioniert auch in anderen Setups.“

Ein Fehler war eben „mergen von Datenquellen in der falschen Reihenfolge“, so dass ständig Knoten als „neu“ gefunden wurden, die es eben nicht waren.

1 „Gefällt mir“

Ich habe noch letzte Änderungen am Produktivserver vorgenommen - erfolgreich und ohne Downtime:
Die SSL-Konfiguration aller Karten ist nun ein wenig aufgemotzt. Damit steigt das Rating von „B“ zu „A+“.

+Alias https://map.ffgek.de Gelsenkirchen
+Instanz Siegen https://siegen.map.eulenfunk.de
+Übersicht Siegerland https://siegerland.map.eulenfunk.de

4 „Gefällt mir“

Die Nicht-(EC)DHE-Cipher-Suites solltest du vielleicht noch abschalten. Die hat man normalerweise nur für Kompatibilität zu XP + IE, aber die sperrt ihr eh schon aus. Sonst kann ein erfolgreicher Downgrade-Angriff nämlich FS deaktivieren.

Und OCSP-Stapling fehlt noch, das geht mit nginx auch recht easy: OCSP-Stapling in nginx | DFN-PKI Blog

1 „Gefällt mir“

DNS-sec wäre auch schön. Das ist dann aber schon Extremsport, den niemand zu schätzen weiss hinterher.
(Und natürlich nicht auf dem Server zu machen, sondern eben beim DNS.)

Irgendwann gegen 14 Uhr hat’s wieder zugeschlagen-

Wobei auf der „systemctl status“ zumindest mir jetzt unverdächtig vorkam, aber der service restart darauf hat geholfen.

root@eulenmap /h/adorfer# systemctl status prometheus
● prometheus.service - LSB: Prometheus monitoring system and time series database
   Loaded: loaded (/etc/init.d/prometheus; bad; vendor preset: enabled)
   Active: active (exited) since Mi 2016-05-04 04:24:56 CEST; 11h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 23268 ExecStop=/etc/init.d/prometheus stop (code=exited, status=0/SUCCESS)
  Process: 23279 ExecStart=/etc/init.d/prometheus start (code=exited, status=0/SUCCESS)

Mai 04 04:24:56 eulenmap systemd[1]: Starting LSB: Prometheus monitoring system and time series database...
Mai 04 04:24:56 eulenmap systemd[1]: Started LSB: Prometheus monitoring system and time series database.
root@eulenmap /h/adorfer# systemctl restart prometheus
root@eulenmap /h/adorfer# systemctl status prometheus
● prometheus.service - LSB: Prometheus monitoring system and time series database
   Loaded: loaded (/etc/init.d/prometheus; bad; vendor preset: enabled)
   Active: active (running) since Mi 2016-05-04 16:01:58 CEST; 8s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 11620 ExecStop=/etc/init.d/prometheus stop (code=exited, status=0/SUCCESS)
  Process: 11631 ExecStart=/etc/init.d/prometheus start (code=exited, status=0/SUCCESS)
    Tasks: 9 (limit: 512)
   Memory: 609.5M
      CPU: 2.093s
   CGroup: /system.slice/prometheus.service
           └─11640 /usr/sbin/prometheus -config.file /etc/prometheus/prometheus.yml -storage.local.path /var/lib/prometheus/data -web.console.templates /etc/prometheus/conso

Mai 04 16:01:58 eulenmap systemd[1]: Starting LSB: Prometheus monitoring system and time series database...
Mai 04 16:01:58 eulenmap systemd[1]: Started LSB: Prometheus monitoring system and time series database.