Asier Marqués

Claves foráneas vs UNIQUE en MySQL.

firesymfony :: Firefox Add-ons

20 Excellent AJAX Effects You Should Know

Seek Attention - jQuery plugin - by James Padolsey

Can You Secure A Shared Server With PHP + FastCGI?

Using the Application Request Routing Module (IIS7)

Windows® Internals: Including Windows Server 2008 and Windows Vista

Scaling Day-By-Day

memcached for Win32

Amazon Web Services Security White Paper

How to Watch Videos on Hulu from Anywhere

En entornos Microsoft, para disponer de URL Rewrite como en Apache con Mod Rewrite, debíamos instalar un componente isapi en el servidor. La opción más conocida es Isapi Rewrite de Helicon.

En IIS7 disponemos de un módulo oficial creado por el equipo de IIS7, que ha sido publicado hace unos días en su versión Go Live Release, apta para entornos de producción.

Podemos crear reglas desde el administrador de IIS7, a mano o mediante una interfaz “para torpes”, o desde el archivo webconfig.xml de cada sitio web.

Entre las funcionalidades más interesantes que puede ofrecernos este módulo se encuentran la posibilidad de cachear las reglas por el servidor web, disponer de una herramienta gráfica para importar reglas de mod_rewrite de apache y la  integración con las trazas de iis para detectar errores en las reglasque creemos.

La gestión de las reglas en el webconfig es tremendamente sencilla:

<rewrite>
  <rules>
    <rule name="Fail bad requests">
      <match url=".*"/>
      <conditions>
        <add input="{HTTP_HOST}" pattern="localhost" negate="true" />
      </conditions>
      <action type="AbortRequest" />
    </rule>
    <rule name="Rewrite to article.aspx">
      <match url="^blog/([0-9]+)/([_0-9a-z-]+)" />
      <action type="Rewrite" url="article.aspx?id={R:1}&title={R:2}" />
    </rule>
  </rules>
</rewrite>

Battle Stations es un juego para facebook tipo MMORTS (juego de estrategia online multijugador masivo en tiempo real), que recibe una media de 13000 jugadores diarios y que ha dado la fama gracias a su éxito a Tyler Projects.

El responsable de Tyler Projects, Tian Yang, tenía curiosidad por saber si una solución basada en Windows 2008 Server podría mejorar su infraestructura basada en CentOS5 y Fedora9.

Montar la aplicación en 2008 Server les llevó 30 minutos y los resultados obtenidos (versión Excel 2003) en cuanto a rendimiento son sorprendentes.

Hicieron dos tipos de pruebas:

- En la primera prueba los tres sistemas operativos (WS2008, Centos5, Fedora9) se probaron “out of the box” es decir, sin ningún tipo de modificación
- En la segunda Windows 2008 se mantuvo con la configuración por defecto, y en Centos5 and Fedora9 fueron optimizados por Tian Yang.

Vemos como Windows 2008 Server consigue casi el doble de rendimiento que CentOS y Fedora.

Esta claro que las mejoras efectuadas en la pila TCP/IP, la nueva arquitectura de IIS7, el componente FastCGI oficial para php de Microsoft y la opción Server Core, hacen posible ver a Windows 2008 Server como una plataforma más que considerable para servir aplicaciones web para internet.

Más información, en el blog de Dennis Chung.

Desde hace algún tiempo he estado leyendo sobre varios frameworks de desarrollo con php, que me permitiesen de una forma fiable automatizar trabajo que, a pesar de no tener una dificultad notable para alguien que sepa programar, te hace perder un montón de tiempo si quieres hacer las cosas bien.

La opción que más me ha gustado para php es sin duda Symfony y puesto que desarrollo tanto para plataformas UNIX/Linux como para sistemas Microsoft, me interesé por hacerlo funcionar e incluso utilizarla en proyectos que actualmente me encuentro desarrollando bajo sistemas Microsoft.

Voy a detallar como es una instalación de Symfony en IIS. Yo lo tengo funcionando sobre 2003 Server SP2 con IIS6

1 - Se descarga el código fuente de Symfony y se descomprime en un directorio en una de las unidades de disco duro del servidor. (Supongamos D:\symfony)

2 - Se crea un directorio cuyo contenido será el que usemos como sitio web. (Supongamos D:\dir_proyecto)

3 - Abrimos un terminal, nos situamos en “dir_proyecto” y ejecutamos lo siguiente para crear un proyecto:

D:\symfony\data\bin\symfony.bat init-project nuevo_proyecto

Ahora creamos una primera aplicación para ese proyecto:

D:\symfony\data\bin\symfony.bat init-app nueva_aplicacion

4 - Creamos un sitio web nuevo que apunte al directorio “D:\dir_proyecto\web”.

5 - Dentro del ese nuevo sitio web, creamos un directorio virtual que apunte a “D:\symfony\data\web\sf”

6 -  Si usamos isapi rewrite necesitamos ahora aplicar las reglas de redirecciones para nuestro sitio web. En la documentación oficial nos comentan una serie de reglas específicas para entornos de IIS. Esas reglas pueden darnos problemas a la hora de acceder a los archivos del directorio “D:\symfony\data\web\sf”.

Para evitar estos problemas, debemos ser fieles a las reglas definidas en el .htaccess que se ha creado en el directorio “D:\dir_proyecto\web” y añadir las reglas de seguridad relativas a entornos Microsoft.

Las reglas de redireccionamiento quedarían de la siguiente forma:
RewriteRule .*(?:global.asa|default\.ida|root\.exe|\.\.).* . [F,I,O]

RewriteRule ^$ index.html [QSA]
RewriteRule ^([^.]+)$ $1.html [QSA]
RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule (.*) /index.php [L]

Con esto ya deberíamos comprobar que todo funciona correctamente.

Muchos os habréis fijado en servicios web que usan subdominios dinámicos (wildcard) para las cuentas de sus usuarios, como por ejemplo jaiku.

Sin embargo, una vez configurados los subdominios dinámicos, tenemos un serio problema y es que, las variables de sesión por defecto se pierden cada vez que ejecutamos la aplicación web desde un subdominio distinto al que hemos utilizado para crear dicha variable de sesión.

Podemos comprobar esto en algunos sitios web que no usan subdominios dinámicos pero, si hacemos login en su www.dirección.com, si después vamos a su dirección.com sin las ‘www’ nos encontramos con que no hemos iniciado sesión. El problema es similar y tiene la misma solución que en el caso de los wildcard domains.

Voy a explicar cómo solucionar este problema y como hacer funcionar subdominios dinámicos.

Los pasos:

1 - Configurar el dns

2 - Configurar el servidor web

3 - Configurar bien el ámbito de las variables $_SESSION en la aplicación php para que se compartan las variables de sesión entre los subdominios.

Configurar el dns.

Basta con crear una entrada tipo host es decir, “A” apuntando a *.tudominio.com . También vale con crear un CNAME * apuntando al registro A del dominio principal (”tudominio.com”).

Si hacemos un ping a “loquesea.tudomino.com” debería ya resolver (a menos que tengas capado el tráfico ICMP claro)

Configurar el servidor web.

En Apache httpd, debemos configurar en el vhost de nuestro dominio un ServerAlias que atienda a “*.midominio.com”

En Nginx, debemos configurar en la sección Server un valor server_name como “*.midominio.com”

En IIS, debemos dejar un sitio virtual sin headers y ese es el que atenderá las peticiones de vuestro wildcard dns, es la única forma.

Se ha discutido sobre este tema en el foro oficial de IIS y según los propios desarrolladores, aunque ha sido demandada durante años, no se piensa implementar dicha funcionalidad por ahora, ni siquiera en IIS7.

Nota: sólo podemos disponer de un sitio web sin headers por servidor web IIS.

Configurar nuestras variables de $_SESSION en php

El truco esta en configurar la directiva session.cookie_domain como “.midominio.com” (importante el . delante del dominio).

Podéis hacerlo en tiempo de ejecución, antes de llamar a session_start(); siempre que tengamos deshabilitado el autoarranque de sesiones en el php.ini (como es lógico y viene por defecto)

ini_set("session.cookie_domain",".midominio.com");
session_start();

Ahora ya podéis crear servicios web tan útiles como este.

Por defecto la pila TCP/IP en un servidor Microsoft Windows 2003 Server viene optimizada para dar servicio de intranet, no para dar servicio de internet.

Tener un servidor sin adaptar adecuadamente dando servicio para internet con iis6 por ejemplo, puede convertirlo en una fácil presa de ataques dDOS entre otros.

Hay que tener en cuenta de igual modo, que un servidor expuesto a internet, no va a tener que soportar ni de lejos la misma carga de tráfico que uno que opere en la intranet de una empresa, en la gran mayoría de los casos.

Para optimizar nuestro sistema debemos tocar las siguientes claves de registro que encontramos en HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Services

Nombre: SynAttackProtect

Clave: Tcpip\Parameters

Tipo: REG_DWORD

Valor:1

Este valor del Registro hace que TCP ajuste la retransmisión de SYN-ACKS. Cuando se configura este valor, las respuestas de conexión superan el tiempo de espera antes durante un ataque SYN (En w2k3 con service pack 1 viene a 1 por defecto)

Nombre: EnableDeadGWDetect

Clave: Tcpip\Parameters

Tipo: REG_DWORD

Valor: 0

Cuando esta activada, TCP puede utilizar una puerta de enlace que no se use en el caso de tener problemas con la que usa por defecto.
Si no se configura este valor como 0, se podría cambiar de puerta de enlace del servidor a otra que el atacante quiera.

Nombre: EnablePMTUDiscovery

Clave: Tcpip\Parameters

Tipo: REG_DWORD

Valor: 0

De no ser 0, un atacante podría forzar que el valor de la unidad de transmisión máxima (MTU) fuera muy pequeño y sobrecargar la pila TCP/Ip.

Nombre: KeepAliveTime

Clave: Tcpip\Parameters

Tipo: REG_DWORD-Tiempo en milisegundos

