UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Satsh]

@andre

Ich glaube ich habe die Ursache gefunden:

root@iobroker:~# tar tvf /opt/initial_iobroker.tar | grep root.root
drwxr-xr-x root/root              0 2020-10-19 14:15 opt/iobroker/node_modules/iobroker.js-controller/tmp/
-rw-r--r-- root/root           28844 2020-10-19 14:15 opt/iobroker/iobroker-data/backup-objects/2020-10-19_12-15_objects.json.gz
-rw-r--r-- root/root              22 2020-10-19 14:15 opt/iobroker/iobroker-data/backup-objects/2020-10-19_12-15_states.json.gz
-rw-r--r-- root/root               2 2020-10-19 14:15 opt/iobroker/iobroker-data/states.json.bak
-rw-rw-r-- root/root              13 2020-10-19 14:15 opt/iobroker/.install_host

Es gibt im initial_iobroker.tar einige Dateien, die root.root gehören - insbesondere auch die states.json.bak - die der iobroker beim restore 0 wahrescheinlich überschreiben möchte - aber wahrscheinlich nicht kann, weil (Vermutung!) iobroker selber einen priviledge drop macht?

S

[andre]

@Satsh Hab mir das gerade mal genauer angeschaut. In der Tat gibt es da Probleme mit den Berechtigungen.
Habe das jetzt im Startupscript beim Restore abgefangen. Beim ersten Test hat das wunderbar funktioniert. Warum es aber jetzt plötzlich zu solch einem Fehler kommt ist mir ein Rätsel. Mein Letzter Restore am Livesystem hat tadellos funktioniert...

Achso, aktuell ist der Fix noch nicht in der Beta enthalten. Muss noch zwei andere Sachen prüfen (und Dokumentieren) und mache dann eine neue Beta-Version.

MfG,
André

[Satsh]

@andre
Blöde Frage: aber was muss man da groß fixen - außer die Files im initial_iobroker.tar mit den korrekten user/group Rechten zu versehen? Oder übersehe ich etwas und die Ursache war noch eine Andere?

Ich denke es kommt auch darauf an, wie man den Mount einbindet. Bei einem nfs mit all-squash oder einem CIFS mit fixed user credentials würde das Problem nicht auftreten denke ich, da hier der User vom Transportprotokol festgetackert wird - egal welche Berechtigungen das File eigentlich hatte.

[andre]

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

aber was muss man da groß fixen

Nichts, hat ja keiner gesagt dass es was großes ist... ;)

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Files im initial_iobroker.tar mit den korrekten user/group Rechten zu versehen

Seitdem ioBroker unter dem user iobroker läuft, gibt es immer wieder mal Probleme mit Berechtigungen. Aus diesem Grund setze ich im Startupscript bei jedem Start den Eigentümer des gesamten Ordner "/opt/iobroker" im Conntainer auf den user iobroker. Im Falle des Restores müsste das aber zwischen umkopieren restore passieren.
Genau da habe ich es jetzt mit eingefügt, sodass beim restore unter dem user iobroker sichergestellt ist, dass dieser alle relevanten Dateien bearbeiten darf.

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Ich denke es kommt auch darauf an, wie man den Mount einbindet. Bei einem nfs mit all-squash oder einem CIFS mit fixed user credentials würde das Problem nicht auftreten denke ich, da hier der User vom Transportprotokol festgetackert wird - egal welche Berechtigungen das File eigentlich hatte.

Jein. nfs und cifs haben damit wenig zu tun. Der mount im Container ist ja kein echter mount. Vielmehr wird dem Container lediglich der Zugriff auf einen bestimmten Ordner im Filesystem des Hosts gewährt. Das merkt man auch, wenn man sich die Berechtigungen des Ordners auf dem Host mal anschaut...
An der Stelle breche ich jetzt aber ab... Das Thema kann ich hier nicht in ein paar Worten erklären...
Nur soviel: Wenn dich das Thema interessiert, probiere mal die Umgebungsvariablen zu uid und gid... und schau dir dann die Berechtigungen der Dateien im ioBroker Ordner auf dem Host an....

MfG,
André

[Satsh]

@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Seitdem ioBroker unter dem user iobroker läuft, gibt es immer wieder mal Probleme mit Berechtigungen. Aus diesem Grund setze ich im Startupscript bei jedem Start den Eigentümer des gesamten Ordner "/opt/iobroker" im Conntainer auf den user iobroker. Im Falle des Restores müsste das aber zwischen umkopieren restore passieren.
Genau da habe ich es jetzt mit eingefügt, sodass beim restore unter dem user iobroker sichergestellt ist, dass dieser alle relevanten Dateien bearbeiten darf.

