tail -f | sysadmin

El lanzamiento de MySQL 5.1 GA ha sucitado un acalorado, aunque no sabemos qué tan útil, debate. En VivaLinux, comentan la controversia en torno al lanzamiento de la nueva versión GA (Generally Available) del DBMS Open Source más popular.

La nueva versión incluye una serie de características muy interesantes, entre las que se incluyen:

• Partitioning de tablas e índices
• Replicación basada en filas y mixta
• Job scheduler inluido
• Manejo de XML mejorado y soporte para XPath
• Nuevas utilidades de diagnóstico y medición de performance de SQL
• Retorno de la librería libmysqld

Sin embargo, el lanzamiento de la nueva versión fue duramente criticado por Michael “Monty” Widenius, fundador y desarrollador de MySQL, quien dice que hay una gran cantidad de bugs críticos que en la nueva versión no han sido corregidos. A este artículo respondió Sun con otro artículo defendiendo su postura.

Por mi parte, lejos estoy de poder ofrecer un juicio técnicamente significativo respecto de los temas en discusión. Sin embargo, más allá de la importancia de la apertura al debate de temas interesantes en el desarrollo de MySQL que espero que sirvan para mejorar el ya muy buen DBMS, no creo que esta discusión resulte muy conducente. Es que, entiendo, subyace un problema básico que experimentamos todos los desarrolladores en nuestra vida diaria, que es un problema estructural y sistémico. Se trata de la contraposición de intereses entre la empresa que recientemente compró MySQL, es decir Sun, y la gente involucrada en su desarrollo, o los trabajadores. Quienquiera que haya trabajado en desarrollo en una empresa de software conoce de primera mano el enfrentamiento entre los intereses del capital de sacar nuevos features a toda costa y los intereses de los desarrolladores, que conocen los bugs actuales, de robustecer un sistema cuyos agujeros de gruyere conocen como las palmas de sus manos.

El interés de Sun es más que evidente. Pongamos por caso que, uno de los nuevos features, es la separación de MySQL Cluster como un producto independiente. Esto va de la mano con un gran negocio de Sun que es vender la solución de cluster para MySQL, en la cual ofrecen hardware, sistema operativo y DBMS en un mismo paquete. De hecho, el mes pasado sacaron una interesante guía sobre cómo configurar MySQL en un cluster Solaris.

La discusión está abierta y, a pesar de mi escepticismo, esperemos que conduzca a algún lado. ¿Ustedes qué opinan?

Dando vueltas por internet me encontré este pequeño artículo donde explican una forma sencilla de usar mod_proxy para redireccionar peticiones de un servidor Apache a otro.

En realidad no llego a entender por qué el autor no utilizó una redirección a nivel DNS, pero supongo que habría razones para ello. De todas formas, es interesante reproducir su sencilla guía.

Por supuesto que esto implica tener el mod_proxy de Apache habilitado.

Luego en el servidor A (el que habría de proxy) es cuestión de introducir estas líneas en el httpd.conf:

ProxyPass / http://192.240.2.93/
ProxyPassReverse / http://192.240.2.93/
ProxyPreserveHost On

La primera línea redirige la petición del servidor A al B. La segunda indica que va a ser un proxy reverso, modificando las cabeceras HTTP Location, Content-Location y URI en la respuesta, para que ésta vuelva al cliente a través del servidor A. Por último, la tercera línea preservará la cabecera Host para hacer redirecciones basadas en el dominio. Esto es porque el caso que explica el artículo original, lo que se quería hacer es que las peticiones enviadas al dominio foo.com (que entendemos que resuelve la IP del servidor A) sean procesadas por el servidor B.

Y en el servidor B (el que va a procesar efectivamente los requests) configurar el virtual host correspondiente:

<virtualhost *:80>
ServerName foo.com
DocumentRoot /var/www/foo

<directory "/var/www/foo">
Order allow,deny
Allow from all
</directory>

