FHEM mit mehr Parametern starten

Begonnen von Loredo, 25 April 2019, 17:01:07

Vorheriges Thema - Nächstes Thema

Loredo

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).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

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

Loredo

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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#3
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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Ich habe den Patch nochmals überarbeitet.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

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

Loredo

#6
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?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

ZitatDas 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 :)

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

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

Loredo

Zitat von: rudolfkoenig am 26 April 2019, 11:52:29
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.


Zitat von: rudolfkoenig am 26 April 2019, 11:52:29
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?
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

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

betateilchen

Zitat von: rudolfkoenig am 26 April 2019, 12:47:24
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:

Zitat von: rudolfkoenig am 26 April 2019, 11:52:29
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.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

Zitat von: rudolfkoenig am 26 April 2019, 10:17:59
- 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 :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

Zitat von: betateilchen am 26 April 2019, 19:15:01
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.


Zitat von: betateilchen am 26 April 2019, 19:15:01
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.


Zitat von: betateilchen am 26 April 2019, 19:15:01
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.




Zitat von: betateilchen am 26 April 2019, 19:15:01
Lasst mich mal ein bisschen über das Thema nachdenken, ich melde mich.


Ganz großen Dank dafür, Udo!
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

betateilchen

#13
Zitat von: Loredo am 25 April 2019, 17:01:07
(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.

Zitat von: Loredo am 25 April 2019, 18:30:16
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 ?

Zitat von: Loredo am 27 April 2019, 11:36:59
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 :)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Loredo

Zitat von: betateilchen am 28 April 2019, 11:25:58
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.


Zitat von: betateilchen am 28 April 2019, 11:25:58
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.


Zitat von: betateilchen am 28 April 2019, 11:25:58
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).


Zitat von: betateilchen am 28 April 2019, 11:25:58

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


Zitat von: betateilchen am 28 April 2019, 11:25:58
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.


Zitat von: betateilchen am 28 April 2019, 11:25:58
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.


Zitat von: betateilchen am 28 April 2019, 11:25:58
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.


Zitat von: betateilchen am 28 April 2019, 11:25:58
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.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER