[erledigt] Festen Mount point für USB cardreader

[TomL]

Für mich wäre die Entscheidung relativ einfach. Aber ich verstehe auch, wenn dich das im Moment noch überfordert. Bei solchen Sachen hilft es immer, das Problem in unabhängige Teile aufzuteilen, die man leichter durchschaut und versteht, um dann für jeden Teil eine eigene optimale Entscheidung zu treffen.

Am Anfang, definiere was du willst und mach ne Bestandsaufnahme, was du hast bzw. was bereits geht. Dann überlege was fehlt und löse das.

Was du willst:
Ein USB-Speichermedium soll seine Daten beim Plug-In automatisch auf ne Platte rsync'n. Dahinter verbergen sich zwei eigenständige getrennt von einander zu lösende Probleme, und zwar zuerst das mounten und dann das kopieren.

Was du hast:
Das Speichermedium und ein fremdes Script, welches konstante Mount-Points erwartet.
Eine Udev-Regel und ein Miniscript, welches den Stick bereits erfolgreich auf den erforderlichen Mount-Point 'symlinkt'.

Was noch fehlt:
Der rsync-Job failed beim Start durch den Udev-Event-Handler - wobei vor dem Hintergrund der Man-Page dieser Weg sowieso falsch wäre. Das Script muss also auf anderem Wege gestartet werden.

Den bereits gelösten Teil (korrekter vorhandener Mount-Point) könnte man lt. Nab's Idee neu konzeptionieren . Anstatt ein fixer Mountpoint, wird nur ein fixer Symlink für das Device generiert. Dann überlässt man den Mount dem Automounter, der einen (für dich als Betrachter) zufälligen Mount-Point erstellt. Aber der Event-Handler muss trotzdem über eine Regel den rsync-Job starten. Dieser spezielle Teilpunkt bleibt also sowieso unverändert bestehen.

Aber zusätzlich ist nun notwendig, das fremde rsyc-Script in seiner bisherigen Logik-Integrität zu manipulieren - was m.E. aufwendig und eigentlich überflüssig ist.... und auch immer neue Risiken für neue Fehler erzeugt. Anstatt -was es bisher tut- einen vorgekauten Mont-Point zu schlucken, muss es nun selbst einen variablen Mount-Point über einen konstanten Device-Symlink ermitteln. Ich halte den Aufwand für höher, weil eine funktionierende Teillösung durch eine andere ersetzt wird, die weiteren Aufwand erzeugt.... und zwar ein fremdes Script anzupassen.

Vielleicht helfen dir meine Überlegungen bei der Entscheidung, aber treffen musst du sie selbst.

[Eomer]

Hi zusammen,

ich glaube wir machen das so, Tom

Trotzdem plagen mich Fragen:

So sah das Script aus, als ich es von einer anderen Seite übernommen habe:

Code: Alles auswählen

# Run Script as a new process when any device is added
KERNEL=="sd[a-z]", SUBSYSTEM=="block", ACTION=="add", RUN+="/bin/su root -c /opt/bin/myfork.sh"
#
# Shutdown System when a Specific device is removed
# This is the serial number of my wifi adapter
ENV{ID_SERIAL}=="Realtek_8176_00e04c000001", ACTION=="remove", RUN+="/bin/su root -c /opt/bin/systemshutdown.sh"

Code: Alles auswählen

#!/bin/bash
date >> myfork.log
setsid /opt/bin/goprosync.sh > setsid.log 

Und dann kommt das Copyscript...wieso hat es in dieser Form funktioniert? Auch das Kopieren von großen Dateien war gar kein Problem.
Liegt diese ganze "kill"-Geschichte daran, dass wir den Mount Point ändern?

Ein anderes Script was ich gefunden habe war wie folgt aufgebaut:

Code: Alles auswählen

SUBSYSTEM=="block", ACTION=="add", ENV{DEVTYPE}=="partition", ENV{UDISKS_PARTITION_NUMBER}=="1", RUN="/usr/local/bin/sd-autocopy"

An dieser Stelle erstmal die Rule.

Code: Alles auswählen

USER=lm
TARGET=/home/$USER/Pictures/Photos
HANDLED_SERIALS="0x000006d4"
MOUNT=/mnt/sd-autocopy
FILE_MATCH=".*\.(jpg|cr2)$"
TRANSFER=mv
 
# END OF CONFIGURATION ########################################################
 
# DEBUG:
# To enable debugging without udev events uncomment the lines below
#ID_SERIAL=0x000006d4
#DEVNAME=/dev/mmcblk0p1
 
# Catch unset but needed vars - terminate script
if [ -z "$ID_SERIAL" ] || [ -z "$DEVNAME" ]; then
    exit 1
fi
 
if ! echo "$HANDLED_SERIALS" | grep $ID_SERIAL >/dev/null 2>&1; then
    logger -t sd-autocopy "Got unhandled serial, skipping (Serial: $ID_SERIAL)"
    exit 1
fi
 
logger -t sd-autocopy "Got handled serial ($ID_SERIAL), moving images..."
 
if [ ! -d "$MOUNT" ]; then
    mkdir -p "$MOUNT"
fi
 
mount $DEVNAME "$MOUNT"
 
LINES=$(find "$MOUNT" -regextype posix-egrep -iregex "$FILE_MATCH" -printf "%TY-%Tm-%Td_%p\n")
DATES=$(echo "$LINES" | cut -d_ -f1 | uniq)

Im Copyscript selbst waren dann die Mount-Befehle etc.
Mit diesem Setup funktionierte sowohl das Erkennen des Cardreaders als auch das Mounten, nur die langen Prozesse taten es nicht.
Verstehe ich richtig, dass dies in etwa das ist, was NAB vorschlägt?

Rein theoretisch sollte dies ja auch funktionieren, wenn man den Prozess von udev löst.
Das ist aber genau DIE Variante die du nicht empfiehlst, weil sie fehleträchtig ist, richtig?


Ich glaube wenn Du mir das kurz beantworten könntest, habe ich es verstanden.

[NAB]

Eomer, die Lösung über die Systemd-Unit schlage ich nicht vor, sondern die scheint sich zwangsläufig zu ergeben, da systemd-udevd sonst dein Backupscript killt. Da scheint TomL auch meiner Ansicht zu sein, der mag Systemd nämlich ganz gerne, während ich es gerne deinstalliere. Darum kann ich das Problem auch nicht nachstellen ... ich hab's nämlich nicht. TomL hat es interessanter Weise anscheinend auch nicht, bei dem scheint es per setsid und & zu funktionieren. Nur bei dir nicht.

Was genau bei dir los ist, wissen wir eigentlich immer noch nicht. Wird das Backupscript nun gekillt oder stoppt es aus unbekanntem Grund? Ich hatte dich hier aufgefordert, dem mal nachzugehen:
viewtopic.php?f=34&t=160495&start=60#p1087884

Mir ging es lediglich noch darum, wo die Konfiguration hingeschrieben wird ... in ein Script, das von einer Udev-Regel ausgeführt wird, oder in ein Script, das von Systemd ausgeführt wird, und in die fstab. Das ist reine Kosmetik, und wenn es TomL nicht gefällt, keine weitere Zeile mehr wert

Die Udev-Regel bleibt auf dem zuletzt funktionierenden Stand. Zusätzlich muss in die Regel eingefügt werden, dass sie Systemd informiert, dass das Backupscript ausgeführt werden muss.

Das myfork.sh bleibt auch so, wie es war - nur der Aufruf des Backupscriptes fliegt da raus - das soll ja nun Systemd machen.

[TomL]

So sah das Script aus, als ich es von einer anderen Seite übernommen habe:

Code: Alles auswählen

# Run Script as a new process when any device is added
KERNEL=="sd[a-z]", SUBSYSTEM=="block", ACTION=="add", RUN+="/bin/su root -c /opt/bin/myfork.sh"
#
# Shutdown System when a Specific device is removed
# This is the serial number of my wifi adapter
ENV{ID_SERIAL}=="Realtek_8176_00e04c000001", ACTION=="remove", RUN+="/bin/su root -c /opt/bin/systemshutdown.sh"

Code: Alles auswählen

#!/bin/bash
date >> myfork.log
setsid /opt/bin/goprosync.sh > setsid.log 

Und dann kommt das Copyscript...wieso hat es in dieser Form funktioniert? Auch das Kopieren von großen Dateien war gar kein Problem.

Nun ja... das bezweifel ich. Das goprosync-Script verlangt doch eindeutige Mount-Points und kümmert sich nicht selber darum... verrate mir mal, wo die bei diesen Vorgaben/Gegebenheiten also gesetzt wurden? Was hat das Script denn wohin gesynct? Fakt ist, udev sieht nicht vor, lange Jobs vom Handler aus zu starten und beendet diese einfach, wenn der Handler beendet wird... siehe eindeutigen Hinweis in der Man-Page:

Code: Alles auswählen

Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished.

Aber mal zur Erklärung.... was macht udev überhaupt? Die wesentliche Aufgabe von udev ist eine dynamische Geräte-Verwaltung. Das heisst, udev gibt Dir die Möglichkeit zur Einflussnahme auf die Geräte-Verwaltung.... im Gegensatz zum dazu statischen Handling durch den Kernel. Du kannst mit udev bei bestimmten Events (z.B. Add oder Remove) eines Devices gewisse Dinge veranlassen, z.B. dem Gerät einen bestimmten Symlink verpassen, oder einen bestimmten kurzen Customizing-Job starten. Und um das Gerät eindeutig zu identifizieren bietet dir Udev eine Hilfe über Filter an, damit die Anweisung einer Regel nicht alle möglichen Devices betriff, sondern nur das gewünschte Gerät betroffen ist. Udev weiss überhaupt nichts von Mounts und irgendwelchen Jobs und es interessiert sich auch nicht dafür.

Liegt diese ganze "kill"-Geschichte daran, dass wir den Mount Point ändern?

Nein, natürlich nicht. Der Mount-Point hat überhaupt nichts mit dem Killen von Prozessen zu tun. Das Beendes des Prozesses hängt einfach mit der Zeit zusammen, die dieser Fork benötigt und das diese Zeit vom Handler nicht "bewilligt" wird. Das gilt ganz offensichtlich für alle vom Handler gestarteten 'weiteren' Prozesse.

Mit diesem Setup funktionierte sowohl das Erkennen des Cardreaders als auch das Mounten, nur die langen Prozesse taten es nicht.
Verstehe ich richtig, dass dies in etwa das ist, was NAB vorschlägt?

Nun ja, ich bezweifel das, weil auch dieses Script nicht die Udev-Restriktionen aushebeln kann. Und nein, das eine (udev-Handler) hat mit dem anderen (kopieren) erst mal nichts zu tun. Aber egal, schauen wir nun noch mal auf die Unterschiede zu Nabs Vorschlag, der sich allein auf das Gerätmanagement bezieht. Nab möchte für das Gerät einen konstanten Symlink für den Geräte-Namen vergeben, der vom automounter auf einen variablen Mount-Point gemountet wird. Das Copy-Script kann das momentan nicht handeln.

Ich schlage vor, einen variablen Geräte-Namen zu belassen und dafür einen konstanten Symlink als Mount-Point zu verwenden. Für Deinen Fall halte ich den konstanten Mount-Point für besser, weil das Script den bereits sowieso verwendet und weil derzeit für dich der Kernel-Gerätename eigentlich irrelevant ist. Beide Wege funktionieren. Aber beide Wege unterliegen in der weiteren Folge (Copy-Job, Forks) gleichermaßen den Restriktionen des udev-Handlers (Kill der Child-Prozesse).... also, das eine ist das Geräte-Management, das andere ein Job mit längerem Zeitbedarf.... der udev-Handler begrenzt die Zeit für geforkte Jobs. Punkt! Fini!

Code: Alles auswählen

Das ist aber genau DIE Variante die du nicht empfiehlst, weil sie fehleträchtig ist, richtig?

Ich empfehle jetzt, nach Nabs Hinweis auf die Man-Page, dem udev-Handler allein das Geräte-Management zu überlassen und dann als eigenen unabhängigen Prozess den Kopierjob via Systemd zu starten... wobei der Kopierjob nur noch vorgekautes (fertige Mount-Points) schlucken muss. Beide Aufgaben sind getrennt voneinander zu betrachten, beide benötigen keine Kenntnis vom anderen, beide erledigen jeder für sich die eigenen Aufgaben. Wenn Du den anderen Weg wählst (symlink für das Device), musst Du fit genug darin sein, das Script auf die neuen Gegebenheiten anzupassen. Natürlich geht das, aber imho ist das am Anfang auch mal fehlerträchtig.

Wenn das noch nicht klar ist, frage gerne noch mal weiter... aber mache nicht den Fehler, Sachverhalte zu vermengen, die nicht vermengt werden dürfen.

[TomL]

TomL hat es interessanter Weise anscheinend auch nicht, bei dem scheint es per setsid und & zu funktionieren.

Ich weiss nicht, ob sleep in dem Fall ein echter Prozess ist oder ob es nur einen Timer-IRQ setzt, um das System nicht zu belasten. Also, ich wäre jetzt rückblickend da eher vorsichtig bei der Bewertung meines Ergebnisses.... und ich denke, so richtig trauen kann man dem nicht....

[NAB]

Sleep ist erst mal ein Programm, und das braucht eine PID, und stirbt, wenn die PID gekillt wird. Die interne Implementierung ist da zweitrangig und das Aufräumen ein Problem des Kernels.

Ach, TomL, woran ich auch noch knabbere ist das hier:

Code: Alles auswählen

setsid /opt/bin/goprosync.sh > setsid.log

Wer schreibt da eigentlich in setsid.log? Die ausführende Shell? Oder das forkende setsid? Oder das goprossync.sh? Und was passiert, wenn die ausführende Shell gekillt wird? Vielleicht magst du das noch mal mit deinem sleep-Beispiel nachstellen.

Eomer, du könntest es mal ohne das "> setsid.log" testen.

[Eomer]

Hey,

vielen Dank für die ausführliche Antwort.
Zu dem ersten Script: Richtig, es klappt nur, wenn der Mount point immer gleich ist (z.B. weil die Kamera die Partition immer gleich bezeichnet). Ich wollte damit nur ausdrücken, dass es bei großen Dateien nicht mit dem Kopieren stoppt!

Zu der anderen Aussage:

Ich empfehle jetzt, nach Nabs Hinweis auf die Man-Page, den udev-Handler allein das Geräte-Management zu überlassen und dann als eigenen unabhängigen Prozess den Kopierjob via Systemd zu starten... wobei der Kopierjob nur noch vorgekautes (fertige Mount-Points) schlucken muss. Beide Aufgaben sind getrennt voneinander zu betrachten, beide benötigen keine Kenntnis vom anderen, beide erledigen jeder für sich die eigenen Aufgaben.

Würde ich sehr gerne angehen
Wo muss ich anfangen?


@NAB: Ich teste jetzt gleich mal die beiden Sachen!

EDIT 1:
myfork.sh sieht jetzt so aus:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

setsid /opt/bin/copyscript.sh
#/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

Bricht nach wie vor ab. Ich teste jetzt mal deinen verlinkten Beitrag.

EDIT 2:
Mit der o.g. Config (myfork) sieht es so aus:

Code: Alles auswählen

pi@raspberrypi:/opt/bin $ ps -e | grep 1325
 1325 ?        00:00:00 copyscript.sh
pi@raspberrypi:/opt/bin $ ps -e | grep 1325
pi@raspberrypi:/opt/bin $ ps -e | grep 1325

Also er bricht ab.


LG

[NAB]

Du kannst noch mal die umgekehrte Variante testen:

Code: Alles auswählen

# setsid /opt/bin/copyscript.sh
/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

Die wird bei TomL ja nicht gekillt.

Und mal nachgucken, welche Udev-Version Raspbian eigentlich benutzt:

Code: Alles auswählen

apt-cache policy udev

Bei Debian Jessie ist das "215-17+deb8u4". Wenn's bei dir anders ist, wär das schon mal eine Erklärung für das unterschiedliche Verhalten bei dir und TomL.

[Eomer]

Du kannst noch mal die umgekehrte Variante testen:

Code: Alles auswählen

# setsid /opt/bin/copyscript.sh
/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

Die wird bei TomL ja nicht gekillt.

Und mal nachgucken, welche Udev-Version Raspbian eigentlich benutzt:

Code: Alles auswählen

apt-cache policy udev

Bei Debian Jessie ist das "215-17+deb8u4". Wenn's bei dir anders ist, wär das schon mal eine Erklärung für das unterschiedliche Verhalten bei dir und TomL.

Bricht leider auch in dieser Variante ab. Prozess ist tot.

Also ich habe die gleiche.

Code: Alles auswählen

$ sudo apt-cache policy udev
udev:
  Installiert:           215-17+deb8u4
  Installationskandidat: 215-17+deb8u4
  Versionstabelle:
 *** 215-17+deb8u4 0
        500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
        100 /var/lib/dpkg/status

Was ich ja eingangs mal gesagt habe: Ich habe einen TFT darauf. Das raspbian-image ist also leicht verändert, weil ein anderer Kernel drauf ist.

[TomL]

Würde ich sehr gerne angehen. Wo muss ich anfangen?

In dem Du NACHEINANDER zwei getrennten Aufgaben löst

myfork.sh sieht jetzt so aus:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

setsid /opt/bin/copyscript.sh
#/usr/bin/setsid /bin/bash -c "/opt/bin/copyscript.sh &"

......Also er bricht ab.

Das ist wieder die Vermengung des Device-Handlings mit dem Copy-Job.... von der ich genau abgeraten habe. Ich würde mich jetzt nicht mehr mit dem Problem des Abbruchs beschäftigen, weil der ja quasi durch die Man-Page regelrecht angekündigt wurde. Warum sich mit einem solchen Problem beschäftigen, was offensichtlich gar nicht zu lösen ist?

Löse doch jetzt einfach das Problem, dass dieser spezielle Speicher nach dem Plug-In immer mit dem passenden Mount-Point verbunden ist. Das heisst, myfork.sh kann eigentlich nix anderes als das hier enthalten:

Code: Alles auswählen

#!/bin/bash
date >> /opt/bin/myfork.log
echo "Versuche: /bin/mount $1 /media/cardreader -o rw" >> /opt/bin/myfork.log

[[ ! -z $(grep $1 /proc/mounts) ]] && exit 1
[ -d /media/cardreader ] || /bin/mkdir -p /media/cardreader
/bin/mount $1 /media/cardreader -o rw
/bin/chmod 777 /media/cardreader

Genau dieser Punkt muss als erstes einwandfrei und zuverlässig funktionieren.... aber auch nichts mehr und anderes darüber hinaus. Und wenn es das tut, beschäftigen wir uns mit dem Kopie-Job...... aber eben NICHT vorher oder jetzt schon und auch nicht in diesem Script.... das ist imho quatsch....

Und noch größerer Quatsch ist es, den Kernel oder die Udev-Version anzuzweifeln. Dein Problem ist einfach mit den vorhandenen Bordmitteln zu lösen.

[TomL]

Sleep ist erst mal ein Programm, und das braucht eine PID, und stirbt, wenn die PID gekillt wird. Die interne Implementierung ist da zweitrangig und das Aufräumen ein Problem des Kernels.

Ja, damit wirst Du wohl Recht haben.

Ach, TomL, woran ich auch noch knabbere ist das hier:

Code: Alles auswählen

setsid /opt/bin/goprosync.sh > setsid.log

Wer schreibt da eigentlich in setsid.log? Die ausführende Shell? Oder das forkende setsid? Oder das goprossync.sh? Und was passiert, wenn die ausführende Shell gekillt wird? Vielleicht magst du das noch mal mit deinem sleep-Beispiel nachstellen.
Eomer, du könntest es mal ohne das "> setsid.log" testen.

Ich halte es für vertane Zeit und für absolut sinnlos, das noch weiter zu verfolgen. Was soll das anderes bringen, als im Idealfall die Richtigkeit der Man-Page zu bestätigen? Vor allem vor dem Hintergrund, dass das doch eigentlich auf anderem Wege ganz easy zu lösen ist.

[TomL]

@eomer

Wenn man sich jetzt erst mal nur mit myfork.sh beschäftigt, dann könnte man imho auch noch zusätzlich Fragen beantworten.

Soll myfork.sh nach dem "Remove'" des Gerätes eigentlich auch wieder aufräumen? Also z.B. nach dem Remove des Geräte den extra angelegten Mount-Point wieder entfernen?

Warum soll myfork.sh nicht auch andere Sticks verwalten, die keine spezielle Nachbehandlung erfordern und diese einfach nach /media/sd?? mounten? Bei mir war es früher so, dass der automounter beim Plug-In eines Sticks ein Verzeichnis /media/thomas/12394-341-53767-8685-875 angelegt hat. Das hat mich total genervt und ich habs so geändert, dass immer alle Sticks /media mit dem gerade aktuellen Device-Namen gemountet wird.

[Eomer]

Genau das versuche ich ja
Ich habe es nur probiert, damit NAB debuggen kann

Also ich habe das Mount-Script (myfork) auf das wesentliche gekürzt (wie du oben geschrieben hast) und es funktioniert in 3 von 3 versuchen.

Deinen Vorschlag, dass myfork aufräumt und auch andere Sticks nach /media// mountet finde ich gut!

[TomL]

Ok, dann lösen wir das jetzt... und erst mal nichts anderes..... vorab eine kurze Erklärung zu meinen eigenen Anforderungen beim Umgang mit USB-Sticks und Card-Readern. Ich nutze nämlich ebenfalls beides.

Also... ich verwende normale USB-Sticks zum einen als Speicher, die ganz normal nach /media mit ihrem Device-Namen gemountet werden sollen.... um eben solche Konstrukte "/media/thomas/12394-341-53767-8685-87", die jedes Mal anders sind, zu vermeiden. Ein Stick mit dem Kernel-Namen "sdb" und einer Partition sdb1 wird also nach /media/sdb1 gemountet. Ein weiterer Stick mit zwei Partitionen würde bei gleichzeitigem Plug-In sdc heissen, die beiden Partitionen sdc1 und sdc2. Gemountet würden die nach /media/sdc1 und /media/sdc2. Jetzt noch eine USB-Harddisk angeschlossen, die würde nach /media/sdd? gemountet werden, in Abhängigkeit von den vorhandenen Partitionen. Ok, ich denke mal, das war jetzt nicht so schwer.

Jetzt habe ich noch besondere Sticks bzw. Partitionen auf Sticks und SD-Cards, die als Key-Sticks zum entschlüsseln von Luks-Containern oder verschlüsselten Hard-Disk-Partitionen verwendet werden. Ich nutze das auf Reisen mit meinem Notebook, wo die Datenpartition verschlüsselt ist und nur mit eingestecktem Stick zugänglich ist. Diese Sticks bzw. Partition sollen nicht nach /media gemountet werden, sondern konstant in mein Homedir, und zwar nach /home/thomas/.keys. Gerade für diesen Ordner ~/.keys gibt es auch weitere Jobs, die genau diesen Ordner erwarten....weil sie die benötigten Schlüssel eben dort finden können. Die Anforderung hat bezogen auf diesen Faktor also große Ähnlich mit Deiner.... konstanter Mount-Point... und nachgeschaltete Jobs, die diesen Mount-Point verwenden, wie z.B. Cryptsetup, OpenVPN.

Und wenn ich die Sticks wieder abziehe, dann soll gefälligst auch wieder aufgeräumt werden und die temporär angelegten Mount-Points sicher entfernt werden.

Sind Dir diese Zusammenhänge jetzt klar..... alles verstanden?

[Eomer]

Klingt prima. Auf Reisen kommt die ssd dran, sie nach Möglichkeit auch verschlüsselt sein sollte, daher passt das auch alles zu meinen Anforderungen!
Und ja, verstanden. Inzwischen sind mir auch alle Zusammenhänge (UDEV/scripts etc.) klar

[TomL]

Ok, dann kommt jetzt eine erste Änderung.... vergiss Dein myfork.sh.... und lösch es, wenn das neue Handling läuft.

Ich nutze für die USB-Mounts ein eigenes Script "usbmount", abgelegt in "/usr/local/bin". Warum dort ...?... weil es Bestandteil des Suchpfades ist und weil dieser Ort imho dafür vorgesehen ist. /opt ist meiner Meinung nach eher unpassend und sollte Binaries vorbehalten sein, die nicht aus dem Debian-Repo kommen. Wirf mal einen kurzen Blick auf die Debian-Dir-Hierarchie:
https://wiki.debian.org/FilesystemHierarchyStandard

Erstelle also zuerst das neue Script:

Code: Alles auswählen

nano /usr/local/bin/usbmount

und füge mit shift+strg+v den folgenden Bash-Code ein:
Script wegen Nachfolgeversion entfernt! Siehe aktuell:
viewtopic.php?f=34&t=160495&start=150#p1088438

Code: Alles auswählen

entfernt

Das Script wird vom Udev-Handler aufgerufen und macht nichts anderes, als ein USB-Device bei "Add" zu mounten und bei "Remove" wieder aufzuräumen. Ist ein besonderes Verzeichnis erwünscht und wenn dieses Verzeichnis als dritter Parameter übergeben wurde, wird das angelegt und verwendet. Wenn $3 jedoch leer ist, wird einfach nach /media/sd?? gemountet. Vergleiche dazu die udev-Rules.

Das Anlegen des Scripts geht natürlich auch problemlos mit Notepad, den Du ja nutzt und gut kennst. Du musst in dem Script allerdings eine Sache ändern, und zwar den Text "thlu" in den Logging-Statements auf Deine Anforderungen anpassen. Warum steht da "thlu"...?... ganz einfach, das sind meine Namens-Initialen, mit denen ich ganz schnell eben im Journal die eigenen Messages nachlesen kann. Mit diesem Befehl filtere ich NUR Messages, die von meinen eigenen Jobs erzeugt werden:

Code: Alles auswählen

journalctl -b | grep thlu

Nach dem Anlegen der Datei nicht vergessen die Rechte zu setzen:

Code: Alles auswählen

chmod 755 /usr/local/bin/usbmount
chown root:root /usr/local/bin/usbmount

Den owner auf root zu setzen ist aus Sicherheitsgründen wichtig und imho zwingend, damit niemand mit Deinem Account ein Script manipulieren kann, welches vielleicht Dir gehört, aber mit root-Rechten ausgeführt wird. Also solche Scripte gehören IMMER root und nur root darf sie ändern.

Das ist meine udev-Regel:

Code: Alles auswählen

nano /etc/udev/rules.d/99-usbmount.rules

Script wegen Nachfolgeversion entfernt! Siehe aktuell:
viewtopic.php?f=34&t=160495&start=150#p1088438

Code: Alles auswählen

entfernt!

Wie Du siehst, enthält die Datei Verschiedenes.... als erstes den Hinweis zu Erinnerung, bei Änderungen zu reloaden. Als zweites die auskommentierte und jetzt ungenutze Regel mit den Trace-Infos, die ich nur bei neuen Devices einmal kurz verwenden werde. Als drittes die besondere Behandlung besonderer Sticks... eben dieses ~/.keys-Verzeichnis. Und als letztes, alles andere mit dem jeweiligen Kernel-Namen nach /media/sd?? zu mounten.

Und jetzt musst Du noch Deine bestehende Regel entweder oben als ersten anfügen, dabei den Goto-Jump nicht vergessen und am besten meine .Key-Regeln mal eben mit '#' auskommentieren... und dann nach dem Reload probieren, obs rennt.... mit verschiedenen Sticks. Dann schauen wir weiter.

[TomL]

Kleine nachgetragene Erklärung.... wegen des Handlings mit der SD-Card und den Sticks. Die SD-Card steckt zu Hause immer drin und kann sofort die Platte entschlüsseln. Auf Reise verschwindet die SD-Card im Portemonnaie und bei Bedarf wird eben ein Stick mit den benötigten Keys eingesteckt und hinterher wieder entfernt. Warum der Unterschied...?... zuhause verschwindet die SD-C komplett im Gehäuse und beansprucht nicht den Port mechanisch... mit biegen und brechen beim rumtragen. Und im Garten isses schlichtweg blöd festzustellen, dass ich mal wieder den Key-Stick irgendwo 'oben' vergessen habe.

PS.... kopiere das Script jetzt noch mal... falls Du es schon kopiert haben solltest... sorry.... ich hatte an einer Stelle noch mal geändert.... war zwar unwichtig... aber trotzdem..... manchmal fallen mir Dinge erst auf, wenns leider schon zu spät ist....

[Eomer]

Hey Tom,

erst einmal vielen Dank für Deine Mühen und für das Teilen Deiner Scripte

Ist das richtig so?

Code: Alles auswählen

KERNEL=="sd??", ACTION=="add",  SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /usr/local/bin/usbmount add  /dev/%k /media/cardreader", GOTO="rules_end"

Code: Alles auswählen

KERNEL=="sd??", ACTION=="remove",  SUBSYSTEM=="block", ENV{ID_SERIAL_SHORT}=="000000000039", RUN+="/bin/bash /usr/local/bin/usbmount remove /dev/%k /media/cardreader", GOTO="rules_end"

So passt es oder? Stick wird auf jeden Fall richtig gemountet.
Blöde frage: Wie umounte ich den Stick denn jetzt? Einfach normal über sudo umount /media/cardreader?

[TomL]

So passt es oder? Stick wird auf jeden Fall richtig gemountet.

Wenn es funktioniert, ist es richtig gemacht. Aber verlangt das rsync-Script nicht ein anderes Verzeichnis... irgendwas mit gopro...?

Blöde frage: Wie umounte ich den Stick denn jetzt? Einfach normal über sudo umount /media/cardreader?

Ja, klar, ganz normal.... beim Abziehen des Sticks danach werden die erstellten Mount-Points automatisch entfernt. Aber warum sudo? Musst Du danach ein Password eingeben oder hast Du dich speziell für umount in der sudoers berechtigt oder vielleicht sogar komplett für alles?

Ok... noch was anderes.... ... ich habe gerade ziemlich blöd geguckt, als ich bemerkt habe, dass gewisse Filesysteme (vfat) auf dem USB-Stick immer read-only gemountet werden. Sowas bescheuertes.... das ist mir nie aufgefallen, weil ich zuerst die Sticks mit meinen Key-Files bestückt habe und dann dazu ne passende Regel erstellt habe. Offensichtlich hats der automounter also anders gehandhabt, als mein Script. Deswegen habe ich da noch mal nachjustiert und den Bash-Code oben im Posting ausgetauscht. Da ich aber nur ext4 und vfat verwende und noch einen Debian-Install-Stick, konnte ich nur 3 Filesysteme berücksichtigen. Im Moment weiss ich gar nicht, ob ich da jetzt noch nen Fehler drin habe.... aber alle Sticks werden passend gemountet, sie gehören zwar root, aber ext4 und vfat sind für User schreibbar. ... sorry, kann passieren... das solltest du also auch austauschen.

Deswegen sagte ich vor einigen Postings... es passieren beim Ändern immer Fehler, an die man unmöglich denkt....

[Eomer]

Wenn es funktioniert, ist es richtig gemacht. Aber verlangt das rsync-Script nicht ein anderes Verzeichnis... irgendwas mit gopro...?

Das ist egal, das Script habe ich schon auf /media/cardreader geändert.

Ja, klar, ganz normal.... beim Abziehen des Sticks danach werden die erstellten Mount-Points automatisch entfernt. Aber warum sudo? Musst Du danach ein Password eingeben oder hast Du dich speziell für umount in der sudoers berechtigt oder vielleicht sogar komplett für alles?

Okay, ich habe halt keine Tastatur am Pi. Vllt. mache ich mir ein kleines unmount-only script auf den Desktop für den Touchscreen.
Mit dem sudo....Standardkonfiguration. Für alles berechtigt.

Ok... noch was anderes.... ... ich habe gerade ziemlich blöd geguckt, als ich bemerkt habe, dass gewisse Filesysteme auf dem USB-Stick immer read-only gemountet werden. Sowas bescheuertes.... das ist mir nie aufgefallen, weil ich zuerst die Sticks mit meinen Key bestückt habe und dann dazu ne passende Regel erstellt habe. Offensichtlich hats der automounter also anders gehandhabt, als mein Script. Deswegen habe ich da noch mal nachjustiert und den Bash-Code oben im Posting ausgetauscht. Da ich aber nur ext4 und vfat verwende und noch einen Debian-Install-Stick, konnte ich nur 3 Filesysteme berücksichtigen. Im Moment weiss ich gar nicht, ob ich da jetzt noch nen Fehler drin habe.... aber alle Sticks werden passend gemountet, sie gehören zwar root, aber ext4 und vfat sind schreibbar. ... sorry, kann passieren... das solltest du also auch austauschen.

Ist doch kein Problem. Schon geändert. Ich nutze tatsächlich fast nur exfat und ntfs. Was sollte ich da machen?

LG

[TomL]

Ist doch kein Problem. Schon geändert. Ich nutze tatsächlich fast nur exfat und ntfs. Was sollte ich da machen?

Keine Ahnung.... ich würde jetzt sagen, im journal müsste gemäß der Case-Option im Script der Hinweis stehen "Undefined Filesystem-Type" und es ist nicht gemountet. Kannst Du mal im journal prüfen, wie da der Log-Eintrag gemacht wurde?

Wahrscheinlich müssen im Script "usbmount" erstmal in den case-Bedingungen die beiden Typen mit passenden Parametern eingetragen werden.... zumindest erst mal grundsätzlich... und dann prüfen, was dabei rauskommt. Wenns read-only ist...*hmmm*... dann muss man ne Lösung suchen, um dem entsprechenden Filesystem-Mounter die passenden Parameter mitzugeben.

Für alles berechtigt.

Wenn damit "ohne Passwortabfrage" gemeint ist, muss Dir klar sein, dass ein "böses" Script/Programm mit Deinem Account auf diesem System komplett alles darf... einschließlich eines denkbaren Zugriffs auf angeschlossene Netzlaufwerke.... und du kriegst nichts davon mit. Das ist schon ein sehr hohes Sicherheitsrisiko.... bzw. die erste weit offene einladende Haustür.......

[Eomer]

Keine Ahnung.... ich würde jetzt sagen, im journal müsste gemäß der Case-Option im Script der Hinweis stehen "Undefined Filesystem-Type" und es ist nicht gemountet. Kannst Du mal im journal prüfen, wie da der Log-Eintrag gemacht wurde?

Also er sagt nur:

Code: Alles auswählen

