Ubuntu 14.04 LTS – Nginx SPDY y Amazon ELB, mejora impresionante.

Hace unos días actualicé nuestros balanceadores para que soportaran SPDY 3.1. El servidor que negocia la conexión es Nginx. La mejora en cuanto a número de request/hits es muy grande.

De https a spdy
De https a spdy
De https a spdy
De https a spdy

La cantidad de conexiones baja mucho, mucho! Bastante más de lo que yo esperaba. A los pocos minutos de aplicar SPDY pensé que algo estaba mal, no podían ser tan pocos request, después de analizar todo a fondo quedo claro que no había nada mal, simplemente hay menos conexiones porque se hacen varias request en una sola gracias spdy.

Esto también ha reducido el consumo de CPU, y también el número de sockets abiertos, bajan tanto como los request claro.

La cantidad de páginas vistas en Google Analytics se mantiene, no hay perdida de tráfico y los servidores trabajan bastante menos. En los 4 días que lleva en marcha, parece que tener una web con https+spdy consume menos que una web solo con http.

Para que funcione SPDY en un balanceador de Amazon (ELB) se debe escuchar el puerto 443 por TCP (no https, ni tcp secure), y para saber que IP tiene el usuario final hay que activar el modo proxy en ELB y en NGINX.

En nginx, se debe añadir proxy_protocol en el “primer server” de la configuración. Si se hace en el segundo o en el tercero, no funcionará (más info). Es conveniente preparar la configuración y dejarlo todo listo solo para hacer “service nginx reload” y empezar con el nuevo protocolo.

server {
listen 443 default_server proxy_protocol ssl spdy;
server_name localhost;

# ....
}

Para activar el proxy protocol en ELB, vamos a suponer que nuestro balanceador se llama “mybalancer1″:

Esto crea la política de Proxy Protocol:

aws elb create-load-balancer-policy --load-balancer-name mybalancer1 --policy-name EnableProxyProtocol --policy-type-name ProxyProtocolPolicyType --policy-attributes AttributeName=ProxyProtocol,AttributeValue=True

Esto aplica esa política en nuestro balanceador:

aws elb set-load-balancer-policies-for-backend-server --load-balancer-name mybalancer1 --instance-port 443 --policy-names EnableProxyProtocol

En cuanto ejecutamos está última linea, empezará a funcionar Proxy Protocol, por lo que debemos reiniciar nginx inmediatamente. En sitios de alto tráfico hay que intentar ejecutar estos comando al mismo tiempo.

Para los que utilicen ubuntu LTS (14.04 ahora mismo), que sepan que nginx spdy 3.1 está desde la versión 1.5 si no voy mal, y la versión de ubuntu LTS es nginx 1.4, por lo que tiene spdy pero es spdy 2, que a mi no me funcionó bien. Recomiendo utilizar la versión 1.8 o superior. http://opensourceeducation.net/updating-nginx-1-4-6-to-1-8-x-on-ubuntu-14-04-and-fixing-limit_zone-errors/

BETA pública de wpand.me

Ya estamos listos para la BETA publica del nuevo proyecto http://beta.wpand.me (de momento se llama así, pero igual cambiamos el nombre que no nos convence del todo…).

¿De que va el proyecto? Es una web para crear páginas web en “un click”. Eliges el diseño que te gusta, lo “compras” y listo, ya tienes una web! luego solo debes cambiar el contenido por el tuyo. También cuenta con herramientas como backup, staging (copias vivas!), etc..

¿Es un 1-click to install? NO! instala todo en un click si, pero los 1-click to install hacen eso, instalan WordPress u otro CMS pero nada más. Aquí el sitio es completo, se pueden crear tiendas, página de restaurantes, etc… con sus plugins y configuraciones. Cuando el cliente las compra tiene todo junto y ya configurado, listo para utilizar.

Pero más que palabras, lo mejor es probarlo!

Así es el panel donde están todos los sitios que has comprado:

wpandme-screen1

 

Y así es la pantalla para controlar tu sitio:

wpandme-screen2

Se puede restaurar un backup, crear una copia del sitio para probar, reemplazar el sitio real con la copia, hacer 4 copias, backup de cada copia, es decir, hacer lo que quieras :)

Si eres dearrollador de páginas web, podemos incluir tu theme en nuestro sitio y cualquier persona lo podrá comprar. Imagina que haces un sitio, y lo vendes varias veces! a cualquiera en cualquier parte del mundo, sin preocuparte por el hosting, la instalación, el dominio, cambios de dominios, nada… Simplemente un click, y listo! ya lo tienen. Más fácil que nunca he?  Contacta con nosotros a info@wpand.me

Se agradece cualquier idea, sugerencia o fallo que hayan encontrado en la aplicación!

Error al actualizar WordPress 4.2 (4.2.2): Parche para el core

El problema apareció al intentar actualizar una instalación con una base de datos un poco grande, concretamente la tabla de options (wp_options). Al intentar actualizar el wordpress aparecía la típica pantalla de “Database update required”:

database-update-wordpress

 

Y aunque le dabas al botón de actualizar la base de datos volvía a aparecer la misma pantalla, un loop infinito.

Al analizar que pasaba exactamente vi que la base de datos trabajaba mucho cada vez que le daba al botón, por lo que quedó claro que no era capas de hacer dicha actualización. Buscando más a fondo encontré una consulta que tardaba mucho en ser completada.

"ALTER TABLE wp_options CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci"

WordPress lanzaba la actualización de la base de datos, pero esta consulta requería tanto tiempo que daba un timeout a nivel de php, aunque la orden de SQL se ejecutaba con éxito. Pero WordPress no se enteraba de que finalizó correctamente, por lo que no quedaba registrada la actualización, volvía al mismo punto y volvía a ejecutar la misma query. Y nunca salía desde loop.

Hice una pequeña modificación en el core, para verificar si la tabla ya tenía el nuevo collation o no, en caso afirmativo continuar porque ya estaba hecho. Abrí un ticket y envíe el parche.

Es mi primera contribución al core de WordPress, aunque es una chorrada pero bueno, es la primera.

Lo que me llamó la atención fue lo rápido con lo que trataron el parche. En menos de 45 minutos ya había confirmado el fallo, aplicado el parche, mejoraron el parche, lo aplicaron para la siguiente versión 4.2.3 y cerraron el ticket!

Era un problema grave, porque cualquier instalación con una tabla grande podría quedarse a mitad de la actualización y quedar bloqueada. Pero han actuado muy rápido. Eso si, aún no se ha publicado la versión 4.2.3 por lo que habrá instalaciones con este problema, y tendrá que actualizar a mano a 4.2.3 o bien ejecutar la instalación por consola y así evitar el timeout.

También puedes descargar este fichero https://core.svn.wordpress.org/branches/4.2/wp-admin/includes/upgrade.php y que es la versión que contiene el nuevo código. Lo subes por ftp y ya funcionará el dichoso botón.

Apache 2.4 con MPM Event, conexiones rechazadas

Hace pocos días que empecé a probar en un entorno real el MPM Event de Apache 2.4 con PHP-FPM.

La configuración por defecto de Apache nunca está pensada para entornos de producción, siempre hay que hacer ajustes. Apache está pensado para “auto-limitarse”, tanto en el número de conexiones, como la ram, etc.. de modo que “nunca” colapsará el servidor. La idea e responder tantas peticiones como sea posible sin utilizar absolutamente todos los recursos del servidor. Así puede convivir con otros sistemas como mysql, php-fpm,…

La idea está bien pero eso requiere de ajustes en cada servidor para que apache utilice todos los recursos que sean posibles, a fin de responder todas las peticiones posibles.

Tras dos días de pruebas, no funciona del todo bien. El problema es que rechaza algunas conexiones.  Aparte de esto, todo funciona bien.

En este servidor tengo unos 350.000 hits por hora. Y rechaza unas 130 conexiones cada hora (de media, aveces más a veces menos, pero nunca 0).

Las conexiones rechazadas fueron aleatorias, nunca es sobre la misma dirección o el mismo tipo de fichero, ya puede ser peticiones a php, jpg, html… es indiferente.

Realicé múltiples ajustes en la configuración de MPM Event, por ejemplo:

<IfModule mpm_worker_module>
# event MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves

ServerLimit 1024
StartServers 8
MinSpareThreads 75
MaxSpareThreads 250
ThreadsPerChild 25
MaxClients 1025
MaxRequestsPerChild 0
</IfModule>

Hice de todo, subir todos los valores a “lo loco”, ajustándolo según la documentación, etc.. el resultado siempre fue el mismo. No puedo ni decir en que punto mejoró o empeoró. Después de cada cambio le daba unos 30 minutos de control para ver que pasaba, y hacía siempre lo mismo.

En el caso de MPM Prefork tengo la siguiente configuración, que funciona perfectamente:

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 250
MaxRequestsPerChild 0
</IfModule>

Se supone que MPM Event ya no es experimental, que es estable desde la versión 2.4 de Apache. Pero algo no va bien o falta documentación.

Un gráfico sobre los errores 503 detectados:

mpm-event-mpm-prefork

Seguiré investigando a ver si puedo publicar la solución.

Probé varias configuraciones en un entorno de pruebas. Pero la realidad siempre es diferente. Simular el tráfico real es muy difícil. Y desde luego el servidor no se comportó igual con todas las IP, url, y user-agents… fluctuante que se tiene en un entorno real.

Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.

Mark Zuckerberg

Cambios en rewrites en WordPress 4.0 para post_type (cpt)

En la versión 4.0 se hicieron varios cambios en relación a los rewrites, ahora es un poco más fácil de gestionar. Pero para las instalaciones antiguas hace falta un cambio cuando se utiliza post_type.

En la URL:

http://www.example.com/carreras/modalidad/tipo1/subtipo1/mi-carrera

Donde “mi-carrera” es el nombre del post_type que queremos mostrar.

En WordPress 3.9, el rewrite para manejar este post_type sería:

$custom = array(
    'carreras/modalidad/([^\/]+)/([^\/]+)/([^\/]+)/?$' => 'index.php?post_type=carrera&carrera=$matches[3]',
);

En el caso de WordPress 4.0:

$custom = array(
    'carreras/modalidad/([^/]+)/([^/]+)/([^/]+)/?$' => 'index.php?post_type=carrera&name=$matches[3]'
);

Lo que cambia principalmente es el parámetro “name”, antes se buscaba el contenido con el mismo nombre del post_type. Ahora indica el post_type y el contenido como “name”.

Ahora es más claro, el método anterior podía resultar algo confuso.

Con smartphones y tabletas se cambio de POP3 a IMAP

Hace muchos años que gestiono servidores de correo para empresas. Y siempre pasaba lo mismo, se configuraba el IMAP y el SSL pero casi no lo se utilizaba, menos de un 10% de los usuarios. Casi siempre utilizaban outlook o similar con POP3 sin ningún tipo de cifrado. Explique muchas veces las ventajas de IMAP y del SSL pero nunca los utilizaban.

Desde que empezaron a utilizar smartphones y tabletas en las empresas esto cambio radicalmente. Primero empezó a utilizarse el SSL en casi todas las conexiones y en los últimos meses, por primera vez, el uso de IMAP es mayor al uso de POP3.

Uso de POP3 vs IMAP 2013-2014

En este gráfico lo verde es IMAP y lo rojo es POP. Lo que es escuro, en los dos colores es el SSL. Se ve como al pasar los meses, lo verde va avanzando hasta ser la mayoría. Aún muchos usuarios utilizan POP3 pero ya son menos del 50%.

Esto es bueno para los usuarios, la seguridad y privacidad, movilidad, etc.. Pero no tan “bueno” para los servidores ahora se necesitan mucho más recursos que antes para atender a las mismas cuentas. El consumo de recursos con POP3 es muy bajo, especialmente si no se utiliza SSL. Pero con IMAP las conexiones se mantienen, lo que incrementa el consumo de ancho de banda, CPU y RAM para menter las conexiones con los túneles de SSL en cada una de ellas.

También aumenta el consumo de espacio en el disco duro. Con POP3 el usuario descargaba los correos a su ordenador cada 10 minutos y el servidor no guardaba nada. Ahora con IMAP el servidor almacena todo, y cada cuenta ahora ocupa barios cientos de MB, y no son pocos los que consumen varios GB.

Todo sea por el progreso!

Bloquear actualizaciones en WordPress y sin penalizar el rendimiento

En cada actualización de WordPress puede surgir alguna incompatibilidad. Por este motivo se suele bloquear las actualizaciones para evitar una actualización accidental, o hecha por un usuario que no conoce los detalles de la instalación (osea, el cliente :P)

Existe un código que está muy propagado por internet:

//Disable Theme Updates # 3.0+
remove_action( 'load-update-core.php', 'wp_update_themes' );
add_filter( 'pre_site_transient_update_themes', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_update_themes' );

//Disable Plugin Updates #3.0+
remove_action( 'load-update-core.php', 'wp_update_plugins' );
add_filter( 'pre_site_transient_update_plugins', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_update_plugins' );

//Diasable Core Updates # 3.0+
add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_version_check' );

Este código funciona pero hay un problema, que empeora el rendimiento de wordpress. Casi multiplica por 4 los tiempos de respuesta.

Sucede porque la función que se crea para engañar al sistema devuelve un valor “null”, así WordPress cree que no hay ninguna actualización. Pero como no sabe cuando se hizo la comprobación ni cual fué la última versión ni nada (porque es un null), vuelve a conectar a wordpress.org para comprobar datos. Es decir, que cada click que se hace en el sitio hace que nuestro WordPress vuelva a consultar a wordpress.org. Una perdida de tiempo.

Un forma más adecuada de hacer este “hack” o bloqueo es la siguiente:

function custom_fake_check_version($a) {
    global $wp_version;
    return (object) array(
        'last_checked' => time(),
        'version_checked' => $wp_version,
    );
}
add_filter('pre_site_transient_update_core',    'custom_fake_check_version');
add_filter('pre_site_transient_update_plugins', 'custom_fake_check_version');
add_filter('pre_site_transient_update_themes',  'custom_fake_check_version');

Es lo mismo que lo anterior, salvo que en lugar de devolver un “null” le estamos diciendo al sistema que la última vez que se comprobó la versión fue “ahora mismo” y que la versión es “la versión actual”. Por lo tanto, WordPress no volverá a consultar ese dato en los servidores de wordpress.org hasta que se eliminen estos filtros.

Scripts para probar la autenticación en IMAP, POP3 y SMTP

Hace casi un año escribí estos scripts para probar los métodos de autenticación en el servidor de correo que estaba instalando en ese momento. La idea es crear un fichero de configuración con los datos de usuario y los métodos que se desean probar. Así, de forma fácil y rápida se puede verificar si la autenticación mediante “PLAIN”, “LOGIN”, “CRAM-MD5″, etc…

He publicado el código en git en la siguiente dirección: https://github.com/gabrielperezs/Authentications-tools-for-mail-servers

Funciona de la siguiente forma, es muy simple:

Se crea un fichero con la configuración, como este, lo llamamos example.conf:

# Account to test
username=test@mydomain.com
password=the_account_password
server=mail.example.org
#auth=auto
auth=manual
authtype=PLAIN LOGIN CRAM-MD5 DIGEST-MD5

Se puede indicar el parámetro “auth” como “auto” para que el script detecte automáticamente los métodos de autenticación disponibles. Si se indica como “manual” (tal como el ejemplo) permite indicar los métodos de autenticación que se quiera o los scripts de perl soporten. Depende de los módulos de perl que estén instalados en el sistema.

Cuando se ejecuta se verá algo así:

$ perl imap-test.pl ~/example.conf
PLAIN -&gt; mail.example.org (test@mydomain.com): OK - SSL OK
LOGIN -&gt; mail.example.org (test@mydomain.com): OK - SSL OK
CRAM-MD5 -&gt; mail.example.org (test@mydomain.com): ERROR - SSL ERROR
DIGEST-MD5 -&gt; mail.example.org (test@mydomain.com): ERROR - SSL ERROR

Esto indica que los métodos de autenticación PLAIN, y LOGIN funcionan correctamente. Tanto con como sin SSL. Y los métodos CRAM-MD5 y DIGEST-MD5 no funcionan.

Los otros dos scripts (smtp-test.pl, pop3-test.pl) funcionan exactamente igual.

La insensibilidad en el día mundial de la alimentación

Un vecino de Palma de Mallorca ha tenido la “gran idea” de colocar este cartel en un contenedor. Dudo que un insensible de este nivel sepa que hoy es el día mundial de la alimentación.

IMG_20131016_114041

Es increíble que alguien se tome el trabajo de escribir y pegar esto en un contenedor para llamar CERDO a una o varias personas  que buscan en la basura para poder alimentarse. Para este vecino el problema no está en que la gente tenga que buscar en la basura para comer, no, el problema está en que no limpian después de “comer”.