Año nuevo, diseño nuevo

Happy New Year
¡Feliz año a todos!

Sólo decir que he aprovechado la entrada del 2013 para cambiarle el diseño al blog, que ya tenía unos añitos. Hacía tiempo que me parecía que el tipo de letra, el tamaño, o directamente la anchura de los párrafos, dificultaban en ocasiones, la lectura.

Así que tras una búsqueda en Google, he encontrado un tema gratuito de WPZoom que espero sirva para ir a mejor. Eso sí, he tenido que adaptarlo bastante, y aun así me quedan unas cuantas cosas por acabar de ajustar.

A ver si puedo acabar de tenerlo todo listo para los próximos días.

Flickr! Foto por Sean MacEntee

Balanceador de carga con LVS y Piranha

cloud computingEn este artículo veremos cómo configurar un balanceador de carga con LVS y Piranha, en un servidor CentOS, con un único router LVS. Hay muchos artículos por Internet que explican cómo hacerlo con 2 routers, para conseguir así tener alta disponibilidad en el balanceador, pero no siempre se disponen de dos máquinas para conseguir la alta disponibilidad. Como añadido, el servicio a balancear será MySQL, no Apache como suele ser habitual.

Para el test, los sevidores tienen las siguientes características, además de selinux deshabilitado e iptables configurado:

Hostname: balancer
IP: (eth0) 192.168.2.228. Default gw: 192.168.2.1

Hostname: mysql1
IP: (eth0) 192.168.2.241. Default gw: 192.168.2.1

Hostname: mysql2
IP: (eth1) 192.168.2.242. Default gw: 192.168.2.1

Continuar leyendo «Balanceador de carga con LVS y Piranha»

Load Average

Load AverageEl Load Average nos sirve para hacernos una idea de la carga del servidor actual, y de los últimos minutos, en media. Se puede ver con el comando «top», en la esquina superior derecha, o con el comando «uptime», por ejemplo.

[user@server ~]$ uptime
09:38:57 up 6 days, 6:33, 1 user, load average: 2.05, 1.59, 1.56

En estos comandos, el Load Average muestra 3 números, correspondientes al Load Average del sistema en el último minuto, los últimos 5 y los últimos 15. En realidad, interesará especialmente el Load Average de los últimos 5 y 15 minutos, puesto que puntualmente (en el último minuto) podría haber una carga alta, pero nos empezaremos a preocupar cuando la elevada carga dure varios minutos.

El Load Average es la media de procesos que han estado:
a) Usando CPU o esperando a usarla
b) Esperando obtener acceso I/O

Así pues, nos puede ayudar a detectar problemas de CPU o de I/O. Un alto Load Average y un bajo uso de CPU nos apuntará a que hemos de usar iostat para revisar la i/o e iotop para acabar de identificar el problema.

El Load Average no se adaptará al número de CPUs, así que hay que tenerlo en cuenta a la hora de intepretar sus valores. Un Load Average de 1, cuando se tiene una CPU, indicará que la CPU se está usando al 100% y que todos los procesos están entrando en la CPU. Pero cuando se tienen 4 CPUs, un LoadAverage de 1 indica que sólo se está usando el 25% del total.

Fuente: http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages

Flickr! Foto por 4Cheungs

Detalles de MySQL Master-Slave

Master Slave databaseMySQL master-slave tiene las siguientes características:

  • Replicación asíncrona: en cuanto se ejecuta una query de modificación en el master, ésta se lanza al momento para ejecutárse en los slaves.
  • La replicación puede basarse en:
    • Statement Based Replication (SBR): ejecuta en los slaves, la sentencia SQL ejecutada en el master.
    • Row Based Replication (RBR): replica en los slaves, únicamente las filas que han cambiado en el master (replica datos en lugar de sentencias que han de ejecutarse).
    • Mixed Based Replication (MBR): una mezcla de las dos anteriores.
    • Se puede verificar el tipo de replicación utilizado, ejecutando en cualquier server:

mysql> show global variables like ‘binlog_format’;
+—————+———–+
| Variable_name | Value |
+—————+———–+
| binlog_format | STATEMENT |
+—————+———–+
1 row in set (0.00 sec)

Continuar leyendo «Detalles de MySQL Master-Slave»

SSH con certificados

Apache HTTPHace un tiempo, escribí como acceder de un servidor a otro mediante certificados por SSH, para automatizar tareas que requieran de una conexión SSH entre servidores, evitando así tener que introducir el password. Aquí el post original.

Sin embargo, en ocasiones, el SSH no está configurado para aceptar conexiones con password, y no podemos por lo tanto, usar el comando «ssh-copy-id». Para estas ocasiones, podemos seguir el procedimiento descrito a continuación:

Continuar leyendo «SSH con certificados»

Pasos para migrar un proyecto web

LAMP MigrationMigrar un proyecto web (php/mysql) de un servidor a otro(s) puede parecer un proceso sencillo, pero rara es la vez en la que no salen imprevistos. Por esta razón, prefiero tener bien documentado todo el proceso de migración, antes de empezar, para evitar sobresaltos e ir sobre seguro.

La idea del siguiente proceso, es clonar la base de datos del servidor a migrar al nuevo servidor, y una vez clonada, modificar el código del servidor a migrar para empezar a usar la base de datos del nuevo server en lugar de la que usaba hasta ahora. De esta manera, no se perderán datos cuando se inicie la modificación de las DNS para apuntar al nuevo servidor.

