por ·8 comentarios

Otro título sugerido:

Lo que en Gentoo es facil, en Ubuntu se me complica.

Me he visto en la necesidad de implementar un sistema de videovigilancia para poder monitorear ciertos sectores de mi casa. Como me he cruzado en varias oportunidades con esas DVR de tipo standalone y me ha tocado configurarlas para que salgan a internet he visto que en muchos –si no en todos los– casos estos aparatitos por dentro corren Linux, el típico micro-kernel, busybox, un init a medida, un webserver básico y poca cosa mas.

Ante la disyuntiva «comprar uno de estos DVR vs hacerme uno propio«, de puro chatarrero me decidí por la segunda opción pensando que si un DVR con tan poco hardware puede hacer todo el trabajo, cualquier PC viejita debería darme el mismo resultado.

No es tan así. Un VIA Samuel 2 de 800Mhz (El que se vendía como VIA C3 1500+, básicamente un K6 III de 800Mhz o un Pentium II con esteroides, que ni siquiera es compatible con i686) a duras penas si alcanza para las dos cámaras que le he instalado.

La cuestión es que necesitaba el sistema funcionando, y lo necesitaba inmediatamente –eso fué hace una semana-, así que googleando un poco dí con Zoneminder, un centro de video vigilancia de código abierto con todas las de la ley que no tiene nada que envidiarle a los mejores productos pagos para otras plataformas.

¿Que hace uno cuando necesita un Linux funcionando rápido?

Va por la que debería ser la mas rápida de todas las opciones: Ubuntu

Craso error.

Nuevamente, no es tan así. Necesitaba el sistema implementado de inmediato y ya habían pasado tres días de prueba, google y error. No había conseguido hacer funcionar Zoneminder como debería, me dí cuenta de que por falta de recursos de hardware, puntualmente falta de microprocesador en Ubuntu… Después de limar Ubuntu hasta donde pude, desactivar todo lo que sé que no voy a usar, incluído el entorno gráfico, llegué a un punto en donde perdí conectividad, se rompió la consola de comandos, se rompió la instalación de Xorg, y se rompió al punto donde lo mas rápido era reinstalar que ponerse a reparar…

Como la necesidad tiene cara de hereje, Taringa de por medio, encontré que para windows hay infinidad de programas mucho menos profesionales que Zoneminder pero que en definitiva cumplen la misma función, lo único que necesito: Streaming HTTP de video desde dos Webcams en tiempo real y grabación con detección de movimiento.

Así fué como al cuarto día estaba cometiendo sacrilegio, instalando un Windows XP en la PC para poder grabar video con detección de movimiento.

Dos días mas tarde, todavía estaba peleando contra el crack, el virus que venía en el crack, el overlay que no funcionaba con la placa de video onboard de tan viejo motherboard, el driver de la placa de video a ver si esto mejoraba, al ver que no mejoraba. a cambiar de programa por algún otro que tampoco me convencia y así sucesivamente en un bucle infinito y la cosa se empezaba a poner desesperante.

En medio de todo eso andaba cuando de nuevo gracias a Google dí con un tal Motion.

Llenas las bolas como las tenía me decidí por la que debería haber sido mi primera opción, mi distribución de Linux de preferencia: Gentoo

Obviamente, instalar Gentoo en una PC de estas características lleva su tiempo, casi dos horas hasta tener un sistema autónomo booteable con lo básico para funcionar: El kernel, la red inalámbrica y motion. (De hecho, dos días después, mientras escribo esto, la pobrecita pc todavía está compilando software extra que quiero agregarle).

Una vez compilado el kernel para que tenga soporte para las dos webcams e instalado Motion, en Gentoo al menos, es coser y cantar.

Motion hace exactamente lo que necesito y mas inclusive. Corriendo sobre Gentoo, donde Ubuntu me dejaba sin microprocesador –por tantas pelotudeces que carga en el entorno gráfico y por fuera del mismo-, Gentoo va extra liviano. Con 7 Horas de uptime y mientras corre Motion y compila Samba:

dvr ~ # uptime
00:19:47 up  7:03,  1 user,  load average: 1.61, 1.66, 1.80

dvr ~ # free -m
total       used       free     shared    buffers     cached
Mem:        477480     424776      52704          0      38620     307212
-/+ buffers/cache:      78944     398536
Swap:      1060248        380    1059868

dvr ~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : CentaurHauls
cpu family      : 6
model           : 7
model name      : VIA Samuel 2
stepping        : 3
cpu MHz         : 799.047
cache size      : 64 KB

Por si no se entendió, 134Mb de ram utilizados, nada de Swap todavía, vamos a ver que pasa después de unos cuantos dias.

