Publicado el

Añadir un disco a un servidor con RAID1 existente

hard diskEn este post se pretende explicar cómo usar la herramienta HP Array Configuration Utility CLI for Linux «hpacucli» para añadir un tercer disco a un servidor HP que ya cuenta con dos discos SAS en RAID1. Nos interesa añadir el tercer disco sin que forme parte del RAID, es decir, queremos añadir el tercer disco como si fuera un disco sin RAID, un disco normal. Ya hablamos de la herramienta hpacucli hace un tiempo aquí.

Entorno

El problema que nos encontramos es que por defecto, los discos los reconoce la controladora del RAID y no aparecen en el fdisk. Así pues, tras añadir físicamente el disco al servidor y tras el reinicio reglamentario para verificar que efectivamente el disco se ha reconocido, nos encontraríamos con que el disco continúa sin aparecer con el fdisk:

[root@myserver]# fdisk -l
Disco /dev/cciss/c0d0: 300.0 GB, 299966445568 bytes

Disposit. Inicio Comienzo Fin Bloques Id Sistema
/dev/cciss/c0d0p1 * 1 126 512000 83 Linux
/dev/cciss/c0d0p2 126 71798 292422656 8e Linux LVM

Disco /dev/dm-0: 234.9 GB, 234881024000 bytes
Disco /dev/dm-1: 10.5 GB, 10536091648 bytes
Disco /dev/dm-2: 21.0 GB, 20971520000 bytes
Disco /dev/dm-3: 31.5 GB, 31474057216 bytes
Disco /dev/dm-4: 1577 MB, 1577058304 bytes

Como se puede ver, únicamente aparece un disco en RAID físico, que sabemos que corresponde con los dos discos de sistema en RAID1. Ni rastro del nuevo disco.

Continuar leyendo «Añadir un disco a un servidor con RAID1 existente»

Publicado el

Configurar SFTP con OpenSSH

seguridadHoy toca ver cómo configurar openSSH (como siempre, en entornos Red Hat) para aceptar únicamente peticiones SFTP enjaulando a los usuarios sftp en sus homes. Para añadirle contenido, además, configuraremos este servicio en un segundo proceso que correrá en la máquina de forma independiente al proceso openssh habitual, para evitar tener problemas con nuestras conexiones SSH, y por tanto, se configurará un puerto de escucha diferente al habitual, en el ejemplo, el 12022.

Fichero de configuración

En primer lugar copiaremos el fichero de configuración de openssh para adaptar la copia a nuestras necesidades:

[root@myserver]# cp /etc/ssh/sshd_config /etc/ssh/sshd_config_12022
Lo abriremos con vi, y nos aseguraremos de cambiar el puerto de escucha por el nuevo puerto. Además, cambiaremos el «Subsystem sftp» por defecto y añadiremos al final las líneas correspondientes al enjaulado de usuarios:
# Cambiamos el puerto
Port 12022

# Modificamos el Subsystem original
#Subsystem sftp /usr/libexec/openssh/sftp-server 
Subsystem sftp internal-sftp 

# Añadimos el enjaulado 
Match Group sftp12022 
  ChrootDirectory /sftp/%u
  ForceCommand internal-sftp 
  AllowTcpForwarding no
Desde este momento, trabajaremos con el nuevo fichero de configuración sshd_config_12022, asegurándonos así de no intervenir en el servicio de openssh de la máquina que ofrece el servicio de SSH. Además de decirle a openssh que a partir de ahora usaremos el puerto 12022 para las coneciones SFTP, habremos definido que se enjaulará a todos los usuarios de sistema cuyo grupo principal sea el grupo «sftp12022». Además, estaremos enjaulando a todos estos usuarios en el directorio /sftp/nombreusuario.
Publicado el

Instalar y configurar MySQL Percona XtraDB Clúster

