[HowTo] ioBroker unter Docker auf Synology DiskStation

[mumurik]

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

Aber du solltest nicht Telegram installieren , habe ich oben nicht erwähnt !
Oder was hast du gemacht !?

also, folgendes habe ich gemacht:

cd /opt/iobroker
pkill -u iobroker
npm cache clean --force
iobroker del telegram
iobroker start

sudo apt update
sudo apt upgrade

Dann den Telegram-Adapter aus GitHub erneut installiert...

[Glasfaser]

@mumurik

Da ist was ganz schräg bei dir gelaufen mit den

node_modules

/opt/iobroker/node_modules/iobroker.telegram/node_modules/socksv5/lib/auth/@eaDir

das Unter / Unter Verzeichiss und diese Datei gibt es nicht

@eaDir

Richtig wäre , es liegt aber alles im Ordner :

/opt/iobroker/node_modules/socksv5/

[Glasfaser]

@mumurik

Es kann auch sein ... das auch andere Adapter betroffen sind , die du mal installieren willst !
Aber bei dieser Querinstallation habe ich auch kein Rat ... eher auf ein Neu Aufsetzen .

[mumurik]

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

@mumurik

Es kann auch sein ... das auch andere Adapter betroffen sind , die du mal installieren willst !
Aber bei dieser Querinstallation habe ich auch kein Rat ... eher auf ein Neu Aufsetzen .

also ich habe den Container jetzt neuaufgesetzt und bekomme bei der Installation des Telegram-Adapters nun folgende Fehlermeldung:

$ ./iobroker add telegram  --host iobroker-docker
NPM version: 6.14.8
npm install iobroker.telegram@1.5.9 --loglevel error --prefix "/opt/iobroker" (System call)
npm 
ERR! code EINVALIDPACKAGENAME
npm ERR!
 Invalid package name "@eaDir/.bin@SynoResource": name can only contain URL-friendly characters

npm ERR! A complete log of this run can be found in:npm 
ERR!     /opt/iobroker/.npm/_logs/2020-10-20T18_09_26_768Z-debug.log
ERROR: host.iobroker-docker Cannot install iobroker.telegram@1.5.9: 1
ERROR: process exited with code 25

und wieder der Verweis auf "@eaDir/.bin@SynoResource"

Muss ich eventuell eine ENVIRONMENT Variable bei der Erstellung des Containers mitgeben?

[Glasfaser]

@mumurik

Gebe mal paar Daten bekannt

• Welche Synology
• Welche DSM Version
• Über Portainer erstellt
• über die Synology Docker Oberfläche erstellt
• Fertiges Docker compose

@andre
hast du vielleicht eine Idee was das sein kann .... !

der Verweis auf "@eaDir/.bin@SynoResource"

[Glasfaser]

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

also ich habe den Container jetzt neuaufgesetzt

mit Backup eingespielt ??
altes Mount Verzeichniss genutzt ??

[mumurik]

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

Welche Synology

DS220+

Welche DSM Version

DSM 6.2.3-25426 Update 2

Über Portainer erstellt

Ja

über die Synology Docker Oberfläche erstellt

nein

Fertiges Docker compose

ja, buanet/iobroker:latest

[dslraser]

@Glasfaser
wegen @eaDir
google spuckt dazu einiges aus.
Beschreibung z.B. hier

https://blog.andreas-schreiner.de/2019/03/18/synology-eadir-verzeichnisse-finden-und-loeschen/

EDIT: ob einfach löschen richtig ist, kann ich aber nicht sagen

[Glasfaser]

@dslraser

Ja ... Danke , habe ich gestern schon danach gesucht .

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

.... auch bei der jetzigen Neuinstallation von Ihm .

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

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.