Instalar WordPress 3.5 en Internet Information Services (IIS) sobre SQL Server 2008

Desde hace algún tiempo llevaba con la idea de intentar montar WordPress en IIS sobre SQL Server, aprovechando las mejoras que están haciendo los chicos de Microsoft para ejecutar PHP en su servidor web ( [1], [2] y [3]). Hoy lo he conseguido así que os cuento cómo hacerlo vosotros (mis pruebas fueron sobre un windows7 con IIS 7, SQL server 2008 y PHP 5.4.12RC1-Win32-VC9-x86).

Dando por sentado que tenemos instalado PHP en nuestro IIS, hay que instalar las extensiones de PHP para SQL Server. Tras descargar el fichero, descomprimirlo, llevar las librerías adecuadas a la carpeta ‘ext’ de nuestra instalación de PHP ya podemos conectarnos a SQL Server con PHP. ¿Que qué librerías son las adecuadas? Al descomprimir el fichero con los drivers encontraremos que los tenemos para php 5.3 y 5.4.Además, en cada una de ellas, los tenemos en su version “thread safe” ( busca “_ts” en nombre del archivo) y “non thread safe” ( busca “_nts” en nombre del archivo). En mi caso, como estoy trabajando con php 5.4.12 en Windows 7 utizaré “php_pdo_sqlsrv_54_ts.dll” y “php_sqlsrv_54_ts.dll“.

¿Cómo compruebo que los drivers están correctamente instalados?

Desde una consola de ms-dos ejecuta:

php.exe -m

que debe generate una lista con los módulos disponibles, en donde deben aparecen los que acabamos de instalar.

Lo siguiente es descargamos la última versión de WP desde la página oficial ( http://wordpress.org/ ), o su versión en español ( http://es.wordpress.org/ ), que hoy es la 3.5.1. Para poder conectarlo con SQL server, en lugar de mySQL, hacemos uso de WordPress Database Abstraction, a día de hoy en su versión 1.1.4.

Lo descargamos, descrompimimos y seguimos las instrucciones que nos proporciona el documento README.txt, que viene dentro del plugin:

1. Upload wp-db-abstraction.php and the wp-db-abstraction directory to wp-content/mu-plugins. 
This should be parallel to your regular plugins directory.  If the mu-plugins directory does not exist, you must create it.
2. Put the db.php file from inside the wp-db-abstraction.php directory to wp-content/db.php
3. Visit $your_wordpress_url/wp-content/mu-plugins/wp-db-abstraction/setup-config.php to generate your wp-config.php file
4. Install WordPress normally
5. Visit $your_wordpress_url/wp-content/mu-plugins/wp-db-abstraction/setup-config.php to generate your wp-config.php file

Lo importante es que, para ejecutar el instalador, en lugar de ir a

http://instalacion.de.wordpress/wp-admin/setup-config.php

vayamos a:

http://instalacion.de.wordpress/wp-content/mu-plugins/wp-db-abstraction/setup-config.php

ya que la primera dirección corresponde con el asistente para instalar sobre mySQL y el segundo es para hacerlo sobre SQLServer (lo que nosotros queremos). Ahora sólo nos queda seguir el asistente e instalar nuestro WP, a lo que debo añadir que, a la hora de seleccionar el tipo de base de datos, tuve que elegir “PDO_sqlsrv” porque con la otra opción, “SQL Server using MS PHP driver”, no instalaba correctamente (probadlo y me decís).

Escogiendo tipo de base de datos en la instalación de wordpress

si habéis seguido los pasos correctamente debiérais tener vustra instalación de WordPress corriendo en IIS  sobre SQL Server. Como nota final, y que me tuvo un rato largo resolverlo (por no buscar en Internet, orgulloso que es uno), si al acceder al blog no véis ningún post o si añadís alguno y tampoco salen daros una vuelta por este hilo del foro de WordPress Database Abstraction: Not showing posts.

Referencias.

Sirviendo páginas web con https

Hablando con un compañero, sobre servir una web institucional mediante HTTP o HTTPS, hemos tenido un interesante intercambio de opiniones (vale, sólo han sido tres correos). Mi idea es que si no hay información sensible de ser robada mejor no usar HTTPS por:

  • que ciertos proxies y sistemas de cacheado de datos no trabajaban bien con TLS/SSL
  • se incrementa el esfuerzo del servidor para cifrar las peticiones a todos los recursos que se sirven con una página web (imágenes, hojas de estilo, ficheros javascript, documentos html, etc)

Como notáis por mis argumentos no soy un experto en TLS/SSL pero, como hablar es gratis, sigamos 🙂 Con esto en mente hubiera desplegado la web con HTTP pero mi compañero no, el opta por HTTPS. Para apoyar su idea me manda un interesante enlace “Should All Web Traffic Be Encrypted?” [1], en Codinghorror, donde se plantea este mismo tema. Con la ayuda de algunas de las referencias que en él se indican mis dos argumetos pierden fuerza.

En los comentarios de “Chrome’s 10 Caches” [2] indican dos referencias “HTTPS Caching and Internet Explorer” [3] y “Should cache SSL content to disk even without Cache-Control: public” [4] donde hablan sobre el compartamiento de los naveadores ante el cacheado de elementos cifrados.

En Internet Explorer [3]:

WinINET will not reuse a previously-cached resource delivered over HTTPS until at least one secure connection to the target host has been established by the current process Es decir: la primera vez que solicitemos el recurso no se cachea pero las siguientes sí, mientras no cerremos el navegador (o eso he entendido).

En Firefox [4]:

Currently, Firefox only caches SSL content to disk if it was sent with Cache-Control: public. On the other hand, IE and Chrome cache SSL content even without that header. And this header was not designed to affect client caches (only proxies).
The reason why I implemented it this way was to avoid caching secure content to disk without an explicit hint that this is OK to do so, but considering that especially IE doesn’t require this header, it seems OK to remove this requirement.

De lo que entiendo que Firefox cachea todos los recursos HTTPS a menos que se añada la cabecera “cache-control: no-store”.

En Chrome [2]:

Caches SSL sessions to disk. This saves several round trips of negotiation when connecting to HTTPS pages by allowing the connection to skip directly to the encrypted stream

Con esto se viene abajo mi idea del no cacheado de los recursos cifrados 🙁 aunque habría que ver cómo se comportan los sistemas de cacheado como Varnish ante el tráfico cifrado [7] En el tema del incremento de trabajo en los procesadores del servidor leo en “SSL FalseStart Performance Results” [5] que, ya desde 2011 (por Dios qué atrasado estoy en el tema!!), hay un método para reducir el tiempo de intercambio de claves durante el proceso de cifrado de las comunicaciones llamado “Transport Layer Security (TLS) False Start” [6].

Con todo lo leido y aprendido sigo pensando lo mismo: a pesar de las mejoras en los navegadores, con el cacheado de los recursos, y en el propio mecanismo de cifrado estoy de acuerdo con el comentario final del artículo con el que comenzamos [1]:

Maybe not tomorrow, maybe not next year, but over the medium to long term, adopting encrypted web connections as a standard for logged-in users is the healthiest direction for the future of the web. We need to work toward making HTTPS easier, faster, and most of all, the default for logged in users.

O en castellano: para sitios web donde los usuarios tengan que logearse el tráfico HTTPS debiera ser obligatorio. A lo que añado: para aquellos que no haya identificación de usuarios es mejor usar HTTP.

[1] Should All Web Traffic Be Encrypted?: http://www.codinghorror.com/blog/2012/02/should-all-web-traffic-be-encrypted.html
[2] Chrome’s 10 Caches: http://gent.ilcore.com/2011/02/chromes-10-caches.html?showComment=1297102528799#c5411401837359385517
[3] HTTPS Caching and Internet Explorer: http://blogs.msdn.com/b/ieinternals/archive/2010/04/21/internet-explorer-may-bypass-cache-for-cross-domain-https-content.aspx
[4] Should cache SSL content to disk even without Cache-Control: public: https://bugzilla.mozilla.org/show_bug.cgi?id=531801#c19
[5] SSL FalseStart Performance Results: http://blog.chromium.org/2011/05/ssl-falsestart-performance-results.html
[6] Transport Layer Security (TLS) False Start: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
[7] Varnish no soporta SSL: https://www.varnish-cache.org/docs/trunk/phk/ssl.html