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

[jgee2]

@Glasfaser

danke für den Tipp. Leider habe ich den gleicher Fehler immer noch. Vielleicht mache ich aber was grundsätzlich falsch. Ich bin so vorgegangen:

• per SSH als root auf die Synology
• per "docker exec -it <container name> /bin/bash" in den Container
• dort wie von dir beschrieben die Kommandos abgesetzt.
• danach iobroker per "gosu iobroker node node_modules/iobroker.js-controller/controller.js" neugestartet.

Das Ergebnis ist:

host.xyz check instance "system.adapter.admin.0" for host "xyz"
host.xyz check instance "system.adapter.discovery.0" for host "xyz"
host.xyz check instance "system.adapter.info.0" for host "xyz"
host.xyz check instance "system.adapter.smartmeter.0" for host "xyz"
host.xyz check instance "system.adapter.knx.0" for host "xyz"
host.xyz check instance "system.adapter.influxdb.0" for host "xyz"
host.xyz check instance "system.adapter.robonect.0" for host "xyz"
host.xyz check instance "system.adapter.sma-speedwire.0" for host "xyz"
host.xyz check instance "system.adapter.javascript.0" for host "xyz"
host.xyz check instance "system.adapter.feiertage.0" for host "xyz"
host.xyz check instance "system.adapter.web.0" for host "xyz"
host.xyz check instance "system.adapter.sonos.0" for host "xyz"
host.xyz check instance "system.adapter.unifi.0" for host "xyz"
host.xyz check instance "system.adapter.vis.0" for host "xyz"
host.xyz check instance "system.adapter.vaillant.0" for host "xyz"
host.xyz check instance "system.adapter.alexa2.0" for host "xyz"
host.xyz check instance "system.adapter.iot.0" for host "xyz"
================================== > LOG REDIRECT system.adapter.javascript.0 => false [Process stopped]
================================== > LOG REDIRECT system.adapter.javascript.0 => false [system.adapter.javascript.0.logging]

Mach ich was grundsätzlich falsch?

@Knallochse, das script habe ich leider nicht finden können.

[FoodFighter]

@stevie77 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Macht auch Sinn, da dies in Portainer ein Pflichtfeld für MACVLAN ist. Kannst du mir erklären, warum das bei dir ja offensichtlich ohne funktioniert?

Ja macht Sinn und ist auch richtig so - das ist mir durch die Lappen gegangen.
Danke für den Hinweis - Ich hab es oben korrigiert

[andre]

@jgee2
Hallo Jo,
ich glaube du bringst da irgendwas durcheinander...

@jgee2 sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Heute habe ich versucht, NPM von Version 10 auf 12 zu aktualisieren, so wie in dem Blog beschrieben. Leider hat der Neustart nicht mehr geklappt.

Was hast du jetzt genau vor? Du schreibst "NPM" aktualisieren, Nimmst die "Version 10 auf 12" (Versionen von Node) und postest die Fehlermeldungen vom Update des js-controllers... Das sind 3 völlig unterschiedliche Dinge...

In meiner Knowledgebase ist das Update vom js-controller beschrieben. Da wäre das Update dann aktuell von Version 2 auf 3. Das wäre dann das Update was du unter Umständen auch im Admin des ioBrokers angezeigt bekommst...

Ich ignoriere jetzt einfach mal "NPM" und "Version 10 auf 12" und beziehe mich auf deine Fehlermeldung beim Ausführen des "npm install..."

Deine Fehlermeldung "sudo: Die Audit-Nachricht kann nicht gesendet werden: Die Operation ist nicht erlaubt" ist nicht neu. Hast du die mal durch die Suche in diesem Thread gejagt?
Das ist ein Thema was hier alle paar Monate wieder aufschlägt.
Es handelt sich um einen bekannten Bug der in Erscheinung tritt wenn man den Container auf einer Synology DS ausführt und das "Host-Netzwerk" verwendet. Synology verwendet in der aktuellen DSM Version einen veralteten Linux Kernel. In diesem Kernel gibt es einen Bug. Der verhindert das Ausführen von sudo innerhalb eines Containers der im Host Mode läuft.... Leider wird beim "npm install..." innerhalb der routine "sudo" aufgerufen. Resultat: Die Installation schlägt fehl.

Eine Workaround für das Update des js-controllers im ioBroker-Container wäre folgendes (vorausgesetzt du hast dein ioBroker-Verzeichnis außerhalb des Containers liegen und in den Container gemountet):

1. Backup machen! (z.B. per duplizieren des ioBroker-Verzeichnisses oder über "iobroker backup" und sichern des Backup-Files)
2. Container löschen
3. Container mit Bridge Netzwerk anstatt Host erstellen (restliche Config natürlich gleich)
4. Update des js-controllers über Kommandozeile durchführen ("pkill io", "npm install..")
5. Container löschen
6. Neuen Container mit Host Netzwerk erstellen

Ich hoffe das hilft dir weiter.

MfG,
André

[qosi]

Hallo noch mal,

habe das Gefühl meine Frage/Problem geht irgendwie unter, ich versuche es noch einmal, jedoch diesmal nicht als Reply auf ein Posting.
Hoffe mit diesem letzten Versuch auf mein Problem aufmerksam zu machen, ggf. poste ich hier auch falsch...k.a...:confused:

Ich wäre super Dankbar wenn jemand hier auf eine Quelle verweisen könnte wo ich nachlesen kann, oder ggf. anhand meiner Infos die Lösung kennt.

Hier der Post um den es geht:
https://forum.iobroker.net/post/419686

Vielen Dank!:spock-hand:

[andre]

@qosi
Hallo,
hast du denn beim Erstellen deines Containers die Capabilities gesetzt?
Hier ein paar Infos: Docker Doku.
Und hier findet man das im Portainer:

Vermutlich fehlt dir der "NET_ADMIN".
Ob noch Weiteres zu tun ist kann ich nicht genau sagen. Ich verwende den Adapter nur auf einem Raspberry-Multihost-Slave...

MfG,
André

[qosi]

@andre
Vielen Dank, habe die --privileged hinzugefügt, erst im Portainer eingeschaltet:

Brachte nix...dann noch in CMD hinzugefügt...

Brachte auch nichts...
Dann noch mehr von den capabilities eingeschaltet, NET_Admin war schon an...

Das sind meine Pakete

build-essential libcairo2-dev libcap2-bin libpango1.0-dev libjpeg-dev librsvg2-dev arp-scan bluetooth bluez libbluetooth-dev libudev-dev net-tools net-ping nano

Leider will er einfach nicht...

radar2.0	2020-04-27 23:51:48.223	info	(643) radar2 set to scan every 20 seconds and printers every 720 minutes.
radar2.0	2020-04-27 23:51:48.222	info	(643) arp-scan will use the following interfaces: [ 'eth0' ]
radar2.0	2020-04-27 23:51:48.221	info	(643) Remove name end for host names: .fritz.box
radar2.0	2020-04-27 23:51:48.221	info	(643) use known IP list: [ '1.1.1.1' ]
radar2.0	2020-04-27 23:51:48.220	info	(643) use known BT list: [ '01:12:23:34:45:56' ]
radar2.0	2020-04-27 23:51:48.219	info	(643) radar2 set to flag items away if they are not seen for 2 minutes
radar2.0	2020-04-27 23:51:48.218	warn	(643) node-bluetooth not found!
radar2.0	2020-04-27 23:51:47.975	warn	(643) Noble not available, Error: { Error: EAFNOSUPPORT, Address family not supported by protocolat new Hci (/opt/iobroker/node_modules/@abandonware/noble/lib/hci-socket/hci.js:74:18)at new NobleBindi
radar2.0	2020-04-27 23:51:47.024	info	(643) Adapter disconnected and stopped with dostop(false) and callback(true)
radar2.0	2020-04-27 23:51:47.023	error	(643) Error: bind EACCES 0.0.0.0:67 at state.handle.lookup (dgram.js:242:18) at process._tickCallback (internal/process/next_tick.js:63:19)
radar2.0	2020-04-27 23:51:47.022	error	(643) uncaught exception: bind EACCES 0.0.0.0:67
radar2.0	2020-04-27 23:51:46.850	info	(643) net-ping not available! Will try to use normal ping!
radar2.0	2020-04-27 23:51:46.815	info	(643) radar2 initialization started...
radar2.0	2020-04-27 23:51:46.796	warn	(643) adapter.objects.getObjectList is deprecated, and will be removed in the future. Please use adapter.getObjectList/Async. Report this to Developer!
radar2.0	2020-04-27 23:51:46.731	info	(643) starting. Version 1.0.9 in /opt/iobroker/node_modules/iobroker.radar2, node: v10.20.1, js-controller: 3.0.19

Hab den js-controller auf 3.0.19 gebracht, vielleicht bin ich mit den aktuellen node usw. Versionen zu aktuell...?
Ich habe den Container erst mal da, der Mount ist auch da, werde weiter stöbern dazu und auf neues Update hoffen.

Im Moment wieder zurück auf dem RPI und hoffen, dass die SD Karte wieder mal eine Zeitlang hält.
Danke für die Doku, werde die mir noch mal in Detail reinziehen.

Hier vielleicht noch der Log vom Container start...log.txt

[andre]

@qosi sagte in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

Error: bind EACCES 0.0.0.0:67 at state.handle.lookup (dgram.js:242:18) at process._tickCallback (internal/process/next_tick.js:63:19)

Hallo,
für mich sieht das soweit eigentlich gut aus. In der einzigen Fehlermeldung die ich finden konnte meckert er an, dass er den Port 67 nicht öffnen kann. Hast du die Fehlermeldung mal durch die Forensuche gejagt?

Ich empfehle dir da mal diesen Thread:
https://forum.iobroker.net/topic/19794/adapter-neuer-radar2-adapter

MfG,
André

[duffbeer2000]

@qosi Sobald du den Privileged mode aktiviert hast interessieren die capabilities nicht mehr da sie dann alle aktiviert sind. Sicherheitstechnisch solltest du den Privileged mode deaktivieren und nur die benötigten capabilities aktivieren. Ich kann das nicht oft genug sagen.

Wenn ein externer angreifer in einen Container eindringt der im Privileged mode läuft, kann er auf eurem Host (Diskstation) sehr großen Schaden anrichten, wie z.B. alle Platten löschen.

Und nun zum eigentlichen Problem:

• schalte den Container aus
• Da du vorher ohne priviledged ausgekommen bist schalt es wieder aus
• dreh die capabilities wieder auf den Ursprungszustand zurück
• aktiviere folgende capabilities zusätzlich zu den Standardmäßigen.: "NET_ADMIN" "NET_RAW" und "NET_BIND_SERVICE"
• Starte den Container wieder
• Führe in der Console folgende Befehle aus:

gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp-scan`)
gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)
gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp`)
gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hcitool`)
gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hciconfig`)
gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which l2ping`)

• Starte den Container neu

[jgee2]

@andre,

Hi André,

ja, da habe ich viel durcheinander gebracht, bitte entschuldige. Versucht hatte ich tatsächlich ein Update des js-controllers, das dann fehlgeschlagen ist. Nochmals danke für deine Hilfe.

Leider bekomme ich auch mit deiner Anleitung hier den Container nicht zum Laufen. Weder im Bridge- noch im Host-Modus. Ich habe daraufhin einen neuen ("nackten") Container installiert und darin mein Backup mit "iobroker restore 0" hergestellt. Sobald das Backup wiederhergestellt wurde, funktioniert auch der Container nicht mehr. Ich scheine mir da richtig was kaputt gemacht zu haben.

Ich habe bereits begonnen, alles neu aufsetzen, das ist soweit lediglich Arbeit... Nur einige meiner Javascripts würde ich gerne wiederherstellen, da da viel Arbeit reingeflossen ist. Weißt du (oder sonst jemand), wie ich aus dem ioBroker Backup einzelne Teile, nämlich die eigenen Javascript-Dateien, wiederherstellen kann? Soweit ich das sehen kann, liegen die alle in einer ziemlich großen JSON-Datei, in meinem Fall 8 MB. Da hat mein Atom Editor große Schwierigkeiten mit...

Beste Grüße

Jo

[duffbeer2000]

@jgee2 Probier mal folgendes bevor du einzelne Sachen wiederherstellst:

• erstelle dir ein neues iobroker_data-Verzeichnis (kannst auch anders nennen)
• lege in das neue iobroker_data-Verzeichnis das Backup-File
• erstelle dir nochmal einen nackten Container mit dem neuen iobroker_data-Verzeichnis
• starte den Container

Jetzt sollte automatisch ein Restore laufen, das dauert einige Zeit bis es komplett abgeschlossen ist. Je nach Anzahl an Adaptern bis zu 2 Stunden oder mehr.

Und heb dir das alte iobroker_data-Verzeichnis auf, dann kann man wenns nicht funktioniert auch damit weiter machen.

[RK62]

@jgee2 Beim neuen System / nach der Reparatur empfiehlt es sich diese Einstellung in der javascript-Instanz zu setzen:

Das Verzeichnis solltest Du vorher manuell anlegen.

Damit werden dann permanent alle Skripte lokal auf das Filesystem synchronisiert und können dort oder im Admin geändert werden.
Mit Hyperbackup hat man dann auch Generationssicherungen der Skripte und kann problemlos auch ein einzelnes mal wieder zurückholen.

Gruß, Ralf

[jgee2]

@duffbeer2000

Hi! Das habe ich gemacht. Die Fehlermeldung beim Starten des Containers war sinngemäß, dass Dateien im Verzeichnis entdeckt wurden, die kein ioBroker Backup wären. Da habe ich dann aufgegeben. Vermutlich war das Backup bereits korrupt. Hab was draus gelernt: Meine ioBroker-Instanz wird bei mir jetzt genauso pfleglich behandelt, wie auch andere Daten. Backups mache ich jetzt regelmäßig und automatisch...

Trotzdem danke und viele Grüße

Jo

[jgee2]

@RK62

Hi Ralf,

super Tipp, danke dir! Schaue ich mir nachher direkt an. Der größte Aufwand war tatsächlich, die Scripte aus der JSON-File herauszuziehen und wieder in Betrieb zu nehmen.

Viele Grüße

Jo

[qosi]

@duffbeer2000 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f which arp-scan)

Hallo duffbeer,

schalte den Container aus --> check
Da du vorher ohne priviledged ausgekommen bist schalt es wieder aus --> check
dreh die capabilities wieder auf den Ursprungszustand zurück --> check
aktiviere folgende capabilities zusätzlich zu den Standardmäßigen.: "NET_ADMIN" "NET_RAW" und "NET_BIND_SERVICE" --> check
Starte den Container wieder --> check
Führe in der Console folgende Befehle aus: --> ja das hab ich auch so versucht, leider passt ihm hier, wie bei vielen anderen Meldungen die man im log sieht im Moment, diese File Geschichte nicht.

root@iobroker1:/opt/iobroker# gosu root setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp-scan`)
Failed to set capabilities on file `/usr/sbin/arp-scan' (Operation not supported)
The value of the capability argument is not permitted for a file. Or the file is not a regular (non-symlink) file
root@iobroker1:/opt/iobroker#

[duffbeer2000]

@jgee2 Lass mich raten, du hast kein neues iobroker_data Verzeichnis angelegt sondern nur den Inhalt gelöscht? Wenn ja ist das logisch da in dem Verzeichnis auch versteckte Dateien sind. Daher sagte ich auch "erstelle dir ein neues iobroker_data-Verzeichnis"

@qosi
apr-scan ist aber installiert? kannst du das mal prüfen?
Gingen die anderen befehle durch? Wenn nicht dann versuchen wir es mal mit dem User iobroker, vielleicht hilft das.

gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp-scan`)
gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which node`)
gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp`)
gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hcitool`)
gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which hciconfig`)
gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which l2ping`)

[jgee2]

@duffbeer2000 said in [HowTo][Anleitung] Installation ioBroker in Docker auf Synology DiskStation:

@jgee2 Lass mich raten, du hast kein neues iobroker_data Verzeichnis angelegt sondern nur den Inhalt gelöscht? Wenn ja ist das logisch da in dem Verzeichnis auch versteckte Dateien sind. Daher sagte ich auch "erstelle dir ein neues iobroker_data-Verzeichnis"

Nein, das root-Verzeichnis war ein neues mit einem anderen Namen. Das Backup war bereits defekt. Der ioBroker hat sogar gestartet und alle Adapter ausgeführt (Daten wurden an influxDB gesendet und mit dem KNX-Bus ausgetauscht), aber die Weboberfläche des Admin-Adapters wollte nicht starten. Ältere Backups waren zu alt für meinen Zweck. Mittlerweile habe ich alles wieder hergestellt und bin dadurch etwas schlauer geworden als zuvor.

[qosi]

@duffbeer2000

Sers,

also arp-scan ist wohl da...

root@iobroker1:/opt/iobroker# arp-scan -lgq --retry=7
Interface: eth0, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.9.5 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.0.2     02:42:c0:a8:00:02

Mit User iobroker sieht es etwas anders aus bei den Befehlen

root@iobroker1:/opt/iobroker# gosu iobroker setcap cap_net_admin,cap_net_raw,cap_net_bind_service=+eip $(eval readlink -f `which arp-scan`)
unable to set CAP_SETFCAP effective capability: Operation not permitted
root@iobroker1:/opt/iobroker#

Das CAP_SETFCAP ist jedoch an...

Auch bei den anderen Befehlen ist die Meldung die gleiche.
Habe mal den Privileged mode eingeschaltet, auch hier der gleiche Fehler.

Dazu sagt google, dass man andere User außer root nicht unbedingt in sudo/sudoers Gruppe legen soll.
Da ich kaum Linux Erfahrung habe, bin ich hierzu ratlos...

Danke für Eure Unterstützung!

[Bongo]

Ich wollte ein Recreate bei einem Container machen und ich glaube ich habe es versehentlich den Container für Portainer selbst gemacht. Jetzt kommt immer die Fehlermeldung:
unable to retrieve stacks

In Stacks sind keine Stacks und die Container List sieht so aus:

Kann mir einer der Portainerspezis sagen was man da tun kann?

Danke für die Unterstützung.

[Bongo]

Ich konnte den Portainer Container über Docker im DSM neu starten. Es scheint wieder zu laufen!

[tugsi]

Moin,
hab die Tage auf die neueste V4.2 hochgerüstet.
Soweit läuft auch alles, nur meine Synology-Instanz kann sich nicht mehr mit der DS verbinden.
Ich habe ein MACVLAN und der Container schaut gleichzeitig auch auf das Bridge-Netzwerk.
Dies hatte ich damals mal eingerichtet, da der Container sonst nicht mehr auf einen anderen Container bzw auf sein Host schauen kann, hatte ja auch geklappt.

Jetzt ist der Thread hier mittlerweile doch sehr groß und unübersichtlich geworden, ich finde den Part nicht mehr, wo dies alles erklärt wurde. Beim Andre auf Buanet wird auch nur auf dieses Forum verwiesen bei den Kommentaren.

Mein Bridge-Netzwerk ist:
bridge
Subnet - 172.17.0.0/16 Gateway - 172.17.0.1

ioBroker-Container (MACVLAN):
iob_public
Subnet - 192.168.33.0/24 Gateway - 192.168.33.100
und hat die interne Adresse:
172.17.0.3

Die DS hat:
192.168.33.101

Wie gesagt, es lief ja bis vor kurzem, daher wundert mich jetzt, wenn ich in den Terminal gehe und einen Ping auf die Synology machen möchte, der die nicht erreichen kann.