Eine zweite FHEM Instanz auf einem Raspberry Pi oder Banana Pi einrichten

[NewRasPi]

und einen Tiefer?

Code Auswählen Erweitern

ls -l /opt/fhem2/

Das mit dem update geht nicht liegt eventuell an den Rechten?

Code Auswählen Erweitern

pi@bPi:/opt $ cd fhem
pi@bPi:/opt/fhem $ ls -l
insgesamt 600
drwxrwxrwx  2 fhem dialout   4096 Jan 21 21:04 backup
-rw-rw-rw-  1 fhem dialout 275283 Jan 21 21:04 CHANGED
-rw-rw-rw-  1 fhem dialout  39621 Jan 20 02:42 configDB.pm
drwxrwxrwx 40 fhem dialout   4096 Jul 14  2018 contrib
drwxrwxrwx  3 fhem dialout   4096 Jul 14  2018 demolog
drwxrwxrwx  4 fhem dialout   4096 Jul 14  2018 docs
drwxrwxrwx  6 fhem dialout  20480 Jan 17 11:03 FHEM
-rw-rw-rw-  1 fhem dialout  14346 Jan 22 10:23 fhem.cfg
-rw-rw-rw-  1 fhem dialout  19987 Okt  4 00:07 fhem.cfg.demo
-rwxrwxrwx  1 fhem dialout 155579 Jan 21 21:04 fhem.pl
drwxrwxrwx  2 fhem dialout   4096 Jan  1 00:00 log
-rw-rw-rw-  1 fhem dialout  39072 Jan 17 11:03 MAINTAINER.txt
drwxrwxrwx  2 fhem dialout   4096 Dez 15 18:13 mp3
-rw-rw-rw-  1 fhem dialout    935 Feb 19  2017 README_DEMO.txt
drwxrwxrwx  5 fhem dialout   4096 Jul 28 13:33 restoreDir
drwxrwxrwx  2 fhem dialout   4096 Jul 14  2018 unused
drwxrwxrwx  9 fhem dialout   4096 Jan  6 00:41 www
pi@bPi:/opt/fhem $ cd
pi@bPi:~ $ cd /opt/fhem2
pi@bPi:/opt/fhem2 $ ls -l
insgesamt 600
drwxrwxrwx  2 fhem dialout   4096 Jan 22 21:21 backup
-rw-rw-rw-  1 fhem dialout 275539 Jan 22 10:09 CHANGED
-rw-rw-rw-  1 fhem dialout  39621 Jan 20 02:42 configDB.pm
drwxrwxrwx 40 fhem dialout   4096 Jul 14  2018 contrib
drwxrwxrwx  3 fhem dialout   4096 Jul 14  2018 demolog
drwxrwxrwx  4 fhem dialout   4096 Jul 14  2018 docs
drwxrwxrwx  6 fhem dialout  28672 Jan 17 11:03 FHEM
-rw-rw-rw-  1 fhem dialout   7503 Jan 21 23:59 fhem.cfg
-rw-rw-rw-  1 fhem dialout  19987 Okt  4 00:07 fhem.cfg.demo
-rwxrwxrwx  1 fhem dialout 155579 Jan 21 21:32 fhem.pl
drwxrwxrwx  2 fhem dialout   4096 Jan 21 14:34 log
-rw-rw-rw-  1 fhem dialout  39072 Jan 17 11:03 MAINTAINER.txt
drwxrwxrwx  2 fhem dialout   4096 Dez 15 18:13 mp3
-rw-rw-rw-  1 fhem dialout    935 Feb 19  2017 README_DEMO.txt
drwxrwxrwx  5 fhem dialout   4096 Jul 28 13:33 restoreDir
drwxrwxrwx  2 fhem dialout   4096 Jul 14  2018 unused
drwxrwxrwx  9 fhem dialout   4096 Jan  6 00:41 www
pi@bPi:/opt/fhem2 $


Ich sehe keine Abweichungen in den beiden Verzeichnisen.

[NewRasPi]

Hallo
Das Update könnte ich natürlich auch auf der ersten Instanz durchführen und dann die neuen Dateien und Module in die zweite Instanz Fhem kopieren. Schön ist das aber nicht.
Grüße Elmar

[Otto123]

was sagt denn {qx(pwd)} in der FHEM Kommandozeile in beiden Instanzen?

