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

Begonnen von DeeSPe, 22 November 2017, 01:03:15

Vorheriges Thema - Nächstes Thema

DeeSPe

Zitat von: dennisk am 16 November 2019, 09:10:44
Hallo @DeeSPe,

vielen Dank für Dein sehr praktisches Modul!
Ich habe aber einen kleinen Fehler gefunden:
In Zeile 152 lautet der Code: my $sudo = AttrNum($name,"serviceSudo",1) || $login !~ /^root@/ ? "sudo " : "";
Damit funktioniert die Verwendung ohne sudo nicht, trotz gesetztem Attribut serviceSudo.
Nach minimaler Änderung der Zeile: my $sudo = AttrNum($name,"serviceSudo",1) || $login =~ /^root@/ ? "sudo " : "";
funktioniert das Modul auch ohne sudo. Aus meiner Sicht schlüssig, da die Überprüfung im ternären Operator nur dann sudo ergeben müsste, wenn $login root enthält.

Vielen Dank schon mal!

Irgendwie war ich heute früh noch nicht ganz wach und habe mich irgendwie von Deinem Argument täuschen lassen.
Es war schon richtig so wie es vorher (ohne Deine Änderung) war. Wenn Du schon root bist, benötigst Du doch kein sudo. Es wird nur benötigt wenn man eben kein root ist.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

dennisk

OK, stimmt, wenn ich jetzt drüber nachdenke, hast Du natürlich Recht, sorry
Dennoch funktioniert bei mir die Nutzung ohne sudo wirklich nur mit der Änderung. Mein FHEM wird jedenfalls nicht unter root gestartet, sondern dem User fhem. Müsste dann nicht eigentlich, bei Setzen von serviceSudo = 0 kein sudo verwendet werden?

DeeSPe

Mir ist zwar noch nicht ganz klar warum man als Nicht-root kein sudo benötigen sollte, aber ich denke wenn Du nach Zeile 152 die folgende Zeile einfügst sollte es mit "serviceSudo 0" klappen.
$sudo = "" if (AttrNum($name,"serviceSudo",1) == 0);

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

dennisk

Ich kann auf sudo verzichten, weil ich dem Benutzer fhem die Berechtigung erteilt habe, den systemd-Service zu steuern.
Das Ganze habe ich mit Polkit umgesetzt und verwende folgende Regel:

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;
                }
            }
        }
    }
});


Wie wäre alternativ folgende Anpassung: my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";
Nun wird sudo nur dann verwendet, wenn der Parameter serviceSudo auf 1 steht UND der Benutzername nicht root ist. Jetzt müsste doch die ursprüngliche Funktionalität erhalten bleiben und serviceSudo = 0 funktioniert auch. Was denkst Du?

DeeSPe

Zitat von: dennisk am 18 November 2019, 19:51:23
my $sudo = AttrNum($name,"serviceSudo",1) && $login !~ /^root@/ ? "sudo " : "";

Danke.
Ist so eingecheckt!

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

piet_pit

Hallo Dan,

ich nutze dein Tool und bin damit sehr zufrieden. Es erleichtert sehr den Umgang mit der Neukonfiguration z.B. bei Homebridge.

Nun habe ich homebridge neu installiert und bin dabei nach der Anleitung aus den github zu homebridge vorgegangen.

https://github.com/homebridge/homebridge/wiki/Install-Homebridge-on-Raspbian

Das hat sehr gut und einwandfrei geklappt, auch die Installation mit dieser

Homebridge Config UI X

Nun klappt aber dein Modul nicht mehr, deshalb die Frage, ob und wo ich das anpassen muss, da steige ich irgendwie nicht durch... 8)

Vielen Dank und viele Grüße
Pit




FHEM 6.0 auf Raspberry Pi 3, Rasbian-Stretch
FRITZ!Box 7490
HM-Mod-RPI-PCB
JeeLink
CUNO 1.47

DeeSPe

Hallo Pit,

ich habe meinen homebridge Service schon ewig laufen und auch über das Modul serviced an FHEM angebunden.
Laut dem von Dir verlinktem Wiki sollte das ja weiterhin über homeridge.service laufen. Allerdings wird der Service nun nicht mehr über systemctl gesteuert, sondern über ein eigenes Kommando "hb-service". Ich habe keinerlei Ahnung was das nun anders macht.
Aber letztendlich ist homebridge-config-ui-x auch nur ein Plugin für homebridge.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

piet_pit

Hallo Dan,

vielen Dank für deine Antwort.
Ich habe dein Modul deinstalliert und neu installiert, jetzt klappt es einwandfrei.

Viele Grüße
Pit
FHEM 6.0 auf Raspberry Pi 3, Rasbian-Stretch
FRITZ!Box 7490
HM-Mod-RPI-PCB
JeeLink
CUNO 1.47

Karflyer

#113
Hallo Dan,

ich nutze an dem 'entfernten', zu steuernden Rechner einen anderen SSH-Port als den Standardport (22). Wie kann ich das bei der Definition des Devices angeben?

Eine weitere Frage. Wie muss die Definition des Devices aussehen um einen 'entfernten' Rechner neu zu booten (reboot bzw. shutdown restart)?

Grüße
Stefan

Elektrolurch

Hallo,

ich brauche mal Unterstützung, da ich den Fehler nicht finde.
Situation:
Ich habe meinen zweiten Server "Kellergeist" neu aufgesetzt.
Von meinem ersten server aus habe ich per serviced vier Dienste kontrolliert. Alle 4 funktionierten, nach dem ich den "Kellergeist" neu eingerichtet habe, gehen nur noch zwei einwandfrei.
Daraus folgt:
a) An dem passwortlosen Zugriff über ssh auf "Kellergeist" kann es nicht liegen, dann würden ja alle vier Dienste nicht über fhem (serviced -> systemctl) kontrollierbar sein.
b) In der /etc/sudoers ist folgendes für den remote - Zugriff Nutzer fhem eingetragen:

fhem ALL=(ALL:ALL) NOPASSWD:/bin/systemctl


Für den Dienst "openvpn" bekomme ich folgende Fehlermeldung in fhem:

DEF openvpn fhem@Kellergeist
NAME openvpn
NOTIFYDEV global
SERVICENAME openvpn
STATE error
TYPE serviced
VERSION 1.2.5
Readings
error Unit openvpn.service could not be found. 2021-02-03 10:50:43
state error 2021-02-03 10:50:43


Wenn ich aber mich auf "Kellergeist" als Nutzer fhem anmelde, kann ich jeden Dienst mit

sudo systemctl restart openvpn

starten / stoppen oder restarten, ohne dass ein Passwort abgefragt wird.
Also stimmt der Eintrag in der /etc/sudoers wohl auch.
Für den zweiten Dienst (eine Instanz von fhem für kleinere andere Aufgaben auf Kellergeist) sieht es so aus:

   DEF        fhem fhem@Kellergeist
   NAME       fhem
   SERVICENAME fhem
   STATE      error
   TYPE       serviced
   VERSION    1.2.5
   READINGS:
     2021-02-01 13:14:03   error           sudo: no tty present and no askpass program specified
     2021-02-01 13:14:03   state           error
     2019-11-19 12:18:17   status          Active: active (running) since Tue 2019-11-19 12:17:38

Die Fehlermeldungen für "openvpn" (service kann nicht gefunden werden) und fhem (sudo: no tty present and no askpass program specified) sind auch noch unterschiedlich.verst
Die Probleme traten mit den zwei Diensten "openvpn" und "fhem" erst auf, nach dem der Server "Kellergeist" neu aufgesetzt wurde und jetzt unter buster läuft.

Jemand einen Tipp??
Wäre sehr dankbar.

Elektrolurch
configDB und Windows befreite Zone!

Otto123

Hi,

ich kenne das Modul nicht, aber um deine Aussage a) zu prüfen ein einfacher Test aus der FHEM Kommandozeile:
{qx(ssh fhem\@Kellergeist sudo whoami)}
{qx(ssh fhem\@Kellergeist whoami)}


Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Elektrolurch

Hallo Otto,

mit whoamI kommt natürlich:
sudo: no tty present and no askpass program specified
weil in der sudoers für fhem nur /bin/systemctl ohne passwort eingetragen ist.

{qx(ssh fhem\@Kellergeist sudo systemctl restart homebridge)}

geht natürlich.
Für "openvpn" oder "fhem" geht es, wie oben beschrieben, natürlich nicht.

Elektrolurch
configDB und Windows befreite Zone!

Otto123

Klingt nach: beide Dienst sind keine systemd Dienste sondern nach anderem Muster gestrickt?
{qx(ssh fhem\@Kellergeist ls -lha /etc/systemd/system/open*)}
{qx(ssh fhem\@Kellergeist ls -lha /etc/systemd/system/)}
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Elektrolurch

Hallo Otto,

der fhem-service existiert unter /etc/systemd/system:
2021.02.06 09:52:01 1: -rw-rw---- 1 root root 455 Jan  2  2020 /etc/systemd/system/fhem.service

openvpn lässt sich zwar mit

sudo systemctl restart openvpn

starten, liegt aber nicht unter systemd/system
sondern unter /etc/init.d/openvpn.
Möglicherweise muss ich dass in der sudoers für fhem berücksichtigen?
Der Aufruf von sudo systemctl restart openvpn geht wohl dann weiter an service openvpn restart, und dass fehlt dann wohl in der sudoers.

So ganz verstehe ich das allerdings noch nicht.

Elektrolurch
configDB und Windows befreite Zone!

Otto123

Hi,

das mit service vermute ich auch, den Unterschied zu fhem.service versteh ich noch nicht.

Ich habe mir mal folgendes notiert:
Inhalt der sudoers Datei
Die durch Komma getrennten Werte in der Datei haben folgende Bedeutung und benötigen immer den vollen Pfad!

/usr/sbin -> für alles im Verzeichnis
/usr/sbin/service * -> für alle Parameter
/usr/sbin/service apache2 * -> für alle weiteren Parameter
/usr/sbin/service apache2 reload -> genau nur hierfür

Insofern würde der jetzige Eintrag sowieso nicht komplett sein?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz