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

videovigilancia .

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

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.

1 – Como saber cuanto ocupa una carpeta en Linux.

¿Cuantas veces necesitaste conocer cuanto espacio ocupa un directorio en particular? Desde la consola al ejecutar «du» por «Disk Ussage«:

~ # du /home/dvr/video/movie/

Te devuelve el tamaño en bloques del directorio en cuestión:

48004   /home/dvr/video/movie/

Como al sistema de archivos lo formateé en su momento con un tamaño de bloque de 1024 bytes –Por defecto se usan 4096 bytes si no se especifica un valor diferente para el parámetro en el argumento de la utilidad que formatea-, la cuenta es facil: 48004 bloques de 1024 bytes cada uno suman 49156096 bytes.

Como no podía ser de otra forma, para no tener que andar haciendo cálculos estrambóticos, se le puede pasar a la utilidad como argumento «-h» por «Human Readable»  para que devuelva el resultado en formato entendible por humanos:

~ # du /home/dvr/video/movie/ -h
47M     /home/dvr/video/movie/

Como el comando es recursivo, puede que te interese además agregarle la opción «-s» por «silent» para que cuando tenga que navegar muchos subdirectorios para sacar la cuenta no te llene la pantalla de texto. La otra muy util que tiene de entre tantas opciones disponibles es la posibilidad de producir un «gran total» con la opción «-c«, por ejemplo:

~ # du /home/dvr/video/movie/ -csh
47M     /home/dvr/video/movie/
47M     total

2 – Conocer el espacio utilizado/disponible por partición

Con la salida en modo «bloques» para el comando «df» por «Disk Free«:

~ # df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda3              9297812   1988296   6837208  23% /
/dev/sdb1               397475    295084     75886  80% /usr/portage
/dev/sdb2             78628740   6382688  72246052   9% /home

O en modo «Human Readable» pasándole el argumento «-h«:

~ # df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda3             8.9G  1.9G  6.6G  23% /
/dev/sdb1             389M  289M   75M  80% /usr/portage
/dev/sdb2              75G  6.1G   69G   9% /home

3 – Gráficos en la consola

Por ultimo la frutillita del postre, el que uso todo el tiempo, powered by python, «pydf«:

pydf en funcionamiento, mas gráfico imposible (para ser en consola).

pydf en funcionamiento, mas gráfico imposible (para ser en consola).

Cada quien sabrá como lo instala con el gestor de paquetes de su distribución de cabecera, en Gentoo es tan simple como ejecutar:


~ # emerge pydf

Como seguramente habrá mas aplicaciones que no conozco, ¿Conocen ustedes algo mejorcito que pydf?

¿Quién no se manda una metida de pata cada tanto? Yo tengo varias de diversa índole en prácticamente todos los aspectos de la vida. Estas son las mejores que puedo recordar que me hayan pasado en Linux tipeando comandos en la consola:

haha_nelson

Ejecutar comandos en el host equivocado:

Ejecutar un comando creyendo estar en la consola local cuando en realidad se trataba de una jaula chroot o un host remoto:

# reboot

# halt

# killall (nombre de proceso importante)

De a poco se me ha hecho costumbre cambiarle el nombre al shell ni bien inicio sesión remotamente. Si me logueo en un Host cuyo nombre es pepito, renombro el prompt para que lo refleje:

# export PS1=”[pepito] $PS1”

Cambiar el puerto del servidor SSH

Eso, por muy boludo que suene ya me pasó unas dos o tres veces cambiar el puerto en el que escucha el servidor SSH y olvidarme de modificar el reenvío de puertos en el router que hace NAT o en el Firewall con lo que me encierro solo del lado de afuera y no puedo volver a conectarme remotamente:

# echo “Port 12345” >> /etc/ssh/sshd_config && /etc/init.d/sshd restart

De ahí viene la costumbre que tengo de instalar una VPN que traspase el firewall en cuanto servidor tengo bajo mi control.

Bajar la interface WAN en lugar de la LAN

Estando logueado por SSH, en lugar de bajar eth1 que era la interface LAN, bajé eth0 que era la WAN. El servidor se queda sin internet, yo me quedo fuera sin conexión. El servidor está a 70 kilómetros de distancia y es domingo a la siesta, nada mas que hacer hasta el lunes a la mañana en que alguien físicamente pueda solucionar el “problemita” reinciando el servidor o levantando eth0 nuevamente.

ifconfig eth0 down

Desde entonces tengo la costumbre de usar variables para asignarle nombres a las interfaces de red y usar la variable en lugar del nombre en el script:

export wan=eth0

Compilar mal el kernel

En un servidor remoto, compilar mal el kernel y reiniciar para probarlo resultando en un kernel panic o en quedarme sin conectividad en el servidor imposibilitando la reconexión remota por SSH para verificar los cambios.

make –j4 && make modules_install && cp arch/i386/boot/bzImage /boot/kernel && reboot

Desde entonces, si necesito reiniciar un host linux que no se si va a volver a la vida después del reboot uso una combinación de este watchdog en caso de pérdida de conectividad con este sistema de reinicio automático en caso de kernel panic y el método fallback que provee grubya voy a escribir al respecto alguna vez– para asegurarme de que si algo me salió mal, el equipo se reinicie solo volviendo a usar la configuración anterior en donde todo funcionaba.

Echando a perder se aprende, ¿Vieron?