Schreibt das Log was beim Update Befehl?
Mal verbose hoch gedreht?

[NewRasPi]

was sagt denn {qx(pwd)} in der FHEM Kommandozeile in beiden Instanzen?

Schreibt das Log was beim Update Befehl?
Mal verbose hoch gedreht?

Hallo Otto
{qx(pwd)}
auf dem ersten FHEM "/opt/fhem"
auf dem zweiten FHEM "/opt/fhem2"

Das mit dem Update Check muss ich noch mal gucken. Es zeigt nach dem umstellen auf verbose 5 ein anderes Verhalten!

[NewRasPi]

Ein Ausschnitt - das verbose 5 ist verdammt umfangreich!

Code Auswählen Erweitern

Control: max-age=0, no-cache, no-store, must-revalidate Pragma: no-cache Keep-Alive: timeout=5, max=99 Connection: Keep-Alive
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_multiple.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_noArg.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_slider.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_svg.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_textField.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/fhemweb_time.js ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/darktouchpadsvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/darktouchpadsvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios6touchpadsvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios6touchpadsvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios7touchpadsvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios7touchpadsvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/iostouchpadsvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/iostouchpadsvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/darksmallscreensvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/darksmallscreensvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios7smallscreensvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/ios7smallscreensvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/iossmallscreensvg_defs.svg ./unused
2019.01.22 22:27:14 4 : mv ./www/pgm2/iossmallscreensvg_style.css ./unused
2019.01.22 22:27:14 4 : mv ./FHEM/firmware/LaCrosseGateway.bin ./unused
2019.01.22 22:27:14 1 : nothing to do...
2019.01.22 22:27:14 4 : WEB: /fhem&fw_id=56&room=Unsorted&cmd=update / RL:1708 / text/html; charset=UTF-8 / Content-Encoding: gzip / Cache-Control: no-cache, no-store, must-revalidate


Hat die verbose Einstellung einen Einfluss auf Update? - ich hatte das als Report von FHEM gesehen.
Jetzt jedenfalls geht auf beiden Instanzen das Update.   

DANKESCHÖN
auch nach einem reboot starten beide Instanzen und auch beide melden zurück, beim "check update"
"nothing to do..."
Vielen Dank an alle die mir hiermit geholfen haben.
Schöne Grüße
Elmar

[Otto123]

Nein verbose bestimmt nur den Loglevel.

[NewRasPi]

Nein verbose bestimmt nur den Loglevel.

Hat dann Dein Befehl " {qx(pwd)}" den Knoten gelöst?
Falls man das "nachvollziehen" kann.
Grüße Elmar

[Otto123]

Nö {qx()} führt einen Befehl aus und schreibt die Antwort ins Browserfenster. pwd bestimmt den aktuellen Pfad. Ich wollte nur wissen ob beide Instanzen wirklich in ihrem Pfad laufen.

Vielleicht lag es einfach am zweiten Start. Blöd, aber wahrscheinlich nicht mehr nachvollziehbar.

Aber ich setz mich bestimmt mal hin und probier das aus. Mal sehen was da so passiert.

Gute Nacht
Otto

[Amenophis86]

Bin ich wohl zu früh ins Bett gegangen, dass es nun doch gelöst wurde

Dann haben wir das Problem ja gefunden, durch den Start per Hand. Deswegen war meine Überlegung auf systemd zu wechseln, da du eh schon Stretch nutzt. Aber egal, geht auch so weiterhin.

Ich habe übrigens bewusst das Verzeichnis kopiert und nicht beides über das selbe laufen lassen. Warum? Teilweise probiere ich in der zweiten Instanz Sachen aus, teilweise soll es dort ein Update geben vor der ersten um auf Fehler zu prüfen und so weiter. Es ist natürlich möglich mit nur einem Ordner alles laufen zu lassen aber man muss sich bewusst sein, ob man das auch so möchte.

Ansonsten danke für die ganzen Hilfen und Tipps

[NewRasPi]

Hallo Amenophis86, Otto und alle anderen Helfer
vielen Dank für die super Unterstützung.
Neugierig bin ich welche Instanz jetzt "Herr über die GPIO-Ports" ist. Zwischendurch kam mal der Hinweis das man diese beiden Instanzen per FHEM2FHEM zum auswerten oder nutzen der Device verbinden kann.
Die Trennung "nur" über ein zusätzliches Fhem- Perl- Sqript hätte mir auch nicht so gefallen. So lang der Platz auch für zwei sauber getrennte Verzeichnisse vorhanden ist traue ich dem mehr. Theoretisch kann ich jetzt ein Update immer erst mal als Testlauf auf der zweiten Instanz ausführen.
Der Hauptgrund ist aber immer noch der "Hürdenfreie Zugang" auf die Kamerabilder ohne Benutzer und Passwort Eingabe.
Dazu muss ich nur die umfangreichen Rechte der zweiten Instanz "begrenzen".
Schöne Grüße
Elmar 

[Amenophis86]

"Herr über die GPIO-Ports"

Was meinst du damit? Lässt du beide auf die Ports zugreifen? Würde mich für eine Entscheidung und die andere nicht zugreifen lassen. Generell gilt, dass beide FHEM Instanzen nicht zwei Dinge (CULs etc) gleichzeitig zugreifen sollten.

[Otto123]

Ein kleines HowTo
Mein erster Test für zweite Instanz. Keine separaten Pfade - alles läuft in einem Pfad!

Achtung! Jeder sollte wissen was er tut, ich garantiere für nix!!!

Nur 3 Zeilen für die FHEM Kommandozeile -> https://commandref.fhem.de/#command
Man braucht sein FHEM und den Browser nicht verlassen!

Frische fhem.cfg holen und unter fhem2.cfg speichern

Code Auswählen Erweitern

"wget -q -O fhem2.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg"
fhem2.cfg editieren, damit die Grundlegenden Dateien getrennt sind + initialUsbCheck ausschalten

Code Auswählen Erweitern

"sed -i -e 's/\/fhem/\/fhem2/;;s/\/eventTypes/\/eventTypes2/;;s/8083/8093/;;$aattr initialUsbCheck disable 1' fhem2.cfg"
FHEM starten

Code Auswählen Erweitern

"perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"

Die zweite "frische" Instanz läuft auf Port 8093 

Mit shutdown kann man die zweite Instanz separat beenden.
Mit shutdown der ersten Instanz (egal wie) wird die zweite mit beendet, da sie ein Kind Prozess der Hauptinstanz ist.
Mit einem notify in der ersten Instanz, kann man die 2 Instanz automatisch mit starten:

Code Auswählen Erweitern

define n_StartFhem2 notify global:INITIALIZED "perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"
Damit läuft auch ein restart ohne Probleme: beide Instanzen werden nacheinander neu gestartet.

Soweit ich das sehen kann nutzen beide Instanzen unterschiedliche CPUs

Gruß Otto

[NewRasPi]

Was meinst du damit? Lässt du beide auf die Ports zugreifen? Würde mich für eine Entscheidung und die andere nicht zugreifen lassen. Generell gilt, dass beide FHEM Instanzen nicht zwei Dinge (CULs etc) gleichzeitig zugreifen sollten.

Hallo Amenophis86
da ich ja die komplette fhem.cfg mitsamt dem Verzeichnis als Grundlage für die zweite Instanz genommen habe, habe ich auch erst mal alle Device aus der ersten Instanz. Fehler habe ich da noch keine gesehen. Einen CULs etc. habe ich nicht dran. Aber der MPD Musikplayer lässt sich jetzt von beiden FHEMs aus starten und beenden. Auf den GPIO Ports habe ich die Relaisplatine um den Verstärker abhänig vom MPD Status an oder aus zu schalten. Das schaltet ja ein DOIF in der ersten Instanz - geht also automatisch an und aus, auch wenn ich in der zweiten Instanz einschalte. Weitere GPIO-Ports schalten über die Relaisplatine auf welchen Raum die Lautsprecherkabel (Minus alle dauerhaft verbunden, Plus wird über Wechselrelais verteilt) Musik abspielen sollen.
Die noch als Reserve freien GPIOs sind jetzt auf beiden Instanzen "zugänglich".
@ Otto
bei dieser Lösung sind aber die Module nicht "geschützt" - also ein Update ändert ALLE Quell Dateien.
Schöne Grüße
Elmar

[fredl99]

@Otto123:
Genau so hab ich es weiter oben gemeint. Aber Du hast einen typo in Deinem sed-script: "evenTypes2"
Ohne init-script am System wird bei einem reboot natürlich überhaupt nichts passieren.

@NewRasPi:
Falls Du mit "mit einem separaten Verzeichnis wohler fühlen" den Sicherheitsaspekt gemeint hast, dann ist das ein trügerisches Gefühl. Dein zuletzt gezeigtes Setup wäre für einen ernstzunehmenden Angreifer ein offenes Scheunentor. Alle Dateien sind beschreibbar für jedermann (und das heißt unter Linux wirklich für jeden Weltbürger). Beschreibbar bedeutet auch lösch- und austauschbar. Nachdem einige Dateien (ebenfalls für jedermann) ausführbar sind, ist das ganze eine Startrampe für jedes erdenkliche Szenario.
Klar denkst Du jetzt, "wer soll denn einen fhem-Server angreifen". Leider sind die Angriffe, die man für ausgeschlossen hält, meistens die erfolgreichsten. Wenn Dir einer die Heizungen abregelt, ist es ein Lausbubenstreich. Wenn er über den kompromittierten Raspi Zugang zum restlichen Netzwerk erlangt oder ihn durch eine modifizierte fhem.pl zum Spam-Bot umbaut, wird's schon unangenehmer.

Man kann nur hoffen, daß Dein Raspi von außen gut geschützt ist, von sich aus ist er es so nicht.
Aus dieser Sicht ist der Passwort-Schutz des Web-UI ebenso trügerisch.

Da der ganze Aufwand nur für einen Web-Zugang ohne Passworteingabe gedacht war, sei gesagt daß Zugangsdaten auch über die URL mitgesendet werden können. Ich gehe davon aus, daß Du die URL am TV nicht manuell eintippst, sondern ein Lesezeichen gesetzt hast. Das könntest Du entsprechend erweitern.

[NewRasPi]

@NewRasPi:
Falls Du mit "mit einem separaten Verzeichnis wohler fühlen" den Sicherheitsaspekt gemeint hast, dann ist das ein trügerisches Gefühl. Dein zuletzt gezeigtes Setup wäre für einen ernstzunehmenden Angreifer ein offenes Scheunentor. Alle Dateien sind beschreibbar für jedermann (und das heißt unter Linux wirklich für jeden Weltbürger). Beschreibbar bedeutet auch lösch- und austauschbar. Nachdem einige Dateien (ebenfalls für jedermann) ausführbar sind, ist das ganze eine Startrampe für jedes erdenkliche Szenario.
Klar denkst Du jetzt, "wer soll denn einen fhem-Server angreifen". Leider sind die Angriffe, die man für ausgeschlossen hält, meistens die erfolgreichsten. Wenn Dir einer die Heizungen abregelt, ist es ein Lausbubenstreich. Wenn er über den kompromittierten Raspi Zugang zum restlichen Netzwerk erlangt oder ihn durch eine modifizierte fhem.pl zum Spam-Bot umbaut, wird's schon unangenehmer.

Man kann nur hoffen, daß Dein Raspi von außen gut geschützt ist, von sich aus ist er es so nicht.
Aus dieser Sicht ist der Passwort-Schutz des Web-UI ebenso trügerisch.

Da der ganze Aufwand nur für einen Web-Zugang ohne Passworteingabe gedacht war, sei gesagt daß Zugangsdaten auch über die URL mitgesendet werden können. Ich gehe davon aus, daß Du die URL am TV nicht manuell eintippst, sondern ein Lesezeichen gesetzt hast. Das könntest Du entsprechend erweitern.

Hallo fredl99

Danke für den Hinweis. Erst mal wollte ich das es läuft. Jetzt darf ich das natürlich auf bessere / weniger Rechte wieder zurück schrauben.

Zu dem URL Link mit Parametern für den TV: Das hatte ich versucht - die zig Varianten die mir bekannt sind gingen alle nicht.
Mit dem guten Gefühl wegen zwei getrennten Verzeichnissen. Ich als Linux Laie mogel mich da immer so mit durch. Wenn ich jetzt in einer Instanz einen Fehler mache, kann ich über SSH die hoffentlich unbeschädigten Datein auf dem gleichen Raspberry/ BananaPi wieder da hin kopieren wo es hackt.

Es freut mich sehr das die Spezialisten in diesem Forum auch bezüglich den Gefahren Tipps geben.
"Bringt" das schliessen aller Ports auf der Fritzbox nur eine trügerische Sicherheit?
Die einzigen Zugänge sind über VPN.
Schöne Grüße
Elmar