Cómo instalar XCache en un servidor compartido

La semana pasada quise instalar en un servidor compartido (Hostmonster para más señas) alguno de los diferentes sistemas de caché que existen para PHP. El único que ofrecen es un paquete de PEAR llamado “Cache” pero necesitaba instalar Apc, Xcache, MemCache o Redis. Me puse en contacto con su departamento técnico para consultar si era posible y la respuesta fue un no. Como cuando instalamos Subversion tampoco fueron ni muy optimistas ni proactivos, no hice demasiado caso a su respuesta y me lancé a intentarlo. Como Apc parecía que iba a ser problemático pues por lo que leí necesitaba ser root, lo intenté con Xcache. En primer lugar, en el directorio “home” de mi usuario en Hostmonster creé los directorios y bajé la versión de xCache para la versión de PHP que corre el servidor:

  1. mkdir modules xcache
  2. wget http://xcache.lighttpd.net/pub/Releases/1.3.2/xcache-1.3.2.tar.gz

Después descomprimí el módulo y lo compilé para la versión de PHP del servidor:

  1. tar -zxf xcache-1.3.2.tar.gz
  2. cd xcache-1.3.2
  3. phpize
  4. ./configure –enable-xcache
  5. make

Compruebo que esté bien:

  1. make test

Y ya sólo queda mover el módulo recién compilado a su directorio de destino:

  1. cd modules
  2. mv xcache.so /home2/usuario/modules

Ahora debemos editar php.ini para que PHP empiece a trabajar con Xcache. Añadí las siguientes líneas:

  1. zend_extension = /home2/usuario/modules/xcache.so
  2. zend_extension_ts = /home2/usuario/modules/xcache.so
  3. xcache.shm_scheme = “mmap”
  4. xcache.size = 32M
  5. xcache.count = 8
  6. xcache.slots = 8K
  7. xcache.ttl = 0
  8. xcache.gc_interval = 0
  9. xcache.var_size = 16M
  10. xcache.var_count = 1
  11. xcache.var_slots = 8K
  12. xcache.var_ttl = 0
  13. xcache.var_maxttl = 0
  14. xcache.var_gc_interval = 300
  15. xcache.test = Off
  16. xcache.readonly_protection = Off
  17. xcache.mmap_path = “/dev/zero”
  18. xcache.coredump_directory = “”
  19. xcache.cacher = On
  20. xcache.stat = On
  21. xcache.optimizer = Off
  22. xcache.coverager = Off
  23. xcache.coveragedump_directory = “”

También le podemos añadir un usuario y contraseña, ésta última debe ir “hashed” con md5 según explica la documentación:

  1. xcache.admin.user = “nombre_del_usuario”
  2. xcache.admin.pass = “4c882dcb24bcb1bc225391a602feca7c”

Para que la configuración tenga efecto deberíamos reiniciar los procesos fcgiphp5 pero eso no es siempre posible en un servidor compartido, así que no me quedó otra que esperar a que ello sucediera. Se pueden ver los procesos de la siguiente forma:

  1. ps aux | grep fcgiphp5

A continuación obtenemos la id del proceso y mediante kill mandamos la señal para matarlo. En todo caso, sea de este modo o bien esperando, en el resultado de phpinfo() deberíamos ver esto si XCache está funcionando correctamente:
XCache correctamente instalado

Configuración XCache

Configuración XCache

Instalarlo es muy fácil, ¿verdad? A continuación me puse otra vez en contacto con ellos para preguntarles si tenían algún inconveniente con la instalación pues mejor prevenir a que deshabiliten la web y su respuesta fue que no veían ningún inconveniente. Como pueden observar, en este tipo de servicios de alojamiento web es mejor ser proactivo y lanzarse a ver si es técnicamente posible.

Ventajas de los Unix-like para un profesional

Primero permítanme definir quien está a cada lado. Los Unix-like son todos los sistemas operativos Unix, por ejemplo OS X, FreeBSD, OpenBSD, Solaris… En este lado también pongo a Linux, aunque no sea exactamente un UNIX pues la licencia GNU significa “GNU’s not Unix” y una distribución Linux es básicamente el kernel de Linux más las herramientas GNU. Por otro lado… Windows, ¿es que hay alguno más? 🙂

Los Unix-like tienen la ventaja de que nos permiten optimizar esfuerzos pues los conocimientos adquiridos con ellos no caducan. Incluso conocimientos adquiridos en los años 70, antes de que surgieran los ordenadores personales o los modernos lenguajes de programación, siguen siendo válidos hoy en día. El equivalente en historia a 40 años en tecnología serían muchos siglos. En un mundo tan cambiante, donde en menos de una década todo cambia, Unix es la única constante de la que tengo constancia. El lenguaje C, las llamadas al sistema, los comandos, las “pipes”… ahí están desde el principio de los tiempos con pocas variaciones, así como su filosofía, probablemente la responsable de que haya podido sobrevivir tantas décadas.

Los desarrolladores y administradores de sistemas del otro lado siempre tienen que estar pendientes de lo que la compañía propietaria decida. Por ejemplo a finales del año pasado a todos los desarrolladores .NET les preocupó el anuncio de que se enfatizaría HTML y Javascript  como plataforma de desarrollo para Windows 8. ¿Iba .NET a ser extinguido? ¿Y todo el tiempo que le dedicaron y títulos oficiales de Microsoft pagados a precio de oro? Al final parece ser que la Runtime va a ser cambiada a COM y si los programadores .NET no quedan tirados es porque será accesible desde C/C++, .NET, etc. Aunque no sería la primera vez ni la última que una empresa deja abandonados a su suerte a los especialistas en alguna de sus tecnologías. ¿Qué pasaría por ejemplo si Sun abandonase Java? Tres años atrás me habrían tildado de loco por el mero hecho de plantear la posibilidad. Ahora las tecnologías de Sun pertenecen a Oracle, quien adquirió a la primera. ¿Qué futuro reserva Oracle para MySQL y Java? El que más le convenga a sus accionistas, obviamente.

Desde una perspectiva más general, las soluciones tecnológicas de Microsoft, Sun y demás enmascaran el problema solucionado detrás de otros problemas. Un profesional en una de esas soluciones tecnológicas es experto en solucionar esos problemas, pero si desconoce el problema principal, el problema que tecnologías como Java, .NET o Windows Server 200X quieren solucionar, al ser reemplazadas esas soluciones por otras el profesional tiene que partir otra vez, casi de cero, a aprender el reemplazo a la vieja solución y pagar de nuevo certificaciones que cuando proceden de grandes multinacionales son siempre costosas.

Nunca he odiado a Microsoft, algo bastante extendido entre los seguidores de las soluciones open source, bien al contrario le reconozco su gran labor de sacar la informática de las grandes multinacionales, bancos, ejércitos y grandes universidades y llevarla a los hogares, escuelas, oficinas y universidades, algo que les agradezco como esperan: pagando las licencias del software suyo que utilizo, básicamente Windows. Ahora bien, por el futuro de mi carrera profesional, prefiero soluciones open source como muchos de los Unix-like que existen ahora mismo y recomendaría lo mismo.

Ocultar la versión de Apache y PHP en las cabeceras

Depende de cómo esté configurado Apache puede estar proporcionando a cualquier curioso con intenciones poco agradables información sobre la versión que se está usando de PHP y de Apache, sabiendo la versión del programa se pueden encontrar con gran facilidad exploits en Internet para vulnerabilidades conocidas. Aquí pueden ver las cabeceras de un Apache que habla demasiado:

Cabeceras con demasiada información

Para que Apache oculte su versión existe la directiva ServerTokens desde la versión 2.0.44 Aquí están los resultados que dan sus opciones:

ServerTokens Prod[uctOnly] => Server: Apache
ServerTokens Major => Server: Apache/2
ServerTokens Minor => Server: Apache/2.0
ServerTokens Min[imal] => Server: Apache/2.0.41
ServerTokens OS => Server: Apache/2.0.41 (Unix)
ServerTokens Full => Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

Como podemos ver, ServerTokens Prod es la que más nos conviene pues es la que da menos información. Desde la versión 2.0.44 está directiva controla la directiva ServerSignature. Para una versión anterior deberíamos usar ServerSignature Off además de ServerTokens.

En la imagen también podemos ver un “X-Powered-By” que proporciona la versión de PHP, lo cual tampoco es nada conveniente. Para evitarlo en el fichero de configuración de PHP php.ini debemos poner a Off la directiva “expose_php”.

Resumiendo, en httpd.conf debemos tener:

ServerTokens Prod

# Opcionalmente:
ServerSignature Off

Y en php.ini:

expose_php = Off

Así obtendremos unas cabeceras más discretas:

Cabeceras sin excesiva información

INFORMACIÓN IMPORTANTE: esto para nada substituye la necesidad de mantener nuestro software actualizado. Tan sólo evita hacerle la vida demasiado fácil a un atacante. Debemos tener en cuenta que mediante herramientas como los scanners de “seguridad” como nmap es posible saber la versión de los servicios que corre un servidor. Por no hablar de worms que van probando servidores y, a veces sin ni tan siquiera haber comprobado previamente la versión, van lanzando exploits en busca de una vulnerabilidad explotable.

Guía Cirugía

Colaboro conjuntamente con Net Midas, en el aspecto técnico (me encargo de la programación e implementación) del interesante proyecto “Guía Cirugía”. Guía Cirugía será un directorio donde usuarios de todo el mundo podrán ponerse en contacto con cirujanos plásticos de toda América Latina y España. Entre otros aspectos, el portal también será un punto de encuentro entre usuarios, un lugar donde los cirujanos publicarán artículos especializados, donde los usuarios podrán plantear sus dudas a los cirujanos, incluirá una sección para cirujanos y más funcionalidades y apartados de los cuales les iremos informando aquí en el blog de VIC Services.

Si bien la colaboración será inicialmente en el desarrollo de todo el apartado técnico pero espero poder aportar también ideas y conocimientos en otros aspectos.

¡Les mantendré informados!