Weihnachtsangebot 2025! 🎄

[Sleepwalker]

Moin,

ich stehe gerade vor einem kleinen Scherbenhaufen.

Hardware:
Pi4, 8GB, SSD

Nun habe ich mich getraut das Update von Bullseye auf Bookworm zu vollziehen. Also Backups gemacht, etc. pp.

• Pi4 geplättet
• Bookworm 64bit Lite über den Imager installiert
• System aktualisiert
• Docker installiert

curl -fsSL https://get.Docker.com -o get-Docker.sh
sudo sh get-Docker.sh
sudo usermod -aG docker $USER

• Portainer installiert

mkdir /home/pi/docker_binds/portainer_data
docker run -d -p 8000:8000 -p 9000:9000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v /home/pi/docker_binds/portainer_data:/data cr.portainer.io/portainer/portainer-ce:latest --http-enabled

• Stack und Binds für ioBroker und Influxdb2 erstellt

services:
  iobroker:
    image: iobroker/iobroker:latest
    container_name: iobroker
    hostname: iobroker
    network_mode: host
    restart: always
    volumes:
      - type: bind
        source: /home/pi/docker_binds/iobroker_data/opt/iobroker
        target: /opt/iobroker
    environment:
      - IOB_BACKITUP_EXTDB=true
      - PACKAGES=influxdb2-cli
  influx:
    image: influxdb:latest
    container_name: influx
    hostname: influx
    network_mode: host
    restart: always
    volumes:
      - type: bind
        source: /home/pi/docker_binds/influx_data/var/lib/influxdb2
        target: /var/lib/influxdb2

FYI, vllt. ist das wichtig: Ursprünglich hatte ich den Stack in einem eigenen Netzwerk. Aber vor ein paar Wochen musste ich (noch während Bullyeye lief) auf "host" umstellen, da ich Multicast-Pakete empfangen muss. Das hatte soweit auch reibungslos funktioniert, wenn auch zähneknirschend ;)

• Influx startet
• ioBroker startet und wirft Fehler

--------------------------------------------------------------------------------
-----             Step 3 of 5: Checking ioBroker Installation              -----
--------------------------------------------------------------------------------

(Re)setting permissions (This might take a while! Please be patient!)... Done.

Checking database connection... Failed.
[ERROR]  Could not connect to states database at 127.0.0.1:9000 (invalid protocol). Please make sure the configured IP and port points to a host running JS-Controller >= 2.0. and that the port is not occupied by other software!
[ERROR]  Could not connect to states database at 127.0.0.1:9000 (invalid protocol). Please make sure the configured IP and port points to a host running JS-Controller >= 2.0. and that the port is not occupied by other software!
[ERROR] No connection to databases possible ...

