sistemas - Userlinux.net

Desde que decidí dar el salto a Android me he sentido un poco desorientado en cuanto a las aplicaciones, si bien algunas de las que usaba habitualmente en el iPhone tenían versión androide, había muchas otras que no sabía si tenían análoga en esta nueva aventura.

Por suerte todas mis plegarias han sido tenidas en cuenta y no he encontrado prácticamente ninguna carencia, es más, podría decir que el cambio ha sido a mejor puesto tanto las aplicaciones como la configuración del terminal son mucho más adecuadas a mi perfil.

Y como lo normal es buscar nuevas aplicaciones y servicios para el terminal, intentaré hacer un listado de las que utilizo habitualmente, mis aplicaciones favoritas (sin ningún orden ni categorización previa). Lo lógico sería que este listado fuera cambiando con el tiempo puesto que todavía me falta mucho por descubrir. Ahí va...

Si algo bueno tiene Mercurial es que permite la autentificación de usuarios a través de SSH. Es muy sencillo agregar un nuevo usuario a un desarrollo/repositorio: adduser y con meterlo dentro del grupo correspondiente al desarrollo llegaría. Pero ¿qué ocurre si no queremos que ese usuario haga otra cosa que no sean comandos hg?.

Conociendo la existencia de hg-ssh no ocurre demasiado, se trata de un script que hemos de referenciar en el authorized_keys del usuario que acabamos de crear de forma que todos los comandos entrantes pasen por este script. El script se encarga de parsear el comando que se pide en ejecución: si es de la familia de Mercurial lo ejecuta, en cualquier otro caso mostrará un error.

Ejemplo de authorized_keys:

command="~/hg-ssh /home/repo1 /home/repo2",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAA...

He optado por copiar el archivo hg-ssh en el directorio home del usuario, pero se podría referenciar directamente el que trae de ejemplo la instalación de Mercurial.

Porque los BOFH, aunque no queramos reconocerlo, también metemos la pata de vez en cuando. Esta vez me ha costado casi 2 meses de downtime de varias páginas, entre ellas el blog de mi compañero @mameyugo.

Una vez reinstalado el servidor y reiniciados todos los servicios damos por supuesto que todo funciona bien y a otra cosa mariposa. De hecho todo estaba up & running. El problema es que fuera de la red local el servidor de nombres... no servía los nombres por un pequeño detalle:

options
{
    listen-on-v6 { ::1; };
    listen-on { 127.0.0.1; 192.168.1.12 };
}

Vaya la que he liado. Pero ha sido sin querer, de veras, os lo prometo por Theo de Raadt. Mis disculpas caballeros.

Despues de un montón de tiempo sin actualizar el Desktop de casa hoy me he puesto manos a la obra, paso a paso, de versión a versión, sin prisas. Tenía una 8.10 así que -en 2 años- los cambios eran más que significativos como para no tener cuidado con ellos.

Las actualizaciones han llevado su tiempo, aproximadamente media hora cada una. Teniendo en cuenta que tuve que subir varios escalones (8.10 -> 9.04 -> 9.10 -> 10.04) aproximadamente el tiempo total de la operación ha sido de poco menos de 2 horas.

Uno de los cambios más significativos y que quería documentar es el cambio de ubicación de los botones "maximizar", "minimizar" y "cerrar" en la ventana de cada aplicación. Por defecto en 10.04 se encuentran alineados a la izquierda (a lo MacOSX).

Mi predilección por Mercurial ha quedado patente en algún que otro post, así que una vez estamos conforme con nuestro servidor de versiones llega el momento de dar un paso más. Intentaremos configurar un interfaz web para mostrar el código a todo el mundo (una especie de Trac solo para código y adaptado a Mercurial).

El proceso es tan sencillo como crear otro VirtualHost en tu Apache con unas características un poco especiales porque en vez de tirar de archivos dinámicos (.php, .asp…) vamos a tirar de un cgi en Python, así que la configuración sería algo así:

Se me ha metido en la cabeza la fuente Fixed y hasta que conseguí ponerla en Gnome-Terminal no he parado, tampoco es que sea demasiado complicado pero bueno, para la posteridad. Lo primero que haremos será editar el archivo ~/.fonts.conf:

<?xml version="1.0"?>
	<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
	<fontconfig>
	<selectfont>
	<acceptfont>
	<pattern>
	<patelt name="family">
	<string>fixed</string>
	</patelt>
	</pattern>
	</acceptfont>
	</selectfont>
	</fontconfig>

Luego actualizamos la caché y reiniciamos Gnome:

# sudo fc-cache -fv
# /etc/init.d/gdm restart

Y ya debería aparecernos dicha fuente en el selector del terminal. La seleccionamos, aceptamos y a ota cosa mariposa.

ACTUALIZACIÓN: La solución para 10.04 es muy similar.

Quicksilver es uno de los programas que ha revolucionado el mundo MacOSX. Debido a su diseño los usuarios de Mac no tiene menú de inicio por lo que para poder ejecutar aplicaciones tenían que ir a la carpeta Aplicaciones. En linux hay algo parecido que se llama gnome-launch-box. Gnome Launch box se puede encontrar en su pagina oficial, al igual que en el los repositorios de Debian/Ubunutu:

# apt-get install gnome-launch-box
# gnome-launch-box

Nunca había pensado que podía ser tan sencillo, varias veces ha surgido la necesidad de grabar un pequeño tutorial de lo que estás haciendo en el escritorio (que no es lo mismo que grabar video en shell) y siempre he recurrido a herramientas como xvidcap, Istanbul o recordMyDesktop, sin embargo parece mucho más fácil que todo eso y con tan solo la dependencia de ffmpeg:

$ ffmpeg -f x11grab -s wxga -r 25 -i :0.0 -sameq ~/out.mpg

Generará un video out.mpg a 25 fps capturando todo lo que hagamos, fácil y sencillo.

Recomendación directa de Top ten one-liners CommandLineFu (vía Wu), no dejéis de echarle un ojo porque hay comandos bastante curiosos e interesantes.

Las tareas programadas en cron por defecto reportan un correo electrónico con la salida del comando a la cuenta local del propietario de la tarea. Si por alguna razón no queremos que ese correo se envíe tenemos varias alternativas que podemos encadenar para garantizarlo.

Por un lado podemos intentar eliminar la salida de errores en las tareas que hemos programado, bien en la propia tarea o bien haciendo uso de /dev/null/. Y por otro lado está el uso de la variable MAILTO en el cron del usuario, vamos a describir un poco más cada una de estas opciones.

Cuando trabajamos con servidores de versiones seguro que hay muchas razones de peso de por medio, una de ellas -la que veremos- puede ser la replicación de código en diversas máquinas.

Supongamos un montón de máquinas que comparten el mismo código de repositorio, el orden de propagación de un cambio en todas esas máquinas es sencillo:

1. Programamos dicho cambio en nuestro servidor de desarrollo (devel).
2. Hacemos un commit local (en sistemas de versionado distribuido -como Mercurial- cada repositorio también es servidor).
3. Lo siguiente es un push al servidor donde almacenamos el código (repo código).
4. Ahora tocaría entrar en cada una de esas máquinas en las que queremos propagar el código y ejecutar un hg pull ; hg update.