EXEC im Docker

[lenschith]

Hallo zusammen,
irgendwie möchte heute nichts klappen. Hab in den Foren einiges gelesen aber irgendwie komme ich nicht weiter.
ich möchte mit dem EXEC Binding Scripte ausführen u.a. Reboot von Systemen. Ich habe die Scripte angelegt, ausführbar gemacht und im Binding konfiguriert. Aber im Binding zeigt es mir den Switch nicht an, dort bleib NULL stehen.
Die Scripte können auf dem Raspberry ausgeführt werden, liegen unter /opt/oh4/userdata/scripte. Ich betreibe openHAB im Docker.
in der whitelist sind die Scripte eingetragen

Code: Alles auswählen

# For security reasons all commands that are used by the exec binding or transformation need to be whitelisted.
# Every command needs to be listed on a separate line below.
sh /userdata/scripts/raspi10_reboot.sh
sh /userdata/scripts/raspi10_shutdown.sh
sh /userdata/scripts/raspi10_update.sh

Code: Alles auswählen

UID: exec:command:RASPI10_reboot
label: RASPI10_reboot
thingTypeUID: exec:command
configuration:
  transform: REGEX((.*))
  interval: 0
  autorun: false
  command: sh /userdata/scripts/raspi10_reboot.sh
  timeout: 300
channels:
  - id: output
    channelTypeUID: exec:output
    label: Rückgabewert
    description: Rückgabewert der Befehlsausführung
    configuration: {}
  - id: input
    channelTypeUID: exec:input
    label: Eingabewert
    description: Eingabewert, der als zweiter Parameter an den Befehl übergeben wird
    configuration: {}
  - id: exit
    channelTypeUID: exec:exit
    label: Rückgabestatus
    description: Dokumentiert die erfolgreiche Ausführung
    configuration: {}
  - id: run
    channelTypeUID: exec:run
    label: Ausführung
    description: Steht während der Befehlsausführung auf ON; durch Setzen auf ON
      wird der Befehl sofort ausgeführt
    configuration: {}
  - id: lastexecution
    channelTypeUID: exec:lastexecution
    label: Zeitpunkt der letzten Ausführung
    description: Datum und Uhrzeit der letzten Ausführung des Befehls im Format
      yyyy-MM-dd'T'HH:mm:ss.SSSZ
    configuration: {}

Hat mir jemand einen Tipp wo mein Fehler liegt.

[udo1toni]

Bist Du sicher, dass das Script ausgeführt werden kann?

[lenschith]

ja, eigentlich schon. auf der CLI kann ich das Script ausführen. Es kommt eine Passwortabfrage ist das ein Problem?

[udo1toni]

auf der CLI kann ich das Script ausführen.

Welches CLI?

Es kommt eine Passwortabfrage ist das ein Problem?

Ja, definitiv

[lenschith]

Habe jetzt noch etwas getestet. Das bringt mich noch zur Verzweiflung.
der User openhab darf auf der Raspberry CLI das Script ausführen, es kommt keine Passwortabfrage.

Code: Alles auswählen

openhab@raspi12:/opt/openhab4/userdata/scripts$ sh test.sh
OK:1 http://deb.debian.org/debian bookworm InRelease
OK:2 http://deb.debian.org/debian bookworm-updates InRelease
OK:3 http://security.debian.org/debian-security bookworm-security InRelease
Holen:4 http://archive.raspberrypi.org/debian bookworm InRelease [23,6 kB]
OK:5 https://download.docker.com/linux/debian bookworm InRelease
Holen:6 http://archive.raspberrypi.org/debian bookworm/main armhf Packages [362 kB]
Holen:7 http://archive.raspberrypi.org/debian bookworm/main arm64 Packages [353 kB]
Es wurden 738 kB in 2 s geholt (323 kB/s).
Paketlisten werden gelesen… Fertig
+ echo apt-get update
apt-get update
+ exit 0
openhab@raspi12:/opt/openhab4/userdata/scripts$

Das Script:

Code: Alles auswählen

#!/bin/bash

sudo sudo apt-get update
set -x
echo "apt-get update"
exit 0

Config in der UI:

Code: Alles auswählen

configuration:
  transform: REGEX((.*))
  interval: 0
  autorun: false
  command: sh /userdata/scripts/test.sh
  timeout: 300

In der UI bleibt der Switch allerdings immer noch auf NULL

Screenshot 2024-01-30 071149.png

[udo1toni]

Noch mal... welches CLI?

Code: Alles auswählen

#!/bin/bash

und

Code: Alles auswählen

command: sh /userdata/scripts/test.sh

widersprechen sich - nicht, dass es zwingend eine Bedeutung hätte, aber es deutet darauf hin, dass da noch Wissenslücken klaffen

[lenschith]

ich bin mir auch sicher das ich da Wissenslücken habe .
CLI: /bin/bash

Code: Alles auswählen

root@raspi12:/opt/openhab4/conf/misc# sudo -u openhab /bin/bash
openhab@raspi12:/opt/openhab4/conf/misc$ sh /opt/openhab4/userdata/scripts/update.sh
***>>> System wird aktualisiert <<<***

die Scripte liegen unter /opt/openhab4/userdata/scripts
userdata wird in den Container gemappt
bin mir nur nicht sicher ob ich evtl. was in der exec.whitelist falsch habe, muss ich da den Pfad aus Sicht von OH eintragen oder den Pfad aus dem Dateisystem?

also so "sh /userdata/scripts/raspi10_update.sh" oder so "sh /opt/openhab4/userdata/scripts/raspi10_update.sh"?

Code: Alles auswählen

openhab@raspi12:/opt/openhab4/conf/misc$ cat exec.whitelist
# For security reasons all commands that are used by the exec binding or transformation need to be whitelisted.
# Every command needs to be listed on a separate line below.
sh /userdata/scripts/raspi10_update.sh

Oder bin ich komplett auf dem Holzweg.

Danke für deine Unterstützung
Gruß Lenschi

[udo1toni]

Also, der erste Punkt ist: Die Shell (≠ CLI) des Host Systems ist etwas vollkommen anderes als die Shell des Containers. Du kannst aber sehr wohl eine Shell innerhalb des Containers "betreten", je nachdem wie Du mit Docker unterwegs bist z.B. von der GNU/Linux Shell aus:

Code: Alles auswählen

user@docker:~$ docker exec -it openhab /bin/sh

Damit landest Du in der sh Shell.
Falls der Container bash mitbringt, kommst Du mit

Code: Alles auswählen

user@docker:~$ docker exec -it openhab /bin/bash

auch in die bash Shell. Aber bei weitem nicht jeder Container bringt bash mit, es geht ja auch darum, die Container möglichst klein zu gestalten, entsprechend sind nicht mehrere Tools für die selbe Aufgabe eingerichtet.

Nutzt Du Portainer, dann kannst Du natürlich auch komfortabel über die WebUI eine Shell öffnen (Container Details -> Console ->Connect. Falls das nicht klappt, eine alternative Shell ausprobieren, Portainer weiß im Allgemeinen nicht, welche die Richtige ist)
Und auch in anderen Docker UIs steht diese Funktion zur Verfügung.

Und Achtung! sh ≠ bash, beide sind ähnlich, haben aber teilweise ein unterschiedliches Verhalten, man sollte also unbedingt darauf achten, schon beim Erstellen eines Scripts darauf zu achten, mit welcher Shell dieses später ausgeführt wird.

Der zweite Punkt: Du möchtest auf einem Remote System Befehle ausführen, für die aus gutem Grund erweiterte Rechte notwendig sind. Dafür gibt es diverse Lösungen, aber man sollte das unbedingt "ordentlich" implementieren. Das heißt:

1. Ein Schlüsselpaar für den User erzeugen, der sich einloggen darf (also openhab), der Private Key darf nicht mit Passwort versehen sein
2. Auf dem Remote System ein Extra Konto für diesen User einrichten
3. den gerade generierten Public Key im Remote Konto hinterlegen und prüfen, dass der Login mit dem neu generierten Private Key funktioniert
4. Im lokalen System den Private Key so hinterlegen, dass der User openhab diesen bequem benutzen kann
5. den Remote Zugriff mittels private Key konfigurieren
6. Auf dem Remote System dafür sorgen, dass der gewünschte Befehl (und nur dieser) ohne Eingabe eines Passworts per sudo vom Remote User ausgeführt werden darf

Die einzelnen Schritte sind nicht weiter schwer zu erledigen, insbesondere das Login mittels Public/Private Key ist wirklich sehr einfach einzurichten, wenn man mal weiß, wie es geht, und man wird nicht mehr nach Passworten gefragt.

Hint an dieser Stelle: Man kann auch dafür sorgen, dass der Remote User überhaupt nur einen ganz bestimmten Befehl ausführen darf. Da man hier aber Parameter übergeben kann, ist es recht einfach, auf dem Remote System ein Script einzurichten, welches die Parameter prüft und in Abhängigkeit der Parameter bestimmte Befehle ausführt. Das sieht dann so aus, dass man tatsächlich per ssh z.B. nur execute shutdown sendet, execute ist dann der Name des Scripts, welches mit dem Parameter shutdown aufgerufen wird, das Script führt daraufhin mit passenden Rechten den eigentlichen Befehl aus (und der kann dann auch etwas ganz anderes machen, also z.B. einen Logeintrag erzeugen und anschließend ein Reboot ausführen oder was auch immer)
Ich habe früher über so ein Script regelmäßig Backups meiner Datenbank gemacht und der backup user durfte exakt den DB-Dump, ein optimiertes Diff zum vorherigen Stand und ein send der Datei an den Backup Server ausführen, sonst nichts.

[lenschith]

Hallo Udo,

