Una para que entiendan pocos: Alguien llegó ayer hasta este humilde blog buscando en Google:
“chroot debian testing smstools”
No es por nada, pero si no sabés como implementar una mísera jaula chroot no deberías estar usando Debian testing, es mas, no deberías estar usando Debian. Por otro lado, smstools en una jaula chroot, ¿Para que?
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:
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:
Este (mini)artículo no es mas que una actualización del artículo anterior: [HowTo] Sistema de vigilancia casero basado en Linux usando una webcam
.
En las pruebas que he ido haciendo hasta el momento, después de 15 días de funcionamiento sostenido:
~ # uptime
22:59:32 up 15 days, 7:47, 1 user, load average: 0.31, 0.39, 0.36
Se porta como si recién hubiera arrancado:
~ # free -m
total used free shared buffers cached
Mem: 228 206 21 0 73 90
-/+ buffers/cache: 42 185
Swap: 517 2 515
Hoy cumple exactamente 31 días de grabación de corrido, en estos 31 días, como únicamente graba –y toma instantáneas– a 640×480 si detecta movimiento, me ha generado un total de 154579 archivos entre fotografías y videos, 7Gb de información:
~ # du -sh /home/dvr/video/ 7.3G /home/dvr/video/
Así que con un disco de 80Gb que tiene supera ampliamente mis estimaciones iniciales, tengo para grabar sin tener que borrar nada apróximadamente 10 meses de corrido, mejor que cualquier DVR comprada con disco de 320Gb.
Para ser gratis y casero, nada mal ¿Eh?
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
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.