Rubén Ortiz » Apache 2.X

Apache – Mod Cache

Rubén Ortiz — Fri, 02 Oct 2009 09:43:44 +0000

Un mod de Apache del que todavía no había hablado es mod_cache. Mod_cache se utiliza sobretodo cuando se montan Apaches que sirven de proxy entre el servidor original y el cliente. Pero no tiene sólo esta utilidad.

Mod_deflate, es un mod de Apache que comprime los contenidos a costa de tiempo de la CPU. Pues bien, si habilitamos mod_deflate, Apache ha de estar comprimiendo continuamente los contenidos que se le requieren. Si usamos también mod_cache y alguno de sus submódulos (mod_disk_cache, mod_file_cache o mod_mem_cache) evitamos que ciertas cosas se recompriman porque Apache las sirve de la cache que ha generado.

Para habilitarlo, hemos de activar los módulos:

LoadModule cache_module modules/mod_cache.so LoadModule disk_cache_module modules/mod_disk_cache.so

El archivo de configuración sería así:


CacheRoot /var/cache/httpd/mod_disk_cache

CacheEnable disk /

CacheDirLevels 5

CacheDirLength 3

CacheRoot es el path a la carpeta donde se guarda la cache
CacheEnable disk / habilita el cacheo para todos los archivos
CacheDirLevels y CacheDirLength ordenan a Apache a crear N niveles de N profunidad en el path

Y por último, reiniciar Apache.

Luego, hemos de pensar que Apache y su mod_disk_cache, ocuparán espacio en disco. Podemos eliminarlo periódicamente con htcacheclean.

# /usr/sbin/htcacheclean -v -t -p/var/cache/httpd/mod_disk_cache -l64M Statistics: size limit 64.0M total size was 9.4M, total size now 9.4M total entries was 696, total entries now 696

Links

Invalid command ‘SetEnv’

Rubén Ortiz — Thu, 09 Jul 2009 09:56:22 +0000

El error era

perhaps misspelled or defined by a module not included in the server configuration

Y si, ese era el problema. El módulo env_module no estaba cargado desde la configuración.
LoadModule env_module modules/mod_env.so

Reiniciamos y a otra cosa.

Proteger carpetas con .htaccess y .htpasswd

Rubén Ortiz — Mon, 22 Jun 2009 14:16:33 +0000

Una forma básica de ofrecer seguridad sobre directorios web en Linux es utilizando las posibilidades que nos ofrece la apache.

.htaccess

Hemos de crear primero, un archivo llamado “.htaccess” y editarlo con las siguientes directivas:

AuthUserFile: path absoluto hasta el fichero .htpasswd
AuthName: contendrá el nombre del prompt o ventana que el usuario leerá al acceder al directorio protegido
AuthType: el tipo de autenticación
require user: los usuarios que podrán acceder al directorio protegido

Un ejemplo de .htaccess sería
AuthUserFile /path/absoluto/a/.htpasswd AuthName Acceso Restringido AuthType Basic require user prueba

Recordad que este archivo se ha de guardar en la carpeta donde queremos implementar la seguridad. Incluso podríamos llegar a bloquear el acceso a archivos, añadiendo debajo de esas líneas lo siguiente:

<\Files "index.html"> Require valid-user <\/Files>

.htpasswd

Este otro fichero, contiene el nombre del usuario y a continuación su password pero, encriptado. Para genera el archivo necesitamos, o bien acceso a nuestro apache para crear el password desde consola o bien, existen muchas webs que nos crean el texto del archivo .htpasswd, al entrar el nombre y el password que queremos.

Si tenemos acceso a la consola lo generamos nosotros mismos:

-bash-3.2# htpasswd -nb pepito pepote pepito:29.fNajst6GCU

para añadirlo al .htpasswd directamente, lo podemos redireccionar con el cat

-bash-3.2# htpasswd -nb pepito pepote >> .htpasswd