pi@raspberrypi:/media/sda1 $ sudo journalctl -b | grep nk
Apr 20 18:42:02 raspberrypi kernel: Initializing XFRM netlink socket
Apr 20 18:42:02 raspberrypi kernel: mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
Apr 20 18:42:02 raspberrypi kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Apr 20 18:42:02 raspberrypi kernel: mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
Apr 20 18:42:02 raspberrypi kernel: mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
Apr 20 18:42:04 raspberrypi kernel: fbtft: module is from the staging directory, the quality is unknown, you have been warned.
Apr 20 18:42:04 raspberrypi kernel: fb_hx8357d: module is from the staging directory, the quality is unknown, you have been warned.
Apr 20 18:42:07 raspberrypi kernel: IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Apr 20 18:42:07 raspberrypi lightdm[549]: ** (lightdm:549): WARNING **: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Apr 20 18:42:09 raspberrypi lightdm[549]: ** (process:736): WARNING **: Error getting user list from org.freedesktop.Accounts: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Accounts was not provided by any .service files
Apr 20 23:09:29 raspberrypi nk:usbmount[2744]: Action=remove   Device=/dev/sdb1   MountTo=/media/sdb1
Apr 20 23:09:29 raspberrypi nk:usbmount[2751]: /usr/bin/udisksctl unmount -b /dev/sdb1 --force    (RC umount=1)
Apr 20 23:09:33 raspberrypi nk:usbmount[2779]: Action=add   Device=/dev/sdb1   MountTo=/media/cardreader
Apr 20 23:09:35 raspberrypi nk:usbmount[2794]: Model: ATTRS{model}=="SD Transcend "  Serialid: ATTRS{serial}=="000000000039" ATTRS{serial}=="3f980000.usb"
Apr 20 23:09:35 raspberrypi nk:usbmount[2803]: /bin/mount /dev/sdb1 /media/cardreader    (FSType=vfat)  (RC mount=0)
Apr 20 23:17:46 raspberrypi nk:usbmount[2953]: Action=remove   Device=/dev/sdb1   MountTo=/media/sdb1
Apr 20 23:17:46 raspberrypi nk:usbmount[2959]: /usr/bin/udisksctl unmount -b /dev/sdb1 --force    (RC umount=1)

Wahrscheinlich müssen im Script "usbmount" erstmal in den case-Bedingungen die beiden Typen mit passenden Parametern eingetragen werden.... zumindest erst mal grundsätzlich... und dann prüfen, was dabei rauskommt. Wenns read-only ist...*hmmm*... dann muss man ne Lösung suchen, um dem entsprechenden Filesystem-Mounter die passenden Parameter mitzugeben.

Ein Problem kommt selten allein

Wenn damit "ohne Passwortabfrage" gemeint ist, muss Dir klar sein, dass ein "böses" Script/Programm mit Deinem Account auf diesem System komplett alles darf... einschließlich eines denkbaren Zugriffs auf angeschlossene Netzlaufwerke.... und du kriegst nichts davon mit. Das ist schon ein sehr hohes Sicherheitsrisiko.... bzw. die erste weit offene einladende Haustür.......

Ja das meinte ich. Danke für den Hinweis. Mit Sicherheit unter Linux bin ich schon etwas vertrauter
Hängt auch nur bei mir hinterm NAT und nicht von außen erreichbar. Bevor der seinen ersten Kontakt mit öffentlichen Hotspots etc. macht, wird der entsprechend abgesichert.
Die Scripte schaue ich mir ja zumindest immer an ob da etwas ungewöhnliches zu sehen ist

[TomL]

Hi
Bin gerade am Handy und sehe den journal-auszug...*lol*... ich würde empfehlen, das 'nk' auf 4 Zeichen zu erweitern. Dann ist die Trefferquote deutlich besser und es wird weniger unnötiges angezeigt.

Aber auf den ersten Blick scheint es, dass das Device als vfat erkannt wird. Damit sollte es doch keine Probleme geben.

Aber der umount war nicht erfolgreich. Der Returncode 1 deutet auf einen Fehler hin. RC 0 = ok !

[Eomer]

Hi
Bin gerade am Handy und sehe den journal-auszug...*lol*... ich würde empfehlen, das 'nk' auf 4 Zeichen zu erweitern. Dann ist die Trefferquote deutlich besser und es wird weniger unnötiges angezeigt.

Aber auf den ersten Blick scheint es, dass das Device als vfat erkannt wird. Damit sollte es doch keine Probleme geben.

Aber der umount war nicht erfolgreich. Der Returncode 1 deutet auf einen Fehler hin. RC 0 = ok !

Okay, mache ich gleich. Was kann man gegen den Fehler tun?

EDIT: abgeändert!

[NAB]

Eomer, erst mal müsste man ne Fehlermeldung haben. Guck mal in die Ausgabe von "dmesg". Sonst probier mal einen manuellen umount.

Hier:
viewtopic.php?f=34&t=160495&start=60#p1087883
Hattest du übrigens schon mal ein defektes FAT-Dateisystem ... "Volume was not properly unmounted. Some data may be corrupt. Please run fsck.". Das kann harmlos sein, es kann aber auch Probleme machen:
https://bbs.archlinux.org/viewtopic.php?id=163553