Autor Thema: FHEM mit mehr Parametern starten  (Gelesen 1155 mal)

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
FHEM mit mehr Parametern starten
« am: 25 April 2019, 17:01:07 »
Gibt es die Möglichkeit, dass ich FHEM statt nur mit "perl fhem.pl fhem.cfg" mit noch mehr Parametern starte?
Aktuell wäre es praktisch dort auf der Kommandozeile Dinge wie nofork=1 setzen bzw. forcieren zu können. Natürlich sollten diese Attribute dann auch entsprechend im Global Device angezeigt werden.
Dort könnte man sie dann natürlich verändern, aber jene Änderung wäre dann nicht dauerhaft (read-only Attribute gibt es ja derzeit nicht).
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:FHEM mit mehr Parametern starten
« Antwort #1 am: 25 April 2019, 17:30:06 »
Zitat
Gibt es die Möglichkeit, dass ich FHEM statt nur mit "perl fhem.pl fhem.cfg" mit noch mehr Parametern starte?
Wenn man in fhem.pl nach ARGV sucht, dann sieht man dass folgende Optionen moeglich sind:
-d setzt $fhemdebug, und damit verbose=5 und logfile=-, was wiederum nofork=1 beinhaltet.
-i und -u wird fuer Windows Service Installation bzw. Deinstallation verwendet

Sonst: bei mehr als einem Kommandozeilen-Parameter wird fhem.pl als Client gestartet, und uebermittelt die Argumente einzeln mit Newline als Befehl an dem Server.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #2 am: 25 April 2019, 18:30:16 »
Hm, ließe sich das erweitern?


-d hilft nicht, weil verbose=5 stören würde und logfile erhalten bleiben müsste (letzteres wäre aber auch nett überschreiben zu können).
Irgendwie wäre es gut, wenn man alle Parameter, die das Start- und Laufzeitverhalten unmittelbar beeinflussen, auch als Parameter angeben könnte und nicht der Client Status gestartet würde.
  • pidfilename
  • logfile
  • nofork
Ich frage auch gar nicht für mich, sondern für Nutzer von configDB im FHEM Docker Container, deren Leben man damit einfacher gestalten könnte. Muss aber auch nicht sein.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #3 am: 25 April 2019, 20:37:30 »
Ich hätte da einen Patchvorschlag anbei.
Das bisherige Verhalten bleibt bestehen. Man kann bei normalem Start nun aber auch key=value Parameter hinzufügen, die als globale Attribute gewertet werden und schreibgeschützt sind.


EDIT: Patch überarbeitet, um ENV Variable FHEM_STARTPARAMS zu nutzen.
« Letzte Änderung: 02 Mai 2019, 09:00:02 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #4 am: 26 April 2019, 10:16:24 »
Ich habe den Patch nochmals überarbeitet.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:FHEM mit mehr Parametern starten
« Antwort #5 am: 26 April 2019, 10:17:59 »
Zitat
Ich frage auch gar nicht für mich, sondern für Nutzer von configDB im FHEM Docker Container, deren Leben man damit einfacher gestalten könnte.
Mir fehlt die eigentliche Begruendung fuer diesen Aenderungswunsch, bzw. ich sehe das Problem nicht.

Ich vermute folgende Gedankenkette:
- configDB wurde "erfunden", damit unbedarfte Benutzer die Konfiguration nicht direkt editieren
- nun fehlt aber genau das, man baut also andere Wege ein
Ich meine in diesem Fall waere auch gangbar die verwendete Konfiguration (fhem.cfg / configDB.db) im docker Image angepasst auszuliefern, nach dem ersten Speichern wuerden diese Werte auch mit dem Patch da landen.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #6 am: 26 April 2019, 10:25:50 »
Nein.

Die Schwierigkeit besteht vor allem darin, dass das Startup Verhalten im Docker Image nur mit nofork=1 läuft.
Wenn nun jemand mit einer bestehenden FHEM Installation, die zuvor außerhalb von Docker betrieben wurde, diese Konfiguration in den Docker Container läd, dann wird vom Startup Script automatisch nofork=1 gesetzt, damit FHEM überhaupt hochkommt. Das funktioniert aber bei configDB nicht, weil ich dort nicht einfach in einer Datei einen Wert ersetzen kann. Die Folge ist, dass Benutzer zuvor diesen Parameter in der noch ohne Docker laufenden FHEM Installation ändern müssen, damit diese Änderung dann auch in der configDB Datenbank mit drin ist. Außerdem ist der Benutzer dann dafür verantwortlich, dass Attribute wie pidfilename und logfile mittels Umgebungsvariable dem Docker Container bekannt gemacht werden, wenn diese globalen Attribute nicht mehr dem Auslieferungszustand entsprechen. Tut er das nicht, gibt es nicht das richtige Verhalten und es gibt keinen Weg für den Benutzer zu erkennen wieso. Er muss von selbst darauf kommen und die README.md aufmerksam genug gelesen haben.

Es bleibt die Gefahr, dass der Benutzer jederzeit auf die Idee kommen könnte das nofork Attribut zu löschen und FHEM dann nicht mehr startet, da nur bei Verwendung von fhem.cfg dieser Parameter wieder korrigiert werden kann.




Ich sehe noch einen weiteren Vorteil der Startparameter: Man kann bestimmte Einstellungen (temporär) überschreiben, ohne das fhem.cfg File anzufassen. Außerdem kann man verhindern, dass bestimmte globale Attribute aus FHEM heraus änderbar sind, da sie im Zweifel von root während des Starts fest vorgegeben sind. Das hat auch einen Sicherheitsaspekt.




Für mich stellt sich hier nicht die Frage "warum implementieren", sondern "warum nicht implementieren"? Was spricht denn dagegen?
« Letzte Änderung: 26 April 2019, 10:57:07 von Loredo »
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:FHEM mit mehr Parametern starten
« Antwort #7 am: 26 April 2019, 11:52:29 »
Zitat
Das funktioniert aber bei configDB nicht, weil ich dort nicht einfach in einer Datei einen Wert ersetzen kann.
Habe also doch richtig geraten :)
Und "nicht einfach" ist ja nicht "unmoeglich", mit sqlite3 kann man Befehle auch absetzen :)

Zitat
Es bleibt die Gefahr, dass der Benutzer jederzeit auf die Idee kommen könnte das nofork Attribut zu löschen und FHEM dann nicht mehr startet, da nur bei Verwendung von fhem.cfg dieser Parameter wieder korrigiert werden kann.
Meines Wissens bietet configDB dafuer auch Loesungen an.
nofork in die Liste der nicht aenderbaren globaen Attribute aufzunehmen waere deutlich weniger Aufwand.

Zitat
Was spricht denn dagegen?
Featuritis, Dokumentation, Wartbarkeit, und dass ich nicht betateilchens Absicht sabotieren will.Aber wenn er keine Alternative hat, kann ich das einbauen.

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #8 am: 26 April 2019, 12:15:02 »
Habe also doch richtig geraten :)


Kaum. Es geht darum, dass ich über die Startparameter in der Lage bin Einstellungen zu forcieren. Das ist auch unabhängig von configDB sinnvoll, weshalb habe ich oben beschrieben. Ich sehe auch nicht, dass man configDB damit den Wind aus den Segeln nehmen würde - ganz im Gegenteil, die Meldungen für das Docker Image beweisen ja, dass Menschen configDB verwenden wollen und es kann nur förderlich sein, wenn man den Umgang mit configDB so einfach wie möglich gestaltet.


Und "nicht einfach" ist ja nicht "unmoeglich", mit sqlite3 kann man Befehle auch absetzen :)


Grundsätzlich nicht, aber fehlerträchtig und in meinen Augen sehr viel komplexer als die paar Zeilen Perl Code in fhem.pl, die ich wesentlich wartungsfreundlicher finde. Ich empfinde es immer als "Hack", wenn man um etwas herum programmieren muss, wenn die Lösung an anderer Stelle kürzer und auch offensichtlicher wäre.


Siehst du denn bei dir viel Aufwand, nachdem du die Zeilen übernommen hättest?
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20459
Antw:FHEM mit mehr Parametern starten
« Antwort #9 am: 26 April 2019, 12:47:24 »
Zitat
Siehst du denn bei dir viel Aufwand, nachdem du die Zeilen übernommen hättest?
Den Patch werde ich nicht uebernehmen:
- wenn ich es supporten muss, dann muss ich es geschrieben haben, sonst weiss ich in ein/zwei Jahren nicht mehr, wozu das gut sein soll.
- die Pruefung auf = ist gefaehrlich, da es Client Aufrufe mit einem = (die durchaus moeglich sind) sabotiert.

Weiterhin gehoert noch Doku dazu, und ich muss sie gegen Andere verteidigen, insb. ist betateilchen laut bei neuen Features.

Wie geschrieben, ich baue was Vergleichbares ein, wenn betateilchen keine Alternative hat.

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15910
  • s/fhem\.cfg/configDB/g
Antw:FHEM mit mehr Parametern starten
« Antwort #10 am: 26 April 2019, 19:15:01 »
Wie geschrieben, ich baue was Vergleichbares ein, wenn betateilchen keine Alternative hat.

Ich bin seit heute in Urlaub. Lasst mich mal ein bisschen über das Thema nachdenken, ich melde mich.

Was ich auf jeden Fall problemlos umsetzbar finde:

nofork in die Liste der nicht aenderbaren globaen Attribute aufzunehmen waere deutlich weniger Aufwand.

Grundsätzlich: lasst uns bitte nicht auf Umwegen hochkomplexe Dinge einbauen, die dazu führen, das Startverhalten von FHEM zu ändern, ohne dass dann auf einen Blick nachvollziehbar wird, warum sich FHEM gerade "speziell" verhält. Das wird auf Dauer nicht mehr supportbar.

Wenn es darum geht, in bestimmten Fällen bestimmte Einstellungen zu erzwingen (die Notwendigkeit dafür kann ich mir durchaus vorstellen) dann gibt es dafür sicher andere Wege als das im Startaufruf von FHEM zu hinterlegen. Dann müssten ja ggf. auch wieder startup-Skripte uvm. angepasst werden.

configDB bietet von Haus aus schon die Möglichkeit, bestimmte Parameter beim Start zu setzen (z.B. den "rescue mode" oder "starten ohne statefile zu lesen"). Mir wäre es lieber, wenn wir auf diese Mechanismen zurückgreifen würden. Man könnte z.B. den "docker-mode" z.B. im config-File für configDB festlegen und dafür sorgen, dass dann entsprechende Attribute global automatisch gesetzt werden.

Aber wie gesagt - das sind gerade spontane erste Gedanken nach dem Lesen des Threads. Ich glaube, die fhem.pl muss dafür nicht angefasst werden.

-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15910
  • s/fhem\.cfg/configDB/g
Antw:FHEM mit mehr Parametern starten
« Antwort #11 am: 26 April 2019, 19:19:29 »
- configDB wurde "erfunden", damit unbedarfte Benutzer die Konfiguration nicht direkt editieren

das ist nur einer der Gründe für die "Erfindung" - aber bei weitem nicht der (für mich) wichtigste :)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #12 am: 27 April 2019, 11:36:59 »
Grundsätzlich: lasst uns bitte nicht auf Umwegen hochkomplexe Dinge einbauen, die dazu führen, das Startverhalten von FHEM zu ändern, ohne dass dann auf einen Blick nachvollziehbar wird, warum sich FHEM gerade "speziell" verhält. Das wird auf Dauer nicht mehr supportbar.


Ich kann ehrlich gesagt nicht erkennen, was hieran "hoch komplex" sein soll - wir reden nicht von Raketenwissenschaft. Auch wird am bisherigen Startverhalten kein Stück verändert, es wird nur genau eine einzige neue Funktion hinzugefügt.
Dass sich FHEM beim Starten "speziell" verhält, haben wir heute schon - nämlich beispielsweise beim Docker Image. Nur ist es dort eben ein Hack und noch dazu ein schlechter, denn er ist nicht offiziell von FHEM supportet (wie ich hier auch an der Diskussion erkenne).


