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!.

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.

OpenMediaVault o como tener un NAS fácil y de código abierto

 Hay muchas maneras de tener almacenamiento en nuestra red local, empezando desde un simple compartido, montando un servidor NFS, hasta un NAS. Esta última opción es la más "profesional" si se le quiere catalogar de alguna forma, pero (siempre hay un pero) las opciones en el mercado para este tipo de productos pueden llegar a ser prohibitivas en la mayoría de los casos, sobre todo si hablamos de redes locales para oficinas pequeñas o pequeñas empresas y las soluciones de bajo costo tienen la limitación de que no son expandibles y que disponemos de los servicios que el fabricante decida y que pueden no siempre ajustarse a nuestras necesidades.

¿Qué pasaría si tenemos un equipo modesto y un poco de almacenaje disponible y queremos tener almacenamiento de acceso en red en un ambiente mixto windows/linux?
¿Qué sucede cuando disponemos de un nuevo disco para aumentar el espacio y además requerimos de otro tipo de servicios para ciertos accesos como por ejemplo ftp y ssh?
¿Qué sucede si requerimos de un control estricto de accesos por parte de grupos y usuarios?

Para cubrir esas y muchas necesidades más tenemos OpenMediaVault. Una distribución GNU/Linux basada en Debian que hace posible tener un servidor NAS flexible y seguro en cuestión de minutos. Dispone de una administración avanzada via web, sistema completamente en español y de uso intuitivo.

Con un equipo de características más que modestas como puede ser un procesador 486, 1Gb de ram y 2Gb de espacio en disco, tendremos corriendo con tranquilidad a OMV. Lo importante aquí es por un lado la estabilidad y velocidad de la red y por otro el tipo de discos que usemos. Si es para un ambiente de tráfico normal, donde los usuarios acceden a sus archivos, discos SATA a 5200rpm será suficiente; si en cambio es para mantener bases de datos transaccionales donde el tráfico puede llegar a ser mucho mayor, se puede pensar a discos SSD.

Pero sea cual sea la situación, nosotros siempre tendremos el poder de decidir qué tecnología usar y cómo usarla. Podemos tener carpetas accesibles únicamente por ssh y otras por sftp, tener una partición dedicada a accesos desde clientes windows y otra invisible a todos excepto para el sistema de respaldos, las posiblidades son infinitas.

Otra gran ventaja de contar con un sistema como OpenMediaVault es la flexibilidad de configuración de los discos y particiones, pudiendo tener arreglos RAID de manera dinámica sin afectar la información, así como cambiar tamaños de particiones al vuelo, desmontar discos/particiones o cambiar puntos de montaje directamente desde la administración web.

Así que ya lo saben, si necesitan disponer de un NAS Gnu/Linux no duden en darle una oportunidad a OpenMediaVault.

En un próximo aporte subiré una guía sobre su instalación y confguración para tener espacio compartido con sistemas windows y un par de cosas útiles más. Estén atentos!

Servidor Local: Arch + Xampp + Joomla 2.5 + Ja T3 Framework

En esta guía voy a reproducir los pasos que he seguido para correr Joomla! sobre XAMPP (Apache, MySQL, PHP y Pearl) en un sistema ArchLinux, todo esto como servidor local; por último instalo JA T3 Framework y una plantilla. Con eso se tendría todo lo básico necesario para empezar la codificación, diseño y administración de un sitio ya sea para uso interno o para luego exportarlo a un hosting.

Servidor NFS sobre Debian, distintos clientes.

En el post anterior sobre la instalación de un servidor web lighttpd decía que lo hice en una pc antigua que volvió a la vida jeje. Bueno otra cosa que conseguí fue un disco IDE de 80Gb en muy buenas condiciones (verifiqué su estado con herramientas como smartctl y hdparm) al cual lo primero que hice fúe vaciarlo y crear una partición ext3 del tamaño completo del disco. En primera instancia pense en ponerlo en mi equipo ya que su disco sata de 320Gb está casi lleno. Pero al ver que las portátiles de mi madre y padre no tienen respaldos actuales y que son muchos gigas de información importante, decidí darle más uso al equipo que hace de servidor web y montar otro servidor, pero esta vez un servidor NFS.

Servidor Web Lighttpd

Luego de dar vida nuevamente a una pc vieja que tenía acumulando polvo mediante una instalación base de Debian Squeeze, decidí hacer algo más con ella.El equipo tiene las maravillosas especificaciones de: AMD Semphron 1200+, 512Mb de RAM, Chipset SiS630 y todo lo demás onboard. Si bien para un escritorio actual puede que no sea mucho, es suficiente para muchos tipos de tareas, mas aún si se presinde de entorno de escritorio ;)

Para hacer pruebas con mi red local, decidí montar un servidor web. Este tenía que ser liviano, estable y rápido. No hay problema si se tiene que sacrificar alguna cosa de avanzada por que no se la requiere (de momento). Así que recordaba servidores "peso ligero" como el confiable Cherokee o Hiawatha pero sin que estos tengan nada de malo, la cantidad de documentación y sitios que los usan activamente me hizo pensarlo dos veces. Si quiero meter mano más a fondo a un servidor prefiero que sea uno de uso comprobado.

Así es como llegue a Lighttpd, un servidor que siendo muy liviano es muy poderoso y es por eso que lo usan sitios como youtube.com, meebo.com, imageshak.us, mininova.org, entre muchos otros, la documentación es muy clara tanto en sus archivos como en la web oficial. No me voy a detener a halbar de sus muchas características ya que me llevaría varias páginas. La página oficial tiene toda información necesaria :)

VSFTPD en Centos - Servidor FTP con usuarios virtuales.

Este posteo es más informativo que una guía, pongo los pasos que he realizado para montar un servidor FTP sobre Centos mediante vsftpd y con la característica de los usuarios virtuales lo cual es mucho más seguro que los normales.

Podemos verificar si tenemos o no instalado vsftpd mediante:

rpm -aq | grep vsftpd

De no ser así, lo instalamos junto con un par de dependencias para la creación de las bases de datos de usuarios como veremos más adelante:

yum -y install db4 db4-utils vsftpd

 A continuación editamos el archivo /etc/vsftpd.conf. El contenido de este puede variar según las características que queramos dar al servicio, pero este sería el contenido mínimo necesario para que funcione bien con usuarios virtuales:

# Bloquear el acceso anónimo

anonymous_enable=NO

# Permitir el acceso local, necesario para usuarios virtuales

local_enable=YES

# Permitir la escritura y la descarga de ficheros

write_enable=YES

download_enable=YES

# Máscara de ficheros

local_umask=022

# Restricciones anónimas

anon_upload_enable=NO

anon_mkdir_write_enable=NO

anon_world_readable_only=YES

# Puerto de conexión

connect_from_port_20=YES

# Generar archivo log

log_ftp_protocol=YES

# Otras características

listen=YES

xferlog_std_format=YES

pam_service_name=vsftpd.virtual

userlist_enable=YES

hide_ids=YES

# Enjaulamiento de usuario

chroot_local_user=YES

# Usarios virtuales y ruta de acceso

local_root=/home/ftpuser/pub

virtual_use_local_privs=YES

guest_enable=YES

Ahora necesitamos crear la base de datos de usuarios virtuales, para ello usamos Berkeley DB. Primero creamos un archivo de texto plano en /etc/vsftpd/

cd /etc/vsftpd

vi usuariosftp.txt

este archivo llevará los nombres de usuarios y claves de acceso una por línea, es decir si el usuario es andres y su clave andresclave y otro usuario andrea y de clave andreaclave, quedaría así:

andres

andresclave

andrea

andreaclave

Generamos la base de datos:

db_load -T -t hash -f usuariosftp.txt vsftpd_virtual_users.db

chmod 600 vsftpd_virtual_users.db

rm usuariosftp.txt

 Con el archivo vsftpd.conf mostrado arriba, todos los usuarios accederán a la misma ubicación especificada por local_root=. Si en cambio deseamos que cada uno tenga su carpeta de usuario (y que no puedan moverse fuera de ella) entonces debemos hacer un par de cambios al archivo de configuración.


Añadimos la opción:

user_sub_token=$USER

y modificamos lo siguiente:

local_root=/home/ftpuser/pub/$USER

Por supuesto que la ruta madre de los usuarios puede ser la que queramos. Solo que suele ser recomendable colocarla en /home por motivos de seguridad ya que por ejemplo suele ser una partición dedicada.

Ahora se crea un archivo PAM para use la base de datos de los usuarios (el nombre del archivo tiene que ser el mismo especificado en la opción pam_service_name=)

vi /etc/pam.d/vsftpd.virtual

Con el contenido:

#%PAM-1.0

auth           required    pam_userdb.so db=/etc/vsftpd/vsftpd_virutal_users

account     required    pam_userdb.so db=/etc/vsftpd/vsftpd_virtual_users

session      required    pam_loginuid.so

Creamos la ubicación indicada en el archivo de configuración:

mkdir -p /home/ftpuser/pub/

chown -R ftp:ftp /home/ftpuser/

Por último iniciamos el servicio y hacemos que se inicie siempre con el sistema:

service vsftpd start

chkconfig vsftpd on

Para monitorear el servicio se tiene el archivo /var/log/secure para el acceso de los usuarios, así como el log del servicio propiamente en /var/log/vsftpd.log

tail -f /var/log/secure | grep vsftpd  

tail -f /var/log/vsftpd.log

Y eso sería todo, podemos acceder al servidor desde los clientes mediante consola o gráficamente con aplicaciones como FileZilla o la extensión de firefox FireFTP.

Espero como siempre que sea de utilidad.

Saludos!