clusterPercona XtraDB Clúster, es la solución de alta disponibilidad y balanceo de carga multi-máster del fork de MySQL «Percona». La solución recomendada para un cluster necesita un mínimo de 3 nodos, pero siempre un número impar de nodos. En este post, sin embargo, montaremos un cluster Percona con 2 nodos y un árbitro -todo con Percona XtraDB Cluster 5.5 y wsrep_provider_version 2.6(r152)- puesto que supondremos que únicamente disponemos de dos servidores dedicados para el clúster. Más adelante se explicará qué es y para qué sirve un árbitro.

Percona Master-Slave vs XtraDB Clúster

Master-slave consta de un único servidor que permite escrituras, mientras que resto de nodos (slaves) únicamente permiten lecturas. Los slaves replicarán los datos del único master, y se mantendrá así los mismos datos en todos los nodos de la solución. En este caso, si se dispone de un balanceador para los slaves, tendremos un balanceo de carga para las lecturas, lo cual hace de esta solución una solución ideal para entornos con un alto volumen de lecturas. Además, se conseguirá un entorno de alta disponibilidad para las lecturas, pero no así para las escrituras.

Con XtraDB Clúster tendremos múltiples servidores corriendo varios MySQL (basados en Percona) con los mismos datos, permitiendo a los clientes escribir en cualquiera de los servidores, y replicando los datos al resto de nodos del clúster. Ésto es ideal para entornos donde hay un gran volumen de escrituras, pero también de lecturas, o donde necesitemos tener alta disponibilidad, también de los nodos «master» (que permiten escrituras).

Limitaciones

Percona XtraDB Cluster, está basado en Galera Cluster (igual que MariaDB Cluster), y por tanto, a día de hoy, tiene un seguido de limitaciones  de entre las que destacan:

  • La replicación sólo funcionará con las tablas InnoDB. Puede haber otras tablas pero no se replicarán, lo cual significa que no se encontrarán en todo el clúster, únicamente existirán en ese nodo.
  • La velocidad de escritura de todo el clúster, viene delimitado por el nodo más lento. Si un nodo tiene problemas y se vuelve lento, el clúster entero será lento.
  • Puede darse el caso de que dos clientes estén modificando la misma celda al mismo tiempo. Si ésto ocurriera, únicamente uno de los dos tendría éxito, mientras que el otro recibiría un error de MySQL.
  • Se recomienda un mínimo de 3 nodos, aunque en la documentación oficial también confirman que se puede montar con 2 nodos. En entornos con dos nodos es altamente recomendable montar un árbitro (que es lo que haremos).
  • Ver listado completo.

Continuar leyendo «Instalar y configurar MySQL Percona XtraDB Clúster»

Publicado el

Cómo configurar VirtualHosts para HTTPS

ApacheEn Apache, usamos los VirtualHosts para poder definir diferentes proyectos web, cada uno con su propio dominio (o dominios), escuchando tras el mismo puerto e IP. Ésto podemos hacerlo para conexiones HTTP normales, pero antiguamente no se podía para HTTPS, puesto que la conexión venía cifrada y por tanto Apache no podía saber a qué dominio se quería acceder.

Al parecer, desde el 2006 se incorporó una extensión que le permitía al cliente (el navegador del usuario) enviar el dominio a consultar en la primera petición, antes de iniciar la transferencia cifrada de datos, permitiéndo así al servidor poder usar el mecanismo de VirtualHosts para tener varios sitios web HTTPS escuchando por el mismo puerto (típicamente el 443).

Requisitos

Seguramente nuestro servidor Linux con Apache ya tenga instalados los requisitos para funcionar, pero para asegurarnos, bastará con confirmar que tenemos:

  • openSSL 0.9.8f o posterior instalado
  • mod_ssl instalado en Apache

En mi ejemplo, un Fedora release 13 (Goddard) con Apache 2.2.15, lo he confirmado así:

[root@myServer]# openssl version
OpenSSL 1.0.0d-fips 8 Feb 2011

[root@myServer]# httpd -M | grep -i ssl
ssl_module (shared)

[root@myServer]# grep -i ssl /var/log/httpd/error_log*
Apache/2.2.15 (Unix) DAV/2 PHP/5.3.3 mod_ssl/2.2.15 OpenSSL/1.0.0-fips mod_wsgi/3.4 Python/2.7.5 configured — resuming normal operations

