Workshop de Ansible

Ayer fue un día frío en Monterrey. Día de cafés en el Hotel Marriott, muy cerca de mi oficina y del aeropuerto Mariano Escobedo. Tres grados centígrados durante todo el día, sazonado con chubascos de agua nieve para darle más sabor al asunto.

La gente de Redhat llegó puntual y a las 9:00 am la sala ya estaba completa. Una breve bienvenida, palabras de agradecimiento a los asistentes y, tras una escueta explicación de las bondades de Ansible, iniciamos con el primero de tres laboratorios. He de comentar aquí que el producto se ve bien y es útil, pero hubo un par de cosas que no me gustaron nada.

El instructor del evento, tenía preparado un template que le permitía enviarnos a todos los asistentes, un correo electrónico simultáneo, adjuntando un pdf con la información necesaria para poder llevar a cabo los laboratorios. Claro, un template de Ansible. Bien, el correo solamente le llegó a una parte de los asistentes. Nunca se nos proporcionó una explicación detallada sobre dicho fallo. Error número uno en un workshop.

La aplicación va por su versión 3.2.1 y fue adquirida por Redhat hace apenas un par de años.

En un data center, este tipo de herramientas suele ser muy útil, pues ofrece un ahorro considerable de tiempo al permitir la automatización de tareas en un número considerable de equipos. Por ejemplo, cuando existe un cambio de horario, cuando es necesario implementar determinado software en varios equipos, etcétera.

Una parte en uno de los laboratorios, consistía en instalar Apache sobre un equipo utilizando un template ya predefinido. En la siguiente captura no se puede apreciar, pero tras finalizar el proceso que corre Ansible, me dio por buena la instalación, cuando la realidad fue que Apache nunca llegó a instalarse. Esto fue así porque la URL que yo indiqué en el template, tenía un error de sintaxis.

Me di cuenta del error, porque el número de tareas que ejecutó Ansible era de 10, mientras que mi compañero de al lado, que no tuvo problema con la instalación, observó que la cantidad de tareas que le mostraba su .log era de algo más de 40. Como dije, el error nunca fue mostrado.

La siguiente prueba consistía en instalar WordPress. Esta, una vez corregido el error de la URL mal escrita que permitió finalmente instalar Apache, se produjo de forma exitosa en un tiempo razonable, aunque he de decir aquí que las pruebas se realizaban sobre un solo equipo. Si yo tengo que instalar wordpress en un solo equipo a mano, creo que lo haría en un tiempo menor al empleado por Ansible. Si, por el contrario, el tiempo que le llevó a Ansible instalar wordpress es el mismo tanto en un equipo como en 200, entonces, valdría la pena tomarlo en cuenta.

Otra de las pruebas y que me produjo un malestar general consistió en hacer una modificación pequeña de forma remota, implementando un archivo de Jboss en un equipo. La tarea mostró un error en la ejecución, como se aprecia en la imagen siguiente:

En apariencia, todo parece indicar que el problema es del password, pero lo cierto es que no fue así. El instructor realizó una revisión rápida y optó por eliminar el laboratorio de varios de los afectados y crearlos nuevamente. El problema nunca se resolvió y no hubo ninguna explicación de por qué se daba el error de forma recurrente. A un compañero le clonaron el laboratorio ¡¡¡ tres veces !!!

Mi conclusión es que no compraría ni loco un licenciamiento de Ansible bajo estas premisas. Un workshop debe de servir para demostrar que el producto funciona perfectamente y, si se produce algún error, compartir con el respetable público a qué se debió dicho error, corregirlo y continuar, demostrando que realmente se trata de una aplicación que va a ayudar a nuestro negocio y que, por lo tanto, vale la pena.

Lo que haré ahora será montar un laboratorio y realizar las pruebas que considere oportunas por mi propia cuenta, aunque mis ojos ya están apuntando a una solución diferente.

Al final de la tarde y, tras una generosa comida, invitados por Redhat (of course), nos dieron unos presentes publicitarios, como suele ser habitual en este tipo de eventos.

Posted in Ansible, Redhat | Leave a comment

Un viaje al pasado con Alpine

A mediados de la década de los 90, fui un usuario activo del cliente de correo Pine, desarrollado en la Universidad de Washington. En aquel entonces, era el que suscribe, un mozalbete defensor a capa y espada del novedoso Linux, causante de más de un quebradero de cabeza a la hora de instalarlo y configurarlo. Pine era ligero y funcional, así que cumplió perfectamente su cometido durante años, hasta que decidí migrar hacia algo más práctico y visual, a medida que las distribuciones Linux iban evolucionando con el paso del tiempo (extraño Slackware 3).

Bien, en la actualidad, Pine ha muerto, como bien indica la web de la UW. Sin embargo, ha renacido bajo el nombre de Alpine con un cambio de licenciamiento. Es decir, mismo perro, pero diferente collar. El asunto es que tengo cierta nostalgia de aquella época, asi que, he decidido instalar y configurar Alpine con mi cuenta de correo personal, cuya característica principal es que se trata de un dominio propio (mi primer apellido) pero que hace uso de los servidores de Gmail.

Para los nostálgicos como yo, sirva el presente post como un recordatorio de instalación y configuración del ya clásico cliente de correo electrónico desde consola y sobre Ubuntu 17.10 que es lo que estoy usando en el momento de escribir este post.

La primera cuestión es instalar Alpine, así que, abrimos una terminal con la combinación de teclas Ctrl+Alt+T y escribimos:

#sudo apt-get install alpine

Voy a dejar ciertas obviedades a un lado, así que, una vez instalado el programa, procederemos a ejecutarlo desde la misma terminal, invocando su nombre:

#alpine

La siguiente pantalla aparece solamente la primera vez que ejecutamos Alpine y constituye el punto de partida inicial hacia lo que sigue, que es la configuración de los parámetros de nuestra cuenta de correo.

Al pulsar sobre la letra E, se nos mostrará el management de la aplicación, tal como se observa en la siguiente captura de pantalla:

Con las flechas de dirección, nos situamos sobre la opción de SETUP y la seleccionamos, procediendo a configurar los parámetros necesarios para que Alpine quede totalmente funcional. Para ello, seleccionaremos la opción C.

Una vez seleccionada la opción C (Config), procedemos a incluir los parámetros de nuestra cuenta de correo.

Dichos parámetros quedarían de la siguiente manera (Sustitúyelos por los tuyos si estás leyendo esto a modo de guía):

  • Personal name: Tu nombre completo
  • User Domain: Tu nombre de dominio (Si usas gmail, entonces escribe gmail.com)
  • SMTP Server: smtp.gmail.com:587/tls/user=usuario@dominio.com
  • Inbox Path: {imap.gmail.com:993/ssl/novalidate-cert/user=usuario@dominio.com}INBOX
  • Incoming Archive Folders=usuario{imap.gmail.com:993/novalidate-cert/ssl/user=usuario@dominio.com}

Cuando hayamos escrito todos los parámetros, simplemente saldremos de la aplicación seleccionando la opción Exit Setup (letra E). El programa nos pedirá la confirmación para escribir los parámetros en el archivo de configuración. Responderemos con la tecla Y y ya podremos hacer uso de Alpine como cliente de correo.

En la captura anterior se puede apreciar que solamente tengo en mi bandeja de entrada dos correos, los cuales podrán ser seleccionados haciendo uso de las flechas de dirección del teclado. Basta con seleccionar uno de ellos para que Alpine nos muestre su contenido:

Pues esto es todo. Alpine tiene más opciones de configuración. En el menú correspondiente se pueden observar todas ellas (SETUP). No obstante, en el $HOME de usuario existe un archivo oculto llamado .pinerc, el cual permite escribir directamente ciertos parámetros. Alpine también soporta cifrado con PGP. No está de más leer un poco al respecto para que, ahora sí, quede personalizado y al gusto de cada usuario.

A mi me gusta invocar al Pine original de los 90, asi que, tan sencillo como hacer lo siguiente:

#ln -s /usr/bin/alpine /usr/bin/pine

Enjoy !

Posted in E-Mail | Leave a comment

Ninfus

Hace unos años comencé a desarrollar una pequeña aplicación para Linux, concretamente en Gambas y sobre Ubuntu, aunque no recuerdo exactamente de que versión del SO se trataba. En ese tiempo trabajaba como parte del personal externo para la infame Telefónica México, osea, Movistar. La aplicación en cuestión se llamaba “Ninfus” y consistía en un inventario de campo desarrollado específicamente para documentar distintos aspectos de hardware, tanto para equipos HP como para equipos Oracle. Se trataba de algo muy específico y que, por azares de la vida, nunca utilicé durante el tiempo que estuve en Telefónica, pero que sí llegué a usar de forma personal en mis tiempos casi inmediatamente posteriores en Indra México.

A continuación, me permito explicar brevemente, de qué iba Ninfus:

El software en cuestión está protegido por contraseña; es decir, la pantalla de login es lo primero que aparece tras invocar al programa. Todos los datos, incluyendo el login/passwd así como la gestión de usuarios adicionales y de equipos, se guardan en una pequeña base de datos sqlite3, lo que permite compartirla fácilmente entre usuarios. Inicialmente pensé en utilizar MySQL, pero finalmente lo descarté, pues en esencia, lo que pretendía era disponer de los datos de manera local, considerando que MySQL se quedaba grande para tal propósito.

En el main form de la imagen se pueden apreciar los distintos campos que componen el programa, el cual, dicho sea de paso, es muy intuitivo, aunque mejorable. Pero el asunto es que lo que entonces buscaba, era ni más ni menos que algo funcional. Para quien ha trabajado en un Centro de Datos, cualquier herramienta que facilite el trabajo de campo siempre es de agradecer.

Como se puede observar, los registros son muy específicos a la vez que útiles, pues permiten obtener los datos necesarios para ubicar físicamente cada equipo, acceder al mismo a través de las IPs, consola, MP o XSCF, etc. De hecho, este pequeño inventario me permitía generar casos de soporte sin necesidad de perder tiempo en teclear comandos para obtenerlos o de caminar unos cientos de metros hasta los equipos, en el supuesto de que no existiera acceso remoto.

La gestión de usuarios con acceso a esta herramienta, se compone de ALTAS, BAJAS y MODIFICADORES. Quizá unas funciones una tanto inútiles, debido a que, como ya he explicado antes, la idea principal era utilizar el software de manera local, lo que limita el número de usuarios en la práctica que, en mi caso, era de tipo individual. No obstante, el código siempre puede ser modificado y basta con cambiar SQL3 por MySQL para convertir a esta herramienta en una utilidad colectiva con gestión a través de la red.

El apartado correspondiente a la gestión de equipos tiene el mismo principio que la gestión de usuarios. La notable diferencia es que, obviamente la cantidad de campos a tener en cuenta es infinitamente mayor. Y en esto reside la verdadera utilidad del software.

Y la pregunta del millón es… ¿Y por qué publicar esto después de tantos años?

Bueno, porque encontré el código por casualidad y decidí probar si todavía funcionaba. Originalmente desarrollé este programa en Gambas 2, el cual ya no se encuentra en los repositorios de Ubuntu, así que instalé Gambas 3 sobre la actual versión 17.10 e importé el proyecto. Obviamente ha habido cambios entre versiones, pero me sorprendió que, la mayoría de los ajustes a realizar se basan en el diseño mismo de las distintas interfaces, mientras que el código parece funcionar a la perfección.

El asunto es que siendo un proyecto que tenía completamente olvidado, creo que todavía puede servir para algo o para alguien, así que, a ratos, trataré de mejorarlo con la finalidad de ponerlo a disposición de quien lo quiera.

No tiene fecha de finalización, pero ya iré comentando en este medio sobre los avances y retrocesos de este renacido proyecto.

Posted in Development | Leave a comment