Inspeccionando la cola de correos sin entregar en Postfix

Josemaría | 25 de marzo de 2014 | 5 comentarios

correo No suele ser habitual que postfix encole y/o retrase la entrega de correos electrónicos. Pero a veces ocurre. Por ejemplo por problemas de time-out con el servidor al que tiene que hacer la entrega. Si monitorizamos las colas de nuestro servidor (por ejemplo con munin) podemos observar cuando pasa y con que frecuencia:

Cola de mensajes retrasados (deferred) en postfix

Por defecto se reintenta la entrega de los correos cada 5 minutos y se descartan (generando un correo de advertencia al remitente) si no ha podido hacerse transcurridos cinco días del envío. Podemos variar estos valores introduciendo los siguientes parámetros en el fichero de configuración principal (/etc/postfix/main.cf):

queue_run_delay = 600
maximal_queue_lifetime = 1d

Existen más parámetros relacionados con esta directiva en este enlace del manual de postfix.

Podemos inspeccionar la cola de postfix para ver que mensajes no ha podido entregar y la causa de ello en cualquier momento usando los comandos mailq o postqueue -p (ambos son equivalentes y proporcionan la misma salida aunque mailq es un comando mucho más flexible y potente con más opciones. Consulta el manual ;-) )

Viendo el contenido de la cola de mensajes retrasados (deferred) en postfix

¿Ves el código alfanumérico de 10 caracteres con que empieza cada entrada de la cola? Es el identificador del mensaje que nos permite ver mucha más información acerca del mismo, su estado y su contenido usando el comando postcat -vq seguido de dicho identificador. Por ejemplo, para inspeccionar el primer mensaje de la cola de aquí arriba:

postcat -vq A3C3486137

También podemos decirle en cualquier momento a postfix que reprocese esos mensajes mediante los comandos postqueue -f o postfix flush. O podemos pedirle que reintente sólo uno de los mensajes de la cola usando el identificador que ya conocemos así:

postqueue -i A3C3486137

Por último, para eliminar todos los mensajes en espera de entrega que están en la cola podemos usar el siguiente comando:

postsuper -d ALL deferred

Ten en cuenta que, en este caso, los mensajes serán eliminados sin que el remitente reciba ningún tipo de notificación de que no ha podido realizarse la entrega.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

RAID por software en Debian 7 con mdadm

Josemaría | 23 de octubre de 2013 | 2 comentarios

hard disk Para el que no lo sepa, un RAID en informática no es una carrera de aventuras sino un disco duro lógico creado a partir de la union de dos o más discos duros físicos con objeto (por lo general aunque no siempre) de proporcionar tolerancia a fallos. Las siglas vienen de Redundant Array of Inexpensive Disks y hace referencia a que, en su día, constituían una alternativa para proporcionar un almacenamiento seguro usando discos baratos en lugar de unos mucho más caros (por lo general SCSI). Ahí está la wikipedia para quién quiera aprender un poquito más ;-)

El método más seguro de usar esta tecnología es mediante hardware dedicado. Eso que quede claro. Pero cuando no queremos o no podemos gastarnos el dinero que esto requiere tenemos la alternativa de implementarlo mediante software. En Linux tenemos para ello mdadm, una herramienta en línea de comando muy sencilla de usar si entendemos los conceptos básicos de lo que estamos haciendo.

La instalación en una Debian es así de sencilla:

apt-get install mdadm

El script de configuración posterior a la instalación sólo nos planteará dos cuestiones. Leelas atentamente (como siempre… ;-) ). En la primera se nos pregunta si el sistema de ficheros raíz de nuestro Linux estará en un RAID con objeto de iniciarlo antes de la secuencia de arranque. En este ejemplo le diremos que no puesto que sólo usaremos RAID para los discos de datos, así que responderemos con none como se nos indica en el mensaje siguiente:

Instalación de mdadm en Debian Linux
En la segunda pregunta se nos interroga acerca de si queremos que los discos RAID que vamos a crear se inicialicen de forma automática durante cada inicio de la máquina o si preferimos hacerlo nosotros manualmente. Contestaremos que queremos que lo haga de forma automática.

Instalación de mdadm en Debian Linux
Una vez instalado mdadm ya podemos crear nuestro RAID. En el ejemplo que vamos a ver crearemos un RAID5 con tres discos de 500GB. El comando lsblk es muy cómodo para ver que asignación de nombres le ha hecho nuestro sistema a estos dispositivos:

Comprobando la asignación de nombres de dispositivos a nuestros discos duros con lsblk
El comando básico para crear un RAID es este:

mdadm --create dispositivo-md --level=x --raid-devices=z dispositivos-sd

O en formato abreviado:

mdadm --create dispositivo-md -l x -n z dispositivos-sd

Donde x es el nivel de RAID (admite los básicos 0, 1, 4, 5, 6, 10 y alguno más) y z el número de discos que formarán el array. El dispositivo-md será el nombre de dispositivo que recibirá el nuevo disco lógico (y que debería de estar en el directorio /dev y, por convención, llamarse md seguido de un número, por ejemplo /dev/md0) y los dispositivos-sd serían los discos físicos que forman el array separados por espacios (por ejemplo /dev/sdb /dev/sdc). Podemos añadir también la opción --verbose para obtener información más detallada del proceso de creación y los posibles fallos. Veamos un par de ejemplos:

Para crear un RAID0 con los tres discos indicados:

mdadm --create --verbose /dev/md0 --level=0 --raid-devices=3 /dev/sda /dev/sdb /dev/sdc

Para crear un mirror (RAID1) con los discos indicados:

mdadm --create /dev/md0 -l 1 -n 2 /dev/sdb /dev/sdc

La creación admite, aparte de estas, otras opciones avanzadas que puedes consultar en el manual que se ha instalado con él (man mdadm). Y vamos ya a seguir con nuestro ejemplo. Para crear el RAID5 que necesitamos ejecutamos lo siguiente:

mdadm --create --verbose /dev/md0 --level=5 -n 3 /dev/sdb /dev/sdc /dev/sdd

Si todo ha salido bien se nos mostrarán algunos mensajes informativos y el comando finalizará indicando que el disco md0 ha sido inicializado y arrancado. Podemos comprobar el estado de nuevo con lsblk o con more /proc/mdstat
Comprobando el estado de un RAID5 recién creado con mdadm

Para poder utilizar nuestro disco debemos aún formatearlo y montarlo en nuestro sistema de ficheros. Vamos a formatearlo como ext4 y a montarlo en un directorio que se llame datos dentro del subdirectorio /mnt:

mke2fs -t ext4 /dev/md0
mkdir /mnt/datos
mount /dev/md0 /mnt/datos

Si usamos ahora, por ejemplo, el comando df (df -k /mnt/datos) para ver el espacio de la partición y el porcentaje de uso veremos que, efectivamente, disponemos de cerca de 1TB correspondiente al tamaño del RAID5 con tres discos de 500GB que hemos montado.

Nos falta aún algo más. Durante la instalación le hemos dicho a mdadm que inicie de forma automática todos los arrays, pero eso no significa que los monte en el sistema de ficheros. Si queremos que lo haga automáticamente en cada arranque y en el mismo directorio donde lo acabamos de hacer de forma manual, tendremos que añadir una línea como la siguiente al fichero /etc/fstab:

/dev/md0  /mnt/datos  ext4  defaults  0  1

Vamos a echarle ahora un vistazo a diversos comandos de gestión y monitorización. Si queremos detener el volumen usamos el argumento --stop. No olvides desmontarlo antes para evitar que haya pérdida de datos:

umount /dev/md0
mdadm --stop /dev/md0

Luego, para volver a arrancarlo de forma manual:

mdadm --assemble /dev/md0 /dev/sdb /dev/sdc /dev/sdd

Y si habíamos incluido la línea que indicamos antes en el fichero fstab para volver a montar el disco en nuestro sistema de ficheros basta con hacer esto:

mount /dev/m0 /mnt/datos

Para ver información de todos los arrays que tenemos en funcionamiento en la máquina usamos el argumento --detail:

mdadm --detail --verbose --scan

Información de los RAID en una máquina con mdadm

Sólo tenemos uno, claro. Para ver información en detalle del mismo:

mdadm --detail --verbose /dev/md0

Información en detalle de un RAID con mdadm

O también podemos usar el argumento --examine para ver información y el estado de cualquier a de los discos que forman nuestro array:
Información en detalle de uno de los discos de un RAID con mdadm

Vamos a simular ahora la rotura de uno de los discos. Para ello apagamos la máquina bruscamente y desconectamos uno de los tres discos del RAID. Podemos hacer fácilmente esta prueba tanto en una máquina real (¡que no esté en producción!) como en una virtual. Tras arrancar de nuevo nuestro RAID habrá perdido la tolerancia a fallos. No obstante, si hemos creado o copiado datos en el directorio /mnt/datos veremos que estos siguen siendo perfectamente accesibles.

OJO: Si el RAID no estaba aún totalmente inicializado (hemos usado discos muy grandes y no ha pasado suficiente tiempo desde su creación o desde la última vez que se recuperó de un fallo) el volumen no arrancará correctamente. Es por tanto muy importante no comenzar a usarlo hasta que no se ha inicializado completamente y extremar las precauciones después del fallo de algún disco hasta que volvemos a recuperar la tolerancia a fallos. Si miramos el pantallazo de aquí arriba en el que aparece la salida de ejecutar more /proc/mdstat vemos que allí aparece una barra de progreso donde se indica el estado de creación o reconstrucción del RAID. Mientras que esa barra no llegue al 100% y desaparezca mejor que no tengas ningún problema ;-)

Para recuperar la tolerancia a fallos debemos de añadir un disco nuevo. Lo hacemos y una vez arrancada de nuevo la máquina ejecutamos lo siguiente para añadir el disco /dev/sdc a nuestro RAID en sustitución del que hemos simulado que se ha roto:

mdadm /dev/md0 --add /dev/sdc

El RAID se reconstruirá sólo de forma automática pero dependiendo del tamaño y del volumen de datos podrá tardar más o menos tiempo. Observa de vez en cuando la salida de more /proc/mdstat para estar al tanto.

OJO: Después de perder un disco los nombres de los dispositivos pueden haber “bailado”. Es muy importante que comprobemos antes (con lsblk, por ejemplo) cuales son los que siguen formando parte del array y cual el nuevo que queremos añadir.

Si lo que queremos es añadir al RAID un nuevo disco para que sea usado como hot spare basta con sumarlo a un RAID ya creado y funcional con el mismo comando que usamos antes para añadir un disco a un RAID estropeado:

mdadm /dev/md0 --add /dev/sde

Si lo que queremos es añadir el disco para agrandar el tamaño del RAID y no para que sea usado como hot spare tendríamos que usar los siguientes comandos:

mdadm /dev/md0 --add /dev/sde
mdadm --grow /dev/md0 –raid-devices=4

En el fichero /proc/mdstat podemos ver el proceso como siempre:
Haciendo crecer nuestro RAID añadiendo un nuevo disco

Lo que no nos va a resolvernos mdadm es hacer que la partición que habíamos creado en el disco y sobre la que estábamos trabajando crezca. Eso es tarea nuestra:

umount /dev/md0
e2fsck -f /dev/md0
resize2fs /dev/md0
mount /dev/md0 /mnt/datos

Y el resultado:
Extendiendo la partición de un RAID al que hemos añadido un nuevo disco

NOTA: Como se puede observar, durante este último proceso de crecimiento del RAID hemos trabajado con cuatro discos (tres originalmente) de 1GB cada uno en lugar de los de 500GB que hemos usado en el resto del tutorial. Quería que se apreciara el cambio de tamaño del volumen y la resincronización de discos tan grandes habría supuesto tener que esperar muchas horas para poder visualizar el proceso completo.

Si lo que queremos es eliminar uno de los discos del RAID (para reemplazarlo por otro, por ejemplo) tenemos antes que marcarlo como fail. Luego lo eliminamos:

mdadm /dev/md0 --fail /dev/sdd
mdadm /dev/md0 --remove /dev/sdd

Y si quisiéramos eliminar el RAID usamos este comando:

mdadm --remove /dev/md0

mdadm tiene también un argumento llamado --monitor que le permite generar alertas cuando ocurre alguna incidencia en el RAID. Por defecto en una Debian el monitor se arranca como un daemon que graba las incidencias en el fichero de logs de la máquina (/var/log/syslog) de esta forma:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog

Si, además, quisiéramos que nos enviara dichas incidencias a nuestra cuenta de correo deberíamos de añadir la opción --mail:

mdadm --monitor --pid-file /run/mdadm/monitor.pid --daemonise --scan --syslog --mail josemaria@uponday.net
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Greylisting en Postfix y Debian 7

Josemaría | 27 de septiembre de 2013 | 2 comentarios

correoNadie se acuerda de Santa Bárbara hasta que truena, que dice el refrán. Yo tenía pendiente configurar un sistema de Greylisting (listas grises) en mi servidor de correo pero no lo he visto como urgente e inmediato hasta el aumento inusitado de actividad de los bots de spam de los últimos días.

El Greylisting es, hoy por hoy, uno de los métodos más efectivos a la hora de controlar el spam y su funcionamiento es sencillo y fácil de entender. Cuando un servidor de correo recibe un mensaje anota en una lista tres datos que lo identifican (la IP desde donde viene, el correo del remitente y el del receptor) y a continuación lo rechaza indicando al emisor que lo intente de nuevo más tarde. Esto se hace con un código 45x:

-> MAIL FROM: <sender@somedomain.com>
<- 250 2.1.0 Sender ok
-> RCPT TO: <recipient@otherdomain.com>
<- 451 4.7.1 Please try again later

Si el mensaje ha sido enviado por un servidor SMTP legítimo reconocerá el mensaje de rechazo y en un tiempo predefinido (típicamente de 300 segundos) reenviará de nuevo el correo que, en este caso, será aceptado por el servidor del destinatario. Un bot preparado para enviar spam no realizará el segundo envío. De esta forma, si el correo no es spam llegará al destinatario con 5 minutos de retraso. Salvo este detalle el emisor no se enterará de nada (todo el trabajo se hace entre los servidores de correo sin que los clientes intervengan). Si el receptor abre la cabecera del mensaje recibido verá una línea parecida a esta:

X-Greylist: delayed 300 seconds by postgrey-1.34 at invernalia; Thu, 19 Sep 2013 16:30:33 CEST

El sistema de control del spam mediante Greylisting fue originalmente ideado por Evan Harris en este whitepaper de 2003. El señor Harris mantiene, además, una lista de implementaciones de su método para diversos servidores de correo. Si quieres más información conceptual sobre esta técnica, esta página y la entrada correspondiente de la wikipedia también tienen información interesante.

Si ya tienes una Debian con un servidor de correo postfix funcionando la implementación en perl del Greylisting es muy, muy fácil de poner en marcha. Basta con instalar el paquete postgrey y añadir check_policy_service inet:127.0.0.1:10023 en la lista de restricciones del fichero main.cf de configuración de postfix en el directorio /etc/postfix:

smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_unauth_pipelining, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_policy_service inet:127.0.0.1:10023

Por supuesto, una vez hechas ambas cosas debemos de reiniciar el servicio postfix. La instalación nos ha creado un nuevo servicio llamado postgrey que arranca como daemon y escucha en el puerto 10023 y que responde a los argumentos habituales: start, stop, restart, reload, force-reload y status. En el directorio /etc/postgrey tenemos dos ficheros denominados whitelist_clients y whitelist_recipients donde, respectivamente, se pueden especificar las direcciones de ciertos servidores smtp o direcciones de correo que no se someteran al procedimiento de rechazo temporal de los mensajes y que se aceptaran al primer intento. Tenemos, además, un fichero donde se encuentra la configuración principal del servicio llamado /etc/default/postgrey que veremos más adelante.

Si observamos ahora el log de nuestro postfix (/var/log/mail.log) podemos estudiar el funcionamiento y si este es correcto. Cuando recibimos cualquier correo (salvo uno ya identificado como válido en las whitelist) será inmediatamente registrado y rechazado:

Al cabo de cinco minutos si el correo es legítimo el servidor remitente volverá a intentarlo y ahora el correo si será aceptado:

Puede que el servidor emisor se impaciente y antes de que transcurran esos cinco minutos vuelva a intentarlo. En ese caso el correo volverá a ser rechazado:

Como puedes observar en los mensajes del log, aparte de la razón del rechazo el servidor enviará una dirección web personalizada donde se informa detalladamente de lo que está ocurriendo:

mensaje de información de postgrey en castellano

Postgrey crea, además, una base de datos en el directorio /var/lib/postgrey donde guarda información acerca de los mensajes recibidos. Después de aceptar cinco mensajes de un servidor, este será automáticamente incluido en una whitelist de tal forma que, a partir de este momento, ya no se le volverá a exigir el trámite de los reintentos. Podemos consultar en cualquier momento los servidores de esta lista ejecutando el siguiente script:

perl /usr/share/doc/postgrey/postgrey_clients_dump

Y una ejecución de ejemplo:

Servidores incluidos en la whitelist de greylist

Tenemos aún pendiente ver el fichero de configuración principal: /etc/default/postgrey. En el podemos modificar, por ejemplo, el texto que aparecerá en el mensaje de rechazo:

POSTGREY_TEXT="Si tu sevidor funciona como debiera debería de intentar enviarme de nuevo el mensaje en 5 minutillos de nada"

También podemos enviar al demonio cualquiera de los argumentos que tenemos disponibles para modificar su funcionamiento (ver man postgrey) mediante el parámetro POSTGREY_OPTS. Por ejemplo, en la siguiente línea se dice al demonio que escuche en el puerto 60000, subimos el retraso para aceptar el mensaje a 600 segundos y le indicamos que incluya las direcciones de los clientes en la whitelist después de aceptarles 3 envíos:

POSTGREY_OPTS="--inet=60000 --delay=600 --auto-whitelist-clients=3"

Para terminar, si quieres comprobar la configuración de tu servidor de correo electrónico para ver si es vulnerable de alguna forma y puede ser usado como un Open Relay, si el correo saliente que envía puede verse bloqueado de alguna forma, etc. existen muchas herramientas en línea pero las más cómodas y completas, a mi juicio, son las de mxtoolbox y el test de allaboutspam.

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Plugins de memcached y bind9 para munin

Josemaría | 5 de septiembre de 2013 | Comentar

herramientasEl otro día dejamos munin instalado y funcionando con los plugins más comunes que vienen de serie y se configuran de forma automática sin (casi) necesidad de manipulación extra alguna. El principal problema que vamos a encontrar con esta herramienta de monitorización es que cuando tratemos de instalar alguno de los centenares de plugins adicionales de que dispone nos encontraremos, según el caso, una información bastante irregular en cuanto a la forma en que tenemos que hacerlo: dependencias, configuración, etc. Hoy vamos a instalar un par de estos plugins adicionales de forma manual y así conoceremos un poco mejor sus tripas y veréis claramente a lo que me refiero.

La primera herramienta que debemos de conocer a la hora de añadir plugins adicionales es munin-node-configure, un script que nos ayuda a identificar que plugins nos pueden resultar útiles y ayudarnos a instalarlos. Como ya vimos, la instalación base de munin identifica muchos de los elementos que pueden resultarnos útiles y los configura e instala, pero si existe algún requisito o dependencia adicional para que funcionen no es capaz de resolverlo aunque si deja un mensaje informándonos de ello si usamos el parámetro --suggest. No suelen ser muy descriptivos y suele hacer falta hacer uso de Google para encontrar la solución (por ejemplo, si te falta la librería libcache-cache-perl para que funcione el plugin de MySQL el mensaje que aparece es “Missing dependency Cache::Cache”), pero bueno, algo es algo.

Para configurar el plugin de bind9 no necesitamos instalar nada adicional, pero si hacer algunos cambios en la configuración de nuestro servidor DNS. En el archivo named.conf.options (típicamente en el directorio /etc/bind) tenemos que introducir la siguiente línea dentro del bloque de options:

statistics-file "/var/cache/bind/named.stats";

Y añadir al final del fichero el siguiente bloque:

logging {
        channel b_query {
                file "/var/log/bind9/query.log" versions 2 size 1m;
                print-time yes;
                severity info;
        };
        category queries { b_query; };
};

A continuación creamos el directorio /var/log/bind9, le damos permisos de escritura al usuario bind, reiniciamos el demonio de nuestro servidor DNS y ejecutamos el comando rndc stats. Con esto el servicio dejará los logs detallados de estadísticas de consultas en ese directorio. A continuación tenemos que configurar el plugin de munin para que las lea y nos las muestre de forma gráfica. Para ello editamos el fichero /etc/munin/plugin-conf.d/munin-node y añadimos los siguientes bloques:

[bind9]
user root
env.logfile   /var/log/bind9/query.log

[bind9_rndc]
user root
env.querystats /var/cache/bind/named.stats

Por último, creamos un enlace a los plugins en el directorio de configuración como explicábamos el otro día:

ln -s /usr/share/munin/plugins/bind9 /etc/munin/plugins/bind9
ln -s /usr/share/munin/plugins/bind9_rndc /etc/munin/plugins/bind9_rndc 

Y ya sólo nos queda reiniciar el demonio munin-node. Casi inmediatamente tendremos una nueva categoría de gráficos dedicada a la monitorización de nuestro servicio de nombres:

Plugin de bind9 para munin

La configuración del plugin para memcached es bastante más sencilla. Lo primero que debemos de hacer es instalar el paquete libcache-memcached-perl (en una debian o derivada). A continuación añadimos el siguiente bloque en el archivo /etc/munin/plugin-conf.d/munin-node:

[memcached_*]  
env.host 127.0.0.1  
env.port 11211  
env.timescale 3

Creamos los enlaces:

ln -s /usr/share/munin/plugins/memcached_bytes /etc/munin/plugins/memcached_bytes
ln -s /usr/share/munin/plugins/memcached_counters /etc/munin/plugins/memcached_counters
ln -s /usr/share/munin/plugins/memcached_rates /etc/munin/plugins/memcached_rates

Reinciamos munin-node y ya:

Plugin de memcached para munin

NOTA: Tienes información bastante detallada acerca del fichero de configuración munin-node, las opciones que admite y su significado en este enlace.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalación y primeros pasos con Munin en Debian 7

Josemaría | 17 de junio de 2013 | 4 comentarios

herramientas Munin es un sistema de monitorización muy similar a cacti (que ya hemos tratado hace poco por aquí) pero que en lugar de usar snmp usa su propio programa recolector de información (llamado munin-node). La instalación básica sobre un único servidor (que es la que vamos a ver) es muy sencilla y proporciona más de 60 gráficas y cerca de 100 indicadores del estado y rendimiento de nuestro servidor sin que apenas tengamos que despeinarnos. Está escrito en perl, viene con una amplia colección de plugins (a la que se le añaden las múltiples contribuciones de los usuarios) y también admite monitorización de servidores windows.

La versión actual en los repositorios estables de Debian wheezy es 2.0.6-4 (de aproximadamente un año de antiguedad) que será la que instalaremos aquí. Si usas los repositorios de la versión inestable (sid) tienes disponible la versión 2.0.14. La máquina donde queremos instalarlo es un servidor LAMP típico con Apache2 y MySQL. Los paquetes necesarios son estos. Y sus dependencias, claro:

apt-get install munin munin-node munin-plugins-extra
NOTA: La versión de munin en una debian estable es la 2.06 mientras que en backports tienes disponible la 2.0.19. Si quieres instalar esta última basta con que sigas las instrucciones que se te indican aquí.

La instalación por defecto en Debian configura Munin para que sólo pueda accederse a la instancia web de monitorización desde la misma máquina en la que hemos realizada la instalación. Para solucionar esto y poder acceder en remoto a través de un navegador tenemos que editar el fichero /etc/apache2/conf.d/munin en el que se encuentra la configuración de la instancia web. Buscamos la directiva <Directory /var/cache/munin/www> y en su interior comentamos las líneas siguientes:

# Order allow,deny
# Allow from localhost 127.0.0.0/8 ::1

Y añadimos esta otra:

Order deny,allow

Luego repetimos la misma operación en las directivas <Location /munin-cgi/munin-cgi-graph> y <Location /munin-cgi/munin-cgi-html>. Con esto el acceso será libre para cualquiera que conozca la URL de acceso. Si queremos proteger la entrada mediante usuario y contraseña podemos, por ejemplo, usar htdigest como contábamos por aquí en su día.

Y listo. Ahora recargamos la configuración de apache:

service apache2 reload

Y ya podemos acceder a través de la URL http://ip-del-servidor/munin/. La pantalla inicial, una vez introducida la identificación, es así de sosa minimalista:

Primera ejecución de munin. Pantalla inicial.

Vamos a pararnos un poco a ver donde ubica sus diferentes elementos. Como ya hemos comentado, munin usa una estructura cliente servidor con nodos recolectores en cada uno de los equipos que queremos monitorizar y un elemento que centraliza la información de todos ellos. El daemon del primer elemento se llama munin-node y el del segundo munin. Ambos son servicios que residen, como es habitual, en el directorio /etc/init.d y responden a los argumentos habituales (start y stop). munin-node responde, además, a restart (necesario cuando añadimos un nuevo plugin o modificamos la configuración de uno ya existente) y alguno mas.

Los archivos de configuración se encuentran en /etc/munin/. Existen, entre otros, un archivo por cada uno de los servicios (munin.conf y munin-node.conf) y un directorio donde se encuentran los plugins en uso de este nodo. El procedimiento para activar los plugins es crear un enlace en este directorio al archivo que contiene el código del plugin. Los que vienen por defecto con la instalación se encuentran en /usr/share/munin/plugins/.

Por último, los datos de la instancia web de monitorización se encuentran en /var/cache/munin/www/, la base de datos en bruto en /var/lib/munin/ (no, no usa mysql como hace cacti), y los logs en /var/log/munin.

Volvemos al pantallazo anterior. En la parte central tenemos acceso a las diferentes máquinas monitorizadas ordenadas por grupos (en nuestro caso sólo una) Mientras que en la barra de la izquierda, abajo, tenemos un menú organizado por categorías con acceso directo a las gráficas diarias, semanales, mensuales o anuales de cada una de ellas. De cualquiera de las formas accedemos a una colección de gráficas pero con una pequeña diferencia. Si accedemos a través del menú superior llegamos a una página donde se encuentran todas las gráficas almacenadas en dos versiones, diaria y semanal (semanas, en realidad, de ocho días :-) , muy bien pensado para detectar mejor las secuencias):

Munin - Gráficas del sistema diarias y semanal

Mientras que si pulsamos en el lateral sólo se nos muestra la lista de las gráficas de la categoría elegida y exclusivamente en la modalidad de vista elegida según la letra que pulsemos: diaria (d), semanal (w), mensual (m, 33 días aproximadamente) o anual (y, 13 meses):

Munin - Gráficas de postfix diarias

Pulsando sobre cualquier gráfica accedemos a la vista en mosaico de las cuatro vistas disponibles antes mencionadas y si de nuevo pulsamos sobre cualquiera de ellas llegamos a una vista ampliada de la misma con un panel de control desde el que podemos, analítica o gráficamente, hacer la ampliación o reducción de cualquier zona de la misma:

Munin - Gráfica de Load Average

NOTA: Lógicamente, los gráficos de una instalación recién concluida no presentan este aspecto. Tendrás que esperar al menos 24 horas para ello ;-)

Lo normal tras la instalación inicial es que, como nos ha pasado, no te instale los plugins correspondientes a apache y mysql debido a que falta algún prerequisito para ello. munin viene con un asistente llamado munin-node-configure que identifica cuales de los plugins que tienes en tu sistema están activos, cuales te podrían ser útiles… Incluso te asiste dándote el comando que necesitas para crear los enlaces necesarios al archivo y directorio adecuados. Échale un vistazo al enlace anterior de este párrafo para más detalles.

Para MySQL, en concreto, basta con que instaléis el siguiente paquete:

apt-get install libcache-cache-perl

Para apache2 necesitamos también instalar una librería extra de perl:

apt-get install libwww-perl

Además, debemos añadir la siguiente línea (o asegurarnos de que ya está) en el fichero /etc/apache2/mods-available/status.conf:

ExtendedStatus On

Y habilitar los módulos status e info de Apache:

a2enmod status info

Por último, reiniciamos el servidor web:

apache2ctl graceful

Creamos los enlaces a los plugins (fíjate en la forma diferente de hacerlo para mysql que se trata de un wildcard plugin) y reiniciamos el recolector de munin de esta máquina:

cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_accesses
ln -s /usr/share/munin/plugins/apache_processes
ln -s /usr/share/munin/plugins/apache_volume
ln -s /usr/share/munin/plugins/mysql_ mysql_bin_relay_log
ln -s /usr/share/munin/plugins/mysql_ mysql_commands
ln -s /usr/share/munin/plugins/mysql_ mysql_connections
ln -s /usr/share/munin/plugins/mysql_ mysql_files_tables
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_bpool_act
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_insert_buf
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_io_pend
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_log
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_rows
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_semaphores
ln -s /usr/share/munin/plugins/mysql_ mysql_innodb_tnx
ln -s /usr/share/munin/plugins/mysql_ mysql_myisam_indexes
ln -s /usr/share/munin/plugins/mysql_ mysql_network_traffic
ln -s /usr/share/munin/plugins/mysql_ mysql_qcache
service munin-node restart

Y con esto (tal vez tengas que esperar unos minutos para ver los resultados) ya tenemos dos categorías nuevas (apache y mysql2) con las gráficas correspondientes. Un par de ejemplos de cada una de ellas:

Munin - Gráfica de threads de Apache

Munin - Gráfica de operaciones de MySQL

Existen muchos otros plugins de monitorización que os pueden ser útiles (asterisk, bind9, memcached, varnish…). En algunos casos puede ser necesario instalar algún otro requisito o realizar algún cambio en la configuración como nos ha ocurrido con Apache y MySQL. Como siempre, lo mejor en el caso de que simplemente creando el enlace al plugin este no funcione es buscar información (que es lo que yo he hecho con estos dos, no creáis que hay muchas otras formas de resolver estas cosas ;-) ). También es sencillo eliminar cualquier gráfico que no nos interese en absoluto simplemente borrando el enlace del plugin correspondiente y reiniciando munin-node. Si tenemos duda acerca del plugin que genera la gráfica, el nombre del archivo aparece en la pantalla de los datos que nos permite realizar zooms de los datos. Añadir otros nodos para centralizar la monitorización de los mismos en esta máquina es bien fácil, pero ya lo dejamos para otro día ;-)

En definitiva, se trata de una herramienta mucho más potente que cacti que nos proporciona toda la información que podemos desear de una máquina y más sin apenas consumir recursos. Hecho en falta, tal vez, la facilidad de cacti para crear vistas personalizadas con ciertos gráficos que te interesa consultar de forma habitual. Y, por supuesto, no es tan cómoda como Cacti para monitorizar electrónica de red usando snmp. Pero bueno, no se puede tener todo ¿no?

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Tiny Tiny RSS: buscando un sustituto a Google Reader

Josemaría | 9 de mayo de 2013 | 9 comentarios

icono de RSS Me resisto a pensar que la anunciada desaparición de Google Reader puede significar en modo alguno que los feeds RSS están tocados de muerte. Google Reader es ahora un buen lector de feeds, pero no siempre ha sido así (¡hasta finales de 2007 ni siquiera integraba un buscador!) y sobrevivíamos. Por otro lado, sin los lectores de feeds estamos abocados a compartirlo todo y estar al tanto de los temas que nos interesan a través de las redes sociales o volviendo a las listas de correo… Y, sinceramente, no veo nada claro que (sobre todo los usuarios técnicos) nos resignemos a ello. Y no, por favor, no. Twitter tampoco sirve para estar al día de casi nada de forma seria.

Si estás conmigo y buscas un sustituto lo más parecido a Google Reader los “gurús”, “expertos” (y, si, también alguna persona maja y corriente ;-) ) ya han hecho listas y valoraciones y casi todos coinciden en que los mejores reemplazos son feedly o The Old Reader. No hay consenso claro por ninguno de ellos, así que seguramente cualquiera de ambos sea una buena elección. Una segunda opción sería cambiar a un lector de escritorio. De estos los hay a patadas pero ya imaginarás que no son la mejor opción cuando lees tus feeds a ratos desde diferentes ubicaciones. Más si además usas un dispositivo móvil. Puesto que la lectura por RSS es algo propio de usuarios medios y/o avanzados no creo que se trate de una buena opción…

Pero si dispones de un servidor web visible en internet y algo de tiempo para dedicarle, tienes una tercera posibilidad: montarte tu propio lector auto-hospedado y no volver a depender de nadie. En este caso, también parece haber dos opciones bastante claras: Tiny Tiny RSS y Selfoss. Yo me he decidido por el primero. Selfoss tiene un aspecto más moderno pero en el escaso tiempo que he dedicado a evaluarlos me ha parecido que Tiny Tiny es más ligero y potente.

ACTUALIZACIÓN: Ya terminando de escribir esto llego a otra opción minimalista y muy interesante si buscas un lector de feeds auto-hospedado: Stringer.

La instalación de Tiny Tiny RSS (tt-rss en adelante) es muy sencilla (como la de la gran mayoría de aplicaciones LAMP) pero no tanto como alguna de las más populares nos tienen acostumbrados

Pantalla principal de tt-rss

¿Buscas una aplicación adaptada a la pantalla de 4 pulgadas de tú móvil? Casi no te hace falta. tt-rss viene con un plugin que lo adapta perfectamente con sólo activarlo:

Plugin para Móvil de tt-rss

O una aplicación web que se instala por separado:

Plugin para Móvil de tt-rss

Si buscas una aplicación nativa para android, tienes esta del propio autor (con una versión gratuita de evaluación) que luce así:

Aplicación Android oficial para tt-rss

Existe, también, un fork gratuito de la anterior.

En cuanto a funcionalidades, tt-rss tiene todo lo que usabas con Google Reader y más gracias a sus funcionalidades base (perfiles de usuario, etiquetado, marcación y búsquedas, filtros…) y a una amplia colección de plugins, muchos de los cuales están soportados y vienen “de serie” con la aplicación. Otros puedes instalarlos de forma individual descargándotelos desde el foro o la wiki que mantiene el autor.

Pantalla de activación de plugins de tt-rss

Publicación de feeds a través de tt-rssY si buscas características sociales, aparte de los plugins que te permiten compartir entradas de forma directa en las principales redes sociales (Facebook, Google+, Twitter, Identi.ca…) tienes uno que te permite “linkar” instancias de diferentes usuarios para compartir recomendaciones o la posibilidad de obtener un feed público de cualquiera de las categorías que lees o, incluso, de una selección hecha de forma manual o mediante un filtrado automático.

Total que, a lo mejor, Google nos ha hecho un favor chapando su Reader. A mi, al menos, parece que así ha sido ;-)

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Apache Tunning (y II). Ajustando el parámetro MaxClients

Josemaría | 24 de febrero de 2013 | 3 comentarios

apache Como ya habíamos hablado por aquí, uno de los parámetros críticos en un servidor Apache es MaxClients, el número máximo de conexiones que es capaz de manejar simultaneamente. Es crítico porque cada tarea de Apache consume una determinada cantidad de memoria y si la suma de la memoria que consumen todos de forma simultanea es mayor que la memoria RAM que la máquina tiene libre comenzará a hacer swapping a disco y, si esta situación se mantiene, corremos un riesgo importante de que se nos quede virtualmente congelada. Una instalación de Apache por defecto toma un valor de 150 para este parámetro y esto es una verdadera burrada para casi cualquier servidor web con menos de 1 Gbytes (o incluso con bastante mas) que use contenidos dinámicos medianamente pesados.

Hace bien poco, buscando por ahí algún enlace para profundizar un poco más en estos temas, me encontré con este artículo de una empresa de hosting donde te proponen un script para ajustar el valor más adecuado a tus necesidades. Había dos cosas que no me gustaban en él script propuesto. Por un lado, tomaban el valor más conservador, es decir, el resultante de dividir la memoria libre entre lo que ocupa el proceso de Apache mayor. En segundo lugar, hacen el cálculo de la memoria libre sin tener en cuenta la que está ocupada por cache o buffers y que podría liberarse en caso de necesidad. Yo le he hecho algunos cambios para salvar ambos puntos y dejarlo un poco más bonito e informativo y me ha salido esto:

#!/bin/bash
clear

# Primero analizamos los procesos de apache funcionando actualmente
LISTA=`ps -aylC apache2 |grep apache2 |awk '{print $8'} |sort -n`

echo "Lista ordenada de la memoria, en bytes, ocupada por los procesos de Apache corriendo en este momento:"
COUNT=0
SUMA=0
for ITEM in $LISTA
do
        COUNT=`expr $COUNT + 1`
        SUMA=`expr $SUMA + $ITEM`
        echo "$COUNT -> $ITEM"
        if [ $COUNT -eq 1 ]
        then
                MENOR=$ITEM
        fi
done

MAYOR=$ITEM
MEDIA=`expr $SUMA / $COUNT`

# Pasamos las cantidades a Kbytes
MENOR=`expr $MENOR / 1024`
MAYOR=`expr $MAYOR / 1024`
MEDIA=`expr $MEDIA / 1024`

echo "El proceso de Apache más grande ocupa" $MAYOR "Kbytes y el menor" $MENOR "Kbytes"
echo "La media de la memoria ocupada por un proceso es de $MEDIA Kbytes"

echo "Detenemos Apache..."
apache2ctl graceful-stop > /dev/null

# Limpiamos los caches y buffers del servidor
sync
echo 3 > /proc/sys/vm/drop_caches

# Calculamos la memoria libre del sistema
FREEMEM=`free -m |head -n 2 |tail -n 1 |awk '{free=($4); print free}'`
echo "La memoria libre del servidor, después de liberar cache y buffers, es de $FREEMEM Kbytes"

echo "Arrancamos Apache de nuevo..."
apache2ctl start > /dev/null

echo "MaxClients debería de estar entre" `expr $FREEMEM / $MAYOR` "y" `expr $FREEMEM / $MENOR`
echo "Usando el valor medio de la memoria ocupada, un valor recomendable de MaxClients sería de" `expr $FREEMEM / $MEDIA`

El script de aquí arriba imprime una lista de la memoria ocupada por todos procesos de Apache activos en el momento de ejecutarlo. Luego toma el mayor, el menor y la media de todos ellos y calcula la memoria libre del sistema. Para ello, antes detiene Apache (con un graceful-stop para no fastidiar a nadie que esté viendo nuestra web en ese momento) y libera los buffers y caches de memoria. Por último, arranca de nuevo Apache y nos da como salida dos valores: una horquilla entre el valor que debería de tomar MaxClient usando el menor y el mayor valor de los procesos tomados en la instantánea anterior y un valor recomendado que sale de usar el valor medio de todos ellos.

Evidentemente no se trata de algo matemático. Como es lógico, ejecutado en diferentes momentos obtendremos valores distintos ya que ni la RAM que usa nuestro servidor es inmutable ni el tamaño de los procesos de Apache es siempre el mismo ni siguen la misma distribución. Pero para darnos una primera idea del valor con el que tenemos que empezar a jugar creo que es bastante válido. Ya me contáis.

NOTA: En algunas instantáneas el valor de memoria ocupado por el proceso más pequeño de Apache puede ser cero, seguramente porque o está creándose o está destruyéndose en ese momento. En ese caso el valor de la horquilla pierde uno de sus extremos. Sería muy fácil modificar el script para que en ese caso tome el segundo valor y divida por un elemento menos, pero ocurre en tan pocas ocasiones que no creo que merezca la pena hacerlo. Al menos no hoy ;-)


Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Instalación y configuración básica de Cacti en Debian para monitorizar un host

Josemaría | 13 de enero de 2013 | 13 comentarios

herramientas La instalación más sencilla (y, me atrevería a decir, más frecuente que he tenido que realizar) que suele hacerse con Cacti es aquella que se se usa para monitorizar los recursos de un único host (típicamente un servidor dedicado o VPS en una empresa de hosting) en el que el propio Cacti se encuentra instalado de forma local.

Cacti necesita para funcionar un servidor web (apache2, por ejemplo) con php, una base de datos de mysql-server, las rrdtools y snmp (cliente y agente). Seguramente tendremos ya instalados apache2 y mysql-server y, si no, añade los paquetes apache2, php5 y mysql-server al comando siguiente:

sudo apt-get install cacti snmp snmpd rrdtool

Durante la instalación se nos pedirá si queremos configurar de forma automática la base de datos que necesita cacti (en caso afirmativo, se nos pedirá la contraseña de root de mysql-server para crear dicha base de datos y un usuario de acceso a la misma) y el servidor web que usaremos (apache2 en nuestro caso).

Una vez concluida la instalación podremos acceder a Cacti con la URL http://ip_o_nombre_del_servidor/cacti. En el primer acceso se ejecutará un asistente en el que se nos pedirá aceptar la licencia de uso, decidiremos el tipo de instalación (nueva o actualización de una versión anterior) y se realizará un chequeo de dependencias:
chequeo inicial de dependencias durante la instalación de Cacti

Una vez cumplimentado esto se nos redirecciona a la ventana de login. El usuario inicial es admin y su password la misma. Inmediatamente después de realizar el primer login se nos forzará a cambiar esta password, así que tenla pensada de antemano ;-)
Login inicial en Cacti. Usuario admin y password admin

Cacti está ya funcionando y recogiendo datos de forma automática del servidor en el que se encuentra instalado. Si lo dejamos unos minutos para que le de tiempo a recoger algunos y pulsamos sobre la solapa de gráficos (arriba a la izquierda) veremos que ya tenemos gráficas (no tan completas como estas que llevan ya más de 24 horas, claro) de carga de la CPU, ocupación de memoria, número de procesos y número de usuarios conectados.
Solapa de entrada a los gráficos de Cacti
Gráficos iniciados de forma automática para localhost en cacti

Para monitorizar el tráfico de red es preciso “tirar” de snmp. Lo primero que tenemos que hacer es configurar el daemon de snmp para que Cacti pueda leer de él. Para ello editamos el fichero /etc/snmp/snmpd.conf y quitamos el comentario que deshabilita la siguiente línea:

rocommunity public localhost

Reiniciamos el servicio (sudo service snmpd restart) y volvemos a Cacti para configurar la nueva gráfica. Para ello entramos en la opción Devices del menú de la izquierda, pulsamos sobre la entrada de localhost (la única que tendremos) y, en la ficha resultante, editamos el campo destacado en la imagen de aquí abajo (el correspondiente a la versión de SNMP que aparecerá como Not in Use) y luego pulsamos el botón de Save. Si todo ha salido bien y Cacti es capaz de contactar con el demonio SNMP de nuestro equipo, arriba a la izquierda aparecerán las líneas de información que también puedes ver resaltadas en este gráfico:
Añadiendo SNMP al dispositivo localhost en Cacti

En la parte inferior de esta misma ficha de datos, en el bloque de “Associated Data Queries” debería de aparecer ahora una línea etiquetada como “SNMP – Interface Statistics” (a la derecha de “Add Data Query”). La seleccionamos, pulsamos el botón de Add y, a continuación, el de Save.
Añadiendo gráficos de SNMP en Cacti

Bien, ahora volvemos a la parte superior de la página y pulsamos en el enlace de “Create Graphs for this Host”. En la página que nos aparece marcamos los interfaces de red cuyo tráfico queremos monitorizar y, ya que estamos, las unidades de disco cuya ocupación queremos controlar (eth0 y sda1, respectivamente, en el ejemplo aquí abajo). Bajo las líneas correspondientes a los interfaces de red tenemos, como puedes ver, un selector que nos permite elegir entre diferentes tipos de gráficos. A mi particularmente la que aparece por defecto (In/Out bits) es la que me parece más cómoda pero, ya sabéis, para gustos… ;-)
Añadiendo gráficos de SNMP en Cacti

Pulsamos Create y listo. Los datos se empezarán a tomar inmediatamente y, a los pocos minutos, si volvemos a entrar en la solapa de Gráficos tendremos ya las primeras muestras disponibles. Después de 24 horas tus nuevas gráficas de tráfico de red y de ocupación de disco lucirán como estas:
Gráfica de tráfico de red en Cacti
Gráfica de ocupación de disco en Cacti

El siguiente gráfico que añadiremos será el de activida de lectura y escritura en discos, muy interesante sobre todo para monitorizar la actividad de nuestro disco de swap y detectar si la máquina está corta de memoria. También es el que más “trabajo” nos va a dar para ponerlo en marcha, así que atención.

Lo primero que necesitas es descargarte y descomprimir este fichero (extraído de este hilo del foro de Cacti que es de donde he sacado las instrucciones que te voy a contar) donde encontraras dos archivos con extensión XML. El que se llama net-snmp_devio.xml tienes que copiarlo al directorio /usr/share/cacti/site/resource/snmp_queries/ de la máquina. El otro, llamado cacti_data_query_ucdnet_device_io.xml, tienes que importarlo desde la opción “Import Template” que aparece en el menú de la izquierda.
Importando plantilla para IO de disco en Cacti

Si el resultado es correcto veremos algo como esto:
Importando plantilla para IO de disco en Cacti

Ahora volvemos a la opción de Devices, volvemos a seleccionar localhost y en la parte inferior, en el mismo bloque de “Associated Data Queries”. ahora nos aparecerá una nueva línea etiquetada como “ucd/net – Device I/O” que debemos de seleccionar y, luego, pulsar el botón de Add y salvar los cambios.
Añadiendo una gráfica de tráfico de disco en Cacti

Volvemos a pulsar ahora en el enlace de “Create Graphs for this Host” y en el nuevo bloque que nos aparece seleccionamos las líneas correspondientes a los discos cuya actividad queremos seguir. En el ejemplo de aquí abajo se han seleccionado sda1 (la partición donde reside el sistema) y sdb (el disco de swap).
Añadiendo una gráfica de tráfico de disco en Cacti

Cambiamos al pie del bloque el tipo de gráfico si así lo deseamos y pulsamos el botón de Create. Listo:
Gráfica de tráfico de disco en Cacti

Y para terminar, un pantallazo con todos los gráficos de monitorización que tenemos ahora en nuestro servidor tras configurar sus dimensiones para que puedan verse cómodamente con un sólo vistazo (pulsa sobre él para verlo ampliado):
Mosaico de gráficas de monitorización de un host con Cacti

Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XXXVI) – Rotar vídeos con mencoder

Josemaría | 26 de diciembre de 2012 | Comentar

chuleta Y otra receta simplota de comandos útiles para hacer modificaciones sencillas a un vídeo. Cuando queremos rotar un vídeo (ya sabéis, aquello de que habéis cogido la cámara en vertical y ahora cada vez que queréis ver al niño hacer sus monerías cogéis tortícolis) podemos usar mencoder. El comando base es el siguiente:

mencoder -vf rotate=1 -oac copy -ovc lavc original.avi -o resultado.avi

El tipo de rotación se selecciona con el argumento -vf rotate=1. El anterior gira el vídeo 90 grados en el sentido de las agujas del reloj, mientras que si lo sustituimos por -vf rotate=2 lo hará en sentido antihorario. Mediante el argumento -oac copy definimos como se trasladará el audio del vídeo y con -ovc lavc especificamos el tipo de codec que usaremos en el vídeo final. Podemos ver las opciones disponibles que tenemos en nuestro sistema mediante el siguiente comando:

mencoder -oac help -ovc help

El argumento -vf, que es el que nos permite realizar transformaciones sobre el vídeo, tiene muchas otras opciones disponibles que también podemos consultar ejecutando:

mencoder -vf help

La opción copy siempre está disponible pero no funcionará con el argumento -ovc (¡si copiamos el original no rotamos!) y algunas de las opciones disponibles puede que nos obliguen a especificar parámetros adicionales (bitrate, fixed_quant, pass, etc.).

Por último, original.avi es el nombre del vídeo a rotar y con el argumento -o resultado.avi definimos como se llamará el vídeo resultante.

ACTUALIZACIÓN: Otras dos transformaciones interesantes en esta misma línea que podemos aplicar mediante el argumento -vf son mirror y flip. Si queremos girar el vídeo 180 grados podemos aplicarlas ambas de modo conjunto (-vf mirror,flip).
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes

Chuletillas (y XXXV) – Instalar xampp en Chakra Linux

Josemaría | 9 de noviembre de 2012 | 2 comentarios

chuleta Si queremos instalar xampp en Chakra Linux nos encontramos con que esta distribución sólo está disponible ya para 64 bits mientras que xampp se distribuye en forma de script sólo para sistemas de 32 bits. La solución pasa, sencillamente, por instalar unas librerías de compatibilidad y listo. Manos a la obra, pues. En un primer paso sustituimos las gcc-libs por las gcc-libs-multilib:

sudo pacman -S gcc-libs-multilib

Luego, tenemos dos opciones, descargar e instalar xampp siguiendo sus instrucciones como haríamos normalmente o usar el paquete ccr disponible (aunque ligeramente desactualizado):

ccr -S xampp

En cualquiera de ambos casos, xampp se instalará en el directorio acostumbrado (/opt/lampp) y responderá a los comandos y opciones habituales.

NOTA: Siempre que he realizado operaciones de este tipo y he instalado versiones de librerías de 32 bits en distribuciones de 64 (concretamente en Ubuntu y Fedora) luego, en algún momento, he tenido problemas de dependencias no resueltas a la hora de realizar alguna instalación y/o actualización. Aunque de momento no he tenido ningún problema similar con Chakra no llevo suficiente tiempo con esta distribucion como para asegurar que esto esté mejor resuelto.
ACTUALIZACIÓN: Olvidaos de esto: xampp ya está disponible en versión de 64 bits.
Compártelo:
    emailPDFPrintBitacoras.comIdenti.caTwitterdel.icio.usDiigoFacebookMeneameBarraPuntoNetvibes