msgbartop
“¿Estás seguro de que ESO es aleatorio?” “Ése es el problema con la aleatoriedad: nunca puedes estar seguro”
msgbarbottom

26 may 16 Comunicación serie con dispositivos ATtiny mediante TinyDebugSerial

Una de las dificultades a las que hay que enfrentarse a la hora de trabajar con dispositivos ATtiny (84/85, etc…) es la carencia de un dispositivo de comunicación serie, como se tiene con los Arduinos convencionales. Esto lleva a que sea difícil en ocasiones realizar tareas de diagnóstico de errores y resolución de problemas. Sin embargo, existe una (varias, en realidad) manera de comunicar mediante conexión serie con los ATtiny. La que yo he podido comprobar que funciona a la perfección es el uso de un adaptador USB a TTL.

Como requisitos previos para que esta solución funcione podemos distinguir los siguientes:

  • Utilización de los cores Arduino Tiny (http://code.google.com/p/arduino-tiny/)
  • Uso de un adaptador USB-TTL. En mi caso, estoy haciendo uso del adaptador SKU145351, que se puede encontrar a un precio muy reducido por Ebay. El mío monta el chip Silicon Labs CP2102.

Con estos componentes es posible hacer uso de comunicación TinyDebugSerial. Esta opción sólo permite la comunicación TX, es decir, el envío de información serie desde el Attiny al PC, pero para labores de resolución de errores es perfectamente válida.

Un ejemplo de comunicación básica sería el siguiente:

void setup() {
Serial.begin(9600);
}

void loop() {
Serial.println("Testing..");
}

Las conexiones con los ATtiny se realizarían haciendo uso de los siguientes puertos:

Attiny85: PIN PB3 (Pin físico 2)
Attiny84: PIN PB0 (Pin físico 2)
Attiny2313: PIN PD1

…además de los habituales puertos VCC y GND.

Conexión serie USB al ATiny

Conexión serie USB al ATiny

Nótese que no hay diferencias en el código con el que se cargaría en un Arduino convencional, y no se necesitan librerías añadidas. También es importante tener en cuenta que esta comunicación será válida para frecuencias de reloj de 8 MHz o inferiores.

Bibliografía:
Serial communication with the Tiny’s
Added TinyDebugSerial to attiny85

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , ,

23 dic 15 Control remoto de sistemas con WhatApp. Yowsup 2

Nuevos avances. La última vez que utilicé WhatsApp como sistema de control remoto (Riego de jardín con WhatsApp y radiofrecuencia) hice uso de la versión 1 de Yowsup, librería de comunicación con WhatsApp escrita en python. Pero algún tiempo después esta primera versión de Yowsup dejó de ser funcional, y aunque tiempo después fue reescrita en una segunda versión, todo el código que había desarrollado para ello no era compatible.

Después de algunos trasteos, y de comprender cómo funciona esta nueva librería, he conseguido volver a hacer operativo el sistema de comunicación. E incluso el código ha quedado bastante más limpio. Recopilemos: se envía desde un terminal móvil un mensaje de control. Este mensaje es recibido gracias a una aplicación que hace uso de Yowsup, instalada en una Raspberry Pi. El programa interpreta el mensaje, y toma la acción oportuna. Hasta este momento, encender y apagar un relé durante un número de segundos indicado en el mensaje; relé que no se encuentra conectado directamente a la RPi, sino controlado por un chip Attiny85. La RPi, haciendo uso de un emisor de RF de 433 MHz, da las órdenes de encendido y apagado al Attiny85. El Attiny, que se encuentra a la espera de mensajes en un modo de bajo consumo, recibe la señal de interrupción hardware provocada por el receptor de 433 MHz. Sale del modo de bajo consumo, y activa el relé. Posteriormente, bajo otra orden de apagado por parte de la RPi, desactiva el relé y vuelve al modo de bajo consumo.

Teniendo en cuenta que aquí en Irlanda un sistema de riego automático es algo que carece de utilidad (el propio clima es un sistema de riego automático :mrgreen: ), ¿qué se puede querer controlar de manera remota? He aquí la respuesta:

En cuanto a la preocupación por el consumo, éste ha mejorado de manera considerable. El Attiny se encuentra alimentado por una batería de móvil de 2100 mAh, conectada a un panel solar que recarga la batería. Hasta el momento, lleva 4 días funcionando de manera ininterrumpida, y la última medición de la batería indica que la carga es de 3.85v. Un enorme avance con respecto a la anterior versión del reloj de riego de jardín.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , ,

12 dic 15 Attiny85: módulo RF a 433 MHz, modo de bajo consumo, y cómo despertarlo con interrupciones

Hace ya bastante tiempo escribí algo acerca de un sistema de riego controlado por WhatsApp que estuve desarrollando. Se basaba en el uso de una Raspberry Pi que actuaba como cerebro del sistema de riego y de comunicaciones, permitiendo el control de todo el sistema mediante mensajería por WhatsApp. La Raspberry, a su vez, se comunicaba con los los relojes de riego mediante módulos de radiofrecuencia a 433 MHz, un sistema de comunicación barato y razonablemente efectivo. En el otro lado, como se comentó en su momento, la válvula de riego se controlaba con un chip Attiny85, programado mediante Arduino.

Como se vio en su momento, el sistema funcionaba razonablemente bien. Sin embargo, varios problemas me llevaron a un callejón sin salida. El principal de ellos, y del que hablaremos hoy, era el consumo del receptor Attiny85. Sobre el papel es un sistema de muy bajo consumo, óptimo para este tipo de funciones. Sin embargo, el sistema de control de la válvula de riego no dejaba demasiado espacio para una batería, así que la alimentación disponible era, como poco, reducida. Pronto se demostró el que el Attiny con el sistema de radiofrecuenca devoraba la batería. Ésta apenas duraba unas 48-72 horas. Y esto, en un sistema que se supone que ha de ser autónomo y con un bajo mantenimiento, era sencillamente inaceptable, sobre todo si lo comparamos con relojes de riego de jardón convencionales, que con un par de pilas AA o una pila cuadrada de 9v pueden funcionar de manera ininterrupida durante meses.

Probé varias soluciones, desde el uso inicial de una batería recargable de 9v hasta el uso de un panel solar con una batería de móvil incorporada. Éste último caso consiguió producir mejoras, llegando el sistema a funcionar durante una semana de manera ininterrumpida. Pero en cualquier caso, no era una gran mejora. Tocaba afrontar el problema de base: un exceso de consumo.

Batería cuadrada de 9v y panel solar con regulador

Batería cuadrada de 9v y panel solar con regulador

En efecto, el problema estaba provocado por un exceso de consumo. Tal y como estaba diseñado, el sistema estaba permanentemente a la escucha de señales por RF, en un bucle sin fin, dado que la señal de encender o apagar la válvula de riego podía darse en cualquier momento. Esta aproximación era, como poco, inadecuada desde el punto de vista del consumo.

Para mejorar esto, probé varias alternativas: desde emitir sólo en determinadas ventanas de tiempo, hasta desconectar la alimentación al módulo de radiofrencuencia y activarlo sólo durante varios segundos cada minuto. Opciones bastante malas, la verdad, ya que se basaban en la precisión de un reloj interno que, como es conocido, no es un prodigio de la precisión.

Otra posibilidad hubiera podido ser un método en el que el Attiny consultara a la Raspberry si había algún comando por ejecutar. Pero por desgracia, los módulos RF de 433 MHz son unidireccionales, por lo que hubiera sido preciso incorporar un emisor al Attiny y un receptor a la Raspberry, complicando de manera innecesaria todo el sistema. Finalmente, la solución vino de mano de dos elementos presentes en el Attiny. El modo sleep y el uso de interrupciones.

El Attiny85 dispone de varios modos de bajo consumo (sleep mode) que sirven para reducir el consumo del chip cuando está a la espera de algún evento. En el caso del Attiny85, puede reducir el consumo hasta en un 90%. Pero no se trataba sólo de dormir al chip, sino de ser capaz de despertarlo cuando se recibiera una recepción de datos en el módulo de RF. Y para ello, nos encontramos con las interrupciones.

Las interrupciones son eventos que provocan un cambio en el estado de reposo o ejecución de un programa -en este caso, un programa cargado en el Attiny85-. Hay interrupciones tanto hardware como software, siendo las hardware las provocadas por un evento externo al programa en sí. Dentro de las interrupciones hardware, en el caso de Arduino, podemos distinguir las interrupciones Externas, y las provocadas por un Cambio en el Pin. El nombre es un poco confuso, pues ambas son externas al chip en sí, pero mientras las Externas están limitadas a un número concreto de patillas en el chip, las de Cambio en Pin pueden ocurrir en cualquiera de las patillas. En el caso concreto del Attiny85, las Externas sólo se producen en el Pin2 (INT0, patilla 7), mientras que las de Cambio en Chip se pueden producir en cualquier otra patilla.

De hecho, es factible despertar al Attiny85 del modo de bajo consumo mediante el uso de interrupciones. En el caso concreto del artículo enlazado, se usa el Pin3 (patilla 7) -luego se usa el modo de Cambio de Pin- para despertar al chip del modo de bajo consumo, como he podido comprobar personalmente (el ejemplo se basa en el uso de un botón conectado a 5v). Sin embargo, a la hora de probarlo con el módulo de RF a 433 MHz el sistema no funcionaba. No era capaz de realizar cambios en el sistema.

A modo de recordatorio, el sistema de control de la válvula consiste básicamente en un relé que activa o desactiva la válvula en función del tiempo que se desea mantener activo el riego. Este relé está controlado por una de las patillas del Attiny, protegida mediante un optoacoplador.

Tras varias pruebas, pude averiguar que el problema estaba causado por una particularidad en el receptor del módulo RF. Sólo he sido capaz de hacerlo comunicar con el chip Attiny a través del del pin de Interrupción Externa (Pin2, INT0), por lo que el ejemplo referenciado anteriormente no resultaba válido. En mi caso, ha sido necesario hacer uso de la patilla INT0:

#include
#include
#include

RCSwitch mySwitch = RCSwitch();
const int rele = 4;
const int dataPin = 0; //INT0, PCINT2
void setup() {
pinMode(dataPin, INPUT);
digitalWrite(dataPin, HIGH);
pinMode(rele, INPUT);
mySwitch.enableReceive(dataPin);

// Flash quick sequence so we know setup has started
for (int k = 0; k < 10; k = k + 1) {
if (k % 2 == 0) {
pinMode(rele, OUTPUT);
}
else {
pinMode(rele, INPUT);
}
delay(250);
} // for
}

void sleep() {

GIMSK |= _BV(PCIE); // Enable Pin Change Interrupts
PCMSK |= _BV(PCINT2); // Use PB3 as interrupt pin
ADCSRA &= ~_BV(ADEN); // ADC off
set_sleep_mode(SLEEP_MODE_PWR_DOWN); // replaces above statement

sleep_enable(); // Sets the Sleep Enable bit in the MCUCR Register (SE BIT)
sei(); // Enable interrupts
sleep_cpu(); // sleep

cli(); // Disable interrupts
PCMSK &= ~_BV(PCINT2); // Turn off PB2 as interrupt pin
sleep_disable(); // Clear SE bit
ADCSRA |= _BV(ADEN); // ADC on

sei(); // Enable interrupts
} // sleep

ISR(PCINT0_vect) {
// This is called when the interrupt occurs, but I don't need to do anything in it
}

void loop() {

if (mySwitch.available()) {

sleep();
int value = mySwitch.getReceivedValue();

if (value == 0) {
// Serial.print("Unknown encoding");
} else {

pinMode(rele,OUTPUT);
delay(10000);
pinMode(rele,INPUT);
}
mySwitch.resetAvailable();
}
}

(Explicación rápida del ejemplo: Se declaran INT0 como receptor de RF, y el Pin4 como control del relé. Se realiza un ciclo de encendido y apagado del relé al inicio para mostrar que el programa ha iniciado, se declara la interrupción del modo de bajo consumo con INT0, y se pasa al bucle principal. Se espera a una interrupción, se comprueba que la señal RF recibida es correcta, y se enciende el relé durante 10 segundos)

Resultado: ¡éxito! No sólo el sistema funciona, sino que he podido comprobar una gran mejora en el consumo del sistema. Durante la fase activa del programa, en la que el relé está activo y se ha recibido la señal de radiofrecuencia, todo el sistema consume unos 9 mA. Cuando está en modo de bajo consumo, a la espera de recibir la señal, baja a niveles inferiores a 1 mA.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , ,

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

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , ,

07 dic 15 Automatización de despliegue y gestión de cortafuegos con Ansible

Estas últimas jornadas he estado trabajando en un sistema de automatización de despliegue de cortafuegos en Softlayer. Llevo un tiempo trabajando con cortafuegos Vyatta, que si bien son bastante prácticos para desplegarlos tanto sobre entornos virtuales como sobre máquinas físicas, adolecen de un grave problema: carecen de un sistema de gestión centralizado. Y cuando manejas del orden de medio centenar de cortafuegos, esto se hace especialmente necesario, no sólo para mantener un sistema homogéneo y manejable, sino también para evitar, en la medida de lo posible, fallos humanos.

¿Y cuál ha sido el sistema elegido para automatizar ciertas tareas de despliegue y gestión? Pues como no podía ser menos, ha sido Ansible. Hasta este momento he sido capaz de:

  • Hacer un despliegue automatizado de la configuración inicial de cortafuegos vyatta en clúster a partir de cortafuegos individuales.
  • Automatizar el desploegue y borrado de múltiples reglas en diferentes cortafuegos

Para ello, lo primero ha sido preparar un entorno de demo, que ha tenido casi más chicha que la propia configuracion con Ansible:

Diagrama del entorno de despliegue

Diagrama del entorno de despliegue


…que se compone de los siguientes elementos:

  • Portátil: Mi propio portátil de trabajo. Actúa como entorno de virtualización basado en KVM. Su función como entorno de virtualización no es relevante en sí como elemento de testeo, pero sin él no sería posible realizar el despliegue del entorno. Sí es relevante su función como cliente de los servicios desplegados por el servidor CirrOS. Se le ha configurado una ruta estática para enrutar el tráfico a través de la IP .254 de la subred externa, que será la IP flotante del clúster de cortafuegos.
  • Servidor CirrOS: Servidor extremadamente ligero (en torno a 32 MB de RAM y un procesador) que levanta servicios SSH y HTTP, este último mediante una simulación con NetCat, lo que también tiene su miga. En cuanto al servidor CirrOS, a los conocedores de entornos cloud como Openstack les sonará bastante, pero he conseguido hacer un despliegue en un entorno KVM convencional.
  • Clúster de cortafuegos Vyatta: El clúster de cortafuegos Vyatta (bueno, en realidad VyOS, el fork software libre surgido cuando Brocade compró el proyecto original) actúa como cortafuegos entre las subredes interna y externa. En la fase inicial consiste en dos cortafuegos independientes, como una configuración básica de sus interfaces de red y poco más, con direcciónamiento .252 y .253. En esta fase, por lo tanto, el portátil no es capaz de conectar con el servidor CirrOS. El equipo vyatta1 actuará como maestro en la configuración VRRP, y el equipo vyatta2 actuará como esclavo.
  • Ansible: Este servidor actúa como servidor de Ansible, como su propio nombre indica. Conecta con los dispositivos vyatta haciendo uso de clave SSH, por lo que -y esto es de lo mejor de Ansible- no necesita de ningún tipo de agente o plugin para realizar los despliegues de configuración o recogida de información desde los dispositivos.

Ansible -y esto no pretente ser una descripción exhaustiva de sus características, por lo que ruego se me perdone cualquier incorrección que pueda perpetrar- puede actuar bien enviando comandos únicos a los equipos administrados, bien haciendo uso de recetas (playbooks). Estas recetas consisten en un grupo de tareas, plantillas y parámetros que se combinan para realizar las labores de automatización de configuración y labores de gestión en los dispositivos:

  • Tareas (task): Comando o grupo de comandos que realizan alguna acción en el dispositivo. Éstas pueden ser creadas en base a módulos predefinidos para simplificar su proceso de creación
  • Plantillas (templates): Las tareas pueden hacer uso de plantillas para simplificar el proceso de configuración o gestión de los dispositivos. Estas plantillas, cuyas variables se completan haciendo uso de los valores asignados a los parámetros, se usan para crear al vuelo los scripts (o cualquier comando) que se quieran aplicar al dispositivo. Lo más interesante del asunto es que estas plantillas se pueden crear de manera bastante sencilla en base a scripts convencionales que ya se estuvieran utilizando para gestionar el dispositivo, simplemente reemplazando las variables del scripts por las variables propias de j2, que posteriormente, en tiempo de ejecución, serán sustituidas por los parámetros definidos en Ansible.
  • Parámetros: Valores concretos de la configuración de los dispositivos a gestionar con Ansible, como por ejemplo el nombre del cortafuegos, la IP de una interfaz, o los valores de la VPN. Estos parámetros pueden ser definidos de múltiples maneras: usando un fichero de configuración global de parámetros, usando ficheros específicos para cada dispositivo (algo especialmente interesante para este caso), almacenando valores en tiempo de ejecución de los propios dispositivos gestionados o del entorno, o una combinación de estos métodos. Posteriormente, estos parámetros se usan para configurar los dispositivos, bien mediante tareas individuales o mediante plantillas.
  • Dispositivos (hosts): Conjunto de servidores que queremos administrar. Pueden ser etiquetados para aplicarle sólo ciertas tareas (por ejemplo, los dispositivos individuales de las parejas de vyattas pueden ser etiquetados como maestro y esclavo para sólo aplicar a cada uno de ellos la configuración que corresponda) que sean de aplicación para el tipo de disposito gestionado.

Una vez configurado el entorno, el recetario, las plantillas y parámetros, la configuración quedó lista para ser aplicada a los dispositivos. Las tareas de un recetario pueden ser ejecutadas de manera secuencial o en una sucesión específica, usando para ello las oportunas etiquetas. En mi entorno, y hasta el momento, he definido tres tipos de tareas:

  • Despliegue inicial: Realiza el despligue inicial de la configuración a la pareja de vyattas para convertirlos en un clúster y realizar las configuraciones básicas de seguridad y gestión requeridas. En el entorno de demo, una vez realizada esta tarea, queda configurada la interfaz flotante en ambas subredes, realizado NAT y el enmascaramiento del tráfico de la interfaz interna a la externa, y permitido el tráfico ICMP entrante de la interfaz externa a la interna. Todo ello permite que el portátil haga ping al servidor, pero no pueda acceder a los servicios.
  • Añadir reglas: Esta tarea realiza un despliegue de política a los cortafuegos. En concreto, permite el tráfico por los puertos 22 y 80 TCP al servidor CirrOS.
  • Borrado de reglas: Permite eliminar las reglas anteriormente definidas

Un ejemplo de ejecución de Ansible para este entorno sería el siguiente:

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t initial

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.252]
ok: [192.168.122.253]