REQUISITOS

  • En el nuevo servidor, abrir (por lo menos) los puertos 22 y 3306 para la IP del servidor a migrar.
  • Apache y MySQL instalados y configurados en el nuevo server, incluído el vhost del proyecto.
  • Resto de dependencias del proyecto instaladas en el nuevo server.

Continuar leyendo «Pasos para migrar un proyecto web»

Yum rollback, undo o deshacer

Yum rollbackEn muchas ocasiones, hemos de actualizar o instalar nuevos paquetes en servidores críticos, que difícilmente podemos asegurar que no afectarán a nuestros servicios. Es posible que la nueva versión de PHP tenga alguna incompatibilidad con el código que usa la versión añeja que tiene el servidor, o que una nueva versión de openssh venga con un 0day.

¿Cómo podemos deshacer lo que acabamos de estropear con yum?

Afortunadamente, las últimas versiones de yum, vienen con una nueva funcionalidad que permite ver el histórico de ejecuciones, y lo más importante, volver atrás. Aquí lo explican en la documentación oficial.

Continuar leyendo «Yum rollback, undo o deshacer»

Apuntes de mod_rewrite

httpd ApacheEste post es una breve introducción a mod_rewrite, que puede servir como punto de partida, pero que no servirá ni mucho menos, como manual ni como guía. Por favor, mira las fuentes al final del mismo, para acceder a las fuentes originales y ampliar la información sobre mod_rewrite.

Mod_rewrite es uno de los módulos de Apache más importantes. Nos permitirá manipular urls (reescribiendo urls al vuelo), redirigir una url a otra o invocar un proxy interno, mediante una serie de reglas y condiciones.

En primer lugar, activaremos el motor de reescritura (en el .htaccess o en el virtualhost correspondiente), en el caso de que esté instalado mod_rewrite. Una vez activado, pondremos las reglas a continuación:

<IfModule mod_rewrite.c>
RewriteEngine On
## Aquí las reglas
</IfModule>

Continuar leyendo «Apuntes de mod_rewrite»

Llevar a background a un proceso running

Background
Si se ha ejecutado un proceso en una terminal Linux, y necesitamos retomar el control de la terminal sin interrumpir el proceso, podemos ejecutar «Ctrl+z» para parar el proceso, sin matarlo. De esta manera, volveremos a tener la terminal en primer plano.

Posteriormente podremos ejecutar «jobs» para ver el proceso recién detenido:

$ jobs
[1]+ Stopped ./test.sh

«Jobs» nos devolverá el número de la tarea correspondiente al proceso.

Si ejecutamos «bg», podremos reactivar el proceso y mandarlo a background, que es lo que deberíamos haber hecho originalmente, si hubiéramos sabido que el proceso se nos quedaría corriendo tanto tiempo en primer plano:

$ bg 1
[1]+ Running ./test.sh &

Flickr! Foto por Maggie-Me

Rotar archivos de log con Logrotate

Logrotate es el proceso encargado de rotar, comprimir y enviar por mail los logs de sistema en Linux.

Cuando un paquete individual (como httpd, bacula, vsftpd, yum, etc.) se instala, éste añade en el directorio /etc/logrotate.d/ su fichero de configuración logrotate encargado de la gestión de los logs. Así por ejemplo, Apache añade un fichero similar al siguiente:

[root@server logrotate.d]# cat /etc/logrotate.d/httpd
/var/log/httpd/*log {
missingok
notifempty
sharedscripts
postrotate
/sbin/service httpd reload > /dev/null 2>/dev/null || true
endscript
}

Si se quieren añadir políticas de rotación de logs para logs que no estén definidos o que no estén en las rutas por defecto, se podrá tocar el fichero de configuración /etc/logrotate.conf

En este fichero (/etc/logrotate.conf), además, se configuran las políticas de rotación de logs comunes a todos los logs. En cada fichero de configuración dentro de /etc/logrotate.d, se pueden sobreescribir las políticas comunes, de forma local, redefiniendo el valor para la variable de configuración deseada. Así por ejemplo, se podría crear un fichero para rotar los logs del tipo /var/log/miapp.log que deja una aplicación concreta, tal y como sigue:

[root@server logrotate.d]# cat /etc/logrotate.d/miapp
/var/log/miapp.log {
weekly
copytruncate
rotate 4
compress
missingok
}

Con la definición anterior, estaríamos inficando:

  • weekly: los logs se rotarán semanalmente.
  • copytruncate: crea una copia del fichero de logs original y después trunca el fichero original a cero bytes, de esta manera «miapp» siempre apuntará al mismo fichero y evitaremos problemas.
  • rotate 4: mantendrá los últimos 5 ficheros (rotará 4 veces).
  • compress: comprime el fichero de log, una vez rotado.
  • missingok: si el fichero de log no existe, no devuelve error.

Logrotate no es un demonio que corre en la máquina. Así pues, tras realizar cualquier cambio en el fichero de configuración, no será necesario realizar ningún restart de ningún servicio. Símplemente, Logrotate usará la nueva configuración en la siguiente ejecución. Si se desea testear Logrotate tras algún cambio en su configuración, se puede ejecutar el comando siguiente:

logrotate -vf /etc/logrotate.conf

PD: Es posible que tras la ejecución del comando anterior, tarde unos segundos en empezar a escribir en el nuevo fichero de logs.

Útil y muy necesario para mantener controlado el espacio usado por los logs.

Fuentes:
http://www.thegeekstuff.com/2010/07/logrotate-examples/
http://www.linuxcommand.org/man_pages/logrotate8.html
http://www.linuxquestions.org/questions/linux-newbie-8/