Vamos a suponer que tenemos un servidor con una partición de SWAP que queremos eliminar, no la necesitamos.

Primero, vamos a desmontar la SWAP.

Para eliminar la partición 5 que corresponde a la SWAP, vamos a usar la herramienta parted.

Empezamos:

Eso es todo, podemos verificar como el sistema ya no detecta la partición 5 de la antigua SWAP.

 

La configuración básica de HAProxy permite añadir el listado de usuarios que tendrá acceso al dashboard para ver el estado del servicio, los nodos del backend, estadísticas, etc.

Un ejemplo de configuración básico de usuarios para HAProxy:  vi /etc/haproxy/haproxy.cfg

Siguiendo la documentación propia de HAProxy para la versión 1.5.X, sección 3.4 «Userlists»:
http://www.haproxy.org/download/1.5/doc/configuration.txt

Ahora vamos a cifrar el anterior password con SHA-512.

Ahora cambiamos la configuración del haproxy.cfg fácilmente con:

Por último, no olvidar hacer un reload del servicio HAProxy para aplicar los cambios.

Anteriormente vimos como crear alias de comandos bash, para agilizar nuestro trabajo, ya sea acortando comandos largos, comandos muy habituales u otras necesidades que puedan aparecernos.

Vamos a ver un ejemplo utilizando un alias del siguiente comando:

Es habitual ver la salida de algunos comandos cada ‘x‘ segundos, para ver si hay cambios, si nuestro automatización crea nuevos archivos, si aparecen nuevas conexiones, etc. Todo esto sin necesidad de ejecutar el comando cada momento, podemos usar el comando watch, que se encarga de ir ejecutando el comando cada ‘x‘ segundos, por defecto hará intervalos de 2 segundos.

Pero el comando watch no funciona al ejecutar comandos que son alias de bash:

Así que para poderlo utilizar hay un workarround, hay que crear otro alias de watch con un espacio al final:

 

Hace unos días vimos como desplegar un clúster de Kubernetes con el sistema operativo CoreOS en Amazon Web Services (AWS).

El despliegue lo hicimos con la herramienta kube-aws que nos facilita la tarea. Igualmente eso no nos impide a conectarnos por SSH a las instancias desplegadas y poder ver configuraciones o ajustar parámetros, etc.

En el archivo cluster.yaml configuramos el parámetro:

Esta clave será una de las que tenemos creadas en EC2 y será la que nos va a permitir conectarnos por SSH, bastará con hacerlo con la clave privada, usuario ‘core‘ y la IP pública:

 

Podemos trabajar con el servicio ProFTPD con el modulo mod_sql, para tener usuarios virtuales y obtener las credenciales de una base de datos. Este sistema será válido tanto para FTP como SFTP.

La estructura de las tablas SQL que nos proponen inicialmente no permite tener usuarios dados de alta, pero inactivos a nivel de servicio, sin permitir su autenticación.

Así que haremos unos pequeños cambios, primero modificando la tabla SQL:

Para acabar, debemos tener un archivo sql.conf similar a este:

Y añadiremos la línea SQLUserWhereClause, quedando así:

Ahora ya podemos desactivar cuentas FTP, cuando haga falta únicamente habrá que cambiar el campo LoginAllowed, por ejemplo así:

 

Generalmente los contenedores Docker se usan para arrancar servicios como Nginx, Apache, PHP-FPM, Redis, etc. Estos servicios se basan en entornos Alpine Linux, Debian u otros.

Cuando el contenedor arrancar con un servicio, su PID será el 1, pero si queremos realizar pruebas con un Debian pelado sin servicios.
¿Como vamos a arrancarlo sin que se nos pare el contenedor Docker?

Muy fácil, vamos a arrancar un contenedor Docker de la imagen base de Debian, lanzando un terminal bash como proceso principal.

Ahora podemos ver como el PID número 1 corresponde a un terminal bash, pero si entramos dentro del contenedor vamos a abrir un bash independiente, con lo cual si salimos y entramos no se detendrá el contenedor al no finalizar el PID 1. Nuestro bash dentro del contenedor para trabajar y realizar pruebas será el que tiene PID 7.

 

El binario kubectl nos permite trabajar con un clúster de Kubernetes, ver PODs, RCs, SVC, crearlos, eliminarlos, ver logs u otras tareas.

Por otro lado solo nos permite trabajar con un clúster a la vez, es decir si queremos trabajar con otro clúster debemos cambiar de contexto.

Podemos ver las configuraciones con el propio binario o también en nuestro home:  ~/.kube/config

En este instante, el clúster de trabajo actual lo podemos ver reflejado aquí:

Y ahora cambiamos el clúster de trabajo actual para kubectl con el siguiente comando:

 

Este tema me ha llevado bastante quebraderos de cabeza y hoy voy a explicar qué pasa y como recibir en la cabecera HTTP el X-Forwarded-For.

El objetivo es obtener la IP real del cliente origen cuando tenemos un LoadBalancer de Google Cloud en su Kubernetes con Container Engine. Ya que sino es así todos los logs de Apache/Nginx del backend van a registrar la IP interna del LoadBalancer y no tendremos la IP real del cliente, haciendo imposible por ejemplo la generación de estadísticas reales de visitas.

Cuando levantamos un Service (SVC) de Kubernetes lo hacemos de la siguiente manera:

El «type: LoadBalancer» va aprovisionar un LoadBalancer de la plataforma de GCP directamente a nuestro ReplicationController asignado con el «selector».

Este LoadBalancer va a ser del tipo TCP y ese será el motivo real por el cual no vayamos a recibir la cabecera X-Forwarded-For.

Esto no sucede igual en AWS, que quizás por defecto levantan un LoadBalancer HTTP así que en GCP hay que hacerlo de otro modo.

Así que el objetivo será levantar un LoadBalancer HTTP de la plataforma de GCP, eso lo haremos con Ingress de Kubernetes.

Vamos a modificar nuestro SVC actual cambiando el «type: LoadBalancer» por «type: NodePort«, aplicamos las nuevas configuraciones.

Ahora ya tenemos un SVC nginx-back que va a ser únicamente accesible desde dentro del clúster de Kubernetes. No tendremos visibilidad desde el exterior.

Para ello vamos a crear un Ingress que va aprovisionar un LoadBalancer HTTP en GCP. Vamos a crear un YAML nuevo:  vi nginx-back-ing.yaml

Ahora debemos tener un poco de paciencia para que se aprovisione correctamente el LoadBalancer HTTP e ir observando los cambios.

Hasta que la línea «backends» de la sección «Annotations» no aparezca como HEALTHY no será 100% funcional nuestro LoadBalancer HTTP en GCP con Ingress de Kubernetes.

 

Suponemos el caso que tenemos un clúster MariaDB Galera con 3 nodos en la misma infraestructura. Puede darse el caso que haya un problema de electricidad y se detengan todos los nodos de golpe.

Cuando vuelvan a arrancar los nodos, cada nodo intentará sincronizarse con los demás nodos que tampoco estarán levantados y no arrancará nuestro clúster.

En este instante es cuando tenemos que decidir cual es el nodo que ha realizado el último commit (INSERT / UPDATE) y tiene los datos mas actualizados.

Para ello basta con ejecutar el mismo binario en todos los nodos, este se encargará de buscar el número del último commit. De los 3 nodos, el que tenga el número mas alto debe ser el que haga el bootstrap para arrancar el clúster de MariaDB Galera.

El nodo1 es el que tiene el commit mas alto, 26289 y este es el candidato a levantar el clúster en primera instancia.

Bastará con realizar el bootstrap del nodo1 siguiendo estas indicaciones:

Por último, podemos arrancar los otros dos nodos de la forma habitual con systemd.

 

En versiones anteriores de Debian se utilizaba init como gestor de arranque de los procesos, pero a partir de Debian 8 Jessie se ha cambiado por el gestor systemd.

Eso ha hecho que cambiara el método para realizar el bootstrap (inicializar) un clúster de base de datos MariaDB Galera. Es decir, arrancar el primer nodo de una agrupación.

En versiones anteriores de Debian, bastaba con ejecutar en el primer nodo:

Pero con Debian 8 Jessie y la llegada de systemd eso ha dejado de funcionar.

La gente de MariaDB ha añadido un excelente binario que facilita la tarea y fácil de recordar: galera_new_cluster