Ich bin nach wie vor der Ansicht, dass es sinnvoll ist, as Startverhalten komplett auch während es eigentlichen Startvorgangs "von oben herab" zu steuern und durchzudrücken. Alles bisher gehörte ist da für mich kein vollwertiger Ersatz und nur Stückwerk.


Wenn es darum geht, in bestimmten Fällen bestimmte Einstellungen zu erzwingen (die Notwendigkeit dafür kann ich mir durchaus vorstellen) dann gibt es dafür sicher andere Wege als das im Startaufruf von FHEM zu hinterlegen. Dann müssten ja ggf. auch wieder startup-Skripte uvm. angepasst werden.


Genau darum geht es: Es soll von innerhalb FHEM unmöglich sein, diese Einstellungen  zu ändern oder zu überschreiben. Alles, was wir nicht über die Startparameter abhandeln, kann wieder abgeändert werden, um Zweifel durch editieren der fhem.cfg. Ich finde das Konzept von Startparametern ist seit Dekaden bewährt und aus gutem Grund, weshalb das für FHEM nicht passen soll, verstehe ich eben nicht.
Wir reden hier ja auch keinesfalls davon, dass Startscripts angepasst werden müssen - aber eben können! Es ändert sich rein überhaupt gar nichts für bestehende und auch neue Installationen - es sei denn, man möchte das explizit und dafür muss der User selbst tätig werden.


Man könnte z.B. den "docker-mode" z.B. im config-File für configDB festlegen und dafür sorgen, dass dann entsprechende Attribute global automatisch gesetzt werden.


Den Impuls zu diesem Gedanken verstehe ich. Jedoch ist das wieder in einer Datei, die der Benutzer abändern kann. Ja, ein Startscript kann die Änderung wieder rückgängig machen, aber ist das dann Sinn der Sache?
Den Startparameter im Startscript kann der Benutzer nur als root ändern, aber nicht als User "fhem". Im Falle von Docker auch nur, bis der Container einmal erneuert wird.


Ich möchte da auch gar keinen speziellen Docker Modus on configDB sehen, das ist mir eine viel zu große Abhängigkeit. Es sind ja alle Werkzeuge schon vorhanden und wenn man meinen Patchvorschlag einmal ausprobiert sieht man auch, dass das problemlos funktioniert. Ich habe nichts dagegen, dass Rudi den Patch nochmals in seinen eigenen "Worten" verfasst, das kann ich sogar sehr gut verstehen.


Was ich nur nicht in meine Birne hinein gehämmert bekomme ist, warum auf Biegen und Brechen immer vermieden werden soll fhem.pl anzufassen, wenn es um ein zentrales Thema wie das Startverhalten geht. configDB ist hier nur ein Beispiel, aber auch ansonsten finde ich es sinnvoll im Sinne von Security Hardening die Möglichkeit zu haben, dass man Einstellungen als "root" vorgibt und es dem "fhem" Benutzer unmöglich ist diese zu missachten.




Lasst mich mal ein bisschen über das Thema nachdenken, ich melde mich.


Ganz großen Dank dafür, Udo!
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15910
  • s/fhem\.cfg/configDB/g
Antw:FHEM mit mehr Parametern starten
« Antwort #13 am: 28 April 2019, 11:25:58 »
(read-only Attribute gibt es ja derzeit nicht).

Das ist nicht ganz richtig. Es gibt schon einen Mechanismus in fhem.pl, der das Löschen bestimmter Attribute verhindert. Auch eine Ausschlußliste für Attribute, die nicht mit gesichert werden, ist bereits vorhanden. Damit auch das Verändern zu unterbinden wäre vermutlich nur eine kleine Änderung.

Ich frage auch gar nicht für mich, sondern für Nutzer von configDB im FHEM Docker Container,

