Edomi im Docker-Container - revised

[starwarsfan]

Muß man eigentlich den Container bei der Synology auch über die Konsole mit den Befehlen starten? Da ich ja direkt im Docker den Container einschalten kann ohne Konsole.

Nein, aber Du musst die entsprechenden Einstellungen dann eben im Docker-GUI der Syno machen. Also Umgebungsvariablen setzen und Ports mappen. Aber ausprobiert habe ich das selber noch nicht. Vielleicht kann ja jemand hier mal Screenshots einstellen, der das bei sich auf einer Syno laufen hat!

[beauty]

Muß man eigentlich den Container bei der Synology auch über die Konsole mit den Befehlen starten? Da ich ja direkt im Docker den Container einschalten kann ohne Konsole.

[starwarsfan]

Hi

Weil's auf dem alten auch so ist. Da sehe ich nämlich das Interface mit der IP der Box. Meine Vermutung wäre, dass das Interface natürlich da sein muss, damit die Applikationen (Edomi) drauf hören können...?
Kann aber auch sein, dass ich mich irre.

So ist es, Du irrst Dich.

Beim alten Container gibt es keine eigenen Netzwerkinterfaces, da dieser mit der Option --net=host gestartet wird. Damit werden die Interfaces des Host direkt in den Container durchgereicht. Was Du dort im Container siehst, ist also das Netzwerkinterface des Host und nicht des Containers, da dieser wie gesagt gar keine eigenen hat.

Aber genau das ist dabei die Krux denn man verliert die Freiheit, das Port-Mapping selber zu machen. Damit ergeben sich zwei offensichtliche Probleme:

1. Wird ein Port auf dem Host schon anderweitig verwendet, wird der Container nicht starten (Stichwort Synology)
2. Man kann nur genau einen Container starten und nicht mehrere parallel

Die Ports sind vermutlich nicht belegt.

Vermuten ist nicht wissen!

Es gibt auch nicht wirklich eine Meldung wenn dem so ist, darauf habe ich aber leider auch keinen Einfluss.

Mach doch mal

netstat -tulpn

auf der Edomi-Maschine, wenn kein Container läuft. Wird dort einer der Ports gefunden?

Zumindest kommt keine entsprechende Meldung. Wenn ich nämlich den "alten" Container laufen lasse, dann beschwert sich docker beim start des neuen Containers, dass die Ports schon belegt sind.

OK, das ist schonmal korrekt. Ich habe aber gefragt, ob Du das mal testen kannst, wenn der alte Container gar nicht vorhanden ist!


Aber hier fällt mir was auf:

docker attach zeigt diesen output:
...
08.03.2018 20:19:37 Prozess KNX starten
08.03.2018 20:19:37 Prozess LOGIC starten
08.03.2018 20:19:37 Prozess PHONE starten
08.03.2018 20:19:37 Prozess VISU starten
08.03.2018 20:19:48 ACHTUNG: Mindestens 1 Prozess ist nicht bereit!
08.03.2018 20:19:48 Prozess MAIN beenden... (Modus 13)
08.03.2018 20:19:48 EDOMI: Beenden...
...

Da geht auch nicht wirklich raus hervor wo genau es hakt. Mal sehen ob ein Neuerstellen des Containers was bewirkt.

Doch, steht doch da! Einer der vier Prozesse verweigert den Dienst und damit ist auch ziemlich klar, warum es bei Dir nicht funktioniert. Ich nehme an, beim Phone-Prozess handelt es sich um das Fritzbox-Modul. Wenn Du das aktiviert hast, dann musst Du natürlich auch die dort verwendeten Ports mappen! Per Default findet sich in der Edomi.ini das hier:

global_fbSoapPort=49000
...
global_fbCallMonPort=1012

Damit musst Du diese beiden Ports auch mappen:

...
-p 49000:49000 \
-p 1012:1012 \
...

Ich weiss nicht, ob das TCP oder UDP ist. Musst Du mal ausprobieren und im UDP-Fall noch /udp hinter dem Mapping ergänzen.

Bitte lass uns wissen, ob's funktioniert!

[DerSeppel]

Nein, warum?

Weil's auf dem alten auch so ist. Da sehe ich nämlich das Interface mit der IP der Box. Meine Vermutung wäre, dass das Interface natürlich da sein muss, damit die Applikationen (Edomi) drauf hören können...?
Kann aber auch sein, dass ich mich irre.

Die Ports sind vermutlich nicht belegt. Zumindest kommt keine entsprechende Meldung. Wenn ich nämlich den "alten" Container laufen lasse, dann beschwert sich docker beim start des neuen Containers, dass die Ports schon belegt sind.

docker attach zeigt diesen output:

           >>> EDOMI startet in 3 Sekunden (Abbrechen mit ENTER) <<<
EDOMI-Konfiguration

MAIN START======================================================================
php: no process killed
EDOMI starten...
08.03.2018 20:19:37 Prozess MAIN gestartet
08.03.2018 20:19:37 EDOMI-Version: 1.56
08.03.2018 20:19:37 EDOMI-ClientId: c8f484a0acea4c247f7025ac58b029bb591d0863c9c1
08.03.2018 20:19:37 Server wurde rebootet
08.03.2018 20:19:37 Prüfung: 64-Bit-System
08.03.2018 20:19:37 PHP-Zeitzone: Europe/Berlin (Winterzeit)
08.03.2018 20:19:37 Datenbank: Verbindung herstellen
08.03.2018 20:19:37 Datenbank: 109 Datenbanken überprüft (0 Fehler)
08.03.2018 20:19:37 Datenbank: RAM reservieren (100 MB pro RAM-DB)
08.03.2018 20:19:37 Datenbank: edomiLive erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMcmdQueue löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMcmdQueue erstellen
08.03.2018 20:19:37 Prozess QUEUE starten
08.03.2018 20:19:37 Prozess SYSINFO starten
08.03.2018 20:19:37 Visualisierungen inititalisieren
08.03.2018 20:19:37 Datenbank: edomiLive.RAMcmdQueue leeren
08.03.2018 20:19:37 Datenbank: edomiLive.RAMko löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMko erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMko befüllen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMko modifizieren
08.03.2018 20:19:37 Datenbank: edomiLive.RAMko Index erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElement löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElement kopieren
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElement Index erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElementVar löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElementVar erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicElementVar befüllen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicLink löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicLink erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicLink befüllen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicLink Index erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicCmdList löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicCmdList erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMlogicCmdList befüllen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMknxRead löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMknxRead erstellen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMknxWrite löschen
08.03.2018 20:19:37 Datenbank: edomiLive.RAMknxWrite erstellen
08.03.2018 20:19:37 Prozess KNX starten
08.03.2018 20:19:37 Prozess LOGIC starten
08.03.2018 20:19:37 Prozess PHONE starten
08.03.2018 20:19:37 Prozess VISU starten
08.03.2018 20:19:48 ACHTUNG: Mindestens 1 Prozess ist nicht bereit!
08.03.2018 20:19:48 Prozess MAIN beenden... (Modus 13)
08.03.2018 20:19:48 EDOMI: Beenden...
08.03.2018 20:19:48 EDOMI: Warten auf LBS (3 Sekunden)...
08.03.2018 20:19:52 Prozess SYSINFO (PID=565) beenden
08.03.2018 20:19:52 Prozess KNX (PID=571) beenden
08.03.2018 20:19:53 Prozess LOGIC (PID=573) beenden
08.03.2018 20:19:53 Prozess QUEUE (PID=563) beenden
08.03.2018 20:19:53 Prozess PHONE (PID=575) beenden
08.03.2018 20:19:54 Prozess VISU (PID=577) beenden
08.03.2018 20:19:54 Datenbank: edomiLive.RAMsysInfo löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMcmdQueue löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMko löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMlogicElement löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMlogicElementVar löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMlogicLink löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMlogicCmdList löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMknxRead löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMknxWrite löschen
08.03.2018 20:19:54 Datenbank: edomiLive.RAMsysProc löschen
08.03.2018 20:19:54 EDOMI: Warten auf EXEC-LBS (3 Sekunden)...
08.03.2018 20:19:57 Datenbank: Verbindung schließen
08.03.2018 20:19:57 Prozess MAIN beendet (13)
php: no process killed
MAIN ENDE=======================================================================
 Server wird in 5s neu gestartet...                       (Abbrechen mit ENTER)
Server: Reboot...

Da geht auch nicht wirklich raus hervor wo genau es hakt. Mal sehen ob ein Neuerstellen des Containers was bewirkt.

[starwarsfan]

Hi

Wenn ich eine Konsole auf dem Container aufmache, dann sehe ich nur ein Netzwerk-Interface mit der Adresse 172.17.0.1

Das ist seltsam, die 172.17.0.1 hat normalerweise der Docker-Host und die Container bekommen dann 172.17.0.2, .3 usw. Läuft noch ein anderer Container? Hast Du den "alten" Container mit der --net=host-Option evtl. noch? Wenn ja, dann würde ich diesen löschen und dann nochmals testen.

Eigentlich hätte ich erwartet dass ein Interface mit 192.168.1.88 vorhanden ist.

Nein, warum?

Gestartet habe ich den Container so:

sudo docker run \
--name edomi \
--restart=on-failure \
-p 80:80 \
-p 8081:8081 \
-p 3671:3671/udp \
-p 50000:50000/udp \
-p 50001:50001/udp \
-p 22222:22 \
-e KNXGATEWAY=192.168.1.201 \
-e KNXACTIVE=true \
-e HOSTIP=192.168.1.88 \
-v /data/edomi-backups/:/var/edomi-backups/ \
-d \
starwarsfan/edomi-docker:latest

Das ist korrekt.

Was mich wundert: Ich kann von dem Container aus trotzdem den Router pingen.

Der "alte" container mit HOST option funktioniert problemlos. Hostsystem ist eine VM mit Ubuntu als OS.

Wie oben schon geschrieben, werden die Ports mglw. durch den anderen Container belegt. Diese Konstellation habe ich jedoch nicht getestet, da ich keine weiteren Container auf meinem Host habe/hatte.

[DerSeppel]

starwarsfan
Ich habe gerade mal deine neue Version aufgesetzt, habe aber das Problem, dass der Container immer wieder neu startet (bzw. Edomi).
Es liegt wohl daran, dass keine Verbindung zum KNX Router hergestellt werden kann.

Wenn ich eine Konsole auf dem Container aufmache, dann sehe ich nur ein Netzwerk-Interface mit der Adresse 172.17.0.1
Eigentlich hätte ich erwartet dass ein Interface mit 192.168.1.88 vorhanden ist.

Gestartet habe ich den Container so:

sudo docker run \
    --name edomi \
    --restart=on-failure \
    -p 80:80 \
    -p 8081:8081 \
    -p 3671:3671/udp \
    -p 50000:50000/udp \
    -p 50001:50001/udp \
    -p 22222:22 \
    -e KNXGATEWAY=192.168.1.201 \
    -e KNXACTIVE=true \
    -e HOSTIP=192.168.1.88 \
    -v /data/edomi-backups/:/var/edomi-backups/ \
    -d \
    starwarsfan/edomi-docker:latest

Was mich wundert: Ich kann von dem Container aus trotzdem den Router pingen.

Der "alte" container mit HOST option funktioniert problemlos. Hostsystem ist eine VM mit Ubuntu als OS.

[KNXFan1970]

starwarsfan
Danke für Deine Arbeit am Docker-Container - funktioniert auf Anhieb und ist super dokumentiert.

[starwarsfan]

Back to topic please!

[NetFritz]

hallo
Na ja.
Da gibt es noch eine andere Bedeutung und die ist Böse gemeint.
Gruß NetFritz

[urknall]

Verstehe nicht, was an "Read The Fine Manual" unangemessen sein soll

[gurumeditation]

Freut mich zu hören. Noch kürzer wäre als Anwort wohl nur noch RTFM gewesen...

Sorry für OT, vielleicht schmunzelt ja einer mit:
Der Moment, nachdem du in einer amerikanischen Universität einem Wirtschaftsstudenten in einer IT-Vorlesung auf seine Frage hin erklärst, wofür RTFM steht, ohne vorher den Filter für gesellschaftlich unangemessene Wörter zu bemühen... Priceless. Ebenso die Stille im ganzen Saal, die sich wie eine Ewigkeit angefühlt hat.

Been there, done that, no t-shirt.

[EPIX]

Super Danke für deinen Hinweis...

Port 81, der Aufruf ist dann http://<sysnoip>:81/visu/
und passt perfekt

[starwarsfan]

Freut mich zu hören. Noch kürzer wäre als Anwort wohl nur noch RTFM gewesen...

[Joggi2222]

Ohh Mann
arghhh Herr schmeiß Hirn vom Himmel!
Ich danke! Jetzt funktioniert es perfekt

[starwarsfan]

Moinmoin,

Na dann lies nochmal Punkt 1 von https://github.com/starwarsfan/edomi-docker.