NEWS

@oliverio sagte in ioBroker Container v10 auf QNAP mit ARMv7 Architektur:

@marc-berg

könnte er sich das image nicht lokal selbst erstellen?
es müsste ja alles im repo vorhanden sein.
https://github.com/buanet/ioBroker.docker/blob/main/debian12/Dockerfile
https://github.com/buanet/ioBroker.docker/blob/main/.github/workflows/build-debian12-latest_sep.yml

Könnte man machen. Entweder das v9 Image nehmen und Node.js 22 im dockerfile installieren oder die v11 als Basis und dieses statt von bookworm von bullseye ableiten. Alles nicht schön, weil man mit einem alten Betriebssystem arbeitet und die Imageerstellung auch nicht selbsterklärend ist.

Ich glaube, der pragmatischste Weg wäre, im vorhandenen v9 Container das Node.js einfach auf die Version 22 zu ziehen. Am besten per Start-/Userscript, dann überleben die Änderungen auch eine Container Neuerstellung.

Angenehmer Nebeneffekt nach dem Rauswurf von Portainer 😁

e2244bd3-33b2-4737-921c-b997c2b7cbdb-image.png

@fredf
Endlich habe ich den 'Fehler' gefunden. Privileged: muss auf on gesetzt werden.

@rulee

du kannst aber auch rsync auf deinem host installieren und die notwendigen verzeichnisse dir im container nach aussen mappen

@kopterframe sagte in USBDEVICES synology Docker:

No such file or directory

durchaus möglich bei diesen kastrierten Systemen.

@kopterframe sagte in USBDEVICES synology Docker:

Habe den USB Stecker mal abgezogen und wieder eingesteckt.
nun geht es wieder.

auch da

@homoran sagte in USBDEVICES synology Docker:

werden die USB ports neu initialisiert und ggf. anderen IDs zugeordnet

@mkaiser96 sagte in Dockerinstallation auf Synology Firewalleinstellungen:

@thomas-braun

Die letzte Einstellung soll ich also deaktivieren? Ich habe gedacht, wenn ich vorher die Ausnahmen zulasse, dass das Ganze funktionieren sollte.

Ich lasse doch alles eingehende zu den Ports 8081 und 1880 durch oder habe ich da ein Denkfehler?

Habe ich dadurch irgendwelche Sicherheitsrisiken, wenn ich den letzten Punkt deaktiviere?

Uh ja Denkfehler … Deine Firewall blockiert den Verkehr in beiden Seiten, ioBroker brauch schon Internet und DNS um Adapter installieren zu können.
Ergo Port 80/443 und 53 (DNS) müssen von innen nach außen freigeschaltet werden

Sind diese blockiert (was deine „alle“ rule macht) kommt halt nichts durch 😉

@m-b

Keine Ahnung wie das bei Qnap ist , bei meiner Synology habe ich Umgebungsvariablen bei der Containererstellung, wo ich den Pfad der USB Devices angebe.

@david-g und bei @Meister-Mopper , hab ich beim ersten mal überlesen 😞
Dafür besser vorgestellt 🙂

Ich habe jetzt eine Lösung und vermutlich das Problem gefunden.

services: wireguard: image: lscr.io/linuxserver/wireguard:latest container_name: wireguard networks: RZ-net: ipv4_address: 172.18.0.2 cap_add: - NET_ADMIN - SYS_MODULE #optional environment: - PUID=1000 - PGID=1000 - TZ=Europe/Berlin volumes: - /root/docker/wg-s2s/config:/config sysctls: - net.ipv4.conf.all.src_valid_mark=1 restart: unless-stopped networks: RZ-net: external: true

Hauptproblem bei der Vergabe der festen IP Adresse ist das angelegte Netzwerk.
Es darf nicht mit /16 angelegt werden. Hier ist vermutlich etwas im Docker-Hintergrund was hier blockiert.
Legt man die Adresse mit /24 an, kann man in der Compose Datei die Adresse auch fest vergeben.

e3536d27-9c97-4719-acb6-81d100ef2dbb-grafik.png

d96374d8-1882-4bac-af70-e9858c8a66b6-grafik.png

@meto304 sagte in Fehlermeldung cmp: EOF on /opt/iobroker which is empty:

/opt/iobroker/iobroker

der pfad passt nicht der muss auf /opt/iobroker/

Du kannst auch watchtower (https://github.com/containrrr/watchtower) mit installieren, der kümmert sich um automatische Updates

@toralt hi, hab mich mal etwas weiter damit beschaeftigt. Wenn ich das konzeptmaessig so zusammenfassen wuerde, waere es korrekt? Das Thema Docker und Port publishing muss dann auch noch angehen.
Der zigbee2mqtt-Container empfängt die Daten von den Zigbee-Geräten über das SLZB-06 und sendet diese als MQTT-Nachrichten an den Mosquitto-Container. Dazu verbindet sich zigbee2mqtt als MQTT-Client mit Mosquitto und veröffentlicht die Daten unter bestimmten MQTT-Themen (Topics). Der Mosquitto-Container (der MQTT-Broker) nimmt diese Nachrichten entgegen und verwaltet sie.
Der ioBroker zigbee2mqtt-Adapter fungiert ebenfalls als MQTT-Client und stellt eine Verbindung zum Mosquitto-Container her. Der Adapter "abonniert" die relevanten MQTT-Themen, unter denen zigbee2mqtt die Zigbee-Daten veröffentlicht. Sobald Mosquitto eine neue Nachricht zu einem dieser abonnierten Themen empfängt, leitet er diese an den ioBroker.zigbee2mqtt-Adapter weiter. Der Adapter verarbeitet diese Nachrichten und stellt die darin enthaltenen Informationen über die Zigbee-Geräte als nutzbare Datenpunkte in ioBroker zur Verfügung.
Die Kommunikation läuft also über den zentralen Punkt Mosquitto: zigbee2mqtt sendet Daten an Mosquitto, und ioBroker holt sich diese Daten von Mosquitto ab.

@marc-berg
Moin, noch ein kleines Update meinerseits:

Adguard und ioBroker sind nun schließlich doch in einem einzigen MACVLAN gelandet. Mit unterschiedlichen Stacks, die das gleiche MACVLAN 1:1 konfiguriert haben, natürlich mit unterschiedlichen ipv4-Adressen der Container 😉

Grund: Mehrere MACVLANs an einem Host-Adapter funktionieren nicht. Und ich wollte nicht tiefer im System herumschrauben.

Ich denke, ein herumgeisterndes Netzwerk wie in der jetzigen Lösung ist nicht so wild. Vielen Dank für die hilfreichen Tipps!

@audiojoy insbesondere der Inhalt deiner Composer-Datei wäre interessant.
Vermutlich werden die Daten nicht aus dem Container ausgeleitet - oder mit dem Zielpfad stimmt etwas nicht.

Die Daten dürfen nicht innerhalb des Containers gespeichert sein, denn der wird bei Updates einfach neu erstellt und wieder mit den außerhalb gespeicherten Daten verknüpft.

Das gilt für alle Container! Ist meine Lieblingsfrage an Leute die schwärmen wie einfach es war, Nextcloud als Container auf dem QNAP/Synology aufzusetzen. Ich frage dann wie das Update lief - Hui, da war alles weg (kommt nicht mehr so oft wie früher die Antwort)