mod_include ofrece un medio de procesar los archivos antes de que los datos se envíen al cliente. Normalmente, mod_include se usa para incluir archivos en un documento que se analizan como HTML antes de alcanzar el cliente. Esta es la razón por la que se denomina "inclusiones del servidor" (SSI).

Gracias a las SSI, los comandos especiales se ejecutan en el servidor, activados mediante comentarios con formato SGML. Estos comandos SGML tienen la siguiente sintaxis:

<!--#element attribute=value -->
        

Si desea ver una lista de valores de element y attribute, consulte la documentación de mod_include en http://httpd.apache.org/docs-2.0/mod/mod_include.html.

Para usar mod_include en SUSE Linux, añada include a APACHE_MODULES en /etc/sysconfig/apache2 o use YaST tal y como se describe en Módulos.

Sugerencia

Utilice la directiva XBitHack (http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack) para dar instrucciones a Apache de que analice archivos con el bit execute definido para las directivas SSI. Esto quiere decir que, en lugar de tener que cambiar la extensión de un archivo para marcarla indicando que incluye elementos SSI (.shtml en el ejemplo mencionado anteriormente), puede usar un archivo .html normal y ejecutar el comando chmod +x miarchivo.html.

mod_cgi permite que Apache pueda entregar contenido creado por programas o guiones CGI (del inglés Common Gateway Interface, interfaz común de gateway). Actúa como instancia entre un lenguaje de programación disponible en el equipo y el servidor Web de Apache. En teoría, se pueden escribir guiones CGI en cualquier lenguaje de programación. Normalmente, se utilizan los lenguajes Perl o C. mod_cgi es la forma más común de incluir contenido dinámico en un sitio Web.

La programación de CGI es distinta de la programación "normal" en que los programas y guiones CGI deben ser capaces de generar el tipo MIME Content-type: text/html para generar un resultado en formato HTML.

#!/path/to/perl
print "Content-type: text/html\n\n";
print "Hola, mundo.";
            

La diferencia entre módulos unidos específicamente a un lenguaje de programación (como mod_php5) y mod_cgi reside en la posibilidad de combinar mod_cgi con mod_suexec (consulte la Sección 46.5.2.1, “Ejecución de las CGI como usuario distinto con mod_suexec ”). Esta combinación permite que los guiones CGI se ejecuten con un ID de usuario concreto. Normalmente, los guiones que usan sólo mod_cgi o mod_php5 se ejecutan con el ID del usuario de Apache (por defecto en SUSE Linux: wwwrun). Los módulos diseñados para un lenguaje de programación (como mod_php5 o mod_ruby) incrustan un intérprete permanente en Apache para ejecutar guiones con el ID de usuario de Apache.

Como consecuencia, las CGI con mod_suexec mejoran la claridad de las tareras administrativas, dado que los procesos CGI pueden asignarse a usuarios individuales en lugar de al propio servidor Web. Además, con esta combinación se consigue una seguridad superior en el sistema de archivos: los guiones sólo heredan los derechos de los que disponga el usuario en el sistema de archivos. Por el contrario, en el caso de los módulos, los guiones otorgan los permisos de archivos del usuario del servidor Web, lo que puede llevar a una visibilidad no intencionada de datos en el sistema de archivos.

Las CGI se terminan cuando la petición de un cliente al servidor Web finaliza. Esto quiere decir que las CGI no son permanentes y liberan todos los recursos ocupados después de la terminación. Esto supone una ventaja, sobre todo en caso de una programación errónea. Con los módulos, los efectos de los errores de programación se pueden acumular porque el intérprete es permanente. Esto puede provocar fallos al liberar recursos, como las conexiones de la base de datos, y puede ser necesario reiniciar Apache.

Para utilizar mod_cgi en SUSE Linux, añada cgi a APACHE_MODULES en /etc/sysconfig/apache2 o utilice YaST tal y como se describe en Módulos. El directorio por defecto para las CGI en SUSE Linux es /srv/www/cgi-bin/.

Si edita manualmente el archivo de configuración de Apache, utilice este ejemplo como guía para configurar mod_cgi.

# Global Environment
LoadModule cgi_module /path/to/mod_cgi.so

# Main Server and/or Virtual Host and/or 
# Directory and/or .htaccess context
AddHandler cgi-script .cgi .pl

# Main Server and/or Virtual Host context
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Alternatively, explicitly allow CGI scripts in a directory
# Main Server and/or Virtual Host context
<Directory /srv/www/some/dir>
    Options +ExecCGI
<Directory>
            

En combinación con mod_cgi (Sección 46.5.1.2, “Interfaz común de gateway (CGI): mod_cgi ”), mod_suexec permite que los guiones CGI (Interfaz común de gateway) se ejecuten como un usuario y grupo especificado. Para este propósito se utiliza el programa suEXEC, que se encuentra en /usr/sbin/suexec2. Se trata de una empaquetadora a la que Apache llama cada vez que se ejecuta un guión CGI o un programa. Tanto la empaquetadora como el programa obtienen el usuario configurado y el ID de grupo asignado. El resultado es que se ejecutan como un usuario o grupo configurado.

Aunque este enfoque reduce considerablemente el riesgo de seguridad que suponen los guiones CGI generados por el usuario, también hay que tener en cuenta algunas consideraciones importantes:

En el caso de errores provocados por mod_suexec, consulte el archivo de registro situado en /var/log/apache2/suexec.log.

Para usar mod_suexec en SUSE Linux, añada suexec a APACHE_MODULES en /etc/sysconfig/apache2 o utilice YaST tal y como se describe en Módulos. Tenga en cuenta que para ejecutar suexec es necesario emplear mod_cgi.

