LVM-RAID1 - Alta disponibilidad de discos lógicos.

Muchas veces (siempre?) se necesita tener la seguridad de que tanto el sistema operativo como la información van a estar disponibles aún cuando exista un fallo en el disco duro.

Ya sea para una estación de trabajo o personal o en servidores, el contar con redundancia a nivel de discos facilita muchísimo la gestión de recursos ante una posible recuperación de desastres, en este caso el fallo total de un disco duro.

Por ejemplo, en una oficina pequeña no se suele disponer de personal para soporte informático permanente el cual descargue de la responsabilidad de mantener los respaldos al día a los usuarios de la red, contratar o mantener una solución de respaldo para todos los equipos suele ser demasiado costoso y en el otro lado, hacerlo únicamente para el equipo crítico para la empresa hace que  la solución sea sub-utilizada. En este caso, pueda que sea mucho más factible simplemente añadir redundancia a los discos y de esta forma en caso de que uno falle no existe afectación alguna y da tiempo para colocar el reemplazo del disco dañado.

Voy a contar otro escenario de la vida real:
Se tienen unos servidores que reciben sus discos desde desde un storage, tiempo atrás una de las controladoras del storage falló y fue necesario migrar y reconstruir el arreglo de cada uno de los servidores (si alguien ha reconstruido un RAID5 en 4 discos sas de 8TB sabe lo que puede llevar). Debido a esto se tuvo una caída del servicio de horas, algo inaceptable.

Lo solución que propuse fue que se cuente con redundancia en los discos generando un LVM-RAID1. Porqué un LVM-RAID y no un raid con MDADM? Principalmente porque los puntos de montaje de los sistemas Linux ya estaban sobre LVM y no se quería añadir otra capa de administración.

Y porqué RAID1? La parte interesante es que en lvm-raid1 se puede definir la cantidad de espejos para el arreglo, por lo que el disco principal tiene n espejos y tendrían que fallar TODOS los discos para que se pierda el acceso a la data. Esto sumado a que cada disco viene de un storage distinto da aún mayor seguridad ante fallos sobre todo de hardware.

Así que manos a la consola :D

- Primero añadimos los discos físicos como pvs:

pvcreate /dev/sde /dev/sdf /dev/sdX

- Creamos el grupo de volúmenes (VolumeGroup) indicando los discos que deseamos formen parte del mismo:

vgcreate miVG /dev/sde /dev/sdf /dev/sdX

- Creamos un volumen lógico que ocupará toda la extensión del disco, esto es importante ya que nos asegura que la data se almacenará en un solo disco. el número para el argumento -m indica la cantidad de espejos que deseamos para el arreglo, el primer disco será el principal el resto las réplicas:

lvcreate --type raid1 -m 3 -l 100%FREE -n miLV miVG /dev/sde /dev/sdf /dev/sdX

Esto creará el lv miLV en el grupo miVG y empezará la sincronización entre todos los discos, esto puede llevar varias horas dependiendo de la capacidad de los discos, su velocidad, etc. Para ver el porcentaje de sincronización podemos ejecutar el comando con watch con actualización por defecto cada 2 segundos:

watch lvs -a -o +devices miVG/miLV

Una vez que se complete el proceso anterior podemos dar el sistema de archivos que deseemos:

mkfs.ext4 -L data /dev/miVG/miLV

La ventaja de LVM-RAID es que podemos añadir o remover espejos al arreglo y deshacer el arreglo por completo sin tener que migrar la información. Eso y muchas cosas más, recomiendo leer la documentación de RedHat sobre Administración LVM para tener una idea de sus alcances.

Si han usado raid por lvm o planean hacerlo póngalo en los comentarios!

Saludos.

Migración de correos en masa con Imapsync a WHM/cpanel

La anterior semana se me presentó la necesidad de migrar una gran cantidad de correos de dos servidores distintos a otro. Los servidores de origen eran muy diferentes si se puede decir; el uno era un servidor "a mano" con webmin, postfix, dovecot, etc. El otro, un Zimbra CE.

Más allá de la diferencia de los servidores era la cantidad de cuentas de correo a migrar y el peso total de estas. Fueron alrededor de 150 cuentas y requerían de 150GB de espacio en el nuevo servidor. 150 para servidores de correo grandes no es nada, pero crear/migrar a mano una a una no es algo que ni deba ponerse como posibilidad.

Realmente nunca había tenido la necesidad de migrar de esta forma, siempre fue de Zimbra --> Zimbra, cpanel --> cpanel, etc. Pero esta vez la migración era desde los servidores antes mencionados hacia un WHM/cpanel.

Las cuentas de hosting ya se encontraban creadas en el WHM, la idea era automatizar la creación de las cuentas de correo en cada una de ellas y posteriormente migrar el correo.

Creación de correos en WHM:

Esto lo hice en línea de comandos en el servidor mediante la API de WHM whmapi1. El comando en cuestión es addpop y toma como parámetros usuario, contraseña, cuota de buzón. De esta forma, cree un archivo (llamado USERLIST) por cada dominio con el listado de cuentas de correo pertenecientes a el en el formato:

username;password:quota

 Una vez se tiene el archivo, ejecuto el siguiente one-liner en el servidor WHM usando la API de cpanel:

while IFS=";" read u p q; do cpapi2 --user=acc-username Email addpop domain=acc-domain email=$u password=$p quota=$q; done < USERLIST

Donde:

• IFS es la variable que indica el separador del fichero USERLIST, en este caso ";", si por ejemplo obtiene un cvs se puede indicar que el separador es ","
• acc-username y acc-domain son los datos de usuario y dominio para la cuenta de cpanel en el WHM.
• $u, $p, $q son usuario, contraseña y quota para cada cuenta respectivamente.

Con esto tenemos creadas las cuentas de correo.

MIgración de correos con Imapsync:

Debemos tener un fichero (llamado en el ejemplo como USERLIST)  con el siguiente formato:

(usuario1;contraseña1;usuario2;contraseña2)

Donde:

• usuario1, contraseña1: credenciales de la cuenta de origen, usuario es sólo el nombre sin el @dominio.com
• usuario2, contraseña2: : credenciales de la cuenta de destino, usuario es sólo el nombre sin el @dominio.com

En cualquier equipo instalamos imapsync, la instalación depende de la distribución que elijamos y existe mucha documentación al respecto por lo que no lo trataré aquí. 

Con imapsync instalado en el equipo que usaremos para ejecutar la migración, podemos usar el script de bash indicado a continuación:

imapsyncpath=/ubicacion/del/ejecutable/imapsync
origen=10.0.1.1
destino=10.0.2.1
options="--tls1 --usecache --delete2 --nofoldersizes --no-modules_version --addheader --subscribeall"
while IFS=";" read u1 p1 u2 p2; do
    { echo "$u1" |egrep "^#" ; } > /dev/null && continue # skip comment lines in USERLIST
    echo "============== Migrating mail from user $u1 to $u2 =============="
    .$imapsyncpath/imapsync --host1 $origen --host2 $destino --user1 $u1 --password1 $p1 --user2 $u2 --password2 $p2 $options --dry
    echo
    echo "============== Ended migration for user $u1 in $u2 =============="
done < USERLIST
echo "Migration Complete."
exit 0

OJO, recomiendo leer la documentación ya que tiene muchas, MUCHAS opciones de sincronización. Las opciones que uso son un tanto generales y pensadas para cubrir las necesidades de mi caso.

Con esto tendríamos sincronizada la información de las cuentas de correo y podemos ejecutarla cuantas veces queramos ya que solo actualizará en el destino la información nueva. En mi caso tuve que esperar a que se refresquen las respuestas DNS de los registros MX de los dominios para poder dar de baja el servidor de origen.

Con el one-liner en el cpanel y el script de para imapsync migré las cuentas de forma semi-automatizada sin tener que estar pendiente en todo momento del proceso. Como dato extra al script de imapsync lo puse como un cronjob diario para mantener al día las cuentas en el destino hasta que me notifiquen del refresco de la zona DNS.

Gracias!.

Comando del día: Dump Restore de máquinas virtuales en Proxmox

Para realizar un dump en vivo de una máquina virtual, tanto openvz como kvm podemos ejecutar el siguiente comando:

vzdump --dumpdir /ubicacion/del/dump VZID

Donde VZID repreenta el número de la VM, por ejemplo 101, 105, etc.
Para restaurar un dump, ejecutamos uno de los siguientes comandos según se trate de openvz o kvm, tomando en cuenta que el VZID no debe existir ya en nuestro nodo proxmox.

vzrestore /ubicacion/del/dump.tgz NEWVZID

qrestore  /ubicacion/del/dump.tgz NEWVZID

Podemos consultar la ayuda de vzdump (vzump --help) para personalizar más nuestros dumps. Si bien proxmox puede realizar réplicas de respaldo de forma automática, se requiere de un segundo nodo contectado. También se puede respaldar de forma manual pero se debe contar con un segundo almacenamiento ya que no respalda al mismo disco donde corre proxmox.

Pero puede que en dicho disco se cuente con una buena cantidad de espacio libre y queramos respaldar en el; o también como es mi caso, disponer de un export nfs montado, y mediante trabajos cron y scripts realizar respaldos periódicos de las máquinas teniendo el control que nosotros queramos.

Todo esto prácticamente con un sencillo comando y sin parar las VMs.

Saludos!

Comando del día: Buscar si un proceso se ha ejecutado más de dos veces y como matarlos.

Hace unos días me pasó que un servicio al parecer se había ejecutado más de una vez (no daré detalles del porqué).

Pero sea como sea la questión era saber cuántos procesos se estaban ejecutando y también una forma de matarlos independiente de la cantidad que estos sean, de esta forma llegué a las dos siguientes líneas de bash que se las puede modificar un poco para que formen parte de un script o unirlas etc:

Mirar si hay más de un proceso ejecutándose cada 2 segundos:

while true; do echo $(ps aux |egrep proceso |awk '{print $2}' |wc -l; sleep 2; done

Matar todos los procesos:

for p in `ps aux |egrep proceso |awk '{print $2}'`; do kill -9; done

Espero les sea de utilidad!!!

Saludos.

Comando del día: Conexión ssh sin contraseña

Para tener una conexión ssh sin necesidad de contraseñas para acceder a nuestros equipos de forma más rápida y cómoda podemos realizar lo siguiente:

$ ssh-keygen -t rsa 

$ ssh-copy-id -i ~/.ssh/id_rsa.pub hostremoto

$ ssh hostremoto

Lo que hemos echo es primero generar nuestra llave ssh, luego copiamos la llave púbilca en el host remoto, nos preguntará por la contraseña y si todo sale bien, el tercer comando nos debería ingresar directamente en el host remoto.

Tomar en cuenta que el usuario que realiza la conexión es el mismo con el que se desea ingresar al host, es decir que si somos user, el comando ssh-copy-id en parte ejecuta algo como:

ssh user@hostremoto

Por lo generalmente user debe existir en los dos hosts.


Saludos!

Configurando Vagrant sobre Windows

Introducción

Vagrant funciona sobre varios sistemas operativos como MacOS X, Windows, Debian, Ubuntu, CentOS, RedHat, Fedora y más. En esta página se seguirá los pasos para tener una máquina virtual de Debian mediante Vagrant sobre Windows.

Entorno Windows

Para ejecutar Vagrant y la máquina virtual en un entorno Windows, vamos a seguir las siguientes secciones

• Instalación de Vagrant 
• Instalación de Oracle VirtualBox 
• Instalación del emulador de consola CMDER 
• Creación de la carpeta para las máquinas Vagrant 
• Creación de la caja Debian-docker 
• Creación de la máquina virtual
• Configuraciones de la máquina virtual
• Ejecución de la máquina virtual
• Conección ssh a la máquina virtual
• Suspendiendo y apagando la máquina virtual

Instalación de Vagrant

Primero descargamos el instalador de Vagrant de http://www.vagrantup.com/downloads.html y lo ejecutamos.

La instalación es simple, cuando pregunte sobre la ruta de instalación como vamos a usar la línea de comandos se recomienda usar una ruta corta, por ejemplo en la guía usaremos “D:\Vagrant”.

Instalación de Oracle VirtualBox

Ahora debemos instalar la versión más actual de VirtualBox del siguiente enlace https://www.virtualbox.org/wiki/Downloads

Con la instalación por defecto está bien.

Instalación del emulador de consola CMDER

Por defecto Windows no cuenta con un emulador de consola y un cliente ssh, hay varias aplicaciones para esto, nostros usaremos un emulador liviano llamado CMDER, tiene buenas funcionalidades incluyendo git y para los que están acostumbrados a la consola de Linux se sentirán como en casa.

Debemos descargar la versión completa de CMDER en el siguiente enlace http://bliker.github.io/cmder

Para ejecutarlo solo hay que descomprimir el archivo descargado en una carpeta y ejecutar Cmder.exe

Se recomienda configurar “Control de Acceso de Usuarios (CAU)” en la opción de "Nunca notificar". En Windows 7 en adelante debería encontrarse siguiendo el orden: Panel de control -> Systema y Seguridad -> Configuraciones de control de acceso de usuarios.

Los siguientes pasos se harán usando CMDER.

Creación de la carpeta para las máquinas Vagrant

Por facilidad, crearemos las carpetas dentro de D:\\Vagrant

Primero una carpeta llamada Proyectos y dentro una que contendrá nuestra máquina virtual de Debian-docker

C:\
λ cd D:\
D:\
λ cd Vagrant
D:\Vagrant
λ mkdir Proyectos
D:\Vagrant
λ mkdir Proyectos\Debian-docker
D:\Vagrant
λ cd Proyectos\Debian-docker
D:\Vagrant\Proyectos\Debian-docker
λ

Creación de la caja Debian-docker

No siempre es necesario empezar desde cero, descargaremos una caja lista que tiene Debian 8 y algunos ajustes listos para funcionar con Docker.io

D:\Vagrant\Proyectos\Debian-docker
λ vagrant box add williamyeh/debian-jessie64-docker --provider virtualbox
==> box: Loading metadata for box 'williamyeh/debian-jessie64-docker'
    box: URL: https://vagrantcloud.com/williamyeh/debian-jessie64-docker
==> box: Adding box 'williamyeh/debian-jessie64-docker' (v1.2.0) for provider: virtualbox
    box: Downloading: https://vagrantcloud.com/williamyeh/debian-jessie64-docker/version/5/provider/virtualbox.box    
    box: Progress: 100% (Rate: 482k/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'williamyeh/debian-jessie64-docker' (v1.2.0) for 'virtualbox'!

Por defecto nos crea una imagen llamada williamyeh/debian-jessie64-docker, la renombraremos a debian-docker mediante los siguientes comandos

D:\Vagrant\Proyectos\Debian-docker
λ vagrant box repackage williamyeh/debian-jessie64-docker virtualbox 1.2.0
D:\Vagrant\Proyectos\Debian-docker
λ vagrant box add debian-docker package.box --provider virtualbox
==> box: Adding box 'debian-docker' (v0) for provider: virtualbox
    box: Downloading: file://D:/Vagrant/Proyectos/Debian-docker/package.box
    box: Progress: 100% (Rate: 526M/s, Estimated time remaining: --:--:--)
==> box: Successfully added box 'debian-docker' (v0) for 'virtualbox'!

Podemos listar las cajas que tenemos

D:\Vagrant\Proyectos\Debian-docker
λ vagrant box list
debian-docker                     (virtualbox, 0)
williamyeh/debian-jessie64-docker (virtualbox, 1.2.0)

Creación de la máquina virtual

En la ubicación actual inicializaremos una máquina virtual basada en la caja debian-docker creada anteriormente

D:\Vagrant\Proyectos\Debian-docker
λ vagrant init debian-docker
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
D:\Vagrant\Proyectos\Debian-docker
λ ls
Vagrantfile

Inicializando la máquina virtual va a crear un archivo de configuración llamado Vagrantfile que "hereda" las configuraciones de la caja usada para su inicialización, en este caso debian-docker.
Este archivo contendrá cualquier configuración específica como memoria, red, carpetas compartidas, etc.

Configuraciones de la máquina virtual

Antes de ejecutar la máquina virtual, vamos a cambiar algunas configuraciones editando el archivo Vagrantfile con el editor de texto de nuestra preferencia.

D:\Vagrant\Proyectos\Debian-docker
λ NotePad Vagrantfile

Localizamos la parte de inicio de configuración “do |config|”. Desde la siguiente línea podemos configurar todo lo que deseemos.

Lo primero que haremos será crear una carpeta compartida en la máquina virtual llamada vagrant para que apunte a la misma ubicación donde se levanta dicha máquina.
Para esto añadimos la siguiente línea dejando saltos de línea arriba y abajo de la misma.

    config.vm.synced_folder"D:\\Vagrant\\Proyectos\\Debian-docker\\", "/media/vagrant"

Ejecución de la máquina virtual

Ahora es momento de iniciar nuestra máquina virtual.

D:\Vagrant\Proyectos\Debian-docker
λ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
    default: /vagrant => C:/Users/Taoshi/Vagrant_Projects/Jessie-Docker
    default: /media/vagrant => C:/Users/Taoshi/Vagrant_Projects/Jessie-Docker
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: to force provisioning. Provisioners marked to run always will still run.

Podemos verificar el estado de la máquina

D:\Vagrant\Proyectos\Debian-docker
λ vagrant status
Current machine states:
defaultrunning (virtualbox)
The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

Conección ssh a la máquina virtual

Vagrant permite conexión ssh nativa hacia las máquina virtuales en ejecución.

D:\Vagrant\Proyectos\Debian-docker
λ vagrant ssh
Linux debian-8-amd64 3.13-1-amd64 #1 SMP Debian 3.13.5-1 (2014-03-04) x86_64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux testing (jessie)
Release:        testing
Codename:       jessie
vagrant@debian-8-amd64:~$

Podemos trabajar como en toda consola bash, para salir lo hacemos con el comando exit

vagrant@debian-8-amd64:~$ exit
logout
Connection to 127.0.0.1 closed.
C:\Vagrant\Proyectos\Debian-docker
λ

Suspendiendo y apagando la máquina virtual

Cuando no deseemos usar la máquina virtual, podemos suspenderla o apagarla.

D:\Vagrant\Proyectos\Debian-docker
λ vagrant suspend
D:\Vagrant\Proyectos\Debian-docker
λ vagrant halt
En cualquiera de los dos casos la reactivamos mediante vagrant up
D:\Vagrant\Proyectos\Debian-docker
λ vagrant up

Eso es todo lo básico para tener nuestras máquinas virtuales mediante Vagrant bajo Windows.

OpenMediaVault - Almacenamiento compartido mediante Samba (I)

Una vez que hemos completado la instalación del servidor OpenMediaVault, seguramente necesitemos tener almacenamiento compartido en un entorno con sistemas Windows. Para ello existe SAMBA, que es la versión libre del protocolo SMB/CIFS. Pero no entremos en detalles y vamos directo a lo que nos interesa: almacenamiento de acceso público en nuestra red desde clientes Windows.

Como mencionaba en el post anterior sobre la instalación, es recomendable instalar el OMV teniendo conectado únicamente el disco donde va a quedar el sistema. Cuando ya hayamos reiniciado y comprobado que podemos ingresar por web a su IP con las credenciales por defecto admin / openmediavault apagamos el sistema y conectamos el o los discos a usar.

Una vez iniciado nuevamente el sistema, podremos ir a Almacenamiento - Discos Físicos  y comprobar que los discos han sido detectados.

El siguiente paso será crear una partición, para ellos iremos a Almacenamiento - Sistemas de Archivos en la parte superior le damos click a Crear y veremos un diálogo como el siguiente:

En este diálogo primero elegimos el disco en el cual vamos a crear la partición, luego le damos un nombre lo más descriptivo posible y por último elegimos el sistema de archivos deseado.El siguiente paso será Montar la partición creada, con lo que podremos ver su capacidad y uso.

Ahora que ya tenemos montada la partición estamos listos para crear una carpeta compartida, para ello nos dirigimos a Administración de permisos de acceso - Carpetas Compartidas y le damos a Añadir.

Empezamos dando un nombre a la carpeta, luego seleccionamos la partición que creamos anteriormente. En "Ruta" podemos escribir directamente la ruta, por ejemplo /compartido lo que creará esta carpeta en la raíz del disco, también tenemos el ícono a la derecha para crear carpetas y subcarpetas si deseamos árboles de directorios más complejos. Por úlitmo los permisos por defecto serán suficiente en la mayoría de los casos ya que un control más preciso se tiene directamente en cada usuario/grupo o por ACLs como lo haremos a continuación.

Dando click en ACL tendremos un cuadro con los permisos de todos los usuarios del sistema y otras opciones más como se puede ver en la captura siguiente:

Si queremos dar acceso completo a los usuarios conectados por Samba, eligimos Lectura/Escritura para el usuario sambashare y más abajo en Otros también elegimos Lectura/Escritura. Si bien esto no es muy seguro, por un lado estamos suponiendo un ambiente confiable en nuestra red local y por otro incialmente habilitamos el acceso completo pero luego ir gestionando usuarios y grupos con permisos específicos, eso vendrá en una publicación futura ;)

Ahora que hemos añadido una carpeta compartida, debemos habilitar el servicio que queramos haga uso de esta, en este caso el servicio Samba. Para ello nos dirigimos a Servicios - SMB/CIFS y habilitamos el servicio.

Podemos dejar el grupo de trabajo por defecto, pero para un control mayor podemos usar un nombre tomando en cuenta que todos los clientes windows en la red local deberán pertenecer a este grupo de trabajo para que tengan acceso al compartido. Se deberá habilitar la casilla de Navegable para que los usuarios puedan ingresar a las subcarpetas, si así se desea. Todo lo demás puede quedar por defecto.

Damos click en OK para que se guarden los cambios y nos pasamos a la pestaña "Compartidos".

Aquí añadiremos un nuevo compartido en el servidor Samba (SMB/CIFS). Primero le damos un nombre y un comentario descriptivo, luego seleccionamos la carpeta compartida que creamos hace un momento, el menu desplegable es muy util  ya que nos indica no solo las carpetas compartidas creadas sino también nos indica a qué partición (o arreglo) pertenece.
Para seguir con la política de acceso público, marcamos la casilla Público y la de Navegable, le damos a OK y tenemos listo nuestro compartido.

Desde un cliente Windows, en el navegador de archivos vamos a Red y se mostrará un equipo con el nombre que hayamos dado al servidor (esto lo podemos modificar en Sistema - Red en la pestaña
"General")

Con esto podemos leer y escribir en el disco compartido desde clientes windows sin ningún problema, en una próxima publicación hablaré un poco más acerca de los permisos para empezar a tener un control más detallado de los accesos al compartido. Estén atentos! y comenten!

Saludos a tod@s.