Tareas programadas con Cron

Al poco tiempo de empezar a tratar con un servidor Linux te das cuenta de que tarde o temprano vas a utilizar una tarea programada. Puede ser que necesites realizar una copia de seguridad cada X tiempo, vaciar una cola de correos, o simplemente controlar que todo está en su sitio.

Sabía desde hace tiempo que algún día hablaría con Don Cron. Llevábamos una temporada mirándonos a la cara, con tono desafiante. Aún conociéndole de oídas, me ha impresionado la potencia y las opciones disponibles de este demonio.

Quién es Cron, y donde lo puedo encontrar

Cron se encarga de ejecutar las tareas programadas que se configuren en el sistema. Probablemente, y aunque depende de tu distribución Linux, en /etc encuentres varios directorios llamados cron.hourly, cron.daily, cron.weekly, cron.monthly. En estos directorios se encuentran los scripts que se ejecutan cada hora, cada día, cada semana, etc...

Uso básico de Cron

Si dejáramos un script en cualquiera de estos directorios se ejecutaría en el momento que proceda. Por ejemplo, si creamos un script que realice una copia de seguridad de nuestros archivos y lo colocamos en cron.daily, este script se ejecutará una vez al día.

Uso avanzado de Cron

Tal vez el uso de los directorios cron.* no satisface nuestras necesidades de configuración para la tarea que queremos programar. En este caso programaremos las tareas a través del archivo crontab.

Esta es, dadas las posibilidades que ofrece, la forma más interesante de utilizar Cron. El archivo en cuestión se encuentra en el directorio /etc, y tiene un formato parecido a este:

SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1

Pasemos a explicar cada una de las partes de este archivo. En primer lugar las primeras cuatro líneas, que contienen variables para Cron.

SHELL, la cual nos indica el shell con el que se ejecutarán las órdenes de Cron. En caso de no asignar valor o de no existir la variable, se tomará el shell del usuario que ejecuta Cron.

PATH, contiene o indica la ruta a los directorios en los cuales cron buscará el comando a ejecutar. Este path es distinto al path global del sistema o del usuario.

MAIL TO es a quien se le envía la salida del comando (si es que este tiene alguna salida). Cron enviará un correo a quien se especifique en este variable, es decir, debe ser un usuario válido del sistema o de algún otro sistema. Si no se especifica, entonces cron enviará el correo al usuario propietario del comando que se ejecuta.

HOME es el directorio raíz o principal del comando cron, si no se indica entonces, la raíz será la que se indique en el archivo /etc/passwd correspondiente al usuario que ejecuta cron.

Tras las líneas con las variables entramos en materia, y empezamos a econtrarnos con líneas de ejecución de tareas. cada una de estas líneas tiene un formato parecido a este:

minutos | horas | día-mes | mes | día-semana | usuario | script

40 * * * * root /etc/scripts/tareaProgramada1.sh

En la primera parte de la linea tenemos la definición del momento en que se ejecutará la tarea.En caso de tener un * en alguno de los campos, significará que se ejecutará la tarea para cada uno de los valores posibles. De esta forma en el ejemplo el script se ejecutará en el minuto 40 de cada hora, cada día de cada semana de cada mes.

El siguiente campo de la línea especifica el usuario que ejecutará el script, y después tenemos la ruta donde tenemos el script que queremos ejecutar. Tendremos que tener en cuenta que el script tiene asignado el permiso de ejecución, y que el usuario que lo tiene que ejecutar tiene permisos sobre el archivo.

Configuración del tiempo de ejecución

Una de las ventajas de Cron es la posibilidad de configurar el momento exacto en que se ejecutará una tarea. Las posibilidades son prácticamente infinitas, por lo que vamos a ver unos ejemplos que nos harán tenerlo más claro.

- Aparte de ejecutar una tarea en un momento concreto, también podemos ejecutarla cada X tiempo. Para esto podemos utilizar la /. Veamos un ejemplo.

15 */2 2/3 * * root /etc/scripts/tareaProgramada1.sh

En este ejemplo el script se ejecutará en el minuto 15 de cada 2 horas, cada 3 días a partir del día 2 de cada mes. La primera ejecución será el próximo día 2 a las 0:15. Hay que tener en cuenta que si no especificamos el incio para el periodo de repetición Cron tendrá en cuenta el primer valor válido. Con */2 se tomará como inicio la hora cero. Con 2/3 se contará de tres en tres, a partir del 2.

- En el caso de que lo necesitemos, también podemos especificar los valores concretos en que queremos configurar la ejecución de la tarea. Utilizando la , podemos dar varios valores a un campo del tiempo de ejecución.

15 7,14 * * * root /etc/scripts/tareaProgramada1.sh

La tarea se ejecutará a las 7:15 y las 14:15 de cada día.

- Podemos también configurar el día de la semana en que se ejecutará la tarea. Nos valdría si lo que queremos es lanzar un proceso muy largo y necesitamos que no haya nadie, por ejemplo el fin de semana. Para el día de la semana podemos utilizar números (del 0 al 7), o con las tres primeras letras del día en inglés. Si se usan numeros hay que tener en cuenta que tanto el 0 como el 7 es el domingo.

15 7 * * sun root /etc/scripts/tareaProgramada1.sh
15 7 * * 7 root /etc/scripts/tareaProgramada1.sh
15 7 * * 0 root /etc/scripts/tareaProgramada1.sh

Con estas tres lineas ejecutaremos la tarea a las 7:15 del domingo.

- Otra opción interesante es configurar un rango de valores para los que se ejecutará la tarea. Utilizaremos el - entre dos valores para especificar un rango. Vamos con un ejemplo.

15 7-14 * * 7 root /etc/scripts/tareaProgramada1.sh

En el ejemplo ejecutaremos la tarea los domingos, en el minuto 15 de 7 a 14 horas. La primera ejecución será a las 7:15 y la última a las 14:15.

- Ahora, si combinamos las diferentes formar de configurar una tarea, podemos ver casos como este:

*/15 8-18/2 10 5 sat root /etc/scripts/tareaProgramada1.sh

La tarea se ejecutará cada 15 minutos, entre las 8 de la mañana y las 6 de la tarde cada dos horas, el día 10 de mayo, siempre que ese día sea sábado.

Este ejemplo sirve para entender que las tareas se ejecutarán sólo si se cumple cada una de las condiciones especificadas. Es posible que tarde años en llegar un sábado 10 de mayo (el último fue en 2008), por lo que hay que tener bastante claro que las condiciones que configuremos tengan algo de sentido.

Ahora ya sabemos programar tareas en nuestro Linux, y lo mejor de todo es que esto es sólo una parte de las cosas que puede hacer Cron. Seguro que volvemos a vernos.

Acceso SSH a ESXi

Después de unos meses tratando con máquinas virtuales y demás, llegó la hora de actuar.

En su día comenté que la mayor parte del trabajo se centraría en Xen, pero los problemas que han aparecido son acerca de una máquina virtual de VMWare. La cuestión es que de un día para otro la máquina ha dejado de funcionar, y ahora nos toca, almenos, averiguar lo que ha pasado.

Probablemente en la mayoría de los casos con la consola del ESXi tengamos suficiente, pero cuando las cosas se ponen feas una de nuestras mejores opciones será la de habilitar el acceso al ESXi a través de SSH para poder ver "desde dentro" lo que está pasando. Es tan fácil como:

Desde la consola de ESXi

1. Pulsar ALT + F1 para acceder al shell. Se muestra una pantalla negra.
   
2. escribir unsupported.
3. escribir la contraseña del usuario root del ESXi.
4. En el directorio /etc se encuentra el archivo de configuración del servicio inetd, inetd.conf. Lo editamos.
5. Descomentamos las lineas del archivo que hacen referencia al servicio SSH.
6. Rearrancamos inetd. Podemos
   

A partir de este momento podremos acceder al ESXi directamente a través de SSH y trabajar sobre él.

Me ha parecido interesante también la opción de realizar tareas a través del navegador, accediendo a la dirección IP del ESXi, pero esa es otra historia que contaremos en otro momento.

Partir una memoria usb flash

Como no paro de tener problemas con los discos duros (gracias windows, gracias subidas de tensión) he tenido que utilizar mucho más de lo que me gustaría ese gran programa llamado HDD Regenerator.

La utilidad de esta aplicación está fuera de toda duda, me ha ayudado a seguir utilizando discos que habían empezado a dar errores serios, pero este no es el tema. La cuestión es que las últimas veces que he utilizado esta aplicación ha sido desde Windows, recuperando el segundo disco del sistema.

Ésta última vez me tocó utilizarlo en el disco principal, por lo que no era posible ejecutar desde Windows, al estar cargado el SO en ese mismo disco y la aplicación necesitar acceso total al mismo. Ante este panorama me tocó decidir si grabar un CD y arrancar desde él o utilizar mi querido pendrive (8GB) para ello.

HDD Regenerator tiene la opción de crear un disco USB de arranque, por lo que es algo automático y muy fácil. Tan sólo tuve que mover los archivos que tenía en la memoria para recuperarlos después. El problema vino cuando en vez de 8GB el pendrive sólo tenía una capacidad de 1,92GB. ¿Qué ha pasado?



Al parecer HDDRegenerator sólo necesitaba 1,92GB de espacio, por lo que creó una partición con ese tamaño, dejando sin asignar el resto de la capacidad de la memoria. A pesar de no fiarme del particionador de Windows, traté de eliminar la partición y crear una nueva con el máximo espacio disponible. No pudo ser, claro.

En este momento es cuando me acordé de una aplicación que ya había utilizado antes para trabajar sobre memorias flash. Se llama SwissKnife, y a pesar de ser freeware vale su peso en oro.

Recuperar el estado inicial de la memoria es tan fácil como hacer un formateo completo (full) del mismo, con con que tendremos una sola partición con el total del tamaño disponible.





SwissKnife ofrece más características, por lo que me parece un software muy recomendable si tenemos una memoria USB de un tamaño considerable. En la página de descarga se puede obtener más información acerca de esta aplicación. A mi, de momento, me ha salvado de darme de cabezazos, o de reiniciar para arrancar en Linux, que ya es bastante.

Virtualicemos el mundo

Hace tiempo que no escribo en el blog, y la verdad es que si lo hago es porque se trata de un tema más que interesante: la virtualización.

El caso es que hace no mucho he empezado a pelearme y experimentar con Xen, tras un fugaz paso por VMware. El resultado no puede ser más satisfactorio, aunque como es normal, al ser novato, se me escapan miles de cosas que se aprenden poco a poco.

Espero que poco a poco tenga la posibilidad de escribir en el blog las cosas que vaya aprendiendo. De momento parece que Xen y yo vamos a ser amigos...

Bluetooth y Linux se llama BlueProximity

Antes de empezar nos aseguraremos de que tenemos el material necesario, que no es más que un dispositivo Bluetooth (por ejemplo uno USB), un teléfono móvil, y nuestra distribución Linux preferida, en este caso Ubuntu 9.04.

El primer paso será comprobar que nuestro adaptador Bluetooth funciona correctamente, tan fácil como conectarlo y ver que en la barra de tareas de nuestro Ubuntu aparece el logo del Bluetooth.

Instalación

Como es la primera vez que oimos hablar de BlueProximity, lo más probable es que no tengamos instalados ni la aplicación ni los paquetes que se necesitan para que funcione. Para instalar abriremos el gestor de Paquetes Synaptic que nos facilitará el trabajo, de paso que resolverá las dependencias con otros paquetes que se necesiten.

Tan sólo buscando por blueproximity nos aparecerá la aplicación a instalar y el sistema se encargará de instalar también todo lo necesario para que funcione al 100%.

Configuración

Después de instalar ejecutaremos BlueProximity, lo que nos mostrará otro icono de Bluetooth en la barra de tareas, pero este con una llave, que en principio será de color rojo.

Abrimos la aplicación y nos encontramos con una ventana como ésta.



Para emparejar el adaptador USB con nuestro móvil exploraremos en busca de dispositivos con el Bluetooth conectado y seleccionaremos el que se corresponda con el nuestro.



Ahora que tenemos seleccionado el móvil con el que queremos relacionar nuestro equipo, lo seleccionamos y pulsamos Usar el dispositivo seleccionado.

Si en el móvil no notamos ningún tipo de reacción, podemos buscar canales en el dispositivo, lo que irá por cada uno de los puertos del móvil para encontrar un canal disponible. En este paso seleccionaremos un canal y tendremos que configurar una clave de paso para emparejar los dispositivos. Ahora si, nuestro móvil nos preguntará por esa clave, y al confirmarla ya podremos utilizar BlueProximity con normalidad.

Ahora tenemos que configurar las distancias, tanto para el bloqueo como para el desbloqueo. Esto se llama así por la finalidad inical de BlueProximity que os contaba antes, que era la de bloquear/desbloquear el PC. Como es normal, podemos decidir estos parámetros, aquí tenemos la pantalla para hacerlo:



Todavía más importante que las distancias en las que reaccionará nuestro HTPC a la presencia de nuestro móvil, es que hará cuando lo detecte o deje de detectar. Podremos configurar un comando que queramos para cada una de las acciones.



Para hacer una prueba rápida podemos escribir firefox www.todohtpc.com en el comando de desbloqueo, y ver como se abre un navegador con nuestra página preferida al acercarnos al adaptador Bluetooth. Ya tenemos BlueProximity funcionando al 100% !!

Descomprimir video por hardware en Linux: VDPAU

Una de las finalidades de nuestro HTPC Linux será la de poder ver videos en alta definición. Hace tiempo que oimos que las tarjetas gráficas pueden descomprimir el video liberando al procesador de tanta carga. Si tenemos un procesador lo suficientemente potente como para hacer el trabajo él sólo, tal vez no nos hayamos parado a pensar en utilizar esta característica de la tarjeta gráfica. Si lo que tenemos es un equipo con una gráfica capaz de descomprimir el vídeo y un procesador no tan potente, el hecho de utilizar la descompresión por hardware puede ser la diferencia entre poder y no poder ver una película en alta definición. Sea cual sea el caso, vamos a ver como se hace.

Lo primero que tenemos que saber es que tenemos entre manos, y se trata de VDPAU (Video Decode and Presentation API for Unix), un API desarrollada por Nvidia para decodificar el video en las tarjetas de la marca. En este enlace se pueden ver las características de VDPAU y las tarjetas gráficas y aplicaciones compatibles.

Entorno de pruebas

Para hacer las pruebas hemos utilizado una instalación básica de Ubuntu 9.04 en un equipo con un procesador de doble núcleo 5200+ de AMD, 2GB de RAM y una tarjeta gráfica 8600GT de Nvidia. La película elegida es Transformers en una resolución 1080p en formato H.264 (.mkv).

Instalación

Como vamos a trabajar sobre una versión recien instalada de Ubuntu en principio no estaremos utilizando los drivers de la tarjeta gráfica, ya que no son software libre, por lo que tendremos que autorizar al sitema a ello. En la sección de Administración podemos activar los controladores. Tendremos que reiniciar para que se apliquen los cambios. Tras el reinicio podremos ver en Administración como han cambiado los drivers de video y son ahora de Nvidia. Probablemente tengamos disponible también el panel de control de Nvidia.

Ahora pasamos a instalar el API de VDPAU, dirigiéndonos al gestor de paquetes (Administración/Gestor de paquetes Synaptic) y buscando en el campo de texto por VDPAU. Obtendremos resultados del estilo nvidia-180-libvdpau-dev. Instalamos el paquete y pasamos a la instalación de un reproductor compatible con VDPAU: Mplayer.

Para instalar Mplayer de forma más sencilla abriremos una consola e iremos ejecutando los siguientes comandos de uno en uno. Cada uno de ellos puede tardar algo de tiempo en terminar, por lo que tendremos que tener algo de paciencia. El último de los comandos tendremos que ejecutarlo como root, por lo que nos pedirá la contraseña de superusuario del sistema.

$sudo apt-get install build-essential subversion
$sudo apt-get build-dep mplayer
$svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer
$ cd $HOME/mplayer
$ ./configure
$ make
$ sudo make install

En el momento en que tengamos instalado Mplayer ya podremos utilizar VDPAU en la visualización a través del reproductor. Calculamos que todo el proceso de instalación puede tardar entre 20-30 minutos, por lo que además de fácil es bastante rápido empezar a ver videos en alta definición en nuestro Linux. Pero ¿Habrá valido la pena tanto esfuerzo? Vamos a ver los resultados.

Pruebas realizadas

Las dos primera imágenes muestran la llamada a Mplayer sin utilizar VDPAU en dos escenas diferentes de la película. Podemos observar en el rendimiento del procesador que siempre almenos uno de los dos núcleos sobrepasa el 50% en el mejor de los casos. Vemos ahora las ventajas que nos ofrece VDPAU.





En estas dos capturas de las mismas escenas que las anteriores, podemos ver que el rendimiento necesario para reproducir el archivo es muy inferior. Salvo algunos picos en la carga, ambos núcleos del procesador se mantienen siempre por debajo del 50%, incluso llegando a quedarse en algún momento en el 0% uno de ellos.





Las ventajas son muy importantes utilizando VDPAU, por lo que es muy recomendable si disponemos de una gráfica compatible.

Xbmc y VDPAU

Como nuestro equipo es un HTPC, no podemos pasar por alto que los archivos de video no se ejecutarán directamente a través del reproductor, sino de un mediacenter. Dado que Xbmc es compatible con VDPAU, vamos a ver como configurarlo para que haga uso del API y la mejora en el rendimiento también a través de este famoso mediacenter.

Para utilizar VDPAU tan sólo tenemos que dirigirnos a la sección de ajustes de reproductor de Xbmc (Settings/Video/Player) y seleccionar Render method como VDPAU. Así de fácil.



Las mejoras siguen siendo notables reproduciendo desde Xbmc.

Sin VDPAU:



Con VDPAU:



Conclusión

Para terminar decir simplemente que, teniendo en cuenta lo que ganamos y que no hace falta entrar en configuraciones complejas para obtener resultados... ¿Que haces que no aceleras el video por hardware?.

Lirc y el control a distancia

Esta entrada tiene algo de especial por varias razones, una es que hacía algún tiempo que no escribía en el blog, y la otra es que (por fin!) me he puesto en serio con la configuración del mando a distancia en mi Linux. Culpa de esto la tiene DuKKon, ya que en su blog leí un post sobre Moovida en la que se hacía referencia a la configuración del mando, lo que me animó a retomar esta deuda pendiente que tenía.

Primero explicaremos cómo funciona el mapeo de teclas para el mando, suponiendo que tenemos a nuestra disposición un mando compatible y que el sistema haya reconocido. Sinceramente no creo que haya problemas con esto, ya que para las pruebas tengo el mando de la Avermedia Studio 203 que configuramos allá por febrero para ver la tele en Linux.

Las aplicaciones en las que nos basaremos para utilizar el mando serán, básicamente, irexec e irxevent. La primera de ellas ejecutará comandos asociados a botones en el mando, y la seguna ejecutará eventos, como por ejemplo cualquiera de las teclas o combinaciones de teclas del teclado.

Para este ejemplo hemos utilizado Ubuntu 9.04 con un mando y receptor que el sistema ya había detectado, concretamente la Avermedia AverTv Studio que utilizamos para ver la tele en Linux.

Utilizaremos Lirc (Linux Infrared Remote Control) el cual podemos instalar desde el gestor de paquetes, o visitanto el sitio web Oficial www.lirc.org.

Para ver las señales que nuestro mando está enviando al sistema podemos utilizar el comando irw, que nos mostrará en la consola las teclas que vayamos pulsando.

Código:

juanma@juanma:~$irw 193 0 KEY_CHANNELDOWN event6 174 0 KEY_ZOOM event6 192 0 KEY_CHANNELUP event6 73 0 KEY_VOLUMEUP event6 72 0 KEY_VOLUMEDOWN event6

Ahora que sabemos que el mando envía señales a nuestro sistema, trataremos que el sistema responda a estas señales de la forma que nosotros queramos, para ello editaremos el archivo .lircrc que se encuentra oculto en nuestro directorio home. Si el archivo no existe, lo crearemos con nuestro editor de textos favorito.

Lirc buscará en este archivo los comandos a realizar para cada tecla que tengamos mapeada del mando. Para convertir las pulsaciones del mando en comandos o en órdenes para nuestro HTPC podemos hacerlo de dos formas diferentes y compatibles, a través de irexec o de irxevent.

Irexec ejecutará el comando que configuremos como si lo hicieramos desde la consola, por el contrario irxevent ejecutará una acción concreto, como por ejemplo pulsaciones en el teclado, que nos serán muy útiles para configurar el comportamiento de nuestro mando en cada programa que vayamos a utilizar. Ambos buscarán en el archivo .lircrc de nuestro directorio home las acciones para cada tecla.

El ejemplo que presentamos está configurado para arrancar y manejar XBMC con el mando, tal vez necesiteis configurar otro programa, pero creo este caso servirá para ver cómo funciona. Y a partir de ahí ajustar la configuración a las necesidades de cada uno.

Para arrancar XBMC con el mando en cualquier momento, utiizaremos una orden para irexec.

Código:

begin prog = irexec button = KEY_POWER config = exec xbmc --fullscreen end

Como veis el formato del archivo no tiene mucho secreto, sólo tendremos que saber el botón al que queremos relacionar la acción (utilizando irw de nuevo) y el comando a ejecutar. Tendremos en cuenta que cada vez que pulsemos esta tecla estaremos ejecutando el comando, incluso cuando estemos utilizando XBMC, por lo que dejaremos esta tecla sólo para arrancar el programa.

Ahora vamos con un ejemplo para emular las teclas con las que navegaremos por XBMC.

Código:

begin prog = irxevent button = KEY_CHANNELUP config = Key Up CurrentWindow end begin prog = irxevent button = KEY_CHANNELDOWN config = Key Down CurrentWindow end

De esta forma cuando pulsemos las teclas de canal arriba/canal abajo estaremos mandando las teclas de arriba/abajo del teclado, para el programa que estemos utilizando en ese momento. Tendremos en cuenta que estamos mandando estas pulsaciones a irxevent, por lo que esta configuración nos valdrá para otros programas, no sólo para XBMC. Además podemos programar acciones diferentes cuando la pulsación de la tecla se repite, muy útil si queremos que se ejecute una acción diferente cuando detectamos una pulsación larga. Además las pulsaciones pueden enviar acciones diferentes dependiendo del programa que estemos ejecutando.

Para completar la configuración podremos definir las teclas para seleccionar un punto de menú, ir atrás, izquierda, derecha, etc... Podemos ver las teclas que podemos mandar a irxevent en irxevents.keys. Incluso podemos mandar combinaciones de teclas.

Si vamos a configurar más de un programa con irxevent podemos crear un directorio .lirc en nuestro /home donde guardar el archivo de configuración de cada programa e incluir los archivos en .lircrc de esta forma:

Código:

include /home/juanma/.lirc/xmbc

Conclusión

Como pasa siempre en Linux, las opciones de configuración son casi infinitas, por lo que la calidad de nuestra configuración dependerá de cuanto afinemos las acciones del mando. Pero tenemos la posibilidad de controlar al completo nuestro sistema desde el mando a distancia, así como cualquier programa que vayamos a utilizar.