CV Container latest vs testing

[Fireworker]

Warum sieht das bei

latest anders aus

2022-03-17.png als bei testing

2022-03-14.png

[peuter]

Weil das ein Bug ist der gestern gefixt wurde, wenn Du Dein testing auf die aktuellste Version (Stand jetzt: 7 Stunden alt) bringst, sollte das wieder gleich aussehen.

[Fireworker]

OK hab Ich gerade gemacht mit

docker run --name CometVisu81 -e KNX_INTERFACE=' iptn:10.0.0.100:3671' --restart unless-stopped -d -p 8081:80 -v CometVisuConfig:/var/www/html/CV81 cometvisu/cometvisu:testing

und bekomme folgende Fehlermeldung

2022-03-17 (1).png


Stimmt bei dem Installations-Befehl alles? was mir aufgefallen ist in dem angegebenen Ordner /var/www/html/CV81 steht nichts drinnen

[peuter]

Wenn der Befehl der einzige ist, denn Du benutzt hast, dann kann das nicht gehen. Eine aktuelle Version bekommst Du mit "docker pull cometvisu/cometvisu:testing" dazu musst Du auch den laufenden Container löschen und stoppen bevor Du den neuen startest, siehe auch https://phoenixnap.com/kb/update-doc...lder%20release.

Und wo hast Du das her: "-v CometVisuConfig:/var/www/html/CV81"? Wundert mich, dass das überhaupt irgendwas lädt. Eigentlich solltest Du damit gar keine Configs in deinem Container haben bzw. nur die original mitgelieferten Und Änderungen dürften einen Container-Neustart nicht überleben.
Die Rechte Seite von ":" muss zwingend immer "/var/www/html/resource/config" sein, weil das der Pfad im Container ist in dem die Configs liegen. Und "CometVisuConfig" (also der Teil vor dem ":") ist dein lokaler Pfad außerhalb des Containers, der dann in den Container gemountet wird. (https://docs.docker.com/engine/refer...-v---read-only)

[Fireworker]

hab es jetzt nochmal nach deiner Anleitung gemacht (vorher den alten Container gelöscht)

docker run --name CometVisu81 -e KNX_INTERFACE=' iptn:10.0.0.100:3671' --restart unless-stopped -d -p 8081:80 -v CometVisuConfig:/var/www/html/resource/config cometvisu/cometvisu:testing

im Portainer sieht das dann so aus wenn es fertig ist

2022-03-17 (2).png 2022-03-17 (3).png
kommt aber trotzdem wider eine Fehlermeldung

2022-03-17 (4).png

[peuter]

Kommt der Fehler auch, wenn Du die Config ganz normal öffnest? Der Screenshots ist ja aus dem Xml-Editor und der Fehler in der Vorschau-Ansicht.
Ansonsten müsstest Du mal beide Haken in der Fehlermeldung aktivieren und auf neu laden klicken. Ich weiß aber ehrlich gesagt nicht ob dieser Mechanismus in der Config-Vorschau richtig funktioniert.

[Fireworker]

Ja kommt auch eine Fehlermeldung

2022-03-17 (5).png

[peuter]

Leider verhindert der Fehler, dass die entscheidende Information in dem Fehlerreport landet. Kannst Du mal in der Netzwerk-Konsole des Browsers nach einem Request für "/cgi-bin/l?u=demo_user" ausschau halten und hier posten was in der Antwort steht (oder ob es eine Fehlermeldung gab und somit gar keine Antwort gibt)?

[Fireworker]

2022-03-17 (7).png Meinst Du das?

[peuter]

Ja, nur dass das nicht die Antwort ist. Die steht in "Response" oder "Preview" der Screenshot zeigt "Headers"

[Fireworker]

Da steht leider nicht drinnen
2022-03-17 (8).png 2022-03-17 (9).png

[Fireworker]

welcher User führt die Dateien aus von der CV? var/www/* ist für User www-data mit 0777

[peuter]

Der User unter dem der Webserver läuft, üblicherweise ist das "www-data" (oder so ähnlich). Da das aber alles im Container passiert brauchst Du dich darum nicht zu kümmern.

Ich interpretiere das jetzt so, dass da keine Antwort kommt (bzw. eine leere) und das könnte möglicherweise zu dem Fehler führen. Jedenfalls ist da irgendwas faul mit deinem Container. Da ich openHAB als backend benutzte kann ich hier aber nicht weiterhelfen, damit kenne ich mich nicht aus. Vielleicht hat Chris M. eine Idee.

[Fireworker]

Gibt es da im Container ein eigenes /var/www/ ? Wenn ja ist das verschlüsselt oder so? denn mit der suche finde ich nur eines, das am Hauptsystem.....
oder greift CV auf das /var/www/ des Hauptsystems zu?

[peuter]

Ich kann Dir nur raten Dich in Geduld zu üben und zu warten bis hier jemand mit einem konstruktiven Vorschlag um die Ecke kommt. Anhand der Fragen kann man sehen, dass Dir das nötige Detailwissen fehlt um dem Problem auf den Grund zu gehen. Wenn Du jetzt anfängst im Container rumzufummeln ohne zu wissen was Du da wirklich tust, dann wird Dir nachher hier niemand mehr helfen können, weil keiner mehr weiß was Du da alles verstellt/probiert hast. An der Stelle erlischt sozusagen die Garantie.

Und die Antworten zu den Fragen in Kurzfassung: Ja, Nein, Nein. Man kann sich in einen Container einloggen um den Inhalt von /var/www zu sehen, aber ich schreibe nicht wie, weil s.o. -> Bitte nicht da drin rumfummeln, das macht nur mehr kaputt.

Man steuert/konfiguriert den Container nur über die Environment-Variablen, d.h. an der Stelle ist der Fehler zu suchen und nicht im Container.