Neues Modul: 98_serviced.pm - systemd und initd Dienste steuern

DeeSPe · 22 Februar 2021, 12:22:13

Mon dennisk,

tut mir leid, irgendwie verstehe ich Dein Problem noch nicht.
"serviceSudo" hatte schon immer den Default-Wert 1.
Wenn "serviceSudo 1" (Standard) gesetzt ist und "serviceLogin" nicht mit "root" beginnt, wird "sudo" verwendet, sonst nicht, daran hat sich auch nichts geändert.
Laut Deiner Raw Def sieht doch alles gut aus!? "error none" und "state running". Wo ist das Problem?

Ich habe bei mir zusätzlich gerade Deine Def angelegt mit : "define sd serviced fhem".
Dann habe ich "verbos 5" gesetzt und man sieht im Log/Event-Monitor sehr schön wie das "shell command" aussieht was dann ausgeführt wird.
Hier direkt nach dem Definieren:

Code Auswählen

2021.02.22 11:02:21 5:  sd: serviced_Set executing shell command: sudo systemctl status fhem
2021-02-22 11:02:21 serviced sd state: status
2021.02.22 11:02:21 4:  sd: Service "fhem" is started
2021-02-22 11:02:21 serviced sd state: running

Und hier mit gesetztem "serviceSudo 0":

Code Auswählen

2021.02.22 11:03:09 5:  sd: serviced_Set executing shell command: systemctl status fhem
2021-02-22 11:03:09 serviced sd state: status
2021.02.22 11:03:09 4:  sd: Service "fhem" is started
2021-02-22 11:03:09 serviced sd state: running

Man sieht dass direkt nach dem Definieren noch "sudo" verwendet wird und nach Setzen von "serviceSudo 0" nicht mehr.
Ich habe auch noch einmal durch den Code geschaut und kann in den letzten beiden Commits keine Änderung der sudo-Zeile feststellen, lediglich in der Zeile davor habe ich die $login-Variable angepasst und um "servicePort" erweitert.

Gruß
Dan

dennisk · 22 Februar 2021, 14:08:22

Ich habs jetzt nochmal nachvollzogen. Wenn ich die aktuellste Version 98_serviced.pm aus dem SVN nehme, dann erhalte ich nach dem Restart folgendes im Log:

Code Auswählen

2021.02.22 13:53:57 1: PERL WARNING: Can't exec "sudo": Datei oder Verzeichnis nicht gefunden at /usr/share/fhem/FHEM/98_serviced.pm line 266, <$fh> line 322.
2021.02.22 13:53:57 1: PERL WARNING: Can't exec "sudo": Datei oder Verzeichnis nicht gefunden at /usr/share/fhem/FHEM/98_serviced.pm line 270, <$fh> line 322.
2021.02.22 13:53:57 1: PERL WARNING: Use of uninitialized value $ret in concatenation (.) or string at /usr/share/fhem/FHEM/98_serviced.pm line 326.
2021.02.22 13:53:57 3: eval: {serviced_ExecFinished('sd|1|')}
2021.02.22 13:53:57 3: sd: Error:

Diese Fehler sind vorher nicht aufgetreten und treten auch nicht auf, wenn ich 98_serviced.pm auf den Stand vor den beiden letzten Commits (@20536) zurücksetze.
Also muss es zumindest irgendwas mit diesen Änderungen zu tun haben. Hast Du eine Idee?

DeeSPe · 22 Februar 2021, 15:02:02

Ich habe nach wie vor keine Idee.

Nochmal langsam:
Du möchtest den Service "fhem" auf dem lokalen System überwachen!
Das soll ohne "sudo" passieren, richtig?

Kannst Du bitte bei dem entsprechenden FHEM Device "verbose 5" einstellen und im Event-Monitor mal den Filter auf den Namen von dem Device setzen. Dann mal bitte einen "get status" absetzen ohne gesetztes Attribut "serviceSudo" und einmal mit (auf 0) gesetztem Attribut. Die Ausgabe im Event-Monitor dann bitte hier posten.

Gruß
Dan

dennisk · 22 Februar 2021, 16:08:38

Ja genau, fhem.service wird unter dem Benutzer fhem gestartet. Über eine Polkit-Regel erteile ich dem Benutzer fhem die Berechtigung, den Systemd-Service fhem.service zu managen:

Code Auswählen

polkit.addRule(function(action, subject) {
    if (action.id == "org.freedesktop.systemd1.manage-units") {
        if (action.lookup("unit") == "fhem.service") {
            var verb = action.lookup("verb");
            if (verb == "start" || verb == "stop" || verb == "restart") {
                if (subject.user == "fhem") {
                    return polkit.Result.YES;
                }
            }
        }
    }
});

Beim Versuch, das Ganze jetzt nochmal nachzustellen, habe ich gesehen, dass jetzt kein Fehler mehr auftritt

Jetzt bin ich verwirrt. Vielleicht beobachte ich das einfach mal und melde mich dann nochmal, falls es wieder auftritt?
Tut mir leid, wenn ich jetzt für zusätzliche Arbeit gesorgt habe.

DeeSPe · 25 Februar 2021, 11:28:48

Zitat von: dennisk am 22 Februar 2021, 16:08:38
Ja genau, fhem.service wird unter dem Benutzer fhem gestartet. Über eine Polkit-Regel erteile ich dem Benutzer fhem die Berechtigung, den Systemd-Service fhem.service zu managen:
Code Auswählen Erweitern
polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.systemd1.manage-units") { if (action.lookup("unit") == "fhem.service") { var verb = action.lookup("verb"); if (verb == "start" || verb == "stop" || verb == "restart") { if (subject.user == "fhem") { return polkit.Result.YES; } } } } });

Beim Versuch, das Ganze jetzt nochmal nachzustellen, habe ich gesehen, dass jetzt kein Fehler mehr auftritt
Jetzt bin ich verwirrt. Vielleicht beobachte ich das einfach mal und melde mich dann nochmal, falls es wieder auftritt?
Tut mir leid, wenn ich jetzt für zusätzliche Arbeit gesorgt habe.

Funktioniert es nun wie gewünscht?
Wenn ja, könntest Du bitte kurz erläutern was die Lösung war?

Danke.

Gruß
Dan

dennisk · 26 Februar 2021, 20:02:10

Ich muss leider sagen, ich habe nichts geändert und auf einmal hat es wieder ohne Fehlermeldung funktioniert. Ich kann wirklich nicht sagen, was das Problem war. Und ja, es funktioniert "wieder" wie gewünscht. Sorry nochmal für den Aufruhr...und vielen Dank für die schnelle Reaktion!

RockFan · 02 März 2021, 12:02:16

Hallo,

erstmal vielen Dank für das Modul

!

Seit Anfang Januar verwende ich es, um auf einem weiteren Raspi den tvheadend-Service zu überwachen. Funktioniert soweit auch prima. Nun habe ich - ich meine seit meinem letzten FHEM-Update am 28.Februar - plötzlich das Problem, dass immer, wenn FHEM startet (z.B. nach einem Update, aber auch nach einem Reboot), folgender Fehler im Log erscheint und der Status des Service auf error geht.

Code Auswählen


2021.03.02 11:23:58 3: tvheadend_service: Error: Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die Regeln erklÃ¤rt hat. Normalerweise lÃ¤uft es auf drei Regeln hinaus: #1) Respektieren Sie die PrivatsphÃ¤re anderer. #2) Denken Sie nach, bevor Sie tippen. #3) Mit groÃŸer Macht kommt groÃŸe Verantwortung. sudo: Kein TTY vorhanden und kein Â»askpassÂ«-Programm angegeben

Wenn ich den Status des Services neu abfrage (get status oder automatisch nach 5 Minuten) passt wieder alles. Vor dem Update letzten Sonntag hatte ich das Problem noch nicht (muss natürlich nicht zwangsläufig heißen, dass das Problem an der neuen Version von serviced liegt

)

Irgendeine Idee?

Viele Grüße
Dieter

Wernieman · 02 März 2021, 13:19:36

Hast Du die sudoers config des Ziels angepasst? Dann ist sie eventuell beim Update etwas kaput gegangen.

Code Auswählen

sudo: Kein TTY vorhanden und kein Â»askpassÂ«-Programm angegeben
Hier möchte sudo ein Passwort, kann es aber nicht abfragen.

Eigentlich darf es anschließend nicht funktionieren .... liegt also nicht an FHEM sondern an der Config des Systemes (besonders sudo)

RockFan · 02 März 2021, 15:32:51

Ich bin bzgl. Linux ein ziemlicher Rookie. Auch wenn ich mich durch FHEM über viele Jahre damit ein wenig beschäftige, bleibt mein Wissen immer etwas oberflächlich

Der User mit dem ich auf dem Ziel-Raspi den tvheadend-Service überwache ist "pi". In der sudoers auf diesem Raspi steht u.a. "pi ALL=(ALL) NOPASSWD: ALL".

Was mich eben nach wie vor stutzig macht sind die Tatsachen, dass es
1. zwischen der Einrichtung meiner Überwachung im Januar und dem FHEM-Update am Sonntag, trotz einiger FHEM-Neustarts diese Meldung nicht gab und
2. reproduzierbar nach einer erneuten Statusabfrage die Abfragen wieder problemlos funktionieren (bis zum nächsten Start von FHEM)

Otto123 · 02 März 2021, 16:33:52

ZitatAbfragen

Du meinst Status? status erfordert kein sudo
Laut gedacht: Oder wird jetzt aus irgendwelchen Gründen lokal versucht mit sudo ssh zu machen? Das kann aber nur Dan erklären. Er hat ja ev. was verändert.

@RockFan Wenn Du mal in ins restoredir schaust: https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Und einfach die alte 98_serviced.pm wieder zurückholst?

RockFan · 02 März 2021, 18:04:09

Genialer wie ebenso einfacher Tipp

Der Restore über die FHEM Oberfläche hat zwar nicht geklappt (die Funktion kannte ich noch gar nicht im Detail), da die einzelnen PM-Module gar nicht gefunden wurden. Aber auf Dateiebene habe ich dann die einzelnen Dateien gefunden und habe die Vorgängerversion des Moduls zurückkopiert.
Und siehe da: Nach "shutdown restart" ist wieder alles in Ordnung. Keine Meldung mehr und der Status des Service entspricht dem tatsächlichem Status ("running").

Nun denke ich, dass sich doch irgend etwas in der letzten Version eingeschlichen hat

Natürlich bräuchte man für die Statusabfrage kein sudo. Aber mit dem Modul kann ich eben auch den Service neu starten, wenn er nicht läuft. Das Modul wird sicherlich nicht unterscheiden, wann es sudo bräuchte und wann nicht (nehme ich mal an).

Viele Grüße
Dieter

DeeSPe · 02 März 2021, 18:19:42

Zitat von: Otto123 am 02 März 2021, 16:33:52
Du meinst Status? status erfordert kein sudo
Laut gedacht: Oder wird jetzt aus irgendwelchen Gründen lokal versucht mit sudo ssh zu machen? Das kann aber nur Dan erklären. Er hat ja ev. was verändert.

@RockFan Wenn Du mal in ins restoredir schaust: https://wiki.fhem.de/wiki/Update#R.C3.BCcksichern_beim_Update_.C3.BCberschriebener_Dateien
Und einfach die alte 98_serviced.pm wieder zurückholst?

Ich hatte im letzten Update einen kleinen Fehler korrigiert, der dafür gesorgt hat dass der Status beim ersten Definieren nicht abgerufen wurde.
Evtl. macht das bei Dir dann beim Start von FHEM Probleme.

Es wäre nett wenn Du das mit der angehängten Version noch einmal testen könntest.
Danke.

Gruß
Dan

EDIT: Test Modul entfernt!

RockFan · 02 März 2021, 19:10:13

Danke Dan!

Prima! Mit der Testversion von Dir funktioniert es.

Viele Grüße
Dieter

DeeSPe · 02 März 2021, 19:39:15

Zitat von: RockFan am 02 März 2021, 19:10:13
Danke Dan!

Prima! Mit der Testversion von Dir funktioniert es.

Viele Grüße
Dieter

Danke für's Testen Dieter!
Ich habe den Fix soeben mit v1.2.7 im SVN eingecheckt.

Gruß
Dan

RockFan · 03 März 2021, 09:07:54

Guten Morgen Dan,

leider unterscheiden sich die Testversion 1.2.7 von gestern Abend und die 1.2.7 in SVN, die ich gerade über update erhalten habe (ich habe die Dateien verglichen). Mein Problem ist somit wieder da.
Kannst Du das bitte nochmal prüfen.

Viele Grüße
Dieter