Es muy típico que un script que funciona perfectamente desde una sesión de usuario normal falle al correr como un trabajo ejecutado por el cron.
Generalmente esto es debido a que las variables de entorno bajo las que se ejecuta el script en uno y otro caso no son las mismas.
En el caso de lanzar OpenVPN como demonio desde una tarea de cron es importante tener esto en cuenta, ya que OpenVPN tras la autenticación llamará al comando ifconfig para crear el dispositivo de red virtual. Llegado este momento, si /sbin no forma parte de la variable de entorno PATH, nuestro script fallará.
Invocar a /etc/init.d/openvpn start | stop para establecer y parar la conexión requiere utilizar los ficheros de configuración ubicados en /etc/openvpn y jugar con /etc/default/openvpn para que el script de inicialización haga lo que queremos. Así, una opción más fácil puede ser llamar a openvpn con un script similar a este, evitando parar accidentalmente sesiones de vpn no deseadas.

#!/bin/bash
PATH='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
/usr/sbin/openvpn --daemon --writepid /var/run/myvpn --cd /root/vpn --config /root/vpn/client.conf
/bin/sleep 16
... (lo que sea que hagamos por la VPN... acceso seguro a svn por ejemplo)...
/bin/kill $(cat /var/run/myvpn) && rm /var/run/mypid

Con PATH aseguramos que OpenVPN, al correr como hijo del cron encuentra el comando ifconfig.

• Con --daemon, OpenVPN corre como demonio. De lo contrario, el script nunca pasaria de esta línea.
• Con --writepid /var/run/myvpn escribimos el PID del proceso OpenVPN en el fichero /var/run/myvpn. Esto nos permite matar sólo esa sessión de vpn con killall más adelante.
• Sleep es sólo para asegurar que el dispositovo TAP y las rutas existan antes de utilizarlas.
• Finalmente matamos sólo la conexión vpn establecida por este script.

Por otro lado, si además de los certificados y claves necesitamos de una autenticación mediante user y password, deberemos especificar el fichero que los contiene tras la opción auth-user-pass /root/vpn/up. Esta opción suele estar en en fichero client.conf y es la responsable de que se te pregunte que introduzcas un usuairo y password en aquellas conexiónes que asi lo requieren. De hecho, todas las opciones que hemos pasado a openvpn por linea de comandos mediante --opcion, pueden ir en dicho fichero de configuración si así lo deseamos.

NSIS (Nullsoft Scriptable Install System) permite empaquetar aplicaciones en un fichero '.exe' autoinstalable. Aplicaciones como OpenVPN (para Windows) o VLC lo utilizan para distribuir sus versiones para plataformas Win32.

Pese a que la aplicación esta ampliamente documentada, he querido escribir este mini-articulo, en el que mediante un ejemplo explico los pasos a seguir para distribuir una aplicación. La idea es que dicho ejemplo sirva de base para no tener que perder mucho tiempo leyendo documentación y realizando mil y una pruebas antes de poder generar un instalable. Podeis utilizar el ejemplo como punto de partida para luego añadir lo que se os ocurra. Para ello os recomiendo dar un vistazo al  rincón de desarrolladores de la wiki del proyecto NSIS.

No he encontrado muchos ejemplos (por no decir ninguno) de como llamar a los métodos SOAP de Mantis desde PHP, asi que aqui dejo unos ejemplitos.

Lo primero de todo es saber que tras la instalación de Mantis, podemos obtener el WSDL bajo esta URL: http://logquesea/api/soap/mantisconnect.php?wsdl

Además del WSDL, es interesante saber que hay una ayuda "para humanos" acerca de los métodos disponibles.  Se puede obtener omitiendo  ?wsdl en la llamada anterior.

A continuación os dejo los ejemplos sobre como llamar a algunos de estos métodos desde PHP.

Chuleta rápida para convertir una maquina VMware Server (''.vmx'') a formato appliance para VMware ESXi (''.ova/.ovf'').

• Inicio → Todos los programas → VMware → VMware Converter
• Convert Machine → Siguiente → Siguiente
• Select the type of source you want to use: Other (Siguiente)
• Source VM or Image: loquesea.vmx (Siguiente)

