Cometvisu - neuester Container

[FabKNX]

Hallo @Chris M. ,

kannst noch mal eine Anleitung für DAu´s veröffentlichen (wie im ersten Post), welcher Container gerade der aktuellste ist und wie man ihn einrichtet?

Das wäre echt klasse.
Danke

[Chris M.]

@FabKNX ja, sehr bald. Aktuell ist ToDo:

1. Die aktuelle 0.10.2 auf CometVisu/CometVisu bereitstellen
2. Die Influx-Unterstützung finalisieren und in den aktuellen 0.11-dev mergen
3. Auf dem Timberwolf die InfluxDB so bereitstellen, dass die CometVisu da leicht darauf zugreifen kann
4. Doku für die CometVisu im Docker Container erstellen

Der erste Punkt muss einfach nur gemacht werden. Bis dahin einfach hier im Thread oben spricken.
Den zweiten wollte ich bereits letztes Wochenende fertig haben. Aber da ich es gleich richtig machen wollte inkl. Editor-Einbindung und allen Möglichkeiten die die InfluxDB bietet (z.B. Tags) ist's nun etwas umfangreicher geworden. Im Wesentlichen fehlt nur noch bisschen Testen, optimaler Weise Testfälle erstellen und die Doku nachziehen.

Bei dem letzten Punkt stecke ich nicht drinnen. Mit dem Beta12er Update ist die Situation sogar schwieriger geworden, da die InfluxDB auf Authentifizierung umgestellt wurde und man sich erst mal ein Passwort besorgen muss Den Weg dazu mag ich nicht beschreiben, das gibt zu viele Nachfragen.
Ich gehe aber davon aus, dass das seitens ElabNet notwendige Schritte sind um 3. zu erfüllen.

Nach 1. und 2. kommt von meiner Seite 4. - was ja genau der Wunsch von Dir ist.

[StefanW]

Ich gehe aber davon aus, dass das seitens ElabNet notwendige Schritte sind um 3. zu erfüllen.

Ja, richtig, wir wollten nur einen geordneten Weg dafür schaffen. Kommt demnächst bzw. Ihr Entwickler steht untereinander in Kontakt.


lg

Stefan

[Auweia]

Hallo Chris,
auf einem Testsystem Pi3 habe ich die CV 0.11.0-dev (build vom 26.11.18) und die Original CV Konfiguration geladen, da ich hoffentlich bald einen TS 2600 bekomme und dann gleich auf die 0.11 wechseln möchte. Beim Einrichten des /cgi-bin/l bin ich auf 2 Probleme gestoßen:
1. auf dem Github : https://github.com/CometVisu/Docker/blo ... entrypoint
in Zeile 20 :
sed -i 's@\\\"s\\\":\\\"SESSION\\\".*}\"@\\\"s\\\":\\\"SESSION\\\", \\\"c\\\": {\\\"baseURL\\\": \\\"'"$CGI_URL_PATH"'\\\"} }"@' /usr/lib/cgi-bin/l
fehlt da eine geschweifte Klammer ?
2. jedenfalls bekomme ich in der CV den Error 404 : Fehler beim Laden von /usr/lib/cgi-bin/l?u=demo_user: 404 - Not Found.
Wird da das falsche backend benutzt ?

Ich möchte eigentlich nur die CV testen: deshalb erfolgt der Aufruf mit /visu/?enable Cache=invalid&testMode=1

VG
Albert
PS: Sollen wir ein neues Thema "Test CV V0.11.0" eröffnen?

[Chris M.]

auf einem Testsystem Pi3

Ui, ein RPi ist ein arm basiertes System. Getestet sind die Container bisher nur auf amd64 Systemen. Für arm müssten die anders übersetzt werden - wie das mit DockerHub automatisch machbar ist ist mir aktuell unbekannt. Ich habe auch kein arm System zum Testen, grundsätzlich sollte der CometVisu Container aber auch in einer arm Version erstellbar sein.

habe ich die CV 0.11.0-dev (build vom 26.11.18) und die Original CV Konfiguration geladen, da ich hoffentlich bald einen TS 2600 bekomme und dann gleich auf die 0.11 wechseln möchte. Beim Einrichten des /cgi-bin/l bin ich auf 2 Probleme gestoßen:
1. auf dem Github : https://github.com/CometVisu/Docker/blo ... entrypoint
in Zeile 20 :
sed -i 's@\\\"s\\\":\\\"SESSION\\\".*}\"@\\\"s\\\":\\\"SESSION\\\", \\\"c\\\": {\\\"baseURL\\\": \\\"'"$CGI_URL_PATH"'\\\"} }"@' /usr/lib/cgi-bin/l
fehlt da eine geschweifte Klammer ?

Wieso? Das sed ersetzt etwas mit "}" durch etwas mit "{ } }", somit sollte doch das Ergebnis passen, oder?

2. jedenfalls bekomme ich in der CV den Error 404 : Fehler beim Laden von /usr/lib/cgi-bin/l?u=demo_user: 404 - Not Found.
Wird da das falsche backend benutzt ?

Selbst wenn der sed ein l erzeugt, dass kein gültiges JSON auswirft (was z.B. bei nicht passenden geschweiften Klammern passiert), so wird es kein 404 geben. Das würde ein 200 ergeben mit ungültigem Inhalt. (Und - ungetestet - wenn das echo durch das sed kaputt werden würde, dann würde ich ein 500 erwarten)

Ich möchte eigentlich nur die CV testen: deshalb erfolgt der Aufruf mit /visu/?enable Cache=invalid&testMode=1

Ganz passt diese URL so nicht. Aber schau einfach erst mal, dass das ganze grundsätzlich mit der Demo-Config läuft, dann kann man wegen dem Rest schauen.

PS: Sollen wir ein neues Thema "Test CV V0.11.0" eröffnen?

Ja, aber bitte unter https://knx-user-forum.de/forum/supportforen/cometvisu - dort werde ich auch bald (dieses Wochenende?) noch einen Thread für die Docker-Images erstellen.

[Auweia]

Vielen Dank für den Hinweis auf die Demo-Config. Leider bekomme ich hier auch den gleichen Fehler- 404 Not found. Ich werde mir die Konfiguration von Apache2 noch genauer ansehen.
VG - Albert

[StefanW]

Hallo Chris,

[*]Auf dem Timberwolf die InfluxDB so bereitstellen, dass die CometVisu da leicht darauf zugreifen kann

wir haben hierüber heute intern gesprochen und ich wollte das mit Dir kurz abstimmen, wie wir das machen.

Vorwort: Wir sind ein wenig Security-verrückt, daher wollen wir nicht bei jedem Timberwolf ein "General-Lese-Passwort" für die influx-DB installieren, dass überall gleich wäre, weil es handelt sich schließlich um personenbezogene Daten und darum vershclüsseln wir die ganze Platte ja auch.

Vorschlag: Der TWS generiert - jeder für sich - ein individuelles Zugriffspasswort dass der Kunde in der Userverwaltung auslesen kann. Dieses trägt er als Startparamter im Portainer ein und beim Start der CometVisu wird es vom Portainer übergeben.

==> Damit bliebe es in der Hand des Besitzers, ob und wem gegenüber er den Leszugriff auf die Influx freigibt.

Wie ist Deine Meinung dazu? Praktikabel?

lg

Stefan

[Chris M.]

Als Königsweg könnte ich mir vorstellen:

• In der Benutzerverwaltung kann man für User Rollen freischalten, z.B. "InfluxDB Lesen"
• Dieser User hat mit seinem eigenen Passwort Lese-Zugriff auf die Datenbank
• In der Docker-Verwaltung kann man den InfluxDB-Port für Docker freischalten (optimal: individuell pro Container)

Hiermit sollte der Sicherheit eigentlich absolut Genüge getan sein. (Einfach einen extra Influx-Lese-Account anlegen, der sonst nichts darf)

Besonders schön wäre natürlich, wenn dem offiziellen CV-Container (bzw. dem CV-Config-Volume) in der dort abgelegten "Hidden-Config" der Log-In automatisch hinterlegt werden könnte ("synchronisiert"). Das würde Config-Aufwand (und damit Fehlermöglichkeiten) beim Anwender reduzieren.

[StefanW]

Hallo Chris,

wir haben es nun folgendermaßen gelöst. Damit der Kunde nicht erst einen Account anlegen muss und dort dann womöglich ein "schlechtes" Passwort verrgibt, erzeugen wir jetzt eines automatisch (wie bei einem API-Key) und zeigen das auf der Portainer-Seite an, wenn man auf das blaue i drückt.

Das sieht dann so aus:



Dieses kann man dann beliebig (ob von der CV oder auch aus anderen Applikationen) verwenden.

In der Docker-Verwaltung kann man den InfluxDB-Port für Docker freischalten (optimal: individuell pro Container)

Das sollte mit Portainer jetzt schon gehen.

Besonders schön wäre natürlich, wenn dem offiziellen CV-Container (bzw. dem CV-Config-Volume) in der dort abgelegten "Hidden-Config" der Log-In automatisch hinterlegt werden könnte ("synchronisiert"). Das würde Config-Aufwand (und damit Fehlermöglichkeiten) beim Anwender reduzieren.

Klar. Wir können schon automatisch eine Datei ablegen in einem Volume, dass man vom Container aus mounten kann um den Key dort dann aus der Datei auszulesen.

Wir hättest Du es denn gerne?

lg

Stefan

[gbglace]

Ich sehe ide gute usability geht auch in den "Anbausystemen" weiter. Sehr schön.

Für die Kosmetik @StefanW , spendiert dem Hinweistext noch ein " r " (Dieser) und "einen ...en" ( einen ausschließlichen) in der letzten Zeile dann ist das rund würde ich sagen.