Una impresionante presentación de Yoshinori Matsunobu, uno de los mayores expertos en BBDD (Principal Infrastructure Architect en DeNA, MySQL Lead Consultant en MySQL/Oracle/Sun, Oracle ACE Director...) explicando todo lo que se necesita saber para la administración de bases de datos MySQL bajo Linux: SSD/HDD y cómo elegir el sistema de ficheros más adecuado, elegir la CPU más adecuada, el tamaño de swap, la configuración de red... aquí está el sumario de la presentación.

Estas son las diapositivas de un tutorial de 3 horas que impartió en la MySQL Conference and Expo 2011.

También se pueden descargar las diapositivas en formato PDF.

Desde hace años me acostumbré a trabajar con un sistema de control de proyectos que me ofrezca un almacén de documentación, gestión de tareas y visor de repositorios de código. Tras probar muchas opciones, mi decisión fue para Trac, y en esta anotación guardo el proceso de instalación y configuración para un entorno multiproyecto y con conexión al sistema de control de versiones Git.

Ya tenemos disponible Firefox 4.0 en Ubuntu 10.10 y anteriores, y puesto que la mejora en rendimiento y funcionalidades es bastante grande, toca instalarlo. Para ello, los pasos son rápidos:

$ sudo add-apt-repository ppa:mozillateam/firefox-stable
$ sudo apt-get update
$ sudo apt-get install firefox

Listo, con esto ya lo tenemos instalado. Si lanzamos ahora Firefox veremos la nueva versión, y tratará de actualizar las extensiones que tengamos instaladas. En mi caso, tuve dos problemas: la extensión de Delicious y el paquete de idioma Español. En ambos casos, al tratar de instalarlos me devolvía un error "Esta extensión no es compatible con Firefox 4.0.1". ¿Solución?

Pufando extensiones

Empecemos por Delicious. La extensión está instalada en nuestro directorio personal y si ID es 2fa4ed95-0317-4c6a-a74c-5f3e3912c1f9, por lo que vamos a su directorio (~/.mozilla/firefox/extensions//{2fa4ed95-0317-4c6a-a74c-5f3e3912c1f9}/, donde <perfil> es una ristra aleatoria de caracteres, única por cada usuario) y editamos el archivo install.rdf, para cambiar la línea

<em:maxVersion>4.0</em:maxVersion>

por

<em:maxVersion>4.1</em:maxVersion>

Reiniciamos Firefox y ya tenemos el plugin, de nuevo, funcionando.

Para hacer lo mismo con el paquete de idioma, vamos a http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/ y descargamos el paquete correspondiente a nuestro sistema, por ejemplo, yo bajé http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/firefox-6.0a1.es-ES.langpack.xpi, o se puede usar directamente uno de estos enlaces:

Para Ubuntu de 32 bit ---> es-ES.xpi

Para Ubuntu de 64 bit ---> es-ES.xpi

Si tratamos de instalarlos, recibiremos el famoso error de versión incompatible, así que directamente lo descargamos (botón derecho --> Guardar enlace...). Lo único que hay que hacer es descomprimir la extensión (es un archivo zip), cambiar la versión en el archivo install.rdf como hemos hecho antes y volver a comprimir la extensión:

$ cd /tmp
 
$ wget http://releases.mozilla.org/pub/mozilla.org/firefox/releases/4.0/linux-x86_64/xpi/es-ES.xpi
$ mkdir extraido && cd extraido
$ unzip ../es-ES.xpi
$ vi install.rdf
$ zip -r ../es-ES-retocado.xpi *

Tras esto, tendremos una extensión es-ES-retocado.xpi. En Firefox, vamos a Tools --> Addons, y en el botón de al lado del buscador a la derecha hacemos clic en Install addon from file... Seleccionamos el archivo que acabamos de crear e instalamos la extensión. Tras unos segundos nos pedirá reiniciar Firefox, lo hacemos y voilá, ya tenemos Firefox en español.

La reforma de la Ley Sinde nos va a traer de regalito el que el gobierno pueda, a su antojo, cerrar el acceso a webs incluso externas a España. Nada más fácil si esto ocurre que acceder a estas webs por medio de un proxy externo a España.

Yo tengo un servidor privado virtual (los típicos VPS) contratado en Francia por menos de 10€ al mes, que uso para alojar varias webs. Pues bien, teniendo un servidor así disponible, basta con abrir un túnel SSH entre nuestro PC y el servidor para que éste haga de proxy y poder navegar tranquilamente por esas webs que nuestros gobernantes no querrán que veamos. Tan fácil como:

ssh -D 2222 usuario@hostname_o_ip_del_servidor

Luego, en el navegador basta con configurar la red para acceso a través de un proxy SOCKS5, apuntando a localhost a través del puerto 2222.

Para el que no tenga un VPS, se pueden encontrar muy muy baratos en USA (hay VPS por menos de $5), o se podrían juntar varios amigos para pagar entre todos un VPS que usar como proxy si esta infame reforma a la ley llega a aprobarse y aplicarse.

Otro uso menos lícito es cuando queremos acceder a alguna web que restringe el acceso según el origen de la IP, por ejemplo, webs que sólo funcionan si se entra desde una IP de Estados Unidos. En estos casos, si tenemos el VPS en EEUU, accediendo de esta forma tendremos acceso porque la IP que llegará será la del VPS.

Munin es un software de monitorización para equipos Linux, que permite monitorizar muchos parámetros y visualizarlos en cómodas gráficas diarias, semanales, mensuales y anuales. Su mejor escenario se encuentra en el mantenimiento de servidores o en la gestión de varios puestos de trabajo. Puede usarse para comprobar el estado de salud y carga de las máquinas, anticipar problemas de rendimiento o capacidad, y en caso de problemas ofrece a posteriori valiosa información sobre los momentos anteriores al problema.

Munin puede descargarse directamente desde la web de Munin, o puede instalarse desde los repositorios del la distribución, ya que normalmente se encuentra en éstos.

Durante el proceso de clonado de máquinas que estoy haciendo me surgió un problema con una: el sistema raíz montaba en read-only. Aunque para un sistema en modo kiosko esto es lo deseado, no lo es en un servidor normal, así que toca repararlo. Tras darme cuenta de que el problema era que montaba en read-only, un ojo a los mensajes de arranque me daba esta información:

$ dmesg
...
Aborting journal on device sda1.
__journal_remove_journal_head: freeing b_committed_data
journal commit I/O error
ext3_abort called.
EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
Remounting filesystem read-only
...

Claramente, es un error en el journaling. Tenemos una posibilidade de actuación que debería-ser-segura-pero-que-yo-no-me-fío. En cualquier caso, debemos arrancar desde un CD de rescate o similar, ya que vamos a actuar sobre la partición desmontada.

Lo que vamos a hacer son palabras mayores: vamos a eliminar el journal de la partición, vamos a reparar errores y luego volver a crear el journal. La teoría dice que este proceso no debería ser destructivo y deberíamos conservar los datos, pero... se trata de una operación delicada, así que por si acaso, backup previo siempre (o mejor aún, una imagen con dd). Y por supuesto, esto sólo se puede hacer desde un Rescue CD o similar, sobre la partición desmontada:

tune2fs -O ^has_journal /dev/sda1
e2fsck -f /dev/sda1
tune2fs -j /dev/sda1

El primer comando desactiva y elimina el journal de la partición. El segundo comando tardará un buen rato según el tamaño de la partición y los datos que contenga; tras el chequeo iniciará la reparación de los problemas encontrados y cuando termine se iniciará la regeneración del journal. Una vez terminados los tres comandos, reiniciamos en el sistema normal para ver si ya se ha resuelto el problema. Tras estos tres comandos, al reiniciar en el sistema normal deberíamos tener el problema resuelto.

En algunos sitios he visto que se aconseja hacer directamente el e2fsck. Creo que no es recomendable, ya que puede producir pérdida de datos: si se hace un e2fsck antes de bajar el journal, tratará de reparar los inodos según el journal corrupto. Si funciona estupendo, hemos reparado el problema a la primera y en tiempo récord, pero si no funciona tendremos que aplicar los tres comandos anteriores, y en ese caso, el e2fsck encontrará mucha información fuera de su sitio, porque trata de recuperar el journal abortado anteriormente (y que hemos eliminado con el primer tune2fs). Esto nos dejará mucha información en lost+found, que será poco menos que imposible de recuperar. Así que, ¿usar e2fsck directamente? Bajo tu responsabilidad, si funciona bien, genial, si no funciona bien, puedes perder datos.

Un pequeño tip para clonar máquinas en red. A veces nos vemos en la situación de tener que duplicar una máquina o, en el peor de los casos, varias (como en un aula). Cuando el hardware es similar o igual, lo mejor es hacer un clonado. Y una forma muy sencilla de clonar dos máquinas es con netcat, la navaja suiza del tpc/ip.

El proceso es muy sencillo. En la máquina destino, arrancamos con un disco de rescate (un LiveCD o similar). Una vez iniciada la sesión y configurada la red, lanzamos un netcat escuchando en un puerto cualquiera:

# nc -l -p 2222 | gunzip | dd of=/dev/sda

Lo que hacemos con este comando es poner a la escucha a netcat en el puerto 2222 (podría ser cualquier otro, mejor si es por encima del 1024). Todo lo que reciba por ese puerto lo enviará a gunzip que, tras descomprimirlo, lo enviará a dd que a su vez lo dejará, bit a bit, en el disco /dev/sda.

Por otro lado, en la máquina origen, ejecutamos:

dd if=/dev/sda | gzip | nc 192.168.0.3 2222

Con este comando, dd lee bit a bit el disco indicado, comprime lo leído y lo envía a través del puerto 2222 a la máquina indicada en la IP.

Al terminar los procesos, tendríamos una máquina destino que sería un clon perfecto de la máquina origen, hecho a través de la red. De hecho, hay que tener cuidado porque al finalizar el clonado la máquina destino tendrá incluso el mismo nombre de host y la misma IP que la máquina origen (si era IP estática), por lo que convendría cambiar estos parámetros desde el sistema de rescate antes del primer reinicio, bien ajustando los parámetros en los archivos correspondientes, bien haciendo un chroot a la partición de sistema clonada. Si lo que se estaba clonando era una partición de datos esto no es necesario, claro.

Ojo, porque este proceso de copia puede tardar mucho. En una red Gigabit se puede calcular unos 10GB/hora, por lo que clonar en red discos grandes puede llevar mucho tiempo.

Hace unos días tuvimos que abrirle a un proveedor externo acceso SSH a una máquina en producción, y queríamos controlar lo que hacían en la máquina. Puesto que SSH va sobre conexión cifrada no resulta tan sencillo guardar un log completo como en un login habitual. La solución, de mano de script.

El comando script simplemente guarda en un archivo todo lo que se hace en consola, tanto los comandos introducidos como su salida. Así, para mantener un log de lo que el usuario hacía en cada sesión SSH, basta con añadir un par de líneas al final de su archivo .bash_profile (en el home de cada usuario):

export PS1="[\t \u@\h \W]\$"
script -q /var/log/sessions/ssh-`date +%Y-%m-%d`-`whoami`-$$.log && exit

La primera de ellas añade información de la hora actual al prompt, de forma que al leer el log veamos en qué momento se ejecutó cada comando. La segunda línea lanza el comando script, con la opción silenciosa (-q) y almacenando los logs en un archivo apropiado. Este archivo estará en /var/log/sessions y su nombre estará formado por la fecha actual, el login del usuario y el PID del comando script. De esta forma tendremos fácilmente localizables los logs de cada día, y separados además por cada sesión. El comando exit al final es necesario para que la ejecución sea totalmente transparente, ya que script exije del comando exit para terminar su ejecución, por lo que si no se pone, cuando el usuario quisiera cerrar la sesión tendría que teclear exit dos veces, una para el comando script y otra para su sesión.

Ahora ya sólo es necesario crear y dar permisos al directorio de logs y empezar a guardar el registro:

# mkdir /var/log/sessions
# chmod a+w /var/log/sessions

Si se prevee que se van a crear nuevos usuarios en el futuro que también precisen de guardar un registro de sus sesiones SSH, basta con añadir esas dos mismas líneas a /etc/skel/.bash_profile.