Hello world! – mudanza

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

O eso es lo que reza el post por defecto que te mete WordPress en cada nueva instalación.

Si, nueva instalación. Después de n años arrastrando un WordPress-mu 2.x y aprovechando un cambio de servidor, me he decidido a migrar a WordPress 3. Así que cambio de servidor y de software… va a petar todo. O más. Se va a cagar la perra.

Ya iré arreglando cosas poco a poco, instalando plugins, temas, acabando de configurar, migrando ficheros que no se hayan copiado bien y demás. Pero es que si no me tiro a la piscina a lo bestia, no lo hago. Y más con lo dejado que tengo esto últimamente, a ver si así lo retomo.

Además y aprovechando el nuevo servidor he montado un mirror de esto. :-)

tinydns por dominios

  • english
  • spanish

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?

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/*~

Pasar URL a minúsculas con nginx

  • english
  • spanish

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.

Parche para autenticar nginx con Amazon S3

Vuelvo tras el paréntesis del CCNA (4 módulos aprobados, sólo me falta el examen final de certificación) con algo que he estado haciendo esta semana en el curro: un parche poder usar la autenticación de S3 al hacer de proxy con nginx.

En el curro estamos montando una arquitectura de servidores con EC2, S3 y ELB: los EC2 están distribuidos por capas, con servidores nginx (web y proxy) delante de los servidores de aplicaciones Tomcat, y aparte en S3 tenemos todo el material “pesado” (fotos, vídeos, descargas, etc.) Como nginx puede hacer de proxy, en lugar de mandar a los usuarios directamente a S3 hacemos de proxy y mapeamos el contenido en nuestro propio dominio, con lo que además nos ahorramos unas pelillas (S3 aparte de por ancho de banda y espacio ocupado, cobra por número de conexiones).

El problema viene porque tenemos una gran mayoría de archivos que son públicos (imágenes, iconos y otros elementos del diseño y archivos multimedia) y otros que sólo queremos que los puedan descargar los usuarios registrados en la página. Un paso hacia la solución es usar el parche Secure Download, que genera URL que expiran tras unos minutos con lo que los elementos privados estarían asegurados, pero sólo a través de nuestra página. Si alguien descubre el nombre de nuestro bucket y el esquema de URL (y no es muy complicado….) podría descargar cualquier cosa directamente de S3.

Con este parche se puede acabar de securizar las descargas: se hacen privadas en el bucket de S3, de forma que sólo autenticándose puedan descargarse (el usuario final ya no podría descargarlas aunque averigüe la URL), y nginx si que puede acceder autenticándose a la vez que protege en local las URL con el Secure Download.

El parche está disponible aquí: nginx proxy – Amazon S3 autentication

Safari AdBlocker, compatible 64bits

Por fin, ¡¡¡un bloqueador de publicidad que funciona en Snow Leopard a 64 bits!!! Con el paso a 64 bits muchos plugins para Safari dejaron de funcionar, entre otros todos los de bloqueo de publicidad.

Acabo de dar por casualidad con uno que funciona: el Safari AdBlocker, un fork basado en SIMBL del SafariBlock compatible con las suscripciones para AdBlock Plus.

¡Muy recomendable!

Google, reinventando Internet III: el DNS

Después de dar alternativas a los protocolos SMTP (Wave) y HTTP (SPDY), le ha tocado el turno al otro caballo de batalla de Internet: el DNS. Mucha gente no le da a este protocolo la importancia que se merece, pero muchas páginas que tienen problemas de rendimiento son por culpa de una mala gestión del DNS, suya o del dominio de algún elemento que tengan en la página (publicidad sobre todo).

Google ha anunciado en su blog oficial la disponibilidad de su nuevo servidor de DNS público. Esta vez no han inventado un nuevo protocolo, simplemente han añadido a su servidor una serie de optimizaciones como gestión compartida de caché entre todo el cluster (que a saber lo grande que es, con lo que va a estar cacheado ¿todo?) y pre-fetching, amén de unas cuantas medidas de seguridad para prevenir ataques DoS y de envenenamiento de cachés.

Esta vez no hay código, parece ser que esto es sólo un servicio gestionado. Las IPs de los DNS de Google son:

  • 8.8.8.8
  • 8.8.4.4

Puede ser una buena alternativa al DNS de tu ISP (la mitad hacen aguas) o a OpenDNS, que se granjeó bastantes enemistades cuando empezaron a redirigir el tráfico de dominios que no existían (y curiosamente, el de Google también) a páginas suyas. Por supuesto, esto va a levantar otra oleada de opiniones anti-Gran-Google-Hermano: si usas el servidor de DNS de Google, van a saber todos los dominios que visites. No cada página individual, pero si cada dominio. Y es que como (¿casi?) todo lo que hace Google, parece que tiene la doble intención de conseguir más y más información sobre los hábitos de los usuarios en Internet para afinar aún más su maquinaria de AdWords/AdSense.

Manifiesto “En defensa de los derechos fundamentales en internet”

Ante la inclusión en el Anteproyecto de Ley de Economía sostenible de modificaciones legislativas que afectan al libre ejercicio de las libertades de expresión, información y el derecho de acceso a la cultura a través de Internet, los periodistas, bloggers, usuarios, profesionales y creadores de internet manifestamos nuestra firme oposición al proyecto, y declaramos que…

1.- Los derechos de autor no pueden situarse por encima de los derechos fundamentales de los ciudadanos, como el derecho a la privacidad, a la seguridad, a la presunción de inocencia, a la tutela judicial efectiva y a la libertad de expresión.

2.- La suspensión de derechos fundamentales es y debe seguir siendo competencia exclusiva del poder judicial. Ni un cierre sin sentencia. Este anteproyecto, en contra de lo establecido en el artículo 20.5 de la Constitución, pone en manos de un órgano no judicial -un organismo dependiente del ministerio de Cultura-, la potestad de impedir a los ciudadanos españoles el acceso a cualquier página web.

3.- La nueva legislación creará inseguridad jurídica en todo el sector tecnológico español, perjudicando uno de los pocos campos de desarrollo y futuro de nuestra economía, entorpeciendo la creación de empresas, introduciendo trabas a la libre competencia y ralentizando su proyección internacional.

4.- La nueva legislación propuesta amenaza a los nuevos creadores y entorpece la creación cultural. Con Internet y los sucesivos avances tecnológicos se ha democratizado extraordinariamente la creación y emisión de contenidos de todo tipo, que ya no provienen prevalentemente de las industrias culturales tradicionales, sino de multitud de fuentes diferentes.

5.- Los autores, como todos los trabajadores, tienen derecho a vivir de su trabajo con nuevas ideas creativas, modelos de negocio y actividades asociadas a sus creaciones. Intentar sostener con cambios legislativos a una industria obsoleta que no sabe adaptarse a este nuevo entorno no es ni justo ni realista. Si su modelo de negocio se basaba en el control de las copias de las obras y en Internet no es posible sin vulnerar derechos fundamentales, deberían buscar otro modelo.

6.- Consideramos que las industrias culturales necesitan para sobrevivir alternativas modernas, eficaces, creíbles y asequibles y que se adecuen a los nuevos usos sociales, en lugar de limitaciones tan desproporcionadas como ineficaces para el fin que dicen perseguir.

7.- Internet debe funcionar de forma libre y sin interferencias políticas auspiciadas por sectores que pretenden perpetuar obsoletos modelos de negocio e imposibilitar que el saber humano siga siendo libre.

8.- Exigimos que el Gobierno garantice por ley la neutralidad de la Red en España, ante cualquier presión que pueda producirse, como marco para el desarrollo de una economía sostenible y realista de cara al futuro.

9.- Proponemos una verdadera reforma del derecho de propiedad intelectual orientada a su fin: devolver a la sociedad el conocimiento, promover el dominio público y limitar los abusos de las entidades gestoras.
10.- En democracia las leyes y sus modificaciones deben aprobarse tras el oportuno debate público y habiendo consultado previamente a todas las partes implicadas. No es de recibo que se realicen cambios legislativos que afectan a derechos fundamentales en una ley no orgánica y que versa sobre otra materia.

Otras webs que se han unido al manifiesto.

nginx, memcached y HTTP 304

  • english
  • spanish

I’m working on the server architecture for a new web portal. It’s going to be Amazon-EC2based and will have a nginx front end to several tomcat back end servers. The nginx servers will proxy-cache some dynamic pages (search results, internal web-services queries) and will also have a static page cache based on memcached.

While starting to roll memcached into the solution I noticed that I stoped receiving HTTP 304 responses, everything served off memcached where 200. After digging a little bit on Google I found out it was the expected behavior as memcached doesn’t store the timestamp (last-modified) of the files. So I’ve given it a try and developed a quick patch. You can find it here.

I’m quite puzzled at the simplicity of the patch, as I didn’t need to code the logic to check if the cached page is more recent than the client’s one and return 302 or 200. After successfully returning the last-modified header from memcached, nginx seems to do the rest of the job somewhere on its own!

I have tested the patch today at work and everything seems to work OK. Will do more extensive testings tomorrow and update the path if needed. In the meantime, if someone gives it a try and works for them (or doesn’t), I’m waiting for your feedback.

Google, reinventando Internet

Primero fue Wave, que a mi modo de ver no es un intento de crear una red social ni de desbancar a Facebook ni a Twitter en lo suyo (aunque probablemente acabará/ía pasando), si no una forma de reinventar la comunicación en Internet: el principal medio de mensajería “serio” es el correo electrónico, y cualquiera que haya administrado un servidor estará de acuerdo conmigo en que el protocolo SMTP tiene problemas, MUCHOS problemas; Y luego está la mensajería instantánea, microblogging y demás. Para mi Wave es un intento de reinventar y unificar todas estas formas de comunicación en una sola, y además hacerla abierta, extensible y muy colaborativa. BTW, ¿a alguien le sobra alguna invitación para Wave? O:-) ¡Gracias, Luismi!

Y no contentos con reinventar el correo-IM-microblogging, ahora están jugando con un sustituto para el HTTP: el protocolo se llama SPDY y por lo visto ya tienen un servidor y una versión modificada de Chrome rulando, y en pruebas de laboratorio han visto mejoras de rendimiento del 50-60%. SPDY apunta a solventar problemas de latencias y mejorar el aprovechamiento de la conexión con medidas como no reenviar cabeceras HTTP (el equivalente) con cada GET, reaprovechar una única conexión TCP para enviar/recibir en paralelo varias peticiones en lugar de abrir una conexión TCP por cada elemento o pedir varios elementos en la misma sesión pero de forma secuencial, o permitir que el servidor inicie conexiones con el cliente para enviarle datos actualizados (bye-bye, AJAX). Suena bien.

Cambiar protocolos tan básicos que usa todo el mundo es difícil. Si no mirad cuántos años llevamos haciendo el paripé con IPv6. ¿Cómo se planifica la migración? ¿Se crean puentes entre el protocolo viejo y el nuevo para que durante el proceso haya interoperabilidad, o los primeros en migrar quedan aislados? Alternativas al SMTP hay más de una, pero ninguna ha fructificado. Sin embargo estoy convencido de que Google se va a llevar el gato al agua con Wave, y de aquí a unos (pocos) años el SMTP será un recuerdo del pasado. Y no me extrañaría que con SPDY acabara pasando lo mismo. Si hay alguien con recursos (mentes brillantes) y posición como para conseguir cambios así, es Google.

¿Qué será lo próximo? ¿IPvG?