mod_suexec es muy útil cuando se aplica a un entorno de host virtual, tal y como se describe en la Sección 46.4, “Hosts virtuales”. Para especificar un grupo y usuario concreto para ejecutar guiones CGI, utilice la sintaxis siguiente en el archivo que incluya las declaraciones de host virtuales (el directorio por defecto en SUSE Linux es /etc/apache2/vhosts.d/*):

<VirtualHost 192.168.0>
# ...
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.ejemplo.com/cgi-bin/
SuexecUserGroup tux users
# ...
</VirtualHost>
            

La sintaxis de SuexecUserGroup nombreusuario grupo en este ejemplo asigna todos los guiones de /srv/www/vhosts/www.ejemplo.com/cgi-bin/ al ID de usuario tux y al ID de grupo users.

mod_ssl ofrece un cifrado muy potente con el uso de los protocolos Nivel de zócalo con seguridad (SSL) y Seguridad del nivel de transporte (TLS) para la comunicación HTTP entre un cliente y el servidor Web. Para este propósito, el servidor envía un certificado SSL con información que prueba la identidad válida del servidor antes de responder a cualquier petición a una URL. A su vez, de esta manera se garantiza que el servidor es el único punto final correcto de la comunicación. Además, el certificado genera una conexión cifrada entre el cliente y el servidor que puede transportar información sin el riesgo de exponer contenido importante en formato de sólo texto. El efecto más visible de usar mod_ssl con Apache es que las URL llevarán delante https:// en lugar de http://.

El puerto por defecto para las peticiones de SSL y TLS en el servidor Web es el 443. No hay conflicto entre una escucha “normal” de Apache en el puerto 80 y una escucha de Apache habilitada para SSL/TLS en el puerto 443. De hecho, HTTP y HTTPS pueden ejecutarse con la misma instancia de Apache. Normalmente se emplea un host virtual (consulte la Sección 46.4, “Hosts virtuales”) para expedir peticiones al puerto 80 y 443 y a servidores virtuales independientes.

Hosts y SSL virtuales basados en nombres

No es posible ejecutar varios hosts virtuales habilitados para SSL en un servidor con una única dirección IP. Los usuarios que se conectan a una configuración de este tipo reciben un mensaje de advertencia en el que se les indica que el certificado no coincide con el nombre del servidor cada vez que visitan una URL. Se necesita una dirección IP o puerto distintos para cada dominio habilitado para SSL para poder comunicarse basándose en un certificado SSL válido. A pesar del mensaje de advertencia, obtendrá el mismo nivel de cifrado que tendría en cualquier sitio SSL válido. Esto quiere decir que mientras el mensaje de advertencia sea aceptable, la comunicación entre el servidor Web y el cliente todavía es segura. El concepto de reconocimiento de la identidad exclusiva del servidor, garantizada por un certificado SSL válido, se pierde.

Para activar mod_ssl en SUSE Linux, añada ssl a APACHE_MODULES en /etc/sysconfig/apache2 o utilice YaST tal y como se describe en la Módulos. Además, el servidor Web debe configurarse para escuchar en el puerto HTTPS estándar 443, lo que puede hacerse manualmente en /etc/apache2/listen.conf o en YaST mediante la entrada de menú para escuchar ‘’(consulte la Selección de dispositivos de red).

Se puede crear un certificado SSL introduciendo cd /usr/share/doc/packages/apache2; ./certificate.sh como usuario Root. Siga las instrucciones que aparecen en pantalla para crear un certificado SSL. Los archivos de certificado resultantes residen en los directorios /etc/apache2/ssl*.

Un certificado “real” con validez global se puede obtener de proveedores como Thawte (http://www.thawte.com/) o Verisign (www.verisign.com).

Si edita manualmente el archivo de configuración de Apache, utilice este ejemplo como guía para configurar mod_ssl.

# Global Environment
# listen on the standard SSL port
Listen 443
# load module only if rcapache2 start-ssl was issued
<IfDefine SSL>
LoadModule ssl_module /path/to/mod_ssl.so
</IfDefine>

# Main Server context
# include global (server-wide) SSL configuration
# that is not specific to any virtual host
# only if ssl_module was loaded
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule>
            

	Sugerencia
No olvide abrir el cortafuegos para Apache habilitado para SSL en el puerto 443. Puede realizarse mediante las opciones ‘Seguridad y usuarios’+‘Cortafuegos’+‘Servicios autorizados.’ A continuación, añada el ‘Servidor HTTPS’ a la lista de ‘Servicios autorizados.’

mod_perl incrusta un intérprete de Perl permanente en Apache. De esta manera se evita el sobrecargo provocado por un mod_cgi que llama a un ejecutable externo en cada petición a un CGI (Interfaz común de gateway). mod_perl permite además controlar muchos aspectos de las funciones de Apache con la ayuda del lenguaje de programación Perl.

Para utilizar mod_perl en SUSE Linux, instale el RPM apache2-mod_perl y active el módulo mediante (Módulos) o manualmente en /etc/sysconfig/apache2. Después de la instalación y la activación, se colocará un archivo de configuración independiente mod_perl.conf en /etc/apache2/conf.d/. Además, el guión de inicio mod_perl se instalará como mod_perl-startup.pl. Para obtener más información sobre cómo usar el módulo, consulte la documentación disponible en el sitio Web de mod_perl (http://perl.apache.org/).

PHP es un lenguaje de programación conocido que en un principio estaba dirigido a su uso en la Web. Existen dos versiones: PHP4 y PHP5. Mientras que PHP4 representa el concepto y enfoque clásico de PHP, PHP5 ha introducido nuevas posibilidades de programación orientadas a objetos junto con muchas otras funciones avanzadas. Tanto mod_php4 como mod_php5 están disponibles en SUSE Linux. Incrustan el intérprete de PHP en Apache como un módulo permanente.

Para usar mod_php4 o mod_php5 en SUSE Linux, instale el RPM respectivo (apache2-mod_php4, apache2-mod_php5) y active el módulo mediante YaST (Módulos) o manualmente en /etc/sysconfig/apache2.

Después de la instalación y activación, se colocará un archivo de configuración independiente para el módulo respectivo (ya sea php4.conf o php5.conf) en /etc/apache2/conf.d/. El sitio Web de PHP (http://www.php.net) es un recurso excelente sobre cómo usar Apache junto con PHP.

mod_python incrusta el intérprete Python en Apache. Python es un lenguaje de programación orientado a objetos con una sintaxis clara y legible. Una función inusual pero muy cómoda es que la estructura del programa depende del sangrado del código fuente en lugar de depender de elementos de demarcación normales como begin y end.

Para utilizar mod_python en SUSE Linux, instale el RPM apache2-mod_python y active el módulo mediante (Módulos) o manualmente en /etc/sysconfig/apache2. Para obtener más información sobre cómo usar el módulo, consulte la documentación disponible en el sitio Web de mod_python (http://www.modpython.org/).

mod_ruby incrusta el intérprete Ruby en el servidor Web de Apache lo que permite que los guiones CGI de Ruby se ejecuten primero. Ruby es un lenguaje de programación de alto nivel y orientado a objetos relativamente nuevo, similar en algunos aspectos a Perl y a Python. Al igual que Python, tiene una sintaxis limpia y transparente. Por otro lado, Ruby ha adoptado abreviaturas (como $.r para el número de la última línea leída en el archivo de entrada), una característica muy apreciada por algunos programadores y detestada por otros. El concepto básico de Ruby se parece mucho al de Smalltalk.

Para utilizar mod_ruby en SUSE Linux, instale el RPM apache2-mod_ruby y active el módulo mediante (Módulos) o manualmente en /etc/sysconfig/apache2. Para obtener más información sobre cómo usar el módulo, consulte la documentación disponible en el sitio Web de mod_ruby (http://www.modruby.net/en/index.rbx).

mod_dav ofrece las funciones de WebDAV (versión y autoría distribuidas basadas en Web) para Apache. WebDAV es una extensión del protocolo HTTP que permite a los usuarios editar y gestionar archivos juntos en servidores remotos. Las funciones de WebDAV son similares a las de FTP pero con la diferencia principal de que HTTP se usa como protocolo subyacente para el acceso al servidor. En efecto, mod_dav hace de un servidor Web de Apache un sistema de archivos remoto avanzado.

Es aconsejable, si no necesario, limitar el acceso a los directorios disponibles mediante WebDAV. Las precauciones mínimas son configurar la autenticación básica de HTTP para el recurso WebDAV junto con las cláusulas de limitación dentro de la directiva Location (Ubicación).

Para acceder al recurso WebDAV, el software de WebDAV tiene que estar presente en el lado del cliente. SUSE Linux ya tiene incorporadas las funciones de WebDAV: Se puede emplear Konqueror con el prefijo webdav:// o webdavs:// (para WebDAV con conexiones SSL) para conectar con un sistema de archivos WebDAV de Apache.

mod_dav necesita el módulo mod_dav_fs, que ofrece el acceso real al sistema de archivos para WebDAV. Para usar mod_dav en SUSE Linux, active el módulo mediante YaST (Módulos) o manualmente en /etc/sysconfig/apache2. Haga lo mismo para mod_dav_fs. Para obtener más información sobre cómo usar el módulo, consulte la documentación disponible en el sitio Web de mod_dav (http://httpd.apache.org/docs-2.0/mod/mod_dav.html).

mod_userdir en SUSE Linux ofrece por defecto los contenidos de cada carpeta ~/public_html de los usuarios como páginas Web públicas. La URL para acceder a esas páginas es http://www.ejemplo.com/~nombreusuario/.

	Sugerencia
mod_userdir en SUSE Linux prohíbe el acceso a cualquier directorio del directorio personal del usuario Root por razones de seguridad. Además, puede permitir específicamente sólo a algunos usuarios tener páginas personales públicas mediante: # Main server context UserDir disabled UserDir enabled tux wilber

Para usar mod_userdir en SUSE Linux, active el módulo mediante YaST (Módulos) o manualmente en /etc/sysconfig/apache2. Para obtener más información sobre cómo usar el módulo, consulte la documentación disponible en el sitio Web de mod_userdir (http://httpd.apache.org/docs-2.0/mod/mod_userdir.html).

Con frecuencia se hace referencia a mod_rewrite como “la navaja suiza de la manipulación de direcciones URL”. Vuelve a escribir las direcciones URL pedidas sobre la marcha según un conjunto de reglas definidas. El resultado normalmente se parece a http://www.ejemplo.com/2/1/de para http://www.ejemplo.com/display.php?cat=2&article=1&lang=de.

En la URL Rewriting Guide (Guía de reescritura de URL) se explican las ventajas y desventajas de este potente aunque complejo módulo:

“Con mod_rewrite pueden ocurrir dos cosas: o se da de bruces la primera vez que lo usa y nunca lo vuelve a utilizar o cae rendido a sus pies debido a su potencia.”

Los conjuntos de RewriteRule pueden definirse en todos los contextos de configuración: para el servidor principal, hosts virtuales, directorios y para los archivos .htaccess. Una buena manera de comenzar con la reescritura de URL de mod_rewrite es la guía de reescritura de URL de http://httpd.apache.org/docs-2.0/misc/rewriteguide.html.

Para usar mod_rewrite en SUSE Linux, active el módulo mediante YaST (Módulos) o manualmente en /etc/sysconfig/apache2.