UDEV Regel

    • Offizieller Beitrag

    Das sind keine im Weg liegenden Steine, sondern Garantien, Sicherheiten

    Sowas sagen unsere Innenminister auch. Im Interesse der Sicherheit der Bürger und auf Kosten ihrer Freiheit.

    Wenn ein Linuxsystem ein Staat wäre, als was würde man da eine Einrichtung wie systemd wohl bezeichnen? Ich schwanke da zwischen Polizei und Stasi. :stumm:

    SCNR

  • Im Interesse der Sicherheit der Bürger und auf Kosten ihrer Freiheit.

    Ich habe ja schön des öfteren gesagt oder zugegeben, dass systemd in seiner Gesamtheit nicht einfach ist. Wer behauptet, systemd ist einfach, der lügt. Aber es gibt was anderes, was mich bei der Debatte immer wieder aufs neue irritiert... und zwar die Haltung einiger Anwender. Die erwarten zwar alle, dass 'ihr' Betriebssystem ihre persönlichen Anforderungen erfüllen kann und das 'ihr' Computer-System immer mehr und kompliziertere und weitere Aufgaben beherrschen muss, aber gleichzeitig erwarten sie, dass die Kompliziertheit der Bedienung so bleibt, wie sie vor 10 Jahren bei Squeeze war. Dabei gabs so vieles von dem, was heute selbstverständlich ist, unter Squeeze eben nicht... wie Internet of Things, Home-Automatisierung, Alexa, private Mailserver, private Cloudsysteme, private WLAN-Accesspoints, Cal/Card-Sync-Server, Internet-Crime, Crypto-Miner, Ramsomware, usw. usw. Wenn es was davon schon gab, dann in den Anfängen, für Pioniere, aber nicht für die breite Masse, wie es heute fast selbstverständlich ist.

    Fakt ist, Squeeze ist Höhlenmalerei... und wer heute umfassende oder komplizierte Anforderungen an seine private IT stellt, wozu ich auch diesen Thread zähle, der muss sich eben die notwendigen aktuellen Kenntnisse aneignen. Wäre die Bedienung heute noch wie bei Squeeze, wäre die Stabilität von Debian die eines wackeligen und löcherigen Holzkarrens zum Transport des Korns nach der Ernte.... mit anderen Worten untauglich. Damit wäre das OS heute für ganz viele Leute mit hochwertigen Ansprüchen schlichtweg unbrauchbar. Moderne Anforderungen mit den Kenntnissen von Squeeze zu realisieren funktioniert nicht. Dafür kann aber systemd nichts.... systemd schafft nur den Rahmen, damit eben auch solche hochwertigen Anforderungen in jeglicher Kombination möglich sind und stabil funktionieren.

    Das ist eigentlich auch der Punkt, warum ich manchmal überlege bzw. zu dem Schluss komme, dass es in Wirklichkeit völlig sinnlos ist, den privaten Usern irgendwas von Sicherheit oder Sorgfalt beim Umgang mit dem PC im Internet zu erklären. Die Wahrheit ist, wir sind wie eine Schafherde, bei der jedes Schaf mit IDC/GPS (Smartphone) gechipt ist, ,damit der Bauer immer weiss, wo wir uns aufhalten. Die tiefere Bedeutung des Chips verstehen die Schafe auch nicht... das er nur dazu dient, dass der Schlachter das Tier auf der Weide leichter findet.... :fies:

    Fazit, es ist heute ein Grad der Kompliziertheit erreicht, das es kaum noch jemand versteht... denn schließlich sind wir alle auch nur Schafe.....

  • Na ja, Du sprichst von einem offenen System (Linux) mit bekannten Regeln die man nachlesen kann und einem System mit vielen Dunkelzonen (Polizei) und geschlossenem System (Stasi).

    Stell Dir vor die Stasi würde wirklich alles nach Gesetz machen :lol:

  • Erstmal vielen Dank für die antworten.

    Ok, das zum Thema systemd... ;)

    Mal sehen ob matze1 noch die Antwort auf #28 zeigt und uns damit "Back to Topic" bringt.

    Ich werde es morgen zeigen wenn ich zu Hause bin.

    EDIT: ich habe gerade auf mein Ubuntu PC mal versucht das ganze nachzustellen, also wenn ich die udev.rules in /etc/udev/rules.d/."

    speichere funktioniert es nicht. Wenn ich es unter "/lib/udev/rules.d/." speichere, dann startet ein bash Script ohne Probleme.

    Mein einfacher Ansatz ist auf dem Pi ist ein bash Script zu starten was dann das Python script startet und fertig.

  • jepp, Ubuntu ist nicht Debian ist nicht raspbian.

    Für Ubuntu guckst Du /etc/udev/rules.d/README

    Debian: The rules files (which amount to more configuration for udevd) are taken from /run/udev/rules.d, /etc/udev/rules.d or /lib/udev/rules.d (debian puts most of the rules in /lib/udev/rules.d).

    Einmal editiert, zuletzt von gugus (10. Februar 2019 um 13:54)

  • So jetzt bin ich doch noch dazu gekommen.

    Also ich habe jetzt in UDEV ein ganz einfachen Eintrag

    Code
    KERNEL=="sd?1", SYMLINK+="musik", RUN+="/bin/bash  /home/pi/shscript.sh"

    der Symlink funzt, aber das Script wird nicht ausgeführt (was bei Ubuntu klappte, aber das ist ja ne ganz andere Baustelle wie Cluster auch schrieb).


    Hier mein Script:

    Bash
    #!/bin/bash
    
    touch /home/pi/udevtext.txt

    Und hier deren Rechte:

    Code
    -rwxr-xr-x 1 root root  37 37 Feb 10 15:46 shscript.sh


    Auch wenn ich Gruppe/Benutzer auf pi ändere bringt es nichts.

  • der Symlink funzt, aber das Script wird nicht ausgeführt (was bei Ubuntu klappte, aber das ist ja ne ganz andere Baustelle wie

    Die udev-Regeln sind imho nicht monitored. Hast Du nach dem Einfügen der Regeln neu gebootet oder zumindest udev neu initialisiert?

    Code
    udevadm control --reload-rules

    Darüber hinaus solltest Du Dir angewöhnen, nicht immer fragmentierte Angaben zu posten, sondern vollständige, damit die Fehlersuche nicht von mal zu mal unnötig erschwert wird. Vollständig sieht so aus:

    Code
    grep shscript.shg /etc/udev/rules.d/*.rules
    KERNEL=="sd?1", SYMLINK+="musik", RUN+="/bin/bash  /home/pi/shscript.sh"
    
    cat /home/pi/shscript.sh
    #!/bin/bash
    touch /home/pi/udevtext.txt
    
    ls /home/pi/shscript.sh
    -rwxr-xr-x 1 root root  37 37 Feb 10 15:46 shscript.sh

    Damit sind Pfade und Zusammenhänge erkennbar. Dieses unnötige Zusammensuchen von fehlenden Informationen erreicht nur eins, und zwar das die Fehlersuche völlig unnötig verkompliziert wird.

    Darüber hinaus fehlt in der Regel die Subsystem-Angabe und die Action-Spezification. Die offene Frage ist also: soll das Script bei Add oder Remove des Gerätes durchgeführt werden? Darüber hinaus fehlt imho auch noch eine Attribut-Identifikation, damit diese Regel nicht bei jedem Device ausgeführt wird.... was möglicherweise ein Problem verursachen könnten. Die Regel ist so also fehlerhaft. Die Lösung wurde schon in #20 beschrieben.

    Um die relevanten Daten zu ermitteln, kann man vor dem Verbinden des Gerätes einen Dump in einem Terminal (als root) aktivieren:

    Code
    udevadm monitor --environment --udev

    2 Mal editiert, zuletzt von WinterUnit16246 (10. Februar 2019 um 16:43)

  • Ich habe immer mit

    Code
    sudo udevadm trigger

    neu eingelesen.

    Aber nach reboot und deine Variante passiert auch nichts.

    Es fehlt die Spezifikation, ob es bei Add oder Remove ausgeführt werden soll... und subsystem..... siehe #20

  • Probiere es mit diesem 2 Regeln.... unverändert (!):

    Code
    grep create-journal /etc/udev/rules.d/*.rules
    
    KERNEL=="sd?1", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/usr/local/bin/create-journal-entry add %k"
    KERNEL=="sd?1", SUBSYSTEMS=="usb", ACTION=="remove", RUN+="/usr/local/bin/create-journal-entry rem %k"

    Und mit diesem ausführbaren Script... ebenfalls unverändert (!):

    Code
    cat /usr/local/bin/create-journal-entry
    
    #!/bin/bash
    echo "User=$USER, Parm1=$1 Parm2=$2 Parm3=$3" | systemd-cat -t "thlu:$(basename $0)" -p info
    exit 0

    In einem Terminal startet du vor dem Verbinden des Gerätes die Journalausgabe als root, und siehe da... das Script wird beim Verbinden des Gerätes gestartet und korrekt ausgeführt... jedes Mal:

    Code
    journalctl -f | grep create
    
    Feb 10 17:00:58 thomaspc thlu:create-journal-entry[13723]: User=, Parm1=rem Parm2=sdd1 Parm3=
    Feb 10 17:01:05 thomaspc thlu:create-journal-entry[13813]: User=, Parm1=add Parm2=sdd1 Parm3=
    Feb 10 17:10:11 thomaspc thlu:create-journal-entry[13919]: User=, Parm1=rem Parm2=sdd1 Parm3=

    Um die vollständige Journal-Ausabe beim Verbinden anzusehen, verwendest Du diese Variante:

    Code
    journalctl -f 

    2 Mal editiert, zuletzt von WinterUnit16246 (10. Februar 2019 um 17:11)

  • Die Ausgabe sieht wie folgt aus:

    Code
    pi@raspberrypi:~ $ sudo journalctl -f | grep create
    Feb 10 17:49:38 raspberrypi systemd-udevd[563]: failed to execute '/usr/local/bin/create-journal-entry' '/usr/local/bin/create-journal-entry add sda1': Permission denied
    Feb 10 17:49:38 raspberrypi systemd-udevd[556]: Process '/usr/local/bin/create-journal-entry add sda1' failed with exit code 2.
  • Es fehlen wieder Angaben:

    Code
    ls /usr/local/bin/create-journal-entry

    Ich tippe mal darauf, dass das fehlt, worauf ich hier schon hingewiesen habe:

    Und mit diesem ausführbaren Script... ebenfalls unverändert (!):

    Die Lösung:

    Code
    chown root:root /usr/local/bin/create-journal-entry
    chmod 755 /usr/local/bin/create-journal-entry
  • Ich habe es jetzt mit chmod +x ausführbar gemacht.

    Code
    pi@raspberrypi:~ $ ls -l /usr/local/bin/create-journal-entry
    -rwxr-xr-x 1 root staff 144 Feb 10 18:11 /usr/local/bin/create-journal-entry
    pi@raspberrypi:~ $ sudo journalctl -f | grep create
    Feb 10 18:11:41 raspberrypi sudo[873]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/nano /usr/local/bin/create-journal-entry
    Feb 10 18:12:04 raspberrypi thlu:create-journal-entry[887]: User=, Parm1=rem Parm2=sda1 Parm3=
    Feb 10 18:12:51 raspberrypi thlu:create-journal-entry[953]: User=, Parm1=add Parm2=sda1 Parm3=
  • pi@raspberrypi:~ $ sudo journalctl -f | grep create
    Feb 10 18:11:41 raspberrypi sudo[873]: pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=/bin/nano /usr/local/bin/create-journal-entry
    Feb 10 18:12:04 raspberrypi thlu:create-journal-entry[887]: User=, Parm1=rem Parm2=sda1 Parm3=
    Feb 10 18:12:51 raspberrypi thlu:create-journal-entry[953]: User=, Parm1=add Parm2=sda1 Parm3=

    Perfekt.... huuuurraaaaar....es läuft..... Script wird gestartet.... Problem gelöst.... :bravo2:

    So, und nun als nächstes... vergisst Du die ganze unnötige Script-Chose, das ist nämlich hier beim Mount eines Block-Device totaler Quatsch und machst Dir stattdessen eine mount-unit, die in der Regel dann wie folgt gestartet wird:

    Code
    grep create-journal /etc/udev/rules.d/*.rules
    
    KERNEL=="sd?1", SUBSYSTEMS=="usb", ACTION=="add", RUN+="/bin/systemctl start deinname.mount"
    KERNEL=="sd?1", SUBSYSTEMS=="usb", ACTION=="remove", RUN+="/bin/systemctl stop deinname.mount"

    Die Mount-Unit kommt nach

    Code
    /etc/systemd/system/deinname.mount

    Dabei wird dir aber Hofei helfen können, der hat dafür schon ein tolles Tutorial hier geschrieben. Hier brauchts halt nur nicht die Netzwerks-Eigenschaften, die sollten aus der Unit raus bleiben.

    Und wie gesagt... die Regel schnappt sich in dieser Form jedes USB-Block-Device... ob das in Deinem Sinne ist... keine Ahnung... es fehlen also eigentlich noch Hardware-Identifikationen in der Regel. Deshalb hatte ich weiter oben auf den Dump hingewiesen....

  • Aber was ich nicht verstehe, warum kann man bei raspbian kein bash oder python Script aus udev heraus starten?

    Natürlich geht das.... das Beispielscript (journaleintrag) von mir ist doch ein Bash-Script.... ich wüsste gar keinen Grund, der das verhindern oder behindern sollte.

  • Also könnte ich mit dem Bash-Script ein Python-Script ausführen?

    Ja sicher geht das.... warum soll das nicht gehen...?... kein Problem. Allerdings denke ich ja auch, dass es ebenfalls völlig ok ist, in jeder Hand 'ne Wasserpumpenzange zu nehmen und sich damit die Socken anzuziehen. Wobei gugus Vorgehensweise zugegebenerweise pragmatischer wäre. Übertragen auf die Socken bedeutet das, frische Socken zu nehmen, dann brauch man auch keine Zange. 8o

    Edit:

    Nur unbedingt dran denken, dass das nur für kurzläufer geeignet ist... also script starten, was machen und sofort wieder beenden.... mit sauberen Return-Code, damit systemd keinen Fehler interpretiert.

    Einmal editiert, zuletzt von WinterUnit16246 (10. Februar 2019 um 21:13)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!