Mit Hotplug spielen

[bof]

Anbei ein kleines Skript, das ich mir zusammengebastelt habe, um mit dem Hotplug-Pfad spielen zu können.

# 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/hotplug

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:

/mod/hot# mkdir SUBSYSTEM
/mod/hot# cat >SUBSYSTEM/usb.init
was auch immer an shellskript ihr euch ausdenkt...
^D

Das so geschriebene Skript wird nun immer ausgeführt, wenn ein Hotplug-Request
mit SUBSYSTEM=usb ankommt. Und zwar vor dem AVM-Krempel.

/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

 

[Silent-Tears]

Wäre es da nicht sinniger gewesen, diverse Anstrengungen zu koordinieren, anstelle vom Neuerfinden des Rades?

 

[hermann72pb]

Verstehe ich das richtig, dass du einen Wrapper für das AVM-Binary hotplug geschrieben hast?
Meine Frage ist, ob es denn wirklich Not tut es mit einem Wrapper zu lösen, oder ob man vielleicht versucht sich in die /etc/hotplug-Skripte zu integrieren. Denn genau da sind die Skripte nach bestimmten Medien unterteilt. Es gibt auch eine Datei, die -glaube ich- unter /etc liegt und die ganzen Hotplug-Anfragen je nach Typ weiterleitet. Hast du dir schon die Sachen angeschaut, oder siehst du da keine Chance?

MfG

 

[bof]

Wäre es da nicht sinniger gewesen, diverse Anstrengungen zu koordinieren, anstelle vom Neuerfinden des Rades?

Dafür sicher nicht. Das waren zwei Tage Fingerübung, die ich für mich gemacht habe, um Box und das Hotplug-Zeug so kennenzulernen, dass ich mich damit wohlfühle. Koordinierende Debatten oder sonstiges hätten mich von dem Ziel nur abgehalten. Die Beiträge von Hermann in den letzten Tagen hatten mir suggeriert dass es an der Ecke eh noch nix fertiges gibt. Und mdev oder gar udev war mir zu fett für das, was ich konkret erreichen wollte.

Ich habe damit nicht unbedingt weiter etwas vor. Aber ich glaube an das Teilen von Code, wenn er einen gewissen Stand an Allgemeinheit erreicht hat. Und sei es nur als Beispiel.

Verstehe ich das richtig, dass du einen Wrapper für das AVM-Binary hotplug geschrieben hast?

Jep.

Meine Frage ist, ob es denn wirklich Not tut es mit einem Wrapper zu lösen, oder ob man vielleicht versucht sich in die /etc/hotplug-Skripte zu integrieren.

Ich wollte bewusst davon die Finger lassen. Klar kann ich da irgendwo passende Stellen finden, um etwas eigenes einzuschieben. Aber das hat viel Beliebiges und bringt dauerhaft Spass bei Änderungen.

Es gibt auch eine Datei, die -glaube ich- unter /etc liegt und die ganzen Hotplug-Anfragen je nach Typ weiterleitet.
MfG

Es gibt einen Fanout für USB-Devices und Classes, um USB-Class/Driver-Bindungen und USB-Device/Modulladerskripte fuer AVM-USB-Devices hinzubekommen. Ich glaube, eigentlich will das heutzutage mit Linux-Bordmitteln ganz anders gemacht werden.

Meinen iptables-Umschalt-Key hätte ich wohl mit einem Eintrag in /etc/usbdevices.tab und einem weiteren /etc/hotplug-Skript abbilden können. "Auf diesen Hub-Ports kein AVM-storage" nur durch Anfassen existierender Skripte.

Gruss
Patrick

 

[olistudent]

Dieses "mount -o bind ..." sollte eigentlich nicht nötig sein. Es gibt eine Variable was bei einem hotplug event ausgeführt werden soll.

/ # cat /proc/sys/kernel/hotplug
/sbin/hotplug

MfG Oliver

 

[bof]

Der mount --bind hat einen Unterschied gegenüber /proc/sys/kernel/hotplug: er erwischt auch Aufrufe aus dem Userlevel, der ja zumindest theoretisch jederzeit /sbin/hotplug von Hand aufrufen könnte.

Praktisch scheint das nicht vorzukommen, bisher habe ich nur Kernelaufrufe gesehen. Aber wenigstens weiss ich das jetzt. Andernfalls hätte ich es nur gehofft

 

[RalfFriedl]

/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]

Funktioniert diese Konstruktion tatsächlich? Bei mir kommt dann

gzip: /mod/hot/.hot: No such file or directory
gzip: /mod/hot/.init: No such file or directory

 

[bof]

Funktioniert diese Konstruktion tatsächlich?

Nö. Ich vermute, dass ich zu sehr damit beschäftigt war, die color-tags zu setzen, um zu merken, dass ich den > vergessen habe...