# rm-rf.es » Apache

Pasos para activar WebDAV en Apache (mod_dav)

Alex — Sun, 15 Jan 2012 08:28:47 +0000

El objetivo de WebDAV es hacer de la World Wide Web un medio legible y editable, en línea con la visión original de Tim Berners-Lee. Este protocolo proporciona funcionalidades para crear, cambiar y mover documentos en un servidor remoto (típicamente un servidor web). Esto se utiliza sobre todo para permitir la edición de los documentos que sirve un servidor web, pero puede también aplicarse a sistemas de almacenamiento generales basados en web, que pueden ser accedidos desde cualquier lugar. La mayoría de los sistemas operativos modernos proporcionan soporte para WebDAV, haciendo que los ficheros de un servidor WebDAV aparezcan como almacenados en un directorio local.

Definición de WebDAV en Wikipedia

Preparación/instalación

Vamos a ver los pasos (sencillos) para activar WebDAV en Apache. Lo primero que hay que verificar es que el módulo mod_dav está cargado, ya sea de forma estática o dinámica. Normalmente cuando instalamos Apache por gestor de paquetes viene cargado de forma dinámica en el fichero httpd.conf:

Loadmodule dav_module modules/libdav.so

Si por contra compilamos Apache manualmente podemos decidir si compilarlo estáticamente o dinámicamente (como hemos visto antes). Para hacerlo estáticamente añadiremos la directiva correspondiente a la línea de compilación y podremos ver si está cargado con el comando:

# httpd -l

Otra opción es instalar el paquete por yum/apt/pkg si el paquete está disponible en un repositorio.

Configuración

Lo primero que tenemos que hacer es activar el soporte para WebDAV a nivel general de Apache, para ello añadiremos la siguiente línea en el fichero httpd.conf. Podemos restringirlo a nivel de o :

Dav On

Además de esto, debemos especificar la base de datos de bloqueos (Lock Database) en la sección global de la configuración del httpd.conf:

DavLockDB /etc/apache/var/DavLock

Este directorio debe tener permisos de escritura para el usuario y grupo que ejecuta el servidor Apache.

El resultado final sería el siguiente, en este ejemplo activamos WebDAV en una ubicación (/webdav) únicamente para usuarios autenticados (admin) configurados con htpasswd

DavLockDB /usr/local/apache2/var/DavLock

   Dav On

   AuthType Basic
   AuthName DAV
   AuthUserFile user.passwd

   
     require user admin

Estas mismas directivas (a excepción del DavLockDB) podríamos añadirlas dentro de un virtualhost.

Conectar al WebDAV

Muchos sistemas soportan acceso a WebDAV de forma nativa. No obstante, en Linux podéis usar cadaver sobre línea de comandos:

$ cadaver http://dav.test.com/webdav/
...
...
dav:/webdav/>

mod_fcgid: HTTP request length 132147(so far) exceeds MaxRequestLen (131072)

Alex — Tue, 30 Aug 2011 10:18:25 +0000

Si utilizas Apache + FastCGI y no has modificado los parámetros por defecto de configuración de fasctcgi es probable que si intentas hacer upload de ciertos ficheros cuyo tamaño no sea muy pequeño recibas un error como este en el log:

[Tue Aug 30 12:05:13 2011] [warn] [client XX.XX.XXX.XX] mod_fcgid: HTTP request length 132147 (so far) exceeds MaxRequestLen (131072)

FastCGI está bloqueando la subida del fichero debido a su tamaño. Los límites iniciales de la directiva MaxRequestLen son muy bajos por defecto (131072), así que conviene ampliarlos para evitar este tipo de errores, por ejemplo a 15MB. Esta directiva la añadimos dentro del fichero php.conf (en la carpeta conf/ de apache) y sino dentro del IfModule correspondiente a fastcgi:


MaxRequestLen 15728640
...
...

Reiniciamos apache y listo. Hay que tener en cuenta que esto mismo puede suceder también en servidores con Lighttpd y FastCGI.

Apache: servir PHP usando extensión HTML

Alex — Wed, 24 Aug 2011 15:10:59 +0000

Existe la posibilidad de que queramos introducir código PHP dentro de ficheros estáticos (.html, .htm…), de modo que al servir la página a través del navegador dicho código php se ejecute en lugar de mostrarse como texto plano. Este truco valdría tanto para cualquier otra extensión (cgi por ejemplo).

Para realizar esta configuración, debemos utilizar la directiva AddType en el fichero .htaccess del website o directamente a nivel general del servidor web en el fichero httpd.conf.

Lo primero que debemos verificar es que tenemos cargado en Apache el módulo mod_mime, que es el encargado de servir la directiva AddType.

# httpd -l | grep mime
  mod_mime.c

Una vez verificado, si quisieramos mapear las extensiones .html para servir contenido PHP, deberíamos añadir la siguiente directiva al fichero .htaccess:

AddType application/x-httpd-php .php .htm .html .shtml

Si tuvierais varias versiones de PHP instaladas en un mismo servidor, es posible que necesitéis especificar la versión del siguiente modo:

AddType application/x-httpd-php5 .php .htm .html .shtml

AddType application/x-httpd-php4 .php .htm .html .shtml

Esto lo podemos añadir también a nivel general en Apache, ya sea directamente en el httpd.conf o en el fichero php.conf junto con el resto de configuraciones de PHP. Si lo añadimos en httpd.conf reiniciamos el servicio tras hacerlo:

# /etc/init.d/httpd graceful

Ahora, si hacemos un fichero test.html con el siguiente contenido, al servirlo en el navegador web ejecutará el código PHP en lugar de mostrarlo como si fuera html puro y duro:

Prueba ejecutar PHP en fichero HTML

Apache: diferencia entre reiniciar con ‘restart’ y ‘graceful’

Alex — Sun, 14 Aug 2011 18:31:59 +0000

Vamos a ver las principales diferencias a la hora de reiniciar un servidor web Apache mediante

/etc/init.d/httpd restart

/etc/init.d/httpd graceful

Reinicio con restart

# apachectl -k restart

# /etc/init.d/httpd restart

Esta forma de reiniciar el servidor web es lo mismo que enviar una señal HUP a los procesos httpd (enviar señales a un proceso). Básicamente lo que hace es:

Solicitar la finalización de los procesos con la señal TERM a los procesos child (hijos) y eliminar el proceso padre
Se vuelven a leer los ficheros de configuración y se abren los ficheros de log. Las estadísticas de mod_status se reinician
Se genera el proceso padre y a partir de él los nuevos procesos hijos

Como podéis ver, hay parada de servicio. Puede llegar a ser mínima pero hay un momento en el que no hay ningún proceso httpd para servir peticiones web.

Reinicio con graceful

# apachectl -k graceful

# /etc/init.d/httpd graceful

Esta forma de reiniciar Apache hace que se envíe una señal

USR1

, lo cual hace que en lugar de reiniciar todos los procesos hijos de vez, el proceso padre permite que cada uno de los child termine de servir la petición web antes de morir. El proceso sería el siguiente:

Enviamos la señal USR1 o graceful
El proceso padre indica a los hijos que mueran una vez finalizada la petición que estén sirviendo
El proceso padre vuelve a leer los ficheros de configuración y abrir los logs
Los procesos hijos van terminando de servir las peticiones y el padre los va sustituyendo por nuevos (que ya tienen cargada la nueva configuración)

Cara a mod_status, módulo que sirve para controlar el estado del servidor web, Apache no habrá sido reiniciado, mantendrá todas sus estadísticas y mostrará con una G los threads que están sirviendo previos al reinicio graceful.

Apache: cómo hacer debug de mod_rewrite

Alex — Fri, 10 Jun 2011 12:47:00 +0000

El módulo de Apache mod_rewrite tiene la opción de activar un modo debug o de registro de errores que puede ser de gran utilidad cuando tenemos algún problema con la creación de urls amigables o cualquier tipo uso que le demos a mod_rewrite.

La implantación es simple, únicamente tenemos que especificar en el fichero de configuración de Apache httpd.conf la ruta hacia el log y el nivel de debug que queremos aplicar, que va de 0 (sin debug) a 9 (máximo debug). Se recomienda configurarlo con el valor 3 ya que siendo superior puede provocar alto uso de recursos:

RewriteLog "/usr/local/apache/logs/rewrite.log"
RewriteLogLevel 3

Es recomendable también activarlo únicamente para el virtualhost que lo necesitemos (si tenemos varios sitios web en el mismo servidor) o incluso a nivel de directorio con la directiva Directory. Reiniciamos Apache y comenzará a volcarse la información sobre dicho log.

[error] (28)No space left on device: mod_python: Failed to create global mutex

Alex — Fri, 03 Jun 2011 06:59:11 +0000

Ayer en un servidor Apache con mod_python me encontré con este error:

[Thu Jun 02 21:43:19 2011] [error] (28)No space left on device: mod_python: Failed to create global mutex 1 of 4 (/tmp/mpmtx280211).
Configuration Failed

Lo primero que hice por lógica fue mirar lo siguiente:

Mirar que el disco tuviera espacio libre (df -h).
Mirar que el disco no estuviera al 100% en inodos (df -i).
Mirar que ningún log de Apache hubiera llegado a los 2.0GB de tamaño.

Ninguna de las tres cosas era cierta y seguía teniendo el problema. Hace ya un par de años tuve un problema similar en Apache y estaba relacionado con los semáforos del Kernel: Apache: Semget: No space left on device. Esa vez la solución que ofrecía era vaciar el array de semáforos. En este caso vamos solucionarlo de otro modo, ampliando los valores de Kernel para los semáforos. Actualmente tenía los siguientes:

# cat /proc/sys/kernel/sem
250	32000	32	128

Los ampliamos y reiniciamos Apache:

# echo "kernel.sem = 512 32000 100 512" >> /etc/sysctl.conf
# sysctl -p
# /etc/init.d/httpd restart

Cluster HTTP en alta disponibilidad con CentOS + Heartbeat

Alex — Tue, 19 Apr 2011 08:20:12 +0000

En esta entrada vamos a montar un cluster de alta disponibilidad con dos nodos CentOS, Heartbeat y servidor web Apache. A partir de esta configuración básica el cluster puede aumentar su número de nodos según requerimientos de forma gradual y sencilla.

La configuración del cluster es la siguiente:

nodo 1:

IP: 192.168.1.129
HOSTNAME: cluster01

nodo 2:

IP: 192.168.1.130
HOSTNAME: cluster02

IP virtual para el cluster:

IP: 192.168.1.131

Imagen: hapm.sourceforge.net

Una vez configurado en los dos nodos el hostname e IPs (la IP virtual de momento no la tocamos), pasamos directamente a la instalación de Heartbeat y Apache, en ambos nodos deberíamos instalar:

 yum install httpd

Si preferís compilar apache en lugar de usar paquetes precompilados acudir a este post: compilar apache y php.

Nota: Tendréis que configurar Apache para que escuche por la IP virtual, no lo arranquéis todavía:

Listen 192.168.1.131:80

Evitamos que httpd arranque automáticamente, lo hará HeartBeat:

# chkconfig httpd off

Instalamos Heartbeat mediante yum:

# yum install heartbeat

Una vez instalado pasamos a la configuración de Heartbeat. Los ficheros básicos son authkeys, ha.cf y haresources. La ruta en la que debemos configurarlos es /etc/ha.d/. Si necesitamos ejemplos o los ficheros base los podemos encontrar en /usr/share/doc/heartbeat-2.1.2/.

ha.cf

ha.cf es el fichero en el que se especifica la configuración global del cluster. Nuestra configuración base es la siguiente. En el fichero de muestra tenéis información sobre todas las directivas disponibles:

logfile /var/log/cluster.log
logfacility local0
warntime 5
deadtime 30
initdead 120
keepalive 2
bcast eth0
udpport 694
auto_failback on
node cluster01
node cluster02

En primera instancia especificamos que el log donde se volcará toda la información será /var/log/cluster.log. Las directivas de detección de fallo de nodos son las siguientes:

warntime: Heartbeat avisará cuando un nodo falle tras 5 segundos.
deadtime: Hearbeat confirmará que un nodo ha caído, 30 segundos.
initdead: Tiempo máximo que Heartbeat esperará a que un nodo arranque, 60 segundos.
keepalive: Especifica cada cuanto tiempo Heartbeat enviará paquetes para comprobar la disponibilidad de los nodos, 2 segundos.

A través de “node” especificamos cada uno de los nodos que componen el cluster (sus hostname), uddport es el puerto UDP utilizado para la comunicación y bcast la interfaz broadcast.

authkeys

Este es el fichero en el que se configura el sistema de autenticación entre todos los nodos del cluster. El formato es el siguiente:

auth num
num algorithm secret

Los algoritmos disponibles son crc (1) sha1 (2) y md5 (3). Se recomienda utilizar sha1 así que lo utilizamos para nuestro cluster. “clu$ter-4uth” será la llave de autenticación (secret):

auth 2
2 sha1 clu$ter-4uth

Únicamente root debe poder leer el fichero, así que asignamos los permisos correspondientes:

# chmod 600 /etc/ha.d/authkeys

haresources

En este fichero se especifican los servicios que se moveran entre los distintos nodos del cluster cuando uno de ellos caiga. En este caso únicamente trabajaremos con httpd, en el propio fichero tenéis toda la información. Le especificamos también la IP virtual asignada al servicio:

cluster01 192.168.1.131 httpd

Propagar cambios de configuración entre nodos

Una vez finalizada la configuración inicial, podemos propagar los cambios entre todos los nodos mediante el comando ha_propagate. Hay que tener conectividad ssh/scp entre las máquinas, si no utilizáis llaves os pedirá la clave ssh de los nodos:

# /usr/lib/heartbeat/ha_propagate
Propagating HA configuration files to node cluster02.

ha.cf                                                                                                                    100%   11KB  10.7KB/s   00:00
authkeys                                                                                                                 100%  672     0.7KB/s   00:00
Setting HA startup configuration on node cluster02.
..
...

Arrancar y probar el cluster

Una vez finalizada la configuración ya podemos proceder a arrancar el cluster, para ello iniciamos HeartBeat en cada uno de los nodos:

# /etc/init.d/heartbeat start

El propio HeartBeat reiniciará Apache, no lo hagáis manualmente:

IPaddr[4618]:    2011/04/19_11:43:02 INFO:  Resource is stopped
ResourceManager[4591]:    2011/04/19_11:43:02 info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.131 start
IPaddr[4694]:    2011/04/19_11:43:02 INFO: Using calculated nic for 192.168.1.131: eth0
IPaddr[4694]:    2011/04/19_11:43:02 INFO: Using calculated netmask for 192.168.1.131: 255.255.255.0
IPaddr[4694]:    2011/04/19_11:43:03 INFO: eval ifconfig eth0:0 192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255
IPaddr[4677]:    2011/04/19_11:43:03 INFO:  Success
ResourceManager[4591]:    2011/04/19_11:43:03 info: Running /etc/init.d/httpd  start

En este caso no estamos montando a través de iSCSI, NFS o similar los datos que sirve Apache, de modo que para verificar contra qué nodo del cluster estamos conectando en cada momento podemos crear un index.html básico en cada uno de los nodos, ruta /var/www/html/index.html en el que indiquemos el nodo en el que nos encontramos.

En este momento, si accedermos a http://192.168.1.131 ya deberíamos poder acceder vía web al servicio, y nos indicará que es el cluster01 quien está sirviendo el contenido.

La primera prueba que vamos a hacer para probar el cluster es tirar el nodo cluster01, para ello tiramos la interfaz de red, en mi caso eth0:

# ifdown eth0

Una vez pasado el tiempo especificado en la configuración, en nodo cluster02 debería tomar el control de httpd y servir la web http://192.168.1.131, en el log veréis algo similar a:

heartbeat[2354]: 2011/04/19_11:31:24 WARN: node cluster01: is dead
heartbeat[2354]: 2011/04/19_11:31:24 WARN: No STONITH device configured.
heartbeat[2354]: 2011/04/19_11:31:24 WARN: Shared disks are not protected.
heartbeat[2354]: 2011/04/19_11:31:24 info: Resources being acquired from cluster01.
heartbeat[2354]: 2011/04/19_11:31:24 info: Link cluster01:eth0 dead.
harc[2417]:	2011/04/19_11:31:25 info: Running /etc/ha.d/rc.d/status status
heartbeat[2418]: 2011/04/19_11:31:25 info: No local resources [/usr/share/heartbeat/ResourceManager listkeys cluster02] to acquire.
mach_down[2447]:	2011/04/19_11:31:26 info: Taking over resource group 192.168.1.131
ResourceManager[2473]:	2011/04/19_11:31:27 info: Acquiring resource group: cluster01 192.168.1.131 httpd
IPaddr[2500]:	2011/04/19_11:31:28 INFO:  Resource is stopped
ResourceManager[2473]:	2011/04/19_11:31:28 info: Running /etc/ha.d/resource.d/IPaddr 192.168.1.131 start
IPaddr[2576]:	2011/04/19_11:31:30 INFO: Using calculated nic for 192.168.1.131: eth0
IPaddr[2576]:	2011/04/19_11:31:30 INFO: Using calculated netmask for 192.168.1.131: 255.255.255.0
IPaddr[2576]:	2011/04/19_11:31:31 INFO: eval ifconfig eth0:0 192.168.1.131 netmask 255.255.255.0 broadcast 192.168.1.255
IPaddr[2559]:	2011/04/19_11:31:32 INFO:  Success
ResourceManager[2473]:	2011/04/19_11:31:32 info: Running /etc/init.d/httpd  start
mach_down[2447]:	2011/04/19_11:31:33 info: /usr/share/heartbeat/mach_down: nice_failback: foreign resources acquired
mach_down[2447]:	2011/04/19_11:31:33 info: mach_down takeover complete for node cluster01.
heartbeat[2354]: 2011/04/19_11:31:33 info: mach_down takeover complete.

Y efectivamente, al entrar por navegador a http://192.168.1.131/ accedemos al cluster02.

Esta es la configuración más básica de un cluster HTTP con HeartBeat, a partir de aquí es cuestión de ir haciendo pruebas de failover y failback tirando nodos, levantandolos, y en definitiva, trastear con la configuración, etc ya que HeartBeat permite una gran cantidad de configuraciones.

Instalar mod_security para Apache en Linux 64 bits

Alex — Fri, 15 Apr 2011 14:03:41 +0000

A la hora de instalar mod_security en sistemas de 64 bits podemos encontrarnos con problemas al intentar hacerlo a través de apxs. Por ello, tenemos que recurrir a la instalación mediante compilación. En este caso bajo un centos 5 x86_64.
Lo primero que hacemos es descargar las fuentes:

$ wget http://www.modsecurity.org/download/modsecurity-apache_2.5.13.tar.gz

Descomprimimos y nos ubicamos en la carpeta apache2 (para versiones 2 de Apache):

$ tar -xzvf modsecurity-apache_2.5.13.tar.gz
$cd modsecurity-apache_2.5.13/apache2

Llega el momento de compilar, en este caso la configuración me ha obligado a especificar la ruta tanto de apxs como de apr-config y apu-config:

# ./configure --with-apxs=/usr/local/apache/bin/apxs \
 --with-apr=/usr/local/apache/bin/apr-1-config \
 --with-apu=/usr/local/apache/bin/apu-1-config

Si no recibimos ningún error compilamos:

# make

E instalamos:

# make install

Llega el momento de añadir a httpd.conf la carga de los módulos necesarios y la llamada al fichero de configuración:

LoadFile /usr/lib/libxml2.so
LoadModule security2_module modules/mod_security2.so

Y la llamada al fichero de configuración que podéis llamar como queráis:

Include conf/modsec2.conf

Ya quedará únicamente crear o copiar el fichero modsec2.conf y copiar las reglas que queramos a la ruta deseada.

modsec2.conf:


SecRuleEngine On
SecFilterCheckURLEncoding On
SecFilterForceByteRange 0 255
SecAuditEngine RelevantOnly
SecAuditLog logs/modsec_audit.log
SecDebugLog logs/modsec_debug_log
SecDebugLogLevel 0
SecDefaultAction "phase:2,deny,log,status:403"
#Redireccion a html de seguridad
ErrorDocument 403 http://rm-rf.es/fallo_seguyridad.html
SecRule REMOTE_ADDR "^127.0.0.1$" nolog,allow
#Includes de configuracion
Include "/usr/local/apache/conf/modsecurity_rules/*.conf"

Finalmente comprobamos que la sintaxis de los ficheros de configuración es correcta y ya podemos arrancar Apache y hacer pruebas con mod_security:

# /etc/init.d/httpd configtest
Syntax OK

Cómo compilar Apache y PHP en Linux

Alex — Sat, 19 Mar 2011 16:53:45 +0000

En este artículo voy a explicar los pasos básicos para compilar Apache y PHP (con soporte para MySQL y otros módulos) en GNU/Linux, concretamente bajo RHEL, aunque se puede aplicar a cualquier distribución (CentOS, Fedora, Debian, etc).

Lo primero que tenemos que comprobar es que tengamos instalados los compiladores necesarios (C / C++…) para poder empezar a trabajar, en RHEL y CentOS podemos instalarlos por yum, y en Debian y similar por apt:

# yum install gcc gcc-c++ autoconf make automake

Compilar Apache

Para compilar Apache lo primero que debemos hacer es bajarnos las fuentes de la versión que queramos instalar. En este caso vamos a bajar la última versión estable de la rama 2.2, la 2.2.17:

# wget http://apache.rediris.es//httpd/httpd-2.2.17.tar.gz

Descomprimimos (podéis hacerlo en el directorio /usr/src/ destinado a las fuentes o en donde más rabia os dé):

#  tar -xzvf httpd-2.2.17.tar.gz

Nos ubicamos en la ruta donde hayamos descomprimido las fuentes:

# cd /usr/src/httpd-2.2.17

Ya estamos listos para comenzar a configurar nuestra instalación. El primer paso de toda compilación es el script configure, básicamente es el momento en el que podemos personalizar como queramos nuestra instalación (lugar donde instalar apache, módulos a compilar, cómo cargar esos módulos, etc) también se realizan ciertos chequeos para verificar que la compilación se puede realizar correctamente.

Para ver todas las posibilidades que nos ofrece la configuración, siempre tendremos que ejecutar la ayuda, resultaría tedioso explicar aquí todas las opciones de compilación así que nos vamos a centrar en una instalación básica, para personalizar vuestras instalaciones:

# ./configure --help

Bien, en nuestro caso la línea de configure va a ser la siguiente:

# ./configure --prefix=/usr/local/apache --enable-headers --enable-rewrite --enable-expires --enable-so --disable-authz-default

–prefix= será la ruta en la que vamos a instalar Apache, en este caso /usr/local/apache.
–enable-MODULO: para la activación de módulos utilizamos este parámetro. En la línea de configuración vemos que hemos activado mod_rewrite, mod_headers y mod_expires. Si no especificamos nada, los módulos se cargan de forma estática, para cargarlos de forma dinámica (DSO, explicado en el siguiente punto) utilizamos –enable-MODULO=shared.
–enable-so Permitimos a Apache cargar módulos compartidos (Dynamic Shared Object (DSO)), php será uno de ellos. Esta opción también nos permitirá añadir nuevos módulos sin necesidad de recompilar y de forma dinámica (añadiendo simplemente el módulo mediante “Load Module” en la configuración). Los modulos que añadamos a través de esta línea de compilación, y sin especificar shared se instalarán de forma estática.
–disable-MODULO: He puesto un ejemplo de deshabilitar un módulo en la línea de compilación para que veáis que se pueden deshabilitar módulos (por defecto Apache carga algunos módulos que quizás no te interesen), en el ejemplo desactivamos authz-default

Una vez que tengamos claro que queremos y que no queremos instalar, podemos construir nuestra compilación, para ello simplemente ejecutamos make (según la cantidad de módulos que hayas configurado le puede costar un rato, puedes ir a tomar un café mientras ;) ):

# make

Y una vez que haya terminado, finalizamos la compilación e instalamos apache:

# make install

Cuando haya terminado ya podemos probar nuestra instalación de apache, lo arrancamos:

# /usr/local/apache/bin/apachectl start

Si accedemos vía web, por ejemplo desde la IP del servidor o el host que tenga configurado, deberíamos visualizar lo siguiente:

It works!

Cómo actualizar Apache

La actualización por compilación de fuentes es bastante sencilla. Simplemente tendríamos que seguir este mismo proceso, pero en el punto del configure apache nos lo pone más fácil. En la ruta /usr/local/apache/build encontraréis un fichero llamado config.nice que guarda vuestros parámetros de compilación, con lo que podéis usar dicho fichero en lugar de crear un nuevo configure. El proceso sería entonces, bajar las fuentes de la nueva versión y:

# ./config.nice
# make
# make install

Nota: Los ficheros de configuración, logs y documentos no se sobreescribirán durante la actualización.

Compilar PHP

Ahora que ya tenemos Apache funcionando, es hora de instalar PHP. Vamos a seguir el mismo procedimiento que para compilar Apache. En este caso vamos a instalar PHP con soporte para MySQL y algún otro módulo que veremos más adelante.

Empezamos descargando las fuentes desde el sitio web de PHP. En este caso la última versión estable de la rama 5.3, la 5.3.6. De nuevo nos colocamos en el directorio src o donde queráis trabajar mientras instalamos:

# cd /usr/sr
# wget http://es2.php.net/get/php-5.3.6.tar.gz/from/es.php.net/mirror

Descomprimimos y nos colocamos dentro del directorio:

# tar -xzvf php-5.3.6.tar.gz
# cd php-5.3.6

Ahora, al igual que con Apache llega el momento de crear la línea de configuración, el configure. Del mismo modo podemos seleccionar la ruta de instalación, los módulos y una buena cantidad de parámetros para personalizar nuestra instalación. Es imprescindible pues revisar la ayuda:

# ./configure --help

Una vez que tenemos claro que y como queremos instalar, comenzamos con el configure:

# ./configure --prefix=/usr/local/php --with-config-file-path=/usr/local/php --with-apxs2=/usr/local/apache/bin/apxs --with-mysql --enable-ftp --disable-pdo --disable-ctype

Pasamos a explicar esta línea de configure:

–prefix: al igual que con Apache especificamos la ruta en la que instalaremos php.
–with-config-file-path: especificamos la ruta donde se encontrará el fichero de configuración php.ini.
–with-apxs2: como vamos a compilar php como módulo dinámico (DSO) updatede apache especificamos la ruta a apxs.
–with-libxml2: para evitar el error provocado porque la compilación no encuentra xml2-config necesitaremos tener instalado libxml2-devel (yum install libxml2-devel. El error es configure: error: xml2-config not found. Please check your libxml2 installation.
–with-mysql: habilitamos soporte para MySQL. Por supuesto, antes de habilitar cualquier extensión, si depende de algún programa hay que instalarlo antes, en este caso el cliente MySQL y las headers (paquete devel):
```
yum install mysql mysql-devel
```
–enable-ftp: habilitamos soporte para FTP. Podemos habilitar cualquier otro módulo con –enable-MODULO
–disable-pdo: deshabilitamos el soporte para PDO. Podemos deshabilitar cualquier otro módulo con –disable-MODULO

Una vez seleccionados los módulos a instalar y las opciones correspondientes podemos comenzar a compilar (puede tardar un rato):

# make

Si todo ha ido bien y no hemos recibido errores podemos finalizar la instalación:

# make install

Una vez instalado automáticamente habrá añadido la carga del módulo en nuestra configuración de apache (fichero httpd.conf):

LoadModule php5_module modules/libphp5.so

Ahora solo nos queda indicar a Apache como tiene que interpretar los ficheros php, tenemos que añadir la siguiente línea dentro del fichero httpd.conf. Podemos añadirla junto a los demás AddType, buscadlos y colocadla debajo:

AddType application/x-httpd-php .php

Ahora solo queda reiniciar apache y verificar el funcionamiento de php. Antes comprobamos que la sintaxis del fichero de configuración httpd.conf es correcta:

# /usr/local/apache/bin/apachectl configtest
Syntax OK

Reiniciamos apache:

# /usr/local/apache/bin/apachectl restart

Podemos crear un fichero de pruebas en php para verificar todos los parámetros y módulos de la instalación de php, el contenido es el siguiente:

Lo colocamos en el DocumentRoot por defecto, en nuestro caso es /usr/local/apache/htdocs y lo ejecutamos desde el navegador, el resultado es el siguiente, ya tenemos Apache y php operativo:

Configurar Apache como Reverse Proxy (Proxy Inverso)

Alex — Tue, 28 Dec 2010 09:39:50 +0000

Reverse Proxy / Proxy inverso

Un reverse proxy es un servidor proxy instalado en el domicilio de uno o más servidores web. Todo el tráfico entrante de Internet y con el destino de uno de esos servidores web pasa a través del servidor proxy. Hay varias razones para instalar un “reverse proxy”:

Seguridad: el servidor proxy es una capa adicional de defensa y por lo tanto protege los servidores web.

Cifrado / Aceleración SSL: cuando se crea un sitio web seguro, habitualmente el cifrado SSL no lo hace el mismo servidor web, sino que es realizado por el “reverse proxy”, el cual está equipado con un hardware de aceleración SSL (Security Sockets Layer).

Distribución de Carga: el “reverse proxy” puede distribuir la carga entre varios servidores web. En ese caso, el “reverse proxy” puede necesitar reescribir las URL de cada página web (traducción de la URL externa a la URL interna correspondiente, según en qué servidor se encuentre la información solicitada).

Caché de contenido estático: Un “reverse proxy” puede descargar los servidores web almacenando contenido estático como imágenes u otro contenido gráfico.

Definición Wikipedia

Configurando Apache como Reverse Proxy

Para poder utilizar el propio servidor web Apache como Proxy inverso, debemos tener compilados una serie de módulos. Los módulos básicos necesarios son los siguientes: mod_proxy, mod_proxy_http, mod_proxy_ftp, mod_proxy_connect, mod_proxy_html, mod_xml2enc y mod_headers.

Lo primero que deberíamos hacer es revisar cuales de estos módulos ya están compilados en nuestro servidor web apache, para ello al pasamos al binario httpd el parámetro

-l

# httpd -l

  mod_headers.c
  mod_proxy.c
  proxy_connect.c
  proxy_ftp.c
  proxy_http.c

En este caso vemos que varios de ellos ya están compilados, hay que decir que mod_proxy integra el resto que véis ( proxy_connect, proxy_ftp y proxy_http). En caso de no tener mod_proxy compilado, deberíais hacerlo a través de la línea de compilación, y en caso de haber instalado apache por gestor de paquetes (yum, apt, etc) deberíais instalar el módulo correspondiente.

Partiendo entonces de la base que tenemos mod_proxy compilado, ahora deberíamos preparar los módulos mod_proxy_html y mod_xml2enc, que permiten reescribes las URLs en formato HTML (tipo mod_rewrite) hacia la ruta del proxy y dar soporte internacional (i18n) respectivamente.

Ámbos módulos se pueden descargar desde http://apache.webthing.com/mod_proxy_html/, una vez descargados podemos añadirlos a apache de forma sencilla mediante apxs de forma dinámica (DSO). Nos ubicamos en la carpeta en la que se encuentren los ficheros mod_proxy_html.c y mod_xml2enc.c y ejecutamos el siguiente comando (puede variar según ruta de apxs):

# /usr/local/apache/bin/apxs -I . -cia mod_proxy_html.c  mod_xml2enc.c

Es posible que encontréis un problema relacionado con libxml, es debido a que para compilar el módulo se necesitan dichas librerías. Podéis hacer un include a dichas librerías con el parámetro -L o directamente hacer un enlace simbólico de forma temporal:

# /usr/local/apache/bin/apxs -L /usr/include/libxml2/libxml/ -I . -cia mod_proxy_html.c  mod_xml2enc.c

O el enlace simbólico:

# ln -s /usr/include/libxml2/libxml/ .

Tras realizar este paso de forma satisfactoria, en nuestro fichero de configuración de Apache httpd.conf deberían aparecer como cargados ámbos módulos:

LoadModule proxy_html_module  modules/mod_proxy_html.so
LoadModule xml2enc_module     modules/mod_xml2enc.so

Ahora añadimos también la carga del módulo xml:

LoadFile  /usr/lib/libxml2.so
LoadModule proxy_html_module  modules/mod_proxy_html.so
LoadModule xml2enc_module     modules/mod_xml2enc.so

Este paso finalizaría la parte de compilación/instalación. Para la configuración es recomendable revisar todas las directivas posibles en la documentación oficial de apache. Nosotros vamos a configurar un ejemplo sencillo. Vamos a hacer que al acceder a http://rm-rf.es/google se acceda a google.es mediante proxy inverso.

Vamos a desactivar lo primero el Forward Proxy porque no lo utilizamos, podemos añadir la siguiente directiva seguido de los LoadModule anteriores:

ProxyRequests Off

El virtualhost con el proxy inverso configurado quedaría de esta forma:


ServerName rm-rf.es
DocumentRoot /xxx/xxx/xxx
ServerAdmin xxx@xxxx
UseCanonicalName Off
CustomLog /xxxxx
ScriptAlias /xxxxx


        SetOutputFilter proxy-html
        ProxyPass         http://google.es/
        ProxyHTMLURLMap         http://google.es /google
        ProxyPassReverse         http://google.es
        RequestHeader unset Accept-Encoding

Como veis, hemos añadido una nueva ubicación “Location” dentro del Virtualhost para especificar que ese es el punto desde el que se servirán las peticiones desde el proxy. Posteriormente mapeamos mediante ProxyPass la URL local contra la URL remota. La directiva ProxyPassReverse permite a apache ajustar la URL en las cabeceras HTTP Location, Content-Location y URI, mientras que ProxyHTMLURLMap es la directiva utilizada para hacer el rewrite de los enlaces HTML.

Finalmente hacemos un graceful o un syntax check (-t) a apache para recargar las configuraciones y verificar si el funcionamiento es correcto. Esta es una configuración básica de como utilizar mod_proxy para servir contenido, vuelvo a recomendar la revisión de la documentación para sacar el máximo partido a este servicio. Quizás en otro artículo explique como configurar este proxy reverso para servir contenido mediante SSL y otras curiosidades más.

# rm-rf.es » Apache

Pasos para activar WebDAV en Apache (mod_dav)

Preparación/instalación

Configuración

Conectar al WebDAV

También te puede interesar:

mod_fcgid: HTTP request length 132147(so far) exceeds MaxRequestLen (131072)

También te puede interesar:

Apache: servir PHP usando extensión HTML

Prueba ejecutar PHP en fichero HTML

También te puede interesar:

Apache: diferencia entre reiniciar con ‘restart’ y ‘graceful’

Reinicio con restart

Reinicio con graceful

También te puede interesar:

Apache: cómo hacer debug de mod_rewrite

También te puede interesar:

[error] (28)No space left on device: mod_python: Failed to create global mutex

También te puede interesar:

Cluster HTTP en alta disponibilidad con CentOS + Heartbeat

ha.cf

authkeys

haresources

Propagar cambios de configuración entre nodos

Arrancar y probar el cluster

También te puede interesar:

Instalar mod_security para Apache en Linux 64 bits

También te puede interesar:

Cómo compilar Apache y PHP en Linux

Compilar Apache

Cómo actualizar Apache

Compilar PHP

También te puede interesar:

Configurar Apache como Reverse Proxy (Proxy Inverso)

Reverse Proxy / Proxy inverso

Configurando Apache como Reverse Proxy

También te puede interesar: