$ firefox
Could not find compatible GRE between version 1.9.1.8 and 1.9.1.8.


Parece que Firefox anda buscando una versión de GRE que esté entre la 1.9.1.8 y la… 1.9.1.8. Vamos, que tiene que ser la 1.9.1.8 . El siguiente paso lógico sería buscar el paquete gre, pero el resultado es algo desalentador :

$ equery list gre
[ Searching for package 'gre' in all categories among: ]
* installed packages
[I--] [  ] sys-apps/grep-2.5.4-r1 (0)
[I--] [  ] x11-proto/bigreqsproto-1.1.0 (0)


También podemos probar con eix, pero el resultado es aun peor (me lo ahorro por la longitud de la salida). Sin embargo, tras hacer una búsqueda en /etc (un buen lugar para empezar a buscar), vemos que al menos tiene ficheros de configuración:

$ sudo find /etc/ -name 'gre*'
/etc/gre.d


Para los que venimos de Debian, el siguiente paso es consultar una guía de comparación de mandatos de gestores de paquetes, un recurso útil que nos da el equivalente a un dpkg -S y buscar a qué paquete pertenece ese fichero:

$ equery belongs /etc/gre.d/
[ Searching for file(s) /etc/gre.d in *... ]
net-libs/xulrunner-bin-1.8.1.19 (/etc/gre.d)
net-libs/xulrunner-1.9.1.8 (/etc/gre.d)


Sabiendo que xulrunner es nuestro sospechoso, basta con ver qué versiones hay disponibles:

$ eix xulrunner
[I] net-libs/xulrunner
Available versions:
(1.8)    1.8.1.19
(1.9)    *1.9.0.11-r1 1.9.0.14 1.9.1.6 1.9.1.8 1.9.2-r5 ~1.9.2.2-r1
{+alsa custom-optimization dbus debug elibc_FreeBSD gnome ipv6 java libnotify python sqlite startup-notification system-sqlite wifi xinerama}
Installed versions:  1.9.2-r5(1.9)


Y comprobar que la versión que queremos es la 1.9.1.8, estando instalada la 1.9.2-r5. Para bajar de versión, nada más fácil que enmascarar la que está instalada y volver a emergerla:

$ sudo echo "=net-libs/xulrunner-1.9.2.3-r1" >> /etc/portage/package.mask
$ sudo emerge xulrunner
$ firefox


Problema resuelto, y oye, siendo el primero de este estilo al que me enfrento por mi cuenta, sienta bien .

If you are an english speaker that arrived here by Google or similar, I’ll just resume the solution to you: Don’t use fucking mod_evasive with mod_dav_svn. Hope that helps

Si, es un nombre críptico de pelotas narices, pero es el que me gustaría haber encontrado a mi al principio de esta mañana, cuando por alguna razón mi configuración para acceder Subversion desde Apache ha empezado a dejar de funcionar correctamente.

Tras volverme loco durante toda la mañana, he descubierto el problema: una pequeña “incompatibilidad” entre mod_dav_svn y mod_evasive, un módulo que se me ocurrió probar con el fin de evitar ataques de denegación de servicio, y que no quiero saber qué otros efectos secundarios puede haber causado (¿bots de los buscadores en la lista negra?).

La cuestión ha comenzado cuando esta mañana he realizado una serie de operaciones masivas de Subversion (un refactoring de estos “gordos”) y de pronto la cosa ha empezado a fallar. A partir de ahí, la cosa ha ido degenerando y ha comenzado a fallar siempre. Tras volverme loco, “reiniciar” el repositorio, tirar las peticiones por un tunel SSH para evitar posibles proxies intermedios, y otras soluciones infructuosas, he optado por probar directamente en el servidor, de forma local. Al principio ha funcionado, así que he optado por instalar mediante backports una versión más moderna de subversion, para ver si había alguna incompatibilidad en ese sentido. Con el tiempo, ha dejado de funcionar en local también, por lo que he reinstalado las versiones originales de Subversion, sin éxito. Como es lógico yo no entendía nada.

Los errores que obtenía en el cliente eran:

svn: PROPFIND of '/': 403 Forbidden

Mientras que en el log de apache aparecía un mensaje

client denied by server configuration: /opt/websites/virtual host docroot

Que era lo que realmente me tenía fuera de juego: ¿Qué pintaba el docroot del virtualhost en el error, si todas las peticiones estaban entrando al location /, el cual estaba configurado como un DAV?

¿Qué estaba pasando? Dado que un simple svn list hace bastantes operaciones, mod_evasive estaba tomándolo como un “ataque”, bloqueando al cliente durante un tiempo. Por eso la cosa ha ido degenerando hasta que no funcionaba nada. El mensaje de error con el dichoso docroot debe ocurrir porque cuando mod_evasive pone a un cliente en su lista negra, ésta ya no llega a entrar en el DAV, y se considera el acceso fallido como un acceso al docroot. ¿Solución? No usar mod_evasive en conjunto con mod_dav_svn, o buscar una configuración del primero que funcione bien con el segundo (yo, escarmentado como estoy, lo dejo para otro día -aka nunca- ).
]]> http://blog.deigote.com/2010/03/03/svn-y-apache-403-forbidden-propfind-client-denied-by-server-configuration/feed/ 4