Bien, con un sencillo paso tendremos este cliente de base de datos instalado en nuestra máquina:

ahornero@6581-D:~$ sudo apt-get install phpmyadmin

Después reiniciamos el servidor:

ahornero@6581-D:~$ sudo service apache2 restart

Y listo. Si tenemos algún problema accediendo a: http://elnombredetuhost/phpmyadmin crearemos la siguiente ruta simbólica:

ahornero@6581-D:~$ sudo ln -s /usr/share/phpmyadmin /var/www/phpmyadmin

El servidor más famoso para estas tecnologías es Apache Tomcat. Veamos cómo instalarlo de forma manual en cualquier distribución. Digo manual porque en los repositorios de Ubuntu no aparece ningún paquete preparado de esta versión, la 7. Suponemos que tenéis instalado Java en vuestro equipo.

Descarga y colocación en directorio destino

Lo primero será acceder a la web oficial de Tomcat y en el menú de la izquierda elegir descargas de la versión 7.0. Bajamos a Binary distributions y elegimos dentro de Core, la versión .tar.gz.

Lo descomprimimos con nuestro interfaz gráfico o mediante comando:

$ tar xvzf apache-tomcat-7.1.4.tar.gz

Y continuamos el proceso. Creamos un directorio adecuado para albergarlo:

$ sudo mkdir /usr/share/tomcat7

Ahora es el momento de mover el contenido:

$ sudo mv apache-tomcat-7.1.4/ /usr/share/tomcat7

Configuración de variables de entorno

Ahora debemos configurar las variable de entorno, pero antes, debemos saber dónde tenemos instalado tanto la JDK (Java Development Kit) como la JRE (Java Runtime Environment). Para ello, usamos la información adquirida en esta entrada de cómo saber la ruta de los ficheros que instala un paquete. Los paquetes a buscar serán en este caso (si usáis la JDK y la JRE de Sun/Oracle) los siguientes:

• sun-java6-jdk
• sun-java6-jre

Las rutas en mi caso son:

• sun-java6-jdk: /usr/lib/jvm/java-6-sun-1.6.0.24/jre
• sun-java6-jre: /usr/lib/jvm/java-6-sun-1.6.0.24/jre

Ahora agregamos al fichero de arranque del sistema (para editarlo tenéis la orden abajo):

$ sudo gedit /usr/share/tomcat7/bin/catalina.sh

Las siguientes líneas:

#!/bin/sh
JAVA_HOME="/ruta/jdk"
JRE_HOME="/ruta/jre"
...

Configuración de los usuarios

Editamos ahora el fichero: /usr/share/tomcat7/conf/tomcat-users.xml para introducir un nuevo usuario que será el gestor de la administración web:

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
 <role rolename="manager-gui"/>
 <user username="usuario" password="contrasena" roles="manager-gui"/>
</tomcat-users>

Arranque y parada del servidor

Arranque:

sudo /usr/share/tomcat7/bin/startup.sh

Parada:

sudo /usr/share/tomcat7/bin/shutdown.sh

Una vez hecho esto (el arranque), podemos acceder a http://localhost:8080 (el puerto por el por defecto escucha Tomcat) y comprobar que el proceso ha funcionado correctamente:

Para instalar LAMP (Linux Apache MySQL PHP) muchos de vosotros usaríais el selector de paquetes por tareas del gestor de paquetes Synaptic, pero en esta versión de Ubuntu y en la anterior no existe el paquete, así que tendremos que instalarlo manualmente.

La tarea, al igual que en el caso que os mencionaba antes, es bien sencilla, desde la terminal, instalamos el paquete tasksel, el mismo que utiliza Synaptic internamente para realizar esta tarea:

ahornero@6581-D:~$ sudo apt-get install tasksel

Ahora lanzamos la herramienta, ya sea directamente desde la misma terminal o a través de Synaptic, aquí lo veremos con la primera opción que es más directa:

ahornero@6581-D:~$ sudo tasksel

Seleccionamos la tarea LAMP, que se encargará automáticamente de instalarnos todos los paquetes y dependencias necesarias:

y luego no solicitará un contraseña para el administrador de la base de datos:

Una vez terminada la instalación, vamos a comprobar que todo funciona como esperamos, así que crearemos un fichero test.php en el directorio /var/www/, donde por defecto se encuentra nuestra web.

Cambiamos los permisos del directorio,

ahornero@6581-D:~$ cd /var/www/
ahornero@6581-D:/var/www$ sudo chown -R ahornero .
[sudo] password for ahornero: *******

y creamos el fichero test.php incluyendo la siguiente línea,

ahornero@6581-D:/var/www$ nano test.php

Finalmente, reiniciamos el servidor Web

ahornero@6581-D:~$ sudo /etc/init.d/apache2  restart
* Restarting web server apache2 … waiting [ OK ]

¡Y terminamos! Al entrar en la dirección http://localhost/test.php nos tenemos que encontrar algo similar a esto:

Bien, espero vuestros comentarios y dudas.

Estas conexiones las hará un script en PHP por lo que además, deberemos instalar OCI (Oracle Call Interface) para PHP. Suponemos que está ya instalado el servidor web Apache 2 y los componentes básicos de PHP.

Instalación de Oracle instantclient

Antes de instalar el instantclient como tal, debemos instalar la librería libaio, necesaria para gestionar entradas/salidas asíncronas al kernel. La instrucción será (utilizo “#” en el prompt para indicar como superusuario, “$” en caso contrario):

# yum install libaio1

O si usamos una distribución que use APT:

# apt-get install libaio1

Lo siguiente será acceder al portal de descargas de Oracle y descargar los componentes necesarios para el instantclient:

• Basic
• Devel
• SQLPlus

Elegimos la última versión, nuestra arquitectura  y descargamos los paquetes RPM. La instalación será inmediata si tenemos una distribución basada en Red Hat:

# yum install paquete.rpm

En caso contrario, deberemos instalar alien previamente para que convierta los paquetes RPM en paquetes DEB:

# apt-get install alien

# alien paquete.rpm

# dpkg -i paquete.deb

Ahora ya nos tocar configurar el famoso fichero Tnsnames.ora. Este fichero variará de una configuración a otra por lo que sólo vamos a comentar dónde situarlo. Su ruta debe ser: /etc/oracle/tnsnames.ora, en caso de no existir, deberemos crearla.

Para terminar, deberemos crear unas variables de entorno. Para ello accedemos al fichero /root/.bashrc como superusuario e incluimos las siguientes líneas:

export TNS_ADMIN=/etc/oracleexport SQLPATH=/usr/lib/oracle/11.1.0.1/client/binexport LD_LIBRARY_PATH=/usr/lib/oracle/11.1.0.1/client/lib:$LD_LIBRARY_PATHexport PATH=$PATH:$SQLPATH

En algunas distribuciones, también podréis hacer ese cambio en otro fichero: /etc/environment.

Instalación de OCI en PHP

Ahora nos toca la parte de PHP, es decir, instalar los componentes necesarios para poder hacer llamadas a Oracle desde PHP usando el instantclient que acabamos de instalar (con lo fácil que es hacer esto mismo con MySQL o PostgreSQL…, las cosas del software cerrado).

Suponemos que tenemos instalado Apache2 y PHP, pero aún así instalaremos dos paquetes más:

# yum install php-pear php5-dev

# apt-get install php-pear php5-dev

PHP-PEAR es según definen sus siglas: PHP Extension and Application Repository, es decir, un repositorio de extensiones y aplicaciones para PHP que nos permite instalar sin problemas ciertos componentes de PHP que no podemos instalar a través de nuestro gestor de paquetes habitual (me recuerda a CPAN con Perl, pero esa es otra historia para otra entrada).

Ya estamos en disposición de ejecutarlo para instalar OCI:

pecl install oci8

En la terminal nos aparecerá algo así como:

1-1, ‘all’, ‘abort’, or Enter to continue:

Pulsamos “1″ luego ENTER y escribimos las siguientes opciones (debemos saber el PATH exacto de nuestras librerías Oracle, cambiará en función de la versión):

shared,instantclient,/usr/lib/oracle/mi_version/client/lib/

PHP-PEAR descargará, configurará, compilará e instalará el módulo. Finalmente, tenemos que añadir a nuestro fichero php.ini una línea para que cargue la librería dinámica de OCI y puedan hacerse llamadas desde los ficheros PHP.

La ruta del fichero será: /etc/php5/apache2/php.ini y la línea a agregar junto a las demás extensiones la siguiente:

extension=oci8.so

Reiniciamos el servidor web y listo:

services httpd restart

O:

/etc/init.d/apache2 reload

El certificado utilizado es autogenerado y suponemos que tenemos ya instalado Apache.

Instalación de OpenSSL y mod_ssl

Lo primero que necesitamos es tener instalado el software necesario, para ello a través de yum hacemos lo siguiente:

yum install mod_ssl openssl

Generación del certificado

Primero generamos la clave privada, elegimos algoritmo RSA y 1024 bits:

openssl genrsa -out ca.key 1024

Ahora generamos el CSR (Certificate Signing Request), un fichero que crea una entidad para pedirle a una tercera que lo firme, verificando así que los datos de la primera entidad son correctos. De esta forma unas entidades van certificando a otras creando una cadena de certificación, donde la primera entidad de llama la raí­z de certificación.

openssl req -new -key ca.key -out ca.csr

Finalmente, nos autofirmamos el certificado:

openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt

Le hemos puesto un período de validez de un año, pero podéis cambiar a vuestro gusto este tiempo. OpenSSL os pedirá una serie de datos sobre el certificado y su entidad emisora (vosotros): correo electrónico, ciudad, país… a través de un interfaz en texto.

Cambio de rutas

El siguiente paso es mover los ficheros de la firma que acabamos de generar a la ruta correcta.

mv ca.crt /etc/pki/tls/certs
mv ca.key /etc/pki/tls/private/ca.key
mv ca.csr /etc/pki/tls/private/ca.csr

Configuración de Apache

Ya estamos listos para comenzar con la configuración de Apache. En las versiones más modernas de Apache, el fichero de configuración viene dividido en varios ficheros separados por temática para un acceso más rápido a la parte deseada. El fichero que vamos a editar es el siguiente: /etc/httpd/conf.d/ssl.conf.

Buscamos las siguientes líneas y le asignamos el valor correcto (no tienen por qué estar seguidas una de la otra):

SSLCertificateFile /etc/pki/tls/certs/ca.crt
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

Host virtual

Para terminar crearemos un host virtual donde indicaremos a Apache dónde buscar las peticiones dirigidas al puerto 443 (las peticiones HTTPS). Definimos un host virtual al final de /etc/httpd/conf/httpd.conf:

NameVirtualHost *:443

Y luego la definición de las características en sí:

<VirtualHost *:443>
        SSLEngine on
        SSLCertificateFile /etc/pki/tls/certs/ca.crt
        SSLCertificateKeyFile /etc/pki/tls/private/ca.key
        AllowOverride All
        DocumentRoot /var/www/httpsdocs
        ServerName nombresitio.com
</VirtualHost>

Reiniciar el servicio

Para que los cambios tengan validez, deberemos reiniciar el servicio:

service httpd restart

Y ya tendremos listo el sitio seguro. Tened en cuenta que como la firma es autogenerada, los navegadores no la contemplarán como segura y aparecerá la típica pantalla de “Error SSL” o similar, que seguro que conocéis.

Una de las acciones básicas de cara a mejorar la seguridad de un sitio web, es evitar que el servidor devuelva los listados del contenido de los directorios que son públicos. Una solución popular es incluir un fichero index.html vacío en todos los directorios que no deben ser listados o que no tienen un fichero que realice alguna función. Si estamos hablando de un sitio web con cientos o miles de directorios, esta opción queda descartada directamente.

.haccess

La alternativa es simple si estamos usando un servidor web Apache, utilizar las bondades del fichero .htaccess. La opción más directa es deshabilitar todos los listados de directorios en nuestro sitio.

Desactivar listados

En el raíz de nuestro sitio, creamos un fichero .htaccess (o añadimos al que ya tenemos) la siguiente línea:

Options -Indexes

De esta forma evitamos los listados en cualquier directorio de nuestro sitio. La opción contraria, para un directorio en particular o porque queramos habilitar esta característica en un sitio donde el proveedor la tiene deshabilitada por defecto es la siguiente:

Options +Indexes

Estilo de los listados

Si lo que queremos es tener el listado, tenemos dos opciones, mostrar la lista básica de ficheros:

IndexOptions -FancyIndexing

O mostrar más información: fechas de modificación, tamaño de ficheros, iconos…:

IndexOptions +FancyIndexing

Ignorar ciertos tipos de ficheros

Otra opción a tener en cuenta es la de ignorar ciertos tipos de ficheros, de forma que podamos listar por ejemplos el contenido multimedia, obviando los ficheros PHP o HTML. Para este ejemplo usaríamos la siguiente instrucción:

IndexIgnore *.php *.html

Finalmente, podemos mostrar un listado en blanco, es decir, ignorar todos los ficheros. Es otra alternativa a impedir los listados.

IndexIgnore *

A pesar de su pequeño tamaño, soporta:

• HTTP/1.1
• Conexiones seguras SSL/TLS (HTTPS)
• Compresión HTTP on-the-fly
• Generación de contenido dinámico a través de CGI y scripts FastCGI
• Extensiones ISAPI
• Soporte nativo de ASP.NET
• XSSI
• Páginas de error personalizadas
• Control sobre las direcciones IP de entrada
• Anti-leeching
• Límite de ancho de banda.

También cuenta con un sistema automático de baneo de IP, así como con una interfaz de gestión remota vía web, que hace que su configuración sea tan sencilla como navegar por una web; quizás este último aspecto sea la característica diferenciadora con Apache.

También podemos ejecutar PHP, Perl, Python, ASP, ASP.NET, y Ruby on Rails; y acceso a bases de datos tales como MySQL, SQLite, MS SQL Server, MS Access, u Oracle. Lo cual supone una ventaja cuando hablamos de servidores Linux que desean soporte sobre un entorno Windows, y hablo de conexiones MS SQL Server y ASP, ya que ASP.net lo podremos soportarte nativamente con Mono y también con Apache.

La desventaja, no es libre, y para disponer de soporte hay que hacerse con una licencia. Ya sabeís que no soy partícipe de rechazar aplicaciones por el mero hecho de ser de pago, creo que es un negocio que no hay que menospreciar, y menos cuando tienen total compatibilidad con entornos Linux y FreeBSD.

Descarga en Aprelium.

El caso que os enuncio a continuación es el de la instalación del CMS WordPress sobre una máquina Ubuntu 10.04, aunque la metodología es completamente aplicable a cualquier uso de las directivas dentro de .htaccess sobre cualquier máquina que corra Apache2 y cualquier sistema sobre él mismo.

En este caso tenemos nuestro sistema WordPress ya instalado sobre el directorio /var/www/, nos dirigimos al panel de administración, y dentro del menú Settings, en Permalinks. En este caso, lo que queremos es usar los Pretty Permalinks, así seleccionaremos, por ejemplo:

Day and name http://www.linuxhispano.net/2010/11/24/sample-post/

Entonces, guardamos los cambios y podemos encontrarnos con el error de que no se ha podido escribir el archivo .htaccess en la raíz del directorio. Este tiene la siguiente forma:

RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ – [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Lo que indica este fichero es que las peticiones por GET que se realicen bajo el index.php sean sustituidas por barras simples /, obteniendo de esta manera una URL más elegante.

Para darle permisos a WordPress para escribir en el directorio (nota: estos permisos también sirven para la actualización e instalacion de plugins), tenemos dos opciones. Nos dirigimos a la entrada que escribió Carazo sobre los permisos en los directorios de WordPress o cambiamos los permisos del directorio completamente haciendo uso del usuario de Apache. Para hacerlo de la segunda forma:

sudo chown -R www-data:www-data /var/www

www-data es, por defecto, el nombre de usuario de Apache, así, nos despreocupamos en adelante de permisos sobre el directorio /var/www/.

Bien, haciendo este cambio ya tenemos permisos para generar el archivo .htaccess desde el CMS, ahora, y una vez activado nos damos cuenta de que sigue sin funcionar, en este caso no se nos avisa de que el cambio no haya surtido efecto ya que WP si ha podido escribir el fichero, pero es Apache quien no logra interpretarlo, de ahí que los enlaces no funcionen.

Una de los problemas que podemos tener es que el módulo mod_rewrite no este activado / instalado, para hacerlo tenemos dos posibilidades. Las dos son igualmente aceptables, ya dependerá de cómo queremos hacerlo:

Instalación sencilla de mod_rewrite

Sencilla, y mucho:

ahornero@6581-D:~$ sudo a2enmod rewrite

Y reiniciamos el servidor:

ahornero@6581-D:~$ sudo /etc/init.d/apache2 restart
[sudo] password for ahornero:
* Restarting web server apache2 … waiting [ OK ]

Instalación menos sencilla de mod_rewrite

Usamos el comando locate para buscar si el módulo mod_rewrite.so está disponible en nuestro servidor:

ahornero@6581-D:~$ updatedb
ahornero@6581-D:~$ locate mod_rewrite.so

En en caso de Ubuntu 10.04 LTS lo encontraremos en /usr/lib/apache2/modules. Ahora nos dirigimos al directorio mod-enabled y tenemos nuevamente dos opciones, o creamos un enláce simbólico al archivo (con ln -s) o:

ahornero@6581-D:~$ cd /etc/apache2/mods-enabled
ahornero@6581-D:~$ touch rewrite.load
ahornero@6581-D:~$ nano rewrite.load

Y pegamos la siguiente línea (usando las rutas que antes hemos visto):

LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so

Y reiniciamos el servidor (se hace evidente):

ahornero@6581-D:~$ sudo /etc/init.d/apache2 restart
[sudo] password for ahornero:
* Restarting web server apache2 … waiting [ OK ]

Continuación de la instalación

Bien, de una forma u otra ya hemos instalado el módulo de Apache mod_rewrite, ahora si probamos nuestra Web es posible que nos funcione o no. En caso de no hacerlo, no va a ser por no tener activado este módulo, evidentemente podemos comprobarlo creándonos un fichero PHP, por ejemplo php_info.php, y haciendo una llamada a la función phpinfo(); así veremos cómo el módulo está activado.

Lo más seguro es que la directiva AllowOverride esté deshabilitada dentro del marco en que nos encontramos, es decir, sobre el directorio /var/www definido dentro del archivo de configuración de Apache. Para solucionarlo, bastará con editarlo de la siguiente manera:

Para Ubuntu 10.04:

ahornero@6581-D:~$ sudo gedit /etc/apache2/sites-available/default

Y lo editamos, de forma que el tag Directory para la ruta /var/www (o la que corresponda en vuestro caso) quede de la siguiente manera:

Options Indexes FollowSymLinks MultiViews
AllowOverride all
Order allow,deny
allow from all

Siendo clave el tema del AllowOverride all, ya que esto es lo que da o no paso a la configuración mediante ficheros .htaccess dentro del directorio sobre el que nos ubicamos.

De igual manera lo haremos sobre cualquier distribución sobre el fichero de configuración, comúnmente http.conf, dentro del directorio /etc/apache2/conf/

Y bien, sea cual sea nuestro caso, hemos de reiniciar el servidor Apache para que los cambios surtan efecto:

ahornero@6581-D:~$ sudo /etc/init.d/apache2 restart
[sudo] password for ahornero:
* Restarting web server apache2 … waiting [ OK ]

Y listo. ¿Alguna duda?

ahornero@6581-D:~$ sudo /etc/init.d/apache2 restart
* Restarting web server apache2 apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName
… waiting apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName

¿Cómo solucionarlo?

Por defecto, en Apache2 sobre Unix, el archivo httpd.conf deberá estar en blanco. Para solucionar este warning, lo editamos:

ahornero@6581-D:~$ sudo nano /etc/apache2/httpd.conf

Y añadimos la siguiente línea:

ahornero@6581-D:~$ ServerName nombre_o_ip_del_servidor

Guardamos, reiniciamos el servicio y listo.

ahornero@6581-D:~$ sudo /etc/init.d/apache2 restart

¿Por qué hablamos hoy de él? Porque Microsoft ha decidido liberarlo bajo una licencia Apache y está disponible dentro de Codeplex (el repositorio de la empresa de Redmond para proyectos de código abierto) el código del compilador y las librerías básicas del lenguaje.

¿Por qué comento esto? Porque de un tiempo para acá, estoy comprobando que Microsoft se está portando con la Comunidad mejor que otras empresas que en otros tiempos eran más aliadas del código libre como Oracle y Apple.

Estoy bastante asustado por el futuro de Java, MySQL y OpenOffice; pero noticias como ésta, aunque sean granos de arena en el desierto, son positivas.

Un par de ejemplos de F# antes de terminar:

(* Esto es un comentario *)
(* Ejemplo de típico ¡Hola Mundo! *)
printfn "Hello World!"

Y una recursividad básica para calcular el factorial:

let rec factorial n =
    match n with
    | 0 -> 1
    | _ -> n * factorial (n - 1)

La tarea es bien sencilla, desde un terminal, instalamos el paquete tasksel, el mismo que utiliza Synaptic internamente para realizar esta tarea:

ahornero@6581-D:~$ sudo apt-get install tasksel

Y lanzamos la herramienta, ya sea directamente desde la consola con el binario tasksel (que invoca internamente a APT) o a través de Synaptic, aquí lo veremos con la primera opción que es más directa:

ahornero@6581-D:~$ sudo tasksel

Seleccionamos la tarea LAMP, que se encargará automáticamente de instalarnos todos los paquetes y dependencias necesarias:

y luego no solicitará un contraseña para el administrador de la base de datos:

Para comprobar que todo ha ido bien, crearemos un fichero test.php en el directorio /var/www/, que es donde por defecto se alojará nuestra web.

cambiamos los permisos del directorio fijándonos como propietario,

ahornero@6581-D:~$ cd /var/www/
ahornero@6581-D:/var/www$ sudo chown -R ahornero .
[sudo] password for ahornero: *******

ahora creamos el fichero test.php e incluimos la siguiente línea,

ahornero@6581-D:/var/www$ nano test.php

reiniciamos el servidor Web

ahornero@6581-D:~$ sudo /etc/init.d/apache2  restart
* Restarting web server apache2 … waiting [ OK ]

y voilà! Debería de funcionar como se muestra en la siguiente imagen desde el navegador:

Espero que te haya sido de gran ayuda, ¿has tenido algún problema?

Hace ya unos cuantos meses escribí para Linux+ un artículo sobre esto que os comento hoy, una introducción al desarrollo de aplicaciones web con Mono. Concretamente fue en el número de febrero. Ha pasado el tiempo y la editorial ha tornado sus miras hacia un entorno más abierto. Primero fue el lanzamiento de la revista en formato PDF y de distribución gratuita (antes era de papel y costaba unos cuantos euros) y ahora han lanzado un blog, llamado Revista Linux, donde irán publicando los artículos más relevantes de la revista en formato post, lo que seguro que tanto vosotros como los motores de búsqueda lo agradeceréis.

Uno de los primeros artículos que han publicado es este que os comento, aquí tenéis el enlace al mismo y un desglose de su contenido.

Introducción al desarrollo de aplicaciones web con Mono

1. Introducción
2. Preparación e instalación
   1. XSP
   2. Apache con mod_mono
      1. Instalación
      2. Prueba
      3. Eliminación de un sitio
3. Ejemplos de interacción con MySQL
   1. Instalación de la base de datos y creación de los datos de ejemplo
   2. Descarga y activación del conector
   3. Código del ejemplo y archivo de configuración
   4. Aplicando estilos
4. Conclusiones

¿Por qué escoger este binomio en lugar de XSP? La respuesta es fácil: XSP es un servidor de pruebas, no de producción y si queremos tener un servicio o aplicación web ejecutando de forma decente en producción, mejor utilizar Apache y mod_mono. Las razones no son sólo por la escalabilidad y eficiencia que permite Apache, sino que están relacionadas por la seguridad que provee el servidor más utilizado a nivel mundial y por la gran variedad de opciones que nos ofrece.

De todas maneras sigo pensando que al igual que el servidor de pruebas de Django es útil para las pruebas, XSP es un buen servidor de pruebas para practicar con nuestro PC cuando estemos aprendiendo ASP.NET. Cuando la aplicación se hace compleja y sobre todo queramos pasarla a producción, Apache.

Instalación y configuración

Construir lighttpd desde cero es un poco más complicado, ya que depende de otras bibliotecas. Como mínimo, necesita la versión de desarrollo (la versión que incluye los archivos de cabecera) de expresiones regulares compatibles con la biblioteca de Perl (PCRE) y la herramienta de compresión zlib. Después de haber instalado estas bibliotecas, la compilación de lighttpd es sencilla:

$ # Lighttpd requires libpcre3-dev and zlib1g-dev
$ wget http://www.lighttpd.net/download/lighttpd-1.4.24.tar.gz
$ tar xzf lighttpd-1.4.22.tar.gz
$ cd lighttpd-1.4.22
$ ./configure && make && sudo make install

Una vez compilado, hemos de crear nuestro archivo de configuración. La configuración más minimalista posible establece la raíz del documento (document root), el puerto del servidor (server port), algunos tipos MIME (Multipurpose Internet Mail Extension), el usuario por defecto (default user) y un grupo para el demonio (daemon):

server.document-root = “/var/www/lighttpd/miDirectorioHost”
server.groupname = “www”
server.port = 80
server.username = “www”

mimetype.assign = (
“.html” => “text/html”,
“.txt” => “text/plain”,
“.jpg” => “image/jpeg”,
“.png” => “image/png”
)

static-file.exclude-extensions = ( “.fcgi”, “.php”, “.rb”, “~”, “.inc” )
index-file.names = ( “index.html” )

Considerando que hemos guardado nuestro archivo de texto como /opt/etc/lighttpd.conf, para lanzar lighttpd bastará con invocarlo y pasarle dicho archivo de configuración:

lighttpd -D -f /opt/etc/lighttpd.conf.

Al igual que Apache, lighttpd puede servir servidores vituales (virtual hosts). Y en solo tres líneas y usando un condicional:

$HTTP["host"] == “www2.linuxhispano-ejemplo.net” {
server.document-root = “/var/www/lighttpd/miDirectorioHostVirtual
}

De esta manera, si accedemos www2.linuxhispano-ejemplo.net, usaremos la alternativa planteada.

Lighttpd es especialmente hábil en el manejo de un gran número de peticiones en paralelo. Y al igual que Apache, podemos usarlo conjuntamente con Ruby on Rails (RoR), PHP, etc.

Artículos relacionados.
Artículo original en  IBM Developer Works.

Para instalar Apache 2, ejecuta en el terminal de tu consola:

sudo apt-get install apache2

Para comprobar que funciona perfectamente ejecuta:

sudo /etc/init.d/apache2 restart

Ubuntu a veces no define el nombre del servidor para Apache así que es bueno que lo hagamos. Edita apache2.conf:

sudo gedit /etc/apache2/apache2.conf

y añade esta línea:

ServerName "your-server-name"

que debería ir cerca a esta línea:

ServerRoot "/etc/apache2"

En realidad no necesitaremos este nombre del servidor pero vale la pena para evitar que Apache escupa advertencias en cada reinicio.

Para comprobar que todo está en orden entra desde un navegador a:

http://localhost