Default: 300000 (5 minutos)

Indica la frecuencia en la que se comprueban si las conexiones TCP inactivas siguen intactas y si el cliente está presente. Generalmente es recomendable cambiar el valor por defecto de 2 horas a 5 minutos, pero en cada caso concreto debemos estipular una configuración adecuada.

Nombre: NoNameReleaseOnDemand

Clave: Netbt\Parameters

Tipo: REG_DWORD

Valor: 1

Con este valor evitamos que el equipo libere su nombre NetBIOS en caso de que se le solicite.

En windows 2003 server no es suficiente con configurar una excepción al puerto TCP 21 en el Firewall para tener acceso a nuestro servidor ftp, ya que usa otros puertos para negociar las conexiónes pasivas.

El método más fiable y rápido para habilitar el acceso ftp en nuestro servidor, es ir a las opciones avanzadas del firewall, seleccionar la conexión local en la cual estamos sirviendo FTP, y seleccionar en su configuración el servicio FTP como se muestra en la captura siguiente.

Otro método consiste en agregar nuestro propio rango de puertos pasivos, a mano en el servidor FTP, y abrirlos después en el firewall.

Podemos hacerlo mediante un script batch como este.

Echo OFF
ECHO AÑADIENDO PUERTOS AL FTP
C:\Inetpub\AdminScripts\adsutil.vbs set /MSFTPSVC/PassivePortRange “5500-5550″

ECHO ABRIENDO PUERTOS EN EL FIREWALL
FOR /L %%I IN (5500,1,5550) DO NETSH FIREWALL ADD PORTOPENING TCP %%I FTPPort%%I
iisreset
ECHO TERMINADO
Pause

Oriol Jiménez, promotor del grupo php Barcelona, ha publicado en su blog phpBSD la presentación sobre rendimiento que llevó a la Barcelona PHP Conference (organizada por el mismo grupo).

Visión recomendada para aquellos arquitectos web que se preocupan por el rendimiento de sus aplicaciones php.

| View | Upload your own

Más presentaciones de la Barcelona PHP Conference aquí.

Aprovechando que tengo un servidor dedicado con Windows 2003 Server para desarrollo, contratado en Hostalia (por si a alguien le interesa), lo he configurado para que PHP corra en modo FastCGI sobre IIS.

Después de bajar la última versión Non-thread-safe de php y descomprimirla en un directorio, en este caso c:\php, procedemos a la instalación y configuración de FastCgi.

En IIS7 basta con agregar el módulo CGI para tener FastCGI pero en IIS6 debes bajarlo, actualmente en versión RTM, de éste enlace en iis.net.

Una vez instalado, podemos a agregar el módulo FastCgi en el servidor IIS. Para ello vamos a la pestaña Directorio particular, dentro de propiedades de un sitio virtual, y en configuración de la aplicación, añadimos la asignación de extensión para “.php” tal y cómo se ve en la captura.

Una vez hecho eso, debemos configurar el fcgiext.ini,localizado en WINDOWS\system32\inetsrv a mano o con un script llamado fcgiconfig.js ,incluido en ese directorio al instalar FastCGI.

Para hacer una configuración rápida lanzamos el siguiente comando en la ruta WINDOWS\system32\inetsrv

cscript fcgiconfig.js -add -section:"PHP" -extension:php -path:"C:\PHP\php-cgi.exe"

o bien si sólo queremos aplicarlo a un sitio web determinado, en este caso el sitio por defecto que tiene IIS

cscript fcgiconfig.js -add -section:"PHP" -extension:php -path:"C:\PHP\php-cgi.exe" –site:1

Si abrimos el fcgiext.ini veremos que se ha configurado fastcgi para funcionar con php y donde tiene que encontrar el ejecutable.

Si llamáis a un script con la función phpinfo(); , veréis que php se ejecuta perfectamente en modo FastCgi.

Si queréis ajustar más cosas para optimizar el rendimiento de fast cgi, os recomiendo que leáis ésta documentación de iis.net.

Arsys, empresa de hosting riojana, se adelanta a nivel internacional ofreciendo planes de servidores dedicados no administrados con Windows 2008 Server tanto en Web como en Standar Edition.

Windows 2008 Server incluye impresionantes mejoras tanto en seguridad como en su nuevo servidor web IIS7, que ha cambiado radicalmente su arquitectura.

La parte más importante y que más afecta al desarrollo web, especialmente al desarrollo con php, es la certificación de Zend Core con Windows Server 2008, lo cual garantiza la integridad de las aplicaciones php servidas en éste sistema operativo.

Otra parte importante es que php ahora se sirve en modo Fast CGI, por lo que su rendimiento es mucho más eficiente.

Los servidores Arsys son IBM @Server xSeries y estan disponibles en tres planes diferentes, con un plan básico de 99 euros al mes.

Las licencias de Windows 2008 Server se alquilan a un precio de 25 €/mes en su versión web y 50 €/mes en su versión Estándar. Podemos ver una comparación de características de las dos versiones aquí.

Gracias Michel por el aviso.