08 dic 15 Uso de CirrOS como servidor ligero de prueba independiente
Decíamos ayer que uno de los elementos del entorno de prueba de la solución con la que estoy trabajando en Ansible era un servidor CirrOS. Pero… ¿qué es un servidor CirrOS?
CirrOS es un servidor ligero, muy ligero, especialmente desarrollado para servir como demostrador de la capacidad de despliegue de máquinas en entornos cloud, como Openstack (de ahí el juego de palabras, claro). Es un servidor cuya imagen ocupa tan sólo 12 megas, se puede desplegar con 32 megas de RAM y una sola CPU. No se le pueden instalar -al menos, no fácilmente- paquetes, y las funcionalidades que ofrece son sumamente limitadas.
Por tanto, ¿qué razón habría para querer desplegar un sevidor así en un entorno? No muchas, en realidad, salvo que tu entorno de demo sea especialmente reducido, como es mi caso. :mgreen: En realidad, también tiene algún problema adicional: aunque la imagen a desplegar es una imagen QCOW2 convencional, que en Openstack despliega de manera sencilla en KVM, fuera de un entorno Openstack, aún usando KVM, da un poco de guerra para desplegarlo.Por ejemplo, en Gnome, aunque puedes crear la máquina desde el “Virtual Machine Manager”, utilizando la imagen descargada, la máquina no arranca. Es preciso exportar el fichero XML de configuración de la máquina, modificar el tipo de disco de “raw” a “qcow2″, eliminar la máquina y volver a crearla importando el XML para hacerla funcionar.
Además, un despliegue convencional de la imagen proporcionada por Launchpad tiene otro problema: como espera ser llamada desde un entorno de computación cloud espera recibir determinados parámetros de configuración a través de los servicios metadatos de éste. Y como no los recibe, se queda esperando durante 20 segundos su recepción… 20 veces.
Además, no hay gran cosa que puedas hacer, salvo acceder a ella por SSH. Ni servidor web, ni de correo, ni de nada.
Pero, pese a todo, es una pequeña maravilla que merece una oportunidad. Porque para cada uno de los problemas anteriores, existe una solución:
- El problema del arranque: como se ha comentado, es cuestión de editar el XML y cambiar el parámetro de despliegue del disco. Y una vez creada la máquina, se puede clonar tantas veces como sea necesario, ya que a partir de este momento siempre se desplegará con la opción correcta.
- Lentitud en el arranque: Aquí hay dos opciones. O bien tocar los parámetros de arranque para que no espere la información del entorno cloud… o hacer uso de una imagen previamente preparada por el usuario de GitHub Eprasad. Ojo, a esta imagen hay que hacerle de igual manera lo comentado en el punto anterior para poderla arrancar desde KVM.
- Carencia de servicios: Y es aquí donde llega la magia. Como he comentado, no hay apenas nada instalado en la máquina, salvo SSH y poco más. Pero ese poco más es sumamente importante. Porque tenemos nada más y nada menos que una instalación de Netcat, la navaja suiza del TCP/IP. Y a partir de aquí, la imaginación puede empezar a volar. Por ejemplo, podemos simular de manera sencilla un bonito servidor HTTP:
MYIP=$(ifconfig eth0|grep 'inet addr'|awk -F: '{print $2}'| awk '{print $1}')while true; do echo -e "HTTP/1.0 200 OK\r\n\r\n<h1>Hi IBM. Welcome to $MYIP</h1>" | sudo nc -l -p 80 ; done&
Así que recomiendo de manera encarecida darle una oportunidad a esta pequeña maravilla. Porque lo merece.
P.D.: Otro pequeño recordatorio. Cómo configurar de manera estática el direccionamiento de red en CirrOS, y definir rutas estáticas:
CirrOS configure network:
COMPUTE: /etc/network/interfaces
auto lo
iface lo inet loopback
auto mybr0
iface mybr0 inet static
address 10.1.0.1
netmask 255.255.0.0
network 10.1.0.0
gateway 10.1.0.2
bridge_ports eth5
bridge_stp off
bridge_maxwait 0
bridge_fd 0
up route add -net 10.0.0.0 netmask 255.255.0.0 gw 10.1.0.2 dev eth5
up route add -net 10.1.0.0 netmask 255.255.0.0 gw 10.1.0.2 dev eth5
up route add -net 0.0.0.0 gw 10.1.0.2 eth5
26 may 11 Cómo simular un servidor web con netcat
La siguiente es una pequeña receta que se puede utilizar para realizar una medición de velocidad de transferencia de datos entre dos equipos remotos, simulando el acceso a un servidor web, con la pequeña particularidad de que no se utiliza ningún servidor web. Utilizamos netcat para servir un fichero de 100 megas, simulando la señalización de protocolo HTTP. En la máquina que hacía de servidor ejecutamos el siguiente comando:
{ echo -ne “HTTP/1.0 200 OK\r\n\r\n”; cat /tmp/archivo.txt; } | nc -l 80
…y en el equipo cliente pedimos con wget abrir una conexión al servidor:
wget http://ip_del_servidor/ -O /dev/null
Adicionalmente, redireccionamos la salida de wget (es decir, el fichero de 100 megas) a /dev/null, con el objetivo de no realizar escritura en disco alguna, en el caso de que estemos utilizando un sistema empotrado o algún dispositivo con poco espacio.
Para generar el fichero de 100 megas podemos utilizar /dev/urandom, de tal manera que los datos sean pseudoaleatorios, y sea más difícil aplicar compresión
por parte de algún elemento interpuesto:
dd if=/dev/urandom of=/tmp/archivo.txt bs=1024k count=100
Sobre el primer comando: no especificamos el tamaño del fichero. Si por alguna razón (algunos clientes web son un tanto especiales) fuera necesario
especificarlo, puede usarse el siguiente comando:
{ echo -ne “HTTP/1.0 200 OK\r\nContent-Length: ” `wc -c some.file | cut -f 1 -d ‘ ‘` “\r\n\r\n”; cat some.file; } | nc -l 80
Etiquetas: http, netcat, servidor web
15 jun 09 Streaming de webcam para monitorización remota
Una de las grandes ventajas de los sistemas linux es su flexibilidad: permiten desde realizar instalaciones estándar de escritorio hasta realizar instalaciones de grandes servidores de procesos de datos. Hoy voy a hablar de una posibilidad que permiten: realizar un sistema de monitorización remota mediante webcam. Esta aplicación respondería al siguiente esquema:
- Una estación remota, con un sistema linux básico con una instalación en modo consola, y una webcam añadida. Idealmente este equipo debería ser de pequeño formato, como un Pico-ITX, pero cualquier equipo sería válido. Con una instalación básica de consola sería más que suficiente.
- Un equipo de escritorio, dedicado a la monitorización. Este equipo, en desde el que se va a realizar el control de la estación remota, requeriría disponer de un entorno gráfico, a discreción del usuario
El sistema operativo, obviamente, tendría que ser linux. Cualquier distribución valdría, pero por mis preferencias personales he de recomendar Debian, una magnífica distribución con la flexibilidad suficiente como para permitir una sencilla instalación de estos dos entornos tan diferentes.
La piedra angular de esta instalación es el programa netcat, la navaja suiza de los administradores de sistemas. Esta herramienta tiene como principal característica es su capacidad para abrir puertos TCP/IP y redireccionar flujos de datos del sistema operativo por ellos. También tiene una función trascendental los túneles SSH, que permiten enlazar puertos en una máquina remota (a la que se realiza la conexión SSH) con otra máquina que esté en la red local del sistema cliente (esto también incluye, obviamente, la propia máquina cliente).
Otra suposición de la que partimos es que el cliente y el servidor NO se encuentran en la misma red local, sino que se encuentran en redes separadas, ya sea porque hay algún elemento como un cortafuegos interpuesto, o bien porque se encuentran enlazadas por una red WAN. En cualquier caso, algo impide impide que se pueda acceder a cualquier puerto entre el cliente y el servidor, estando limitado a accesos por puertos bien conocidos, como SSH.
En primer lugar, habría que configurar el sistema operativo del servidor para que reconozca la webcam. Esta tarea queda fuera de este mini-tutorial, por lo que me remito a internet para realizar esta labor. Sin embargo, en un sistema linux reciente, tendría que ser más que suficiente con instalar Video For Linux 2, ya que los módulos necesarios suelen venir por defecto en el kernel. Esto debería provocar que la webcam, al ser conectada al servidor, haga aparecer el dispositivo /dev/video0 (o algo por el estilo).
Una vez hecho esto, la idea en el servidor es la siguiente: recoger el flujo de datos de la webcam a través del dispositivo correspondiente (/dev/video0,o el que corresponda), y mediante netcat, abrir un puerto (por ejemplo, el 2000) y dirigir el flujo de datos anterior a este puerto, que estará preparado para recibir conexiones. Esto se haría mediante el siguiente comando:
$ cat /dev/video0 | nc -l -p 2000
Por otro lado, en el cliente, habría que realizar la siguiente operación: realizar un túnel SSH al servidor, de tal manera que se enlace el puerto que hemos abierto en el servidor (en este caso, el 2000) con un puerto en la máquina cliente (en este caso, el 270001). A continuación, con netcat se recoge el flujo de datos del puerto 27001; por último, mediante un pipe, se recoge la salida del comando anterior (que sería mostrada por la salida estándar) hacia un programa de visualización de vídeo adecuado, como mplayer o xine. La sucesión de comandos sería la siguiente:
ssh -f -L 27001:127.0.0.1:2000 usuario@servidor sleep 10; nc 127.0.0.1 27001 | xine -
Un cutre-esquema de lo expuesto anteriormente sería el siguiente:
Diagrama de la instalación
Con toda esta película conseguiríamos visualizar desde el equipo cliente la webcam del servidor.
Una pequeña variación de lo anterior permite, por otro lado, hacer streaming de ficheros de vídeo (o audio). Con el siguiente comando abriríamos el puerto local 2000 para accesos desde un servidor remoto, que leerían del fichero video.avi:
nc -l -p 2000 < video.avi
Por la parte del cliente seguiríamos usando el comando anterior.
Existen algunos corolarios a este mini-tutorial. Uno de ellos consistiría en lograr que el acceso al servidor sea sin contraseña, basándonos en el uso de certificados de usuario. Pero eso ya quedará para otro día.
Etiquetas: debian, linux, netcat, pico-itx, streaming, túnel ssh, webcam
Medidor de entropía
