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

[Glasfaser]

@mumurik

Zeige mal den Inhalt von

cd /opt/iobroker 

nano package.json

[dslraser]

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

Aber die Frage ist , wie kommt das in ioBroker rein !

vielleicht indexiert er den Ordner ? (die Ordner kann man ja selbst angeben)

Zitat von der verlinkten Seite:

In der Regel ist der Index Service dafür verantwortlich, solche Dateien/Ordner zu verwalten. Wird der Shared Folder per SMB verbunden, sind die Ordner nicht sichtbar. Wird der Shared Folder per NFS oder AFS verbunden, sind die Ordner zu sehen und sind teilweise sehr störend.

[Glasfaser]

@dslraser

Ich würde es eher so machen ..
Synology komplett neu starten und dann den Container neu anlegen .
Da muss etwas bei der Synology sein .... anders kann ich mir es nicht vorstellen .
Also mit dem ioBroker Image ( Container ) hat es weniger zu tun .
Bin auch am Ende ... weiter weiß ich auch nicht , was es sein kann.

[dslraser]

@Glasfaser
Hier schreibt auch Jemand wie diese Verzeichnisse zu Stande kommen.

https://www.markus-gerber.ch/2014/07/eadir-auf-synology-nas/

Aber wie gesagt, helfen kann ich da auch nicht...

[Glasfaser]

@dslraser

Danke für deine Tipps ( wie immer ;) ) ....
Ich habe kein Rat dazu ..... aber das ist die Entscheidung von @mumurik ob er was löscht .

[andre]

@mumurik Ich hab jetzt zwar nicht alles gelesen, aber die "@eaDir" Verzeichnisse kommen wohl von der Medienindizierung. Hast du mal geschaut ob da bei dir vielleicht was aktiviert ist? Kann mir schon vorstellen, dass es ggf. ungünstig ist, wenn die DS den Ordner indiziert in dem dein iobroker liegt und dann dort vielleicht auch noch Verzeichnisse anlegt...

Im Zweifel würde ich mal probieren für den Ordner /opt/iobroker auf der DS einen anderen Pfad zu nehmen. Dann ne frische Container Installation machen und über restore ein Backup einspielen.

MfG,
André

[mumurik]

Also, Indizierung war für den iobroker-Verzeichnis nicht eingeschaltet, aber die "@eaDir" Verzeichnisse wurden wohl nach der Migration automatisch angelegt (ich hatte vor kurzem eine Migration von DS213j zu DS220+).

Ich habe jetzt alle "@eaDir" Verzeichnisse manuell gelöscht und den Container neuangelegt -> keine Probleme mehr mit der Installation des Adapters!

@Glasfaser @dslraser @andre
Vielen lieben Dank an alle für die hilfreichen Tipps!

[Glasfaser]

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

wurden wohl nach der Migration automatisch angelegt
ich hatte vor kurzem eine Migration von DS213j zu DS220+

dann passt das auch zu diesem Link @eaDir auf dem Synology NAS

Zitat :

Nach dem Zurückspielen eines Backups auf meinem Synology-NAS stellte ich fest, dass dieses, ohne mich zu fragen, überall seine @eaDir Verzeichnisse eingefügt hat. 

keine Probleme mehr mit der Installation des Adapters!

Schön das es jetzt geht ... :face_with_thermometer: :cold_sweat:

War auch ein blöder Fehler am Anfang bis man darauf kommt !

[Satsh]

Leider habe ich ein Problem mit dem Upgrade von 4.2.0 auf 5.0.0.

Habe mittels BackItUp ein Minimal-Backup erzeugt, den Container heruntergefahren, den Container gecloned und dabei das Image mit neuem Tag gepulled, sowie den Mount auf ein neues Verzeichnis umgebogen. In das root des neuen Verzeichnisses habe ich dann das backup gelegt und den Container hochgefahren.

Er erkennt zwar das Backup und versucht es auch einzuspielen, bricht aber ohne nennenswerte Meldungen ab, lediglich das restore.log enthält einen Fehler - den finde ich zwar im Forum, aber keiner der Hinweise scheint irgendwie zu passen.

Docker Log:

------------------------------------------------------------,
---------------     2020-10-26 15:06:17      ---------------,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----       Welcome to your ioBroker-container!        -----,
-----          Startupscript is now running.           -----,
-----                Please be patient!                -----,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----              Debugging information               -----,
-----                                                  -----,
-----                      System                      -----,
-----               arch:      x86_64                  -----,
-----                                                  -----,
-----                     Versions                     -----,
-----               image:     v5.0.0                  -----,
-----               node:      v12.19.0                -----,
-----               npm:       6.14.8                  -----,
-----                                                  -----,
-----                       ENV                        -----,
-----               PACKAGES:  vi                      -----,
-----               SETGID:    1000                    -----,
-----               SETUID:    1000                    -----,
------------------------------------------------------------,
 ,
------------------------------------------------------------,
-----         Step 1 of 5: Preparing container         -----,
------------------------------------------------------------,
 ,
Installing additional packages is set by ENV.,
The following packages will be installed: vi...,
E: Paket vi kann nicht gefunden werden.,
Done.,
 ,
------------------------------------------------------------,
-----   Step 2 of 5: Detecting ioBroker installation   -----,
------------------------------------------------------------,
 ,
ioBroker backup file detected in /opt/iobroker. Restoring ioBroker...,
Done.,
 ,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!,
!!!!!                             IMPORTANT NOTE                             !!!!!,
!!!!!        The sartup script restored iobroker from a backup file.         !!!!!,
!!!!! Check /opt/iobroker/log/restore.log to see if restore was successful.  !!!!!,
!!!!! When ioBroker now starts it will reinstall all Adapters automatically. !!!!!,
!!!!!         This might be take a looooong time! Please be patient!         !!!!!,
!!!!!  You can view installation process by taking a look at ioBroker log.   !!!!!,
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!,
 ,
------------------------------------------------------------,
-----   Step 3 of 5: Checking ioBroker installation    -----,
------------------------------------------------------------,
 ,
(Re)Setting folder permissions (This might take a while! Please be patient!)...,
Done.,
 ,
Fixing "sudo-bug" by replacing sudo in iobroker with gosu...,
Done.,
 ,
Looks like this is a new and empty installation of ioBroker.,
Hostname needs to be updated to  iobroker.fritz.box...,
The host for instance "system.adapter.admin.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
The host for instance "system.adapter.discovery.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
The host for instance "system.adapter.info.0" was changed from "dd5e0cc90d86" to "iobroker.fritz.box".,
Done.,
 ,
------------------------------------------------------------,
-----      Step 4 of 5: Applying special settings      -----,
------------------------------------------------------------,
 ,
Some adapters have special requirements/ settings which can be activated by the use of environment variables.,
For more information take a look at readme.md on Github!,
 ,
------------------------------------------------------------,
-----          Step 5 of 5: ioBroker startup           -----,
------------------------------------------------------------,
 ,
Starting ioBroker...,
 ,
host.iobroker.fritz.box check instance "system.adapter.admin.0" for host "iobroker.fritz.box",
host.iobroker.fritz.box check instance "system.adapter.discovery.0" for host "iobroker.fritz.box",
host.iobroker.fritz.box check instance "system.adapter.info.0" for host "iobroker.fritz.box",
Send diag info: {"uuid":"7abd3182-d399-f7bd-da19-9550d8babede","language":"","country":"","hosts":[{"version":"3.1.6","platform":"Javascript/Node.js","type":"linux"}],"node":"v12.19.0","arch":"x64","adapters":{"admin":{"version":"4.0.10","platform":"Javascript/Node.js"},"discovery":{"version":"2.3.7","platform":"Javascript/Node.js"},"info":{"version":"1.7.2","platform":"Javascript/Node.js"}},"statesType":"file","objectsType":"file","model":"Intel(R) Celeron(R) CPU J3355 @ 2.00GHz","cpus":2,"mem":10282930176,"ostype":"Linux","city":""},
hash changed or no sources cached => force download of new sources,

Restore.log:

host.iobroker.fritz.box Using backup file iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz
host.iobroker.fritz.box Cannot find extracted file from file "/opt/iobroker/node_modules/iobroker.js-controller/tmp/backup/backup.json"
 Cannot save /opt/iobroker/iobroker-data/states.json: Error: EACCES: permission denied, open '/opt/iobroker/iobroker-data/states.json.bak'

Ich habe auch schon versucht ioBroker nackt als 5.0.0 hochzufahren, BackItUp zu installieren und darüber dann zu recovern - das bringt leider auch kein zählbares Ergebnis.

Habe ich irgendwo ein Brett vor dem Kopf? Ist das ein bekanntes Problem? Ich finde es gerade etwas erschreckend, dass scheinbar meine Backups bei einem Fresh Install gar nicht funktionieren...

[Glasfaser]

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

Ich habe auch schon versucht ioBroker nackt als 5.0.0 hochzufahren,

dann den Ordner erstellen

mkdir /opt/iobroker/backups

dort dein Backup rein , dann

pkill -u iobroker
iobroker restore iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz
iobroker start

eventuell wenn es danach nicht geht

pkill -u iobroker
iobroker host this
iobroker start

[Satsh]

@Glasfaser

Das bin ich zwischendurch auch schon selber angegangen und es scheint auch mit leichteren Hopsalas funktioniert zu haben.
Hat erst mal ein bisschen gedauert, bis ich gemerkt habe, dass unter 5.0.0 "pkill io" gleich den ganzen Container killed, dachte immer irgendwas wäre jetzt ganz kaputt... Zum "Glück" liefen ja nur drei Instanzen, die ich dann von Hand gekillt habe.

Der Restore hat mit einigem Meckern im Log funktioniert, aber das waren aus meiner Sicht vernachlässigbare Fehler. Beim Versuch die Instanzen zu starten, hat er erwartungsgemäß gemeckert, dass die Instanz nicht da wäre und er den Adapter jetzt installiert. Dabei haben einige Adapter gemeckert, dass das Nachinstallieren einiger Libs fehlgeschlagen wäre.
Die Instanzen wurden dann aber danach doch nicht gestartet. Bis auf admin.0 waren alle Instanzen stopped. Ich habe diese dann von Hand nacheinander gestartet und immer ein bisschen gewartet. Dann habe ich den ioBroker mal 30 Minuten in Ruhe gelassen und dann denn Container restartet um zu schauen, ob auch alles wieder sauber hoch kommt.

Bis dato sieht alles gut aus. Auch meine größte Angst, dass ioBroker mal wieder meine History Datenpunkte gekilled hat, hat sich nicht bestätigt. Nach dem Start des InfluxDB Adapters waren alle Datenpunkte wieder so im Logging, wie es sein sollte.

Würde sagen: Operation geglückt.

Aber wieso funktioniert der Restore beim FirstStart nicht? Gibt es da irgendwelche Hinweise? Bin auch durchaus bereit hier noch zu unterstützen und Sachen zu debuggen.

[andre]

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

dort dein Backup rein , dann
pkill -u iobroker iobroker restore iobroker_2020_10_26-13_13_56_backupiobroker.tar.gz iobroker start
eventuell wenn es danach nicht geht
pkill -u iobroker iobroker host this iobroker start

Bitte, bitte kein "iobroker start" im Container! Den Container immer komplett neu starten, damit das Startscript durch läuft und den ioBroker selbst startet!
https://smarthome.buanet.de/2019/05/iobroker-docker-image-steuerung-per-kommandozeile/

MfG,
André

[andre]

@Satsh Soweit alles richtig gemacht.

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

Aber wieso funktioniert der Restore beim FirstStart nicht? Gibt es da irgendwelche Hinweise? Bin auch durchaus bereit hier noch zu unterstützen und Sachen zu debuggen.

Der Restore funktioniert aufgrund eines Zugriffsproblems nicht. Kurzum, irgendwas mit den Berechtigungen stimmt da nicht.

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

Cannot save /opt/iobroker/iobroker-data/states.json: Error: EACCES: permission denied, open '/opt/iobroker/iobroker-data/states.json.bak'

Das ist der Übeltäter. Habe in letzter Zeit vermehrt Anfragen dazu. Habe noch nicht rausgefunden was da los ist und ob sich da irgendwo etwas verändert hat, auf das ich im image vielleicht reagieren muss...
folgendes würde mich in deinem Fall interessieren:

1. Nutzt du eine DiskStation als Docker Host?
2. Wie und wo legst du das Verzeichnis an, dass du für /opt/iobroker verwendest?
3. Mit welchem User auf der DS arbeitest du (also aus Sicht der Berechtigungen)?
4. Wie kopierst du das Backupfile?
5. Irgendwelse Besonderheiten/ Hindernisse vor dem ersten Start des Containers?

MfG,
André

[Satsh]

@andre

1. Ja, ioBroker läuft direkt auf meiner DS
2. Ich habe innerhalb der DS einen gemeinsamen Ordner /Docker, unter dem ich die einzelnen Mountpoints anlege, damit sie ins Backup laufen. Für ioBroker mache ich einen lokalen Bind auf /volume1/Docker/iobroker (Beispiel), ich nutze für ioBroker kein Volume im Docker.
3. Ohne User, da lokaler Bind.
4. Ich habe zwei Wege probiert, da ich von dem "Kopierfehler über Windows" gelesen habe: 1. Copy&Paste innerhalb der DS (CMD+C,CMD+V) 2. Download von der DS, Upload auf die DS
5. Ich clone den alten ioBroker Container und führe danach folgende Änderungen durch:

• Bind auf neues, leeres Verzeichnes (damit ich im Notfall das alte Verzeichnis noch mit dem alten Container als Fallback wieder hochfahren kann)
• Pull des neues Image (hier 5.0.0)
• Kopieren des letzten Backups in das root des neuen Verzeichnisses

Irritierend ist ja, dass das Verzeichnis komplett leer ist und damit ja keine Verzeichnisse mit falschen Berechtigungen existieren. Alles was erzeugt wird, wird von ioBroker erzeugt. Und entpacken kann er das Backup ja scheinbar und legt damit auch Verzeichnisse an. Und danach hat er ein Problem ein selbst angelegtes File zu lesen? Das klingt schon sehr seltsam...

Ich weiß nur leider nicht wo ich zum Debuggen dazwischenfunken kann. Wo ist denn das Script, was das Backup dabei behandelt? Dann schaue ich mal drüber...

[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?