Posts Tagged servidor web
Subir vídeos a YouTube con Zend Gdata
Posted by Xavi in Programación Web, Redes sociales on 24/08/2009
Aunque no sea difícil seguir los tres artículos relacionados con la subida de vídeos a You Tube (se encuentran todos a continuación) os dejo la referencia a los tres apuntes:
Y algunos enlaces de interés:
Problemas para conectar con MySQL Server
Posted by Xavi in Bases de datos, Linux on 21/08/2009
Intentando conectar con un MySQL Server que tenemos en el servidor de desarrollo de la oficina nos hemos dado cuenta de que por defecto no se puede acceder a este sistema gestor de base de datos desde un ordenador que no sea ‘localhost’ o ’127.0.0.1′ (en la versión 5.1 por lo menos).
El error que recibíamos no era ni culpa del router (que es un Zyxel de Telefónica y no sería le primer problema que nos da), ni del firewall por defecto de Ubuntu (ufw, Uncomplicated FireWall) ni nada parecido, el error era culpa nuestra.
La instalación del servidor de desarrollo de la oficina se hizo un viernes de Agosto cerca de la una del mediodía y con las prisas para salir corriendo hacía la playa nos olvidamos mirar los archivos de configuración del servidor de MySQL. El archivo de configuración de MySQL (por defecto alojado en /etc/mysql/my.cnf en Ubuntu) contiene por defecto la siguiente directiva:
bind-address = 127.0.0.1Con lo que se bloquean todas las conexiones al servidor que no se hagan desde esta dirección. Para solucionar el problema sólo hace falta comentar esta línea:
#bind-address = 127.0.0.1Y reiniciar el servicio (desde la consola):
sudo /etc/init.d/mysql restart
Este apunte es solo un pequeño paréntesis en la serie de artículos referentes a Subir vídeos a YouTube con Zend Gdata – Requisitos previos y Identificación del usuario, pronto volveremos con el último de la saga!
Autenticar un usuario en Zend Framework – Identificar usuario
Siguiendo el hilo del apunte anterior vamos a ver como identificar un usuario una vez programado el adaptador.
El componente Zend_Auth implemente el patrón Singleton de diseño. Esto quiere decir que en todo momento sólo tendremos una instancia de esta classe y que para obtenerla deberemos utilizar su método estático getInstance(). La instancia de Zend_Auth será la que utilizaremos para identificar al usuario una vez obtengamos sus datos.
Formulario para identificar
Para identificar un usuario, en nuestro caso, nos hace falta conocer su nombre de registro (nickname, mail o lo que se utilice) y su contraseña. Con un formulario estándar nos bastará:
<form action="/authentication/login" method="post">Podemos observar que el formulario apunta al controlador AuthenticationController y la acción loginAction. Aquí es dónde identificaremos el usuario.
<input type="text" name="username"/>
<input type="password" name="pwd"/>
</form>
Identificar el usuario en el controlador
Para identificar al usuario deberemos implemetar la acción loginAction dentro del controlador que se encargue de identificar a los usuarios (no tiene por qué ser AuthenticationController). Veamos un ejemplo:
<?phpA partir de aquí se puede diferenciar más el comportamiento del sistema en función del $res->getCode() por ejemplo. Un switch-case nos puede servir para diferenciar un error en el nombre de usuario o en la contraseña.
class RegisterController extends Zend_Controller_Action{
...
public function loginAction(){
require_once('/path/to/AuthenticationAdapter.php');
$auth = Zend_Auth::getInstance();
/* Comprovaciones de que $_POST['username'] y
* $_POST['pwd'] existen */
if(/* Existen y cumplen las restricciones*/){
$adapt = new AuthenticationAdapter($_POST['username'], $_POST['pwd']);
$res = $auth->authenticate($adapt);
if($res->getCode() == Zend_Auth_Result::SUCCESS){
/* Esta línea es muy importante porqué es la que nos grabará los datos que hemos
* introducido en la variable $sessionData (en el post anterior) en la session */
$auth->getStorage()->write($result->getIdentity());
}
}
}
Consultar si un usuario está identificado
Una vez identificado el usuario y guardados los datos que queremos (session) tendríamos que poder acceder a esta información desde cualquier punto del sistema. Esto se puede hacer a través del método hasIdentity() del componente Zend_Auth. Veamos un ejemplo de como lo utilizaríamos si quisiéramos redirigir a la página principal un usuario que no está identificado:
/* En alguna action que no queremos que los usuarios no identificados vean */Espero que a partir de aquí podais identificar vuestros propios usuarios
$auth = Zend_Auth::getInstance();
if($auth->hasIdentity()==true){
/* Si está identificado guardaremos los datos
* que pusimos en $sessionData en la variable $identity */
$identity = $auth->getIdentity();
}else{
/* Si no está identificado lo redirigimos al document root */
$this->_redirect('/');
}
Os dejo la dirección del manual de referencia del Zend Framework porqué, una vez llegados a este punto, las posibilidades que tenemos con Zend_Auth son enormes.
Si teneis alguna duda ya sabeis, comentad!
Autenticar un usuario en Zend Framework – Crear el adaptador
Posted by Xavi in Programación Web on 30/03/2009
Después de pelearnos nuestras horas con el framework de Zend hemos conseguido identificar un usuario con las herramientas que provee este framework (Zend_Auth). La adapatación no ha sido al 100% porqué teniendo la información relativa a los usuarios en una base de datos no utilizamos el adaptador que Zend tiene empleado para estos fines (Zend_Auth_Adapter_DbTable) sino que implementamos un adaptador desde cero.
Antes de empezar a definir que nos hace falta para poner en marcha la identificación de usuario comentamos que estos pasos se han realizado en un servidor Lighttpd-MySQL-PHP5 en un sistema operativo Ubuntu 8.10. Ahora sí, vamos a ver como establecer una autentificación de usuarios:
Implementar un adaptador para autentificar usuarios
Este paso se puede modificar según el origen de la información que vayamos a usar. El framework tiene soluciones específicas para datos de acceso almacenados en base de datos, provenientes de peticiones HTTP, de un servidor LDAP o por OpenID. Como hemos comentado al principio nuestros datos estan almacenados en una base de datos pero vamos a implementar un adaptador desde cero.
Para implementar un adaptador desde cero debemos implementar la interfície Zend_Auth_Adapter_Interface, para eso deberemos implementar obligatoriamente el metodo authenticate() (por razones derivadas de la herencia) y también le añadiremos un par de cositas más. Este adaptador debe recibir la información necesaria para identificar un usuario y realizar la comprovación.
Veamos un ejemplo de la classe:
<?php
class AuthenticationAdapter implements Zend_Auth_Adapter_Interface{
private $_username = null;
private $_password = null;
public function __construct($username, $password){
$this->_username = $username;
$this->_password = $password;
}
public function authenticate(){
//TODO comprobar si $username y $password estan presentes en la base de datos
...
if(/* Estan presentes*/){
/* $sessionData es una variable con la información que queremos guardar en sessión */
return new Zend_Auth_Result(Zend_Auth_Result::SUCCESS,$sessionData);
}else{
/* Si no esta el $username */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_IDENTITY_NOT_FOUND,$sessionData);
/* Si el password es incorrecto */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE_CREDENTIAL_INVALID,$sessionData);
/* Error en la identificación por otros motivos */
return new Zend_Auth_Result(Zend_Auth_Result::FAILURE,$sessionData);
}
}
}
En el próximo post seguiremos con el controlador y como utilizar este adaptador. No falteis!
Empaquetar una instancia de EC2 en funcionamiento (I)
Posted by Xavi in Linux, Programación Web on 04/03/2009
La documentación de Amazon sobre sus servicios es, en muchos casos, bastante confusa. Por este motivo, y enlazando con un apunte anterior en el que hablabamos de crear una página web sencilla con un servidor en Amazon EC2, vamos a revisar el proceso de empaquetado (bundle) de una instancia para crear una AMI de la que podamos correr tantas instancias como nos apetezca.
¿Por qué queremos crear una propia AMI?
Normalmente las AMI que tenemos a nuestra disposición tienen una selección de software bastante estándar, por consiguiente, si el software que queremos correr difiere mucho de la selección preestablecida, sería recomendable crear una AMI propia para no tener que instalar y configurar todo el software adicional cada vez que arrancamos una instancia.
Esta AMI podrá ser completamente privada, así que podremos dejar la configuración muy ajustada a nuestro sistema para ahorrar el máximo tiempo posible en el arranque de cada máquina virtual.
En resumen podríamos decir que crear una AMI propia nos permite dejar guardada una máquina configurada con todo el software necesario para arrancar una instancia y ponernos a trabajar con un tiempo mínimo de start-up.
Prerrequisitos
Para llevar a cabo este mini-tutorial para realizar el “bundling” de una instancia de EC2 necesitaremos lo siguiente:
- Una instancia de EC2 corriendo Ubuntu 8.10
- Conocer y tener acceso a la Private-key y certificado del protocolo de identificación X.509
- Tener acceso a la instancia de EC2 por SSH (esto implica tener acceso al archivo *.pem que nos sirve de identificación en la instancia)
- Conocer las Access Key ID y Private Access Key de la cuenta de Amazon WebServices
Subir la Private Key y el Certificate a la máquina virtual
Para poder identificarnos en las operaciones que realicemos en la máquina virtual nos hará falta tener a nuestra disposción los archivos de identificación (Private Key y Certificate del protocolo X.509). Aún así debemos tener en cuenta que tendremos que subirlos a un directorio que no quede guardado cuando hagamos el empaquetado de la AMI porque sino podríamos estar esparciendo nuestros archivos secretos de identificación por todas nuestras instancias en funcionamiento (¿y eso es algo que no queremos verdad?).
El directorio dónde vamos a subir estos archivos será /mnt y lo haremos con el siguiente comando:
scp -i /ruta/a/llaves/archivo-de-identificacion.pem /ruta/a/llaves/pk-xxxx.pem /ruta/a/llaves/cert-xxxx.pem root@dns.publica.de.amazon :/mntEste comando sube los dos archivos pk-xxxx.pem y cert-xxxx.pem al directorio /mnt de la máquina virtual como usuario root utilizando el mismo sistema de identificación que utilizariamos si quisiéramos acceder por ssh.
No debería hacer falta pero señalamos que tenemos que cambiar la ruta /ruta/a/llaves por la ruta absoluta de los archivos implicados y dns.publica.de.amazon por la DNS pública de la instancia que podemos encontrar en el panel de control de Amazon EC2.
Instalación de las herramientas en la máquina virtual
Para instalar las herramientas de Amazon para gestionar las AMIs vamos a seguir un proceso que nos ha funcionado pero no tiene porqué ser el único ni el mejor. Este proceso utiliza el paquete precompilado *.rpm de Amazon y la herramienta alien para pasarlo a *.deb. Vamos a verlo paso a paso:
- Accedemos a la máquina virtual por ssh (recuerda que todas las operaciones después de esta se realizarán en la linea de comandos de la instancia en Amazon EC2):
ssh -i /ruta/a/llaves/archivo-de-identificacion.pem root@dns.publica.de.amazon - Instalamos el software que necessitamos para instalar y utilizar las AMI Tools de Amazon:
apt-get install ruby alien* es posible que nos encontremos estos dos paquetes ya instalados en la AMI correspondiente pero mejor asegurarnos. - Descargamos las AMI Tools en un directorio que luego no vaya a ser almacenado en el “bundling” como por ejemplo /tmp:
cd /tmp
wget http://s3.amazonaws.com/ec2-downloads/ec2-ami-tools.noarch.rpm - Una vez descargado el archivo rpm vamos a crear el .deb con alien y instalarlo:
alien -d ec2-ami-tools.noarch.rpm* El nombre del paquete .deb generado puede variar según las versiones del software que estemos utilizando.
dpkg -i ec2-ami-tools_1.3-31781_all.deb
Si todo ha funcionado de forma correcta ya tenemos la instancia preparada para ser empaquetada y registrada pero esto lo veremos en un post posterior (aquí).
Tu primera página web con Amazon EC2
Posted by Xavi in Linux, Programación Web on 20/02/2009
En la actualidad, Amazon posee uno de los recursos más interesantes para el hospedaje de aplicaciones web que necesiten gran escalabilidad (tanto para aumentar la capacidad de cómputo como para disminuirla y no pagar por recursos que no nos van a hacer falta). Este recurso es un grupo de servicios web entre los cuales podemos encontrar almacenamiento en S3, bases de datos muy simples con SimpleDB o, el que nos va a centrar en este post, servidores escalables en EC2 (EC2 viene de Elastic Cloud Computing).
aws-tutorial
La explicación teórica de qué es y qué no es EC2 voy a dejarla para un posible post posterior, de la misma forma, tampoco vamos a entrar a describir el proceso de alta en una cuenta de Amazon EC2, que en el fondo se trata de una simple gestión administrativa. Por consiguiente, a partir de aquí sólo vamos a cubrir el cómo visualizar una página web simple partiendo de una cuenta “virgen” de Amazon EC2.
Prerrequisitos
Los prerrequisitos para afrontar el proceso que vamos a describir son los siguientes:
- Tener localizadas los ficheros de certificado y clave privada del certificado X.509 que nos identifican en los servicios de Amazon.
- Tener acceso total a la cuenta de Amazon AWS (es lógico pero no está de más comentarlo).
Escoger y arrancar la AMI
Una vez identificados en el sistema de Amazon (ALERTA: dependiendo del navegador y el sistema operativo que estemos utilizando es posible que se nos pida nuestra identificación más de una vez en el proceso) debemos dirigirnos al ‘AWS Management Console’ y dentro de este a la pestaña ‘Amazon EC2′.
Nuestro primer objetivo cuando nos encontremos en dicha pestaña será arrancar una AMI (Amazon Machine Image, en otras palabras un servidor virtual). Esto lo podemos llevar a cabo desde el Dashboard y desde las secciones de Instances y AMIs. Sea cual sea el camino escogido iremos a parar al siguiente diálogo:
Como ya hemos comentado en anteriores posts, en este blog hay un aprecio bastante grande a Ubuntu y, por tanto, basaremos esta primera instalación en nuestra distribución favorita. En la pestaña comunity AMIs seleccionaremos sólo los sistemas de 32-bits (para poder escoger la máquina más económica posible) y el sistema operativo Ubuntu. Para la realización de este proceso yo he escogido la imagen con el manifest: alestic/ubuntu-8.10-intrepid-base-20081222.manifest.xml. Es de las primeras opciones que nos aparecen con la versión 8.10 del sistema operativo. Cuando localicemos la AMI sólo tenemos que pinchar en el link “select” y pasar al siguiente paso.
En un primer momento tendremos que crear una clave para identificar nuestras instancias (en el paso ‘Create Key Pair’). Tenemos que ir con sumo cuidado a la hora de guardar esta clave porque nos permitirá el acceso a la instancia por diferentes métodos más adelante. Después de haber creado esta instancia debemos configurar el Firewall de la máquina de forma que sea lo más segura posible pero que podamos acceder a ella por SSH (en un entorno de producción dejaríamos cerrado el puerto para posteriormente dar acceso sólo desde las IP que consideráramos seguras con las herramientas de EC2).
Para acabar de arrancar la máquina virtual sólo nos quedará definir el número de instancias (poned 1), el tipo (poned small, la más barata), seleccionar la Key Pair que acabámos de crear para identificar la instancia y dejar seleccionados los dos grupos en Security groups. No vamos a entrar en las opciones avanzadas porque para mostrar una página web estática no nos afectan pero existe un gran abanico de posibilidades para configurar las AMIs que queremos arrancar.
Una vez pulsado el botón “Launch” vamos a tener que esperar unos segundos para que la máquina arranque definitivamente.
Conectarse de forma remota a la instancia
En la sección de Instances ahora deberíamos ver un registro nuevo (con el status running) que podemos seleccionar. Una vez seleccionado, si hacemos click en el botón Connect nos dará los datos para acceder a la máquina via SSH.
El ejemplo de comando que nos ponen en el diálogo que se abre cuando hacemos click en Connect es un buen ejemplo, si sustituimos el nombredelakeypair.pem por el path completo donde está este archivo en nuestro ordenador podremos acceder a la instancia sin ningún problema. En Ubuntu el path podría ser /home/user/Keys/nombredelakeypair.pem
Instalar un servidor web
Para poder mostrar una página web deberemos instalar un servidor web en la instancia. Podemos decantarnos por Apache2 o Lighttpd para poner un par de ejemplos. En la consola de la instancia con ejecutar el siguiente comando tendríamos el servidor Lighttpd corriendo sin más problemas:
sudo apt-get install lighttpd*En el post anterior hay una explicación más extensa de las posibilidades de este servidor web.
Dar acceso a través del puerto 80 a la instancia
Una vez instalado el servidor web, si nos dirijimos a la DNS pública que nos indica el panel de instancias veremos como el navegador no acaba de encontrar la página que deseamos. Esto es porque por defecto las instancias tienen cerrados los puertos de comunicación (al pagarse por tráfico es conveniente que estén cerrados por defecto). Para poder abrir estos puertos debemos tener instaladas las herramientas de EC2 en nuestro ordenador local.
El siguiente apartado sólo está probado sobre Ubuntu 8.10 y por lo tanto no puedo asegurar que funcione ni en otras versiones de la misma distribución:
Para instalar las herramientas de EC2 en nuestra Ubuntu 8.10 debemos seguir estos pasos:
- Instalar la versión 5 de Java (pero la versión de Sun, nada de OpenJDK)
- Descargar la herramientas de su web (podeis encontrar el enlace en su guia)
- Descomprimir las herramientas en un directorio accesible
- Seguir las intrucciones de como setear las herramientas que hay en el apartado Setting up the Tools de la guía oficial. NOTA: En Ubuntu, antes de empezar a ejecutar el comando ‘export’ debemos ejecutar el comando ‘bash’ para que arranque este interprete y no intentar lanzar las instrucciones con el comando ‘sudo’ se deben introducir todas los comandos tal como se exponen en la web de Amazon.
- Una vez instaladas las herramientas sólo debemos correr el comando siguiente y ya podremos acceder a la página web de ejemplo del servidor que hayamos instalado en la instancia de Amazon
bash*Esto es un recopilatorio de los comandos que se tienen que ejecutar POR SEPARADO. Para saber el significado de cada uno consulta la sección Setting up the Tools de la guía.
export EC2_HOME=/ruta/a/las/herramientas
export PATH=$PATH:$EC2_HOME/bin
export EC2_PRIVATE_KEY=/ruta/a/las/claves/pk-XXXXXXXXXXXXXXXXX.pem
export EC2_CERT=/ruta/a/las/claves/cert-XXXXXXXXXXXXXXXXX.pem
ec2-authorize default -p 80A partir de aquí… lo dejo a vuestra imaginación.
Lighttpd y la vida después de Apache
La programación de sitios web dinámicos en PHP va casi siempre asociada al servidor Apache pero, en ocasiones, se puede recurrir a alternativas para mejorar el rendimiento de las aplicaciones web. En el presente artículo explicaremos la instalación del servidor Lighttpd en un sistema Ubuntu 8.10 para proyectos en PHP (compatibles con el Zend Framework).
Lighttpd es un servidor web más ligero que Apache que aporta un plus de rendimiento muy conveniente en según que entornos. El primer paso que vamos a describir se debe realizar sólo en el caso de que tengamos instalado un Apache 2 en el servidor.
Eliminar Apache 2 del servidor
Para eliminar este servidor del equipo podemos recurrir a la linea de comandos o al gestor de paquetes Synaptic. Para la línea de comandos deberemos ejecutar la siguiente orden y aceptar que nos desinstale todas las dependencias:
sudo apt-get remove apache2.2-commonPara el gestor Synaptic tendremos que localizar el paquete apache2.2-common, marcarlo para eliminar y aplicar junto con las dependecias también.
NOTAS:
- Seguramente nos pedirá desinstalar el paquete php5 de las dos formas, pero no pasa nada, después ya volveremos a instalar el interprete para este lenguaje.
- Si desinstalamos el paquete apache2 realmente no estaremos eliminando el servidor porque se trata de un meta-paquete que puede ser eliminado sin ninguna repercusión para los paquetes asociados.
Instalar el servidor Lighttpd
Para instalar el servidor yo recomiendo usar la linea de comandos (si se deseara utilizar Synaptic se tendrían que instalar los mismos paquetes que vamos a instalar a través del terminal pero buscándolos uno a uno).
Los paquetes que vamos a instalar son lighttpd, php5-cgi y lighttpd-doc (siempre que queramos la documentación de soporte para el servidor, mi recomendación es instalarla, nunca está de más…); lighttpd y lighttpd-doc son paquetes del servidor web mientras que php5-cgi será el paquete para interpretar las páginas dinámicas en PHP. Veamos el comando para instalar estos paquetes a la vez:
sudo apt-get install lighttpd lighttpd-doc php5-cgiNOTAS:
- Después de este paso aún no podremos ejecutar páginas PHP, nos faltan unos pequeños pasos que veremos a continuación.
- Si nuestra aplicación en PHP requiere acceso a base de datos tendremos que instalar los paquetes correspondientes (php5-mysql, php5-odbc…), en el caso de que necessitáramos manipular imágenes, instalaremos otros paquetes como por ejemplo php5-gd. En resumen, php5-cgi sólo nos proporciona un interprete básico de archivos PHP, para extenderlo existen muchos paquetes pero no los vamos a tratar en este post.
- Si intentamos visualizar una página PHP al final de este paso es posible que el servidor nos devuelva un error 403 FORBIDDEN. Para solucionarlo sólo tienes que seguir leyendo…
Activar PHP en Lighttpd
PHP debe ser activado en el archivo principal de configuración del servidor Lighttpd. Este archivo se llama lighttpd.conf y se encuentra en /etc/lighttpd/ para editarlo con Gedit por ejemplo tenemos que ejecutar el siguiente comando en el terminal:
sudo gedit /etc/lighttpd/lighttpd.conf* si estamos sin un entorno gráfico podemos editarlo con vim, pico o nano.
En el archivo de configuración vamos a tener que añadir el módulo fast-cgi (mod_fastcgi) nos va a tener que quedar una sección parecida a esta:
server.modules = (i tenemos que añadir nosotros una nueva sección como la siguiente (la podemos introducir justo después del paréntesis para cerrar la sección anterior):
"mod_access",
"mod_alias",
"mod_accesslog",
"mod_compress",
"mod_rewrite",
"mod_redirect",
"mod_evhost",
"mod_fastcgi",
# "mod_usertrack",
# "mod_rrdtool",
# "mod_webdav",
# "mod_expire",
# "mod_flv_streaming",
# "mod_evasive"
)
fastcgi.server = ( ".php" => ((NOTAS:
"bin-path" => "/usr/bin/php-cgi",
"socket" => "/tmp/php.socket"
)))
- Si necessitamos reescribir las URLs de las peticiones al servidor nos tenemos que asegurar que no estén comentadas (sin el ‘#’ delante) las lineas “mod_rewrite” y “mod_redirect”.
- El path “/usr/bin/php-cgi” puede depender de la instalación de los paquetes de PHP. Para asegurarnos podemos ejecutar el comando ‘whereis php-cgi’ y comprovar que nos arroja la misma ruta que hemos escrito en el archivo de configuración.
- Se pueden encontrar más opciones de configuración del modulo de PHP en la página oficial del servidor web aquí.
Setear un servidor virtual en Lighttpd
Se pueden setear servidores virtuales en Lighttpd de forma muy simple modificando el mismo archivo de configuración que en el apartado anterior (/etc/lighttpd/lighttpd.conf). Para setear un servidor virtual con la dirección “direccionaleatoria.com” y directorio base “/home/user/proyecto” tendremos que añadir una sección al final del archivo de configuración como la siguiente:
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
}
- Igual que con el módulo PHP, se pueden encontrar más opciones de configuración avanzada de servidores virtuales en la página oficial del proyecto Lighttpd aquí.
Definir reglas de reescritura de URLs para el Zend Framework
Lighttpd puede ejecutar de forma eficiente proyectos realizados bajo el framework PHP de Zend siempre que se definan correctamente las reglas de reescritura de las URLs. Para conseguir esto debemos añadir las siguientes lineas al archivo de configuración:
url.rewrite-once = (Podemos conseguir que esta reescritura sólo afecte a un servidor virtual si añadimos estas lineas dentro del apartado correspondiente. Si queremos que la reescritura sólo afecte al servidor virtual que hemos seteado en el paso anterior la sección del servidor virtual debería ser la siguiente:
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
$HTTP["host"] == "direccionaleatoria.com" {NOTAS:
server.document-root = "/home/user/proyecto/"
url.rewrite-once = (
".*\?(.*)$" => "/index.php?$1",
".*\.(js|ico|gif|jpg|png|css)$" => "$0",
"" => "/index.php"
)
}
- Estas normas de reescritura se pueden encontrar en los foros oficiales del Zend Framework aquí.
Y con estos breves pasos… muy breves!!! Ya tenemos una aplicación web PHP (con Zend Framework o no) corriendo bajo Lighttpd, provadlo y me contais si corre más que en Apache.
Comentarios recientes