Una de las cosas más importantes que debe hacer un buen administrador de sistemas es adaptar el software al entorno al que está destinado, porque no tiene las mismas necesidades un servidor dedicado a sistemas de blogs que uno dedicado a streaming de vídeo o a juegos online, cada uno ha de ser configurado de la forma más óptima para su entorno.
En entornos de hosting compartido la configuración se adapta con el objetivo de satisfacer las necesidades de la mayoría de los usuarios, pero en un servidor dedicado, resulta fundamental una configuración óptima, por lo que vamos a ver las diferencias entre los handlers.
Un detalle importante es que podemos asignar un handler diferente a cada versión, de forma que podríamos tener PHP 5 con un handler de CGI y PHP 4 con un handler DSO. Vamos a ver las diferencias entre ellos.
DSO, también conocido como mod_php, cuyas siglas significan «Dynamic Shard Object». Está considerada como la configuración más rápida, ejecutando PHP como un módulo de Apache, lo que conlleva que todos los scripts se ejecutan con el usuario «nobody».
El problema del usuario «nobody» es que si un hacker ejecuta un exploit de PHP puede conseguir acceder a otras áreas del sistema donde el usuario «nobody» pueda tener acceso, por lo que resulta un sistema altamente vulnerable en hosting compartido o donde varios usuarios tienen acceso.
Todos los ficheros creados con un script de PHP no serán accesibles desde la web, lo que significa por ejemplo, que si subimos una imagen mediante WordPress, no podremos acceder a ella. Esto conlleva un serio problema de permisos con casi todos los sistemas CMS.
DSO es indudablemente más rápido que el resto de handlers y tiene un consumo de CPU muy bajo, pero en cuentas de hosting compartido se desaconseja por completo su uso.
CGI, cuyas siglas significan «Common Gateway Interface», ejecuta PHP como un módulo de CGI. Por desgracia, CGI también ejecuta los procesos de PHP como el usuario «nobody», aunque si tenemos suEXEC habilitado, podremos ver que usuario ha realizado la petición.
Este método no es más rápido ni más seguro que DSO, simplemente existe para entornos donde DSO no es posible.
suPHP o «single user PHP», ejecuta PHP como un módulo de CGI, pero con la principal diferencia de que los usuarios ejecutan los procesos con su nombre y no con «nobody», por lo que la seguridad es notablemente más elevada. suPHP es la configuración por defecto en entornos como cPanel y es la más recomendada para entornos con varios usuarios, ya que conocemos en todo momento quien está ejecutando cada script.
suPHP establece correctamente los permisos de los ficheros al subirlos desde algún script como WordPress. Además, si una cuenta es comprometida, no puede afectar al resto ya que no tendría permisos para efectuar dicha escalada en el servidor.
La contrapartida es que su consumo de CPU es alto en comparación a otros métodos, y no se pueden usar sistemas de cache como Xcache o APC.
FastCGI, también conocido como «mod_fcgid» o FCGI, es una variación de alto rendimiento de CGI. Tiene las ventajas y los beneficios de suPHP (cada usuario ejecuta los scripts con su nombre y no con «nobody»), además de reducir notablemente el consumo de CPU y ofrecer velocidades similares a DSO. Por último, es compatible con sistemas de caché como APC o eAccelerator.
La pega de FastCGI es un elevado consumo de memoria (cada petición permanece abierta de fondo, lo que permite que los sistemas de cache puedan funcionar), pero no debería ser un problema en los servidores actuales con grandes cantidades de memoria. Si dispones de gran cantidad de ella, es la opción más recomendada.
Si se modifica el handler a FastCGI o suPHP, es necesario actualizar los permisos y la propiedad de los ficheros. Para ello se han creados scripts que lo realizan de forma automatizada, como este.
DSO | CGI | SuPHP | FastCGI | |
---|---|---|---|---|
Bajo consumo de CPU | ✔ | ✔ | ||
Bajo consumo de memoria | ✔ | ✔ | ||
Ejecuta PHP con su usuario | Sólo con suEXEC |
✔ | ✔ | |
Seguridad óptima | ✔ | ✔ |