ErrorLog /var/log/apache2/foo.err
CustomLog /var/log/apache2/foo.log combined
</virtualhost>

Revisando mi Google Reader me encontré con que varios blogs citaban un mismo artículo. Diez errores comunes de administradores de Linux que recién se inician en este mundo. No viene mal revisarlos, para asegurarnos de seguir buenas prácticas, aunque son realmente muy básicos.

1. Instalar aplicaciones de varios tipos (.DEB, .RPM, .TGZ, etc.)
2. Ignorar las actualizaciones de los paquetes de software instalados.
3. Pobre elección para la contraseña del superusuario (root).
4. Evitar la línea de comando.
5. No conservar una copia del anterior Kernel funcional.
6. No resguardar los archivos de configuración críticos.
7. Arrancar un servidor con X.
8. No entender los permisos de los usuarios en el sistema de archivos.
9. Ingresar directamente como el superusuario.
10. Ignorar los archivos .log

Lugares donde he visto el post: VivaLinux, Linux, Java y Programación y, el artículo original en TechRepublic.

Anoche me puse a jugar un rato con un VPS porque tenía ganas de instalar lighttpd (AKA lighty) junto con Apache, de manera de montar un escenario similar al que proponía Cesar hace un tiempo en el blog del Web & Beer. Según lo que comenta ese artículo, Lighty es una opción muy interesante para montar proxies que distribuyan automáticamente la carga entre distintos webservers para servir contenidos de distinto tipo (básicamente distinguiendo entre estático y dinámico).

Por lo tanto, me puse a jugar un poco en este VPS para montar en él un lighty y un Apache, el primero escuchando en el puerto 80 y el segundo en el 8080. El primero va a ser el que reciba los requests y sirva el contenido estático y el segundo el que procese los requests de contenido dinámico (php). Como dije, esto fue más que nada un juego, porque el proyecto para el que lo voy a implementar no lo amerita y de hecho quizás poner un proxy en un servidor solo (no como balanceador de distintos nodos, sino balancenado la carga internamente) probablemente no se justifique. Pero valió la pena para meterme un poco en el tema de lighty y armar una pequeña guía de instalación.

En este caso, por culpa del VPS, tuve que trabajar con CentOS (hubiera preferido Slackware, pero es lo que había). Sin embargo, procuré hacer la instalación compilando todo yo mismo, porque me resulta más entretenido y creo que da mejores resultados.

Instalación de Lighttpd

La instalación de lighttpd es bastante sencilla e intuitiva para cualquiera que haya compilado e instalado Apache o cualquier otro servidor en Linux.

En primer lugar, lógicamente, hay que descargar el software de la web oficial: http://www.lighttpd.net/download. A mi me gusta hacer esto en el directorio /usr/src.

# cd /usr/src
# wget http://www.lighttpd.net/download/lighttpd-1.4.20.tar.gz
# tar zxvf lighttpd-1.4.20.tar.gz
# cd lighttpd-1.4.20

Luego, suponiendo que tenemos instaladas las librerías que podamos llegar a necesitar (glib2, openssl, libpcre), pasamos a configurar y compilar. Si no tenemos las librerías podemos ir descargandolas de sus sitios oficiales y compilándolas, o instalarlas con yum.

Yo utilicé el siguiente configure para mi Lighty:

./configure \
    --prefix=/usr \
    --exec-prefix=/usr \
    --bindir=/usr/bin \
    --sbindir=/usr/sbin \
    --sysconfdir=/etc/lighttpd\
    --datadir=/usr/share \
    --includedir=/usr/include \
    --libdir=/usr/lib \
    --libexecdir=/usr/libexec \
    --localstatedir=/var \
    --sharedstatedir=/usr/com \
    --mandir=/usr/share/man \
    --infodir=/usr/share/info \
    --with-openssl

Luego compilamos e instalamos:

# make && make install