Sino, podemos buscar sitios en internet y luego editamos el fichero.

Si apache no te pide la autorización al acceder a la ventana, asegúrate de que lo tienes bien configurado.

Links
http://www.apacheweek.com/features/userauth
http://www.cristalab.com/tutoriales/proteger-carpetas-con-.htaccess-y-.htpasswd-c213l/
http://www.elated.com/articles/password-protecting-your-pages-with-htaccess/
http://chernando.eu/doc/apache/
http://www.colordeu.es/BLOG/proteger-carpetas-web-con-htaccess-y-htpasswd
http://readthefuckingmanual.net/error/1385/

Apache Server-Status not Found 404

Rubén Ortiz — Thu, 18 Jun 2009 13:55:37 +0000

Esto lo sospechaba por puro sentido común, pero no había dado con la forma de arreglarlo. Si decidimos activar el mod_status para Apache, hemos de acceder vía web a http://ip/server-status o http://dominio/server-status. El problema es que si en el dominio configurado tenemos reglas para .htaccess, el .htaccess interpretará la URL /server-status ocasionando que nos devuelva un 404. Para evitarlo hay que decirle que /server-status no es una URL para redireccionar. Editamos el .htaccess y añadimos:

RewriteCond %{REQUEST_URI} !=/server-status

Reiniciamos apache, y si todo está ok, deberíamos ver la información del mod.

Links

Quitar cabeceras ETag de Apache

Rubén Ortiz — Mon, 18 May 2009 09:55:18 +0000

Editamos el archivo de configuración de apache y añadimos:

Header unset ETag FileETag None

También lo podemos configurar con nuestro .htacccess. Reinciamos apache y listo. El motivo de hacerlo ya es entrar en discusión de ciertos factores.

Links

http://www.askapache.com/htaccess/apache-speed-etags.html

[client ::1] Directory index forbidden by Options directive: /var/www/html/

Rubén Ortiz — Thu, 04 Sep 2008 09:49:37 +0000

No es un errror grave, pero es el típico que te llena los logs de error de apache y la verdad, molesta. Lo que debemos hacer es crear un index.html dentro de la ruta que muestra el error.

# touch /var/www/html/index.html

http://www.howtoforge.com/forums/showthread.php?t=17144

Apache mod_expire. Expiración de contenidos web

Rubén Ortiz — Thu, 07 Aug 2008 10:01:50 +0000

Otra funcionalidad de apache. Se trata de mod_expire. Con mod_expire, podemos expresar el tiempo de expiración de un tipo de archivo (css,gif,png…etc). De esta manera, avisamos al navegador que ese contenido no va a cambiar en un determinado tiempo y no hace falta que lo vuelva a descargar.

En las instalaciones típicas de Apache 2.0.X el mod_expire, al igual que una legión de modulos, ya viene compilado y cargado en la configuración por defecto. Si tenemos dudas de si está o no, lo podemos comprobar con la extensión de Mozilla Firebug, YSlow. Utilizando esta extensión vemos la fecha de expiración de un archivo en concreto.

Primero, compilamos el modulo sino lo tenemos por defecto, utilizando apxs. Si no tenemos este binario, podemos instalarlo con

# yum install httpd-devel

Necesitamos el fichero .c del mod_expires, lo podemos bajar o copiar del paquete de httpd. Una vez lo tengamos todo, ejecutamos:

# /usr/local/apache/bin/apxs -i -a -c /root/httpd-2.2.6/modules/metadata/mod_expires.c

Se deja el módulo en la ubicación por defecto

# /usr/local/modules/mod_expires.so

Comprobamos en el fichero de configuración de apache, que se ha cargado la línea de configuración adecuada:

# LoadModule expires_module modules/mod_expires.so

Salvamos los cambios y reiniciamos apache

# /etc/init.d/httpd restart

Podemos utilizar mod_expires en diferentes contextos, pero seguiremos el ejemplo encontrado en Yukei.net, por comodidad, más que nada. Nos referimos a utilizar htaccess, con lo cual, explícitamente necesitamos mod_rewrite.

Vamos al directorio donde tenemos el contenido que queremos controlar por expiración y creamos el htaccess

# touch .htaccess

#joe .htaccess

Añadimos

ExpiresActive On ExpiresDefault "access plus 1 year"

o bien

Añadimos esto en el fichero httpd.conf de nuestro apache

ExpiresActive On ExpiresDefault "access plus 1 month"

Reiniciamos apache again

# /etc/init.d/httpd restart

Ahora, es cuando debemos comprobar con Yslow que nuestro contenido expira en el tiempo que nosotros hemosindicado. Para mod_expire hay dos directivas, ExpireDefault y ExpireByType. Son muy similares

ExpireDefault

ExpiresDefault "access plus 1 month" ExpiresDefault "access plus 4 weeks" ExpiresDefault "access plus 30 days"

ExpireByType

ExpiresByType text/html "access plus 1 month 15 days 2 hours" ExpiresByType image/gif "modification plus 5 hours 3 minutes"

Links:

http://www.yukei.net

http://mapopa.blogspot.com

http://httpd.apache.org/docs/2.0/mod/mod_expires.html

Apache. MaxClients y más…

Rubén Ortiz — Tue, 13 May 2008 08:45:42 +0000

Conocer la versión

Hay muchas maneras pero dejamos dos simples. Es necesario por motivos obvios, conocer la versión de apache instalada en nuestro sistema y el modo en el que ha sido compilado.

# httpd -v

Output:

-bash-3.1# Server version: Apache/2.2.3 -bash-3.1# Server built: Jan 15 2008 20:33:30

# httpd -l

Compiled in modules:

core.c
prefork.c
http_core.c
mod_so.c

De esta manera sabemos que estamos ante un servidor Apache / 2.2.3 y en modo prefork:

Prefork MPM: el modo prefork utiliza múltiples procesos hijo, cada proceso hijo se ocupa de una conexión a la vez. Prefork es muy adecuado para sistemas con doble CPU, la velocidad es comparable al del Worker MPM y es altamente tolerante con los fallos en los módulos y los procesos hijos colgados. Por contra, el uso de memoria es alto y cuanto más tráfico tenemos más memoria consume

Worker MPM: utiliza múltiples procesos hijo. Es multi-thread dentro de cada proceso hijo y cada thread se encarga de una conexión. Worker es más rápido y escalable y el uso de memoria es comparativamente bajo. Es también adecuado para múltiples procesadores. Worker es menos tolerante ante fallos de módulos y un fallo en un thread puede afectar a todos los threads de un proceso hijo.

Este Módulo de MultiProcesamiento (MPM) implementa un servidor híbrido multiproceso-multihebra. Usando hebras para atender peticiones, el servidor puede servir un mayor número de peticiones con menos recursos de sistema que un servidor basado únicamente en procesos. No obtante, se mantiene casi por completo la estabilidad de un servidor basado en procesos manteniendo la capacidad multiproceso, pudiendo cada proceso tener muchas hebras.

Directivas de Apache

MaxClients: es el número total de procesos hijo httpd que pueden ser procesados simultáneamente. El valor por defecto es bastante elevado para la mayoría de servidores (256). Cada proceso hijo es capaz de mapear (allocate) en memoria un número de información X. En Drupal, por ejemplo, cada proceso puede utilizar unos 10-15 Mb de memoria. 20 procesos, por 20MB de RAM cada uno, consume cerca de 500MB de memoria física. Cuando nos acercamos o llegamos al límite marcado, apache no devuelve un TimeOut inmediato, sino que coloca la petición en cola. Una aproximación racional al número adecuado para esta directiva podría ser la división de la cantidad total de RAM disponible (dejando una generosa cantidad para otros procesos) entre el máximo tamaño del proceso apache. Podemos saber el consumo de memoria de apache por proceso con el comando ps.

Lo fundamental para entender como gestionar la directiva MaxClients, es comprender que puede tener un valor “alto” sino nuestro servidor está sirviendo contenido estático, pero con aplicaciones modernas tipo PHP de contenido dinámico, podemos tener graves problemas de estabilidad si no calculamos bien el número total de MaxClients. Una fórmula para calcular el valor apropiado del MaxClients sería (hay muchas) la siguiente:

MaxClients = Total RAM dedicated to the web server / Max child process size

En un ejemplo práctico, tenemos una máquina virtual (OpenVZ) con 1Gb de RAM asignado. Después de averiguar el tamaño total del proceso apache, dividimos:

1 GB (1024 MB) / 2,3 MB = 445 MaxClients

Siempre pensando en un servidor que “sólo” ejecutara apache, obviamente, este valor es sólo un ejemplo. Nunca se debería asumir esa cantidad total de MaxClients. Lo mejor sería aumentar un poco el valor y comprobar el funcionamiento del servidor. Pero sería un buen punto de referencia.

StartServers: número de procesos iniciales.
MinSpareServers: número de procesos iniciales en iddle que esperan una petición.
MaxSpareServers: número máximo de procesos en iddle esperando.
MaxRequestsPerChild: cuando un proceso excede este valor, el proceso es destruido y, si es necesario, un nuevo proceso lo reemplaza. Esto puede reducir la memoria total usada en muchas situaciones, con los archivos dinámicos incrementando constantemente su uso de RAM y reiniciando los procesos para reducir su uso.
ServerLimit: si nosotros queremos aumentar el número total de MaxClients de 256 a 300, debemos en principio aumentar el ServerLimit a la misma cantidad. Sino, el apache se quejará mostrándolo por la salida estándar.
KeepAlive: por defecto está en off. Al estar on, permitimos a una misma conexión TCP hacer múltiples peticiones sin descartar la conexión (conexiones persistentes).
MaxKeepAliveRequests: el número total de peticiones permitidas por una misma conexión TCP.
KeepAliveTimeOut: el número máximo de segundos que permanecerá el proceso esperando a ser respondido.

Ejemplo configuración por defecto de Apache

# IfModule prefork.c StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 # IfModule # IfModule worker.c StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 # ifModule

Calcular memoria consumida por Apache

# ps -ylC httpd --sort:rss

–sort rss (lista ordenando por RSS(Resident Set Size), kb del proceso en memoria)

Output:

# S 48 5674 17426 0 75 0 2904 2637 277588 ? 00:00:00 httpd

2904 / 1024 = 2,8 MB ocupados por proceso de Apache. Ahora, debemos saber el número total de procesos:

# lsof -i | grep httpd | grep ESTABLISHED | wc -l

Output:

# 15

De este modo, tenemos que por proceso utilizamos 2,8 MB de memoria (no swap). Y sabemos que hay 15 procesos de apache en memoria, con lo cual 2,8 MB x 15 = 42 MB usados. Otra forma, quizá más fácil de calcular como está rindiendo nuestro apache, es utilizar este script escrito en python (gracias al admin de Devside ) Os dejo un output de lo que muestra el script:

Private + Shared = RAM used Program

84.0 KiB + 312.0 KiB = 396.0 KiB klogd
128.0 KiB + 452.0 KiB = 580.0 KiB syslogd
128.0 KiB + 524.0 KiB = 652.0 KiB init
824.0 KiB + 600.0 KiB = 1.4 MiB bash
568.0 KiB + 1.1 MiB = 1.6 MiB sftp-server
1.6 MiB + 1.9 MiB = 3.5 MiB sshd (3)
37.4 MiB + 2.1 MiB = 39.5 MiB httpd (180)

Optimización

No hablaremos de optimización totalmente pero, si comentaremos que una de las cosas que se recomiendan por toda la comunidad es deshabilitar los módulos de apache que no necesitemos. En el ejemplo que me ocupa, una máquina virtual de 1GB de RAM de OpenVZ, deshabilitamos de 52 procesos 35, dejando sólo activos 17. Volvimos a hacer el calculo de la memoria utilizada por apache entonces:

2,3 MB por proceso x 12 procesos = 33,6 MB! (22 % menos en memoria). No está mal.

Otro consejo que se da en todos los manuales de tunning de Apache, es el deshabilitar la resolución de DNS, HostnameLookups. Esta directiva intenta resolver cada IP conectada a tu servidor y eso genera un consumo de recursos innecesario.

Conexiones Persistentes

En sus inicios, el protocolo HTTP no permitía las conexiones persistentes, lo que significaba que era necesaria una conexión al servidor por cada archivo que tuviese que ser descargado. Esto era una manera ineficiente de hacer las cosas, especialmente desde que Internet comenzó a tener sitios webs con gran cantidad de archivos. ¿Por qué?:

Cada conexión requiere la carga de al menos, 3 paquetes para ser iniciada (SYN,SYN-ACK,ACK). Esto significa que al menos 3 viajes de ida y vuelta para abrir una conexión.
Dada la naturaleza de TCP, bajo protocolo HTTP, una conexión funciona más rápido cuanto más tiempo está “abierta”. El cerrar y abrir continuamente conexiones, no permite a HTTP utilizar su ancho de banda total.

Directivas de KeepAlive

KeepAlive: habilita o deshabilita las conexiones persistentes [ On - Off]
KeepAliveTimeout: cuanto tardará Apache, en segundos, después de que una petición haya sido respondida para pasar a otra antes de cerrar la conexión.
MaxKeepAliveRequests: el número total de peticiones que se permite a una conexión abierta.

Cuando un cliente se conecta al servidor web, se le permite realizar múltiples peticiones en la misma conexión TCP, lo cual reduce la latencia asociada a las múltiples conexiones. Esto es útil cuando, por ejemplo, una conexión a una página web requiere varias imágenes, y todas esas imágenes son recibidas por el cliente en una misma conexión. El lado malo es que cada proceso o worker en el servidor debe esperar a que se cierre la sesión por el cliente antes de poder resolver la siguiente conexión. Es difícil decir si es adecuado o no, activar las conexiones persistentes. En caso de que lo activemos, debemos dejar un valor muy bajo, 2, en la directiva KeepAliveTimeout. De esta manera, nos aseguramos de que cualquier cliente puede hacer las peticiones con bastante tiempo, y que el proceso no estará esperando eternamente a que el cliente cierre la conexión y se moverá a la siguiente conexión TCP. Resumiendo, sólo podemos probar su uso y ver si responde a nuestras necesidades.

Una curiosidad. Después de activar el KeepAlive, lo pude ver reflejado al instante en las gráficas del Cacti.

Un poco después de las 16.00 hice el cambio y se puede ver perfectamente. Es lo bueno de tener herramientas como esta. Era viernes y como no es bueno hacer cambios en fin de semana, lo desactivé.

Por último, comentar que la compresión de Apache logra muy buenos resultados. Revisar mod_deflate.

Fuentes:

http://drupal.org/node/215516

http://www.mysqlperformanceblog.com

http://www.mysqlperformanceblog.com/

http://www.devside.net/articles/apache-performance-tuning

http://publib.boulder.ibm.com

http://www.onlamp.com/pub/a/onlamp/2004/02/05/lamp_tuning.html

http://www.pacosanchez.com/2007/11/21/optimizando-apache

http://httpd.apache.org/docs/2.0/mod/worker.html

http://httpd.apache.org/docs/2.0/mod/prefork.html

http://www.ibm.com/developerworks/web/library/l-tune-lamp-2.html#listing1

http://www.apache-es.org/?p=20

http://www.pixelbeat.org/scripts/ps_mem.py – Reporta la memoria consumida por el sistema

Apache devuelve páginas PHP en blanco

