Algunas cosas son mas complicadas en Linux. Poner a funcionar un dispositivo USB hace algunos años en Linux era lísa y llanamente un dolor de bolas. De esa época aprendí que el comando lsusb sirve para listar los dispositivos conectados a los puertos USB y que cada dispositivo, como si fuera una especie de MAC Address tiene un identificador único:

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

El ID que en este caso es 1d6b:0002 es único y es el mismo tanto para Linux como para Windows, aun que la connotación sea diferente. De tener que lidiar con identificadores USB aprendí que a veces, cuando no queda otra, buscar en Google por identificador es la mejor opción. Es mas, aveces, es la única opción.

Me pasó ayer. Necesitaba instalar uno de esos cables adaptadores de USB a puerto serial, los usb2com o usb2vcom que le dicen por las siglas de “USB a Virtual Com Port”. Resulta que el que fabricó el cable –y la renegrida concha de su madre– no tuvo a bien incluir un cd o minicd con el driver, Ni siquiera tuvo a bien incluír una página web desde donde se pudiera descargar el puto driver. Supuestamente era un adaptador “Plug n Play”, No installation Required.

Plug and PLay las pelotas.

No hubo poder de Dios que hiciera funcionar el cable, ni en Windows XP, ni en Windows 7, ninguno de los dos tenía el driver incorporado, no había forma de descargarlo desde la página web del fabricante, no podía leer el chipset interno (dentro de la ficha DB9) para poder saber con que estaba lidiando, estaba por ir a comprar otro cable de alguna marca mas seria cuando me iluminé.

Panel de control / Sistema / Hardware / Administrador de dispositivos, propiedades del cable en cuestión:

id_usb

Para el ejemplo estoy mostrando el de mi webcam, pero en el caso del cable, el VID & PID respectivamente rezaban:

USB\VID_067B&PID_2303

That´s it, eso es todo. No se necesita mas que googlear buscando lo anterior para llegar a la página web del fabricante del chipset que en mi caso es un tal “Prolific”, el que le vende al fabricante del cable, y descargar desde ahi un driver universal para el mismo:

http://www.prolific.com.tw/eng/downloads.asp?id=31

Esto viene mas que bien si ya estás aplicando el método que explico en este artículo anterior para centralizar todos los Logs que generan Linux, Windows y otros dispositivos que pudieras tener pululando en tu red en un solo host, para poder después leerlos cómodamente desde una página web.

Para que veas todo el mundo que te rodea en modo texto, de preferencia verde sobre fondo negro

Para que veas todo el mundo que te rodea en modo texto, de preferencia verde sobre fondo negro

Se puede loguear texto arbitrario a syslog desde cualquier PC corriendo Linux en la red simplemente por medio del comando «logger» (sin las comillas).

La salida de logger va a parar derechito a syslog y es accesible desde /var/log/messages:

~ # logger puto el que lee
~ # tail /var/log/messages

Nov 10 23:30:01 dvr cron[12109]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:40:01 dvr cron[12161]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:46:25 dvr root: puto el que lee

Hasta ahí nada de otro mundo, un comando que por si solo no tiene mucha magia, manda texto al syslog, ¿Y?

Por si solo no resalta en absoluto pero: ¿Qué pasa cuando necesitás loguear a syslog la salida de un comando cualquiera que por defecto va a la pantalla y no a syslog?

¡Bingo! Usando un pipe es cuestión de redireccionar la salida a logger para tenerlo accesible desde /var/log/messages, desde la red en el syslog server y desde la página web para mayor comodidad. Supongamos que quiero loguear la salida de ping a uno de los DNS de google:

~ # ping 8.8.8.8 -c2 | logger
~ # tail /var/log/messages

Nov 10 23:40:01 dvr cron[12161]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:46:25 dvr root: puto el que lee
Nov 10 23:50:01 dvr cron[12220]: (root) CMD (test -x /usr/sbin/run-crons && /usr/sbin/run-crons )
Nov 10 23:56:17 dvr logger: PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
Nov 10 23:56:17 dvr logger: 64 bytes from 8.8.8.8: icmp_req=1 ttl=47 time=178 ms
Nov 10 23:56:18 dvr logger: 64 bytes from 8.8.8.8: icmp_req=2 ttl=47 time=178 ms
Nov 10 23:56:18 dvr logger:
Nov 10 23:56:18 dvr logger: --- 8.8.8.8 ping statistics ---

Nov 10 23:56:18 dvr logger: 2 packets transmitted, 2 received, 0% packet loss, time 1001ms

Nov 10 23:56:18 dvr logger: rtt min/avg/max/mdev = 178.639/178.658/178.677/0.019 ms

Te cambia la vida, ¿No?

A ver cuantos miles de usos le encontrás a esto.

Típico caso: Recuperación de datos, el medio ha sido sobreescrito con información reciente, con lo que no todos los archivos recuperables a bajo nivel salen sanos.

Lo que haría todo el mundo es abrir archivo por archivo de a uno verificando cuales estan sanos y cuales rotos lo que por resumirlo de alguna manera que englobe totalmente el concepto que quiero transmitir: Es un reverendísimo dolor de bolas.

Acción y efecto de probar todos los archivos recuperados uno por uno para detectar de forma manual cuales están corruptos

Acción y efecto de probar todos los archivos recuperados uno por uno para detectar de forma manual cuales están corruptos

Buscar de entre los miles de archivos que nos puedan interesar cuales salieron sanos y cuales se corrompieron de manera manual como hice toda la vida es la parte que mas tiempo y recursos (mentales) consume. Por suerte alguien en los foros de Gentoofuente de eterna sabiduría informática si las hay– tuvo la misma inquietud pero además fué un poco mas inteligente que yo, quería hacerlo automáticamente. Ya de entrada venía bien encaminado cuando dijo:

Hola,

Tengo un respaldo de archivos antiguos de mi trabajo (principalmente MSOffice), en algún momento varios archivos se corrompieron, por lo que hay archivos que se pueden abrir y otros que no hay caso.

Quiero eliminar los archivos corruptos.

Para diferenciarlos de los buenos se me ocurrió utilizar el comando «file»

Ahí fué que se me encendió la lamparita y vengo utilizando este método automático desde entonces exitosamente. Es que el comando «file«, puede diferenciar a la perfección un tipo de archivo de otro con lo que cualquier archivo que estuviera corrupto, ya sea una imagen, un video, música o un documento de office en lugar de ser identificado como corresponde, simplemente figurará como de tipo «data«.

Tan sencillo como eso, eliminar del directorio que contiene los archivos recuperados, todos aquellos que figuren como de tipo «data«, a lo que Stolz, moderador del foro y mago programador de Bash respondió con este sencillo script que navega subdirectorios recursivamente eliminando todos los archivos que sean de tipo «data»:

find . -type f | while read linea; do
  tipo=`file -b "$linea"`
  if [[ $tipo == "data" ]];then
    rm  "$linea"
  fi
done

Paso a paso:

Se crea un archivo dentro de /usr/bin para que contenga al script, lo llamaremos «borrador_de_archivos_corruptos«:

nano /usr/bin/borrador_de_archivos_corruptos

Se copia el contenido del script y se pega dentro del archivo que estamos editando con nano (o el que sea tu editor de texto de cabecera).

Se sale guardando los cambios.

Se convierte el archivo en ejecutable:

chmod +x /usr/bin/borrador_de_archivos_corruptos

Y ya estça listo para usar.

IMPORTANTE: Ejecutar borrador_de_archivos_corruptos únicamente dentro de la carpeta que contiene la información salvada del proceso de recuperación de datos. Ejecutar el script fuera de la misma te va a borrar archivos que son de tipo «data» por que tienen que serlo, te va a hacer mierda todo lo que encuentre a su paso, para que se entienda.

Ya tenés otro motivo mas para tener un Linux siempre a mano.


Si tu disco rígido se ve como este, ni te gastes en seguir leyendo por que no hace falta: ¡Es viejísimo! (Y no, no se pueden recuperar los correos electrónicos que tenías guardados ahí antes del holocausto nuclear)

Si tu disco rígido se ve como este, ni te gastes en seguir leyendo por que no hace falta: ¡Es viejísimo! (Y no, no se pueden recuperar los correos electrónicos que tenías guardados ahí antes del holocausto nuclear).

Este es mas viejo que la escarapela pero se me ocurrió que quizás no todos estén y/o estéan al corriente:

El sistema de automonitoreo y reporte de todos los discos rígidos, S.M.A.R.T. por las siglas en inglés de Self Monitoring And Reporting Tool lleva la cuenta de cuantas horas lleva encendido tu disco rígido. No tengo ni la mas putañera idea de como verificar esto en windows ni me interesa aprender tampoco pero en linux, tirando de la herramienta smartmontools, he aquí los resultados:

Para /dev/sda:

# smartctl -s on /dev/sda && smartctl -a /dev/sda | grep Power_On_Hours

9 Power_On_Hours          0x0012   093   093   001    Old_age   Always       –       4835

Mi disco rígido identificado como /dev/sda lleva un total de 4835 horas funcionando. Si hubieran sido de corrido, haría un total de casi 202 días sin apagarse nunca… Casi un año.

Mi /dev/sdb, por otro lado, Tiene mas agachadas que japonés con visitas:

# smartctl -s on /dev/sdb && smartctl -a /dev/sdb | grep Power_On_Hours

9 Power_On_Hours          0x0012   099   099   000    Old_age   Always       –       9271

Suma el solito 9271 horas, que si fueran todas de corrido harían un total de casi 387 días. Mas de un año.

¿Cuantas veces se apagó y encendió la PC en donde estuvo conectado este disco rígido?

# smartctl -s on /dev/sdb && smartctl -a /dev/sdb | grep Power_Cycle_Count

12 Power_Cycle_Count       0x0032   090   090   008    Old_age   Always       –       7165

Miren si habrá aguantado cascotazos el botón de encendido del gabinete: 7165 veces lo he presionado como mínimo y todavía sigue ahí como si nada. Ni vencido el resorte, ni despintado el plástico, nada… Gabinetes para PC eran los de antes.