Configurar compresión gzip en nginx

nginx La compresión de lo que el servidor web envía al cliente es una de las técnicas más sencillas para mejorar la respuesta de nuestras webs. En nginx lo habilitamos facilmente a través de las directivas adecuadas del archivo nginx.conf en el directorio /etc/nginx. Por defecto suelen aparecer pero comentadas. Una configuración típica podría ser esta:

 ##
# Gzip Settings
##

gzip on;
gzip_disable "msie6";

gzip_vary on;
gzip_proxied any;
gzip_comp_level 6;
gzip_buffers 16 8k;
gzip_http_version 1.1;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon;

La información de que hace cada línea la tienes aquí. Y no olvides que una vez hechos los cambios debes reiniciar el servidor web para que tomen efecto.

Pasar de http a https en una web con nginx y wordpress

nginx “Papá” Google dejó claro hace unos meses que quería darle un empujoncito en sus rankings a quienes usaran https en lugar de http. Y allá vamos todos como tiernos corderitos a hacer la migración. ¡Faltaría más! Lo bueno (por verle algo) es que a los que esto no nos va ni nos viene nos sirve para motivarnos a remozar un poquillo el blog y hacer cosas nuevas. Y en eso estamos. Hasta hace bien poquito si queríamos usar https en una web y no queríamos gastarnos dinero en certificados teníamos las opciones que nos ofrecían StartSSL o CaCert. Pero desde finales del año pasado contamos con Let’s Encrypt: un proyecto patrocinado, entre otros, por la EFF y Mozilla del que todo el mundo habla maravillas. Había que probarlo, estaba claro.

Con Lets Encrypt no hacemos la instalación de un certificado a la antigua usanza, sino que instalamos en nuestro servidor un programa que se encarga de realizar la instalación y posterior renovación periódica de forma automática. Además, si usamos Apache se encarga de realizar la configuración necesaria en nuestro servidor de forma automática. Está previsto que en el futuro también existirá un script para nginx pero de momento esta posibilidad no existe aún.

Nuestro punto de partida es un servidor web que funciona en Debian 8.4 usando nginx como servidor web y wordpress como CMS. El fichero de definición para nuestro virtualhost es de lo mas sencillito que se despacha:

server {
        listen   80 default_server;
        root /var/www/myblog;
        index index.php;
        server_name www.myblog.com;
        access_log /var/log/nginx/myblog-access.log;
        error_log /var/log/nginx/myblog-error.log;
        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }
        error_page 404 /404.html;
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
              root /usr/share/nginx/www;
        }
        location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_param SCRIPT_FILENAME $request_filename;
		}
}

Lo primero que necesitamos es instalar el cliente de Lets Encrypt. Para ello ejecutamos lo siguiente (con privilegios de root):

apt-get install -y git
git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
cd /opt/letsencrypt
./letsencrypt-auto

El código anterior instala el paquete git y copia el código necesario al directorio /opt/letsencrypt. Luego nos posiciona en dicho directorio y ejecuta el script que realizará la instalación de dependencias necesarias (augeas, gcc y python), instalará los certificados raices en nuestro servidor y creará el directorio /etc/letsencrypt.

Lo siguiente que necesitamos es crear un directorio temporal para letsencrypt accesible a través de nuestro servidor web. En la documentación nos recomiendan hacerlo de la siguiente forma:

cd /var/www
mkdir letsencrypt
chown www-data:www-data letsencrypt

En tercer lugar crearemos un fichero de configuración con los datos del certificado que queremos crear. Dicho fichero debe de estar en el directorio /etc/letsencrypt/configs/ y debería de llamarse como el dominio para el que queremos crear el certificado pero añadiendo la extensión .conf. En nuestro caso, por tanto, el fichero se llamará www.myblog.com.conf y tendrá el siguiente contenido:

domains = www.myblog.com
rsa-key-size = 2048 # Si lo deseas puedes usar claves de 4096
server = https://acme-v01.api.letsencrypt.org/directory
email = josemaria@myblog.com # Recibirás recordatorios de renovación en esta dirección
text = True
authenticator = webroot
webroot-path = /var/www/letsencrypt/

Cuarto paso: tenemos que hacer accesible el directorio letsencrypt que creamos anteriormente en /var/www a nuestro servidor web. Para ello añadimos las siguientes líneas dentro del bloque server de la definición de nuestro virtualhost:

location /.well-known/acme-challenge {
        root /var/www/letsencrypt;
    }

Para que el cambio anterior tenga efecto necesitamos hacer un reload del servicio de nginx:

systemctl reload nginx
NOTA: Para asegurarte de que no has metido la pata al editar los ficheros de configuración de nginx puedes hacer un test antes del reload:

nginx -t

Ahora ya vamos a solicitar el certificado a Let’s Encrypt. Para ello ejecutamos lo siguiente:

cd /opt/letsencrypt
./letsencrypt-auto --config /etc/letsencrypt/configs/www.myblog.com.conf certonly

Si todo ha salido bien se descargará el certificado a nuestra máquina y obtendremos una salida similar a esta:

Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt --config /etc/letsencrypt/configs/www.myblog.com.conf certonly

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at
   /etc/letsencrypt/live/www.myblog.com/fullchain.pem. Your
   cert will expire on 2016-07-10. To obtain a new version of the
   certificate in the future, simply run Let's Encrypt again.
 - If you like Let's Encrypt, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Fíjate que el certificado descargado es válido sólo durante seis meses. Acuerdate de esto que luego veremos como renovarlo. Bien. Pues ya nos queda sólo ún último paso para terminar: tenemos que modificar de nuevo el fichero de definición del virtualhost de nuestro servidor web para que atienda las peticiones https, sepa donde está el certificado que necesita para ello y redireccione todas las peticiones que se hagan a través del puerto 80 al nuevo servicio que reside en el 443. El nuevo fichero de definición de virtualhost quedaría como sigue:

server {
        listen   80;
        server_name www.myblog.com;
        return 301 https://www.myblog.com/$request_uri;
}

server {
        listen   443 ssl default_server;
        root /var/www/myblog;
        index index.php;
        server_name www.myblog.com;
        location /.well-known/acme-challenge {
        	root /var/www/letsencrypt;
    	}
        ssl_certificate /etc/letsencrypt/live/www.myblog.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/www.myblog.com/privkey.pem;

        access_log /var/log/nginx/myblog-access.log;
        error_log /var/log/nginx/myblog-error.log;
        location / {
                try_files $uri $uri/ /index.php?q=$uri&$args;
        }
        error_page 404 /404.html;
        error_page 500 502 503 504 /50x.html;
        location = /50x.html {
              root /usr/share/nginx/www;
        }
        location ~ \.php$ {
		include snippets/fastcgi-php.conf;
		fastcgi_pass unix:/var/run/php5-fpm.sock;
		fastcgi_param SCRIPT_FILENAME $request_filename;
		}
}
NOTA: Si quieres ver que líneas hemos añadido basta con que compares con las líneas que hemos dejado un poco más arriba 😉

Volvemos a hacer un reload de la configuración de nginx y nuestro servidor ya debería de funcionar correctamente con https y, es más, redirigir todas las peticiones de enlaces a través de http que hubiera en cualquier sitio de internet al nuevo servicio https. Puedes comprobar las características del nuevo certificado que acabas de instalar a traves de los servicios de SSLABS

¿Hemos dicho que hemos terminado? Bueno, en realidad no… Faltarían un par de detallitos. El primero, acordarte de que el certificado caduca a los seis meses. Para renovarlo basta con ejecutar de nuevo lo siguiente:

cd /opt/letsencrypt
./letsencrypt-auto --config /etc/letsencrypt/configs/www.myblog.com.conf certonly

Pero los chicos que llevan nginx nos han dejado un útil script que podemos crear y programar desde crontab:

#!/bin/sh

cd /opt/letsencrypt/
./letsencrypt-auto --config /etc/letsencrypt/configs/my-domain.conf certonly
if [ $? -ne 0 ]
 then
        ERRORLOG=`tail /var/log/letsencrypt/letsencrypt.log`
        echo -e "The Let's Encrypt cert has not been renewed! \n \n" \
                 $ERRORLOG
 else
        nginx -s reload
fi
exit 0

Para que funcione debes de crear un directorio llamado letsencrypt colgando de /var/log. Allí se dejarán los mensajes de error en caso de que la renovación no pueda realizarse correctamente. Ah, y no apures los seis meses de vida del certificado hasta el final. Por si acaso… Lets Encrypt nos deja renovar nuestros certificados hasta 5 veces al día, así que si lo programas para que se ejecute cada cuatro meses, por ejemplo, no va a morirse nadie 😉

En segundo lugar, si nuestra web lleva funcionando desde hace tiempo con http, google nos tendrá indexados en multitud de sitios y si no queremos perder el ranking de esos enlaces debemos de informarle del cambio. Existe una guía editada por la propia Google donde nos dicen paso a paso como hacer esto.

En tercer y, ahora si, último lugar, aunque nuestro servicio redirige todas las peticiones http a https, estas redirecciones podrían penalizar un poco el rendimiento de nuestra web. Debemos de tratar de ir eliminando los antiguos enlaces que estén en nuestra mano y para ello deberíamos de empezar por la propia configuración de wordpress cambiando la dirección del sitio en la entrada de Ajustes Generales.

Si necesitas alguna otra cosa no cubierta aquí tienes disponible un completito manual aquí

ACTUALIZACIÓN: La mejor forma ahora de instalar los certificados de Let’s Encrypt es usar certbot. Además hay otros cambios sobre lo aquí escrito: un paquete en Debian backports llamado certbot, la caducidad de los certificados se ha bajado a tres meses y alguna cosilla mas… Así que usa este artículo como base si quieres pero no te lo creas todo a pies juntillas que se ha quedado viejo muy pronto!

Cambios en la configuración de nginx y php5-fpm en Debian 8 (Jessie)

nginx Hace unos días, tras actualizar la versión de Debian a Jessie, nginx dejó de funcionar correctamente. Servía sin problemas las páginas estáticas pero cuando trataba de interpretar una página php devolvía una página en blanco sin, aparentemente, ningún error. Ni en ficheros de logs, ni por pantalla, ni nada de nada. Parecía más bien un error de php5-fpm que de nginx o, tal vez, de la forma en que se comunican ambos. Probé la comunicación por puertos TCP en lugar de hacerlo por sockets como lo tenía por defecto y el resultado era el mismo… Así que como me pilló entre semana y con mucho trabajo hice una migración de urgencia a apache y lo dejé pendiente hasta que tuviera un ratito libre.
Hoy ya tocaba y la solución ha sido rápida puesto que el “problema” estaba reportado en la bendita lista de bugs de debian desde hace meses, cuando se detectó durante el testing de la nueva versión. Y pongo “problema” entre comillas porque en realidad se trata de un cambio de estructura a partir de la versión 1.6.2 de nginx (la que acompaña a Jessie) y que viene perfectamente documentado en el fichero index.html que se crea por defecto en el directorio /var/www/html (si, esto también cambia y es la nueva ubicación por defecto para las páginas web).
Existe algún otro cambio pero, para resumir, ahora cuando creas un virtual host que necesita usar php en lugar de usar el bloque de configuración que vimos por aquí hace unas semanas tendrás que usar este:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $request_filename;
    }

Plugins de nginx y php5-fpm para munin

herramientas Vamos a añadir una nueva entrada a las “sagas” sobre munin y nginx que tenemos abiertas desde hace poco. Concretamente vamos a ver como configurar y hacer funcionar los plugins que nos permitan monitorizar nginx y php-fpm desde munin. Como siempre lo haremos en un Debian (versión 7) y puede que en otra distribución algo sea ligeramente distinto.

Lo primero que debemos de hacer es habilitar la publicación de estadísticas tanto en nginx como en php-fpm. La forma de hacerlo en cada uno es distinta. Para nginx basta con que creemos una directiva como la siguiente en el fichero de definición de uno de los virtual hosts del mismo (típicamente en el virtual host por defecto):

location /nginx_status {
	stub_status on;
	access_log off;
	allow 127.0.0.1;
	deny all;
	}

Las dos últimas líneas sirven para evitar conexiones que no vengan de la propia máquina y podemos quitarlas (o modificar las restricciones) si queremos consultar estas estadísticas en tiempo real desde nuestro propio navegador. Habilitar las estadísticas para php-fpm es un poco más complicado. En primer lugar tenemos que habilitar la publicación de estadísticas en el fichero /etc/php5/fpm/pool.d/www.conf. Las estadísticas están deshabilitadas y para corregir esto basta con descomentar la siguiente línea y modificar el path por el que queramos usar:

pm.status_path = /fpm_status

Luego de nuevo en el fichero de configuración en el fichero de virtual host añadimos la siguiente directiva:

location /fpm_status {
	access_log off;
	include fastcgi_param;
	include snippets/fastcgi-php.conf;
	fastcgi_param SCRIPT_FILENAME $request_filename;
	fastcgi_pass unix:/var/run/php5-fpm.sock;
	allow 127.0.0.1;
	deny all;
	}

Aparte del mismo comentario hecho antes sobre las dos últimas líneas, obtserva que en la línea fastcgi_pass se indica que el acceso a fpm está configurado mediante sockets. Si tu accedes a través de puertos TCP tendrás que modificar esa línea por la correspondiente que, típicamente, suele ser esta:

fastcgi_pass 127.0.0.1:9000;

Una vez hecho esto comprobamos que no hemos cometido ningún error (service nginx configtest) pedimos a nginx que vuelva a leer la configuración (service nginx reload) y probamos que todo está correcto desde línea de comando mediante curl:

Probando la publicación de estado de nginx y fpm-php desde curl

NOTA: fpm tiene unas estadísticas mucho más completas detalladas proceso a proceso que podemos consultar con el siguiente comando:

curl http://localhost/fpm_status?full

El segundo paso sería editar el fichero /etc/munin/plugin-conf.d/munin-node para proporcionar a munin-node las variables de entorno oportunas. Hacemos esto añadiendo los siguientes dos bloques al final del mismo:

[nginx*]
env.url http://localhost/nginx_status

[phpfpm_*]
env.url http://localhost/fpm_status
env.ports 80
env.phpbin php-fpm
env.phppool www

En tercer lugar tenemos que decirle a munin-node que añada los plugins correspondientes. Los de nginx vienen “de serie” y basta con que creemos los enlaces a los mismos en el directorio /etc/munin/plugins como ya hemos hecho otras veces:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/nginx_connection_request
ln -s /usr/share/munin/plugins/nginx_memory
ln -s /usr/share/munin/plugins/nginx_request
ln -s /usr/share/munin/plugins/nginx_status

Los de php-fpm tenemos que bajárnoslos desde este enlace. Copiamos los cinco plugins en el directorio /usr/share/munin/plugins y luego creamos los enlaces al directorio /etc/munin/plugins:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/phpfpm_average
ln -s /usr/share/munin/plugins/phpfpm_connections
ln -s /usr/share/munin/plugins/phpfpm_memory
ln -s /usr/share/munin/plugins/phpfpm_processes
ln -s /usr/share/munin/plugins/phpfpm_status

Y ya casi hemos terminado. Sólo tenemos ahora que reiniciar el demonio de munin-node (service munin-node restart) y en unos minutos nos aparecerán las nuevas gráficas bajo las etiquetas de nginx y php:

Gráficos de monitorización de munin para nginx y php5-fpm

Migrando de Apache 2 a nginx: Virtual Hosts

nginxLos ficheros de definición de Virtual Hosts en nginx se almacenan en directorios muy similares a los de apache. Tenemos un directorio llamado sites-available y otro que se llama sites-enabled y ambos están bajo el directorio principal de configuración que es /etc/nginx. En el primero se deberían de guardar todos los virtual hosts del servidor (estén disponibles o no) y en el segundo aquellos que están activos. La forma correcta de activar o desactivar un Virtual Host debería de ser crear un enlace en el segundo directorio al archivo correspondiente del primero, al igual que en Apache. Para desactivarlo temporal o definitivamente borraríamos ese enlace. La diferencia aquí con apache es que no contamos con comandos similares a los a2ensite y a2dissite que hacen estas operaciones de forma cómoda, pero tampoco se nos van a caer los anillos por hacer un enlace manualmente en línea de comando a estas alturas ¿verdad? Bueno, por si acaso, el siguiente comando realizaría un enlace del fichero de definición de Virtual Host llamado miweb del directorio sites-availabe en el directorio sites-enabled:

ln -s /etc/nginx/sites-available/miweb /etc/nginx/sites-enabled/

Veamos ahora el “esqueleto” de configuración más básico en Apache:

<VirtualHost *:80>
	ServerName www.miweb.com
	ServerAlias blog.miweb.com *.miweb.es
	DocumentRoot /var/www/miweb/
	DirectoryIndex index.php index.html index.htm;
</VirtualHost>

Y su equivalente en nginx:

server {
        listen 80;
        server_name www.miweb.com blog.miweb.com *.miweb.es;
        root /var/www/miweb/;
        index index.php index.html index.htm;
}

Puesto que partimos de que conocemos la sintaxis en Apache no deberíamos de encontrar problemas en entender la de nginx ¿verdad? Sólo un detalle adicional sobre estas líneas. Si tenemos un servidor con más de un interfaz y/o dirección IP y queremos que el servidor web sólo atienda a una de ellas en Apache sustituiríamos la primera línea del ejemplo anterior por esta:

<VirtualHost 123.45.67.89:80>

En nginx haríamos lo propio modificando así la segunda línea:

listen 123.45.67.89:80;

Cualquier configuración adicional del Virtual Host se realizaría incluyendo las directrices adecuadas en el interior del bloque de definición. Veamos algunas de las más comunes. Por ejemplo, si queremos dar una ubicación concreta y separada del lugar donde se almacenan los logs de acceso y error, en Apache lo hacíamos con estas líneas:

CustomLog /var/log/apache2/miweb-access.log combined
ErrorLog /var/log/apache2/miweb-error.log
LogLevel warn

Y en nginx lo haríamos así:

access_log /var/log/nginx/miweb-access.log;
error_log /var/log/nginx/miweb-error.log warn;

El formato del log de accesos por defecto en nginx es idéntico al modo combined de Apache. No obstante, tenemos un montón de opciones adicionales que puedes consultar aquí. Los niveles permitidos para el log de error son, además de warn, error, crit, alert, y emerg.

¿Cómo redefinimos las páginas de error que nos mostrará el servidor web? En Apache usábamos la directiva ErrorDocument:

ErrorDocument 404 /errores/404.html
ErrorDocument 500 /errores/500.html
ErrorDocument 502 /errores/502.html
ErrorDocument 503 /errores/503.html
ErrorDocument 504 /errores/504.html

En nginx usamos error_page:

error_page 404 /errores/404.html;
error_page 500 /errores/500.html;
error_page 502 /errores/502.html;
error_page 503 /errores/503.html;
error_page 504 /errores/504.html;

Si queremos redireccionar varios errores a una misma página podemos hacerlo de esta forma:

error_page 500 502 503 504 /errores/500bis.html;

Veamos ahora como se restringe el acceso a ciertos directorios. En Apache, para denegar el acceso a todo el mundo a un directorio del servidor web lo hacíamos de esta forma:

<Directory /secreto>
        Deny from all
</Directory>

Mientras que en nginx haríamos lo mismo así:

location /secreto {
        deny all;
}

Para restringir el acceso a determinados clientes, en Apache “jugamos” con las directrices Order, Deny y Allow. En nginx no existe ninguna directiva similar a Order. Debemos de poner una a una todas las instrucciones deny y allow que necesitemos. El servidor las analizará una a una y en orden hasta encontrar la primera que “cuadre” con la petición que está atendiendo de forma similar a como se comportaría un cortafuegos. Las siguientes reglas son todas válidas:

location /secreto2 {
    deny  192.168.1.1;
    allow 192.168.1.0/24;
    allow 10.1.1.0/16;
    allow 2001:0db8::/32;
    deny  all;
}

Si lo que queremos es restringir el acceso mediante usuario y contraseña con un fichero generado con htpasswd como hacíamos habitualmente con Apache, podemos hacerlo de forma fácil. El fichero de contraseña lo generamos de la misma forma que ya sabemos (tienes que tener instalado el paquete apache2-utils para contar con esta utilidad) e incluir las siguientes directivas:

location /secreto3 {
    auth_basic "Control de Acceso";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

La línea auth_basic sólo aporta un mensaje de texto que aparecerá en la ventana en la que se nos pide el usuario y contraseña. La directiva auth_basic_user_file es la que marca el lugar y el nombre del fichero que contiene los usuarios y las contraseñas (las hashes de estas, en realidad) autorizadas para acceder al directorio /secreto3 de nuestro Virtual Host.

Si nuestro Virtual Host necesita interpretar páginas en PHP, debemos de pasar estas peticiones al módulo adecuado y tenemos que expecificarlo aquí, y no como ocurría en Apache que se hacía de forma automática con sólo tener activo el módulo php5. Yo uso php5-fpm (aunque existen otras alternativas) y para que funcione debemos de incluir un bloque como este:

location ~ \.php$ {
    try_files $uri =404;
    fastcgi_pass unix:/var/run/php5-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
ACTUALIZACIÓN MUY IMPORTANTE: A partir de la versión 1.6.2 de nginx en Debian 8 (Jessie) el anterior bloque de configuración para php ya no es válido y habría que usar en su lugar este otro.
ACTUALIZACIÓN: PHP-FPM puede usarse con puertos TCP o con sockets. Las ventajas de usar sockets te las cuenta brevemente aquí Javier Terceiro.

En Debian hay que instalar el paquete correspondiente (apt-get install php5-fpm) y asegurarse de que el módulo aceptará las peticiones en la dirección que hemos indicado con la directiva fastcgi_pass. Esto lo comprobamos en el fichero de configuración /etc/php5/fpm/pool.d/www.conf y buscando la línea siguiente:

listen = /var/run/php5-fpm.sock
IMPORTANTE: Si necesitas usar de forma imprescindible ficheros .htaccess este no es tu servidor web. nginx está diseñado para ser rápido y eficiente y no soporta nada parecido. Los .htaccess son cómodos para permitir pequeñas personalizaciones de configuración en servidores compartidos, pero en cualquier otro caso son absolutamente prescindibles y desde el punto de vista de la eficiencia son tremendamente negativos. Piensa que por cada petición que se hace al servidor web, este tiene que recorrer todos los directorios del Virtual Host uno por uno en busca de ficheros de este tipo. Aquí te lo explican muy bien y en este enlace y en este otro tienes herramientas automáticas para ayudarte a migrar las reglas que tengas en ellos a nginx.

Año nuevo, servidor web nuevo. Migrando a ningx

nginx Por aquello de terminar un año y empezar el siguiente con cambios y nuevos propósitos, ayer comencé a migrar la infraestructura que da soporte a este blog a nginx. Si has pasado por aquí en las últimas horas habrás podido experimentar problemas debido a los cambios. Ahora parece ya casi totalmente estable pero dista aún de estar optimizado y habrá que trabajar un poco mas en ello… Y bueno, ya que estamos, feliz año y tal 😉