Wenn ich das richtig verstehe, betrifft die eigentliche Aufgabe aber nicht nur diese spezielle Kombination (configDB + Docker) sondern auch die Anwender von fhem.cfg+Docker ?

Genau darum geht es: Es soll von innerhalb FHEM unmöglich sein, diese Einstellungen  zu ändern oder zu überschreiben.
...
Jedoch ist das wieder in einer Datei, die der Benutzer abändern kann.
...
Ich möchte da auch gar keinen speziellen Docker Modus on configDB sehen, das ist mir eine viel zu große Abhängigkeit.
...
configDB ist hier nur ein Beispiel, aber auch ansonsten finde ich es sinnvoll im Sinne von Security Hardening die Möglichkeit zu haben, dass man Einstellungen als "root" vorgibt und es dem "fhem" Benutzer unmöglich ist diese zu missachten.

Nach einigem Nachdenken bin ich zu folgendem Standpunkt gekommen.

  • wenn es eine spezielle Anforderung gibt, die NUR die Anwender von configDB betrifft, dann sollte eine solche Anforderung auch innerhalb von configDB erfüllt werden und nicht in fhem.pl
  • betrifft eine Anforderung alle Anwender, dann sollte ein zentraler Mechanismus geschaffen werden, der dann wiederum so gestaltet wird, dass er beide Konfigurationsvarianten unterstützt. Diesbezüglich hat die Kooperation zwischen Rudi und mir in der Vergangenheit gut funktioniert.

Was ich jetzt im konkreten Fall "Docker" noch nicht verstanden habe: Wie wird die Aufgabenstellung bei Anwendern mit fhem.cfg gelöst?

Meine Meinung zum Thema Startparameter ist unverändert geblieben. Das Verhalten von fhem.pl ist an der Stelle - teilweise auch historisch gewachsen - recht empfindlich, wie Rudi ja schon am Beispiel "client Aufruf mit zulässigem = als Parameter" erwähnte. Man müsste dann vermutlich auch noch an andere Dinge denken, z.B. "wie verhält sich FHEM dann bei einem 'shutdown restart'?"

Ob ein Anwender die Konfigurationsdatei von configDB nur als root ändern kann oder auch als Benutzer fhem ist eine Frage, die sich mit Linux Bordmitteln lösen lässt. Und wenn Anwender auf die Idee kommen, ein Startskript, das von root erstellt wurde, bezüglich seiner Rechte so zu verändern, dass es chmod=777 bekommt, hast Du darauf auch keinen Einfluss mehr und Dein Sicherheitsaspekt ist bedeutungslos geworden. Ja - der Benutzer ist für die Folgen selbst verantwortlich, aber wir haben doch hier im Forum schon oft genug die Erfahrung gemacht, dass User wider besseren Wissens genau solche "Lösungen" wählen, um überhaupt irgendwas zum Laufen zu bringen, weil sie einfach nicht verstehen, was sie da tun.

Zusammengefaßt kann ich - ehrlich gesagt - bisher immer noch keinen wirklichen Grund erkennen, warum man FHEM mit weiteren (beliebigen / beliebig vielen) Startparametern aufrufen können soll. Wenn es wirklich etwas gibt, was man FHEM beim Start unbedingt mitteilen müsste, kann man immer noch über die Verwendung von Umgebungsvariablen nachdenken und diese dann innerhalb der fhem.pl auswerten.



Viele Grüße aus dem sonnigen Serbien, wo erst heute Ostersonntag ist :)
« Letzte Änderung: 28 April 2019, 11:29:49 von betateilchen »
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg-Stammtisch: 14.06.2019

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3458
  • ~ Challenging Innovation ~
Antw:FHEM mit mehr Parametern starten
« Antwort #14 am: 02 Mai 2019, 09:13:47 »
Das ist nicht ganz richtig. Es gibt schon einen Mechanismus in fhem.pl, der das Löschen bestimmter Attribute verhindert.


Genau an der Stelle hat mein Patch auch angesetzt, ich habe den "Mechanismus" dort also durchaus "nur" erweitert - sprich die "kleine Änderung", die du ansprichst, habe ich im Patch schon vorgeschlagen.


Auch eine Ausschlußliste für Attribute, die nicht mit gesichert werden, ist bereits vorhanden.


Die Attribute sollen ja durchaus mitgesichert werden, das ist kein Problem. An dieser Stelle braucht es keine Änderung.


Wenn ich das richtig verstehe, betrifft die eigentliche Aufgabe aber nicht nur diese spezielle Kombination (configDB + Docker) sondern auch die Anwender von fhem.cfg+Docker ?


Richtig. Der aktuelle Workaround die fhem.cfg mittels sed bei jedem Start zu Patchen ist ein Hack.
Außerdem gibt es gewiss auch Nutzer, die in ihrem /etc/init.d/fhem Script Startparameter setzen würden, wenn sie wüssten, dass es geht und dass es ihnen ggf. in einigen Belangen mehr Betriebssicherheit bringt. Das kann man schlecht vorausahnen, da ohne diese Möglichkeit eben oftmals auch niemand auf die Idee kommt, dort etwas zu tun (Henne <> Ei).


  • betrifft eine Anforderung alle Anwender, dann sollte ein zentraler Mechanismus geschaffen werden, der dann wiederum so gestaltet wird, dass er beide Konfigurationsvarianten unterstützt. Diesbezüglich hat die Kooperation zwischen Rudi und mir in der Vergangenheit gut funktioniert.


Ihr dürft natürlich gerne wieder die Köpfe zusammenstecken, ich dachte aber, ich hätte euch die "Arbeit" schon abgenommen.


Was ich jetzt im konkreten Fall "Docker" noch nicht verstanden habe: Wie wird die Aufgabenstellung bei Anwendern mit fhem.cfg gelöst?


Ich verstehe die Frage nicht? Ganz gleich, ob ich nun configDB oder fhem.cfg verwende, ein Startparameter hat einfach _immer_ Vorrang. Wenn ich das so mache, dann habe ich auch zukünftig am wenigsten Abhängigkeiten.


Meine Meinung zum Thema Startparameter ist unverändert geblieben. Das Verhalten von fhem.pl ist an der Stelle - teilweise auch historisch gewachsen - recht empfindlich, wie Rudi ja schon am Beispiel "client Aufruf mit zulässigem = als Parameter" erwähnte.


Das verstehe ich. Ich denke aber auch, dass ich das soweit korrekt berücksichtigt habe. Die RegEx kann man ja auch noch entsprechend ausweiten - es geht ja auch nur um den allerersten Parameter. Wenn der nicht im Format m/[a-z0-9]+=[a-z0-9]+/i ist, dann ist es wohl ein Client Kommando.


Ob ein Anwender die Konfigurationsdatei von configDB nur als root ändern kann oder auch als Benutzer fhem ist eine Frage, die sich mit Linux Bordmitteln lösen lässt.


Es geht nicht darum etwas mit Linux Boardmitteln zu lösen.


Wenn es wirklich etwas gibt, was man FHEM beim Start unbedingt mitteilen müsste, kann man immer noch über die Verwendung von Umgebungsvariablen nachdenken und diese dann innerhalb der fhem.pl auswerten.


Wenn ihr denkt, dass es über Umgebungsvariablen sicherer ist, ist das auch ein Weg. Ich habe den Patch oben entsprechend angepasst. In der Tat hilft es auch für das "shutdown restart" Verhalten, bisher hatte ich nur "rereadcfg" berücksichtigt.


Funktional ist der Patch damit für mich brauchbar, aber Rudi kann ihn natürlich so umschreiben, dass es seine Sprache ist.
FHEM-Module: ENIGMA2, GEOFANCY, PHTV, RESIDENTS, ROOMMATE, GUEST, HP1000, Pushover, THINKINGCLEANER, Wunderground | FHEM-Befehl: msg

FHEM-Docker auf Intel NUC mit Proxmox VE
Homematic via HMCCU, Hue Color Bulbs, LG OLED 65C8, Sonos Playbar+2xOne+Sub, 2x Sonos One, 1x Sonos Play:1

 

decade-submarginal