TASK: [initial-config | upload script for configuring description] ************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [initial-config | run script for configuring description] ***************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [initial-config | debug var=desc_value.stdout_lines] ********************
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=4 changed=2 unreachable=0 failed=0
192.168.122.253 : ok=4 changed=2 unreachable=0 failed=0

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t add

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.253]
ok: [192.168.122.252]

TASK: [rules | retrieve Description for a firewall] ***************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | upload script for configuring description] *********************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | run script for configuring description] ************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | debug var=desc_value.stdout_lines] *****************************
ok: [192.168.122.252] => {
"desc_value.stdout_lines": [
"Outside In"
],
"item": ""
}
ok: [192.168.122.253] => {
"desc_value.stdout_lines": [
"Outside In"
],
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=5 changed=3 unreachable=0 failed=0
192.168.122.253 : ok=5 changed=3 unreachable=0 failed=0

i82hisaj@debian:~/ansible/vyos# ansible-playbook main.yml -t delete

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [192.168.122.252]
ok: [192.168.122.253]

TASK: [initial-config | debug var=desc_value.stdout_lines] ********************
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

TASK: [rules | upload script for deleting rule] *******************************
changed: [192.168.122.252]
changed: [192.168.122.253]

TASK: [rules | run script for configuring description] ************************
changed: [192.168.122.253]
changed: [192.168.122.252]

TASK: [rules | debug var=desc_value.stdout_lines] *****************************
ok: [192.168.122.253] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}
ok: [192.168.122.252] => {
"desc_value.stdout_lines": "{{ desc_value.stdout_lines }}",
"item": ""
}

PLAY RECAP ********************************************************************
192.168.122.252 : ok=5 changed=2 unreachable=0 failed=0
192.168.122.253 : ok=5 changed=2 unreachable=0 failed=0

Algunas ideas hasta el momento:

  • Desafortunadamente no existe ningún módulo oficial que permita hacer la administración simplificada de cortafuegos vyatta, lo que significa que todo el trabajo de definir la automatización de tareas ha de realizarse desde cero, en base a scripts y configuraciones básicas de Ansible.
  • Afortunadamente, el sistema de interacción de Ansible es lo suficientemente flexible para permitir la conversión sencilla de scripts previamente existentes a plantillas J2, lo que permite -en mi caso- aprovechar bastante trabajo previo ya existente.
  • Existen interesantes posibilidades de conectar Ansible con sistemas de gestión vía web, como es el caso del proyecto Semaphore.

En resumen, si bien Ansible este caso requiere de bastante trabajo para poder realizar de manera efectiva la automatización del despliegue y gestión de cortafuegos (vyatta, en este caso), las ventajas que proporciona y el trabajo final que ahorra hacen que valga la pena. Como diría nuestro amigo Barney, en este caso nos encontramos claramente por encima de la diagonal Vicky Mendoza:

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , ,