Renombrar todas las tablas de MySQL para cambiar lower_case_table_names

En ocasiones es necesario cambiar el lower_case_table_names para mantener compatibilidad de aplicaciones ejecutándose en Windows o en Linux. Si las bases de datos ya residen en el servidor Linux, antes de cambiar este parámetro a 1 (para compatibilizarlo con Windows), hay que renombrarlas todas para que estén en minúsculas. Este pequeño snippet puede servir de ayuda para hacerlo:

#!/bin/bash

for i in $(mysql -NB -e 'show databases'); do
        if [ $i == 'mysql' -o $i == 'information_schema' ]; then
                continue;
        fi
        echo "DB: $i"
        for j in $(mysql -NB -e "show tables from $i"); do
                lower=$(echo $j | tr [[:upper:]] [[:lower:]])
                if [ "$lower" == "$j" ]; then
                        continue;
                fi
                echo "$j -> $lower"
                mysql -e "RENAME TABLE $j to $lower" $i
        done
done

Nice quote

"Count on it, if someone finds out you are building a robot they will ask why and what will it do. Almost no matter what you say it will do, it will leave them cold. It will never do enough to meet their movie expectations. Plus they don’t, for the most part, understand the why of building a robot. You and I do because we want to create and explore and we like the challenge."

-- http://www.seattlerobotics.org/encoder/sep98/dougl.html

Que encienda un led el que no se haya sentido así alguna vez.

Sobre patinazos

Ayer tuve un patinazo gordo en el curro, lo que provocó quejas casi instantáneas de montones de clientes. Aprendí a fuego dos lecciones, una que no conocía y otra que sí, pero que por relajación no tuve en cuenta:

• La diferencia entre array_merge y $arr1 + $arr2, y cómo se tratan los índices numéricos del array resultante. Si tu código depende del valor de los índices la has cagado dependiendo de cuál de las dos opciones uses.
  
• Como en el fútbol, no hay cambio pequeño. Aunque sea un cambio que ocupe tres malditas líneas la puedes meter hasta el fondo. Tan hasta el fondo que los de Nueva Zelanda te huelan el tufillo del pie.
  

Espero que no vuelva a pasar. Sino, me veré obligado a retorcerme los testículos con alguna herramienta metálica.

Errores de GPG con apt/aptitude

Hoy me he encontrado con un pequeño problemilla al hacer un aptitude update en un sistema que tengo con Debian Sarge. El caso es que me daba unos "warnings" relacionados con las claves públicas que ahora son obligatorias para los paquetes, las cuales yo no tenía descargadas:

W: GPG error: http://security.debian.org sarge/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY A70DAF536070D3A1

Según he visto en amazing-development, se puede hacer a manosi no tienes las claves públicas de los empaquetadores. Los pasos son bastante sencillos.

Primero, nos bajamos la clave pública a partir del identificador de la clave que aptitude no encuentra (lo que va detrás del NO_PUBKEY):


$ gpg --keyserver hkp://wwwkeys.eu.pgp.net --recv-keys 00CB25206E825E4E A70DAF536070D3A1

como parámetro le podemos pasar todos los identificadores que nos han fallado.

Después importamos estas claves públicas desde GnuPG al keyring de Debian:


$ gpg --armor --export A70DAF536070D3A1 B5D0C804ADB11277 | apt-key add -


Y ya podemos hacer el aptitude update sin que nos de ningún aviso más.

Transpirenaica 07

Este Agosto, del 15 al 19 he hecho una ruta transpirenaica con un colega. El viaje ha sido guapísimo: las carreteras, los paisajes, el buen rollito... Podéis ver las fotos que hice en picasa.

Cambios en shorewall 3.0

Una rápida. En shorewall 3.0 han modificado la manera de especificar las reglas del firewall en /etc/shorewall/rules. Donde dije:

AllowSSH    net:$MI_IP    fw

Ahora digo:

SSH/ACCEPT    net:$MI_IP    fw

Han cambiado /usr/share/shorewall/action.* por /usr/share/shorewall/macro.*. Antes utilizando el sistema de actions sólo podías hacer el Allow, mientras que con las macros le puedes pasar el parámetro de la acción a ejecutar (ACCEPT, REJECT, etc), bastante más flexible.

Hosting virtual masivo a medias

En Apache es posible configurar de manera muy fácil el hosting virtual masivo de manera general a nivel de servidor, pero hay un caso con el que me he encontrado que no se especifica y que paso a describir:

Tenemos una sola máquina con una sóla dirección IP y muchos nombres de máquina apuntando a ella. Podemos montar de manera muy fácil un hosting virtual masivo, con las mismas configuraciones para todos los dominios. Este caso es diferente, ya que necesitamos tratar uno de los dominios de manera especial, puesto que ese tiene muchas más visitas que los demás y queríamos dividir el log de apache en dos: uno para el dominio gordo y otro para los otros más pequeñitos.

Conseguir esto en Apache 1.3 me llevó un par de tardes, pero al final lo conseguí con una configuración similar a estas (parece una chorrada, pero cuando me encontré con ello no vi ni un sólo ejemplo por ningún sitio):

NameVirtualHost ip_del_server
ServerName nombre_oficial

<VirtualHost>
   VirtualDocumentRoot /var/www/sitios/%0
   CustomLog /var/log/apache/log_pequeñito combined
</VirtualHost>

<VirtualHost>
   ServerName www.gordo.com
   DocumentRoot /var/www/docroot/
  CustomLog /var/log/apache/log_gordo combined
</VirtualHost>

La idea aquí es aislar dos configuraciones, una para el dominio gordo y la otra, que será común para el resto de dominios. Para que funcione es necesario que la definición del hosting masivo esté la primera, ya que la primera definición la pilla como default y van todas las peticiones a ese host (siempre y cuando no haya definido otro VirtualHost cuyo ServerName coincida con la petición).

Así, si viene una petición a www.gordo.com, ésta seguirá las configuraciones de su host virtual. En cualquier otro caso se utilizará la configuración del hosting masivo.