Ankündigung

**saegefisch** · 25.06.2019, 21:01

Vielen Dank für Deine Hinweise, werde ich mal nachgehen.
WAN von LE, aber im LAN nutze ich eigene Zertifikate.

**jonofe** · 25.06.2019, 21:06

Ich denke du musst das CA certificate deiner CA, welche das SSL Zertifikat des EDOMI Servers signiert hat, den vertrauenswürdigen CAs auf deinem Influx Server hinzufügen. Diese befinden sich je nach OS in verschiedenen Dateien:

/etc/ssl/certs/ca-certificates.crt // Debian/Ubuntu/Gentoo etc.
/etc/pki/tls/certs/ca-bundle.crt // Fedora/RHEL 6
/etc/ssl/ca-bundle.pem // OpenSUSE
/etc/pki/tls/cacert.pem // OpenELEC
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem // CentOS/RHEL 7

Alternativ sollte es auch möglich sein die SSL Verification auf dem Influx Server auszuschalten.

verify_ssl: false

**saegefisch** · 26.06.2019, 18:20

Hi André,
lieben Dank. Nachfrage: Ich habe damals auf meinem zentralen Linux-Server (Ubuntu) mir eine alle damaligen Server ([...V3_req]... DNS.1=...IP.1=...umfassende /etc/ssl/openssl.cnf angelegt und dann mit den Schlüsseln meiner CA dies ausgeführt

Code:

 sudo openssl ca -name CA_default -gencrl -keyfile ./private/cakey.pem -cert ./cacert.pem -out ./private/ca.crl

und soweit ich mich erinnern kann mit einem Befehl alle Server-Zertifikate meines LAN für meine CA erstellt - auf einen Schlag. edomi war damals nicht dabei, weil ja nicht https-fähig.

Die Frage: Wenn ich jetzt für edomi in der cnf-Datei einen Abschnitt ergänze und den Befehl wieder ausführe: Werden dann für die bisherigen Server die gleichen Dateien/Zertifikate erzeugt oder sind es andere? Wenn es andere sind: Werden meine bisherigen ungültig/abgelöst? Das wäre dann eine Menge Arbeit und mag ich gerne vermeiden... Kurz gefragt: Ist die erneute Ausführung von -gencrl gefahrlos? Oder: Kann ich bei einer umfassenden .cnf auch auch nur für einen Server -gencrl laufen lassen?

Dann hätte ich auch Server-Zertifikate für edomi und vermutlich wird die crt-Datei von openssl schon entsprechend ergänzt.

**jonofe** · 26.06.2019, 19:18

Dieser Befehl generiert doch nur eine Certificate Revocation List (CRL), oder?
Ich verstehe den Zusammenhang mit dem ursprünglichen Problem nicht.

Aber ich sehe gerade, dass der ursprüngliche Fehler ja ein remote error ist, d.h. dein Grafana Server hat einen Fehler geloggt, der auf der Client-Seite aufgetreten ist (LBS). Dieser baut ja eine Verbindung via curl auf. Und der Fehler bedeutet, dass curl auf dem EDOMI Server dem SSL Zertifikat des Grafana Servers nicht vertraut. Ich denke du musst dein CA Certificate "cacert.pem" dem /etc/pki/tls/certs/ca-bundle.crt auf dem EDOMI Server hinzufügen bzw dem cainfo file, welches für php definiert ist. Das sollte in /etc/php.d/curl.ini stehen.

Alternativ müsste der LBS angepasst werden:

PHP-Code:


curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

**saegefisch** · 26.06.2019, 22:00

Hi André,

Du bist mit Deinen Expertisen unglaublich treffsicher (womit Du mir mehfach wöchtlich zum Lächeln bringst)...doch sieh's mir nach, ich habe dazu nur noch ein grauseliges Halbwissen. Damals habe ich mich sehr intensiv damit beschäftigt, das Thema Let's Encrypt, Server Zertifikate für meinen Server-Zoo und auch die Client-Zertifikate für meine Dienste über den RevProxy erarbeitet und lauffähig bekommen. Damals war ich recht fit. Langes Wiki mir selber geschrieben, aber an der für meine heutige Frage relevanten Stelle zu dünn und da erzähl' ich bestimmt auch mal was falsch... sorry...

Ich dachte, die mit dem öffentlichen und privaten Schlüssel der CA erzeugten CRL werden dann (nach Prüfung) signiert mit seiner CA (durch das PW des CA-Schlüssels) und dadurch dann CRT, üblicherweise im PEM-Format. In meiner Frage ging es ja darum, dem edomi-Server in meinem LAN mit meiner CA eine Zertifikat zu erstellen, was nach meinem Verständnis CRT als PEM sind.
Signieren ist ja kein Ding, aber meine Frage bezog sich auf die Erstellung der dafür erforderlichen CRL. Ich brauche ja nur für edomi eins, nicht aber noochmal für die anderen Server, die sind ja schon versorgt und tatsächlich läuft fast mein gesamter inter-LAN-Verkehr mittlerweile ebenfalls per SSL (Ausnahmen: edomi, TVH-frontend, pi-hole-Frontend). InfluxDB war bis vorgestern auch noch ohne und habe nun auf https umgestellt.

Daher war die Frage: Ist es gefahrlos, sich auch für laufende Server neue CRL zu erzeugen als "Beifang" für ein erstmaliges CRL für edomi oder beinflusst das meine bestehenden Zertifikate? Die Frage ist ganz allgemein (für mich) interessant.

Aber zum Grundproblem zurück:
Grafana ist dabei denke ich unbeteiligt.
InfluxDB (auf zentralem Ubuntu-Server) erhält Daten u.a. von telegraf von sich selbst, aber z.B. auch vom RevProxy. OK, problemlos.
Edomi per LBS aber wird von InfluxDB abgewiesen, seit ich auf https umgestellt habe.

In /etc/pki/tls/certs/ca-bundle.crt ist die cacert.pem bereits enthalten, das hatte ich wohl schon früher mal gemacht. Sollte also OK sein und erfüllt Deinen und Michales Lösungs-Vorschlag.
Den LBS um
Code:
```
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);
```
zu ergänzen funktioniert wunderbar, InfluxDB nimmt dann wieder Werte. Ist eine Lösung: OK

Aber ist das die beste Lösung? Schöner wäre ja sicher, PHP in die SSL-Lage zu versetzen, oder? Oder ist das akademisch?

Falls ja, bleibe ich problemlos bei der Lösung drüber...ansonsten zur Ausgangslage:

Für PHP habe ich in /etc/php.d/curl.ini nur 2 Zeilen:

Code:

; Enable curl extension module
extension=curl.so

Eine cainfo finde ich leider gar nicht im System: find / -iname cainfo*. Damit ist vermutlich ursächlich, dass PHP keine Kenntnis von der CA des aufrufenden Dienstes hat

Frage: Was muss ich tun, um PHP darüber in Kenntnis zu setzen?

Ich breite das gerade etwas aus, weil vielleicht andere von meiner Frage und unserer Lösung später profitieren können...

Danke und viele Grüße,
Carsten

**jonofe** · 27.06.2019, 05:59

Hi Carsten,
zu deiner ersten Frage bin ich leider auch nicht wirklich auskunftsfähig

Zu dem Zertifikatsproblem: Hier könntest du mal folgende Zeile zur /etc/php.d/curl.ini hinzufügen:

Code:

 
 curl.cainfo = /etc/pki/tls/certs/ca-bundle.crt

Dann sollte curl für alle SSL Aufrufe die Zertifikate als trusted einstufen, welche mit den CA-Zertifikaten aus dieser Datei signiert wurden. Ist also dein CA-Zertifikat in dieser Datei und hat deine CA auch das SSL Zertifikat deines Influx-Servers signiert, dann sollte damit das Problem gelöst sein.

Diese Einstellung ist dann systemweit für PHP gültig. Alternativ kann man das CAINFO File auch spezifisch für eine CURL Anfrage setzen. das würde dann mit

PHP-Code:


curl_setopt($ch,CURLOPT_CAINFO,'<pfad_zu_deinem_cacert_bundle_file');

Also einfach der SSL_VERIFYPEER auskommentieren und mit diesem Befehl ersetzen. Das cacert-bundle File ist dann wie oben angegeben /etc/pki/tls/certs/ca-bundle.crt oder es kann auch das einzelne Zertifikatsfile deiner CA sein, also cacert.pem. Das musst du dann nur irgendwo auf deinem EDOMI Server ablegen und den Pfad hier entsprechend anpassen.

Ansonsten ist natürlich auch das

PHP-Code:


curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

aus meiner Sicht ausreichend, denn damit bleibt ja die SSL Verschlüsselung erhalten, nur kann nicht verifiziert werden, dass das SSL Server Zertifikat von einer vertrauenswürdigen CA ausgestellt/signiert wurde. Für den internen Betrieb halte ich es für unkritisch, wobei natürlich die o.g. erste Variante die beste Lösung wäre.

**saegefisch** · 27.06.2019, 11:08

Hallo André,

Zitat von jonofe Beitrag anzeigen

PHP-Code:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);

aus meiner Sicht ausreichend, denn damit bleibt ja die SSL Verschlüsselung erhalten, nur kann nicht verifiziert werden, dass das SSL Server Zertifikat von einer vertrauenswürdigen CA ausgestellt/signiert wurde. Für den internen Betrieb halte ich es für unkritisch, wobei natürlich die o.g. erste Variante die beste Lösung wäre.

=> Da haben wir offenbar die gleichen Abschätzungen, sehe ich exakt genauso.Tatsächlich habe ich bei telegraf bereits diesen Weg gewählt.

Zitat von jonofe Beitrag anzeigen

zu deiner ersten Frage bin ich leider auch nicht wirklich auskunftsfähig

=> Unfassbar, dass ich das mal erlebe...

schade, habe irgendwie auch in Suchmaschinen falsch gesucht, auf jeden Fall nichts gefunden. Wäre allgemein interessant, aber die Antwort gebe ich mir dann wohl in paar Jahren selber, wenn die Zertifikate Ihr Lebensende erreichen und ich ohnehin dran muss...

Ergebnis: Sammlung der Lösungs-Optionen - aufsteigend in der Reihenfolge der Lösungsqualität (aus meiner Sicht)

Code:

[COLOR=#000000][COLOR=#0000BB]curl_setopt[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$ch[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]CURLOPT_SSL_VERIFYPEER[/COLOR][COLOR=#007700], [/COLOR][COLOR=#0000BB]0[/COLOR][COLOR=#007700]); [/COLOR][/COLOR]

>>> OK: Funktioniert

Code:

[COLOR=#000000][COLOR=#0000BB]curl_setopt[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$ch[/COLOR][COLOR=#007700],[/COLOR][COLOR=#0000BB]CURLOPT_CAINFO[/COLOR][COLOR=#007700],[/COLOR][COLOR=#DD0000]'[/COLOR][/COLOR]/etc/pki/tls/certs/<cacertmeinserver>.pem[COLOR=#000000][COLOR=#DD0000]'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR]

>>> OK: Funktioniert (spezifisch im LBS für eine CA)

Code:

[COLOR=#000000][COLOR=#0000BB]curl_setopt[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$ch[/COLOR][COLOR=#007700],[/COLOR][/COLOR][B]CURLOPT_CAPATH[/B][COLOR=#000000][COLOR=#007700],[/COLOR][COLOR=#DD0000]'[/COLOR][/COLOR]/etc/pki/tls/certs[COLOR=#000000][COLOR=#DD0000]'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR]

>>> Nicht getestet, habe ich aber in der PHP-Doku zu CURL gesehen.

Code:

[COLOR=#000000][COLOR=#0000BB]curl_setopt[/COLOR][COLOR=#007700]([/COLOR][COLOR=#0000BB]$ch[/COLOR][COLOR=#007700],[/COLOR][COLOR=#0000BB]CURLOPT_CAINFO[/COLOR][COLOR=#007700],[/COLOR][COLOR=#DD0000]'[/COLOR][/COLOR]/etc/pki/tls/certs/ca-bundle.crt[COLOR=#000000][COLOR=#DD0000]'[/COLOR][COLOR=#007700]);[/COLOR][/COLOR]

>>> OK: Funktioniert (spezifisch im LBS für alle CA), wenn CA in CRT enthalten oder PEM-Inhalt manuell in CRT eingefügt wird.

In /etc/php.d/curl.ini eintragen

Code:

curl.cainfo = /etc/pki/tls/certs/ca-bundle.crt

>>> OK: Funktioniert (vmtl. Systemweit PHP), wenn CA in CRT enthalten oder PEM-Inhalt manuell in CRT eingefügt wird.
Ich habe mich für die letzte Lösung entschieden, weil sie edomi gesamtheitlich in meinem LAN hilft.

Wieder eine Herausforderung gelöst. Danke!

**saegefisch** · 27.06.2019, 11:22

Hallo Michael

gulp2k : Danke für Deine Lösungshilfe vor ein paar Tagen, Dein letzter Satz traf ja genau den Punkt (ich wusste nur nicht direkt wie).

Folgende Ergänzungen mag ich noch für den LBS vorschlagen:

Im Log von InfluxDB sieht man schön, wer was POSTet, weil anderer Quellen offenbar den "useragent" belegen, nur der Input aus edomi ist unsichtbar. Wenn man folgendes ergänzt, wäre schon mal statisch mehr Info da
Code:
```
curl_setopt($ch, CURLOPT_USERAGENT, 'EDOMI/LBS19001034');
```
oder noch besser mit einem wählbaren Text, weil zumindest ich den LBS vielfältig einsetze und man dann direkt sieht Fritzbox, PV, WW, Lüftung,...
Code:
```
curl_setopt($ch, CURLOPT_USERAGENT, 'EDOMI/LBS19001034/<wählbarer Text über zusätzlichen Eingang>');
```
oder den ganzen Text über einen E und der ist vorbelegt auf "EDOMI/LBS19001034". Tausend Möglichkeiten...
Wenn Du ohnhin dran gehen solltest, könnte man für Menschen, die die gleiche Frage mit https haben, in der Hilfe ergänzen, dass die CA des InfluxDB-Servers in der /etc/pki/tls/certs/ca-bundle.crt enthalten sein muss oder die Prüfung mit curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); ausschalten kann (und ggf. auskommentiert direkt im Code schon einfügen). Vielleicht würde sich sogar ein weiterer Eingang lohnen, um das an/aus zu schalten. Oder Beim Protokoll gibt es eine 3. Option, z.B.: "http, https, https_noverify" die dies macht.

Ist aber alles Kür, Dein LBS war und ist klasse und hilft mir sehr. Nach Beseitigung meines CA-Fehlers jetzt auch mit "https"...

VG, Carsten

**bas29** · 07.08.2019, 17:15

Hi zusammen,

ich stehe hier etwas auf dem Schlauch und brauche mal Hilfe:

image_87139.png

Docker mit grafana und influx. das "batch" script krieg ich einfach nicht ans laufen, es gibt immer einen HTTP 400 Code zurück.

Auszug aus der individual log

Code:

2019-08-07 18:04:44 896308 10339 - EXEC LBS19001034(1093) 1: - Data: edomi,1 2=199[LF]edomi,3 4=92161[LF] - Info Dauer: 0.004882s, HTTP-Code: 400, URL: http://docker:8086/write?db=edomi
2019-08-07 18:04:44 947930 10341 - EXEC LBS19000398(1095) 1: - Data: Watt value=199 - Info Dauer: 0.033225s, HTTP-Code: 204, URL: http://docker:8086/write?db=edomi

Auszug aus der log von influx

Code:

192.168.177.102 - edomi [07/Aug/2019:18:00:18 +0200] "POST /write?db=edomi HTTP/1.1" 400 131 "-" "EDOMI/LBS19001034" 739c53df-b92c-11e9-8105-0242ac140002 620
192.168.177.102 - edomi [07/Aug/2019:18:00:18 +0200] "POST /write?db=edomi HTTP/1.1" 204 0 "-" "-" 73a5ca8d-b92c-11e9-8106-0242ac140002 15104

influxdb.conf:

Code:

[meta]                                                                                                                                                                      
 dir = "/var/lib/influxdb/meta"                                                                                                                                        
[data]                                                                                                                                                                      
 dir = "/var/lib/influxdb/data"                                                                                                                                            
engine = "tsm1"                                                                                                                                                          
 wal-dir = "/var/lib/influxdb/wal"                                                                                                                                        
[http]                                                                                                                                                                      
log-enabled=true                                                                                                                                                            
suppress-write-log = false                                                                                                                                                  
access-log-path = "/var/lib/influxdb/log"                                                                                                                                  
write-tracing = true

Kurzum. mit der Influxdb scheint ja alles io zu sein, da es die Werte annimmt. Einer eine Idee woran es noch liegen kann bzw. wie ich weiteres logging aktiviere um das Problem einzugrenzen? Oder mach ich was grundsätzlich falsch? Habe jetzt bewusst mal nur Nr. als Spalten und Tags mitgegeben, weil ich auch das als Fehler ausklammern wollte. Aber damit klappts auch nicht.

Gruß und dank bas29

**gulp2k** · 07.08.2019, 17:38

spontan, authentifizierung? schick mal live werte.
kann mir vorstellen das ein leeres passwort feld die url kaputt macht...

**bas29** · 07.08.2019, 19:05

Hi, sorry... das ist nicht leer und war nur raus genommen für den Screenshot. Denke aber das die Authentifizierung ja gleich sein sollte, weil die Werte gleich sind. Wenn ich es richtig verstanden habe, dann ist das Script doch auf der Basis von dem anderen entstanden. Oder kann ich bei den andere Dingen was falsch gemacht haben? Also line Protokoll, der Auto-Delimiter-String?

Bildschirmfoto 2019-08-07 um 19.57.42.png

**gulp2k** · 07.08.2019, 19:29

Trag mal bei E10 “Watt” ein und lass alles unter E11 leer.

**bas29** · 08.08.2019, 08:07

Morgen Michael, danke für die Hilfe:

Leider noch nicht erfolgreich: Bildschirmfoto 2019-08-08 um 08.59.06.png

Auszug aus log ohne E12 & E13:

Code:

2019-08-08 08:49:11    849716    31225    -    EXEC LBS19001034(1093) batch: 
2019-08-08 08:49:11    890928    31227    -    EXEC LBS19000398(1095) 1:  - Data: Watt value=332 - Info Dauer: 0.054446s, HTTP-Code: 204, URL: http://docker:8086/write?db=edomi##

Auszug log influx db - nichts kommt bei der influxdb an:

Code:

192.168.177.102 - edomi [08/Aug/2019:08:49:01 +0200] "POST /write?db=edomi HTTP/1.1" 204 0 "-" "-" 9a8d4db4-b9a8-11e9-9917-0242ac140002 26043
192.168.177.102 - edomi [08/Aug/2019:08:49:11 +0200] "POST /write?db=edomi HTTP/1.1" 204 0 "-" "-" a1016cff-b9a8-11e9-9918-0242ac140002 48958
192.168.177.102 - edomi [08/Aug/2019:08:49:24 +0200] "POST /write?db=edomi HTTP/1.1" 204 0 "-" "-" a8c111ee-b9a8-11e9-9919-0242ac140002 19978

Auszug aus der log mit E12 &E13:

Code:

2019-08-08 09:03:03 347134 16169 - EXEC LBS19000398(1095) 1: - Data: Watt value=2559 - Info Dauer: 0.025321s, HTTP-Code: 204, URL: http://docker:8086/write?
db=edomi
2019-08-08 09:03:04 859339 16208 - EXEC LBS19001034(1093) batch: - Data: Watt,1 2=2336[LF] - Info Dauer: 0.00515s, HTTP-Code: 400, URL: http://docker:8086/write?db=edomi

Es kommt was an, aber immer nur mit Fehler (400 Bad Request)

Code:

192.168.177.102 - edomi [08/Aug/2019:08:53:31 +0200] "POST /write?db=edomi HTTP/1.1" 400 63 "-" "EDOMI/LBS19001034" 3bd7482f-b9a9-11e9-9933-0242ac140002 530
192.168.177.102 - edomi [08/Aug/2019:08:53:31 +0200] "POST /write?db=edomi HTTP/1.1" 204 0 "-" "-" 3bd524ff-b9a9-11e9-9932-0242ac140002 32834

PS. Ja ich habe das Script von dir dahingehend geändert das ich den Vorschlag von Carsten aufgenommen habe um in der Influxdb Log erkennen zu können woher der Eintrag kommt. Das Batch Script hat also folgenden Eintrag bekommen:

Code:

curl_setopt($ch, CURLOPT_USERAGENT, 'EDOMI/LBS19001034');

Ich stehe hier leider etwas auf dem Schlauch und verstehe nicht woran es noch liegen kann und bin daher für jede Idee dankbar.

Gruß
Sebastian

**gulp2k** · 08.08.2019, 23:28

dann probier es bitte erst nochmal mit meiner version vom download portal. ich bin leider im Urlaub und kann nicht viel testen, aber bis jetzt hatte noch niemand solche Probleme deshalb denke ich das der LBS selbst gehen sollte.

**saegefisch** · 09.08.2019, 00:02

Vielleicht liegt es an den Werten in "Tags" und "Field"; in dem Screenshot hast Du sie numerisch belegt: Versuche daher statt "1" und "2" z.B. mal "a=b" und "wirkleist"

Die Tags dienen performanten und/oder einfachen Zugriffen, um in grafana mit wenigen Handgriffen Gruppen automatisch/dynamisch zu selektieren und auszugeben. Sie werden in der Numenklatur "<tagname>=<tagwert>" (und bei Bedarf mehrere mit Komma getrennt) belegt, also z.B. "dev=TV,raum=WZ".
Field darf meines Wissens nicht numerisch beginnen, wenn es nicht gequotet wird (ich weiß nicht, ob der LBS das macht), aber eine 1 als Wertname erscheint mir auch nicht zielführend. Beides könnte wohl möglich zu einem Fehler/nicht schreiben führen.

Daher: Mal angenommen, Du möchtest dei Leistung von Geräten (in Watt) ablegen, dann würde für mich eher Sinn ergeben
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=TV,raum=WZ" | Field: "wirkleist"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=Foen,raum=DG_Bad" | Field: "wirkleist"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=Sonos,raum=WZ" | Field: "wirkleist"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=etage,raum=OG" | Field: "wirkleist"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=gesamt" | Field: "wirkleist"
und gleich noch mehr neben der Wirkleistung
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=TV,raum=WZ" | Field: "cosphi"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=TV,raum=WZ" | Field: "strom"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=gesamt" | Field: "strom"
Metric: "Elektro" | Value: aus GA/iKO | Tag: "dev=gesamt" | Field: "spannung"
Metric: "Temp" | Value: aus GA/iKO | Tag: "raum=WZ" | Field: "temp"
Metric: "Temp" | Value: aus GA/iKO | Tag: "raum=WZ" | Field: "temp_max"
...
So kannst Du z.B. leicht ein Diagramm zeichnen lassen für die Wirkleistung alle Verbraucher im WZ (selbst wenn morgen ein Gerät dazu kommt). Oder aller einer Etage. Oder alle Werte des TV. Oder...

PS: LBS funzt seit Wochen super verlässlich - im Original genauso wie adjustiert...

Ankündigung

InfluxDB / Grafana

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar