Anbei ein kleines Skript, das ich mir zusammengebastelt habe, um mit dem Hotplug-Pfad spielen zu können.
Man beachte, dass .hot und .init Dot-Dateien sind. Das ist Absicht, da in dem Verzeichnis Unterverzeichnisse mit diversen Namen optional dazukommen können. Wem ein anderer Basisfpfad als /mod/hot lieber ist, der ändere in der .hot-Datei auch HOT=/mod/hot entsprechend.
Ist das Skript wie beschrieben aktiviert, sollte sich erst einmal gar nichts ändern. Es passiert erst dann etwas, wenn in /mod/hot weitere Dateien angelegt werden.
Immer und als erstes bei jedem hotplug-Request ausgeführt wird .init. Wenn dort befunden wird, dass irgend eine Datei /mod/hot/.debug existiert (touchen reicht), tut sich etwas. Ab dann werden in /tmp/hotlog.* pro Hotplug-Request diverse Dinge in jeweils separate Dateien mit langen Namen weggeschrieben. Ausserdem gibt es pro Request zwei Zeilen syslog.
Wem das Verhalten nicht passt, kann das .init File anpassen.
Am operativen Verhalten sollte sich immer noch nichts ändern, sprich der normale AVM-Kram weiter ausgeführt werden. Soweit also reines Debugging. Interessant wird es jetzt:
Das so geschriebene Skript wird nun immer ausgeführt, wenn ein Hotplug-Request
mit SUBSYSTEM=usb ankommt. Und zwar vor dem AVM-Krempel.
... ich hoffe, die "generelle Idee" ist klar geworden. SUBSYSTEM und PRODUCT sind natürlich Environmentvariablen, wie sie der Kern zu den Hotplug-Events liefert. In den /tmp/hotlog.* Dateien direkt am Anfang zu finden. Was dort steht, kann nach dem gezeigten Schema auch hierarchich zur Ausführung von Skripten führen.
Noch ein paar Details:
Meine beiden akuten Anwendungen für das Geraffel sind zum einen ein kleines Dongle, mit dem ich zwischen zwei iptables-Rulesets (normal und failsafe/lockdown) umschalte, indem ich es ziehe und stecke (und auch noch in den richtigen Hub-Port!
- und ausserdem will ich via DEVPATH-Auswertung einzelne Hub-Ports ganz von dem AVM-usb.pandu und damit normalen mount-Geraffel ausnehmen können.
Viel Spass mit dem Skript, falls jemand damit etwas anfangen kann.
Patrick
Code:
# mkdir /mod/hot && cd /mod/hot
/mod/hot# gzip < /irgendwoher/hot.plug.gz [COLOR=green]/mod/hot/.hot[/COLOR]
/mod/hot# gzip < /irgendwoher/hot.init.gz [COLOR=red]/mod/hot/.init[/COLOR]
/mod/hot# chmod 700 [COLOR=green] /mod/hot/.hot[/COLOR]
/mod/hot# chmod 600 [COLOR=red] /mod/hot/.hot[/COLOR]
/mod/hot# mount --bind [COLOR=green]/mod/hot/.hot[/COLOR] /sbin/hotplugMan beachte, dass .hot und .init Dot-Dateien sind. Das ist Absicht, da in dem Verzeichnis Unterverzeichnisse mit diversen Namen optional dazukommen können. Wem ein anderer Basisfpfad als /mod/hot lieber ist, der ändere in der .hot-Datei auch HOT=/mod/hot entsprechend.
Ist das Skript wie beschrieben aktiviert, sollte sich erst einmal gar nichts ändern. Es passiert erst dann etwas, wenn in /mod/hot weitere Dateien angelegt werden.
Immer und als erstes bei jedem hotplug-Request ausgeführt wird .init. Wenn dort befunden wird, dass irgend eine Datei /mod/hot/.debug existiert (touchen reicht), tut sich etwas. Ab dann werden in /tmp/hotlog.* pro Hotplug-Request diverse Dinge in jeweils separate Dateien mit langen Namen weggeschrieben. Ausserdem gibt es pro Request zwei Zeilen syslog.
Wem das Verhalten nicht passt, kann das .init File anpassen.
Am operativen Verhalten sollte sich immer noch nichts ändern, sprich der normale AVM-Kram weiter ausgeführt werden. Soweit also reines Debugging. Interessant wird es jetzt:
Code:
/mod/hot# mkdir SUBSYSTEM
/mod/hot# cat >SUBSYSTEM/usb.init
was auch immer an shellskript ihr euch ausdenkt...
^DDas so geschriebene Skript wird nun immer ausgeführt, wenn ein Hotplug-Request
mit SUBSYSTEM=usb ankommt. Und zwar vor dem AVM-Krempel.
Code:
/mod/hot# mkdir SUBSYSTEM/usb/PRODUCT
/mod/hot# cat >SUBSYSTEM/usb/PRODUCT/529_31b_100.init
was auch immer passieren soll, wenn dieses spezielle USB-Produkt rein oder raus geht
^D... ich hoffe, die "generelle Idee" ist klar geworden. SUBSYSTEM und PRODUCT sind natürlich Environmentvariablen, wie sie der Kern zu den Hotplug-Events liefert. In den /tmp/hotlog.* Dateien direkt am Anfang zu finden. Was dort steht, kann nach dem gezeigten Schema auch hierarchich zur Ausführung von Skripten führen.
Noch ein paar Details:
- Wo immer es .init Dateien gibt, kann es auch eine .exit Datei geben. Im Beispiel wird usb.init immer ausgeführt vor usb/PRODUCT/..., und usb.exit würde danach ausgeführt. .init -> preorder, .exit -> postorder
- Wenn die .init / .exit Dateien ein x-bit gesetzt haben, werden sie als Subprozess ausgeführt. Sind sie "nur" lesbar, werden sie als Shellskript gesourcet. Das ist insbesondere deshalb wichtig, weil gesourcete Shellskripte mit export XXX=yyy Environment-Variablen setzen können, die für alle darauffolgenden Skripte (eines Hotplug-Events) sichtbar und wirksam sind.
- Die Unterverzeichnisse, die Environmentvariablen bezeichnen, SUBSYSTEM und PRODUCT in den Beispielen oben, können auch einen numerischen Prefix, gefolgt von einem "-", haben. Also zB. /mod/hot/SUBSYSTEM/usb/10-PRODUCT/... und parallel /mod/hot/SUBSYSTEM/usb/20-DEVPATH. So wie in rc.d lässt sich dadurch eine genehme Abarbeitungsreihenfolge festlegen, wenn man das mal braucht.
- Wenn irgendwo während dem Ausführen der diversen gefundenen .init/.exit-Skripte eine Variable HOT_NOAVM=y gesetzt wurde, dann wird das sonst danach normal laufende AVM-Hotplug-Geraffel unterdrückt.
- Sobald eines der .init/.exit-Skripte eine Variable HOT_DOAVM=y setzt, wird jede weitere (tiefere Verzeichnisse, andere Variablen) Verarbeitung abgebrochen, nur noch die .exit-Skript-Kette im Rücklauf ausgeführt, um die Schachtelung zu wahren. Der Sinn ist, immer in irgendeinem der Skripte ausdrücken zu können "jetzt aber direkt so wie AVM es will machen".
Meine beiden akuten Anwendungen für das Geraffel sind zum einen ein kleines Dongle, mit dem ich zwischen zwei iptables-Rulesets (normal und failsafe/lockdown) umschalte, indem ich es ziehe und stecke (und auch noch in den richtigen Hub-Port!
- und ausserdem will ich via DEVPATH-Auswertung einzelne Hub-Ports ganz von dem AVM-usb.pandu und damit normalen mount-Geraffel ausnehmen können.Viel Spass mit dem Skript, falls jemand damit etwas anfangen kann.
Patrick