danke für die ausführliche Antwort aber ich verstehe jetzt gerade überhaupt nichts mehr. Aber evtl. hab ich mich falsch ausgedrückt und du bist schon einen Schritt weiter als ich gedacht habe.

Noch mal zu meiner Ausgangslage:
[*]Mein Host ist ein Raspberry PI mit Docker
[*]Auf diesem Raspberry läuft der Container mit openHAB
[*]Von diesem openHAB möchte ich jetzt mit dem EXEC Binding ein Update des Hostsystems(Raspberry) über ein Script ausführen
[*]ich habe das EXEC Binding installiert aber das Switch ITEM vom Channel Ausführen bleibt auf NULL. Es wird mir kein Switch angezeigt

zu 2., ja das habe ich schon so mit einem User "service" konfiguriert wenn ich später einmal Remote Maschinen runterfahren will.

Aber als ersten Schritt möchte ich es schaffen das ich aus meinen openHAB Container das Hostsystem updaten und rebooten kann.

Habe ich irgendwas generell falsch verstanden? oder was übersehen.

Sorry für meine Dummheit, aber ich dachte das kann nicht so schwer sein.

Gruß Lenschi

[udo1toni]

Sorry für meine Dummheit, aber ich dachte das kann nicht so schwer sein.

Nix Dummheit! Allerhöchstens könnte man von Unwissenheit sprechen (aber auch die ist keine Schande).
Der Punkt ist: openHAB läuft in einem Docker Container. Damit ist openHAB "virtuell" auf einem anderen PC. Auch dieser Zugriff ist also ein Remote Zugriff. Du kannst aus einem Container heraus nicht (direkt) auf das Hostsystem zugreifen, das ist Teil des Konzepts von Containern, es geht ja genau darum, die einzelnen Dienste so voneinander abzuschotten, dass sie sich gegenseitig selbst mit brachialer Gewalt nicht in die Quere kommen können, wirklich, scheißegal was Du innerhalb des Containers veranstaltest, incl. dem Versuch, die Festplatte zu formatieren oder als root alle Daten des gesamten Dateisystems zu löschen - sudo rm -rf / und schwupps ist alles weg. Wirklich. Alles. Aber nicht aus einem Container heraus... Container wegwerfen und neu starten, und der Container ist wieder da, als wäre nichts gewesen. Bis auf die Konfiguration halt, die hat man ja ins Nirvana geschickt).

So sehr ich den Wunsch nach einem solchen Update Schalter verstehe, ist es aber keine sehr kluge Idee.
Punkt 1: Der Container wird im Zuge des Updates vermutlich wegfliegen, womit dann auch openHAB nicht mehr erreichbar ist.
Punkt 2: es gibt bei Updates immer mal wieder Meldungen, bei denen apt stehen bleibt und auf eine Eingabe wartet (z.B. Entscheidungen über veränderte Konfigurationsdateien, durch die neue Default Version ersetzen oder die alte Version behalten).
Wenn man also ein Update ohne weitere Eingriffe ausführen möchte, dann sollte man die entsprechenden Systemfunktionen dafür nutzen. Es gibt dafür das Paket unattended-upgrades, welches aber nicht ohne Grund standardmäßig nicht installiert ist. Man sollte also auch einigermaßen wissen, was man da wie konfigurieren muss.

Für die Verwaltung der Container bietet sich portainer an. Lege eine Datei upgrade-portainer.sh an und mache sie ausführbar.

Code: Alles auswählen

#! /bin/bash
docker stop portainer
docker rm portainer
docker pull portainer/portainer-ce:latest
docker run -d -p 8000:8000 -p 9443:9443 --name=portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Die Datei lädt portainer und startet es anschließend. Danach ist portainer über die IP des Host mit https:// unter 9443 erreichbar. Zitat aus der Portianer Doku:

The username defaults to admin but you can change it if you prefer. The password must be at least 12 characters long and meet the listed password requirements.

Du kannst also einen beliebigen Usernamen wählen, admin ist die Vorgabe. Das Passwort muss mindestens 12 Zeichen lang sein. Du kannst später über die Oberfläche weitere User anlegen. Portainer kann beliebig viele Docker Hosts verwalten, kostenlos kannst Du bis zu drei Hosts nutzen (über eine Oberfläche... natürlich kann man beliebig viele Docker Instanzen mit jeweils einem eigenen Portainer versehen und diesen dann standalone laufen lassen).
Über Portainer kannst Du dann alle Container aller Docker Hosts verwalten, updaten, erstellen usw, bis auf den Portainer Container selbst (deshalb das upgrade-Script, welches Du zu diesem Zweck einfach von einem User aufrufst, der in der Gruppe docker ist).

Systempflege mag lästig sein, mit den passenden Werkzeugen ist sie aber manuell mit wenigen Klicks erledigt, ein Schalter in openHAB ist dafür aber völlig ungeeignet (selbst wenn man das entsprechende Script erfolgreich zum Laufen bringt)