Si no tienes openssl ni mod_ssl, puedes instalarlo con yum y posteriormente reiniciar Apache:

[root@myServer]# yum install openssl mod_ssl
[root@myServer]# /etc/init.d/httpd restart

Continuar leyendo «Cómo configurar VirtualHosts para HTTPS»

Publicado el

VPN entre dos servidores con openVPN

openvpntech_logo1Hoy vamos a montar una VPN entre dos servidores ubicados en dos CPDs distintos, para que puedan comunicarse entre ellos a través de un canal seguro. En mi caso, he usado el túnel VPN (Full TLS) para conectar dos servidores MySQL que replican los datos el uno del otro. De esta forma, los datos que se replican de la base de datos viajan por Internet a través de un canal privado y seguro.

He hecho las pruebas en el siguiente entorno:

  • OpenVPN 2.3.2 x86_64-redhat-linux-gnu

Un servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace (sí, 512MB de RAM, y estamos en 2013, sí).

  • Hostname: vpntest1
  • IP pública: 80.80.80.81
  • IP privada: 10.10.10.81

Un segundo servidor CentOS 6.4 con 512MB de RAM, instancia de RackSpace en un CPD diferente.

  • Hostname: vpntest2
  • IP pública: 80.80.80.82
  • IP privada: 10.10.10.82

Por defecto, los servidores vienen con selinux deshabilitado, iptables parado, y no pueden hacer ping entre sí mediante sus ips privadas pero sí mediante sus ips públicas. He seguido, en mayor parte, este fantástico tutorial que han hecho los técnicos de Rackspace.

También es importante configurar ntp en ambos servidor, para que tengan la hora sincronizada.

Continuar leyendo «VPN entre dos servidores con openVPN»

Publicado el

Automatiza el mantenimiento de directorios temporales en Linux

cleanNo sé cómo he podido vivir tanto tiempo sin conocer tmpwatch, una herramienta que suele venir con el sistema y que nos permite automatizar el mantenimiento de directorios que por su naturaleza, acumulan ficheros temporales que pocas veces se vuelven a usar. tmpwatch, por lo tanto, busca los ficheros y directorios antiguos en una determinada ubicación, y los elimina de forma recursiva. Lo que antes solía hacer con una instrucción como la siguiente, ahora lo haré con tmpwatch:

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual
find . -mtime +365 -exec rm {} \;

# eliminación ficheros con más de 365 días desde la última modificación desde el directorio actual y sub-directorios
find . -depth -mtime +365 -exec rm {} \;

Un ejemplo muy claro, es usar tmpwatch para eliminar los ficheros que no se han usado (access time) en los últimos x días (o meses) dentro de directorios como /tmp o ~/Downloads. En cuanto a servidores, seguro que tendemos la típica aplicación que va dejando cientos de archivos temporales en una determinada ubicación, que hemos de estar borrando cada cierto tiempo ya sea a mano o con algún script programado en el cron.

Continuar leyendo «Automatiza el mantenimiento de directorios temporales en Linux»

Publicado el

MongoDB: Recuperar un config server

mongodbHoy me he encontrado, que tras una caída de un servidor que alojaba un config server de mi cluster MongoDB 2.2.0 (sobre un entorno Red Hat), el config server no era capaz de arrancar. Concretamente, al intentar iniciar el config server, podría ver los siguientes logs en el fichero de error:

Thu Sep 12 11:47:37 [initandlisten] dbexception during recovery: 15874 couldn’t uncompress journal section
Thu Sep 12 11:47:37 [initandlisten] exception in initAndListen: 15874 couldn’t uncompress journal section, terminating
Thu Sep 12 11:47:37 dbexit:
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close listening sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to flush diaglog…
Thu Sep 12 11:47:37 [initandlisten] shutdown: going to close sockets…
Thu Sep 12 11:47:37 [initandlisten] shutdown: waiting for fs preallocator…
Thu Sep 12 11:47:37 [initandlisten] shutdown: lock for final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: final commit…
Thu Sep 12 11:47:37 [initandlisten] shutdown: closing all files…
Thu Sep 12 11:47:37 [initandlisten] closeAllFiles() finished
Thu Sep 12 11:47:37 [initandlisten] shutdown: removing fs lock…
Thu Sep 12 11:47:37 dbexit: really exiting now

Al parecer, el fichero de journal se ha corrompido con la caída del server y ni si quiera es capaz de solucionarse con un «–repair». Aprovechando que mi cluster tiene 3 config servers, he pasado a parar uno de los dos config servers que aun funcionaban, para copiar los datos del dbpath al config server corrompido, con tal de recuperarlo.

El proceso ha sido el siguiente, descrito en la documentación oficial de MongoDB (v2.2): Continuar leyendo «MongoDB: Recuperar un config server»

Publicado el

Limpieza y rotación del slow-query-logs

cleanupYa hablamos de cómo limpiar de forma segura el error-log de MySQL. Otro fichero de logs que puede dar problemas, si lo tenemos activado, es el slow_query_log, que se encarga de almacenar las queries que se han ejecutado sin índices, o que han tardado más de determinados segundos en ejecutarse. Este fichero, por tanto, nos debería servir para identificar puntos de mejora en nuestras queries, pero si tenemos mucho que mejorar, se llenará rápidamente. En mysqlperformanceblog explican cómo crear un script para uso de logrotate para limpiar de forma automática este log de forma periodica, y evitar así problemas mayores.

Primero, crearemos el script de rotación, cogido directamente de mysqlperformanceblog:

[root@myserver]# vi /etc/logrotate.d/mysql-slow

/var/lib/mysql/mysql-slow.log {
nocompress
create 660 mysql mysql
size 1G
dateext
missingok
notifempty
sharedscripts
postrotate
/usr/bin/mysql -u logrotate -pmipassword -e ‘select @@global.long_query_time into @lqt_save; set global long_query_time=2000; select sleep(2); FLUSH SLOW LOGS; select sleep(2); set global long_query_time=@lqt_save;’
endscript
rotate 5
}

Se ha de tener en cuenta, que en la instrucción de postrotate, necesitaremos añadir el usuario y password de acceso al mysql para poder ejecutar esas consultas. También se deberá indicar la ruta al fichero del slow-log en la primera instrucción (marcado en negrita).

Continuar leyendo «Limpieza y rotación del slow-query-logs»

Publicado el

Instalar y configurar REDIS desde source

91018527El título es bastante identificativo. Este post explica cómo instalar y configurar Redis (la base de datos/caché key-value) en CentOS 6 desde source, si por alguna razón no pudiéramos o no quisiéramos instalar mediante yum.

Descarga e instalación

Podemos descargar la última versión estable de Redis directamente desde la web oficial. Bastará con extraer el tarball y ejecutar «make«:

[root@myserver]# wget http://redis.googlecode.com/files/redis-2.6.13.tar.gz
[root@myserver]# tar xzf redis-2.6.13.tar.gz
[root@myserver]# cd redis-2.6.13
[root@myserver]# make

Si todo ha ido bien, ya tendremos Redis listo. Como seguramente habremos descomprimido el tarball en un directorio temporal, en mi caso he preferido cubrirme las espaldas y mover el directorio extraido (y posteriormente recompilado con make) a /etc/redis/installation_files.

[root@myserver]# cd ..
[root@myserver]# mv redis-2.6.13 installation_files
[root@myserver]# mkdir /etc/redis
[root@myserver]# mv installation_files /etc/redis/

Continuar leyendo «Instalar y configurar REDIS desde source»

Publicado el

Vaciar el error.log de MySQL

Un tema que me ha preocupado siempre, son los logs de MySQL, y más concretamente el error.log. En entornos de replicación, el error.log puede llegar a ser gigante cuando se usan sentencias que el sistema detecta como «advertencias». Por ejemplo:

[Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. The statement is unsafe because it uses a LIMIT clause. This is unsafe because the set of rows included cannot be predicted.

¿Cómo podemos vaciar el error.log de forma segura, sin que tenga impacto en el servicio de MySQL? Pues vamos a verlo.

Continuar leyendo «Vaciar el error.log de MySQL»