Archivo de la categoría: Linuxadas

tinydns por dominios

[spanish]Los que han trabajado conmigo saben que me gustan mucho los servidores de DJB. Creo que tanto qmail como djbdns son dos servidores estables como una roca en los que se puede confiar sin problemas. Pero hay mucha gente que simplemente no los entiende y los critica por cualquier motivo.

Por ejemplo, con el djbdns. He oído muchas veces la queja de que tener todos los dominios del tinydns en un único fichero de configuración (data) es un coñazo, cuando tienes muchos dominios (>50) la cosa se vuelve inmanejable. Eso prueba mi argumento de que esta gente no se entera de una de las ventajas de los programas de DJB: si, puedes editar los ficheros de configuración a mano, ¡pero lo bueno que tienen es que usan formatos simples fácilmente automatizables! ¿No quieres tener todos los dominios en un único fichero? Perfecto, sepáralos como te resulte más cómodo administrarlos y luego los vuelves a juntar antes de compilarlos.

El siguiente Makefile sirve precisamente para esto: en vez de trabajar con el «data» de toda la vida se crea un directorio «domains» donde se usa un fichero por dominio (el formato es el mismo), a partir de ese momento se usan estos ficheros y no el «data» para la administración. Al ejecutar make el makefile junta todos los ficheros de los dominios en el data y lo compila. Y si defines la IP o FQDN del servidor de backup en env/BACKUP, lo sincroniza. Fácil, ¿verdad?[/spanish]

[english]It’s no secret that I really like DJB‘s software. I think that qmail and djbdns are rock-solid pieces of software, something you can really rely on. But some people just don’t get them and bash them for whatever reasons.

Case in point, djbdns. Many a time I’ve heard the argument that having all tinydns’ domains in a single data file is a PITA. Well, that proves those people don’t get the point in DJB configuration files: you can edit them by hand, but their real power is that they’re easily scriptable! You don’t want having all the domains in a single file? Ok, split them and join them before compiling!

You can do this with the following makefile: split the domains, one per file on the «domains» directory, and work with those files, don’t ever touch the original «data» file again. And if you have a backup server put it’s IP address or FQDN on an env/BACKUP file. Then when you run «make» it will join all the files, compile them and sync the results with the backup server. Easy as pie, don’t you think?[/english]


all: data.cdb

data: domains/*[^bB][^aA][^kK~]
        cat $+ > data

data.cdb: data
        /usr/bin/tinydns-data
        [ -f ../env/BACKUP ] && rsync -azv * root@`cat ../env/BACKUP`:`pwd`

clean:
        -rm -f *~ domains/*~

Depurando problemas con nginx

[spanish]La semana pasada he estado pegándome con un problemilla que tenía con el nginx de mi blog: de vez en cuando se quedaba frito, no respondía a ningún request y tenía que reinciarlo. Hace tiempo que monté un script que se ejcutaba cada X minutos, comprobaba si se había quedado tostado y lo reiniciaba, pero esto no es una solución, sólo una ñapa termporal.

Como decía he estado unos días mirándolo con más detalle, y preguntando en la lista de correo de nginx. Un detalle importante que me dijeron allí es que el log de error se puede poner en modo «debug», que saca trazas bastante completas de lo que está haciendo cada proceso (con su PID) en cada paso del procesado de las requests: cabeceras, rewrites, proxies, cgis … todo.

error_log /var/log/nginx/$host-error.log debug;

Con esto, sabiendo el PID del proceso que está chungo, es muy fácil ver qué estaba haciendo en el momento que se ha quedado colgado. Y para juntar una cosa con la otra, el script que usaba para detectar los cuelgues, en el que añadí varias métricas como un netstat -nap (que saca el PID), un ps, vmstat, etc.:

#!/bin/sh

TIMEOUT=20
CHECK=http://localhost/wp-admin/
LOG=/var/log/checkWeb/checkWeb-$(date +%Y%m%d).log
LOGR=/var/log/checkWeb/restart-$(date +%Y%m%d).log
TMP=/tmp/checkWeb-$RANDOM

if ! wget -t 1 -o /dev/null -O /dev/nul -T $TIMEOUT $CHECK
then
echo "ERROR, reiniciando nginx"
echo "** REINICIANDO **" >> $TMP
date >> $TMP
echo "- CLOSE_WAIT:" >> $TMP
netstat -nap | grep -c CLOSE_WAIT >> $TMP
echo "- vmstat" >> $TMP
vmstat 1 5 >> $TMP
echo "- free" >> $TMP
free >> $TMP
echo "- ps" >> $TMP
ps aux >> $TMP
echo "- netstat" >> $TMP
netstat -nap >> $TMP
echo "" >> $TMP
echo "" >> $TMP

#       pkill -9 -f php-cgi
pkill -9 -f nginx
sleep 1s
/etc/init.d/nginx start

cat $TMP
cat $TMP >> $LOG
date >> $LOGR
fi

rm -rf $TMP

De esta forma, cada vez que localhost/wp-admin (estaba debuggeando un WordPress) no respondía, aparte de reiniciar nginx, me guardaba en un log bastante información sobre el sistema. Con el tiempo vi que siempre que se quedaba colgado, había varios procesos nginx con sockets en el estado CLOSE_WAIT. Con ese PID y el error.log de nginx en modo debug, vi que siempre que un proceso se quedaba colgado con sockets en CLOSE_WAIT, lo último que había estado sirviendo era lo mismo: en el blog tengo varios ejemplos de cómo ejecutar servidores con daemontools; daemontools utiliza «named pipes» (FIFO) en disco, que básicamente si no tienen un proceso alimentándolos, para el que los lee son un agujero negro; cuando nginx se ponía a servir uno de estos FIFO es cuando se quedaba frito.

Lo curioso es que no había tenido problemas ni con Apache ni con lighttpd. Aunque desde luego el problema es que esos FIFO no deberían estar ahí. Los quité y llevo más de cinco días sin cuelgues, cuando antes tenía 3-4 al día mínimo.[/spanish]

[english]Last week I’ve been debugging a problem I had with this site’s nginx server: from time to time it hanged and I had to restart the process. Some time ago I wrote a little script that checked if it was running OK and restarted it otherwise, but anyway that wasn’t a real solution.

So I spent some days really looking into it and asking for support and reporting my findings to the nginx mailing list. One useful tip I got there was enabling the «debug» mode on the error log, which shows full traces of the processes (including their PID) as they’re processing the request, the rewrites, upstreams, etc.

error_log /var/log/nginx/$host-error.log debug;

With this extended log and the PID of the process malfunctioning, it’s quite easy finding out what that process was doing right before hanging. In order to find out the PID of the hanged processes, I extended my check-reboot script to log some generic system metrics right before restarting nginx: netstat -nap (which shows the PID), ps, vmstat, etc.

#!/bin/sh

TIMEOUT=20
CHECK=http://localhost/wp-admin/
LOG=/var/log/checkWeb/checkWeb-$(date +%Y%m%d).log
LOGR=/var/log/checkWeb/restart-$(date +%Y%m%d).log
TMP=/tmp/checkWeb-$RANDOM

if ! wget -t 1 -o /dev/null -O /dev/nul -T $TIMEOUT $CHECK
then
echo "ERROR, restarting nginx"
echo "** RESTARTING **" >> $TMP
date >> $TMP
echo "- CLOSE_WAIT:" >> $TMP
netstat -nap | grep -c CLOSE_WAIT >> $TMP
echo "- vmstat" >> $TMP
vmstat 1 5 >> $TMP
echo "- free" >> $TMP
free >> $TMP
echo "- ps" >> $TMP
ps aux >> $TMP
echo "- netstat" >> $TMP
netstat -nap >> $TMP
echo "" >> $TMP
echo "" >> $TMP

#       pkill -9 -f php-cgi
pkill -9 -f nginx
sleep 1s
/etc/init.d/nginx start

cat $TMP
cat $TMP >> $LOG
date >> $LOGR
fi

rm -rf $TMP

This way, each time localhost/wp-admin was unresponsive (I was debugging a WP site), besides restarting nginx I was getting a lot of system info. With time I got to realize that nginx processes were not actually hanging, but some of their sockets got on the CLOSE_WAIT state forever until the process was restarted. Looking for the PID of those processes according to netstat on the error log, the last request they were processing before getting to the CLOSE_WAIT state was always the same: on my blog I have some examples of how running servers with daemontools; daemontools uses named pipes (FIFOs), which can become kind of black holes if there’s no process feeding them; when nginx hit one of these FIFOs, it hanged.

Funny thing is that I never had this problem with either Apache nor lighttpd. But anyway the problem is not nginx but those FIFOs which shouldn’t really be there. I removed them and have had no hanged processes in five days, while before this nginx was restarting 3-4 times a day.[/english]

find -empty,borrar directorios vacíos

[spanish]El comando find tiene una opción –empty que detecta directorios o ficheros vacíos (0 bytes). Esto se puede utilizar para borrar o localizar todos los ficheros o directorios vacíos en una ruta determinada:[/spanish]

[english]The find command has an –empty option which detects empty directories of files (0bytes). This is useful if you need to locate or remove empty directories or files from a directory structure:[/english]

find /path/ -type d -empty -exec rmdir {} ;
find /path/ -type f -empty

Pasar URL a minúsculas con nginx

[spanish]

Con nginx y el módulo de Perl embebido es posible reescribir/redirigir todas las visitas a URL en minúsculas añadiendo algo como esto a la configuración:

http {

	...
	perl_modules  perl/lib;

 	perl_set $uri_lowercase 'sub {
   		my $r = shift;
   		my $uri = $r->uri;
   		$uri = lc($uri);
   		return $uri;
 	}';
	...
}

server {
	...

	location / {
               if ( $uri != $uri_lowercase ) {
                       rewrite . http://$host$uri_lowercase;
               }
# or just:
#		rewrite . $uri_lowercase;
	}
	...
}

La primera opción (con el if y el http://$host) genera una redirección HTTP a la URL en minúscula si la URL que pide el cliente no está ya toda en minúscula. Me gusta más esta técnica ya que de alguna forma normaliza todas las URL a una forma canónica en minúsculas. La segunda opción (sin el if ni el http://) simplemente acepta cualquier URL y la reescribe internamente a minúsculas. Si previamente se renombran todos los ficheros y directorios a minúsculas se consigue un efecto «case insensitive» similar al de Windows.

Quiero dar las gracias al siguiente post de la lista de usuarios de nginx en el que me he inspiarado ;D para conseguir hacer esto. En efecto, la documentación y ejemplos del módulo de Perl de nginx son muy escasos. :-(

http://forum.nginx.org/read.php?2,39425,39944

De todas formas esta solución tiene dos problemas:

  • Hace falta el módulo de Perl que según los propios desarrolladores es experimental y puede tener memory leaks.
  • Aunque la redirección se hace en el location que esté el rewrite, el cálculo de la URL en minúscula al estar en la sección «http» de la configuración se hace para todas las peticiones que lleguen al servidor, haya que cambiarles la URL o no. Es decir, si tienes un servidor virtual con 10 dominios y sólo en una parte de uno de ellos es necesario reescribir las URL, aunque sólo se redirija el tráfico en ese caso, la URL en minúscula se calcula para todas las peticiones de todos los dominios.

Supongo que si en lugar de definir la variable en minúscula se escribiera una función Perl si que se podría restringir a un location determinado, tengo que mirarlo con más detenimiento aunque con la poca documentación que hay de esto la cosa está chunga. Otra opción es escribir un módulo en C que lo haga.

¿Y por qué querría alguien reescribir todas las URL a minúsculas? En el trabajo estamos migrando una aplicación Tomcat vieja desarrollada y que hasta ahora corría en un servidor Windows a Linux, y parece ser que los desarrolladores originales no prestaron nada de atención al tema de las mayúsculas y minúsculas en los nombres de ficheros y directorios, enlazando a veces bien los ficheros según mayúsculas y minúsculas pero otras veces no. Esto en Windows no es un problema, pero en Linux si que lo es. Así que lo que hemos hecho ha sido renombrarlo todo a minúsculas y configurar esta redirección a minúsculas en los servidores nginx que tenemos delante de la granja de Tomcats. Aún así todavía quedan algunos casos problemáticos aislados que han tenido que ser tratados uno a uno, como includes en los JSP a ficheros en mayúsculas (estos casos no «salen» al nginx si no que los trata internamente Tomcat, con lo que la redirección no se aplica), pero el grueso de los accesos a imágenes, videos, páginas HTML estáticas, etc. mal enlazados se ha solucionado de un plumazo sin tener que tocar el código.

[/spanish][english]

With nginx and its embedded Perl module it is possible to automatically rewrite/redirect every incoming request to a lowercase URL with something like this:

http {
	...
	perl_modules  perl/lib;

 	perl_set $uri_lowercase 'sub {
   		my $r = shift;
   		my $uri = $r->uri;
   		$uri = lc($uri);
   		return $uri;
 	}';
	...
}

server {
	...

	location / {
               if ( $uri != $uri_lowercase ) {
                       rewrite . http://$host$uri_lowercase;
               }
# or just:
#		rewrite . $uri_lowercase;
	}
	...
}

The first option (with the if and http://$host) sends an HTTP redirect to the lowercase URL if the requested URL is not completely in lowercase. I like this approach better as it kind of normalizes all URL to a canonical form. The second option (without if nor http://) just accepts any URL and internally rewrites them to lowercase: if you rename all your directories and files to lowercase, this will imitate Windows’ case-insensitive behaviour.

Kudos to the following post on the nginx users list were I draw the «inspiration» :D from to get this done. The embedded perl doc and examples are indeed scarce. :-(

http://forum.nginx.org/read.php?2,39425,39944

Anyway I see two problems in this approach:

  • you need the embedded perl module which according to the docs is experimental and can lead to memory leaks.
  • the actual redirection is done with the rewrite, which you can put on the location you need. But the URL lowercase calculation, being on the «http» section of the config, is done for each and every request arriving to your server. Say you have a virtual server with 10 domains and you only need this on one particular location of one of them. The lowercase URL is going to be calculated for every request of every domain.

I guess that by defining a perl function the URL calculation could be restricted to a particular location, have to look into it further. Another option is writing a C module.

And why would anybody want to rewrite every URL to lowercase? We’re migrating a legacy Tomcat-based application from Windows to Linux, and it seems the original developers were not «case-aware» at all, they mixed upper and lowercase in the filenames without regarding how the actual files were named. On Windows this is not a problem but when moving the app to Linux it is. So we have renamed every file and directory to lowercase and used the previous configuration on the nginx servers that load-balance our Tomcat farm. Some corner-cases remain (includes in JSP files, which don’t route back to the nginx server and are dealt internally by Tomcat) and have been dealt with one by one, but the bulk of wrongly addressed images, videos, links to HTML files, etc. now works.

[/english]