Esperamos un rato e ignoramos el warning que da (Siguiente)

• Siguiente, Siguiente
• Select destination type: Virtual Appliance (Siguiente)
• Virtual Appliance Name: lo que sea
• Location: donde sea que tengamos espacio suficiente
• Siguiente

Rellenamos los detalles del appliance: Product URL, Version, Vendor, Vendor URL, Annotation...

• Siguiente, Siguiente

Ahora seleccionamos el formato del fichero de salida (distribution format), teniendo especial cuidado de utilizar el formato ova. (Si especificamos ova, obtendremos tanto el formato ova como el ovf. OVF es que que vamos a poder importar desde ESXi)

• Siguiente, Siguiente, Finalizar

Dependiendo del tamaño del a imagen, el proceso puede tardar un buen rato, asi que paciencia.

This is my first post in English, so I apologize in advance for my poor grammar. 

I'll try to explain how to export all the pages of a Trac wiki into a Dokuwiki .  All the process is based in my own shell script, which uses trac-admin, wget and html2wiki to export all the content of your Trac wiki into a dokuwiki folders.

At a glance, the main steps performed by the script are the following:

• Get the Trac wiki pages as a HTML files using wget.
• Remove all the HTML code belonging to the Trac page itself.
• Convert all the pages from HTML to Dokuwiki format (using html2wiki).
• Fix some internal/media links and transform footer attachments into dokuwiki format.
• Rename all the pages and media from upper to lower case.

The output of the script are two tarball files. One with the Dokuwiki pages, and the oter one with the media files.

Bueno, este va a ser una entrada breve. Casi tanto como rápido y fácil ha sido configurar esto en Opensuse 11. Y es que Linux ya no es lo que era. Ahora casi todo se puede hacer a golpe de ratón (snif snfi!).

Bueno, ahi va la receta:

• Desde la sección "Hardware" de Yast,  habilitamos el lector de huellas (Fingerprint Reader).

• Vamos a la sección "Security and Users" de Yast y seleccionamos "User and Group Management". En la pestaña "Users", seleccionamos los usuarios que queremos puedan validar su sesion mediante el lector de huellas y editamos sus propiedades. Vamos a la ventana de plugins, seleccionamos el plugin "Sets the User Fingerprint" y le damos a "Launch". Nos pedira que pasemos el dedo tres veces por el lector y listos.

Ahora, si abrimos un terminal y nos convertimos en su - <usuario>, nos pedira que introduzcamos el password o pasemos el dedo. Mola!

Bueno, pero como funciona realmente todo esto ?

Por un lado, lo que hemos hecho es configurar la autenticación pam para llamar a los modulitos que permiten la entrada desde el lector de huellas. Dicho de otro modo, metemos en /etc/pam.d/common-auth-pc esta linea:

auth    sufficient      pam_thinkfinger.so

Luego, via Yast hemos llamado a la herramienta Think Finger para que lea y verifique nuestra huella y la meta en /etc/pam_thinkfinger en formato usuario.bir.

Así pues, para que tambien podamos pasar a root con un sólo dedo, hemos de ejecutar el siguiente comando  (pasando olimpicamente de Yast). Aunque sólo sea para que parezca que sabemos lo que estamos haciendo.

tf-tool --add-user root

Si queremos pasar al 100% de Yast y hacerlo todo desde la linea de comandos, hemos de asegurarnos de cargar el modulo uinput y que tenemos un dispositivo tipo /dev/input/uinput o similar.

Para más información: man pam_thinkfinger, man tf-tool y thinkfinger.sourceforge.net

Por cierto, por si no lo habeis adivinado aun, sí ahora tengo un Dell m1330 full featured ! Con gadgets así, los cambios de trabajo se hacen menos duros jeje.

El otro dia me regalé un par de libros. Entre ellos la 3ª ediciñon de "Unix Programación avanzada" de Fco. Manuel Márquez, ed. Ra-ma (ISBN:8478976035). La segunda edición de este mirmo titulo fue mi santo grial en la asignatura de Sistemas Operativos. En esta última entrega se ha ampliado bastante la parte de "Procesos", que ahora se llama  "Procesos e Hilos".

Si te interesa enviame un email y acordamos la forma de hacertelo llegar.

Teneis más info sobre el libro aqui.

Mucho ha llovido desde que en 2006 empezara a jugar con Compiz y XGL. Pese ha todo, no ha sido hasta hace unos dias que me he decidido a utilizar Compiz Fusion + AIGLX como configuración por defecto. Los motivos que me retenian en un modelo sin composite manager eran básicamente de fiabilidad y rendimiento. Y es que hasta hace muy poquito, habia un par de problemas con las tarjetas Intel que me impedian trabajar con la fluidez y fiabilidad necesaria para mi trabajo diario.

El principal de ellos era un problema que afectaba a la acelerarción XVideo y algun que otro problemilla. El resultado práctico era que la reprodución de videos a pantalla completa asi como los programas que tiraban de aceleración grafica tipo Google Earth, era patetica. Por otro lado, mi dock preferido hasta la fecha no terminaba de llevarse demasiado bien con el decorador de ventanas de Compiz Fusion  (Emerald) y ni con kde window decorator.  Ahora, los problemas con el video se han solventado y existen otros docks realmente chulos que exprimen al máximo las capacidades de Compiz. De momento estoy utilizando Cairo-Dock, si bien mi idea es utilizar AWN en cuanto sea capaz de hacerlo funcionar en mi OpenSUSE.

Bueno, no me enrollo más os dejo con el obligado video demostrativo en el que además muestro las bondades de VirtualBox corriendo una máquina virtual WindowsXP.

Tal y comentaba en un post anterior, una de las motivaciones principales a la hora de reemplazar mi actual servidor, era reducir el consumo eléctrico que supone tener el servidor encendido las 24 horas del dia. Pues bien, ha llegado el momento de realizar una comparativa de consumos entre el servidor viejo (Pentium III de Intel) y el nuevo (C7-D de VIA).

La verdad es que, pese a que esperaba grandes diferencias en el consumo, los resultados obtenidos no han dejado de sorprenderme. Y es que además de las enormes diferencias en el consumo, me ha llamado mucho la atención ver como la simple ejecución de un salvapantallas puede disparar apreciablemente (2-3W) el consumo de energia de nuestro equipo. Otra curiosidad ha sido ver la pantalla de 15.4" del portatil se come ella solita 7 de los 21W que consume el portatil en reposo.

Ni me imagino la candidad de energia que podría ahorrarse con algo tan simple como deshabilitar el salvapantallas (OpenGL) de las workstations de una gran multinacional con miles de terminales.

Bueno, no me enrollo más, y os dejo a continuación con los resultados de las medidas realizadas.

Los tres equipos evaluados en esta comparativa han sido:

• HP Kayak xu800 (Intel Pentim III 733MHz): El servidor que actualmente hospeda esta web.
• Compaq Presario V4000 (Intel Centrino 1,77MHz): Portatil utilizado para escribir estas lineas.
• Via VB7001 (Via C7-D 1,5MHz): Nuevo servidor

El equipo utilizado para realizar las medidas (grácias Jordi !) es un vatímetro electrónico del fabricante Paget  Trading LTD, modelo 9149. Adquirido en una de las irresistibles ofertas de la cadena de supermercados Lidl.

De cada uno de los equipos, se han tomado medidas del equipo en reposo, realizando accesos de lectura a disco de forma intensiva (dd) y utilizando extensiones OpenGL de la targeta gráfica (glxgears). Para mejorar la fiabilidad y precisión de los test, los valores COST y KWh, son el resultado de medir el consumo de los equipos durante 24 horas de funcionamiento ininterrumpido.

Tras esto, veamos los resultados obtenidos...

Como sabeis, recientemente me he montado un servidor de bajo consumo. Entro otras muchas cosas, el equipo carece de unidad de CD/DVD o disquetera, por lo que instalar el sistema operativo desde un medio optico quedaba descartado. En este mini articulo, voy a explicar cómo instalar Debian 4.0r3 (etch) desde una llave USB.