Kein Admin nach Update

[Homoran]

@codierknecht sagte in Kein Admin nach Update:

@rj3n53n

Solange die Ports sich da nicht in die Quere kommen, passt das.

da war aber was mit Port 9000 wimre.

[RJ3n53n]

@homoran wimre sagt mir gar nichts

[Homoran]

@rj3n53n sagte in Kein Admin nach Update:

wimre

Wenn
Ich
Mich
Richtig
Erinnere

war an @Codierknecht gerichtet

[RJ3n53n]

@Homoran
Ach so. Danke....

[Codierknecht]

@homoran sagte in Kein Admin nach Update:

da war aber was mit Port 9000

Hatte meinen Container damals auf der Synology auch immer als Host laufen. Ohne Probleme.

[Homoran]

@codierknecht kann sein, dass irgendeine Station die 9000 nurzt. ich hab da dunkel due Surveillance station im Hinterkopf

[RJ3n53n]

@homoran Ich hab gerade nochmal geschaut. Ich hab nichts laufen, was auch die 9000 benötigen würde.

[xbow42]

darf ich mich mal einklinken? da mein iobroker nach dem letzten adminadapter update auch nicht mehr will hab ich das System auf einem baugleichen Rechner neu ausgesetzt.
Alt: bullsey, der iobroker auf dem Hostsystem und diverse andere Dienste als dockercontainer.

Neu: trixie hab ich in jeweils zwei separaten Stacks/Containern iobroker und evcc mit den üblichen Standardports. beides einzeln läuft aber der iobroker kann scheinbar nicht auf evcc 127.0.0.1:7070 zugreifen. wenn ich die Netzwerk-IP von eth0 verwende funktioniert es.

evcc.0
	2025-09-25 19:21:56.081	error	connect ECONNREFUSED 127.0.0.1:7070

Warum geht die Lokal-IP nicht?
Zur allgemeinen Vorgehensweise dachte ich, wenn ich die Dienste in separaten Stacks verwalte ist es leichter sich von vielleicht nicht mehr benötigten Diensten zu trennen. Wie seht ihr das?

zweites Problem bachup iobroker und zigbee wieder eingespielt, aber es werden keine Geräte angezeigt und dieser Instance-status.

Con-Anschlußnahme und ExtPanID sind auch gleich geblieben nach Stick umstecken. Alter Rechner ist aus um Konflickte zu vermeiden. Was ist zu tun?

VG Michael

[Codierknecht]

@xbow42 sagte in Kein Admin nach Update:

Warum geht die Lokal-IP nicht?

Weil die nur den jeweiligen Container erreicht. Ist ja die IP des "localhost".
Was Du machen kannst: Per MacVLAN den Containern jeweils eigene IP-Adressen vergeben. Die sind dann auch "von außen" erreichbar.

Spoiler

services:
  iobroker:
    container_name: ioBroker
    image: buanet/iobroker:latest
    hostname: iobroker
    volumes:
      - iobroker:/opt/iobroker:rw
    environment:
      PACKAGES: "nano"
      AVAHI: "true"
    tty: true
    stdin_open: true
    restart: unless-stopped
    networks:
      macvlan:
        ipv4_address: 192.168.179.232

volumes:
  iobroker:
networks:
  macvlan:
    external: true

Oder Du lebst damit, die IP des Docker-Host + Port zu verwenden.

Zur allgemeinen Vorgehensweise dachte ich, wenn ich die Dienste in separaten Stacks verwalte ist es leichter sich von vielleicht nicht mehr benötigten Diensten zu trennen. Wie seht ihr das?

Mache ich eigentlich nur noch. Mittlerweile habe ich mir eine ganze Bibliothek an (mehr oder weniger) nützlichen Compose/Stacks angelegt. Man weiß ja nie, was man später nochmal brauchen kann.

[xbow42]

@codierknecht Danke für die Rückmeldung! Dann lasse ich das so. jeder neu aufgesetzte Server bekommt dann wieder die IP vom ausrangierten. Deutlich schneller als bei diversen Clients die Konfiguration zu ändern.

Was mir noch fehlt ist ein strukturiertes todo für die Neuinstallation. Dauert doch einige Stunden bis man alles wieder auf Reihe hat.
jetzt bin ich am Suchen was ich auf den alten Server wo hin geschoben hab...