Slave-Installation - Master unter Slave-Adresse erreichbar
-
@arteck Nein ... ist ein 16er Subnet
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Redis ist nicht im Einsatz
muss es auch nicht.
nur bei Redis ist die manuelle Konfiguration das Muss.Die gleiche Anleitung gilt auch für "mit ohne" Redis, dann allerdings mit file statt redis
-
@homoran Jupp. Genau so ist es konfiguriert. Sobald ich den Slave starte, ist die Admin-Oberfläche auf dem Master nicht mehr zu erreichen. Nur die Adminoberfläche des Slaves. Dort sind alle Adapter des Masters sichtbar. Bei den Hosts auf dem Slave wird aber nur der Slave angezeigt.
Um den Master wieder zu erreichen, muss ich den Slave stoppen und den Master neu starten.
Das klingt alles ziemlich verbogen
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Das klingt alles ziemlich verbogen
So ist es
Ich habe da jetzt keine Ahnung
und das mit den Netzen ist zu hoch für mich -
@homoran Das mit dem Netz ist nicht so kompliziert. Durch das Subnet (255.255.0.0 oder /16) werden lediglich alle Geräte von 192.168.0.1 bis 192.168.255.254 in einem Netz geführt. Bei einem 24er Netz (255.255.255.0 oder /24) sind des nur alle Geräte von 192.168.0.1 bis 192.168.0.254.
Beste Grüße
-
@ducle Danke!
So ungefähr wusste ich das, nur weiß ich nicht ob das Multihostsystem mit diesen EinstellungenMaster (192.168.0.10/16):
Slave (192.168.181.28/16):zurechtkommt
-
@homoran An der Clientinstallation scheint es schon mal nicht zu liegen. Ich hab jetzt einen anderen Rechner genommen und Ubuntu frisch aufgesetzt. Auch hier tritt der selbe Effekt auf. Ich kann es mir nicht erklären, warum nach der Aktivierung des Slave der ioBroker nur noch über die IP des Slave zu erreichen ist. Aber das auch nur halb korrekt.
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
warum nach der Aktivierung des Slave der ioBroker nur noch über die IP des Slave zu erreichen ist
letzte Idee
Wenn du dann auf dem admin bist, sieh mal unter Instanzen.
Welchem Host ist der admin zugeordnet? -
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Host / Unix Socket of states DB (file), default[192.168.0.10]:
Hast du mal versucht vom Slave aus diese IP anzupingen.
Und noch was.
Ich bin jetzt etwas verunsichert ob die Objects auch auf dem Master verweisen sollen....
ich mach mich schlauerledigt!
alles gut! -
@homoran Ping zwischen beiden Maschinen geht. Was meinst Du genau mit "welchem Host der Admin zugeordnet ist?
Hier mal ein Screenshot der Instanzen. Es laufen nur die, die auch vorher auf dem Slave vorhanden waren. Die stehenden (roten) sind die, die auf dem Master installiert sind und dort auch problemlos laufen (naja, es sei denn man startet den verbunden Slave.
Nach den neuen Installation des Slave ist die IP-Zuordnung folgende:
Master: 192.168.0.10/16
Slave: 192.168.0.11/16 -
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Was meinst Du genau mit "welchem Host der Admin zugeordnet ist?
Da ist ja gar kein Multihost aktiv!
ich hatte es so (wahrscheinlich falsch) verstanden, dass Master und slave vertauscht seien.@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Es laufen nur die, die auch vorher auf dem Slave vorhanden waren.
da soll vorher nichts sein!
nur controller und höchstens adminAlle Instanzen müssen über den admin des Masters auf dem slave installiert werden.
(Das hätte ich gerne gesehen) -
@homoran So sieht die leere Slave Installation vor dem Connect aus
-
Was mir eben etwas spanisch vorkommt:
Die Version des Hosts auf dem Slave:
weicht von der auf dem Master ab:
Warum kommt bei der Neuinstallation die 3.3.19 obwohl doch nur die 3.3.19 verfügbar ist?
So sehen beide Installation vor dem Connect aus:
-
@ducle OK, das ist Basisinstallation.
Da kann man backitup und Discovery löschen.Aber das ändert nichts an der Tatsache, dass du den admin noch aufrufen kannst.
Aber auch da hatte ich etwas falsch verstanden.
Ich dachte du landest auf dem Slave wenn du den admin des Masters aufrufst.Da scheint bei dir tatsächlich die Kopplung falsch gelaufen zu sein.
Ich würde jetzt nochmal mit
iobroker setup custombeide Hosts isoliert konfigurieren.
Dann müsste man auf beide admins kommen.
Dann beide rebooten und anschließend neu koppeln.BTW Hats du nach der Änderung der Konfig neu gebooted?
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Warum kommt bei der Neuinstallation die 3.3.19 obwohl doch nur die 3.3.19 verfügbar ist?
????
wo ist der Unterschied? -
@homoran Sorry, das war ein Tippfehler. Hier der Satz noch einmal neu:
Warum kommt bei der Neuinstallation die 3.3.19 obwohl doch nur die 3.3.18 verfügbar ist?
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
@homoran Sorry, das war ein Tippfehler. Hier der Satz noch einmal neu:
Warum kommt bei der Neuinstallation die 3.3.19 obwohl doch nur die 3.3.18 verfügbar ist?
Das ist eine gute Frage:
latest: 3.3.19 for 1 days stable: 3.3.18 for 68 daysdie Neuinstallation sollte eigentlich stable installieren.
-
@homoran Ich hab jetzt noch einmal manuell konfiguriert:
Zuerst den Master:
@homecentral:~$ iobroker setup custom Current configuration: - Objects database: - Type: file - Host/Unix Socket: 0.0.0.0 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 0.0.0.0 - Port: 9000 - Data Directory: ../../iobroker-data/ Type of objects DB [(f)ile, (r)edis, ...], default [file]: Host / Unix Socket of objects DB(file), default[0.0.0.0]: Port of objects DB(file), default[9001]: Type of states DB [(f)file, (r)edis, ...], default [file]: Host / Unix Socket of states DB (file), default[0.0.0.0]: Port of states DB (file), default[9000]: Data directory (file), default[../../iobroker-data/]: /opt/iobroker/iobroker-data/ Host name of this machine [homecentral]: updating conf/iobroker.json @homecentral:~$ iobroker multihost enable Please check the binding of the configured file server to allow remote connections. No configuration change needed. Multihost discovery server: enabled Discovery authentication: enabled Persistent activation: disabled Objects: file on 0.0.0.0 States: file on 0.0.0.0 @homecentral:~$ iobroker restartanschließend den Slave:
@schaltschrank:/$ iobroker setup custom Current configuration: - Objects database: - Type: file - Host/Unix Socket: 0.0.0.0 - Port: 9001 - States database: - Type: file - Host/Unix Socket: 0.0.0.0 - Port: 9000 - Data Directory: ../../iobroker-data/ Type of objects DB [(f)ile, (r)edis, ...], default [file]: Host / Unix Socket of objects DB(file), default[0.0.0.0]: 192.168.0.10 Port of objects DB(file), default[9001]: Type of states DB [(f)file, (r)edis, ...], default [file]: Host / Unix Socket of states DB (file), default[192.168.0.10]: Port of states DB (file), default[9000]: Host name of this machine [schaltschrank]: updating conf/iobroker.json @schaltschrank:/$ iobroker multihost connect 1 | 192.168.0.10 | host | 192.168.0.10 | "authentication required" Please select host [1]: 1 Enter secret phrase for connection: ******** Config ok. Please restart ioBroker: "iobroker restart" @schaltschrank:/$ iobroker restartDann habe ich den Master neu gestartet. Anschließend den Slave. Als der Master hochkam, konnte ich mich auf die WebAdmin-Oberfläche verbinden. In dem Moment wo der Slave hochkam, war die Oberfläche auf dem Master nicht mehr erreichbar und die "verqueere" Oberfläche auf dem Slave war erreichbar.
Links Slave, Rechts Master:
-
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
Ich hab jetzt noch einmal manuell konfiguriert:
nicht wirklich!
@ducle sagte in Slave-Installation - Master unter Slave-Adresse erreichbar:
@homecentral:~$ iobroker multihost enable
iobroker multihost connect
das solltest du nicht machen, sondern nur die Änderungen an der Konfig
-
@homoran OK. Jetzt das ganze noch einmal manuell (ohne den connect Befehl) durchgeführt. In dem Moment wo der Slave hochfährt und iobroker startet geht die Webobverfläche des Masters offline
