Hallo
Ein Modul das FHEM mit verschiedenen fhem.cfg laden kann und FHEM auch eine eigene IP Adresse zuteilt.
Der FHEM Server startet. Ein Modul kontrolliert ob die einzustellende A_IP-Adresse frei ist.
Wenn ja:A_FHEM wird geladen, FHEM läuft normal mit der eigenen A_IP-Adresse.
Wenn nein: es wird eine andere B_FHEM Installation wird gestartet und erhält die B_IP-Adresse.
Dazu ein Modul das die beiden FHEM A_FHEM und B_FHEM mit wenig Aufwand auf dem gleichen Stand hält.
Backup machen geht schnell aber zurückspielen braucht Handarbeit und halt fremde Programme, FileZilla und Putty.
bin erst jetzt darauf gestossen...
Mit neuen/verschiedenen IP-Adressen auf einer Maschine dürfte es nur schwer gehen, sie werden ja in Betriebsystem verwaltet, aber mit verschiedenen Ports geht es.
Ich mache so etwas, allerdings nicht aus FHEM heraus, sondern aus einem vorgelagerten Perl-Script. Dieser startet (je nach Konfiguration) mehrere FHEM-Instances mit verschiedenen "fhem.cfg" und überwacht diese, ob sie noch laufen (und startet sie ggf neu).
Script liegt hier: https://github.com/hexenmeister/fhem-watchdog
Bei Bedarf kann ich etwas mehr Erklärungen nachreichen.
Die configDB kann sowas von Haus aus.
Zitat von: hexenmeister am 17 Juni 2017, 12:30:17
Mit neuen/verschiedenen IP-Adressen auf einer Maschine dürfte es nur schwer gehen, sie werden ja in Betriebsystem verwaltet,
Und wo ist das Problem? Mein eth0 auf dem Cubietruck hat 4 verschiedene IP Adressen.
eth0:0
eth0:1
Mein Router hat 7.
Aber das Problem ist eher das es wenig User gibt die wissen wie man sowas ohne Verluste mit FHEM macht und noch viel viel weniger die sowas unter Linux beherrschen.
Zitat von: betateilchen am 17 Juni 2017, 19:02:03
Die configDB kann sowas von Haus aus.
configDB hat seine Vorteile, für mein Fall (bei meiner Vorliebe für Config-Datien ;D ) brauche ich es eher nicht.
Zitat von: betateilchen am 17 Juni 2017, 19:02:03
Und wo ist das Problem? Mein eth0 auf dem Cubietruck hat 4 verschiedene IP Adressen.
Das ist nicht das Problem, kann man schon machen, aber das in einem FHEM-Modul zu erledigen wäre sicher fehl am Platz.
Mein Script ist einer ein Watchdog für mehrere Instanzes, und weil verschiedene Ports einfacher zu verwenden sind, als IP-Adressen, ging ich den weg des geringsten Widerstandes ;D
Vielen Dank für die Antworten
ZitatMit neuen/verschiedenen IP-Adressen auf einer Maschine dürfte es nur schwer gehen, sie werden ja in Betriebsystem verwaltet, aber mit verschiedenen Ports geht es.
Das wäre dann am besten ein Modul in Fhem das mit Admin rechten vom Linux die nötigen IP Adressen im Betriebssystem anpasst?
Oder nur vordefinierte Einstellungen im Betriebssystem aktiviert ginge auch.
Ist mir schon klar das es mit script etc. geht.
Mann kann sehr viel mit FHEM.
Es gibt aber leider noch Sachen die sehr kompliziert sind.
zb.
Backup machen geht einfach, zurückspielen halt nicht.
Ein Modul wo der Speicherort für das Backup hinterlegt werden kann.
Das einem dann die Backups anzeigt, die dort gemacht wurden.
Und per klick ein Backup macht und auch ein Backup zurückspielen kann.
Das braucht aber natürlich auch Admin Rechte für Linux.
Zitat von: Damu am 18 Juni 2017, 10:52:30
Das wäre dann am besten ein Modul in Fhem das mit Admin rechten vom Linux die nötigen IP Adressen im Betriebssystem anpasst?
FHEM mit Admin (root) Rechten laufen zu lassen halte ich für eine sehr schlechte Idee.
Und für die Verwaltung von IP-Adressen ist FHEM schlicht und einfach nicht da. "Golden hammer" war schon immer ein AntiPattern ;)
Was ist Dein eigentlicher Anwendungsfall?
Ein FHEM-Modul, dass ein FHEM Backup zurückspielen kann, macht mEn gar keinen Sinn. Zurückspielen muss man sicher in 99,9% der Fälle, wenn FHEM nicht mehr läuft. Dann hilft einem das Modul nicht. Für alles andere gibt es restore (und nur da macht es Sinn).
Ich habe ein FHEM Server der immer läuft.
Ich habe den Server nochmals als reserve wenn der Hauptserver mal aussteigt.
Ich möchte den Aufwand für die Wartung etc. etwas vereinfachen.
Die Kameras senden auch Meldungen zu FHEM.
Wenn der FHEM server ein anderer mit Anderer IP ist muss das alles immer angepasst werden.
Das mit dem Goldenen Hammer verstehe ich.
Vielleicht ein Script das Mann mit Fhem ausführen kann, das dem FHEM Server eine zweite Adresse zuweist, und eines das die zugewiesene Adresse wieder entfernt.
Allen FHEM Server die selbe IP Adresse zuweisen finde ich eine schlechte Ide,
Eine Zweite IP Adresse und wenn möglich diese nur für FHEM und wenn diese zusätzlich noch aktiviert und deaktiviert werden kann ist natürlich viel besser.
Verstehe... Hot standby.
Gute Idee, aber... dem FHEM anzuvertrauen, IP-Adressen zu verwalten, ist gefährlich. Das muss viel tiefer ins Betriebssystem, oder besser als eine zusätzliche Komponente vor den Rechnern (also keine mehrfach-IPs).
Es muss ja nicht nur eine zusätzliche IP angemeldet werden, sondern auch die andere unbedingt weg. Zwei gleiche IPs im Netzwerk bringen alles durcheinander, dann laufen beide nicht mehr rund. Was soll FHEM2 machen, wenn Server1 noch online ist, aber FHEM1 schon tot? Server1 umkonfigurieren? Wodurch? Und wenn der Server nicht mehr korrekt ansprechbar ist, aber die IP noch durchaus erreichbar ist?
Meiner Meinung nach kann das so nicht zuverlässig funktionieren.
2 x fhem virtualisiert und auf dem host iptables plus script welches, je nach Zustand, routet ?
Frage dann: wie hält man die beiden Instanzen synchron ?
vg
joerg
Virtualisiert retten nicht von Host-Ausfall.
Mir reichen FHEM mit Watchdog, der die Instanz überwacht plus Hardware-Watchdog fürs Betriebssystem.
Wenns wirklich besonders wichtig ist, könnte man zwei Rechner identisch konfigurieren und durch einen externen Watchdog (Arduino?) Ein- uns Ausschalten lassen (Cold standby). Problem des Synchronisierens bleibt noch. Dafür könnte man (stündlich?) den Haupt-FHEM auf NAS sichern und beim Start des Reservesystems automatisch den letzten Backup ziehen. Ist mir aber zu kompliziert. Eine Reserve-Boot-SDCard in der Schublade reicht mir ;)
ZitatWas soll FHEM2 machen, wenn Server1 noch online ist, aber FHEM1 schon tot? Server1 umkonfigurieren?
Wenn FHEM startet die FHEM IP nur freigeben wenn Sie nicht benutzt wird.
Wiese muss dann die erste IP weg?
Mobotix hat auch zwei als Standart gesetzt.
Ich meine die zweite gleiche IP von dem anderen Rechner. Zwei gleiche im Netzwerk wäre eine Katastrophe.
Wie bringt dieses Verfahren, wenn erste Fhem hängt/abstürzt, die IP aber schon belegt hat? Solche Mechanismen können nur wirken, wenn sie deutlich tiefer verankert sind.
ZitatIch meine die zweite gleiche IP von dem anderen Rechner
Dershalb meine ich das beim FHEM Start, Fhem kontrolliert ob die Adresse benutzt wird, und wenn Sie frei ist,
Meine Ide ist das FHEM beim Start zuerst eine start_fhem.cfg diese kann dann wenn nötig den anderen FHEM Server ausschalten, bei mir vielleicht über ssh wie ein Synology, und wenn das nicht geht über das Infratec IP-Switch.
Dort habe ich zwei Nuc und ein PI3 angeschlossen.
Das Infratec IP Switch hat Bistabile Relais, es braucht kein Haltestrom. Nur die Elektronik und das Anzeige LED braucht Strom.
Hab es auch mal mit einem APC IP Switch versucht, braucht 3.5 Watt wenn alles aus ist und 14 Watt wenn alle (16 ein sind) ein sind.
Das Infraten braucht glaube 3.5 Watt wenn alles aus ist und 4.5 Watt wenn alles ein ist (8).
An dem Infratec ist aber auch noch Fernseher und Radio, wenn ich diese im Tag nur 30 Minuten vom Standby ausschalte, hab ich den Strom für das Infratec gesparrt.
Eines hab ich umgebaut, das heisst Trafo gegen ein Schaltnetzteil ersetzt, das brauch nun 0.9 Watt weniger.
Die beiden NUC und das PI3 sind auch am Infratec.
Wenn eines nicht erreichbar ist aber trotzdem läuft kann ich es so über das Infratec trotzdem ausschalten (NOT_AUS), oder neu starten.
Die start_fhem.cfg kann wenn alles stimmt automatisch oder auch manuel die normale fhem.cfg laden etc.
ist nur eine Ide.
Die Idee verstehe ich, eine solche Absicherung ist ja an sich ganz gut. Nur die Implementierung finde ich so nicht optimal. Das ist wie ein Program für eine CNC-Fräsmaschine zu schreiben um damit Frühstücksbröttchen aufzuschneiden. Geht bestimmt, ist aber ein overkill und das Ergebnis ist auch suboptimal.
Daher bezweifle ich, dass jemand so ein Modul je schreiben wird. Wer dazu in der Lage ist, wird vermuttlich gleich ein Script in Perl (oder sonst was) schreiben, der das gleiche tut, ohne gleich ein unnötiges Moloch hochzufahren. Solche Sicherheitsfunktionen müssen möglichst schlank implementiert werden und nichts unnötiges enthalten. Alles, was über ist, ist eine potentielle Fehlerquelle.
Guten Abend,
Zitat von: betateilchen am 17 Juni 2017, 19:02:03
Die configDB kann sowas von Haus aus.
Das klingt interessant, allerdings habe ich die Vorgehensweise noch nicht entdecken können?! Aktuell habe ich zwei FHEM-Ordner, aus welchen ich jeweils eine Instanze mit ConfigDB starte - könnte ich theoretisch beide Instanzen aus einem Ordner mit unterschiedlichen ConfigDBs starten? Wie könnte ich meine zweite ConfigDB migrieren?
Ronny
Gesendet von meinem SM-G935F mit Tapatalk
Ich verwende statt IP Adressen die DNS Namen, und den DNS Server kann ich leicht pflegen. Also wenn irgendwann ein Service auf ein System auf eine andere IP Adresse kommt, dann ändere ich das nur im DNS Server, achja und die Netzwerkkonfiguration aller Systeme mit DHCP. Da gibts dann zwar einen single point of failure, aber ohne dem geht sowieso gar nix
Sent from my iPad using Tapatalk
ZitatIch verwende statt IP Adressen die DNS Namen, und den DNS Server kann ich leicht pflegen
Dann müste FHEM die DNS Namen selber anpasssen können.
Das heist bei mir müsste FHEM dem der Fritzbox mitteilen welchen DNS Name das laufende FHEM hat und die die Portweiterleitungen auch so ändern können.
Wäre eine gute Sache.
Ich kenne die fritzbox nicht, aber ich denke das sind auch nichts anderes als configfiles, wo man sicher mit scripts arbeiten kann. Aber der DNS müsste ja nicht unbedingt auf der Fritzbox sein. Wobei ich das anders gemeint hatte, ich ändere nicht die Name, die sind fix, also z.b. fhem.meine.domain, aber die IP Adresse dahinter kann sich ändern.
Sent from my iPad using Tapatalk