Mal ne andere Frage... schonmal über chmod g+s /opt/iobroker nachgedacht? In meinem Falle hätte das das Problem ziemlich sicher erschlagen, aber ich weiß nicht wie Docker das genau mit Volumes handhabt, die über NFS/CIFS bereitgestellt werden.

@Satsh sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Ich denke es kommt auch darauf an, wie man den Mount einbindet. Bei einem nfs mit all-squash oder einem CIFS mit fixed user credentials würde das Problem nicht auftreten denke ich, da hier der User vom Transportprotokol festgetackert wird - egal welche Berechtigungen das File eigentlich hatte.

Jein. nfs und cifs haben damit wenig zu tun. Der mount im Container ist ja kein echter mount. Vielmehr wird dem Container lediglich der Zugriff auf einen bestimmten Ordner im Filesystem des Hosts gewährt. Das merkt man auch, wenn man sich die Berechtigungen des Ordners auf dem Host mal anschaut...
An der Stelle breche ich jetzt aber ab... Das Thema kann ich hier nicht in ein paar Worten erklären...
Nur soviel: Wenn dich das Thema interessiert, probiere mal die Umgebungsvariablen zu uid und gid... und schau dir dann die Berechtigungen der Dateien im ioBroker Ordner auf dem Host an....

Hm ok, mit den Interna von Docker im Bezug auf Volumes habe ich mich noch nicht beschäftigt. Das fällt sonst unter die Kategorie "funktioniert halt" ;)

Danke trotzdem für deine Erklärungen und den Fix.

Gruß
Sascha

[Kraxelhuber]

@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Was die ENV IOB_MULTIHOST angeht, da habe ich aktuell noch keine Doku zu gemacht. Hier geht es im Grunde darum, dass man einen ioBroker Container als Slave konfigurieren kann der sich dann automatisch zu einem Master verbindet. Damit das funktioniert muss die ENV natürlich beim master auf "master" und beim slave auf "slave" konfiguriert werden. Zusätzlich müssen die ENVs für objectsdb und statesdb entsprechend konfiguriert werden... Wer sich mit Multihost auskennt ist natürlich gerne eingeladen auch dies zu testen.

Ich plane bei mir eine Multihost-Lösung aufzubauen. Derzeit habe ich zwei ioBroker Instanzen jweils im Docker Container laufen. Die Hauptinstanz läuft auf einer Synology Diskstation, der zukünftige Slave im Container auf einem RPi.

Vielleicht könnte jemand kurz aufzeigen, wie die Container/Instanzen konfiguriert werden müssen?

Nach meinem ersten Verständnis muss die Environment Variable IOB_MULTIHOST auf master gesetzt werden. Das ist ja auch der Standard, also ist der Container auf der Syno Diskstation schon vorbereitet, oder?

Der Container auf dem RPi erhält dann logischerweise die Environment Variable IOB_MULTIHOST mit dem Wert slave.

Aber ich muss doch sicherlich den Multihost Modus aktivieren, Stichwort iobroker multihost enable (auf dem Master) und iobroker multihost connect auf dem Slave System, richtig? Wie löse ich das in der Docker-Umgebung?

[Berchemer]

Sorry, aber leider ist dieser Threat sehr lang geworden und die Suche hat mich jetzt nicht weitergebracht. Aber natürlich habe ich eine Frage bezüglich der Installation von ioBroker unter Docker :-)

Vielleicht kann mir einer weiterhelfen.

Ich möchte mal wieder gerne eine Neuinstallation durchführen, weil bei früheren Installationen möglicherweise wegen mehrerer parallel laufender ioBroker einige Installationspunkte nicht so abgelaufen sein könnten, wie eigentlich gewünscht.

Dabei wollte ich auch mal ausprobieren, ob Docker wirklich Erleichterung gerade bei Neu- und Testinstallationen bringt.
Ich werde versuchen mich bei der Installation auch an die Vorgabe von buanet halten. Nur werde ich versuchen, das System auf einem x86 unter Ubuntu-Server zu installieren und nicht unter einer nackten debian-Version. Aber auch hier lasse ich mich gerne belehren. GUI brauche ich nicht. Konfiguriere es eh über Putty.

Es geht mir nur um die Frage, ob ich redis und influxdb/grafana als eigenständige Dockerinstallationen auf dem System installieren soll, auf dem auch der ioBroker-Master als eigenständige Dockereinrichtung laufen wird oder ob ich in einer Docker-Maschine ioBroker, influxdb, grafana und redis installieren soll.

Ihr merkt, Docker ist für mich noch etwas Fremdes. Also seid bitte gnädig mit Euren Antworten ;-)

[andre]

@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Ich plane bei mir eine Multihost-Lösung aufzubauen. Derzeit habe ich zwei ioBroker Instanzen jweils im Docker Container laufen. Die Hauptinstanz läuft auf einer Synology Diskstation, der zukünftige Slave im Container auf einem RPi.

Multihost ist zwar im Container noch beta, läuft bei mir aber schon seit einiger Zeit in ähnlicher Konstellation mit zwei slaves ohne Probleme. :)

In der Beta-Readme habe ich auch schon etwas mehr geschrieben:

Multihost (beta)
With the help of the ENV "IOB_MULTIHOST" and the ENVs for objects and states db connections (see ENVs table above) it is now possible to run a container as standalone, multihost master or multihost slave. This is more or less a feature for advanced users. Please make sure you know how ioBroker multihost is working and set the ENVs as with ìobroker setup custom.
For general information about iobroker multihost feature please see official ioBroker documentation.

Also, nach Möglichkeit zum Testen die aktuelle Beta verwenden. In der ioBroker Doku nachlesen wie Multihost überhaupt funktioniert. Stichwort States und Objects DB.
Die Umgebungsvariable IOB_MULTIHOST beim Master setzen. Je nach verwendetem Netzwerk (bei Bridge) müssen auch die Ports 9000 und 9001 geöffnet werden.
Für den Slave ebenfalls die Umgebungsvariable IOB_MULTIHOST setzen. Außerdem die Variablen für objects und states DB, denn der Slave greift ja auf die DBs des Masters zu.
Slave starten und er sollte in der ioBroker Web UI auftauchen.

@Kraxelhuber sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Aber ich muss doch sicherlich den Multihost Modus aktivieren, Stichwort iobroker multihost enable (auf dem Master) und iobroker multihost connect auf dem Slave System, richtig?

Nein. Das wird nicht benötigt!

Quick and Dirty Beispiel aus meinem Setup. Achtung für die States DB nutze ich einen Redis Container!

...wird es auch ein Tutorial zu geben. :)

MfG,
André

[andre]

@Berchemer sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Nur werde ich versuchen, das System auf einem x86 unter Ubuntu-Server

Mhhh... https://github.com/buanet/docker-iobroker/tree/master#iobroker-for-docker

Since v4.0.0 the image is available for the following architectures: amd64, armv7hf, aarch64.

Dafür habe ich kein Image parat...

@Berchemer sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

und nicht unter einer nackten debian-Version

Verstehe ich nicht, wo hat denn wer was von Nackten gesagt? :) Solange es Linux ist und Docker drauf läuft ist es Wurscht. Allerdings spielt die Architektur eine Rolle (siehe oben)...

@Berchemer sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Es geht mir nur um die Frage, ob ich redis und influxdb/grafana als eigenständige Dockerinstallationen auf dem System installieren soll, auf dem auch der ioBroker-Master als eigenständige Dockereinrichtung laufen wird oder ob ich in einer Docker-Maschine ioBroker, influxdb, grafana und redis installieren soll.

Ahhhhhh! Wenn ich "Docker-Maschine" höre stellen sich mir sofort die Nackenhaare auf! :) NATÜRLICH wird für jede Anwendung ein eigener Docker Container verwendet! Wenn man es ganz genau nehmen würde, müsste sogar jeder ioBroker-Adapter in einem eigenen Container laufen (was praktisch aber nicht geht)... Du brauchst dazu auch nur eine "Dockerinstallation". Docker wird als Dienst auf dem Host installiert. Die Anwendungen startest du als Container unter Verwendung des Docker Dienstes.
Also die Antwort auf deine Oder-Frage: JA. Jeder Anwendung sein Container. Verbunden über ein gemeinsames Bridge Netzwerk.
Und lies mal zu docker-compose. Damit kannst du mit einem "Config-File" alle Container inkl. Netze mit einmal deployen...

Viel Erfolg!

MfG,
André

[Kraxelhuber]

@Kraxelhuber said in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Nach meinem ersten Verständnis muss die Environment Variable IOB_MULTIHOST auf master gesetzt werden. Das ist ja auch der Standard, also ist der Container auf der Syno Diskstation schon vorbereitet, oder?
Der Container auf dem RPi erhält dann logischerweise die Environment Variable IOB_MULTIHOST mit dem Wert slave.

Wie weise ich dem Slave den richtigen Master zu?

[andre]

@Kraxelhuber

