Kein Admin nach Update

[Codierknecht]

@rj3n53n sagte in Kein Admin nach Update:

Ich weiß gerade nicht, wie Du das mit ein Projekt meinst

Ich vermute mal: Du hast das bislang über den Container-Manager als Container aufgesetzt.
Dann muss man den ganzen Kram "von Hand" passend einstellen. Volumes, Ports, Variablen etc.

Man kann das im Container-Manager auch als "Projekt" aufsetzen. Dann wird die komplette Konfiguration in einer YAML-Datei abgelegt. In Docker nennt sich das "Compose" und in Portainer "Stacks". Ist aber alles das gleiche.

Als Quelle wählst Du "docker-compose.yml erstellen" und fügst dann den folgenden Inhalt in den Editor ein.
Ein grundlegendes docker-compose.yml für ioBroker könnte so aussehen:

services:
  iobroker:
    container_name: ioBroker
    image: buanet/iobroker:latest
    hostname: iobroker
    network_mode: "host"    
    volumes:
      - /volume1/Docker/ioBroker:/opt/iobroker
    environment:
      PACKAGES: "nano"
      AVAHI: "true"
    restart: unless-stopped

Muss halt ggf. etwas an die eigenen Gegebenheiten angepasst werden.
Man beachte hier: Der Container läuft als "host". Man muss also keine Ports speziell mappen.
Könnte allerding schiefgehen, wenn auf der Synology noch ander Dienste (WebStation, Fotos usw.) laufen, die Ports beanspruchen die auch vom ioBroker verwendet werden.

[RJ3n53n]

@codierknecht
Okay, jetzt weiß ich, was Du meinst. Ja, so hatte ich das gemacht. Eingerichttet hatte ich es nach einer Anleitung. Noch bevor es bei Synology Container-Manager hieß. Da war damals auch beschrieben, welche Ports ich öffnen musste.

[Codierknecht]

@rj3n53n sagte in Kein Admin nach Update:

Noch bevor es bei Synology Container-Manager hieß

Seit DSM 7 gibt's den Container-Manager und damit auch die "Projekte".
Macht das Ganze deutlich einfacher.

welche Ports ich öffnen musste

Wenn der Container im Host-Mode läuft, muss man keine Ports mehr freigeben.
Solange auf der Syno nix läuft was dem Container da in die Suppe spucken kann, spart man sich die ganze Port-Litanei.

[RJ3n53n]

@codierknecht
Ich hab da ein oder andere auf der Syno am Laufen. Aber auch da gab es bisher keine Probleme.

[Codierknecht]

@rj3n53n

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

[RJ3n53n]

@Codierknecht Dankeschön

[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...