El siguiente nivel de Docker es Atomic

Los contenedores son una interesante forma de distribuir aplicaciones y plataforma pero cuando hay aplicaciones que requieren de varias partes, como servidor web, base de datos, etc. todos ellos en contenedores diferentes, esto puede ser una tarea colosal. Son muchos contenedores que deben presentarse unos a otros con puertos especificos de cada uno y variables de acceso, etc, y hacer todo esto de forma manual puede ser una tarea de adminstración muy compleja.

Para estos casos el proyecto atomic juega un rol muy importante. Es un conjunto de herramientas que permiten presentar aplicaciones con sus diferentes contenedores ya todos integrados de acuerdo a reglas definidas.

La guia de inicio del proyecto es bastante sencilla de seguir y una vez funcionando el cluster de servidores es bastante sencillo de desplegar aplicaciones, aunque sigue siendo bastante manual porque se basa en archivos de texto, al igual que los Dockerfile de los contenedores, con las configuraciones para deplegar los “pods” (conjunto de contenedores vinculados), y luego el aplicar los mismos al cluster tambien es manual, a los sumo se puede automatizar un poco. Podemos decir que atomic presenta un lenguaje para juntar especificaciones de cada contenedor y desplegar los contenedores ya todos vinculados.

Creo que en el futuro, nos presentaran una herramienta de gestión de los “pods” más visual, pero por ahora, permite una administración muy fácil de algo que puede volverse engorroso con el tiempo.

Nota al margen: el cluster de atomic, no tiene una seguridad muy elaborada entre servidores y clientes, me supongo que es porque se espera que corra en un “ambiente aislado y seguro”.

Creando imagenes en docker

En esta entrega trabajaremos con crear una imagen con nuestras configuraciones y publicarla para que otros puedan usarla en sus proyectos.

Empecemos descargando una imagen como base para nuestro trabajo.

docker pull fedora:latest

Para este ejemplo he creado un repositorio con los archivos usados, en este caso es simplemente un archivo PHP que contiene una función básica.

Crearé una imagen de Fedora 23 con el servidor Apache instalado y configurado para usar PHP. Este servidor luego mostrará una página con toda la informacón del ambiente PHP.

Primero creamos un directorio de trabajo, luego crearé un archivo llamado Dockerfile en el mismo.

mkdir fedora-test
touch fedora-test/Dockerfile

En este mismo directorio crearé un archivo, llamado archivo.php, cuyo contenido será el siguiente:

 <?php
phpinfo();
?>

Esto será para un ejemplo que usaremos mas adelante.

El archivo Dockerfile es el que define las acciones a realizar para obtener la imagen y se ejecuta de la siguiente forma:

cd fedora-test
docker build -t docker.io/rodolfoarce/fedora-test:0.1 .

El parametro -t docker.io/rodolfoarce/fedora-test:1.0 es para identificar la imagen con una etiqueta, así luego podremos publicar esta imagen con una etiqueta especifica en los repositorios publicos.

La clave de la construccion de la imagen es el archivo Dockerfile, que contiene todas las instrucciones para crear la imagen en cuestión.

Editamos el archivo Dockerfile, para que contenga las siguientes lineas, las explicaré por partes, y el archivo final deberá ser como este: click aquí

FROM fedora:latest

MAINTAINER Rodolfo Arce <mail@ejemplo.com>

La primera linea indica la instrucción FROM, que es la imagen original desde donde partiremos, en este caso yo parto desde fedora en su última version. Luego se indica la instrucción MAINTAINER quien es el que crea o mantiene esta imagen.

Acá empieza la parte divertida, esta imagen deberá ser modificada a través de varias tareas. Cada una de estas tareas, o conjunto de tareas se reaizan usando la instrucción RUN y a partir de ahí suceden los cambios

RUN dnf -y install httpd php && dnf clean all

Estos comandos instalan el serviro Apache y las librerías de PHP. Observación: Los comandos que fueras a realizar NO son interactivos, deben ser automáticos, por eso en se ejecutó con el parametro correspondiente dnf -y

Luego borro la cache de archivos descargados y los metadatos, esto es una buena practica para mantener las imagenes limpias y compactas en tamaño.

Hasta ahora el sistema es capaz de ejecutar el servidor web, pero yo quiero una pagina web en específico que sea mostrada. Existen dos formas de hacer esto, voy a ponerlas ambas a continuación, pero en el archivo mantendré la forma mas amigable con otros usuarios.

Primera forma:

Copiarla desde el directorio de trabajo, para esto se usa la instrucción COPY

COPY archivo.php /var/www/html/info.php && chown apache:apache /var/www/html/info.php

De esta forma yo estoy copiando archivo.php de mi directorio actual, al sistema de archivos de la imagen a ser creada y cambiando el usuario dueño del mismo.

La otra forma es descargar en vivo el archivo desde algún repositorio público legible por los nuevos usuarios.

RUN curl -L -s https://github.com/rodolfoarces/docker-test/raw/master/archivo.php -o /var/www/html/info.php && chown apache:apache /var/www/html/info.php

Esto es mas amigable porque otras personas podrán ver el contenido del archivo en vez de recibir una caja negra que no saben lo que hace.

Finalmente vienen tres instrucciones que van mas o menos de la mano:

EXPOSE 80

CMD ["-D", "FOREGROUND"]

ENTRYPOINT ["/usr/sbin/httpd"]

La instrucción EXPOSE indica que puerto deberá abrirse en comunicación con el exterior, la siguiente instrucción CMD indica parametros que deberán pasarse al ejecutable inicial ENTRYPOINT de la imagen, en este caso es el servidor httpd.

Si yo fuera a crear una imagen de otro servicio o ejecutable que escuche en otro puerto, deberé cambiar la instrucción EXPOSE, si este ejecutable no requiera de parametros de inicio, la instrucción CMD es innecesaria.

Para ejecutar esta imagen inicializamos un contenedor usando el siguiente comando:

docker run -d --name=test -p 80:80 rodolfoarce/fedora-test:0.1

Apuntamos nuestro navegador a la IP del servidor en cuestión y debería de mostra la información del ambiente.

En mi caso puedo observar esta información: Apache/2.4.18 (Fedora) PHP/5.6.17

Ahora para publica esta nueva imagen, la envío a los un repositorio fedora-test previamente creado en mi cuenta de docker hub.

docker push docker.io/rodolfoarce/fedora-test

Seguimos luego con otras entregas de mas funcionalidades de Docker

Primeras experiencias con docker

Docker logo

Docker llegó para revolucionar la ejecución, la administación y aprovisionamiento del software para siempre.

Si algunas vez escuchaste la expresión “No funciona en mi maquina” mientras observabas el mismo software funcionando perfecto en tu maquina, entonces Docker es la herramientas que necesitas.

Creo que docker no soluciona todos los males, si traes contigo malos habitos y vicios en el ciclo de vida de desarrollo, docker solo agregará una nueva capa de complejidad a los mismos. Usar con cuidado :)

Resumiendo lo que es y que hace: Docker es una herramienta que permite la ejecución de software proveyendo TODO el ambiente (librerías) para el mismo, si necesidad de instalarlo en la maquina ejecutora del mismo o la necesidad de una aislamiento de hardware como lo hace la virtualización. Wow, eso lo hizo mas confuso!. Bueno, ejemplo.

No más hyperviosores

No más hyperviosores

Mi maquina es fedora, para ejecutar un software que requiere Debian, debo instalar Debian (directo a la maquina, o en maquina virtual), ejecutar el software. Docker permiter que puedas descargar todo el sistema de archivos de la distribución debian, y ejecutar el software en ese entorno descargado. Les parecerá muy similar a la virtualización, pero no es así, porque la virtualización presenta un sistema operativo completo y aislado ejecutado en memoria por medio de un hypervisor, en el caso de docker es solo UN SOLO proceso ejecutado en memoria no asi TODO el sistema operativo.

Manos a la obra!

Para fedora:

dnf install docker

para Debian/Ubuntu

apt-get install docker

para CentOS/Red Hat

rpm install docker

Bajo la misma premisa expuesta, ahora quiero ejecutar un software en Debian. Para esto como el usuario root del sistema, descargo la imagen del sistema operativo, y lo preparo para la ejecución de un software

[root@laptop ~]# apt-get --version    <- Esto es Fedora
bash: apt-get: command not found
[root@laptop ~]# docker pull debian
.. Aca muestra varios mensajes..
[root@laptop ~]# docker run --name=test -t -i debian:latest /bin/bash
root@a1b2c3d4e5:/#  cat /etc/issue    <- Esto es debian 
Debian GNU/Linux 8 \n \l
root@a1b2c3d4e5:/# apt-get --version
apt 1.0.9.8.1 for amd64 compiled..

Para explicar un poco mejor lo sucedido. En mi maquina Fedora ejecuto, apt-get, un comando muy conocido de las distribuciones de Debian. Me dice el interprete que estoy mal de la cabeza, eso no existe, lo cual es cierto. Luego descargo la imagen del sistema operativo de debian. Inicio un contenedor con esa imagen (explicaré mejor eso en unos parrafos más) y ya estoy dentro de la distribución debian. Ejecuto el mismo comando y ahí si existe. Puedo realizar las tareas con el mismo.

Un poco de contexto, que es muy importante. Todas las tareas y cambios que realice suceden dentro del contexto del contenedor. NO afecta la maquina host, en este caso, todo pasa en Debian, nada en Fedora.

El contenedor crea un sistema de archivo virtual para ejecución, con lo cual todas las modificaciones se mantienen durante la vida del contenedor. Hacemos todo lo que tenemos que hacer, salimos.

En la consola de Debian, ejecutamos “exit” y con eso salimos del contenedor, pero el sistema de archivo del contenedor sigue almacenado (aunque ya no “en vivo”). Entonces para entender la ejecución terminación y limpieza de las imagenes y contenedores vamos a un par de comandos más de ejemplo.

Lo primero que necesitamos es imagenes, estan son la base para los contenedores y nos dan un sistema de archivo desde el cual iniciar las tareas. Vemos cuales imagenes tenemos disponibles con “docker images

[root@laptop ~]# docker images
REPOSITORY                        TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
docker.io/debian                  latest              2b90562fac36        2 weeks ago         125.5 MB
docker.io/centos                  latest              60e65a8e4030        4 weeks ago         196.6 MB

Tengo imagenes de Debian y CentOS, a partir de estas imagenes se crean los contenedores, que son la ejecucion de los mismos. Creamos un contenedor del mismo ejemplo anterior. Para descargar imagenes de sistema operativo, el comando es “docker pull [nombre][:etiqueta]“.. la etiqueta es algo opcional, para versiones

[root@laptop ~]# docker pull debian
.. Aca muestra varios mensajes..
[root@laptop ~]# docker pull debian:7
.. Aca muestra varios mensajes..

Descargamos la imagen de debian, la ultima version, “latest“, que es la opcion por defecto si no es especifica la etiqueta, y la versión 7 que sería la anterior ya espeficicando la etiqueta.

Luego iniciamos el contenedor, pasando como parametros un nombre legible con “–name=“, ya verán eso porque es mejor así, “-t -i” son opciones para abrir (o mostrar) la consola , luego la imagen de base, en este caso “debian:latest” y luego el comando a ejecutar, en este caso el interprete de comandos “/bin/bash“, pero en otras entregas veremos como esto puede ser otro ejecutable. Ejemplo actual:

[root@laptop ~]# docker run --name=prueba -t -i debian:latest /bin/bash
root@a1b2c3d4e5:/#

Notesé el interprete bash entrega un conjunto de numero y letras luego del usuario “root@a1b2c3d4e5“, esto es un ID unico del contenedor.

Se pueden observar los contenedores en ejecución con “docker ps“, de la siguiente forma, abrimos otra consola en la maquina host y hacemos lo siguiente:

[root@laptop ~]# docker ps
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS              PORTS                NAMES
a1b2c3d4e5           debian                                   "/bin/bash"              34 seconds ago      Up 32 seconds                            prueba

En el momento en que cerramos el interprete bash en el contenedor, el proceso muere y desaparece, pero el sistema de archivos aun sigue almacenado, de esta forma todos los contenedores de alguna forma se mantienen en el tiempo. Y la forma de iniciarlos nuevamente es por su ID. Y luego uno debe “conectarse” nuevamente.

[root@laptop ~]# docker ps
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS              PORTS                NAMES
[root@laptop ~]# docker start a1b2c3d4e5     <-Con esto iniciamos el contenedor ya conocido
a1b2c3d4e5
[root@laptop ~]# docker ps
CONTAINER ID        IMAGE                                    COMMAND                  CREATED             STATUS              PORTS                NAMES
a1b2c3d4e5           debian                                   "/bin/bash"              1 hour ago      Up 60 seconds                            prueba
[root@laptop ~]# docker attach a1b2c3d4e5    <-Con esto nos "conectamos" al contenedor nuevamente  
root@a1b2c3d4e5:/#

Con lo anterior estamos iniciando nuevamente el contenedor original de Debian, usando su ID. Nos conectamos a nuevamente al contenedor usando “docker attach [ID]“. Para detenerlo, salimos de la consola o desde cualquier otra consola hacemos “docker stop [ID/Nombre]“.

[root@laptop ~]# docker stop a1b2c3d4e5

Luego de detener el contenedor, el mismo puede ser iniciado nuevamente, pero en caso de haber realizado todas las actividades y ya no lo necesitamos mas, lo borramos para que no ocupe espacio de almacenamiento, un poco de limpieza con “docker rm [ID]“. Si lo que queremos borrar es una imagen descargada usamos “docker rmi [nombre][:etiqueta]

[root@laptop ~]# docker rm a1b2c3d4e5
[root@laptop ~]# docker rmi debian:latest

Con esto cerramos los primero pasos con docker y en las proximas entregas estaré comentando mis experiencias creando imagenes y un poco mas de administración de contenedores.

Git y la revolución de la colaboración

Git LogoHoy me toca hacer una presentación en la Universidad Americana, en su ciclo de charlas y exposiciones.

Pensé en Git para esta charla, porque creo que los sistemas de versionamiento, y los portales de publicación de codigo fuente como github, sourceforge, y demás son el pilar fundamental del software libre, al menos desde el punto de vista mas práctico. Ahí es donde esta el código fuente.

Existe una revolución relacionada con Git, o con la colaboración mejor dicho, y somos parte de esta revolución, directa o indirectamente y los CVS son son la base de esta tendencia. Lee mas acá

Les acerco mis diapositivas: Git – Universidad Americana – Oct 2013

 

 

Crea tu distro (Fedora)

La ultima entrada estuvo enfocada en armar la distro para Linux Mint, en esta entrada estaremos construyendo nuestra distribución basado en Fedora.

Para la construcción de Fedora, se utiliza las herramientas de LiveCD. Para lo cual hay que instalar el paquete:

[root@localhost #  ~] yum install livecd-tools

La herramienta utiliza un/os archivo/s kickstart para la instalación de los paquetes, y la preparación del entorno, pueden descargar los archivos con el paquete del repositorio, o pueden descargar solo los que requieren, y modificar a gusto

[root@localhost # ~] yum install fedora-kickstarts spins-kickstarts

Las secciones mas representativas del archivo kickstart son: los repositorios, la lista de paquetes y los archivos personalizados.

Los repositorios se declaran de la siguiente forma:

# Repositorio basado en mirrors (como el de fedora)
repo --name=fedora --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch
# Repositorio basado en una URL
repo --name=repopersonal --baseurl=http://miservidor.com/directorio/

Los paquetes se instalan simplemente ubicándolos en en la sección de paquetes:

%packages
livecd-tools
anaconda
paquete-1
#para eliminar un paquete instalado se usa el "-" como prefijo
-paquete-2
# Los grupos de paquetes se declaran con un "@" como prefijo
@Base
@Development tools
%end

Los archivos personalizados son mas complejos, dentro del mismo kickstart se ejecutan comandos de consola, y desde estos mismo comandos se crean los archivos. El punto clave es donde empieza y donde finaliza el archivo.

Los archivos personalizados se generan luego de la instalación de todos los paquetes, en la seccion “post” del archivo kickstart. y se generan de la siguiente forma.

%post
cat >> /sbin/mi_script.sh <<EOF
#!/bin/bash
echo "Este es un script de bash"
EOF
%end

De esta manera, uno crea el archivo y en el contenido se carga en el mismo, hasta que recibe la orden EOF (end of file), esta orden puede ser cualquier secuencia de caracteres, pero es buena practica usar esa orden.

Una vez que tenemos el archivo kickstart de nuestra preferencia, se inicia el programa para crear la distro.

livecd-creator --verbose --config=/directorio/mi_archivo_kickstart.ks --fslabel=Fedora-RodolfoRemix --cache=/var/cache/live

Esta herramienta descargara todos los paquetes (y sus dependencias) las instalará en un sistema de archivo temporal. Luego se crea el sistema de archivo “live”, y se crea el livecd usando el mismo.

Una nota al margen, uno se vera tentado de agregar los repositorios externos de rpmfusion por ejemplo, para agregar soporte mp3, o de adobe para el plugin de flash player. Pero esto trae consigo un problema al “control de calidad” de la distribución fedora.

Todos las variantes de fedora que utilicen sus repositorios oficiales, son consideradas “remixes” del mismo, pero si van a utilizar repositorios o software personalizado. La marca fedora (y sus guias de uso) estipulan de que que NO PUEDE USARSE la marca o el logo de fedora en el mismo, para esto se recomienda instalar el paquete de logos genericos y desinstalar el paquete de logos de fedora en las listas de paquetes de su archivo kickstart.

%packages
# desinstalar logos de fedora
-fedora-logos
# instalar logos genericos
generic-logos
%end

Arma tu distro

Mi primera incursión en el remix de una distribución de linux fue con el LiveCD de slax, en ese entonces usaba slackware como mi distro de escritorio así que tenía la sarten por el mango.

El problema con slax era que estaba diseñado para ser usado como LiveCD y no tenia forma “fácil” de instalarse. De ahí que me ví en la busqueda de nuevas formas de personalizar una distro a mi gusto.

Remastersys

Una de las herramientas mas prometedoras que hay para personalizar una distro es “Remastersys”, el cual en su interface permite crear una distro a partir del sistema operativo en el que se encuentra instalado, y puede sacar varias versiones, una del sistema operativo solo, y otra del sistema operativo con las configuraciones de usuarios y datos de los mismos; lo cual lo hace una excelente herramienta de backup.

Para empezar a usar “Remastersys”, debemos configurar el repositorio del paquete para nuestra distribución. De la experiencia que tengo con esta herramienta, me funcionó muy bien con distribuciones basadas en ubuntu hasta la 10.04 LTS, o Linux Mint 9.

Debemos agregar a nuestra lista de repositorios la siguiente linea:

deb http://www.geekconnection.org/remastersys/repository karmic/

Y luego actualizar e instalar el paquete:

sudo apt-get update
sudo apt-get install remastersys

Con esto ya podemos empezara usarlo, ejecutando como root el comando de la interfaz grafica de la herramienta

sudo remastersys-gui

La opcion de creación de la imagen que buscan es “Dist” ya que crea la imagen de sistema operativo en el que se encuentra instalado, sin datos de usuarios.

Yo personalmente, para mantener el orden, siempre instalo una maquina virtual, y en ella personalizo todo lo que necesito (y lo documento tambien), y creo la imágen de la maquina virtual sin afectar a mi sistema operativo del día a día.

MintConstructor

Otra opción interesante disponible para Linux Mint es la herramienta “mintconstructor” que es una version para la distro de la herramienta “reconstructor”. Es mucho mas simple, y no tan customizable como “Remastersys” pero es muy pontente cuando se conoce como funciona el sistema operativo.

Funciona desempaquetando una imagen iso previa en un directorio del nuestro sistema actual, y luego nos crea una terminal en jaula (chroot terminal) en ese directorio, donde podemos customizar la distro a nuestro gusto.

Para poder customizar la distro, es necesario conocer los comandos de instalacion de software y la personalización que requiere, todo desde la linea de comandos, con esta herramienta no hay ventanas con la cuales trabajar.

sudo apt-get install minconstructor
sudo /usr/lib/linuxmint/mintConstructor/mintConstructor.py

Yo personalmente me he encontrado con un problema en la creación de la distro usando el “mintconstructor” en el cual en el proceso de creación no me crea el archivo .iso, pero si estan creados todos los demas archivos, asi que busque cual es el comando que utiliza y lo corrí de forma manual y me crea la imagen sin problemas.

Asumiendo haya usado el directorio /var/cache/livecd, debo ir al mismo y ejecutar el comando como sigue:

cd /var/cache/livecd
sudo genisoimage -o ./livecd.iso -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -V "LiveCD" -cache-inodes -r -J -l ./remaster/

Esto me devolverá un archivo /var/cache/livecd/livecd.iso que ya esta listo para probarse

En que situación querrian crear su propia distribución?

Mantener una distribución es un trabajo muy complicado, lo ideal es siempre trabajar sobre algo ya previamente probado, y hacer “tweaks” sobre eso.

En el caso mío, mas alla de las necesidades laborales, cree una versión de mi sistema operativo con ciertas modificaciones que necesitaba para usar mi modem 3g, que con las versiones de sistema que usaba siempre requerían de instalación de paquetes y modificación de archivos de configuración. Con la creación de mi remix, tenía todo lo que necesitaba en un LiveCD que podía correr en cualquier maquina.

Una nota sobre el uso del servidor SSH

Cuando el paquete openssh-server es instalado, se crean unos archivos de configuracion, estos archivos deberían ser unicos por cada maquina, pero si se usan en el contexto de un LiveCD y la instalación del mismo, el mismo archivo de configuración se copiará en todas las maquinas que instalemos.

Mi solución es eliminar esos archivos, y colocar un control en el inicio que los crea cada vez que bootea la maquina, siempre y cuando no existan.

Primero borramos los archivos.

rm /etc/ssh/ssh_host_{dsa,rsa}_key*

Luego en el archivo /etc/rc.local colocamos el siguiente codigo

if [ ! -e /etc/ssh/ssh_host_dsa_key ]
then
	dpkg-reconfigure openssh-server
fi

De esta forma, en cada inicio, se controla si existe el archivo, y si no existe hace una “reinstalación” rapida del paquete, que los crea nuevamente, unicos para cada inicio, y para cada maquina.

El PGP nuestro de cada día

Antes lo más importante era el hardware, donde el poder de procesamiento era tan valuable que los computadores tomaban pisos enteros del edificio donde se encontraban. Con el advenimiento de las computadoras personales, la importancia caía sobre el software.

Hoy la importancia está en la información.

Ya hace un tiempo estoy haciendo una serie de tutoriales sobre la encriptación de datos y creo que con este nuevo tutorial le puedo dar un complemento mas que necesario.

Señoras y señores, ante Uds., PGP para todos los días

Pruebalo o no sirve

Como administradores de sistemas, tenemos una responsabilidad con la alta disponibilidad. No deberíamos darnos un solo minuto de down-time.

La realidad nos dice otras cosas, que no somos invencibles, y por sobre todas las cosas, que “Si algo puede salir mal, saldrá mal“, la famosa ley de murphy.

Esta ley nos da una guia para pensar en el peor escenario posible de las cosas. Por esta ley es que hacemos nuestras copias de seguridad. Ponemos nuestros datos en otra maquina, y hasta en otra ciudad para que “cuando” algo salga mal, podamos levantarnos de las cenizas como el ave fenix.

Esta copia de seguridad es nuestro seguro de vida.

En la realidad, uno quisiera nunca comprobar que su seguro de vida funciona, pues para eso tendriamos que morir. Pero ese no es el caso para las copias de seguridad.

Existen maquinas virtuales. Crea una desde cero, y aplica tu copia de seguridad, y por sobre todas las cosas documenta el proceso y los resultados.

Ninguna copia de seguridad es aceptable, hasta que el proceso permita replicar el estado actual de la maquina, o como mínimo permitir el correcto funcionamiento de los servicios críticos.

Pruébalo, o no sirve.. a menos que quieras probar tu backup bajo presión, cuando el mundo se haya derrumbado.

 

Soporte dinamico para modulos del kernel

Supongo que hubiera sido conveniente poner esto en la sección de tutoriales, pero creo que en esta ocasión es mas comentario/opinión que tutorial para la generación de un modulo en especial.

Hace un tiempo recibí en prestamo una computadora EXO (Classmate) cuya distribución “oficial” era bastante peculiar. Para ser una distro orientada a la educación  no tenía ningun software educativo (?!). Y cualquier distribución estandar de GNU/Linux puede ser instalado, pero la conexión wifi no funciona de forma estable.

Leí que existía un controlador para esta placa, y lo instalé. Todo funcionaba bien, pero me preguntaba como haría para instalar el mismo software en varias maquinas sin tener que hacerlo de forma manual.

Ya trabajando con el sistema operativo, se me presentó la actualización del sistema (y el kernel). Al hacerlo, el wifi dejó de funcionar, esto se daba porque el modulo se compiló para esa versión especifica del kernel, al actualizarlo el modulo no se cargaba con el kernel.

Leyendo un poco el como solucionar el problema, leí un artículo sobre dkms, e indagué un poco más. Y el sistema es muy interesante. Trabaja compilando el código fuente del módulo cada vez que se actualiza el kernel, así al instalar uno nuevo, el modulo no deja de funcionar.

La ventaja de este método, ademas de lo observado es que trabaja directamente sobre el código fuente del modulo, no asi con modulos precompilados como los demás que vienen con nuestro kernel.

Vamos a la parte práctica. Mi placa wifi es Realtek 8192SE, y el módulo soportado esta disponible en la web del fabricante. Además del codigo fuente del módulo, trae además el firmware (no libre) de la placa. Este detalle es relevante, ya que el sistema DKMS solo compila el kernel y lo ubica en árbol del kernel actual instalado, pero no así el firmware.

Lo primero es ubicar el código fuente de acuerdo a ciertos parámetros. Debe ubicarse en un carpeta en /usr/src/[nombre_del_módulo]-[versión_del_módulo]

mkdir /usr/src/rtl8192se-0005.1230.2011

En este directorio deberá encontrarse el archivo de configuración del sistema dkms.conf, con el cual guiaremos la instalacion.

Mi configuración refleja la instalación de varios modulos

PACKAGE_NAME="rtl8192se"
PACKAGE_VERSION="0005.1230.2011"
# Este es el primer modulo que debe compilarse e instalarse
BUILT_MODULE_NAME[0]="rtlwifi"
DEST_MODULE_LOCATION[0]="/kernel/drivers/net/wireless/"
# Este es el segundo modulos, pero es compilado en un directorio diferente
BUILT_MODULE_NAME[1]="rtl8192se"
BUILT_MODULE_LOCATION[1]="rtl8192se/"
DEST_MODULE_LOCATION[1]="/kernel/drivers/net/wireless/rtl8192se"
# Instalación del firmware, y borrado luego de la desinstalación 
POST_INSTALL="install.sh $source_tree/$PACKAGE_NAME-$PACKAGE_VERSION"
POST_REMOVE="remove.sh"

El script de instalación recibe como parámetro el lugar donde se encuentra el código fuente, y debe notarse que se usa como nombres de variables. Esto se recomienda buena práctica ya que se puede configurar para usar un directorio alternativo.

El script de instalacion es bastante simple, pero corrobora la existencia previa, para no copiarlo todas las veces que se compila

#!/bin/bash
$FIRM_DIR=$1/firmware/rtlwifi
# Corroborar que el firmware no este presente
if [ ! -d /lib/firmware/rtlwifi ]
then
    # Si no existe, copiarlo
    cp -a $FIRM_DIR /lib/firmware/
fi

El script de borrado del firmware es un comando simple

#!/bin/bash
rm -R /lib/firmware/rtlwifi

Una vez que estan hechos los archivos, se procede a la compilación del modulo. Pero antes se requiere la instalación de las cabeceras del kernel actual

# Debian/Ubuntu/Mint
apt-get install kernel-headers dkms
# Red Hat/Fedora/Centos
yum install kernel-headers dkms

Una vez instalado el sistema DKMS los comandos para generar los paquetes instalables de los mismos.

dkms add -m rtl8192se -v 0005.1230.2011
dkms build -m rtl8192se -v 0005.1230.2011
# Deb package
dkms mkdeb -m rtl8192se -v 0005.1230.2011
# RPM package
dkms mkrpm -m rtl8192se -v 0005.1230.2011

Los paquetes instalables pueden luego publicarse en repositorios.

La página de man del dkms tiene muchas mas opciones disponibles para los módulos que son compilados con características específicas. Incluyendo cambiar el nombre al instalarlo, la compilación solo para cierta versiones del kernel, etc.

El sistema en si es bastante rápido y estable. En el caso de Fedora, el kernel al utilizar la opción AUTO_INSTALL, verifica en cada booteo la presencia del módulo, lo cual agrega 30 segundos (o más) al proceso de inicio.

Ecosistema de servicios

Como proveedor de servicios en el área de informática, no puedo rechazar la idea de hacer una pequeña reflexión sobre el ecosistema de servicios que nace con el software libre.

Voy a empezar con una anécdota. En una cena con Richard Stallman yo le comentaba que el software libre genera un ecosistema de servicios asociados. Él me detuvo cuando hubo escuchado la palabra “ecosistema” y luego me dejó continuar. Le pregunté porqué había hecho eso, y me respondió que no le gustaba la palabra de “ecosistema” en el contexto del software, porque no implicaba conciencia moral. Es decir, en un ecosistema, no hay bien o mal, solo hay sistemas que interactuan. A lo cual agregó que le gustó mi término “de servicios” porque tenía una conotación de asistencia o ayuda en la traducción que el manejaba. Creo que esquivé su ira por centímetros.

El software libre, mi área de trabajo cotidiano, me presenta con una realidad de trabajo poco convencional, comparado con la clásica venta de productos y servicios, mas que nada porque mi producto estrella es gratutito. Yo no vendo el software marca acme, te vendo la capacidad acumulada de mi experiencia (y certificacion) de instalar el software marca acme de forma rápida, segura y con garantías.

Esto es asi, porque todos, absolutamente todos, podríamos si quisieramos instalar cualquier software libre, es inherente a la licencia, que es de libre uso, acceso, copia, modificación y redistribución, entonces porque me elegiría alguien para instalarlo por ellos, si lo pueden hacer solos?. Porque la experiencia acumulada, y el conocimiento del software y su configuración me permiten a mi hacerlo en una fracción de tiempo y con todas las funcionalidades necesarias.

No quisiera negar a nadie la oportunidad de aprender a usar software libre, pero a veces, la disponibilidad de tiempo es un factor a tener en cuenta.

El ecosistema de servicios que nace del uso de software libre, no solo incluye la instalación y configuración, tambien el mantenimiento, en el corto, mediano y largo plazo, como son la copia de seguridad de las configuraciones en periodos de tiempo establecidos (ojo que esto también se puede automatizar), la modificación de las configuraciones para agregar/modificar las funcionalidades, actualización segura. Un servicio interesante es la personalización del software, donde programadores son contratados para modificar un software existente a las preferencias y necesidades de un cliente.

Uno de los servicios que mas ha llamado mi atención ultimamente es la educación, es decir el entrenamiento en el uso de software libre en todos los niveles. Desde el uso de aplicativos de ofimática en la estación de trabajo, hasta la instalación y puesta a punto de servidores de alta disponibilidad. El conocimiento acumulado también se puede vender como servicio. Y el ecosistema se vuelve cada vez mas complejo.

La ventaja de este ecosistema de servicios es que nada esta atado a un solo proveedor. Como el software es libre y gratuito, el cliente TE ELIGE por sobre los demás proveedores por todas las razones posibles. Desde familiaridad, precio, disponiblidad, conocimiento previo de la plataforma. La dinámica esta dada por la capacidad y por la calidad de los servicios, no por contratos de licencia.

Una de mis acciones más polémicas es que cuando un proveedor me solicita un servicio, le soy claro con mi nivel de conocimiento del mismo, y ante la duda le ofrezco otros proveedores que podrían darle ese servicios. Ud se preguntará porque direcciono a los clientes a la competencia, y le respondo que el cliente se merece una solución, incluso si la solución no sea la mía. Y creanme cuando les digo que en informática, todo tiene solución, la pregunta real es el precio y el tiempo.