Eulenkarte - mapconfig

PharmaJoe · 3. Mai 2016 um 19:10

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.

Lutz · 3. Mai 2016 um 19:48

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

adorfer · 3. Mai 2016 um 20:27

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.

PetaByteBoy · 3. Mai 2016 um 22:24

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

yayachiken · 4. Mai 2016 um 07:01

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

adorfer · 4. Mai 2016 um 09:30

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.)

adorfer · 4. Mai 2016 um 14:52

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.

adorfer · 5. Mai 2016 um 04:29

Um mal die Ingrid zu machen:

das Prometheus ist eine echte „nightly“ mit allen Seiteneffekten. Aber ältere laufen nicht unter dem aktuellen Ubuntu-LTS (haben andere schon zu geschrieben)
Der Service, was den Prometheus da startet ist ein elender Hack. Wenn das Ding aussteigt (und z.B. weder Tasks, noch CPU hat), dann startet der nicht neu
Den Prometheus per Cron einmal die Stunde neu zu starten ist nur ein Notnagel.

PetaByteBoy · 5. Mai 2016 um 20:01

Sollte jetzt stabiler sein. Das Init-Script wurde durch einen systemd-Service ersetzt, der erkennt wenn Prometheus abstürzt und automatisch wieder startet.

PetaByteBoy · 5. Mai 2016 um 20:21

Hab jetzt andere ciphers eingestellt.

OCSP-Stapling ist jetzt auch drin.

Pinky · 6. Mai 2016 um 12:43

internal server error

adorfer · 6. Mai 2016 um 12:45

Sollte das ein Posting werden?
Oder ist das eine Meldung, die Du erhältst?
Wenn ja, wo?

Pinky · 6. Mai 2016 um 12:48

dachte das erkennt Ihr so.
Map, global, Übersichten, haben alle rote Flag und darauf klicken bei response kommt internal server error
also map hat wieder Dashboard init failed Flag

Datens cheinen auch nicht so richtig zu sein, bekommen für Leichlingen 123 Knoten online. Wäre nett, ist aber noch nicht.

edit
fehler ist weg

adorfer · 9. Mai 2016 um 04:40

Ich habe dem Mapserver jetzt 8GB Ram gegeben.
Aber ich vermute, dass das „so“ nicht reicht.
Da müssen andere Optimierungen in die Spur. Denn das initiale Laden der Datenbanken „nach dem Restart“ riecht geradezu nach „FullTableSearches“…

PetaByteBoy · 9. Mai 2016 um 04:54

Ich habe aber auch den Prometheus restart rausgenommen.
Probieren wir mal restart jeden Tag.

adorfer · 9. Mai 2016 um 05:11

Ich hoffe eher, dass sich evtl Daten >48h evtl. auf 30min-Intervalle aggregieren lassen. Um die Datenmenge auszudünnen.
Und die Datenrate könnte man evtl. gleich (im Intervall?) vorberechen und speichern lassen. Dann müsste man nicht ständig Bytecounter-Differenzen bilden.

Aber wie man das konkret tut: Keine Ahnung. Es scheint aber Mechanismen in Prometheus für zu geben.

adorfer · 9. Mai 2016 um 16:28

@PetaByteBoy
Das Grafana ist mal wieder in die Jagdgründe gegangen.
Ich könnte davortreten, aber ein PostMortem wäre evtl. sinnvoller.

PetaByteBoy · 9. Mai 2016 um 16:37

Platte war voll weil auf map1 der Standardwert für die Datendichte (alle 10 Sekunden) eingestellt war.

Ich ziehe jetzt vollständige Daten von map2 rüber.

PetaByteBoy · 12. Mai 2016 um 04:43

Es scheint jetzt auch unter Ubuntu stabil zu laufen. Da ich die Daten vom Arch rübergezogen habe, gibt es keine Lücken.

Ich muss aber noch schaffen, dass die Daten mach 1 Woche ausgedünnt werden.
Und Traffic deltas vorberechnen …

PetaByteBoy · 15. Juli 2016 um 17:43

Vor ca. 2 Tagen habe ich ein Update von Grafana eingespielt. Das hat die Bildchen kaputt gemacht (eine Errormeldung draufgezeichnet). Heute habe ich das gefixed. Die Lösung war, die „fullscreen“-Option aus den eingebundenen URLs zu entfernen.

Heute habe ich den Prometheus geupdated. Das Update hat einigen Schaden angerichtet:
Das Initscript wurde „enabled“ (autostart ein), ich hatte es vorher „disabled“ (autostart aus), um es durch eine eigenes Systemd-Servicefile zu ersetzen. Dadurch dass das Initscript vor dem Servicefile startete, war der Port bereits belegt…
Zweitens hat sich das config-Format geändert. Ich habe die Config an das Format angepasst.

Ich habe eine „path.sh“-Datei eingeführt, in der einzelne Änderungen an den Configs vorgenommen werden können, nachdem diese neu generiert wurden. Die patch.sh wird nach dem „./gen.sh all“ gestartet und blendet aktuell die Kontaktadressen auf der Wuppertaler Karte aus.

Außerdem wurde das Zertifikat für map.ffdus.de renewed.

Es wurde vorgeschlagen, die Grafana-Bildchen per nginx für 5min zu cachen. Ich halte diese Idee für sinnvoll.