Tomando un screenshot cada vez que detecta movimiento y filmando además un video en formato mpeg4, después de 24 Hs de funcionamiento continuado me ha generado un total de 164Mb de información:

dvr ~ # du -sh /home/dvr/video/
164M    /home/dvr/video/

Regla de tres simple, tiene un viejo disco de 80Gb nada mas que para almacenar video, a 170Mb de video/fotografías por día promedio, tengo espacio suficiente como para grabar unos 45 días de corrido, un mes y medio. Nada mal para ser que no gasté ni un centavo.

Un poco de información técnica:

Instalar motion en Gentoo es tan simple como ejecutar:

emerge motion

Y esperar a que termine de compilar. La configuración se controla desde el archivo /etc/motion.conf y es autoexplicativa. Usando el viejo truco, he limpiado de comentarios mi archivo de configuración para que vean como me quedó:

dvr ~ # nocomentarios /etc/motion.conf
daemon on
process_id_file /var/run/motion/motion.pid
setup_mode off
videodevice /dev/video0
v4l2_palette 8
input 8
norm 0
frequency 0
rotate 0
width 640
height 480
framerate 24
minimum_frame_time 0
netcam_tolerant_check off
auto_brightness on
brightness 128
contrast 0
saturation 0
hue 0
roundrobin_frames 1
roundrobin_skip 1
switchfilter off
threshold 1500
threshold_tune off
noise_level 32
noise_tune on
despeckle EedDl
smart_mask_speed 0
lightswitch 0
minimum_motion_frames 1
pre_capture 5
post_capture 0
gap 60
max_mpeg_time 0
output_all off
output_normal on
output_motion off
quality 75
ppm off
ffmpeg_cap_new on
ffmpeg_cap_motion off
ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily
ffmpeg_bps 500000
ffmpeg_variable_bitrate 0
ffmpeg_video_codec mpeg4
ffmpeg_deinterlace off
snapshot_interval 0
locate off
text_right %d-%m-%Y\n%T-%q
text_changes off
text_event %Y%m%d%H%M%S
text_double off
target_dir /home/dvr/video
snapshot_filename %v-%Y%m%d%H%M%S-snapshot
jpeg_filename %v-%Y%m%d%H%M%S-%q
movie_filename %v-%Y%m%d%H%M%S
timelapse_filename %Y%m%d-timelapse
webcam_port 8080
webcam_quality 100
webcam_motion off
webcam_maxrate 24
webcam_localhost off
webcam_limit 0
control_port 8081
control_localhost off
control_html_output on
control_authentication usuario:contraseña
track_type 0
track_auto off
track_motorx 0
track_motory 0
track_maxx 0
track_maxy 0
track_iomojo_id 0
track_step_angle_x 10
track_step_angle_y 10
track_move_wait 10
track_speed 255
track_stepsize 40
quiet on
thread /etc/motion1.conf

El archivo /etc/motion1.conf es una copia idéntica del anterior pero tomando video desde /dev/video1 (la segunda webcam).

Las webcams no tienen ninguna ciencia, son las típicas de 640×480 a 30FPS que en windows no necesitan driver ni nada para funcionar. La PC es un CPU sin monitor, ni teclado ni mouse, escondido para que no se vea, conectado a mi red inalámbrica. Tiene dos discos, uno de 10Gb desde donde Bootea y uno de 80Gb para almacenamiento. Tiene también 512Mb de RAM que nunca llegará a utilizar para nada con Gentoo al parecer. Con 128Mb andaría sobrado seguramente.

En definitiva: Si tenés por ahí una webcam y un CPU viejo tirado y necesitás videovigilancia superprofesional: Zoneminder es para sacarse el sombrero. Para uso doméstico, Motion va mas que bien y hasta donde lo he podido probar funciona todo tal y como debería, mejor inclusive que los 6 o 7 programitas diferentes para windows que probé y que supuestamente cumplían la misma función.

¿Lo mejor de todo?

GRATIS

Mi único gasto fueron los cables extensores USB para poder llevar las webcams lejos del CPU en cuestión.

Moraleja: El que no coje, se deja En informática, lo que parece el atajo es en realidad el camino mas largo entre dos puntos.

por ·Sin comentarios

Siguiendo la línea del post anterior en que uso mplayer para reproducir videos de youtube, se me acaba de ocurrir otro tip estúpido, de esos que simplifican la vida:

Descargar videos de youtube simplemente presionando una combinación de teclas (evitando así eso de instalar extensiones para el navegador que cumplan la misma función y si te pasa como en mi caso, evitando llevar las manos hasta el mouse para hacer click, que soy de los que tienen mas tiempo las manos en el teclado que en el mouse).

La idea es:

  • Copiar la URL (la dirección del video de youtube) al clipboard o portapales – como prefieran
  • Llamar por medio de un atajo de teclado a un script de bash que descargue el video en donde le especifiquemos.
  • Opcional: reproducir el video descargado con mplayer o tu reproductor de cabecera.

Desde un terminal (o si prefieren, en modo gráfico) creen una carpeta en donde almacenar los videos que descargará el script. El siguiente comando crea una carpeta llamada videos dentro de /home/tu_usuario/ :

mkdir  ~/videos

Instalar el paquete youtube-dl y si no lo tienen instalado del post anterior instalen además el paquete xclip. No puedo dar instrucciones específicas para cada distribución. Usen su gestor de paquetes para instalarlos. En Gentoo:

emerge youtube-dl xclip

Crear un archivo en blanco:

touch ytdl.sh

hacerlo ejecutable:

chmod +x ytdl.sh

Editar con su editor de texto de cabecera el archivo ytdl.sh:

nano ytdl.sh

Copiar dentro del archivo el siguiente contenido:

#!/bin/bash

youtube_url=`xclip -o|sed “s/ .*//”|head -n1`

cd ~/videos

#Descomentar la opción que se vaya a usar:

#Opción 1 sin especificar nombre de usuario y contraseña:

#youtube-dl -b -t $youtube_url

#Opción 2, especificado usuario y contraseña:

#youtube-dl -u <usuario> -p <password> -b -t $youtube_url

Crear un atajo de teclado que llame a ytdl.sh:

De nuevo no puedo dar instrucciones específicas pero todos los gestores de ventanas (Gnome, KDE, XFCE, etc…) tienen algún modo de definir atajos de teclado.

He estado mirando un poco y para usar atajos de teclado en XCFE que es el entorno de escritorio que estoy usando hay que ir a Settings / Xfce 4 settings manager / Keyboard / Application shortcuts. (Sepan disculpar pero tengo XFCE instalado en inglés).

Por ejemplo, asociar el combo de teclas CTRL + Y para que al ser pulsado ejecute ytdl.sh o si quieren llamarlo por el path completo, que llame a /usr/bin/ytdl.sh

Es realmente un TIP estúpido ¿No? 😀

Simplifica mucho la vida, eso si…

por ·4 comentarios

Viene de la época en que el manual de Gentoo ofrecía como alternativa la posibilidad de que un amigo mas experimentado «te ayude» durante la instalación del sistema operativo, con todos los perjucios que eso conlleva mas adelante a la hora del mantenimiento periódico…

Screen es una herramienta poderosísima a la que no termino nunca de encontrarle nuevos usos. Entre tantas cosas que permite hacer, se puede usar para compartir una sesión en la consola de comandos con N cantidad de personas, donde todos pueden leer los comandos que los demás tipean y la salida por consola que estos comandos devuelven y todos pueden escribir en la misma consola de comandos. Es como una orgía, pero en Bash.

Por hacer una comparación, sería como una especie de VNC o Terminal Server pero para el modo texto de linux, en tiempo real y multiusuario.

Muy útil para mostrarle a algún colega/cliente/amigo como se hace tal o cual cosa en linux mientras se mantiene a la par una conversación por video conferencia, teléfono, chat, etc.

Nunca he asistido a uno de esos FLISOL pero esto se me ocurre que sería una buena alternativa también.

*COF*puedeservirparachatearyparacontrolarunabotnet*COF*

Teniendo Screen instalado, el funcionamiento es bastante sencillo, por ejemplo:

  • Una pc remota de nombre pcremota
  • Un usuario remoto identificado como usuarioremoto
  • Un usuario local identificado como usuariolocal
  • Usuariolocal necesita compartir una sesión de consola con usuarioremoto en pccremota.

Como se pone en funcionamiento:

Usuariolocal se conecta a pcremota identificádose a si mismo como usuarioremoto:

~ $ ssh usuarioremoto@pcremota

Usuariolocal inicia screen en pcremota:

~ $ screen -S sesioncompartida

Usuarlocal inicia el modo multiusuario de screen presionando las teclas [CTRL] + [a] y luego tipeando:

:multiuser on

Usuarioremoto se conecta a la sesión compartida:

~ $ screen -x usuarioremoto/

Y eso es todo. Durante toda la sesión ambos pueden leer y escribir sobre la misma consola.

Al ejecutar screen -S sesióncompartida se está especificando un nombre para la  sesión en cuestión. Si cualquiera de los usuarios conectados se desconectara, podría recuperar todo en donde lo dejó usando:

~ $ screen -r sesioncompartida

¿Y si son usuarios distintos?

Si se trata de usuarios distintos, por poner un ejemplo, donde usuariolocal se autentica contra pcremota como root y usuarioremoto se va a conectar a la sesión de root, entonces el ejecutable de screen necesita tener habilitado el bit SUID:

~ $ chmod u+s /usr/bin/screen

Por otro lado, luego de habilitado el modo multiusuario de la sesión screen que inició root, este tendría que darle permiso a usuarioremoto para que se conecte a su sesión. Como todos los comandos en scren, presionando primero [CTRL] + [a] y tipeando:

:acladd usuarioremoto

Y  así sucesivamente N cantidad de veces, una por cada usuario que se va a conectar a la sesión screen con credenciales diferentes a las del usuario que inició el proceso.

por ·7 comentarios

Viene de este otro artículo anterior, a raíz de la necesidad de ejecutar aplicaciones remotas en el servidor X local usando X11-Forwarding sin que se nos pregunte una contraseña. (Ideal para el acceso directo de la dama o el alias de bash del caballero).

Normalmente, si necesitamos conectarnos a un servidor SSH habitualmente, tendríamos que especificar el nombre de usuario y una contraseña. (Se especifica el usuario únicamente si nos autenticaremos remotamente como un usuario distinto al usuario que localmente ejecutará ssh)

Al cabo de un tiempo esto termina volviéndose tedioso por lo que usar un juego de llaves (key authentication) es la mejor solución.

Por otro lado, desde el punto de vista de la seguridad, –además de correr sshd en un puerto no privilegiado (de 1024 en adelante) y el buen fail2ban controlando los logs- la autenticación por llaves es muchísimo mas confiable en la medida en que nuestra clave privada se mantenga así (privada) y no caiga en manos de nadie.

Habiendo generado nuestro par de llaves RSA para autenticación ssh, una llave privada, y una pública, basta con copiar nuestra llave pública a todo servidor o pc contra la cual nos autenticaremos para que nos deje entrar sin preguntar quien está en la otra punta ni cual es la contraseña.

Sea cual sea el motivo que te lleve a implementar autenticación por llaves, por comodidad o por seguridad, veamos como se pone en funcionamiento:

Generar el par de llaves:

El comando ssh-keygen, que viene de serie con el paquete openssh es el encargado de generar nuestro juego de llaves:

~ $ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/mn/.ssh/id_rsa):
Created directory ‘/home/mn/.ssh’.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/mn/.ssh/id_rsa.
Your public key has been saved in /home/mn/.ssh/id_rsa.pub.

Dejando la contraseña (passphrase) en blanco durante el proceso, he generado mis dos llaves, la pública: id_rsa.pub dentro del directorio /home/mn/.ssh/  y la privada: id_rsa dentro del mismo directorio.

Copiar la llave pública a la ubicación remota:

Usando secure copy movemos nuestra clave pública hasta el servidor que frecuentamos:

~ $ scp ~/.ssh/id_rsa.pub usuario@servidor:

Instalar la llave pública en la ubicación remota:

Nos logueamos en el servidor (que todavía nos preguntará la contraseña):

~ $ ssh usuario@servidor

Password: **********
Last login: Wed Jul 29 23:19:44 ART 2009 from 5.192.233.114 on ssh

Y copiamos el contenido de nuestra llave pública dentro del archivo authorized_keys en el directorio  ~/.ssh/:

~ $ cat id_rsa.pub >> ~/.ssh/authorized_keys

~ $ exit

¡Y eso es todo!

Si nuevamente intento loguearme usando SSH en este servidor, ya no pregunta mi contraseña. Mi llave privada se coteja contra la llave pública y me permite el acceso de forma cómoda e instantanea:

~ $ ssh usuario@servidor
Last login: Wed Jul 29 23:20:09 ART 2009 from 5.192.233.114 on pts/0
servidor ~ $

Es importantísimo tener en cuenta que este método planteado, si bien es mucho mas seguro que el método tradicional de autenticación –que es vulnerable a ataques de fuerza bruta– a la vez representa un gran riesgo para la seguridad si alguien se hace con nuestra llave privada.

Quien tenga acceso local a la pc que almacena la llave privada automáticamente tiene acceso remoto a las pc o servidores que conocen nuestra llave pública.

Existiendo la posibilidad de especificar un password en nuestra llave privada automáticamente el sistema se vuelve seguro ya que en el caso de que este password no esté en blanco:

  • El acceso SSH no es vulnerable a ataques de fuerza bruta.
  • Nuestra clave privada no se puede desencriptar sin conocer el password.
  • Se nos pide el password de la clave privada en lugar de el password de usuario para iniciar sesión.

En este último caso se pierde la comodidad de loguearnos sin contraseña. Se nos pregunta la contraseña pero de la llave y no del usuario en cuestión. Esto también se puede automatizar haciendo uso de ssh-agent, pero es tema para otro artículo, para no complicar demasiado las cosas.