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;
    }

Añadir repositorios de paquetes extras a un NAS de Synology

nginx Desde hace más de cuatro años centralizo mis copias de seguridad en un DS411j de Synology (producto ya descatalogado y sustituido por el DS414j. Se trata de un NAS de 4 bahías (de las que tengo ocupadas sólo tres con discos de 2 Teras en RAID5) y que poco a poco se ha convertido en un elemento indispensable para muchas otras tareas aparte de las mencionadas copias. Los NAS de Synology vienen con un sistema operativo propio llamado DSM (Diskstation Manager) que no es más que una distribución de Linux adaptada a estos dispositivos. Es verdad que no es tan flexible como usar FreeNAS u Openfiler, por ejemplo, pero el hardware de Synology es compacto silencioso y barato no demasiado caro. Resultón, vaya. Montar algo parecido por tu cuenta saldría bastante más caro y elegir los componentes adecuados llevaría un tiempo considerable si, como yo, no estás demasiado al día en cuanto al hardware que puedes utilizar para ello.

A lo que vamos. DSM es, como hemos dicho, una distribución Linux y como tal viene con sus propios repositorios de paquetes a los que accedemos a través de una aplicación denominada Centro de Paquetes.

Centro de paquetes de Synology DSM

Como suele ocurrir en sistemas similares, sólo encontramos software validado por el fabricante pero, al igual que en cualquier otro Linux, tenemos la posibilidad de añadir repositorios adicionales con software compilado por terceros. El procedimientos es bastante sencillo. En primer lugar entramos en la pantalla de Configuración (botón arriba a la derecha) y en la pestaña de opciones generales nos aseguramos de marcar la segunda opción en el Nivel de Confianza:

Configuración del Nivel de Confianza en DSM

A continuación pulsamos en la pestaña de Orígenes del paquete y hacemos click en el botón de agregar. La ventana emergente que aparece tiene sólo dos campos: un nombre identificativo y la URL del repositorio. En el ejemplo siguiente estoy añadiendo el repositorio de SynoCommunity cuya URL es http://packages.synocommunity.com/

Añadiendo un repositorio de paquetes en DSM

Y listo. Pulsamos aceptar y veremos una nueva opción llamada Comunidad en el menú lateral del Centro de Paquetes. Si pulsamos en ella veremos el nuevo software que tenemos disponible:

Software de terceros en el Centro de paquetes de DSM

Además del anterior yo tengo instalados dos repositorios más: el de Cphub (https://www.cphub.net/) y el de Synobox (http://synobox.fr.nf/synopackages/) pero hay muchos más. Tienes un par de listas con muchos otros repositorios aquí y aquí.

En cualquier momento puedes consultar y eliminar los repositorios añadidos en la pestaña de Orígenes del paquete vista anteriormente:

Repositorios de paquetes instalados en DSM

Además, cada uno de los repositorios instala al ser añadido un certificado que puedes consultar y/o eliminar desde la pestaña correspondiente:

Certificados de los repositorios de paquetes instalados en DSM

Chuletillas (y XXXXIII) – Extraer el audio a un vídeo usando ffmpeg o mencoder

chuleta Extraer el audio de un vídeo es otra de esas tareas que realizo de vez en cuando y que siempre tengo que buscar para recordar. Aquí queda la chuletilla de rigor para quién le sirva:

ffmpeg -i video_origen.avi -ab 128000 -ar 44100 audio_destino.mp3

Los dos argumentos usados (-ab y -ar) definen el audio bit rate (Tasa de bits) en bits por segundo y el audio sampling rate (Tasa de muestreo) en Herzios respectivamente y son los que van a definir la calidad del audio (y el tamaño del archivo) de salida. Ten en cuenta que si usas valores más altos de los que trae el audio del vídeo original ffmpeg lo que hará será interpolar los datos necesarios y puede que obtengamos peor calidad que en el original. No se puede sacar de donde no hay, que dice el refran 😉 El comando es válido con cualquier formato origen y/o destino cuyos codecs reconozca nuestro sistema: mkv, avi, mp4, mp3, ogg, wav, etc.

Y si prefieres usar mencoder tienes este otro comando que hace lo mismo:

mencoder video_origen.avi -of rawaudio -oac mp3lame -ovc copy -o audio_destino.mp3
NOTA: El segundo comando está sacado de Commandline Fu, un recurso inestimable para todos aquellos que apreciamos las virtudes de la línea de comandos.

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