No recuerdo con exactitud el año en que instalé por primera vez Linux aunque podría arriesgar que ésto sucedió en el 1997/98.  Mi distribución elegida entonces fue Slackware (a sabiendas de que era de las más complicadas, quería algo simil UNIX -en rigor, creo que me dieron ese CD y no tuve muchas alternativas-). En aquellos tiempos hacer un Dual Boot con Windows y Linux no era tan simple como hoy debido a que Linux no contaba aún con instaladores gráficos de esos que nos guían practicamente a lo largo de toda la instalación y el Windows de entonces podía con suerte bootearse a si mismo.  Logré -con la ayuda de un amigo linuxero- instalar Linux junto con un Windows (95 o 98, supongo).

Nunca voy a a olvidar el desequilibrio que senti cuando ingresé a Slack por primera vez, me logueé root, hice startx y abrí el explorador de archivos. Mi amigo se habría ido para ese momento porque recuerdo que navegando las carpetas del sistema llegaba al / para encontrarme con un conjunto de directorios del que sabía absolutamente nada. Vale aclarar que en éstos tiempos  yo no tenía aún Dial up en mi casa y la comunidad Linux era un germen de lo que es hoy en día.

En la actualidad Google puede proveer información acerca de lo que sea que queramos entender, pero aún así intentaré en este artículo explicar al usuario que llega de Windows la arquitectura de los ficheros que componen éste enorme sistema operativo llamado Linux como me hubiera gustado que me lo expliquen aquel día.

Puesta esta introducción, comencemos  sin más con nuestro cometido.

LNW: Linux no es Windows

Me voy a permitir la licencia de jugar con este concepto. En la comunidad del Software Libre Richard Stallman (un personaje con que estoy de acuerdo con reservas y a quien considero muy sobrevalorado si tenemos en cuenta con qué contribuyó al mundo de Linux y la posición que ocupa en los medios de comunicación) introdujo el concepto de GNU (GNU is not Unix) para distinguir a Linux en tanto sistema operativo libre de Unix, el sistema operativo a partir del cual Linus Torvalds creó el primer Kernel Linux (si sabés que fue Minix y no Unix quizás este artículo no esté dirigido a vos).

Linux no es Windows significa que, tenemos que hacer un esfuerzo tan grande como podamos para olvidar el modo en que Windows se estructura y actua -intentar poner nuestra mente en Tabula rasa, como diría Locke- y preparanos para un sistema operativo que nos brindará lo mismo y más que Windows, pero de otro modo. Si bien las interfaces gráficas (Gnome/KDE  y otras) con que Linux cuenta hoy en día son muy intuitivas para un usuario de Windows, no tardaremos en entender que estás interfaces gráficas corren sobre una estructura totalmente distinta a la acostumbrada en Windows y, a diferencia de la experiencia que podamos tener con el OS de Microsoft, en Linux vamos a encontrarnos con la consola de comandos muy rapidamente. Esto es importante desde que la mayoría de usuarios de Windows en su vida han ejecutado el comando cmd (sí, es la mayoría).

Dicho esto, rebooteamos nuestra cabeza y vamos a explicar la arquitectura de Linux y la función de los componentes que la integran.

El Arbol de Directorios en Sistemas Linux

En resumen, un SO Linux posee una serie de directorios que conforman el sistema de archivos. Estos pueden crearse en una misma partición o disco (los instaladores gráficos de distribuciones actuales recomiendan este esquema para los nuevos usuarios) así como en distintas particiones o discos rígidos. Independientemente del esquema que elijamos (instalar todos los directorios en una misma partición o en distintas) veremos siempre el listado del árbol de directorios como si éstos estuvieran en un mismo disco/partición.

1- La raíz del sistema "/": en Linux el punto más alto en el árbol de directorios es lo que se denomina root. Podríamos pensarlo como el C:\ de Windows pero con la distinción de que en Windows podemos tener otras unidades (otros HHDD o lectoras DVD) que se listarán con otra letra como separados de C:\ en tanto que en Linux cualquier componente estará siempre ubicado en algún punto debajo de la "/".

2- El directorio /bin: este fichero contiene binarios ejecutables (es decir, archivos que en windows serían .exe) requeridos en el proceso de boteeo del sistema y utilizados normalmente por los usuarios. Si listamos los archivos de este directorio entenderemos facilmente de qué hablamos: allí residen programas como ls, tar, mkdir, rm, cp y -en líneas generales- ejecutables que utlizamos constantemente en consola.

3- El directorio /boot: archivos utilizados en el proceso de booteo del sistema. Encontraremos aquí a nuestro booteador (GRUB o LILO). Este fichero es lo primero que el sistema operativo analiza una vez se ha arrancado la PC y establecido comunicación con el sistema operativo. Generalmente tendremos aquí además una versión comprimida de nuestro Kernel con nombre vmlinuz (en mi Debian Squeeze vmlinuz-2.6.32-5-amd64)

4- El directorio /dev: al introducir la raíz del sistema hablamos de que en Linux -a diferencia de Windows- las unidades de almacenamiento y periféricos en general no se listaban en paralelo a la "/", sino que estaban en algún punto debajo de ésta. Este punto es, en concreto, el fichero dev cuya misión es la de abstraer los dispositivos de Hardware brindando archivos que permitan manipularlos para cada caso. Si corremos ls en este directorio encontraremos allí archivos que hacen referencia a nuestra lectora DVD, discos rígidos y demás periféricos de que dispongamos. Vale aclarar que dev es abreviatura de devices o dispositivos en español.

5- El directorio /etc: este directorio contiene los archivos de configuración de los programas que nuestra distribución traiga y de aquellos que instalemos. Es común que al instalar un nuevo programa en Linux se cree (o uno deba crear manualmente) una carpeta en este directorio que contiene los archivos mediante los cuales podemos controlar el comportamiento del programa en cuestión. Un ls a este directorio nos mostrará carpetas tales como apt, apache2, php5, mysql y demás aplicaciones que posean archivos de configuración editables por el usuario.

6- El directorio /home: aquí encontraremos los ficheros de los usuarios creados en el sistema operativo. Por lo pronto, durante el proceso de instalación de tu Linux, habrás creado un usuario root y un usuario con que utilizarás el sistema operativo por defecto  (/home/miusuario). Al bootear tu Linux ingresarás a la interface gráfica y los programas de que esta dispone con los datos de tu usuario no root. Recordemos que Linux es un sistema multiusuario (esto es, pueden haber 5 usuarios distintos en la misma máquina en el mismo momento) y mantiene la información de cada usuario aislada dentro de subdirectorios en home. Cada usuario creado dispone de su carpeta dentro de /home/nombredeusuario en que puede guardar información y configuraciones generales (de la interface gráfica por ejemplo) a la que sólo tendrá acceso él mediante su user y pass. Este es uno de los puntos fuertes de Linux desde hace tiempo. Vale aclarar que el usuario root puede acceder a los datos de cualquier usuario.

7- El directorio /lib: este fichero almacena librerías compartidas  para programas del  sistema operativo y módulos del kernel.

8- El directorio /mnt: este fichero oficia como punto de montaje para dispositivos tales como lectograbadoras de DVD, USB sticks, particiones de otros OS, etc. Si bien las distribuciones de hoy en día automontan DVDS o USB sticks en la carpeta /media en el pasado (cuando instalé mi primer Slackware,  por ejemplo) uno debía montar manualmente cualquier periférico a través del comando mount y el punto para dicho montaje era siempre el directorio /mnt. Si tenemos un Dual Boot y queremos que nuestras particiones de Windows estén disponibles en Linux podemos montarlas para que se carguen en el proceso de Booteo siguiendo estas instrucciones. Vale aclarar que el tutorial monta en /mnt, pero las particiones podrían ser montadas en cualquier otro sitio (/home/miuser/windows, por ejemplo). Lo cierto es que en distribuciones como la mía (Debian Squeeze) en que al introducir un DVD o un Stick USB el proceso de montaje se raliza automáticamente en /media el directorio /mnt parecería estar presente nada más que por romanticismo. Por suerte soy un romántico y he montado todos mis discos/particiones NTFS en él

9- El directorio /root: el rincón del administrador. Este fichero es al usuario root lo que a un usuario no root su fichero /home/nosoyroot. Tiene como finalidad brindarle al administador un espacio propio para trabajar y almacenar separado de los directorios del sistema y de los subdirectorios de usuarios con privilegios inferiores en /home.

10- El directorio /sbin: más ejecutables (binarios de sistema o system binaries). Este directorio extiende  la lista de programas disponibles en /bin para ser corridos desde consola, pero  en este caso son programas cuya utilización suele estar reservada para el root user. Un ls al directorio nos mostrará programas como iptables o shutdown que sólo deben estar al alcance de un superusuario o root (imaginen un Linux con 5 usuarios trabajando en que uno de los 5 pudiera apagar el sistema ... not good mate =).

11- El directorio /proc: este directorio provee información sobre el sistema. Podemos, por ejemplo, obtener información sobre nuestro procesador corriendo cat /proc/cpuinfo. Es interesante observar que se trata de archivos inexistentes en el rígido que son llamados desde la memoria RAM. Hagan un ls al dir para ver su contenido y luego un ls -l para ver el peso de los archivos que ls acaba de listar. OMG!

12- El directorio /usr: este directorio es como "un lugar más" en que se situan archivos que bien podrían ir en /sbin o /lib. Dicho esto, encontraremos aquí más ejecutables, más librerías, más código fuente (src), mucha documentación acerca de los programas contenidos, etc. Un ls de este directorio nos permitirá ver que, a diferencia de los mencionados anteriormente, aquí poseemos una estructura de subdirectorios que a su vez contienen mucha información. Si tu Linux vino con una serie de programas instalados, éstos se ejecutan -en la mayoría de los casos- desde este directorio. El Konqueror, por ejemplo, tiene su ejecutable en /usr/share/applications/kde4 (uso KDE ¿y qué?)

13- El directorio /var: por último, el directorio var -cuyo nombre proviene de variable- almacena una serie de archivos  que, como su nombre lo indica, suelen ser variables. Aquí encontraremos archivos de logs de diversas aplicaciones en constante cambio desde que la actividad en cada aplicación los modifica agregando información de su funcionamiento. Este directorio suele ser el destinado al alojamiento de sitios web (de hecho contiene por defecto una subcarpeta llamada /www). Es importante comprender que, con la excepción de los directorios de usuarios en /home y superusuario en /root, el resto de los directorios que hemos visto suelen mantenerse sin alteraciones (al menos si no instalamos o actualizamos) por lo que un directorio como /var es preciso dado que toda la actividad del sistema debe imprimir huellas en algún sitio y lo hace aquí.

Aclaraciones

Tenemos la obligación de aclarar que -como es evidente- no hemos hecho más que describir superficialmente los contenidos de cada uno de los directorios que configuran el sistema de archivos en Linux. Sin embargo, se trata de una breve introducción a una "nueva forma de pensar los cimientos del sistema operativo que utilizaremos" con que me hubiera gustado contar cuando por vez primera le di click al "subir nivel" hasta el root de mi Slackware y me encontré con esta colección de carpetas en que no estaban ni Documents and Settings ni Application Data.

Quizás quienes se inician en el mundo de Linux puedan leer esta pequeña introducción y comenzar a utilizar este gran sistema operativo comprendiendo su estructura mejor de lo que llegaron a entender lo que tuvieron bajo C:\ durante años. Ojalá así sea.

1. Nociones de Escalabilidad, Load Balancing y Failover

En este artículo veremos cómo configurar un Load Balancer con Failover usando software con el fin de Balancear un Web Server. Un Load Balancer es, en escencia, un sistema que recibe peticiones de un cliente, las procesa a partir de algún criterio (algoritmo) y finalmente las envía a alguno de los servidores que las resolverán y responderán.

Si ya estás familiarizado con los conceptos de escalabilidad, Load Balancing y Failover quizás quieras saltearte esta parte e ir directo al punto 2, en que comenzaremos a detallar la configuración de nuestro Cluster HA.

En esta oportunidad, balancearemos la carga de un Web Server (HTTP), pero los Load Balancers suelen permitir balanceo de diversos servicios tales como smtp, ftp, https, dns, pop3 y otros.

Pongamos por ejemplo que nuestro sitio web se encuentra alojado en un dedicado y que debido al alto tráfico el servidor comienza con picos de Server Load que sobrecargan el procesador. Esto, generalmente, tiene el poco feliz final de downtime o una respuesta lenta y nos pone frente al problema y el mundo de la escalabilidad: debemos resolver el alto tráfico de algún modo.

Ahora bien, existen dos modos de encarar este problema y conseguir que nuestro Servidor Web soporte el tráfico. En los 2 casos estaríamos "escalando" pero de distinto modo.

Escalar verticalmente
Tan simple como comprar un dedicado con mayor capacidad (CPU, RAM). Si el tráfico sigue creciendo y el día de mañana el nuevo Server nos queda chico nuevamente compramos uno más grande. Y así ...

Escalar horizontalmente
Este método apela a una solución más económica y consiste en agregar un nuevo servidor al servidor saturado de modo de tener 2 servidores web con copias idénticas de nuestro sitio y "repartir" el trabajo que antes realizaba el dedicado original. Un eventual crecimiento del tráfico permitiría agregar uno o más servidores.

En materia de escalabilidad, la solución correcta a la hora de responder a tráfico alto y posibilidades de que éste siga creciendo es escalar horizontalmente y es aquí donde los Load Balancers se tornan necesarios dado que una estructura de servidores como la descripta en el modelo de escalabilidad horizontal requiere que delante de los 2 o más servidores webs de que disponemos, exista un sistema que capture las peticiones de los visitantes y las envíe a uno u otro servidor, repartiendo de este modo el trabajo y la carga.

Decimos que la escalabilidad horizontal es el método adecuado porque escalar verticalmente tiene un límite (en algún punto llegaremos a la instancia en que compramos el Servidor más potente que nuestro Datacenter pueda ofrecernos, habremos invertido muchísimo dinero en Servidores y las migraciones  de la aplicación a un server más grande sin downtime y -finalmente- acabaremos pensando en escalar horizontalmente).

Por otro lado, escalar horizontalmente es económico, dado que se utilizan muchos boxes  de bajo costo.  Agregar un nuevo Box detrás del Load Balancer es tarea de minutos y no supone downtime de ninguna clase (al menos si las cosas salen bien). Se elimina además un problema fundamental en el mundo de la alta disponibilidad: el SPF o Single Point of Failure debido a que si un Box "se muere" el Balaceador detectará su estado (Failover) y seguirá enviando las peticiones de los clientes a los otros: tendremos tiempo de arreglarlo o reemplazarlo de un modo transparente para nuestros visitantes.

Las ventajas de escalar de este modo no terminan aquí (otra muy fuerte es el Global Load Balancing, que permite detectar la ubicación geográfica de nuestro visitante y resolver sus peticiones con el Servidor más cercano a él). En resumen, explicar las virtudes de escalar horizontalmente requeriría un extenso artículo dedicado al tema. Nos bastará con saber que éste es el esquema elegido por Google, Facebook y, en línea generales, todos los sitios que deben resolver millones de Requests por segundo día a día.

2. Comenzando con nuestro Load Balancer

Antes de comenzar a configurar nuestro LB, debemos introducir -aunque sea, brevemente- una distinción acerca de estos sistemas ubicados al frente de nuestros servidores. Existen 2 tipos de Load Balancers. Estos son:

1. Hardware Load Balancer
2. Software Load Balancer

Load Balance con Hardware supone utilizar equipos de red diseñados específicamente para realizar Balanceo de Carga. Se trata en todos los casos de dispositivos con un costo bastante alto. Un ejemplo típico es el conocido F5 Big Ip de F5 Networks, aunque existen muchas empresas que fabrican éste tipo de componentes de Networking.

Por otro lado, hacer Load Balancing con Software supone contar con Boxes dedicados exclusivamente a esta tarea. Estos boxes corren Linux y sobre ellos instalamos algun software que se encargará de realizar el balanceo.

Existen diversas soluciones para hacer Load Balancing con Software. La más conocida es, quizás, Linux Virtual Server (LVS), pero hemos optado en este caso por Haproxy, dado que es una solución tan robusta como sencilla de poner a andar, representando la elección ideal para introducirnos en el mundo del Load Balancing.

2.1 Nuestro escenario

Visto y considerando que balancearemos un Servidor Web que corre una aplicación PHP/MYSQL necesitamos como mínimo disponer de 3 equipos con Linux (Debian Squeeze, en nuestro caso). Uno de los equipos será destinado al Balanceo y los otros dos serán los servidores lampp detrás de éste. Necesitaremos además crear una IP virtual en el balanceador, a la que direccionaremos todo el tráfico.

Aquí están los valores con que trabajaremos

- Nodo1:  Load Balancer - Debian Squeeze + Haproxy (192.168.1.31)
- Nodo2:  Server HTTP - Debian Squeeze + LAMPP (192.168.1.32)
- Nodo3:  Server HTTP - Debian Squeeze + LAMPP (192.168.1.33)
- IP Virtual: 192.168.1.20
- Dominio virtual: www.sitio.dev

3 notas sobre este entorno

1. Es muy importante que nuestras interfaces de Networking en cada box estén configuradas estáticamente y no vía DHCP. Si éstas obtienen su IP vía DHCP es hora de setearlas a static. Hacer esto es muy simple y pueden seguir éste artículo para llevar esta tarea a cabo.

2. Debido a que estamos trabajando en una Red local no usaremos Bind9 para resolver nombres  de dominios. Nos limitaremos a editar el archivo hosts del Box Balanceador para que un nombre de dominio ficticio www.sitio.dev apunte a la IP virtual (192.168.1.20).

3. Al lector atento no se le habrá escapado que este entorno tiene un SPF a nivel del Load Balancer: si la máquina corriendo Linux y Haproxy se cae por alguna razón nuestro sitio alojado en los 2 Servidores no responderá cuando ingresemos www.sitio.dev en nuestro navegador. Nos hemos tomado la licencia de trabajar con este SPF para la redacción de este artículo, pero si quisieramos configurar un Cluster de alta disponibilidad con Failover en producción lo ideal sería disponer de un segundo Box pasivo balanceando que tomara la tarea del primero ante una eventual falla (arquitectura active/passive). Estos 2 Load Balancers podrían utilizar heartbeat para conocer su estado constantemente de modo que ante una eventual falla en el Load Balancer 1 la IP Virtual resolviera al Load Balancer 2.

 3. Configurando nuestra IP Virtual (192.168.1.20) y preparando los servidores web.

Vamos a editar nuestro fichero /etc/network/interfaces en nodo1 (el Load Balancer) para crear una IP Virtual.

carp@nodo1:/$ su root
Contraseña: Ingresamos clave Root
root@nodo1:/# pico /etc/network/interfaces
Debajo de la declaración estática de la Ip de este Box, agregamos:
# Load Balancer VIP
auto eth0:1
iface eth0:1 inet static
  address 192.168.1.20
  gateway 192.168.1.1
  netmask 255.255.255.0
  network 192.168.1.0
  broadcast 192.168.1.255
salvamos (ctrl+o), salimos (ctrl+x) y reiniciamos la red

root@nodo1:/# /etc/init.d/networking restart
Reconfiguring network interfaces...
done.
root@nodo1:/# 
Podemos comprobar la creación de nuestra VIP con ifconfig
root@nodo1:/#  ifconfig

[...]
eth0:1    Link encap:Ethernet  HWaddr 00:1d:60:d9:03:9a
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
[...]

Creada nuestra VIP, editaremos hosts para apuntar el dominio www.sitio.dev a élla.

root@nodo1:/# pico /etc/hosts
Agregamos debajo de los valores del fichero:
192.168.1.20 sitio.dev www.sitio.dev
salvamos (ctrl+o) y salimos (ctrl+x) 

Recordamos que por tratarse de una configuración local no utilizamos (aunque podríamos) Bind9 para resolver dominios.  Si así lo hicieramos deberíamos registrar la entrada www como CNAME en la zona correspondiente. Aquí nos limitamos a controlar el dominio ficticio desder hosts y lo repetimos con y sin las www para que éste sea accesible de los 2 modos.

Ya tenemos nuestra VIP configurada en nodo1 y el dominio www.sitio.dev apuntando a ella: estamos listos para comenzar con Haproxy, pero antes -siempre resta algo- tendremos que realizar una modificación en el modo en que nuestros 2 servidores Lampp (192.168.1.32/33) almacenarán los logs.

Haproxy funcionará como un proxy transparente delante de nuestros servidores web y es de fundamental importancia que los configuremos para que al hacer logging lo hagan con las IPS de nuestros visitantes y no con la del Balanceador (de otro modo todos los request en access y error.log tendrán como IP 192.168.1.20).

Para evitar esto ingresamos a cada Box -por lo general a través de ssh- y buscamos en el fichero apache2.conf (en mi caso, las últimas líneas del archivo). Al llegar a la parte en que se definen los Logs encontraremos una explicación comentada de lo que necesitamos cambiar.

Vamos con el primer Servidor Web (nodo2 : 192.168.1.32)

root@nodo1:/# ssh 192.168.1.32
Ingresamos clave root del Box nodo2:
root@nodo2:/# pico /etc/apache2/apache2.conf

Bajamos hasta el final del fichero y encontraremos:

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

Tal cual se explica arriba de esta sección como comentario necesitamos intrudoducir este cambio:

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %O" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

salvamos (ctrl+o) y salimos (ctrl+x)

Las modificaciones no terminan aquí. El mecanismo de Failover de nuestro software de Balanceo (Haproxy) consiste en enviar requests cada x cantidad de segundos (este valor es configurable, como veremos más adelante) a cada Box para saber si éste se encuentra o no disponible. Para esto, se suele crear un fichero .txt vacío en cada box que Haproxy solicitará para conocer su estado. Si Haproxy obtiene una respuesta positiva (OK 200) entonces el servidor está funcional. Si por el contrario el Request al fichero .txt no es respondido Haproxy no enviará más solicitudes a ese servidor y dirigirá todo el tráfico al otro/s.

Ahora bien, necesitamos decirle a nuestros servidores que no computen estas solicitudes ni la logueen, debido a que esto aumentaría drásticamente el tamaño de nuestros logs. Para lograrlo, editaremos el fichero de cofiguración de VirtualHosts en cada uno de los Boxes indicando explicitamente que toda solicitud del archivo test.txt (así se llamará el archivo que aún no creamos) no debe ser incluída en los logs.

Seguimos con la sesión ssh en 192.168.1.32
root@nodo2:/# pico /etc/apache2/sites-enabled/www.sitio.dev

Este fichero es copia de 000-default (el archivo que Apache2 trae por defecto) y en él debemos buscar la sección Log Files y modificarla de modo que esto:

 # Log files
CustomLog /var/log/apache2/access.log combin 

quede así:

 # Log files
SetEnvIf Request_URI "^/test\.txt$" dontlog
CustomLog /var/log/apache2/access.log combined env=!dontlog 

salvamos (ctrl+o), salimos de nano (ctrl+x) y finalmente cerramos la sesión ssh con exit

Ingresamos al segundo servidor web vía ssh  (nodo3 : 192.168.1.33) y repetimos lo hecho en los ficheros /etc/apache2/apache2.conf y /etc/apache2/sites-enabled/www.sitio.dev.

Una vez que hemos realizado estas modificaciones en ambos servidores, nos reconectamos vía ssh y creamos el archivo test.txt vacío en cada uno en el nivel en que nuestro sitio se encuentra (en cada box corremos touch /var/www/test.txt).

4. Instalando y configurando Haproxy

Al fin llegamos al punto en que instalamos el software con que realizaremos Load Balancing. Si bien el orden en que estos pasos se han llevado a cabo (preparar los servidores web antes de instalar Haproxy) no tienen por qué transitarse de este modo, es recomendable siempre "preparar" nuestros boxes para el software antes de instalarlo. De esta forma, luego podemos dedicarnos pura y exclusivamente a la configuración del mismo olvidando el resto.

root@nodo1:/$ su root
Contraseña: Ingresamos clave Root
root@nodo1:/# apt-get install haproxy

Una vez instalado Haproxy (link al paquete por las dudas) procedemos a configurarlo. Debido a que este fichero trae consigo mucha información que no utilizaremos, creamos una copia del original y luego borramos su contenido para poder ingresar nuestra configuración desde 0.

root@nodo1:/$ cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy_orig.cfg
root@nodo1:/# cat /dev/null > /etc/haproxy/haproxy.cfg
root@nodo1:/# pico /etc/haproxy/haproxy.cfg

 Ingresamos al fichero en blanco y en él introducimos: 

global
        log 127.0.0.1   local0
        log 127.0.0.1   local1 notice
        maxconn 4096
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 2000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000

listen lbservers 192.168.1.20:80
        mode http
        stats enable
        stats auth carp:miclave
        balance roundrobin
        cookie uid prefix
        option httpclose
        option forwardfor
        option httpchk HEAD /test.txt HTTP/1.0
        server nodo2 192.168.1.32:80 cookie A check
        server nodo3 192.168.1.33:80 cookie B check

Guardamos (ctrl+o) y salimos (ctrl+x)

Hemos definido en la sección listen la ip virtual a que el Balanceador responderá y el puerto (que por ser Balanceo HTTP es 80). Definimos además un usuario y clave para las stats (que nos permitirán ver el estado de nuestro farm de servers) y optamos por el algoritmo Round Robin para balancear la carga. Como todo buen balanceador, Haproxy permite otros métodos para balancear que no veremos aquí pero es recomendable conocer. Además, definimos la cookie con nombre uid (que de hecho se crea en nuestra aplicación cuando un usuario se conecta con su cuenta) como parámetro para fijar sticky sessions (esto significa que una vez el usuario inicia sesión el Balanceador lo mantendrá en el Box en que se logueó de modo de conservar los valores de la sesión que no se encuentran en otros boxes). Finalmente indicamos el nombre del fichero (test.txt) que le dirá al balanceador si los servidores se encuentran o no usables y, por último, listamos los 2 boxes con lampp hacia los cuales deberán dirigirse los Requests.

Ahora vamos a agregar Haproxy a init de modo que se cargue al bootear linux. Esto se realiza seteando ENABLED=1 en /etc/default/haproxy

root@nodo1:/# pico /etc/default/haproxy
Cambiamos ENABLED=0 por ENABLED=1
Guardamos (ctrl+o) y salimos (ctrl+x)

5. Finalizando la configuración y probando nuestro Balanceador

Sólo un paso nos separa de ingresar www.sitio.dev en nuestro navegador y obtener el sitio web de alguno de los 2 servidores que lo alojan. Debemos agregar al archivo /etc/sysctl.conf la variable net.ipv4.ip_nonlocal_bind con valor 1 para que el kernel permita a nuestras aplicaciones (Haproxy) utilizar una IP que no está asociada a ningún dispositivo (nuestra vip, que no posee un placa). Ingresamos al fichero de configuración y agregamos al final la siguiente línea:

root@nodo1:/# pico /etc/sysctl.conf
En el final agregamos:
net.ipv4.ip_nonlocal_bind=1
Guardamos (ctrl+o) y salimos (ctrl+x)

Una vez reiniciemos el Load Balancer la configuración que acabamos de agregar será cargada. Para evitarnos un reboot innecesario la cargaremos con el comando:

root@nodo1:/# sysctl -p
Y al fin arrancamos Haproxy
root@nodo1:/# /etc/init.d/haproxy start
Starting haproxy: haproxy.
root@nodo1:/# 

Si Haproxy ha comenzado sin problemas y los servidores web nodo2 y nodo3 están corriendo Lampp sin inconvenientes tendríamos que obtener el sitio que alojamos en ellos al ingresar en un navegador (en mi caso el Box con Haproxy tiene GUI y navego desde ahí) www.sitio.dev

Es una buena idea agregar en el body del index.php de ambos sitios algo como "nodo2" y "nodo3" en los respectivos servidores de modo de poder cargar la página y saber a qué box envió la petición Haproxy.

Podemos ver el estado de nuestro cluster de servidores ingresando a: http://192.168.1.20/haproxy?stats (les pedirá el user y pass que han definido en /etc/haproxy/haproxy.cfg, sección listen directiva stats.

Pueden probar el failover deteniendo uno de los 2 servers para verificar que el sitio seguirá mostrándose desde el otro y ver en el panel de stats de Haproxy como el server detenido aparece en rojo.

6. Consideraciones finales

Haproxy es software poderoso a la hora de realizar Load Balancing con Failover y, como hemos visto, configurarlo no nos ha representado mayores dificultades. Está claro que hemos realizado una configuración básica y seguramente podría mejorarse en varios aspectos. Hemos decidido, simplemente, "ponerlo a andar" como primer paso (esto no es poco). Una vez funcionando pueden estudiar en profundidad el software y tweakearlo como les guste.

Aquí hemos asumido que los 2 sitios webs php/msyql alojados en los servers webs detrás del LB, ya han resuelto la sincronización de sus contenidos. Este no es un tema menor y hemos, con anterioridad, cubierto posibles soluciones tanto para sincronizar ficheros como para tener las bases de datos mysql en idéntico estado.

Usé mi DVD de Debian Squeeze e instalé la misma distro en tantas PCS completas como tenía (en su momento tenía 2 PCS que oficiarían como Servidores Lampp detrás de un Load Balancer a configurar en mi PC de trabajo).

Como siempre, al realizar la instalación de Debian, elegi que la configuración del equipo en red se realizara vía DHCP: antes de usar Debian usé Slackware, luego Centos y siempre instalé con DHCP por la simple razón de que al terminar la instalación e ingresar a la X abría el Konqueror y Google estaba ahí.

No tardé gran cosa en darme cuenta de que los nodos de mi red con networking seteado vía DHCP cambiabian de IP (lo cual suponía acomodar una larga lista de cosas en que se apuntaba a los boxes con las ips obtenidas vía ifconfig).

Fue así que me dispuse a configurar IPS estáticas para todos los Boxes de mi red linux y evitarme las modificaciones que tendría que realizar cada vez que mi Router se reiniciaba.  Sorprendentemente, designar una IP fija para cada Box fue mucho más simple de lo que pensaba y me bastó con editar el fichero /etc/network/interfaces de cada PC con Linux en la red.

A continuación detallo los pasos a seguir. Estos deben correrse en tantos Boxes como uno quiera setear con IP estática dentro de la Red.

carp@server:/$ su root
Ingresamos Pass de root
root@server:/# pico /etc/network/interfaces

Si han instalado Linux y configurado la Red con DHCP este fichero debería contener esto:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface - use DHCP to find our address
auto eth0
iface eth0 inet dhcp

Supongamos que tenemos 3 máquinas corriendo linux y queremos asignarles las IPS
- 192.168.1.30
- 192.168.1.31
- 192.168.1.32

Para lograr esto tendremos que modificar nuestra primary network interface en el archivo /etc/network/interfaces de cada uno de los Boxes. Mostraremos cómo quedaría el primero dado que en los 2 restantes la configuración será identica con la excepción de la IP que irá cambiando de 30 a 32:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
 address 192.168.1.30
 gateway 192.168.1.1
 netmask 255.255.255.0
 network 192.168.1.0
 broadcast 192.168.1.255

Repetiríamos este procedimiento 2 veces en las 2 máquinas restantes variando el valor address a 192.168.1.31 y 192.168.1.32 respectivamente. Finalmente, una vez que los archivos de los 3 boxes han sido modificados, necesitamos reiniciar el servicio de networking.

root@server:/# /etc/init.d/networking restart
Reconfiguring network interfaces...
done.
root@server:/# 
 Una vez reiniciado el servicio de Networking podemos chequear las IPS
root@server:/# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:1d:60:d9:03:9a
          inet addr:192.168.1.30  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21d:60ff:fed9:39a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:162846 errors:0 dropped:0 overruns:0 frame:0
          TX packets:147001 errors:0 dropped:0 overruns:0 carrier:1
          collisions:0 txqueuelen:1000
          RX bytes:134065556 (127.8 MiB)  TX bytes:14926261 (14.2 MiB)

DHCP funcionará bien si lo que nos interesa es Correr Linux como sistema operativo y poder navegar internet, pero en la medida en que nos ponemos pretensiosos (y quienes nos metemos con Linux somos gente generalmente inquieta)  ya sea para armar un Servidor de Alta Disponibilidad, un Cluster o cualquier otra arquitectura en red que implique comunicación entre boxes a través de sus IPS internas, las IPS dinámicas provistas por DHCP se convertirán en un verdadero problema.

Afortunadamente, solucionarlo es sencillo.

Lo primero con que nos encontramos al instalar, en mi caso Debian Squeeze, e iniciar el sistema es que, si bien durante la instalación de Debian se reconocen otras particiones con NTFS al ingresar éstas o bien no están en /mnt o bien aparecen pero no puede escribirse en ellas.

Lograr que al iniciar Linux las particiones Windows aparezcan y puedan escribirse  es sencillo y  requiere editar el fichero /etc/fstab. Tomemos mi caso:

Mi PC tiene 3 HHDD SATA, 2 de 500GB y uno de 360GB en el que tengo un Dual Boot Win7/Debian6. En total, sin contar la partición de Debian tengo 4 Discos y particiones (uno de los discos de 500GB no está particionado y se utiliza para Backups). Es decir que necesitaba poder disponer, utilizar y escribir desde Debian en estas 4 particiones.

La solución -como dije- fue muy simple:

carp@server:/$  su root
 Ingresamos pass de root
root@server:/# pico /etc/fstab
Al final del fichero fstab, agregué:

/dev/sda2  /mnt/winsys ntfs-3g  umask=0,nls=utf8 0 0
/dev/sda5  /mnt/windata ntfs-3g umask=0,nls=utf8 0 0
/dev/sdb1  /mnt/backup ntfs-3g  umask=0,nls=utf8 0 0
/dev/sdc1  /mnt/data3 ntfs-3g  umask=0,nls=utf8 0 0

Salvar y salir

Al reiniciar y entrar a Debian allí estaban mis particiones con permisos de lectura/escritura. Es importante guardar una copia del original cuando trabajaremos sobre ficheros sensibles como lo es fstab (un error allí puede traer un lindo dolor de cabeza al reiniciar). Si bien  yo no lo he hecho en los procedimientos aquí detallados,  lo hago siempre antes de tocar con cp /etc/fstab / etc/fstab_orig lo cual me daría la posibilidad de restaurar el original en caso de panic!

Linux ofrece muchas alternativas a la hora de instalar un ftp-server y hemos optado en este caso por trabajar con ProFTPD debido a que es un servidor ftp robusto y configurarlo con medidas extra de seguridad (TLS) es relativamente sencillo.

La necesidad de securizar nuestras transferencias FTP con un protocolo como TLS (Transport Security Layer) reside en que al operar con FTP estamos moviendo a través de internet archivos de texto plano que podrían ser facilmente legibles en caso de que, por ejemplo,  trabajemos en una red en que corre un Sniffer. La tarea de TLS será la de garantizar que los datos de conexión al servidor FTP y los paquetes que subamos o bajemos sean encriptados de modo tal que, ante un sniffer u otra herramienta que intercepte nuestra tráfico no corramos el riesgo de exponer información valiosa.

Instalando PROFTPD

Comenzaremos por instalar y configurar este servidor FTP. Al finalizar esta sección tendremos un servidor FTP funcionando sin ninguna clase de securización.

Trabajaremos sobre Debian Squeeze y asumimos que hay un Lampp instalado y corriendo (aunque realmente no lo precisaremos) al que deseamos agregarle un servidor FTP con el que cargar contenidos al directorio en que se encuentra nuestro sitio.

carp@server1:~$ su root
 Ingresamos clave de root 
root@nodo0:/# apt-get install proftpd openssl

La instalación preguntará si deseamos correr el server FTP como Standalone (Independiente), o desde inetd. Elegimos Standalone.

Una vez terminado el proceso de instalación ya tenemos nuestro servidor ftp instalado y funcionando. Intenta una conexión usando  una cuenta no root y conseguirás acceso al home del usuario empleado. Como verás puedes subir niveles hasta / y acceder a archivos de configuración en /etc: el usuario puede explorar todo el servidor y esto es algo que -por razones evidentes- no queremos.

Necesitamos poner un jail para que cuando el user carp se conecte, ingrese al listado de /home/carp sin posibilidades de subir de nivel. Esto es muy sencillo de realizar modificando el valor de DefaultRoot en el archivo de configuración de proftpd (/etc/proftpd/proftpd.conf).

root@nodo0:/# /etc/init.d/proftpd stop
Stopping ftp server: proftpd.
root@nodo0:/# pico /etc/init.d/proftpd.conf
Buscamos en el fichero de configuración la línea comentada:
# DefaultRoot ~
La descomentamos y modificamos de modo que quede:
DefaultRoot /var/www carp
Guardamos, salimos e Iniciamos ProFTPD nuevamente:
root@nodo0:/# /etc/init.d/proftpd start

Basicamente hemos descomentado el parámetro que nos permite restringir el acceso vía FTP proporcionando el path al que nuestro user (carp) debe acceder al conectarse seguido del nombre de usuario.

Si reiniciamos proftpd e intentamos conectarnos nuevamente con el user carp FTP listará los contenidos de /var/www y no habrá posibilidad de subir niveles: /www es la rama más alta en el árbol de este usuario.

Securizando nuestro servidor FTP con TLS

Hasta aquí disponemos de un servidor 100% funcional. Ahora nos encargaremos de securizarlo utilizando TLS.

Si bien ProFTPD viene con soporte para TLS, tendremos que crear un certificado SSL para poder habilitar esta funcionalidad. Dicho esto, vamos a crear un directorio ssl dentro de /etc/proftpd en que guardaremos nuestro Certificado y Key SSL.

root@nodo0:/# mkdir /etc/proftpd/ssl
root@nodo0:/# openssl req -new -x509 -days 365 -nodes -out /etc/proftpd/ssl/proftpd.cert.pem -keyout /etc/proftpd/ssl/proftpd.key.pem   

Se nos presenta un aviso y un formulario en que debemos proporcionar datos básicos:

Generating a 1024 bit RSA private key
.........++++++
........................................++++++
writing new private key to '/etc/proftpd/ssl/proftpd.key.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:AR
State or Province Name (full name) [Some-State]:Buenos Aires
Locality Name (eg, city) []:Merlo
Organization Name (eg, company) [Internet Widgits Pty Ltd]:DDM
Organizational Unit Name (eg, section) []:DDM
Common Name (eg, YOUR name) []:Daniel
Email Address []:info@tarsky.com   

root@nodo0:/#

No entraremos en detalles acerca de cómo crear Certificados SSL con Openssl, pero sí recomendamos -a quienes quieran conocer un poco más acerca de la creación de certificados self-signed- la lectura de este How To en el sitio de Openssl.

Habiendo creado nuestro certificado volvemos sobre el archivo de configuración de ProFTPD para habilitar la funcionalidad de TLS.

root@nodo0:/# pico /etc/init.d/proftpd.conf
Buscamos y descomentamos quitando el #:
Include /etc/proftpd/tls.conf
Guardamos y salimos.

A continuación y finalizando, debemos configurar el fichero /etc/proftpd/tls.conf que viene con el paquete proftpd. Debido a que este fichero contiene unas cuantas líneas nos resultará más sencillo eliminar su contenido y reescribir los parametros de configuración para que TLS funcione con nuestro certificado y clave. Manos a la obra:

root@nodo0:/# cat /dev/null > /etc/proftpd/tls.conf
root@nodo0:/# pico /etc/proftpd/tls.conf
Nos encontraremos con el fichero en blanco y allí escribimos:

<IfModule mod_tls.c>
TLSEngine on
TLSLog /var/log/proftpd/tls.log
TLSProtocol SSLv23
TLSOptions NoCertRequest
TLSRSACertificateFile /etc/proftpd/ssl/proftpd.cert.pem
TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key.pem
TLSVerifyClient off
TLSRequired on
</IfModule> 

Guardamos, salimos y reiniciamos proftpdf
root@nodo0:/# /etc/init.d/proftpd restart
Stopping ftp server: proftpd.
Starting ftp server: proftpd.
root@nodo0:/#

Y eso es todo! Nuestro Servidor FTP cuenta ahora con la seguridad de transacciones protegidas por un protocolo de encriptación basado en SSL.

Conectando con mi FTP Client

Para terminar, hay que aclarar que el hecho de haber implementado TLS sobre FTP implicará realizar un tipo de conexión desde el cliente FTP que utilicemos distinta a la que acostumbramos usar para acceder a una cuenta de FTP sin ninguna clase de securización.

La mayoría de los clientes FTP poseen la opción de conectar a FTP con TLS (Este tipo de conexión suele llamarse FTPS también). En el caso de Fillezilla, basta con ingresar los datos como de costumbre con la salvedad de que en cifrado debe elegirse "Requiere FTP Explicito Sobre TLS" en lugar del valor por defecto "Utilizar FTP simple".

En caso de no encontrar la opción para realizar conexiones TLS, revisen la documentación del cliente para asegurarse de que éste posee soporte (y si no lo tiene consideren seriamente utilizar otro cliente).

Las operaciones de control a realizar antes de ejecutar el comando eran nada más que 2:

1) El script debía verificar que quien lo ejecutara fuera Root, de otro modo a rootearse.
2) Además, necesitaba verificar que el servicio pasado como primer flag fuese un archivo existente de hecho en /etc/init.d/

Lo escribi primero en Perl y luego en Bash para poder agregarlo definitivamente a mi PATH. Mostraré aquí sólo la versión de Bash y los procedimientos para incorporarlo definitivamente al PATH de trabajo. Al final del artículo dejo link a las 2 versiones por si alguien prefiere Perl.

El Script Bash

#!/bin/bash

# Only allow to run script if Root
if [[ $EUID -ne 0 ]];
   then
   echo "Permisos insuficientes. Corra este script como Root!" 1>&2
   exit 1

   else

      #Check if service exists
      if [ -f /etc/init.d/$1 ]
      then
      # We do have a service, lets shoot the Flag (System will give valid options if bad Flag):
      exec  /etc/init.d/$1 $2 

      else
      #No Service at init.d, return error ...
      echo "El servicio "$1" no existe en /etc/init.d/";
      fi

fi

Escrito y chequeado el Script, me dispuse a agregar la carpeta /serverscripts (donde planeo ir almacenando scripts de esta clase) al PATH de Bash.

root@carp:/# pico /root/.bashrc

Debido a que considero más prolijo definir los PATHS que usaré a futuro sin tocar el archivo .bashrc agregué en el la línea:

source ~/.mypaths

Guardé cambios y luego cree el archivo en que, en principio, incluiría el directorio /serverscripts a mi PATH de trabajo:

root@carp:/# pico /root/.mypaths
en el fichero escribi
export PATH=$PATH:/serverscripts
Guardé y reboot para asegurarme de que el fichero permanecería en PATH

Al reloguearme, echo $PATH incluía /serverscripts entre los PATHS de trabajo y mi pequeño programa en Bash funcionaba sin problemas con comando de tipo services mysql restart independientemente de donde lo corriera. Un pequeño y sencillo programita que va a ahorrarme mucho tiempo sin duda.

Dejo links para descargar en Bash o Perl.
Saludos

Services.sh (Bash)
Services.pl (Perl)

Ya hace algunos años ha aparecido una pequeña aplicación en Perl llamada Slowloris que permite realizar un ataque de DOS (Denial of Service) contra sitios con infraestructuras de servidores no Balanceados. Para explicar rapidamente el funcionamiento de este script, citemos las palabras de su creador:

"Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they'll allow. "

Traducido y resumido: lo que es este pequeño script hace es enviar una cantidad importante de HTTP REQUESTS incompletos, lo cual impide que el servidor reciba->atienda->despache el Request. En otras palabras los servidores acumulan estos Requests sin posibiliad de "despacharlos" desde que no pueden satisfacer vía Response las peticiones por no estar estas bien formadas a pesar de ser reconocidas como peticiones válidas.

Sorprenderá saber que entre los Servidores Web que se encuentran afectados por este script figuran (Apache 1.x y 2.x). Nos interesa especialmente poder poner esta herramienta a funcionar para analizar el grado de susceptibilidad que nuestros servidores puedan tener.

Es por esto que -con fines educativos- explicaremos cómo instalar y utilizar este pequeño pero efectivo script.

IMPORTANTE: he probado este script en Debian y Centos. No lo he hecho en Windows aunque, tratandose de Perl, debería ser posible correrlo sobre Win siempre que se cuente con Perl y las librerías necesarias instaladas.

Realizando un DOS con Slowloris

Descargaremos el código fuente desde http://ha.ckers.org/slowloris/slowloris.pl. El script es Perl y puede leerse (tarea que recomiendo para comprender en profundidad su funcionamiento). Una vez tenemos el script en nuestro ordenador le asignamos permisos de ejecución con chmod 777 slowloris.pl. Para que slowloris corra Perl necesita los módulos: IO::Socket::INET
, IO::Socket::SSL.

Estos módulos pueden instalarse a través de CPAN del siguiente modo:

root@carp:/#  perl -MCPAN -e 'install IO::Socket::INET'
root@carp:/#  perl -MCPAN -e 'install IO::Socket::SSL'

Si bien esto debería resolver las dependencias requeridas por Slowloris, recomiendo además correr

root@carp:/#  apt-get install libio-socket-ssl-perl

debido a que a pesar de tener el interprete de Perl instalado y haber incorporado los 2 módulos sin problemas el siguiente error me aparecía a querer ejecutar el script.

Can't locate IO/Socket/SSL.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.1 /usr/local/share/perl/5.10.1 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .) at slowloris.pl line 4.
BEGIN failed--compilation aborted at slowloris.pl line 4.

Habiendo instalado el componente libio-socket-ssl-perl, Slowloris comenzó a funcionar sin problemas y bastó con tipear:

root@carp:/#  perl /path/to/slowloris.pl -dns nodo1

para dejar el Box que responde a ese hostname en /etc/hosts inutilizable. Es tan simple como eso ... Demás está decir que si nodo1 hubiese sido algún website sobre Apache en internet, éste hubiera caído del mismo modo en que cayó mi Box.

Por fortuna, mis HTTP servers corren detrás de un Load Balancer (Haproxy en caso de LB con software o F5 en caso de Hardware) y los ataques realizados mediante esta técnica contra el frente de mi Infraestructura no son efectivos (esta ha sido la razón por la cual instalé Slowloris y le tiré a morir al dominio e Ip virtual al frente de mi aplicación).

Ignoro qué tan al día estarán Hosting Providers trabajando con Apache respecto a los mecanismos para detener estos ataques pero pueden encontrarse en Google varios posts en que se explican posibles soluciones a este sencillo pero efectivo ataque (que van desde Balancear Carga hasta técnicas vía Firewall y NetFilter).

Dejo un buen artículo para comenzar a leer acerca de esta vulnerabilidad: http://www.funtoo.org/wiki/Slowloris_DOS_Mitigation_Guide. Si les importa la seguridad de sus aplicaciones web y éstas corren sobre Apache es irresponsable no conocer si son o no atacables mediante este método.

No creo que haga falta explicar que si dejan Slowloris pasandolé REQUESTS a algún site y se van a dormir, la IP desde la que estan enviando el DOS quedará registrada miles de veces en los access.log del server.

Conocer estas herramientas, utilizarlas y entenderlas siempre es bueno porque uno no puede defenderse de algo cuyo funcionamiento ignora. Lo que cada uno haga queda por cuenta de cada uno y me limito a decir que si poner offline algunos sitios con este programa te hace sentir un "Hacker" vas por mal camino ;P

Antes de comenzar, considero importante dedicar algunas palabras a la Replicación de datos en Mysql. Recomiendo, además, la lectura del anterior artículo ya que gran parte de lo que veremos aquí fue escrito en él desde que Mysql no tiene una solución específica para Replicar Master-Master y arribamos a este modelo duplicando el trabajo realizado al replicar Master-Slave: es decir, creamos replicacion de master (box1) a slave (box2) y luego repetimos el proceso de master (box2) a slave (box1) de suerte que arribamos -en este caso- a una interface con 2 bases de datos sobre las cuales se pueden realizar tareas INSERT/UPDATE/DELETE, etc que impactarán de inmediato en la contigua.

La replicación supone un mecanismo para mantener contenidos alojados en Bases de Datos en sincronía y es, por lo tanto, una estrategia de valor a la hora de escalar. Mysql ofrece la posibilidad de Replicar de una Base de Datos llamada Master a otra Slave. Este modelo, como comentamos en el artículo en que desarrollamos dicha metodología, tiene sus limitaciones y sus beneficios. Las limitaciones se dan en el campo de la funcionalidad de un Slave, que sólo permite operaciones de lectura (SELECT) dejando los writes a cargo del Master. Sin embargo, es bien sabido que en sitios de alto tráfico  un importante porcentaje (al menos un 70%) de la interacción con la Base de datos es de tipo lectura: los usuarios se pasean por nuestro sitio y eventualmente escriben la Base de Datos.

Es así que tener Servidores de Bases de Datos que sólo permitan lectura puede ser una buena estrategia dado que se podría, por ejemplo, direccionar todo el tráfico de usuarios no conectados a esos servidores liberando a los servidores encargados de escribir en Base de Datos del grueso del tráfico. Recordemos que un Master puede tener tantos Slaves como le coloquemos.

Claro está que con el tráfico llegará la necesidad de poder responder a interacciones write con la Base de Datos lo cual supondrá poseer mas de una BD en que puedan realizarse INSERTS/UPDATES/DELETES. Si bien Mysql no otorga una solución específica en materia de Replicación para sincronizar Bases de Datos Write, ésto puede realizarse muy facilmente  con una vuelta de tuerca a la Replicación Master-Slave. Con el tiempo y el tráfico creciente nos encontraremos con una arquitectura de BDS Write sincronizadas que a su vez tendrán Slaves para lectura. Las posibilidades para hacer HA escalando horizontalmente son varias y la Replicación en Mysql es uno de varios métodos disponibles.

Dichas estas palabras, comencemos con el armado de nuestra arquitectura MASTER-MASTER

Nuestro escenario

Para este tutorial usaremos 2 boxes con Lampp instalados sobre Debian Squeeze. Estos son los valores con que trabajaremos:

Box Lampp 1 (server1) = 192.168.1.31
Box Lampp 2 (server2) = 192.168.1.32
Base de datos instalada en ambos servers: blog (la BD de un WordPress)
Usuario Mysql = daniel
Clave Mysql = demichele

Asumimos Lampp funcionando con phpmyadmin instalado para disponer de una interface gráfica con que comprobar la replicación así como la base de datos a replicar instalada en los 2 servidores en estado idéntico.

Configuracion Box 1 (192.168.1.31)

Comenzaremos con el primer Box modificando el archivo de configuración de mysql ubicado en /etc/mysql/my.cnf. Mi experiencia con replicación me ha enseñado que lo mejor es empezar por poner a andar un Master-Slave y, una vez que éste funciona, realizar el proceso inverso en el Box 2. Internet está plagada de tutoriales en que se muestran los ficheros my.cnf de los boxes involucrados y las sentencias cruzadas de GRANT REPLICATION SLAVE. Lo cierto es que, si uno copia y pega los contenidos de los archivos modificando los valores y corre los GRANT REPLICATION SLAVE, luego la replicación muy posiblemente no funcionará: nos encontraremos en Google buscando por qué obtenemos  Slave_IO_Running: No con SHOW SLAVE STATUS\G;

Recordemos: la replicación Master-Master es en realidad replicación Master-Slave en 2 sentidos, por lo que comenzar logrando Master-Slave es tener la mitad del trabajo resuelto.

Vamos a la consola:

carp@server1:~$ su root
ingresamos password de root
root@server1:/# pico /etc/mysql/my.cnf

En el archivo my.cnf comenzaremos por quitar la restricción a localhost comentando la línea bind-address = 127.0.0.1 que limita el alcance del servicio a la interface local. Vamos a comentar esta línea con # de modo que quede:

#bind-address = 127.0.0.1

Bajamos un poco más en el archivo dentro de la cabecera [mysqld] hasta llegar a la sección Logging and Replication y buscamos la línea comentada #server-id = 1. Allí modificamos como sigue:

server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = blog
salvamos los cambios y reiniciamos mysql
root@server1:/# /etc/init.d/mysql restart

Hasta aquí hemos identificado a este servidor con id 1, indicado dónde se encuentra el log del mismo y definido la Base de Datos que nos interesa Replicar hacia el Box 2.

A continuación debemos asignar al usuario mysql (daniel)  permisos de Replicación en el Box 2. Volvemos a la consola:

root@server1:/# mysql -u root -p
clave de root mysql
mysql> GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.32' IDENTIFIED BY 'demichele';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.32';
mysql> FLUSH PRIVILEGES;
mysql> USE blog;
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

Obtendremos una tabla como la siguiente. Es recomendable anotar los valores de File y Position dado que los utilizaremos al final del tutorial para sincronizar los 2 Boxes a partir de la posición de los Logs.

Salimos del prompt de mysql quitando el lock a las tablas

mysql> UNLOCK TABLES;
mysql> QUIT;
root@server1:/#

Pasamos al Box 2 (192.168.1.32)

Continuaremos con los pasos del primer tutorial debido a que estamos intentando realizar Replicación Master-Slave como primer paso. Encontraremos, sin embargo, algo nuevo en la configuración de my.cnf del Box 2 que luego repetiremos en el Box 1: el uso de auto_increment_increment y auto_increment_offset, de vital importancia para el correcto funcionamiento de la Replicación Master-Master.

Vamos a la consola del Box 2 a editar la sección Logging and Replication dentro del header [mysqld]:

root@server2:/# pico /etc/mysql/my.cnf
#bind-address = 127.0.0.1
server-id = 2
master-host = 192.168.1.31
master-user= daniel
master-password= demichele
master-connect-retry= 60
auto_increment_increment = 2
auto_increment_offset = 2
binlog_do_db = blog
binlog_ignore_db = base_que_no_quiero_afectar

Guardamos los cambios y reiniciamos Mysql:
root@server2:/# /etc/init.d/mysql restart

Aquí nos encontramos con una primera novedad respecto al tutorial de Replicación Master-Slave. Esta consiste en la necesidad de resolver el escenario para campos autoincrement. Supongamos que tenemos 2 Boxes que pueden escribir vía INSERT y manejan un alto tráfico al punto en que se solicitan 2 INSERTS al mismo tiempo en una tabla con autoincrement. El box que primero reciba el INSERT ocupará el próximo índice disponible y deberá comunicarle al otro/s que la posición está tomada y el incremento debe continuar a partir del valor asignado.  Esta "comunicación" no será inmediata dado que siempre existe Lag entre los boxes. Con esto nos hacemos una idea del problema al que nos enfrentamos:

• el box 1 recibe la orden de insert al mismo tiempo que el box 2
• el próximo índice es -digamos- 1000
• el box 1 escribe la Base de datos usando el índice y comunica al box 2 que continue a partir del 1001
•  pero cuando la sincronización llega al Box 2, éste  ya ha escrito su base de datos utilizando el índice 1000
• al llegar la sincronización nos encontramos con un DUPLICATE KEY ERROR

Los paramtros auto_increment_increment y auto_increment_offset configurados debidamente en cada Box nos salvarán de este problema mediante un mecanismo extremadamente intuitivo: el primero seteado en 2 con offset de 2 tramitará los INSERTS en tablas con AI tomando el próximo índice disponible (ejemplo 14) y escribiendo 16 mientras que asignaremos al otro box un offset de 1 de modo que autoincremente naturalmente. En sintesis, el Lag entre boxes deja de importar debido a que cada Base de Datos posee un criterio para tomar índices que evitará la colisión. Más información sobre estos parametros puede ser encontrar en el sitio de Mysql.

Comenzando a trabajar la Replicacion bidireccional

Hasta aquí hemos configurado my.cnf en el Box 1, creado una cuenta de usuario mysql (daniel) con privilegio de Replicar Slave desde el Box 1 en el Box 2 y, por último, configuramos my.cnf del Box 2 para indicarle quien era su Master y proporcionar la información necesaria.

Lo que haremos ahora es darle a la cuenta mysql daniel privilegio para hacer Replication Slave pero desde el Box 2 hacia el Box 1 y, finalmente, editaremos my.cnf del Box 1 para decirle que es Slave del Box 2. En pocas palabras: repetiremos lo hecho hasta aquí pero en sentido inverso.

En la consola del Box 2 (192.168.1.32)

root@server2:/# mysql -u root -p
clave de root mysql
mysql> GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.31' IDENTIFIED BY 'demichele';
mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.31';
mysql> FLUSH PRIVILEGES;
mysql> USE blog;
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

Obtendremos un cuadro simil el anterior. Anotemos los valores de File y Position para el Box 2 (los que anotamos antes pertenecían al Box 1). Tenemos 2 cuentas mysql con el user daniel cruzadas que le permiten Replicar a los slave definidos. Ha llegado el momento de convertir a nuestro Master (192.168.1.31) en un Slave de 192.168.1.32.

Transformando el Master 1 en Slave

Volveremos a editar my.cnf de Server 1 para darle las mismas instrucciones que le hemos dado en Server 2:

root@server1:/# pico /etc/mysql/my.cnf
#bind-address = 127.0.0.1
server-id = 1
master-host = 192.168.1.32
master-user= daniel
master-password= demichele
master-connect-retry= 60
auto_increment_increment = 1
auto_increment_offset = 2
binlog_do_db = blog
binlog_ignore_db = base_que_no_quiero_afectar

Guardamos los cambios y reiniciamos mysql
root@server1:/# /etc/init.d/mysql restart

Con esto, hemos basicamente creado una arquitectura circular (la topología de la replicación Master-Master es, de hecho, circular). Le decimos al Box 1 que tiene server id 1 y debe trabajar con determinada base de datos. Creamos una cuenta mysql desde el Box 1 en que le damos a un usuario permisos para Replicar en un Slave del Box 2. Le decimos al Box 2 (editando my.cnf) donde está su Master (192.168.1.31). Luego repetimos toda la operación en sentido inverso cuidando que los valores de auto_increment_increment y offset estén debidamente seteados. El resultado: los boxes interactúan como Master y Slave entre sí.

Sincronizando los Boxes

Por último debemos sincronizar los boxes de modo que cada Servidor sepa a partir de qué log mysql trabajar y desde qué posición comenzar (esta es la información que obtuvimos en las tablas al arrojar la sentencia SQL SHOW MASTER STATUS).

En el box 1 (192.168.1.31) ingresamos a mysql como root:

root@server1:/# mysql -u root -p
Ingresamos clave de root mysql
mysql>  SLAVE STOP;
mysql>  CHANGE MASTER TO MASTER_HOST='192.168.1.32', MASTER_USER='daniel', MASTER_PASSWORD='demichele', MASTER_LOG_FILE='VALOR_OBTENIDO_EN_BOX2', MASTER_LOG_POS=VALOR_OBTENIDO_EN_BOX2;
mysql>  SLAVE START;
mysql>  QUIT;

En el Box 2 (192.168.1.32):

root@server2:/# mysql -u root -p
Ingresamos clave de root mysql
mysql>  SLAVE STOP;
mysql>  CHANGE MASTER TO MASTER_HOST='192.168.1.31', MASTER_USER='daniel', MASTER_PASSWORD='demichele', MASTER_LOG_FILE='VALOR_OBTENIDO_EN_BOX1', MASTER_LOG_POS=VALOR_OBTENIDO_EN_BOX1;
mysql>  SLAVE START;
mysql>  QUIT;

Por último reiniciamos mysql en ambos boxes vía /etc/init.d/mysql restart y podemos probar en cada box si la replicación está funcionando ingresando como root mysql con:

root@server1:/# mysql -u root -p
Ingresamos clave de root mysql
mysql>  SLAVE START;
mysql>  SHOW SLAVE START\G;

De la información del SLAVE nos interesa que los valores Slave_IO_Running y Slave_SQL_Running estén en YES en ambos casos. Si todo está ok podemos probar la Replicación ingresando al phpmyadmin de uno de los Servers para agregar un valor y verificar que éste se haya replicado en la BD del otro Server.

Lo que los tutoriales nunca te explican

En mi camino para lograr una buena Replicación Master-Master he leído y probado muchas cosas. El inglés no es -por fortuna- un problema para mi ya que conozco el idioma bastante bien. Este tutorial, al igual  que otros que he escrito y seguiré escribiendo es largo. Debo confesar que nada me gusta más cuando ando buscando cómo hacer algo que un tutorial en que se limitan a darme los comandos a utilizar para obtener lo que busco. Sin embargo, algunas cuestiones que revisten una complejidad media/alta como la Replicación merecen una explicación detallada de qué se hace y por qué se hace.

A continuación voy a listar algunas posibles causas por las cuales la replicación suele no funcionar y que no he leído en ningún lado.

1) La cuenta de usuario mysql (daniel) a la que le asignamos permisos para Replicar no es el usuario utilizado para conectar a mysql ni tiene permisos en local.

Esto es tan simple como suena: si estamos usando un user y pass mysql que ya existian y poseían permisos para trabajar con el Blog o Sitio web, entonces usaremos esa misma información  cuando hagamos GRANT REPLICATION SLAVE. Lo cierto es que muchas veces cuando intentamos poner a andar replicación le damos GRANT a un usuario que no existe, creandoló en el acto y luego nos encontramos con que el sitio anda bien pero no hay replicación (ni la habrá dado que el usuario al que se le asignó el privilegio de replicar no es el que se está utilizando para interactuar con la BD).

Otra cosa común es que al  correr la sentencia mysql GRANT REPLICATION SLAVE ON *.* TO 'daniel'@'192.168.1.32' IDENTIFIED BY 'demichele', como hemos hecho en este ejemplo estamos otorgando privilegios a un usuario cuyo ámbito es el otro Box y no el local. Una buena forma de saber si estamos haciendo las cosas bien es intentar loguearse a mysql y phpmyadmin del Box 1 con el usuario en cuestión. Si el usuario y clave no existían, luego de haberlo creado habremos agregado el User Daniel con Host 192.168.1.32 estando en el Box 1 (192.168.1.31).

Para resolver este inconveniente comenzamos por verificarlo. Nos logueamos a mysql como root y corremos SELECT User,Host FROM mysql.user; Mysql responderá con una tabla en que se listarán los Usuarios y Hosts en que tienen incumbencia. Si la combinación  de User: Daniel Host: localhost no se encuentra, entonces debemos crearla para poder operar en cada box con este nuevo usuario (porque el usuario debe tener los privilegios necesarios para conectarse a la aplicación en localhost y, además, los agregados para Replicar Slave en Box con que se conecta).

Agregar el usuario a localhost es tan simple como:

root@server1:/# mysql -u root -p
clave de root mysql
mysql> GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> QUIT;

Realizada esta operación el usuario tiene ALL PRIVILEGES en localhost + REPLICATION SLAVE y ALL PRIVILEGES en el server remoto. Esta operación debe ser realizada en ambos boxes.

 2) No  hay comunicación  entre los servidores porque el puerto 3306 está cerrado en el Firewall.

Comentamos la línea bind-address en los ficheros my.cnf de cada servidor para permitir a mysql  trabajar con otras máquinas en la red (o fuera de ella). Sin embargo, esto puede no ser suficiente y a veces necesitaremos abrir el puerto con iptables. Diagnosticar la comunicación entre boxes es muy sencillo:  tras haberle dado GRANT ALL PRIVILEGES ON *.* TO 'daniel'@'192.168.1.32'; desde el Box 1, lo siguiente debería ser posible:

root@server1:/#  mysql -u daniel -h 192.168.1.32 -p
Ingresamos la clave demichele

Si obtenemos el prompt mysql tenemos conectividad. Si en cambio obtenemos un mensaje del tipo ERROR 1130 (HY000): Host 'server1' is not allowed to connect to this MySQL server tendremos que abrir el puerto en el Firewall del siguiente modo:

root@server1:/# /sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 3306 -j ACCEPT
root@server1:/# iptables-save

3) GRANT ¿a quien y sobre que?

Muchos tutoriales sobre Replicación se despachan a la hora de otorgar privilegios para Replicar Slave con sentencias del tipo:

GRANT REPLICATION SLAVE ON *.* TO 'user'@'%' IDENTIFIED BY 'clave';

Esto se leería -con un poco de humor- más o menos así: "Dale permisos para replicar slave al user en todas las bases de datos en todos los servidores". En este tutorial hemos utilizado la expresión *.* porque sólo poseemos una base de Datos con que trabajaremos. Contamos además con las bases de datos que mysql y phpmyadmin ha instalado pero optamos por excluirlas en  los ficheros my.cnf haciendo uso de binlog_ignore_db que puede utilizarse tantas veces como sea preciso para no incluir en la Replica algunas base de datos.

Si estuvieramos en un entorno en que trabajamos con VirtualHosts y contamos con una cantidad considerable de Bases de Datos, asignarle a un usuario permisos para Replicar Slave en todas ellas sería una mala idea. Es así que una sentencia de esta clase se adaptaría mejor:

GRANT REPLICATION SLAVE ON mibasededatos TO 'user'@'%' IDENTIFIED BY 'clave';

Por último el comodín % es también innecesario desde que uno puede o bien querer apuntar a un Host remoro como lo hemos hecho, o bien a localhost. Nuevamente una sentencia más discreta:

GRANT ALL ON mibasededatos TO 'user'@'localhost' IDENTIFIED BY 'clave';

O bien definir la IP del server destino, como lo hemos hecho aquí.

Eso es todo por ahora, la Replicación  es un tema que da para mucho y éste -con seguridad- no será el último capitulo.

Se trata -en esta oportunidad- de algo muy sencillo: hemos tocado tanto Mysql que simplemente desearíamos comenzar de cero por lo que necesitamos un clean uninstall de mysql para, luego, reinstalar y volver a comenzar.

Esto es muy sencillo en Debian Squeeze y supongo que debe serlo en otras distribuciones. No necesitamos explicar que todas las bases de datos del servidor van a perderse. Vamos a desinstalar por completo mysql de suerte que si luego intentamos un  mysql -u root -p bash no reconocerá el programa.

Vamos a la consola, pero antes una aclaración fundamental. Al desinstalar mysql del modo en que lo haremos, estaremos desinstalando todos los paquetes cuyo nombre comience con mysql (el  asterisco es REGEX para todo lo que se llame mysql+cualquier cosa). Es muy importante comprender que muchas aplicaciones no vinculadas a un Lampp hacen uso de algunos paquetes mysql.

Un ejemplo: en el Box que uso para trabajar (el único con interface gráfica) corri el comando tal cual se describe abajo y al reiniciar me encontré con que mi KDE había desaparecido y entraba en Gnome sin chances de elegir una sesión KDE en el Login. Por fortuna recuperé mi KDE tal cual lo tenía corriendo como root apt-get install kde-plasma-desktop.

Como conclusión la desinstalación de mysql a través de este método es recomendable sólo en el caso de que uno sepa muy bien cuales son las dependencias que se perderán. En lo personal realicé el procedimiento en otros boxes sin GUI sin inconvenientes, pero debo aclarar que estos boxes eran fresh install de Debian sin GUI con Apache2, PHP5 y no mucho más.

Para boxes con una cantidad importante de componentes instalados no recomiendo este método: supongo que lo mejor sería ir por los paquetes mysql-server y mysql-client en lugar de afectar la totalidad de paquetes en cuyo nombre aparezca la palabra mysql.

carp@server1:~$ su root
ingresamos la clave de root
root@server1:/# apt-get --purge remove mysql*

La desinstalación comenzará y al finalizar habremos borrado todo lo relacionado a mysql de nuestro servidor, de suerte que si intentamos un mysql -u root -p nos encontraremos con el fastidioso bash: mysql: no se encontró la orden, esperado en este caso.

Luego para reinstalar podemos usar el CD o DVD de la distro o bien agregar a sources.list la fuente del paquete mysql-server.  En mi caso agregué deb http://ftp.us.debian.org/debian squeeze main  y luego corri

root@server1:/# apt-get install mysql*

Si esta instrucción arrojara el clásico "E: No se ha podido localizar el paquete mysql" intenten con:

root@server1:/# apt-get install mysql-server mysql-client

Y a recomenzar con Mysql!

Saludos

Como es evidente, esto no me servía en nada: si un box debía ser reiniciado por cualquier razón, éste debía volver a ofrecer servicios lo más rápido posible. Es así que la necesidad de saltear el paso del Login se hizo patente: necesitaba que mis boxes reiniciaran y se loguearan automáticamente.

Autologin on Boot con Mingetty

La solución, afortunadamente, es bien sencilla gracias a Mingetty. Antes de abrir la consola me gustaría realizar una aclaración. Al intentar instalar mingetty vía apt los paquetes no fueron encontrados en mi Debian DVD ni en las sources que Debian instala en /etc/apt/souces.list por defecto. Si bien esto es normal, le ahorrará algo de tiempo a alguien saber que la fuente que agregué en sources.list para obtener el paquete fue:

deb http://ftp.br.debian.org/debian squeeze main

Pueden encontrar mirrors para este paquete según la arquitectura del ordenardor en que vayan a instalarlo en http://packages.debian.org/squeeze/mingetty

Dicho esto, vamos a la consola e instalemos mingetty:

carp@server3:/$ su root
ingresamos contraseña de root
root@server3:/# apt-get install mingetty

Instalado mingetty, debemos modificar el fichero /etc/inittab del siguiente modo:

root@server3:/# pico /etc/inittab
Bajamos en el fichero hasta llegar a esta sección
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Aquí podemos observar como getty está abriendo líneas de comando en cada una de las 6 terminales (a las que podemos cambiar con ALT + FN) En nuestro caso nos interesa autologin en la terminal 1, es decir la terminal con cuyo promt nos encontramos cuando Linux termina de bootear.

Para lograr esto, modificamos la primera línea de modo que quede:

1:2345:respawn:/sbin/mingetty --autologin carp --noclear tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

Salvamos el fichero y reiniciamos con:

root@server3:/# shutdown -r now

El box hará el reboot, cargará como de costumbre pero el prompt de login jamás aparecerá. En su lugar, nos encontraremos con que ya estamos logueados con el usuario especificado.

Observaciones finales

Realizar un autologin en los Boxes es, como se ha visto, una tarea bastante sencilla. Jamás me cansaré de decir que setear el autologin a root es -además de una mala idea- innecesario dado que el Administrador siempre podrá hacer su root vía SSH. En este ejemplo nos hemos limitado a autologin en la terminal 1, pero de ser necesario podríamos extenderlo a otras terminales. Si bien en mi caso los boxes son headless y no tienen ninguna interface gráfica instalada, es recomendable saltear la terminal 7 que suele reservarse para X11.

Saludos