Udev es el subsistema de Linux que proporciona eventos de dispositivo a su computadora. En lenguaje sencillo, eso significa que es el código que detecta cuando tiene cosas conectadas a su computadora, como una tarjeta de red, discos duros externos (incluidas las memorias USB), mouse, teclados, joysticks y gamepads, unidades de DVD-ROM, etc. sobre. Eso lo convierte en una utilidad potencialmente útil, y está lo suficientemente expuesto como para que un usuario estándar pueda escribirlo manualmente para hacer cosas como realizar ciertas tareas cuando un determinado disco duro está conectado.
Este artículo le enseña cómo crear un script de udev activado por algún evento de udev, como conectar una memoria USB específica. Una vez que comprenda el proceso para trabajar con udev, puede usarlo para hacer todo tipo de cosas, como cargar un controlador específico cuando se conecta un gamepad o realizar una copia de seguridad automática cuando conecta su unidad de copia de seguridad.
Un guión básico
La mejor manera de trabajar con udev es en pequeños fragmentos. No escriba todo el script por adelantado, sino que comience con algo que simplemente confirme que udev activa algún evento personalizado.
Dependiendo de su objetivo para su secuencia de comandos, no puede garantizar que alguna vez verá los resultados de una secuencia de comandos con sus propios ojos, así que asegúrese de que su secuencia de comandos registre que se activó correctamente. El lugar habitual para los archivos de registro es /var. directorio, pero eso es principalmente el dominio del usuario raíz. Para probar, use /tmp , al que pueden acceder los usuarios normales y, por lo general, se limpia con un reinicio.
Abre tu editor de texto favorito e ingresa este simple script:
#!/usr/bin/bash
/usr/bin/date >> /tmp/udev.log
Coloque esto en /usr/local/bin o algún lugar similar en la ruta ejecutable predeterminada. Llámalo trigger.sh y, por supuesto, hacerlo ejecutable con chmod +x .
$ sudo mv trigger.sh /usr/local/bin
$ sudo chmod +x /usr/local/bin/trigger.sh
Este script no tiene nada que ver con udev. Cuando se ejecuta, el script coloca una marca de tiempo en el archivo /tmp/udev.log . Pruebe el script usted mismo:
$ /usr/local/bin/trigger.sh
$ cat /tmp/udev.log
Tue Oct 31 01:05:28 NZDT 2035
El siguiente paso es hacer que udev active el script.
Identificación única del dispositivo
Para que su secuencia de comandos sea activada por un evento de dispositivo, udev debe saber bajo qué condiciones debe llamar a la secuencia de comandos. En la vida real, puede identificar una memoria USB por su color, el fabricante y el hecho de que la acaba de conectar a su computadora. Su computadora, sin embargo, necesita un conjunto diferente de criterios.
Udev identifica los dispositivos por números de serie, fabricantes e incluso números de identificación de producto y de proveedor. Dado que esto es temprano en la vida útil de su script udev, sea lo más amplio, no específico e inclusivo posible. En otras palabras, primero desea capturar casi cualquier evento udev válido para activar su secuencia de comandos.
Con el monitor udevadm comando, puede acceder a udev en tiempo real y ver lo que ve cuando conecta diferentes dispositivos. Conviértete en root y pruébalo.
$ su
# udevadm monitor
La función de monitor imprime eventos recibidos para:
- UDEV:el evento que udev envía después del procesamiento de la regla
- KERNEL:el evento del kernel
Con monitor udevadm en ejecución, conecte una memoria USB y observe cómo se arroja todo tipo de información en su pantalla. Note que el tipo de evento es un ADD evento. Esa es una buena manera de identificar qué tipo de evento desea.
El monitor udevadm El comando proporciona mucha información buena, pero puede verla con un formato más bonito con el comando udevadm info , suponiendo que sepa dónde se encuentra actualmente su memoria USB en su /dev árbol. De lo contrario, desenchufe y vuelva a enchufar su memoria USB, luego emita inmediatamente este comando:
$ su -c 'dmesg | tail | fgrep -i sd*'Si ese comando devuelve sdb:sdb1 , por ejemplo, sabe que el kernel ha asignado a su memoria USB el sdb etiqueta.
Alternativamente, puede usar el lsblk comando para ver todas las unidades conectadas a su sistema, incluidos sus tamaños y particiones.
Ahora que ha establecido dónde se encuentra su unidad en su sistema de archivos, puede ver información udev sobre ese dispositivo con este comando:
# udevadm info -a -n /dev/sdb | lessEsto devuelve mucha información. Concéntrate en el primer bloque de información por ahora.
Su trabajo es elegir partes del informe de udev sobre un dispositivo que sean más exclusivos para ese dispositivo, luego decirle a udev que active su secuencia de comandos cuando se detecten esos atributos únicos.
La información de udevadm procesa informes en un dispositivo (especificado por la ruta del dispositivo), luego "camina" hacia arriba en la cadena de dispositivos principales. Para cada dispositivo encontrado, imprime todos los atributos posibles usando un formato clave-valor. Puede redactar una regla para que coincida según los atributos de un dispositivo más los atributos de un único dispositivo principal.
looking at device '/devices/000:000/blah/blah//block/sdb':
KERNEL=="sdb"
SUBSYSTEM=="block"
DRIVER==""
ATTR{ro}=="0"
ATTR{size}=="125722368"
ATTR{stat}==" 2765 1537 5393"
ATTR{range}=="16"
ATTR{discard\_alignment}=="0"
ATTR{removable}=="1"
ATTR{blah}=="blah"
Una regla udev debe contener un atributo de un único dispositivo principal.
Los atributos principales son cosas que describen un dispositivo desde el nivel más básico, como es algo que se ha conectado a un puerto físico o es algo con un tamaño o este es un dispositivo extraíble .
Desde la etiqueta KERNEL de sdb puede cambiar dependiendo de cuántas otras unidades se conectaron antes de conectar esa memoria USB, ese no es el atributo principal óptimo para una regla udev. Sin embargo, funciona para una prueba de concepto, por lo que podría usarlo. Un candidato aún mejor es el atributo SUBSYSTEM, que identifica que se trata de un dispositivo de sistema de "bloqueo" (por lo que lsblk el comando enumera el dispositivo).
Abra un archivo llamado 80-local.rules en /etc/udev/rules.d e introduce este código:
SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"Guarde el archivo, desconecte su memoria USB de prueba y reinicie.
Espera, reinicia en una máquina Linux?
En teoría, solo puede emitir udevadm control --reload , que debería cargar todas las reglas, pero en esta etapa del juego, es mejor eliminar todas las variables. Udev es lo suficientemente complejo, y no desea estar acostado en la cama toda la noche preguntándose si esa regla no funcionó debido a un error de sintaxis o si simplemente debería haber reiniciado. Así que reinicie independientemente de lo que le diga su orgullo POSIX.
Cuando su sistema vuelva a estar en línea, cambie a una consola de texto (con Ctl+Alt+F3 o similar) y conecte su memoria USB. Si está ejecutando un kernel reciente, probablemente verá un montón de resultados en su consola cuando conecte la unidad. Si ve un mensaje de error como No se pudo ejecutar / usr /local/bin/trigger.sh , probablemente olvidó hacer el script ejecutable. De lo contrario, es de esperar que todo lo que vea sea que se conectó un dispositivo, recibió algún tipo de asignación de dispositivo del kernel, etc.
Ahora, el momento de la verdad:
$ cat /tmp/udev.log
Tue Oct 31 01:35:28 NZDT 2035
Si ve una fecha y hora muy reciente devuelta desde /tmp/udev.log , udev ha activado con éxito su secuencia de comandos.
Refinando la regla en algo útil
El problema con esta regla es que es muy genérica. Conectar un mouse, una memoria USB o la memoria USB de otra persona activará indiscriminadamente su secuencia de comandos. Ahora es el momento de comenzar a concentrarse en la memoria USB exacta que desea activar su secuencia de comandos.
Una forma de hacerlo es con la ID del proveedor y la ID del producto. Para obtener estos números, puede usar el lsusb comando.
$ lsusb
Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub
Bus 003 Device 005: ID 03f0:3307 TyCoon Corp.
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub
Bus 001 Device 003: ID 13d3:5165 SBo Networks
En este ejemplo, el 03f0:3307 antes de TyCoon Corp. denota los atributos idVendor e idProduct. También puede ver estos números en la salida de udevadm info -a -n /dev/sdb | proveedor de grep , pero encuentro la salida de lsusb un poco más agradable a la vista.
Ahora puede incluir estos atributos en su regla.
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/thumb.sh"Pruebe esto (sí, aún debe reiniciar, solo para asegurarse de que está recibiendo nuevas reacciones de udev), y debería funcionar igual que antes, solo que ahora si conecta, digamos, una memoria USB fabricada por una compañía diferente (por lo tanto, con un idVendor diferente) o un mouse o una impresora, el script no se activará.
Siga agregando nuevos atributos para enfocarse más en ese uno memoria USB única que desea activar su secuencia de comandos. Usando udevadm info -a -n /dev/sdb , puede averiguar cosas como el nombre del proveedor, a veces un número de serie o el nombre del producto, etc.
Por su propia cordura, asegúrese de agregar solo un nuevo atributo a la vez. La mayoría de los errores que he cometido (y he visto cometer a otras personas en línea) es arrojar un montón de atributos en su regla udev y preguntarme por qué ya no funciona. Probar los atributos uno por uno es la forma más segura de garantizar que udev pueda identificar su dispositivo con éxito.
Seguridad
Esto plantea las preocupaciones de seguridad de escribir reglas udev para hacer algo automáticamente cuando se conecta una unidad. En mis máquinas, ni siquiera tengo activado el montaje automático y, sin embargo, este artículo propone scripts y reglas que ejecutan comandos con solo tener algo enchufado.
Dos cosas a tener en cuenta aquí.
- Concéntrese en sus reglas de udev una vez que las tenga funcionando para que activen secuencias de comandos solo cuando realmente quieres que lo hagan. Ejecutar un script que copia ciegamente datos hacia o desde su computadora es una mala idea en caso de que alguien que tenga la misma marca de memoria USB lo conecte a su caja.
- No escriba su regla udev y scripts y olvídese de ellos. Sé qué computadoras tienen mis reglas de udev, y esas cajas suelen ser mis computadoras personales, no las que llevo a las conferencias o las que tengo en mi oficina en el trabajo. Cuanto más "social" sea una computadora, es menos probable que obtenga una regla de udev que podría resultar en que mis datos terminen en el dispositivo de otra persona o que los datos o el malware de otra persona estén en mi dispositivo.
En otras palabras, como ocurre con gran parte del poder proporcionado por un sistema GNU, es su trabajo ser consciente de cómo está ejerciendo ese poder. Si abusas de él o no lo tratas con respeto, muy bien podría salir terriblemente mal.
Udev en el mundo real
Ahora que puede confirmar que udev activa su secuencia de comandos, puede centrar su atención en la función de la secuencia de comandos. En este momento, es inútil, no hace más que registrar el hecho de que se ha ejecutado.
Uso udev para activar copias de seguridad automáticas de mis memorias USB. La idea es que las copias maestras de mis documentos activos estén en mi memoria USB (ya que va donde quiera que vaya y se puede trabajar en ella en cualquier momento), y esos documentos maestros se respaldan en mi computadora cada vez que conecto la unidad a esa maquina En otras palabras, mi computadora es la unidad de respaldo y mis datos de producción son móviles. El código fuente está disponible, así que siéntete libre de mirar el código adjunto para ver más ejemplos de cómo restringir tus pruebas udev.
Dado que es para lo que más uso udev, es el ejemplo que usaré aquí, pero udev puede tomar muchas otras cosas, como gamepads (esto es útil en sistemas que no están configurados para cargar el módulo xboxdrv cuando un gamepad está conectado) y cámaras y micrófonos (útil para establecer entradas cuando se conecta un micrófono específico), así que tenga en cuenta que es bueno para mucho más que este ejemplo.
Una versión simple de mi sistema de respaldo es un proceso de dos comandos:
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", SYMLINK+="safety%n"
SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/trigger.sh" La primera línea detecta mi memoria USB con los atributos ya discutidos, luego asigna a la memoria USB un enlace simbólico dentro del árbol de dispositivos. El enlace simbólico que asigna es safety%n . El %n es una macro udev que se resuelve en cualquier número que el kernel le dé al dispositivo , como sdb1, sdb2, sdb3, etc. Así que %n sería el 1 o el 2 o el 3.
Esto crea un enlace simbólico en el árbol de desarrollo, por lo que no interfiere con el proceso normal de conexión de un dispositivo. Esto significa que si usa un entorno de escritorio al que le gusta montar dispositivos automáticamente, no le causará problemas.
La segunda línea ejecuta el script.
Mi secuencia de comandos de respaldo se ve así:
#!/usr/bin/bash
mount /dev/safety1 /mnt/hd
sleep 2
rsync -az /mnt/hd/ /home/seth/backups/ && umount /dev/safety1
La secuencia de comandos utiliza el enlace simbólico, lo que evita la posibilidad de que udev asigne a la unidad un nombre inesperado (por ejemplo, si ya tengo una memoria USB llamada DISK conectada a mi computadora y conecto mi otra memoria USB también llamada DISK, la segunda se etiquetará DISK_, lo que frustraría mi guión). Monta seguridad1 (la primera partición del disco) en mi punto de montaje preferido de /mnt/hd .
Una vez montado de forma segura, utiliza rsync para realizar una copia de seguridad de la unidad en mi carpeta de copia de seguridad (mi secuencia de comandos real utiliza rdiff-backup y la suya puede utilizar cualquier solución de copia de seguridad automatizada que prefiera).
Udev es tu desarrollador
Udev es un sistema muy flexible y le permite definir reglas y funciones en formas que pocos otros sistemas se atreven a proporcionar a los usuarios. Aprenda y utilícelo, y disfrute del poder de POSIX.
Este artículo se basa en el contenido del Manual de Slackermedia, que tiene la licencia GNU Free Documentation License 1.3.