Ahora debemos crear el usuario con el que va a correr nuestro Lighty.

# adduser -m -d /var/www -s /sbin/nologin lighttpd

Creamos algunos directorios adicionales para ubicar los distintos archivos de logs y configuración.

# mkdir -p /etc/lighttpd
# mkdir -p /var/log/lighttpd
# chown -R lighttpd:lighttpd /var/log/lighttpd

Ahora vamos a crear nuestro archivo de configuración. Yo utilice uno de la guía en la que me basé para hacer esta otra guía y lo modifiqué según lo que yo necesitaba, para incorporar la configuración del proxy. También se pueden ver ejemplos en la página oficial del Lighttpd. Notese que lighttpd no instala un archivo de configuración por default, como sí lo hace Apache, porque casi sin configuración puede funcionar. De hecho en la página de Lighttpd se observa una configuración muy básica para un servidor de contenido estático en 8 líneas.

# cd /etc/lighttpd
# wget http://www.tail-f.com.ar/files/lighttpd.conf.txt
# mv lighttpd.conf.txt lighttpd.conf
# chown lighttpd:lighttpd lighttpd.conf
# vi lighttpd.conf

Teniendo la configuración de Lighty tal como la queremos, pasamos a copiar el script a nuestra carpeta /etc/init.d. Esta sería la parte del a guía más dependiente de la plataforma. Aquí también partí de un script que encontré en la misma guía y le saqué algunas cosas de unos módulos que yo no iba a utilizar.

Pueden descargar mi versión de aquí, pero lo que tenemos que destacar, son las siguientes líneas.

## Proxy
proxy.server = (".php" => ((
                                "host" => "127.0.0.1",
                                "port" => 8080
                          )),
                ".css" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".jpg" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".gif" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".png" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".flv" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".js" => ((
                                "host" => "127.0.0.1",
                                "port" => 80
                          )),
                ".swf" => ((
                                "host" => "127.0.0.1",
                                "port" => 80

# --- stripped ---- #
## bind to port (default: 80)
server.port                = 80

En esas líneas vemos que se define un proxy, que de acuerdo a las extensiones de los archivos va a mandar los requests a una destinación u otra. En este caso, que solamente tenemos una máquina, los archivos .php se envían al puerto 8080, donde tendremos el Apache, y los demás al puerto 80 que es donde escuchará Lighty. Luego, al final vemos, justamente, la configuración para que Lighty bindee con el puerto 80.

# cd /etc/init.d
# wget http://www.tail-f.com.ar/files/lighttpd.init.txt
# mv lighttpd.init.txt lighttpd
# chmod +x lighttpd
# chkconfig --add lighttpd
# chkconfig lighttpd on

Y por último, estamos listos para iniciar nuestro nuevo servicio.

# service lighttpd start

Fuente: NixCraft.

Instalación de Apache

Vamos a ir, por último, a la instalación de Apache 2.2. Esto es bastante más estándar y, como el post está dedicado más que nada a Lighty, solamente voy a dejar mi configure y los pasos de instalación sin demasiada explicación.

Descargamos el Apache del sitio oficial y lo configuramos.

# cd /usr/src
# wget http://apache.dattatec.com/httpd/httpd-2.2.10.tar.bz2
# tar jxvf httpd-2.2.10.tar.bz2
# cd httpd-2.2.10

Esta es la configuración que elegí yo, basado en gran parte en la que viene por default con Directadmin.

# ./configure \
        --prefix=/usr \
        --exec-prefix=/usr \
        --bindir=/usr/bin \
        --sbindir=/usr/sbin \
        --sysconfdir=/etc/httpd/conf \
        --datadir=/usr/share \
        --includedir=/usr/include \
        --libdir=/usr/lib \
        --libexecdir=/usr/libexec \
        --localstatedir=/var \
        --sharedstatedir=/usr/com \
        --mandir=/usr/share/man \
        --infodir=/usr/share/info \
        --enable-so \
        --enable-dav \
        --enable-dav-fs \
        --enable-dav-lock \
        --enable-suexec \
        --enable-deflate \
        --enable-unique-id \
        --with-suexec-caller=apache \
        --with-suexec-docroot=/ \
        --with-suexec-gidmin=100 \
        --with-suexec-logfile=/var/log/httpd/suexec_log \
        --with-suexec-uidmin=100 \
        --with-suexec-userdir=public_html \
        --with-suexec-bin=/usr/sbin/suexec \
        --with-included-apr \
        --with-pcre=/usr/local \
        --includedir=/usr/include/apache \
        --libexecdir=/usr/lib/apache \
        --datadir=/var/www \
        --localstatedir=/var \
        --enable-logio \
        --enable-ssl \
        --enable-rewrite \
        --with-ssl=/usr \
        --enable-headers \
        --enable-expires

Luego compilamos e instalamos.

# make && make install

En este punto yo decidí crear un usuario httpd para el Apache, y luego ponerle a la carpeta /var/www como dueño al usuario lighttpd y como grupo httpd.

# adduser -m -d /var/www -s /sbin/nologin httpd
# chown -R lighttpd:httpd /var/www
# chmod -R 770 /var/www

Luego hay que editar la configuración de Apache, fundamentalmente para decirle que escuche en el puerto 8080. A continuación algunos elementos importantes de la configuración.

Listen 8080
User httpd
Group httpd
ServerName localhost:8080
ErrorLog "/var/log/httpd/error.log"
CustomLog "/var/log/httpd/access.log" common

Por último, hay que instalar el script en el /etc/init.d (yo obtuve el mío de otro servidor, pero en Google debe haber varias versiones, porque es algo muy común). Luego hay que darle los permisos de ejecusión, ejecutar el chkconfig como con Lighty, e iniciar el servicio.

# service httpd start

Luego sobre el mismo servidor instalé PHP y MySQL, pero no me quiero extender sobre la configuración de esos servicios para no desvirtuar este post. En todo caso, en un futuro, publicaré mi configuración habitual de PHP para quienes estén interesados.

Me da cierta vergüenza tener que publicar este artículo por las tecnologías de las que voy a hablar: FrontPage y Apache 1.3. Pero entenderán que son cosas que aún se usan y cada tanto nos vemos obligados a lidiar con ellas.

Las extensiones de FrontPage son básicamente una serie de scripts que corren del lado del servidor y que, como su nombre lo indica, extienden la funcionalidad del FrontPage. A pesar de ser un producto de Microsoft, es compatible con Apache.

El tema es que, al menos en Directadmin, solamente es compatible con Apache 1.3. Según entiendo, las extensiones en sí se pueden instalar con Apache 2.x, pero el Directadmin solamente las soporta cuando se usa la versión 1.3.

Ahora bien, esta instalación no vamos a poder realizarla con Custombuild, sino que tenemos que recurrir al más antiguo CustomApache. Entonces los pasos serían los siguientes:

Descargar e instalar CustomApache:

cd /usr/local/directadmin
mkdir customapache
cd customapache
wget http://files.directadmin.com/services/customapache/build
chmod 755 build
./build update

Lo más sencillo ahora sería ejecutar build all, que va a instalar el Apache y las extensiones:

./build all

Si por alguna razón no se quiere compilar e instalar todo, se puede compilar Apache con:

./build apache_mod_ssl

Y luego habría que instalar las extensiones:

./build mod_frontpage

Por último, y esto es muy importante, hace falta habilitar las extensiones para que Directadmin muestre el correspondiente menú. Para ello es necesario editar el archivo /usr/local/directadmin/conf/directadmin.conf y poner el parámetro frontpage_on en 1.

frontpage_on=1

Luego se reinicia el servicio del Directadmin y listo:

service directadmin restart