Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
-
- Beiträge: 16
- Registriert: 1. Nov 2020 12:06
Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Hallo, würde gerne -ohne Fehler- einen Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm) machen.
Das neue System Raspi (Bockworm) ist entsprechend -initial- vorbereitet:
>> leeres Openhab 4.1.1 im Docker läuft(via docker-compose aufgesetzt) mit zugeordneten Volumens
>>> Pfad /home/hsrroot/openhab
>>> IP-Adresse xxx.xxx.xxx.212;
>>> KNX-Gateway von 172.21.0.2:0 auf xxx.xxx.xx.170:3671; muss hierbei etwas beachtet werden?
>>> native deconz-Anbindung auf xxx.xxx.xxx.216 (ca. 100 Sensoren)
>> altes Openhab 4.1.1 im Docker läuft (via docker-compose aufgesetzt) mit zugeordneten Volumens
>>>Pfad /home/pi/opnehab3
>>> IP-Adresse xxx.xxx.xxx.210
>>> KNX-Gateway von 172.21.0.2:0 auf xxx.xxx.xx.170:3671; muss hierbei etwas beachtet werden?
>>> native deconz-Anbindung auf xxx.xxx.xxx.216 (soll dann auch sein!)
Die Docker-Compose-Konfig ist deckungsgleich, nur die Pfade sind angepasst.
Wie gehe ich nun sinnvoll vor, so dass kein weiterer Konfigurationaufwand notwendig ist und damit das System sofort produktiv ist?
(A) nur die Openhab-Konfig-Dateien (addons, userdata, conf) kopieren?
>>> beide Container abschalten
>>> Dateien kopieren; tmp und cache habe ich gelöscht
>>> altes System beenden
>>> Container Openhab im neuen System starten
Erster Versuch: KNX-Server kann nicht verbunden werden!! OH-IP war in Netzwerk-Einstellungen nicht selektiert. KNX-Zugriff geht trotzdem nicht.
(B) ?
Gruss hsrtreml
Das neue System Raspi (Bockworm) ist entsprechend -initial- vorbereitet:
>> leeres Openhab 4.1.1 im Docker läuft(via docker-compose aufgesetzt) mit zugeordneten Volumens
>>> Pfad /home/hsrroot/openhab
>>> IP-Adresse xxx.xxx.xxx.212;
>>> KNX-Gateway von 172.21.0.2:0 auf xxx.xxx.xx.170:3671; muss hierbei etwas beachtet werden?
>>> native deconz-Anbindung auf xxx.xxx.xxx.216 (ca. 100 Sensoren)
>> altes Openhab 4.1.1 im Docker läuft (via docker-compose aufgesetzt) mit zugeordneten Volumens
>>>Pfad /home/pi/opnehab3
>>> IP-Adresse xxx.xxx.xxx.210
>>> KNX-Gateway von 172.21.0.2:0 auf xxx.xxx.xx.170:3671; muss hierbei etwas beachtet werden?
>>> native deconz-Anbindung auf xxx.xxx.xxx.216 (soll dann auch sein!)
Die Docker-Compose-Konfig ist deckungsgleich, nur die Pfade sind angepasst.
Wie gehe ich nun sinnvoll vor, so dass kein weiterer Konfigurationaufwand notwendig ist und damit das System sofort produktiv ist?
(A) nur die Openhab-Konfig-Dateien (addons, userdata, conf) kopieren?
>>> beide Container abschalten
>>> Dateien kopieren; tmp und cache habe ich gelöscht
>>> altes System beenden
>>> Container Openhab im neuen System starten
Erster Versuch: KNX-Server kann nicht verbunden werden!! OH-IP war in Netzwerk-Einstellungen nicht selektiert. KNX-Zugriff geht trotzdem nicht.
(B) ?
Gruss hsrtreml
- udo1toni
- Beiträge: 15243
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Du hast es schon gut beschrieben. Aber vollständig:
Zunächst beendest Du den Container mit dem Neuen System.
Dann führst Du den Befehl
aus und notierst Dir UID und GID (die zweite und dritte Zahle nach den Buchstaben (sollten für die drei Volumes identisch sein)
Jetzt beendest Du den alten Container.
Anschließend kopierst Du den Inhalt der Volumes vom alten Container in die neuen Volumes.
Danach prüfst Du (vom Host System aus als User root), dass UID und GID in den kopierten Daten mit den gerade ermittelten übereinstimmen.
Falls es Abweichungen gibt, wäre der passende Befehl
wobei UID und GID natürlich durch die betreffenden Zahlen zu ersetzen ist.
Der neue openHAB Container sollte möglichst im host-Mode laufen, da nur so Autodiscovery uneingeschränkt funktionieren wird.
Der Container erhält dann direkt die selbe IP wie das Host System und belegt auch die entsprechenden Ports (5007, 8080, 8443) - ein Mapping ist nicht vorgesehen.
Das knx Gateway sollte nicht Teil des openHAB Containers sein (so oder so) und benötigt also auch keine Class-B Adresse, das gleiche gilt für dekonz. Oder ist das eh eine Instanz auf einem anderen Rechner bzw. eine eigene Hardware?
Noch ein paar Worte zu den privaten IP-Adressen: Die musst Du grundsätzlich nicht unkenntlich machen (das bringt keinerlei Sicherheitsgewinn).
Die öffentliche IP solltest Du keinesfalls verraten, die private IP kannst Du hingegen in Zehn Meter großen Ziffern an die nächste Hauptstraße stellen, ist völlig irrelevant.
Privat bedeutet hier, dass die IP nicht übers Internet erreichbar ist, im Gegensatz zur öffentlichen IP.
Hat jemand Zugriff auf Dein (W-)LAN, so ist auch hier die Information zur IP irrelevant, denn ein einfacher nmap Befehl reicht, um innerhalb weniger Sekunden alle erreichbaren Geräte innerhalb Deines LAN zu finden (incl. Informationen, welches Betriebssystem läuft und welche Ports offen sind - also alle notwendigen Informationen für direkte Angriffe).
Wenn die Daten auf dem neuen System liegen und die Besitzrechte korrekt gesetzt sind, kannst Du den neuen Container einfach starten.
Ach so... Da der neue Host ziemlich sicher eine andere IP hat als der alte Host, musst Du hier natürlich aufpassen. Alternativ kannst Du dem neuen Host die IP des alten Host zuweisen (nachdem Du den alten Host komplett gestoppt hast)
Zunächst beendest Du den Container mit dem Neuen System.
Dann führst Du den Befehl
Code: Alles auswählen
ls -ln /home/hsroot/openhab/*
Jetzt beendest Du den alten Container.
Anschließend kopierst Du den Inhalt der Volumes vom alten Container in die neuen Volumes.
Danach prüfst Du (vom Host System aus als User root), dass UID und GID in den kopierten Daten mit den gerade ermittelten übereinstimmen.
Falls es Abweichungen gibt, wäre der passende Befehl
Code: Alles auswählen
chown -R UID:GID /home/hsroot/openhab/*
Der neue openHAB Container sollte möglichst im host-Mode laufen, da nur so Autodiscovery uneingeschränkt funktionieren wird.
Der Container erhält dann direkt die selbe IP wie das Host System und belegt auch die entsprechenden Ports (5007, 8080, 8443) - ein Mapping ist nicht vorgesehen.
Das knx Gateway sollte nicht Teil des openHAB Containers sein (so oder so) und benötigt also auch keine Class-B Adresse, das gleiche gilt für dekonz. Oder ist das eh eine Instanz auf einem anderen Rechner bzw. eine eigene Hardware?
Noch ein paar Worte zu den privaten IP-Adressen: Die musst Du grundsätzlich nicht unkenntlich machen (das bringt keinerlei Sicherheitsgewinn).
Die öffentliche IP solltest Du keinesfalls verraten, die private IP kannst Du hingegen in Zehn Meter großen Ziffern an die nächste Hauptstraße stellen, ist völlig irrelevant.
Privat bedeutet hier, dass die IP nicht übers Internet erreichbar ist, im Gegensatz zur öffentlichen IP.
Hat jemand Zugriff auf Dein (W-)LAN, so ist auch hier die Information zur IP irrelevant, denn ein einfacher nmap Befehl reicht, um innerhalb weniger Sekunden alle erreichbaren Geräte innerhalb Deines LAN zu finden (incl. Informationen, welches Betriebssystem läuft und welche Ports offen sind - also alle notwendigen Informationen für direkte Angriffe).
Wenn die Daten auf dem neuen System liegen und die Besitzrechte korrekt gesetzt sind, kannst Du den neuen Container einfach starten.
Ach so... Da der neue Host ziemlich sicher eine andere IP hat als der alte Host, musst Du hier natürlich aufpassen. Alternativ kannst Du dem neuen Host die IP des alten Host zuweisen (nachdem Du den alten Host komplett gestoppt hast)
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 1. Nov 2020 12:06
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Hallo udo1toni, herzlichen Dank für deine ausführlichen Rückmeldungen. Aktuell habe ich zu deinen Vorschlägen folgenden Stand:
>> die UID/GID sind jeweils "0" und passen somit
>> im alten und neuen System ist yml-Einstellung: networks: - default; hier meinest du auf networks: - host einstellen
>>deconz läuft auf einem weiteren Raspi und funktioniert auch mit dem neuen System
>> ein Mapping gibt es: ports: - "38080:8080/tcp"
>> das System startet korrekt nur die Verbindung zum KNX-Gateway geht nicht:
Das knx Gateway sollte nicht Teil des openHAB Containers sein (so oder so) und benötigt also auch keine Class-B Adresse:
>> UID: knx:ip:46e1045af6
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: true
readRetriesLimit: 3
ipAddress: 192.168.0.170
>> localIp: 172.21.0.2 >> was kommt hierhin?
autoReconnectPeriod: 60
type: TUNNEL
localSourceAddr: 0.0.0
readingPause: 50
portNumber: 3671
responseTimeout: 10
location: System
D.h., die Einstellung ist falsch? Im alten System hatte ich aus den Anfangszeiten noch einen Container knxd laufen
>> die UID/GID sind jeweils "0" und passen somit
>> im alten und neuen System ist yml-Einstellung: networks: - default; hier meinest du auf networks: - host einstellen
>>deconz läuft auf einem weiteren Raspi und funktioniert auch mit dem neuen System
>> ein Mapping gibt es: ports: - "38080:8080/tcp"
>> das System startet korrekt nur die Verbindung zum KNX-Gateway geht nicht:
Das knx Gateway sollte nicht Teil des openHAB Containers sein (so oder so) und benötigt also auch keine Class-B Adresse:
>> UID: knx:ip:46e1045af6
label: KNX/IP Gateway
thingTypeUID: knx:ip
configuration:
useNAT: true
readRetriesLimit: 3
ipAddress: 192.168.0.170
>> localIp: 172.21.0.2 >> was kommt hierhin?
autoReconnectPeriod: 60
type: TUNNEL
localSourceAddr: 0.0.0
readingPause: 50
portNumber: 3671
responseTimeout: 10
location: System
D.h., die Einstellung ist falsch? Im alten System hatte ich aus den Anfangszeiten noch einen Container knxd laufen
- udo1toni
- Beiträge: 15243
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
UID/GID 0 sollte eigentlich nicht sein, 0 ist das root Konto. Evtl. ist Dir da schon Zu Beginn ein Fehler unterlaufen.
Als localIp musst Du die Host IP setzen, denn das ist ja die IP, unter der openHAB erreichbar ist.
Wenn Du unter der IP 192.168.0.170 ein "physisch vorhandenes" knx/IP Gateway erreichen kannst, brauchst Du nicht noch zusätzlich knxd.
Falls Du eine knx-USB Schnittstelle nutzt, musst Du evtl. knxd für die Anbindung nutzen, dann läuft knxd aber als separater Container, openHAB kommuniziert dann über die Host IP mit knxd.
Für Netzwerkverbindungen wird immer die Host IP verwendet, gegebenenfalls mit der Portnummer, die als Mapping angegeben ist.
Wenn ein Container im host Mode läuft, bekommt er kein eigenes Subnetz, sondern verwendet einfach die IP-Adresse des Host. Solange sich keine Ports von anderen Containern in die Quere kommen, macht das nichts. Für openHAB ist der host Mode aber wichtig, weil die Docker Netzwerkbridge kein Multicast routen kann. Multicast ist an vielen Stellen in der Netzwerkkommunikation von openHAB essenziell - z.B. wenn man eine knx/IP Router einsetzen will, aber auch für AVAHI/ZeroConf und etliche andere Protokolle.
Als localIp musst Du die Host IP setzen, denn das ist ja die IP, unter der openHAB erreichbar ist.
Wenn Du unter der IP 192.168.0.170 ein "physisch vorhandenes" knx/IP Gateway erreichen kannst, brauchst Du nicht noch zusätzlich knxd.
Falls Du eine knx-USB Schnittstelle nutzt, musst Du evtl. knxd für die Anbindung nutzen, dann läuft knxd aber als separater Container, openHAB kommuniziert dann über die Host IP mit knxd.
Für Netzwerkverbindungen wird immer die Host IP verwendet, gegebenenfalls mit der Portnummer, die als Mapping angegeben ist.
Wenn ein Container im host Mode läuft, bekommt er kein eigenes Subnetz, sondern verwendet einfach die IP-Adresse des Host. Solange sich keine Ports von anderen Containern in die Quere kommen, macht das nichts. Für openHAB ist der host Mode aber wichtig, weil die Docker Netzwerkbridge kein Multicast routen kann. Multicast ist an vielen Stellen in der Netzwerkkommunikation von openHAB essenziell - z.B. wenn man eine knx/IP Router einsetzen will, aber auch für AVAHI/ZeroConf und etliche andere Protokolle.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 1. Nov 2020 12:06
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Vielen Dank; jetzt wird es für mich kompliziert:
"UID/GID 0 sollte eigentlich nicht sein, 0 ist das root Konto. Evtl. ist Dir da schon Zu Beginn ein Fehler unterlaufen"
>> wahrscheinlich, lasse ich erst mal so...
"Als localIp musst Du die Host IP setzen, denn das ist ja die IP, unter der openHAB erreichbar ist.
Wenn Du unter der IP 192.168.0.170 ein "physisch vorhandenes" knx/IP Gateway erreichen kannst"
>> ja, ein KNX-IP-Gateway, also local-IP auf 192.168.0.212 (= Host-IP-vom Raspi)
>> knxd nutze ich nicht mehr (also Container löschen)
"Für Netzwerkverbindungen wird immer die Host IP verwendet, gegebenenfalls mit der Portnummer, die als Mapping angegeben ist.
Wenn ein Container im host Mode läuft, bekommt er kein eigenes Subnetz, sondern verwendet einfach die IP-Adresse des Host. "
>> wenn ich auf "networks: - host" umstelle (192.168.0.212:38000), dann bekommt OH kein Class-B-Netz mehr (127....)! Richtig?
>> d.h. in OH muss dann als Primäre IP die 192.168.0.212 stehen und nicht mehr 172.21.0.2/16
>> die Ports der anderen Container sind alle andere Nummern
Liege ich mit meinen Interpretationen nun richtig?
"UID/GID 0 sollte eigentlich nicht sein, 0 ist das root Konto. Evtl. ist Dir da schon Zu Beginn ein Fehler unterlaufen"
>> wahrscheinlich, lasse ich erst mal so...
"Als localIp musst Du die Host IP setzen, denn das ist ja die IP, unter der openHAB erreichbar ist.
Wenn Du unter der IP 192.168.0.170 ein "physisch vorhandenes" knx/IP Gateway erreichen kannst"
>> ja, ein KNX-IP-Gateway, also local-IP auf 192.168.0.212 (= Host-IP-vom Raspi)
>> knxd nutze ich nicht mehr (also Container löschen)
"Für Netzwerkverbindungen wird immer die Host IP verwendet, gegebenenfalls mit der Portnummer, die als Mapping angegeben ist.
Wenn ein Container im host Mode läuft, bekommt er kein eigenes Subnetz, sondern verwendet einfach die IP-Adresse des Host. "
>> wenn ich auf "networks: - host" umstelle (192.168.0.212:38000), dann bekommt OH kein Class-B-Netz mehr (127....)! Richtig?
>> d.h. in OH muss dann als Primäre IP die 192.168.0.212 stehen und nicht mehr 172.21.0.2/16
>> die Ports der anderen Container sind alle andere Nummern
Liege ich mit meinen Interpretationen nun richtig?
- udo1toni
- Beiträge: 15243
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Ja, aber die 172.21.0.2 war schon immer verkehrt, denn über diese IP ist openHAB von außen gar nicht erreichbar 
networks: müsste meiner Interpreatation nach allerdings in network_mode umbenannt werden, jedenfalls steht das so bei mir drin:
Ach so, Forenfunktionen: Wenn Du unten auf "Vollständiger Editor" klickst, bekommst Du ein Editorfenster mit Knöpfen, um Zitate zu markieren oder auch Code (alles was in irgendeiner Form formatiert wiedergegeben werden sollte, wäre Code, also Logzeilen, yaml (ganz wichtig!) oder auch Inhalte von anderen Textdateien, das ist besser lesbar und im Falle von yaml sogar entscheidend, weil die Einrückungen Teil des Codes sind. Die Forensoftware entfernt aber führende Leerzeichen bei der Ausgabe.
Wenn Du im vollständigen Editor bist, Teile eines Postings markierst und anschließend in diesem Posting auf die Schaltfläche Zitat klickst (innerhalb des Postings oben rechts), dann wird der markierte Text automatisch als Zitat in Deiner Antwort eingefügt. Bist Du nicht im vollständigen Editor, so fügt der Button immer das vollständige Posting ein und löscht den bereits geschriebenen Text...

networks: müsste meiner Interpreatation nach allerdings in network_mode umbenannt werden, jedenfalls steht das so bei mir drin:
Code: Alles auswählen
version: '2.2'
services:
openhab:
image: "openhab/openhab:latest"
restart: always
network_mode: host
ports:
- 8080:8080
- 8443:8443
volumes:
- "/etc/localtime:/etc/localtime:ro"
- "/etc/timezone:/etc/timezone:ro"
- "/portainer/Files/AppData/Config/openHAB4/openhab_addons:/openhab/addons"
- "/portainer/Files/AppData/Config/openHAB4/openhab_conf:/openhab/conf"
- "/portainer/Files/AppData/Config/openHAB4/openhab_userdata:/openhab/userdata"
environment:
CRYPTO_POLICY: "unlimited"
EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
OPENHAB_HTTP_PORT: "8080"
OPENHAB_HTTPS_PORT: "8443"
USER_ID: "998"
GROUP_ID: "997"
Wenn Du im vollständigen Editor bist, Teile eines Postings markierst und anschließend in diesem Posting auf die Schaltfläche Zitat klickst (innerhalb des Postings oben rechts), dann wird der markierte Text automatisch als Zitat in Deiner Antwort eingefügt. Bist Du nicht im vollständigen Editor, so fügt der Button immer das vollständige Posting ein und löscht den bereits geschriebenen Text...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 1. Nov 2020 12:06
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Umstellung von default auf host in compose:
>> ERROR: for openhab "host" network_mode is incompatible with port_bindings
Auch mit diesem Eintrag erscheint der Fehler:
>>> Habe nun den Bereich "ports" komplett gelöscht, dann konnte auf das KNX-System zugreifen!
hier meine bisherige Compose:
>> ERROR: for openhab "host" network_mode is incompatible with port_bindings
Auch mit diesem Eintrag erscheint der Fehler:
Code: Alles auswählen
ports:
- 8080:8080
- 8443:8443
hier meine bisherige Compose:
Code: Alles auswählen
#version: '2.2'
services:
openhab:
image: "openhab/openhab:4.1.1"
container_name: openhab
restart: unless-stopped
networks:
- default
ports:
- "38080:8080/tcp"
volumes:
- "/etc/localtime:/etc/localtime:ro"
- "/etc/timezone:/etc/timezone:ro"
- "openhab_addons:/openhab/addons"
- "openhab_conf:/openhab/conf"
- "openhab_userdata:/openhab/userdata"
environment:
CRYPTO_POLICY: "unlimited"
EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
OPENHAB_HTTP_PORT: "8080"
OPENHAB_HTTPS_PORT: "8443"
USER_ID: "1000"
GROUP_ID: "1000"
volumes:
openhab_addons:
driver: local
openhab_conf:
driver: local
openhab_userdata:
driver: local
- udo1toni
- Beiträge: 15243
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Ja, stimmt auffällig, im host-Mode gibt es kein Port Mapping. Das muss noch aus einem früheren Versuch übrig sein (bei dem ich den Container im bridge Mode habe laufen lassen)...
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
-
- Beiträge: 16
- Registriert: 1. Nov 2020 12:06
Re: Umzug von einem Openhab 4.1.1 im Docker (Buster) auf einen neuen Raspi 4 (Bockworm)
Danke für Deine Hilfe;
Testphase:
Compose-Einstellungen ("network_mode: host") und ohne das Mapping ("38080:8080/tcp")
Problem Netzwerkeinstellungen in OpenHab:
Primäre IP-Adresse
AUS: 172.17.0.1/16
AUS: 172.19.0.1/16
AUS: 172.21.0.1/16
AN: 192.168.0.212/24
Eine Broadcast-IP-Adresse (z.B. 192.168.1.255).
Einzelne IP-Adresse pro Interface: Nur eine einzelne IP-Adresse pro Interface verwenden.
AUS: IPv6 verwenden
Aufgrund dieser Einstellungen liefert das Systeminfo-Binding als Netzwerk IP-Adresse nur "UNDEF"
Was muss ich tun, damit statt "UDEF" die 192.168.0.212 (des Raspi) erscheint?
Weiterhin gibt es dazu Warnungen im LOG:
Testphase:
Compose-Einstellungen ("network_mode: host") und ohne das Mapping ("38080:8080/tcp")
Problem Netzwerkeinstellungen in OpenHab:
Primäre IP-Adresse
AUS: 172.17.0.1/16
AUS: 172.19.0.1/16
AUS: 172.21.0.1/16
AN: 192.168.0.212/24
Eine Broadcast-IP-Adresse (z.B. 192.168.1.255).
Einzelne IP-Adresse pro Interface: Nur eine einzelne IP-Adresse pro Interface verwenden.
AUS: IPv6 verwenden
Aufgrund dieser Einstellungen liefert das Systeminfo-Binding als Netzwerk IP-Adresse nur "UNDEF"
Was muss ich tun, damit statt "UDEF" die 192.168.0.212 (des Raspi) erscheint?
Weiterhin gibt es dazu Warnungen im LOG:
Code: Alles auswählen
2024-06-26 10:39:05.872 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.21.0.1/16, truncating to /24, some addresses might be lost
2024-06-26 10:39:05.876 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.19.0.1/16, truncating to /24, some addresses might be lost
2024-06-26 10:39:05.880 [INFO ] [.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.17.0.1/16, truncating to /24, some addresses might be lost