# rm-rf.es | Administración de sistemas

Bitácora personal de un SysAdmin Gnu/Linux, Windows, BSD...

Pasos para activar WebDAV en Apache (mod_dav)


Apache

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 <Directory> o <Location>:

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
<Location /webdav>
   Dav On

   AuthType Basic
   AuthName DAV
   AuthUserFile user.passwd

   <LimitExcept GET OPTIONS>
     require user admin
   </LimitExcept>
</Location>

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)


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:

<IfModule mod_fcgid.c>
MaxRequestLen 15728640
...
...
</IfModule>

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

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


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

/etc/init.d/httpd restart

y

/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:

  1. Solicitar la finalización de los procesos con la señal TERM a los procesos child (hijos) y eliminar el proceso padre
  2. Se vuelven a leer los ficheros de configuración y se abren los ficheros de log. Las estadísticas de mod_status se reinician
  3. 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:

  1. Enviamos la señal USR1 o graceful
  2. El proceso padre indica a los hijos que mueran una vez finalizada la petición que estén sirviendo
  3. El proceso padre vuelve a leer los ficheros de configuración y abrir los logs
  4. 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


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


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:

  1. Mirar que el disco tuviera espacio libre (df -h).
  2. Mirar que el disco no estuviera al 100% en inodos (df -i).
  3. 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


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

Cluster Apache Heartbeat

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


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:

<IfModule mod_security2.c>
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"
</IfModule>

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


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=<ruta> 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:

<? phpinfo(); ?>

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:

php 5.3.6