Tag apache - Userlinux.net

¡Menuda combinación!. A decir verdad empecé jugando un poco con el maldito slowloris y al final acabé montando este batiburrillo de servidores, primero para paliar el efecto del dichoso gusano y segundo para preparar el servidor para la inminente nueva versión del blog - que me gustaría estrenar con el décimo aniversario de este humilde rinconcito -.

En un esquema inicial analógico de esos que tantos nos gustan podemos ver la pirula (pido perdón de antemano por la calidad de la foto):

Llevo desde el fin de semana con la mosca detrás de la oreja. Uno de los servidores que administro ha visto incrementada de forma inexperada su carga media de CPU sin motivo aparente. Donde el load average normal de 1 minuto variaba entre 0.40 y 0.80 de repente suponía cargas tan elevadas como 60 o 100 unidades.

En esos momentos puntuales que llegaban a dejar la máquina zombie el proceso que abarcaba un consumo de entre el 60% y el 90% de CPU era apache2. Intrigante que ni error.log ni slow-queries.log de MySQL (lo que normalmente suele ser cuello de botella) dieran ninguna pista.

Mi predilección por Mercurial ha quedado patente en algún que otro post, así que una vez estamos conforme con nuestro servidor de versiones llega el momento de dar un paso más. Intentaremos configurar un interfaz web para mostrar el código a todo el mundo (una especie de Trac solo para código y adaptado a Mercurial).

El proceso es tan sencillo como crear otro VirtualHost en tu Apache con unas características un poco especiales porque en vez de tirar de archivos dinámicos (.php, .asp…) vamos a tirar de un cgi en Python, así que la configuración sería algo así:

Un servidor en el que se había instalado una OVH Release2 Group Manager (o algo así), los clientes no eran capaces de acceder al puerto 80 de Apache, todas las redirecciones se hacían al 443 por SSL. Me encuentro con esto en la configuración por defecto de Apache2:

# Forcing https
RewriteEngine On
RewriteRule ^(.*) https://%{SERVER_NAME}$1

Configuraciones por defecto... ¡Yo os maldigo! (por si no hace efecto el hechizo, decir que tengo un amigo brujo nivel 50).

Hablando de mod_rewrite siempre saltan las dudas, normalmente lo más problemático suelen ser las expresiones regulares así que he decidido reunir en una entrada toda la información que he recolectado sobre el tema.

Empiezo por dos cheatsheets que deberían ser un musthave para cualquier sysadmin, aquí las dejo para descarga y/o visualización:

• Cheat 1
• Cheat 2

Nota: Post en actualización constante, se irán tanto agregando nuevos ejemplos como features que se vayan usando.

Si alguna vez estás sirviendo un comprimido -pongamos un rar- y Apache lo muestra como texto plano (Content-Type: text/plain) -en lugar de darlo a descargar- lo único que debes hacer es agregar esta linea a tu fichero de configuración:

AddType application/x-rar .rar

Según parece el comportamiento de Apache por defecto para los archivos rar dista mucho de ser el correcto. Hacemos un restart y hasta luego Lucas.

Mucha gente se ha quejado últimamente de los themes de DokuWiki que tengo para descargar. La descripción general del error era que el archivo estaba corrupto y no se podía descomprimir y -por ende- era imposible de instalar.

Mis primeras reacciones echaban la culpa a Windows (err#1), puesto que los archivos están en tar.gz y no sabía si un herramienta normal de Windows como Winzip, Winrar o similares eran capaces de entender dicho formato. Sabía que 7zip era capaz y mis recomendaciones se encaminaron por ahí (err#2)

Las insistencias me hicieron ver que estaba equivocado. El problema real tenía que ver con el mod_deflate del servidor. Dicho módulo de Apache se encarga de comprimir ciertos contenidos para consumir menos ancho de banda entre cliente y servidor y -a costa de unos ciclos de cpu- servir páginas a mayor velocidad.

Dependiendo del IDE (o lo que sea) que usemos para programar es posible que él mismo se encargue de hacer copias de seguridad de forma automática cada X tiempo. Algunos tienen la mala costumbre de renombrar los archivos que estamos editando y agregarle el siempre molesto "~" a la extensión, con lo que un config.php pasaría a ser config.php~ y ya la hemos liado.

¿Por qué?, básicamente porque -por defecto- Apache no tiene capacidad de procesar los archivos .php~ con lo que su comportamiento -por defecto- es enseñar el código fuente de dicho archivo. Una de las posibles soluciones:

<FilesMatch ".php~">
	Order allow,deny
	Deny from all
</FilesMatch>

Hecho ésto en el VirtualHost correspondiente obtendremos un bonito Forbidden (403) indicando al presunto malhechor que el archivo existe pero, en cierto modo, nos hemos preocupado de corregirlo.

Hace un rato me ha dado por jugar con Apache2 en una máquina de pruebas. Intentando modificar ciertas páginas PHP he encontrado un problema de codificación de texto, tanto en acentos como en eñes salían caracteres raros, por lo que pensé si sería problema de la actualización de Apache. Así que haciendo una búsqueda en apache2.conf por 'charset' topé con lo siguiente: