Extender el tiempo de evaluación de productos Microsoft

Josemaría | 13 de julio de 2015 | 4 comentarios

windows Me suele incomodar bastante llegar a un instituto y encontrarme que las licencias de los sistemas operativos y programas de Microsoft (ya sea en máquinas virtuales o reales) son piratas. A veces, incluso, que algún profesor instruya a sus alumnos acerca de como crackearlas o, en algún caso, que le pida consejo de como hacerlo al espabilado de la clase. En su casa cada uno puede hacer lo que le plazca, pero en un centro de enseñanza donde se supone que estamos preparando a la gente para salir al mundo laboral no me parece una buena práctica en absoluto. No me gusta la política de licencias de Microsoft, pero siempre que he trabajado en una empresa me he negado a piratear licencias (aunque no siempre he podido mantener esta postura, para que negarlo). Pero mi idea en este sentido es que el que las quiera que las pague, y quien no quiera pagarlas, tiene buenas alternativas a todos sus sistemas y productos.

Además, si necesitas usar licencias Microsoft (y en ciclos formativos de Informática, como comprenderéis, es imprescindible) existen la posibilidad de usar licencias gratuitas de evaluación. Se pueden descargar desde aquí previo registro y suelen tener una validez inicial de entre 90, 120 o 180 días. Las licencias de evaluación son plenamente funcionales, pero una vez transcurrido el plazo estipulado suelen reiniciar el equipo sin previo aviso tras cada hora de funcionamiento.

Aunque los equipos en los centros educativos suelen “reformatearse” todos los años estos tiempos son insuficientes para un curso, pero pueden extenderse usando el Server License Manager. Una vez concluido el período de evaluación solo hay que ejecutar lo siguiente:

slmgr /rearm
Ejecutando un intérprete de comandos con privilegios reales de administrador en Windows 8.1IMPORTANTE: Recuerda que en los nuevos windows de escritorio aunque tu usuario tenga perfil de administrador no trabaja normalmente con esos privilegios (¡afortunadamente!), así que si no estás usando el verdadero administrador del sistema debes de ejecutar estos comandos forzando privilegios reales de administrador. Para ello, busca el icono del intérprete de comandos y pulsando sobre el el botón derecho del ratón elige la opción de “ejecutar como administrador”. Si no lo haces así, el comando dará un error diciendo que no puede ejecutarse.

Tras ejecutar esa instrucción y reiniciar el equipo la licencia se renovará por un tiempo igual al que tuvimos una vez instalada. Pero cuidado, no son tiempos acumulativos. Me explico: si instalamos un windwows 2008 server con 180 días iniciales de evaluación y transcurridos los primeros 100 días ejecutamos esa orden no nos encontraremos con un equipo al que restan 260 días para finalizar la evaluación, sino 180. Igual que recien instalado. Así que es importante que no “renovemos” la licencia hasta que esté agotado el periodo inicial. Esto es fácil puesto que Microsoft nos informa cuando el tiempo expira, pero si quieres hacerlo de forma más eficiente la propia Microsoft te explica como automatizar este procedimiento mediante un script. También dispones de opciones para comprobar los días que restan hasta la expiración (/dlv) y el número de renovaciones que has consumido y que aún te restan (/dli):

Y ahora lo mejor: esta renovación puede hacerse varias veces. Habitualmente al menos tres veces, pero no es una regla fija: A veces sólo permite una renovación adicional a los 90 días base, lo que nos da un período total de pruebas de 180 días (6 meses) mientras que otrs se nos permite hasta cinco o siete renovaciones de 180 días cada una (¡48 meses!¡Más que la vida útil de muchos equipos!

NOTA: El Server License Manager da mucho más juego de lo que he contado por aqui. Échale un vistazo a este texto si quieres ver otras utilidades para extender aún más la vida de tus licencias de evaluación 😉

Añadir iconos al escritorio de Openbox

Josemaría | 5 de junio de 2015 | 1 comentario

openbox Hace ya más de dos años que uso Openbox como escritorio y no pierdo ocasión para recomendarlo encarecidamente siempre que puedo. Es cinco veces más ligero que LXDE, diez que XCFE y casi 30 veces menos pesado que KDE. Aquí tienes la comparativa de la que salen estos datos. Además, aunque al principio no lo parezca, es fácilmente configurable y personalizable.

Hacía ya tiempo que tenía en borrador una pequeña guía de personalización y configuración con las tareas más comunes pero hace un par de meses que se me adelantó emezeta y como lo suyo está tan bien y tan completito no tiene ya sentido alguno repetirse… Sólo me voy a permitir hacer un añadido que a él se le ha pasado por alto: como poner iconos sobre el escritorio. Openbox por defecto no lo permite, pero existen varios técnicas para hacerlo. Vamos a ver una de ellas.

La forma más fácil consiste en hacerlo a través de un administrador de archivos. PcmanFM y/o Thunar suelen ser los más habituales en Openbox, así que vamos a explicar como hacerlo con el primero de estos. Lo primero que tenemos que hacer, lógicamente, es asegurarnos de que tenemos este administrador de ficheros instalado y en caso contrario hacerlo. En Archlinux o una derivada lo hacemos así:

sudo pacman -S pcmanfm

A continuación ejecutamos lo siguiente:

pcmanfm --desktop

Y ya. Con esto le estamos indicando a pcmanfm que será el encargado de gestionar el escritorio. Automáticamente nos mostrará los iconos que tengamos en el directorio Desktop (o desktop, o Ecritorio según la distribución) de nuestro home y todo lo que creemos o enlacemos en este directorio aparecerá en nuestro Escritorio. Los efectos “colaterales” son varios y algunos de difícil resolución. Ahora ya no podremos gestionar los fondos de pantalla con Nitrogen ni tendremos disponible el menú de aplicaciones que antes aparecía al pulsar el botón izquierdo del ratón en cualquier zona libre del escritorio. Además, si estábamos usando conky habrá desaparecido “ocultado” por pcmanfm.

Lo de conky lo podemos arreglar fácilmente. Sólo tenemos que editar el fichero .conkyrc (que debe de estar en el directorio raíz de nuestro home), buscar el parámetro own_window_type y sustituir su valor (desktop) por normal:

own_window_type normal

Para configurar un fondo de pantalla y automatizar este ajuste en el arranque del sistema debemos editar el fichero autostart que estará en el directorio .config/openbox de nuestro home. Allí buscaremos la referencia a nitrogen que debería de ser algo como nitrogen --restore & y la sustituiremos por las siguientes líneas:

pcmanfm --desktop &
sleep 1s
pcmanfm --set-wallpaper=/usr/share/backgrounds/evodark.jpg

Openbox con iconos mediante pcmanfm

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

Josemaría | 23 de mayo de 2015 | 2 comentarios

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

Josemaría | 12 de mayo de 2015 | 5 comentarios

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

Categorías: howto´s, tecnología
Etiquetas: , , , ,

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

Josemaría | 11 de mayo de 2015 | 3 comentarios

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

Josemaría | 5 de mayo de 2015 | 4 comentarios

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

Daredevil (y mi amor incontenible hacia Netflix)

Josemaría | 14 de abril de 2015 | 1 comentario

nginx Entre el sábado (tres del tirón) y ayer lunes (1) me he visto ya los cuatro primeros episodios de Daredevil, la nueva serie Marvel producida por Netflix, y he de decir que aunque mis expectativas eran altas han quedado, más que colmadas, rebosadas. Y no soy el único, al parecer: la media de la puntuación por episiodio en IMDB va desde el 8,9 del primero hasta el 9,7 del último.

Daredevil Teaser Poster

En estos cuatro episodios se ve violencia cruda (casi, casi del estilo de una película de Tarantino, así que nada de dejarse ir por el entusiasmo y verla con vuestros pequeños), fabulosas y bastante realistas coregrafías en las peleas (donde el bueno del señor Murdock se lleva unas mantas de palos increíbles) y personajes secundarios bien construidos. Foggy Nelson está para invitarlo a salir, Karen Page y Claire Temple tampoco desmerecen… y el Kingpin interpretado por el enorme Vincent D’Onofrio convence desde los escasos minutos en que hace su aparición al final del tercer episodio y llena la pantalla aún sin necesidad de las decenas de kilos extras con que estamos acostumbrados a verlo en los comics. Las referencias al resto del universo Marvel u otros super heroes se han limitado, por el momento, a la mención indirecta a la llamada “Batalla de Nueva York” con que cierra la primera película de Los Vengadores, pero tampoco se han echado en falta, la verdad. Imagino que irá apareciendo alguna referencia adicional a medida que la serie avance y también nexos de unión con futuros productos de la casa (ahí está la señora Temple, por ejemplo).

La serie, para que nadie se llame a engaños, está más enfocada en el plano de los heroes que en el de los super. No esperes superpoderes, deslumbrantes uniformes ni grandes efectos especiales. Es, por simplificar, la historia de un tipo muy duro que reparte caña entre los malos, disfruta mientras lo hace y luego se atormenta por haberlo hecho. Pero todo muy bien contado, de veras.

Visto lo visto, los trece episodios me van a saber a muy poco, creo. Menos mal que a final de año tendremos disponible la serie dedicada a Jessica Jones y el año que viene la de Powerman. Más tarde llegarán Puño de hierro y, finalmente, una quinta serie sobre los Defensores que unirá a los cuatro personajes anteriores y cerrará la saga. ¡Larga vida a Netflix!

Migrando de Apache 2 a nginx: Virtual Hosts

Josemaría | 25 de marzo de 2015 | 4 comentarios

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.

Chuletillas (y XXXXII) – Eliminar paquetes huérfanos y dependencias no utilizadas en Archlinux y derivadas

Josemaría | 19 de marzo de 2015 | Comentar

chuleta Hace ya años que sólo uso Archlinux o derivadas en mis equipos de escritorio, ya sean estos portátiles o equipos de sobremesa. Empecé con la propia Archlinux para luego pasar a Chakra y, por último, a Manjaro que es actualmente mi favorita.
El siguiente comando nos permite eliminar todos los paquetes huérfanos y dependencias no utilizadas de forma equivalente a como haríamos en una Debian o derivada con apt-get autoremove:

pacman -Rcns $(pacman -Qdtq)

La segunda parte del comando (pacman -Qdtq) es la que realiza el listado de dependencias inútiles mientras que la primera (pacman -Rcns) las recibe y elimina después de mostrárnos la lista en pantalla y pedirnos confirmación.

NOTA: Por aquí dejé hace algún tiempo una chuleta con los primeros pasos a dar con pacman y ccr que sigue siendo válida. ccr es el gestor de paquetes realizados por la comunidad de usuarios (no oficiales, por tanto) de Chakra. En Archlinux y Manjaro se usa yaourt en lugar de ccr pero el funcionamiento de ambas es bastante similar.

Lo más visto por aquí en 2014

Josemaría | 2 de enero de 2015 | Comentar

icono de calendarioEa, otro año más por aqui para hacer una pequeña lista con los temas que más se han leído en el blog durante los últimos doce meses por si a mi lector se le ha pasado alguno por alto. Mi ritmo de publicación ha caído tanto que al final los peperos van a tener razón con eso de la baja productividad del país. Con una media de dos entradas al mes (un tercio menos de lo que publiqué en 2013) este blog está predestinado a extinguirse en un par de años. Menos mal que Google no es tan bueno como dicen (¿tampoco lo sabes ya?¿y se supone que mis lectores tienen un alto perfíl técnico?¡Buffff!) y me sigue permitiendo vivir de las rentas… En fin que allá vamos a hacer el repaso este y con él a sentar buenos propósitos de prolífica actividad para este 2015. Como todos los años, vaya 😉