Desactivando módulos innecesarios en Apache

Tengo un servidor Apache montado en una máquina física muy justita de recursos (especialmente de memoria RAM). El servidor Apache que viene por defecto tendría que cambiarlo por nginx. Por lo que dicen en los mentideros de Internet parece que consume menos recursos que Apache… mientras tomo la decisión de migrar, he optado por recortar módulos de Apache que no necesito. Puedes ver la lista completa de módulos Apache lanzados así:

apachectl -M

En concreto, para montar un WordPress sencillito, he desactivado los siguientes, por innecesarios:

a2dismod status
a2dismod negotiation
a2dismod env
a2dismod autoindex
a2dismod authn_file
a2dismod authz_file
a2dismod authz_user
a2dismod auth_basic
a2dismod authn_core

Ahora, la lista queda así (filtrando los módulos básicos, que no se pueden deshabilitar):

apachectl -M | grep shared
 
access_compat_module (shared)
alias_module (shared)
authz_core_module (shared)
authz_host_module (shared)
deflate_module (shared)
dir_module (shared)
filter_module (shared)
mime_module (shared)
mpm_prefork_module (shared)
php5_module (shared)
rewrite_module (shared)
setenvif_module (shared)

Si partes de cero y quieres ver qué módulos puedes desactivar, te recomiendo el siguiente procedimiento:

1) teclea a2dismod y a continuación pulsa TAB dos veces. Bash te dará los nombres de los módulos desactivables.

2) deshabilita uno a uno los módulos. Por ejemplo,

a2dismod env

y a continuación, comprueba que tu configuración Apache no depende de ese módulo usando

apachectl configtest

Con eso no es que te asegures al 100% de que no la has pifiado, pero te será de gran ayuda hacerlo, porque detecta pifias antes de relanzar Apache…

3) Relanzar Apache

service apache2 restart

Si quieres saber más al respecto, te recomiendo que leas este hilo de discusión en stackoverflow.com y que antes de deshabilitar módulos alegremente, le eches un vistazo a lo que hace cada uno de ellos en la documentación de Apache. Por ejemplo, si quisieras ver qué hace y para qué sirve el módulo env, ésta sería la página del manual de Apache.

Incubando huevos al estilo Apache

Me gusta aplicar herramientas y técnicas que aprendo en la ingeniería de grandes proyectos de software opensource en la gestión y trabajo diario de los Proyectos Fin de Carrera que dirijo (ahora, Trabajos Fin de Grado). Realmente creo que estas técnicas se pueden reutilizar tamb ién y de forma bastante directa en el ámbito empresarial, pero eso lo dejo como tema de discusión para otro día. Ahora quiero centrarme en exponer brevemente, de forma muy resumida, cómo funciona la incubadora de proyectos de Apache.

Apache ofrece cobertura técnica (infraestructura, servidores, listas de correo, espacio en disco…) y legal a los nuevos proyectos que acoge, aparte de permitir asociar su marca, Apache (muy reconocida en el mundo tecnológico) al nuevo proyecto. Éste, a cambio de pasar a formar parte de la incubadora de la fundación (a ser un podling), debe empezar a cumplir ciertos requisitos.

No es fácil llegar a formar parte de la incubadora, hay un largo camino que recorrer, pero una vez que lo consigues y tu proyecto obtiene una dirección en la incubadora Apache, entras, como hemos dicho, en la zona de Podling. Aquí tendrás resposabilidades y mucho trabajo por hacer. Entre otras cosas:

* generar un informe de seguimiento. Uno al mes durante los primeros 3 meses y uno cada 3 meses a partir de ahí.
Puedes ver esta planificación de informes general, o uno en particular (mes de Marzo de 2012)

* mantener actualizada una página con un resumen del estado del proyecto. Por ejemplo, ésta de OpenMeetings.

* atender las listas de correo

* generar novedades en el proyecto. Estas novedades serán recogidas y documentadas de forma automática. Si cada proyecto de la incubadora es visto como un huevo, el nido de huevos sería el clutch de Apache. Y las novedades en el clutch están monitorizadas.

¿Qué se monitoriza? Entre otros datos, los días de incubación, la última fecha de commit en SVN, la última fecha de actualización de la página de estado, el número de nuevos commiters,

Como todo huevo bien cuidado por sus progenitores, eclosionará en algún momento, pasando a ser un potencial proyecto Top Level de Apache (digo potencial porque deberá ser aprobado por votación)

Como ves, la política de incubación es interesante y puede ser aplicada fuera del entorno Apache (en empresas de desarrollo software, en proyectos fin de carrera, trabajos fin de grado…). Lo que está claro es que requiere mucha dedicación y esfuerzo a los responsables del proyecto, así que ahora entenderás mejor porqué algunos proyectos no se deciden a dar el paso de entrar en la incubadora (aparte de que algunos proyectos no quieran usar ni los servicios ni la licencia Apache).

Proxy inverso en Apache

El problema es sencillo de enunciar, pero no tan facil de resolver. Tengo un servidor A con IP pública,
al que puedo editar sus archivos de configuración. Desde el servidor A se puede acceder a otro interno, privado,
al que llamaré B. No es posible acceder a B directamente (desde fuera). ¿Cómo configuro A para que haga las veces de reverse-proxy? Es decir, quiero que lo que un cliente (navegador Firefox, por ejemplo) pida a A con una determinada dirección de carpeta, por ejemplo, http://A/carpeta , sea redirigido (por el propio servidor A) a la ruta http://B/carpeta y el resultado de esa llamada sea devuelto al cliente Firefox.


Cliente <--> Servidor IP pública (A) <-> Servidor IP Privada (B)

Esto tal cual no parece difícil y se puede hacer activando el módulo proxy_http de Apache. Pero en micaso, al probarlo, me encontré con otro problema añadido: las páginas que B devuelve a A y éste finalmente al cliente Firefox, incluyen código HTML con enlaces a B. Como ya he dicho, desde el cliente Firefox no podemos acceder directamente a B, así que esto era de verdad un problema… hasta que encontré el módulo proxy_html_module, que reescribe en Apache el contenido de las páginas antes de entregarlas 🙂

El módulo proxy_html_module hay que instalarlo (los demás están disponibles en Apache 2 de serie, al menos en Ubuntu):


$ sudo apt-get install libapache2-mod-proxy-html

Así que, en resumen, el problema enunciado se resuelve así:

1) Activar los módulos necesarios en Apache


$ sudo a2enmod proxy_http_module
(tiene una dependencia con proxy_module que se resuelve ‘automágicamente’)
$
$ sudo a2enmod proxy_html_module

2) Activar el acceso al Proxy para localhost o la IP del servidor A (si no, toda petición será rechazada)


$ sudo vi /etc/apache2/mods-available/proxy.conf

AddDefaultCharset off
Order deny,allow
Deny from all
Allow from localhost # o en su lugar, la IP pública

3) Definir las redirecciones que nos interesen:

$ sudo vi /etc/apache2/sites-enabled/000-default
ProxyPass /carpeta/ http://B/carpeta/
ProxyHTMLURLMap http://B/carpeta /carpeta
#

ProxyPassReverse /
SetOutputFilter proxy-html
ProxyHTMLExtended On

Más info en el manual de Apache 2 al respecto de ProxyPassReverse y en la guía de mod_proxy_html

Ver los módulos que tenemos cargados en Apache2

Receta rápida:

# /usr/sbin/apache2ctl -t -D DUMP_MODULES

using 127.0.1.1 for ServerName
Loaded Modules:
core_module (static)
log_config_module (static)
logio_module (static)
mpm_prefork_module (static)
http_module (static)
so_module (static)
alias_module (shared)
auth_basic_module (shared)
authn_file_module (shared)
authz_default_module (shared)
authz_groupfile_module (shared)
authz_host_module (shared)
authz_user_module (shared)
autoindex_module (shared)
cgi_module (shared)
deflate_module (shared)
dir_module (shared)
env_module (shared)
mime_module (shared)
negotiation_module (shared)
php5_module (shared)
setenvif_module (shared)
status_module (shared)
Syntax OK

Hosts Virtuales en Apache 2 (Ubuntu)

Lo que sigue es una breve nota técnica que me sirva (y a otros) como recordatorio para la próxima vez , dado que hoy he perdido un rato con la configuración de un host virtual en Ubuntu (en Fedora lo tenía todo ya hecho, y sólo era copiar y pegar 🙂

En /etc/apache2 disponemos de varios subdirectorios, dos de ellos importantes para nuestra tarea. El primero sites-available y el segundo sites-enabled.

Los ficheros de configuración de los hostings virtuales se configuran en sites-available. El segundo subdirectorio sólo contiene enlaces a aquellos virtulhost que queremos activar.

Queremos crear un virtualhost de nombre hackit. Es decir, cuando ponga en mi navegador http://hackit me debe de llevar a la página principal de ese host. Si pongo http://localhost me llevará al virtualhost por defecto (distinto del de hackit).

Lo primero, creo una nueva entrada en /etc/hosts (mantengo lo que había y añado lo siguiente):

127.0.0.1 hackit

Copio los archivos del nuevo site en /var/www/hackit.

Comienza el procedimiento de configuración del nuevo virtualhost en Apache2:

$ cd /etc/apache2/sites-available

Edito las dos primeras líneas del fichero default para que queden así:

NameVirtualHost *:80
<VirtualHost *:80>
$ cp default hackit

Edito hackit para que las primeras líneas queden así:

<VirtualHost *:80>
ServerAdmin webmaster@hackit

ServerName hackit

DocumentRoot /var/www/hackit
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/hackit>
$ cd /etc/apache2

El siguiente comando, a2ensite (available2enablesite) crea un enlace en sites-enable al site que le indiquemos (es decir, activa el virtualhost que acabamos de crear)

# a2ensite hackit

Comprobamos:

$ ls -al sites-enabled/

Recargamos apache2:

#/etc/init.d/apache2 force-reload
Listo!