El problema mas común que impide que se pueda acceder correctamente a un sitio o aplicación web que se está instalando o desarrollando es que los archivos y directorios no cuenten con los permisos de acceso apropiados para que el servidor de páginas (Apache por ejemplo) pueda accederlos correctamente.  En estos casos se obtiene un mensaje de error similar al  mostrado a continuación.

failed to open stream: Permission denied in /ruta/al/proyecto/index.php on line xx

La solución

En términos generales, los directorios deben contar con permisos 755 (drwxr-xr-x) y los archivos -como .php- 644 (-rw-r–r–).  Esta modificación puede realizarse de manera recursiva aprovechando la flexibilidad del comando find de la siguiente manera.

$ find /ruta/al/proyecto -type d -exec chmod 755 {} \;
$ find /ruta/al/proyecto -type f -exec chmod 644 {} \;

Inclusive es posible establecer filtros a los nombres de los recursos actualizados para mayor precisión en el cambio.

$ find /ruta/al/proyecto -type f -name '*.php' -exec chmod 644 {} \;

Intentando utilizar un software web que incluía un .htaccess y este se aprovechaba de la funcionalidad del RewriteEngine de Apache2, obtenía siempre el siguiente mensaje de error.

Invalid command 'RewriteEngine', perhaps misspelled or defined by a module not included in the server configuration

Solución

Activar el módulo del RewriteEngine de Apache2.

$ sudo a2enmod rewrite

Reiniciar Apache2 para que tenga en cuenta al módulo recién activado.

$ sudo service apache2 restart

Mientras que en producción mostrar al usuario final la información relacionada con el error producido es un riesgo de seguridad demasiado alto, durante el desarrollo del software es una condición necesaria para entender que está pasando con el código que se está probando.

En la mayoría de despliegues de Apache/PHP vienen ahora con esta opción desactivada, redireccionando por defecto los mensajes de error al archivo de registro habitualmente ubicado en /var/log/apache2/error.log.

Procedimiento

Es posible activar la opción de mostrar los errores de PHP en pantalla a tres diferentes niveles de acuerdo con el alcance que se le desee dar a este comportamiento.

A nivel global, esta modificación aplica a todo el servidor o sitios web publicados bajo esa configuración.

$ sudo vi /etc/php5/apache2/php.ini

error_reporting = E_ALL
display_errors = On

A nivel de un directorio o una aplicación, esta modificación afecta a los scripts ubicados bajo un directorio específico.

$ vi /var/html/un/directorio/especifico/.htaccess

<IfModule mod_php5.c>
    php_value error_reporting E_ALL
    php_value display_errors on
</IfModule>

A nivel de una sección de código específico, esta modificación afecta sólo una parte de un script.

$ vi /var/html/un/script.php

error_reporting(E_ALL);
ini_set('display_errors','On');

Aclaración adicional

Para que los ajustes de configuración de los últimos dos niveles sean tenidos en cuenta, el directorio donde del sitio web publicado deberá tener por lo menos activa la siguiente opción.

AllowOverride Options

Esta se deberá modificar bajo /etc/apache2/mods-enabled/userdir.conf para los sitios personales de los usuarios (public_html) o /etc/apache2/sites-enabled/* para los virtualhosts existentes.

Los bots de los motores de búsqueda son las aplicaciones que contínuamente están revisando los sitios web y sus enlaces para indexar sus páginas.  Esto es bueno porque es precisamente lo que permite funcionar a los buscadores web y mantener su información actualizada, sin embargo también es malo para quienes mantienen los sitios si estos acceden con demasiada frecuencia y utilizan demasiados recursos del servidor, además también es posible que se desee mantener información oculta a los ojos de estos motores de búsqueda.

Para hacer esto se les indica o se les niega el acceso a nuestro sitio a estas aplicaciones.

Procedimiento.

Utilizando el archivo robots.txt.

• Este archivo se debe ubicar en la raíz del sitio web.
• Es una indicación amable a los bots para que cumplan lo que allí se especifica.
• Es posible que bots malintencionados hagan caso omiso de estas indicaciones.

Impedir el acceso a todo el sitio a todos los bots.

# Go away
User-agent: *
Disallow: /

Impedir el acceso a la carpeta /blog del sitio al bot de Google.

# Don't index my blog
User-Agent: Googlebot
Disallow: /blog/

Desde el archivo .htaccess.

• Las modificaciones se realizan en el archivo .htaccess del sitio web.
• Estas políticas son mas restrictivas y no pueden ser obviadas por los bots.
• Debe concerse con precisión la red de la cual proviene el bot ya que se impedirá su acceso por parte del servidor de páginas.
• Es posible que existan otros clientes válidos que intenten acceder desde las ubicaciones especificadas, por ello la dirección especificada deberá ser lo mas precisa posible.

Impedir el acceso al bot de Google.

Limit GET HEAD POST
order allow,deny
deny from 66.249
allow from all

Mod_security es una herramienta extremadamente útil que actúa como un firewall para los sitios web permitiendo filtrar de manera muy flexible la forma como los usuarios acceden a las aplicaciones web, evitando por ejemplo vulnerabilidades conocidas o accesos inválidos.  Mas información.

Su flexibilidad la convierte también en algo un tanto compleja de entender, como todo en la vida tendré que sacar un tiempo para estudiarla y entender en serio como se implementan sus reglas.

Descripción del problema.

En la vida práctica algunas veces las restricciones por defecto que por seguridad el módulo impone interfieren con el correcto funcionamiento de la aplicación web y es cuando suceden mis problemas.  Me sucedió alguna vez con un sitio basado en CodeIgniter y ahora con una instalación de Piwik.

El acceso al script de generación de estadísticas funcionaba correctamente cuando este era accedido directamente.

http://www.server.com/piwik/piwik.php

Sin embargo fallaba por extrañas razones cuando era accedido con parámetros GET tal y como se debe hacer cuando se instala en un sitio web para que lleve las estadísticas de acceso a sus páginas.

http://www.server.com/piwik/piwik.php?url=http%3A%2F%2Fwww.server.com%2Fsite%2F&action_name=Main&idsite=1&res=1280×1024&h=10&m=55&s=25&fla=1&dir=0&realp=0&pdf=1&wma=1&java=0&cookie=1&title=Main%20|%20My%20Site&urlref=

Si se invocaba directamente se producía un error 503 (Service Temporarily Unavailable) y en las aplicaciones que lo tuvieran instalado para el control de sus estadísticas aparecía como una imagen al final de su contenido (en lugar de un cuadrado transparente).

El problema era que mod_security estaba impidiendo el acceso normal al sitio debido a alguna de sus reglas.

Descripción de la solución.

Sin tener profundos conocimientos en la creación y manipulación de las reglas de mod_security la idea no era modificarlas sino evitar que se aplicara el filtro sobre la aplicación web afectada.

Una primera solución fue desactivar por completo a mod_security para esa aplicación específica.  Para hacer esto es necesario crear un archivo .htaccess en el directorio raíz de la aplicación con el siguiente contenido.

SecFilterEngine Off
SecFilterScanPOST Off

Esto soluciona el problema sin embargo también elimina las ventajas de seguridad que trae consigo el módulo.  Una segunda opción sería entonces evitar que el filtro se aplique al archivo específico que está teniendo el problema con el filtro.  Para hacer esto el contenido del archivo .htaccess debe ser el siguiente.

SetEnvIfNoCase Request_URI ^/piwik/piwik\.php$ MODSEC_ENABLE=Off

Donde se especifica la ubicación exacta (relativa o absoluta) del archivo con problemas.

Enlaces.

• mod_security: Opensource Web Application Firewall.
  http://www.modsecurity.org/
• Apache Module mod_setenvif.
  http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html
• mod_security en Dreamhost Wiki.
  http://wiki.dreamhost.com/Mod_security

La instalación de estos paquetes se puede realizar de dos maneras.  Utilizando Tasksel, que yo he llamado el método rápido, o instalando -casi- individualmente los paquetes que se deseen.  En mi opinión personal prefiero el segundo método ya que controlo directamente que se está instalando en el servidor.

Tasksel es una herramientas de Debian que se incluye en la mayoría de las distribuciones hijas (como Ubuntu) y permite instalar en bloque muchos paquetes según agrupaciones predefinidas, entre ellas la instalacion de un LAMP Server.

Instalación de Apache.

Instalación del servidor HTTP.

# apt-get install apache2

# apt-get install wwwconfig-common

Modificar la ubicación del DOCUMENT_ROOT.

Por defecto el árbol de directorios que se publica a través del servidor web se ubica en /var/www, si se desea modificar esta ubicación es necesario realizar los siguientes pasos.

Crear el directorio donde se almacenarán los documentos web.

# mkdir -p /home/www/public

Modificar la configuración de Apache para incluír a este nuevo directorio.

# vi /etc/apache2/sites-enabled/000-default

Reemplazar las ocurrencias de /var/www por la ruta deseada, es decir, los valores de DocumentRoot y su correspondiente Directory.

DocumentRoot /home/www/public/
# …
<Directory /home/www/public/>
# …

Reiniciar el servicio para tener en cuenta los cambios recién realizados.

# /etc/init.d/apache2 restart

Instalación de PHP.

Instalación de lenguaje de programación y varios de sus módulos.

# apt-get install php5 php5-cli php5-gd php5-mcrypt php5-curl php5-imagick php5-mhash php5-sqlite php5-xsl

Instalación del módulo dinámico (DSO) de Apache.

# apt-get install libapache2-mod-php5

Instalación de MySQL.

Instalación del motor de base de datos.

# apt-get install mysql-server

Instalación del modulo de PHP asociado a este motor de base de datos.

# apt-get install php5-mysql

Instalación de PHPMyAdmin para la administración de la base de datos a través de web.

# apt-get install phpmyadmin

El acceso se realiza a través de la URL http://localhost/phpmyadmin/.

El procedimiento no fue interesante, simplemente creé el nuevo subdominio y copié los archivos con un cp -rf, sin embargo si me interesa documentar el pequeño cambio que tuve que hacer para conservar la ruta anterior y no romper enlaces antiguos al sitio, especialmente el del RSS.

Es necesario indicarle a Apache que la ubicación antigua ha sido movida a la nueva ubicación.  Para esto agregué la siguiente instrucción al archivo .htaccess ubicado en el directorio raíz correspondiente con el URL http://jorgeivanmeza.com/.

redirect 301 /blog/ http://blog.jorgeivanmeza.com/

El formato de la instrucción redirect es el siguiente.

• Movido permanentemente: 301.
• Ubicación antigua: /blog/.
• Nueva ubicación: http://blog.jorgeivanmeza.com/.

Gracias a esto mis feeds se pueden consultar tanto desde el nuevo sitio: http://blog.jorgeivanmeza.com/feed/ como desde el anterior: http://jorgeivanmeza.com/blog/feed/.

Enlaces.

• htaccess 301 redirect tutorial.
  http://www.tamingthebeast.net/articles3/spiders-301-redirect.htm

Apache.

$ sudo apt-get install apache2 libapache-mod-suphp

MySQL.

$ sudo apt-get install mysql-admin mysql-client mysql-navigator mysql-server phpmyadmin

PHP.

$ sudo apt-get install php5 php5-cli php5-dbg php5-gd php5-interbase php5-mcrypt php5-mysql php5-sqlite php5-suhosin php5-xdebug php-soap

# cd /usr/ports/lang/python
# make install clean

    THREADS
    UCS4
    PYMALLOC
    IPV6

# python -V

    Python 2.5.2

Instalación de mod_python.

# cd /usr/ports/lang/mod_python3

# make install clean

Configuración de Apache con mod_python.

# vi /usr/local/etc/apache22/httpd.conf

    LoadModule python_module libexec/apache22/mod_python.so
    PythonOption mod_python.mutex_directory "/tmp"
    PythonOption mod_python.mutex_locks 8

    <Directory "/home/web">
        AddHandler mod_python .py
        PythonHandler pythontest
        PythonDebug On
    </Directory>

Recuérdese que el DOCUMENT_ROOT del servidor es "/home/web".

A continuación se creará el siguiente archivo ubicado en /home/web/pythontest.py para verificar el funcionamiento del módulo.

# vi /home/web/pythontest.py

from mod_python import apache
import datetime
def handler(req):
    today = datetime.date.today()
    req.content_type = "text/plain"
    req.write("Hello, today is " + str(today.day) + "/" + str(today.month) + "/" + str(today.year) + ".")
    return apache.OK

Si se consulta el sitio http://webserver.mydomain.com/pythontest.py deberá obtenerse una respuesta similar a la mostrada a continuación.

    Hello, today is 27/5/2008.

Si se intenta ejecutar cualquier otro programa .py ubicado en el mismo directorio (/home/web) se obtendrá siempre la misma respuesta ya que en la configuración de Apache se especificó que ese archivo (pythontest.py) sería quien manipulase los archivos Python en ese directorio. Para permitir el acceso de otros programas desde la misma ubicación se deberán utilizar manipuladores (handlers) especiales como mod_python.Publisher, mpservlets o Vampire.

Enalces.

• Lenguaje de programación Python.
• mod_python.
• Instalación de mod_python (documentación en general).

# make install clean

# vi /usr/local/etc/apache22/httpd.conf

LoadFile /usr/local/lib/libxml2.so
LoadModule mod_security2    libexec/apache22/mod_security2.so
<IfModule security2_module>
    SecRuleEngine On
</IfModule>

# /usr/local/etc/rc.d/apache22 restart

Nota: la instalación con la versión 2.1.3 no se pudo realizar ya que el Makefile no realizaba correctamente el enlace con libxml2 y fallaban las reglas que requerían procesamiento de XML. Se recomienda actualizar a una versión superior.

El siguiente paso consiste en configurar las reglas de seguridad que apliquen a su negocio. Para esto edite apropiadamente los siguientes archivos bajo la ruta /usr/local/etc/apache22/Includes.

• mod_security2.conf
• no-accf.conf
• mod_security2/ (directorio de reglas)

Enlaces

• Manual de referencia (documentación).
• Reglas de GotRoot.