Please check your configuration and try again.
For more information see ioBroker Docker image docs (https://docs.buanet.de/iobroker-docker-image/docs).

This Script will exit now.

Das passiert in einer Endlosschleife von Neustarts. ioBroker will irgendwie Port 9000 in Anspruch nehmen, aber der ist von Portainer genutzt. Ich habe keine Ahnung, was das mit der "states database" auf sich hat. Starte ich ohne influx, kommt der gleiche Fehler. Auch wenn ich ioBroker und influx in ein anderes bridged-network bringe, hilft das nichts. Auch nicht, wenn ich Portainer selbst in ein anderes Netz stecke. Auch wenn ich den HTTP-Port 9000 von Portainer nicht mappe (und den HTTPS-Port nutze), funktioniert es nicht. Dann kommt folgende Meldung beim Start von ioBroker:

--------------------------------------------------------------------------------
-----             Step 3 of 5: Checking ioBroker Installation              -----
--------------------------------------------------------------------------------

(Re)setting permissions (This might take a while! Please be patient!)... Done.

Checking database connection... Failed.
[ERROR] Error: no UUID found

Please check your configuration and try again.
For more information see ioBroker Docker image docs (https://docs.buanet.de/iobroker-docker-image/docs).

This Script will exit now.

Irgendetwas ist da verflucht und ich habe keine Idee mehr, wie ich einfach nur Docker, Portainer und den Stack mit ioBroker und Influxdb2 laufen lassen kann. Das einzige eingespielte Backup ist von Portainer selbst, da hatte ich die Einstellungen vorher gesichert und bei Installation wieder eingespielt. Ansonsten ist alles frisch.

Vielen Dank für's Lesen bis hierher!
Und falls jemand eine Idee hat, was ich falsch mache, würde ich mich über jegliche Rückmeldung freuen. Ich will nicht zurück zu Bullseye :confounded:

[Homoran]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

ioBroker will irgendwie Port 9000 in Anspruch nehmen,

das ist die interne Datenbank zur Verwaltung sämtlicher Datenpunkte (states)!

Das ist mit Sicherheit kein BUG von ioBroker

[Sleepwalker]

@homoran Puh, zum Glück habe ich auch nicht behauptet, dass das ein Bug ist :blush:

Es lief unter Bullseye in gleicher Konstellation problemlos, auch wenn Portainer auf 9000 registriert war. Wo ist mein Fehler?

PS: Hätte ich in ein anderes Forum gemusst? Ich fand "Error/Bug" eigentlich ganz passend. Falls dem so ist, bitte ich um Verzeihung und -schiebung.

[Homoran]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

zum Glück habe ich auch nicht behauptet, dass das ein Bug ist

aber in ebendieser Kategorie gepostet ;-)

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Es lief unter Bullseye in gleicher Konstellation problemlos, auch wenn Portainer auf 9000 registriert war.

sollte es nicht gekonnt haben!
Aber it Docker kenn ich mich nicht aus

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Wo ist mein Fehler?

Wie schon erwähnt, ist es völlig normal, das sich Portainer und ioBroker um den Port 9000 streiten, wenn iobroker im Host-Modus betrieben wird. Also Port 9000 bei Portainer nicht mappen und per https verbinden.

Starte dann mal nur Portainer und zeig mal den Output von

netstat -plte

[Sleepwalker]

@marc-berg
Das ist aktuell der Fall, Portainer nur mit 8000 und 9443

Output:

(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       User       Inode      PID/Program name
tcp        0      0 0.0.0.0:ssh             0.0.0.0:*               LISTEN      root       5611       -
tcp        0      0 0.0.0.0:9443            0.0.0.0:*               LISTEN      root       174298     -
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      root       174296     -
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      root       5613       -
tcp6       0      0 [::]:9443               [::]:*                  LISTEN      root       174299     -
tcp6       0      0 [::]:8000               [::]:*                  LISTEN      root       174297     -
tcp6       0      0 [::]:8086               [::]:*                  LISTEN      pi         175638     49641/influxd

Starte ich jetzt ioBroker, kommt das, was ich oben bereits erwähnt habe:

--------------------------------------------------------------------------------
-----             Step 3 of 5: Checking ioBroker Installation              -----
--------------------------------------------------------------------------------

(Re)setting permissions (This might take a while! Please be patient!)... Done.

Checking database connection... Failed.
[ERROR] Error: no UUID found

Please check your configuration and try again.
For more information see ioBroker Docker image docs (https://docs.buanet.de/iobroker-docker-image/docs).

This Script will exit now.

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Starte ich jetzt ioBroker, kommt das, was ich oben bereits erwähnt habe:

Startet ioBroker, wenn du vorher das Verzeichnis /home/pi/docker_binds/iobroker_data/opt/iobroker löschst? Du hast doch ein Backitup-Backup, oder?

Welche Version des js-controllers hast du vorher gefahren?

[Sleepwalker]

@marc-berg Uff, ok, ioBroker startet.

Danke! Dass ich das nicht selbst ausprobiert hab :man-facepalming:

Nun, jetzt kommt das "aber"...

So richtig warm bin ich mit der Lösung nicht, auch wenn es so funktioniert. Jetzt meckern die Browser rum, HTTPS, mimimi. Gibt es eine "simple und narrensichere" Möglichkeit, Multicast-Pakete in einem bridged-Netzwerk zu empfangen? Könnte ich den Stack dann wieder nebst Portainer inkl. Port 9000 laufne lassen?

Oder gibt es gar einen besseren Ansatz?

PS: Ja, ich habe ein Backitup-Backup von Influx, ioBroker und NodeRed.
PPS: Die vorherige js-controller-Version weiß ich leider nicht, sorry. Brauche ich das Wissen?

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Möglichkeit, Multicast-Pakete in einem bridged-Netzwerk zu empfangen?

Nein. Entweder Host oder alternativ MACVLAN. Anders geht es nicht.

Alternativ kannst du den Portainer HTTP Port ja auf 9999 oder so mappen. Dann hast du den SSL Trouble nicht.

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

PPS: Die vorherige js-controller-Version weiß ich leider nicht, sorry. Brauche ich das Wissen?

Das wäre nur relevant beim Zurückspielen des Backups. Wenn die Versionen nicht passen, wird das nichts.

[Sleepwalker]

@marc-berg Hm, schade, das MACVLAN ist für meinen Geschmack leider nicht so das Gelbe vom Ei.

Dann werde ich jetzt erst einmal versuchen, die Backups wieder einzuspielen. Entweder die Binds komplett oder nur Backitup, das entscheidet gleich mein Bauch. Leider hat sich die docker GID bei Bookworm von 994 auf 992 geändert und ich habe mittels tar ohne --numeric-owner gesichert :man-facepalming: 994 ist nun leider i2c, den ich eigentlich nicht brauche....

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

MACVLAN ist für meinen Geschmack leider nicht so das Gelbe vom Ei.

Warum? Leidest du an IP-Address-Knappheit in deinem Netzwerk?

[Sleepwalker]

@marc-berg Weil sich die Container dann gegenseitig nicht mehr sehen. Oder?

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Weil sich die Container dann gegenseitig nicht mehr sehen. Oder?

Erstmal ja, korrekt. Darum könntest du einen der Container, die miteinander reden sollen, AUCH in das zweite Netzwerk stecken. Fertig.

In dem Beispiel also den ioBroker in das MACVLAN und in das Bridge-Netzwerk, in welchem auch die InfluxDB steckt.

[Sleepwalker]

@marc-berg Oh warte, da eröffnen sich neue Welten. Container in mehreren Netzwerken. Jetzt ergibt das alles einen Sinn. Gibt es bei solchen Konstellationen etwas bestimmtes zu beachten oder regelt docker den Zugriff, wann es wohin geht?

[Marc Berg]

@sleepwalker sagte in Pi4 - bookworm, docker, portainer, iobroker, influx:

Gibt es bei solchen Konstellationen etwas bestimmtes zu beachten oder regelt docker den Zugriff, wann es wohin geht?

Es ist (weiterhin) zu beachten, dass man keine IP-Adressen zum Ansprechen des jeweils anderen Containers nutzt, sondern den Namen. Dann wird automatisch der richtige Container (also hier z.B. "influx") angesprochen.

[Sleepwalker]

@marc-berg Holla, das gefällt mir! Ich glaube, das wird in Angriff genommen, bevor ich mit dem Wiederherstellen weitermache.

Uh, ich bin aufgeregt, werde hier auf jeden Fall Ergebnisse posten, ggf. noch die ein oder andere Frage.

Herzlichen Dank bis hierhin erst einmal! Das war super aufschlussreich (wie schon beim letzten Mal :) )

[Marc Berg]

@sleepwalker sagte in [gelöst] Pi4 - bookworm, docker, portainer, iobroker, influx:

Ich glaube, das wird in Angriff genommen

Vielleicht noch ein Tipp. Ich bin ein Fan davon, auch die Netzwerke komplett im Stack mit anzulegen. Dann hat man die gesamte Konfig in einer Datei und muss nicht noch manuell in Portainer rumwurschteln.

Beispiel mit Container in zwei Netzwerken:

services:
##### SERVIIO #####
  serviio:
    container_name: serviio
    image: soerentsch/serviio
    hostname: serviio
    domainname: fritz.box
    restart: unless-stopped
    volumes:
      - /opt/docker/serviio/library:/opt/serviio/library
      - /opt/docker/serviio/config:/opt/serviio/config
      - /opt/docker/serviio/plugins:/opt/serviio/plugins
      - /opt/docker/serviio/log:/opt/serviio/log
      - /media/serviio:/media/serviio
    environment:
      - TZ=Europe/Berlin
    networks:
      mvl1:
        ipv4_address: 192.168.1.32
      serviio_net:
##### NETWORKS #####
networks:
  mvl1:
    driver: macvlan
    name: mvl1
    driver_opts:
      parent: eno1
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.32/27
  serviio_net:
    driver: bridge
    name: serviio_net

[Sleepwalker]

@marc-berg

Leider hatte das Backup doch Vorrang, nachdem ich mein DHCP erstmal aufräumen musste.

Ich habe jetzt

192.168.100.64/29

Netzadresse: 192.168.100.64
Broadcast: 192.168.100.71
Host-IPs: 192.168.100.65 bis 192.168.100.70

aus meinem IP-Pool genommen. Soweit, so gut.

Nun möchte ich die Netzwerke ebenfalls in der "compose file" mit anlegen. Das sollte für ioBroker mit influx ungefähr so aussehen (noch nicht getestet):

services:
  iobroker:
    image: iobroker/iobroker:latest
    container_name: iobroker
    hostname: iobroker
    networks:
      - vlan_network
          ipv4_address: 192.168.100.65
      - iobroker_network
    restart: always
#    ports:
#      - 8081:8081 # Admin
#      - 8082:8082 # VIS
#      - 1880:1880 # NodeRed
#      - 1882:1882 # Shelly Adapter MQTT
#      - 8091:8091 # Backitup Restore Webinterface
#      - 9081:9081 # Backitup Fileserver fur Downloads von Backitup
#      - 9082:9082 # Backitup Fileserver fur Uploads von Backitup
#      - 34103:34103 # Alexa Adapter Cookie
    volumes:
      - type: bind
        source: /home/pi/docker_binds/iobroker_data/opt/iobroker
        target: /opt/iobroker
    environment:
      - IOB_BACKITUP_EXTDB=true
      - PACKAGES=influxdb2-cli
  influx:
    image: influxdb:latest
    container_name: influx
    hostname: influx
    networks:
      - iobroker_network
    restart: always
    ports:
      - 8086:8086 # Admin
    volumes:
      - type: bind
        source: /home/pi/docker_binds/influx_data/var/lib/influxdb2
        target: /var/lib/influxdb2
networks:
  vlan_network:
    driver: macvlan
    name: vlan_network
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.100.0/24
          gateway: 192.168.100.1
          ip_range: 192.168.64/29
  iobroker_network:
    driver: bridge
    name: iobroker_network

Jetzt habe ich noch drei Fragen:

1. Sieht das so i.O. aus?
2. Die Portweiterleitungen beim ioBroker brauche ich nicht, wenn ich über die .65 gehe, oder?
3. Die schwierigste Frage: Ich würde das gleiche MACVLAN gerne in einem anderen Stack nutzen, dann aber für einen Container mit der IP .66. Geht das? Ist das so, dass der erste Stack, der ein Netzwerk nutzt, es erstellt und alle anderen Stacks mit dem gleichen Netzwerknamen das Netz dann mitnutzen, sollte es schon existieren?

Sorry, etwas umständlich, aber bevor ich das kaputtfrickel...im Netz habe ich da so direkt nichts zu gefunden.

[Marc Berg]

@sleepwalker sagte in [gelöst] Pi4 - bookworm, docker, portainer, iobroker, influx:

Sieht das so i.O. aus?

• die Einrückungen passen nicht überall. Es müssen für eine untergeordnete Ebene immer zwei Zeichen eingerückt werden.
• ip_range ist falsch, da fehlt ein Oktett

Die Portweiterleitungen beim ioBroker brauche ich nicht, wenn ich über die .65 gehe, oder?

Korrekt, bei Host oder MACVLAN sind Weiterleitungen sinnfrei. Die kann man zwar ohne Fehlermeldungen im Stack definieren, haben aber keine Funktion.

Die schwierigste Frage: Ich würde das gleiche MACVLAN gerne in einem anderen Stack nutzen, dann aber für einen Container mit der IP .66. Geht das? Ist das so, dass der erste Stack, der ein Netzwerk nutzt, es erstellt und alle anderen Stacks mit dem gleichen Netzwerknamen das Netz dann mitnutzen, sollte es schon existieren?

Das geht, hat aber ein paar kleine Randerscheinungen:

Du kannst im zweiten Stack das erste Netzwerk mit dem Schlüsselwort "external: true" mitnutzen. Das hat aber den Nachteil, dass der zweite Stack nur startbar ist, wenn der erste schon läuft.

networks:
  vlan_network:
    external: true

Oder du definierst im zweiten Stack das Netzwerk wie im ersten 1:1 nochmal. Dann ist die Startreihenfolge egal. Kleiner Nachteil: Wenn beide Stacks beendet sind, wird in diesem Fall das Netzwerk nicht mitgelöscht.

Kommt auf den konkreten Anwendungfall an, ob das sinnvoll ist.