Rubén Ortiz — Mon, 21 Apr 2008 14:38:39 +0000

Un error tonto, más propio de un descuido ocasional que de un mala configuración. Pero me lo dejo aquí anotado para pensar más en el, si me vuelve a ocurrir. Tocando la configuración de un apache de una determinada máquina, para que la configuración por defecto no redirigiese a otro destino mediante la directiva Redirect, se me olvidó especificarle algo obligatorio si queremos utilizar el php.

AddType application/x-httpd-php .php .phtml AddType application/x-httpd-php-source .phps

Reiniciar apache y ya está. Esta es una de las causas, hay más que pueden afectar a nuestros servidor web.

Apache y mod_evasive

Rubén Ortiz — Tue, 01 Apr 2008 16:24:25 +0000

¿Qué es Mod Evasive?

Apache Evasive Maneuvers Module
A module for Apache (both 1.3 and 2.0) giving Apache the ability to detect and fend off request-based DoS/DDoS attacks and brute-force attacks conserving your system resources and bandwidth. This tool can be configured to report abusers and even talk to network gear (such as a firewall or ipchains).

Uno de los más famosos mods de toda la comunidad, creado por Zdziarski, este mod_evasive, es usado por cientos de webs. A estas alturas no sirve de nada presentarlo. Voy a explicar brevemente los pasos para poder utilizarlo en un sistema RedHat, Centos. Tuve la incógnita de como se podía hacer partiendo de una instalación de apache, creada a partir de yum y el repositorio de RedHat. Lo único que necesitamos es instalar el paquete httpd-devel:

# wget http://www.zdziarski.com/projects/mod_evasive/mod_evasive_1.10.1.tar.gz # gunzip mod_evasive_1.10.1.tar.gz # tar xf mod_evasive_1.10.1.tar

Actualización:

Mod Evasive 1.10.1

Necesitamos el binario apxs, para poder compilar el mod. Instalamos el paquete httpd-devel:

# yum install httpd-devel

El archivo está localizado en:

/usr/sbin/apxs

Ahora, vamos a ver como compilarlo. Léemos directamente del archivo de instalación. Hay 2 archivos diferentes según nuestra versión de Apache, mod_evasive.c para el apache v1.3 y mod_evasive20.c para Apache v2.X. Leemos directamente del “README” del mod:

1. Extract this archive
2. Run $APACHE_ROOT/bin/apxs -i -a -c mod_evasive20.c
3. The module will be built and installed into $APACHE_ROOT/modules, and loaded
4. Restart Apache

No hace falta que lo hagamos, pero como no tenemos el /bin/apxs dentro del $APACHE_ROOT creamos un enlace simbólico y entonces ejecutamos.
# ln -s /usr/sbin /etc/httpd/bin # /etc/httpd/bin/apxs -i -a -c mod_evasive20.c

El modulo se guardará en $APACHE_ROOT/modules y se modificará automáticamente el httpd.conf para cargar el modulo. Lo siguiente es editar el archivo de configuración de apache para configurar el mod. Incluimos el siguiente trozo de código:

DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10

Este código de configuración es sólo el que viene por defecto. El mod permite incluso interactuar con Iptables para banear ips por firewall. Por ejemplo, podemos configurar rangos de ips “blancas”, seguras, que sabemos que no van a ser focos potenciales de ataques de DDos.

DOSWhiteList 127.0.0.1
DOSWhiteList 195.168.160.*

La lista de ips baneadas, se incluirá en el syslog del sistema, concretamente, en /var/log/messages. Sólo nos queda ya reiniciar apache.

Una vez tengamos todo configurado, podemos utilizar un script en perl para comprobar si mod_evasive hace su trabajo.

# perl test.pl

[...] HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 200 OK HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden HTTP/1.1 403 Forbidden [...]

Cuando mod_evasive detecta que el umbral de conexiones ha sido rebasado, añadirá la ip a la lista de bloqueados.

Links