@andre sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Für den Slave ebenfalls die Umgebungsvariable IOB_MULTIHOST setzen. Außerdem die Variablen für objects und states DB, denn der Slave greift ja auf die DBs des Masters zu.

Indem du dem Slave sagst wo die Master DBs liegen...

MfG,
André

[Berchemer]

@andre sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

@Berchemer sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Also die Antwort auf deine Oder-Frage: JA. Jeder Anwendung sein Container. Verbunden über ein gemeinsames Bridge Netzwerk.
Und lies mal zu docker-compose. Damit kannst du mit einem "Config-File" alle Container inkl. Netze mit einmal deployen...

Viel Erfolg!

Danke erst einmal :-) :+1:

[Kraxelhuber]

@andre said in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Indem du dem Slave sagst wo die Master DBs liegen...

Ja super, das hat bei mir funktioniert.

Habe jetzt einen neuen Container jeweils mit der Beta Version auf der DiskStation (master) und dem RPi (slave) eingerichtet. Grundsätzlich würde ich aber lieber mit der Stable Version arbeiten. Was denkst du denn, wann die Multihost Funktionalität in die Stable Version integriert wird?

[andre]

@Kraxelhuber

Ach Leute, habt doch nicht immer so viel Angst vorm bösen Beta...
Tatsächlich ist es doch so, dass ich das "beta" hinter die Version schreibe und größtenteils auch den Betatest mache...
Und wenn es Läuft dann zähle ich die Versionsnummer hoch und tadaaa, ein neues Stable Release...
So wie gestern auch wieder...

Build ist durch, Version gerade raus: https://github.com/buanet/docker-iobroker/releases/tag/v5.1.0
Image steht im Docker Hub zur Verfügung.

MfG,
André

[Bongo]

Hi,

von Zeit zu Zeit muss auch mal eine Synology gebootet werden. Bei mir wird der Container nicht neu gestartet. In der Synology Docker App kann man "Automatischen Neustart aktivieren". Ich denke wenn man mit Portainer arbeitet sollte man da nichts machen. Oder doch?
Im Portainer habe ich nichts gefunden. Der Portainer selbst wird automatisch gestartet. Wie geht das mit dem ioBroker Container?

[andre]

@Bongo sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

In der Synology Docker App kann man "Automatischen Neustart aktivieren".

Diese Einstellung gibt es im Portainer auch. Da geht es um die restart policy des Containers. Also was macht der Container wenn er z.B. aufgrund eines Fehlers beendet wird. In der Regel stellt man das so ein, dass der Container sich dann selbst neu startet.

Eine dedizierte Einstellung über die man sagen könnte, starte diesen und jenen Container beim Start des Docker Dienstes kenne ich nicht...

MfG,
André

[andre]

Kleines Update

Mit v5.1.0 ist im Docker Hub seit heute Morgen eine neue Stable Version des ioBroker Container Images verfügbar. Details wie immer in der readme.md auf Github

Für alle die ihren ioBroker Docker container automatisch Updaten möchten habe ich jetzt auch ein latest Tag für eine bestimmte Version zur Verfügung gestellt. Aktuell ist das "latest-v5"
Die Verwendung des Tags vermeidet ein automatisches Upgrade auf v6 und bleibt stattdessen immer beim letzten stable innerhalb der v5.

Für mehr Infos und Updates zu meinen Tutorials und Projekten abonniert meinen Telegram Kanal.

MfG,
André

[dslraser]

@andre
Danke :+1: läuft

[Bongo]

@andre
Danke für den Tipp. Ich habe 3 Container wo ich bei einem zum Testen diese Einstellung von Never auf Always geändert habe. Nach dem Restart waren dann alle 3 Container gestartet.
Hmm, ich hätte schwören konnen, dass es beim letzten Mal nicht so war. Das war allerdings kein Reboot sondern ein unerwarteter shutdown. Vielleicht ist das was anderes.

Ich habe noch ein paar alte Test-Container die nicht gestartet sind. Ich vermute was zuletzt gestartet war wird nach einem Reboot wieder gestartet.

Mal sehen was beim nächsten unerwarteten shutdown passiert, der hoffentlich nicht eintreten wird ;-)

[andre]

@Bongo sagte in [HowTo] ioBroker unter Docker auf Synology DiskStation:

Ich vermute was zuletzt gestartet war wird nach einem Reboot wieder gestartet.

So ist es bei reboot eigentlich. Die Restart Policy sagt eigentlich nur, was passiert wenn der container fehl schlägt...
Bisher hatte ich aber auch noch nie Probleme mit dem Restart der DS...