Ayer, mientras Fuco y yo depurabamos una aplicación utilizando esa pequeña maravilla que es Pry, sentimos la necesidad de evaluar varios fragmentos de código. Para esto, Pry proporciona el comando “edit” que ofrece dos posibilidades: 1) utilizar fichero temporal (la opción -t) , o 2) indicar una ruta donde leer/escribir un fichero. En el primer caso no podemos reutilizar el contenido del fichero por lo que más nos vale no equivocarnos al teclear, y en el segundo nos vemos obligados a indicar dónde guardar los ficheros, lo que es tedioso si sólo pretendemos hacer algo temporal. No pasa nada, pry-buffers al rescate.

Con pry-buffers lo que queremos es juntar lo mejor de 1) y 2), permitiendo manejar buffers persistentes. Veamos cómo es una sesión pry con pry-buffers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

pry(main)> buf
    ...  Aquí un rato con el vim (o con lo que uséis)...
This is de default buffer
pry(main)> buf -l
Available buffers: default
pry(main)> buf -s default
puts "This is the default buffer"
pry(main)> buf test
    ...  Aquí otro rato más con el vim...
This is a test 2
pry(main)> buf -s test
Buffer test contents:
puts "This is a test #{1 + 1}"
pry(main)> buf -l
Available buffers: default, test
pry(main)> buf -d test
Buffer test cleaned

En resumen, podéis usar y gestionar tantos buffers como queráis y estos serán persistentes entre comandos (y entre sesiones Pry).

Para lograrlo hemos uttilizado el mecanismo de extensión de Pry, que permite definir nuevos comandos a través del fichero de configuración de pry ($HOME/.pryrc) o mediante plugins (como pry-doc o pry-remote). Nosotros hemos optado por la segunda opción. Si os apetece probarlo instalad la gema

1

gem install pry-buffers

Y si tenéis curiosidad, el código fuente está en github.

Esta es una gema para uso interno (vamos, para que Fuco sea feliz) pero esperamos que os resulte útil a alguno.

Happy Prying!

Para el que no lo conozca, Tunnelblick es un GUI gratuito y open-source que permite controlar OpenVPN en Mac OS X, y que viene siendo lo que usamos los maqueros de Trabe en nuestras casas para conectarnos a la feliz VPN de Trabe. Es un software muy interesante pero tiene un bug que impide tener múltiples dominios de búsqueda configurados.

Como no quiero resultar pesado, este post tiene dos versiones: la corta, que va al grano y da una solución, y la extendida que explica un poquillo las cosas para el que quiera entender el problema y la solución (TL;DR).

La versión corta

Si vuestra VPN publica varios dominios de búsqueda Tunnelblick sólo se va a quedar con él último dominio (un fallo conocido y documentado: issue 144). Para solucionarlo sólo es necesario explorar los contenidos de la aplicación Tunnelblick.app (versión 3.2beta32) y modificar el contenido del fichero client.3.up.tunnelblick.sh (en Contents/Resources/) con el script que os dejo en este gist (el diff por un lado y el script completo por otro). Configurais la VPN para usar el método de establecimiento de DNS “Asignar servidores de nombre (alternativa 1)” (en inglés “Set nameserver (alternate 1)”) y listo.

La versión extendida (con explicaciones y todo eso)

En Trabe tenemos un DNS interno y varios dominios de búsqueda y los resolv.conf de nuestras máquinas se parecen a esto:

1
2

search pizza.it moussaka.gr tortilla.es
nameserver 192.168.1.10

La VPN está configurada para que envíe esta información a los clientes, utilizando directivas push en la configuración del servidor OpenVPN:

1
2
3
4

push "dhcp-option DNS 192.168.1.10"
push "dhcp-option DOMAIN pizza.it"
push "dhcp-option DOMAIN moussaka.gr"
push "dhcp-option DOMAIN tortilla.es"

Tunnelblick tiene un modo de funcionamiento que teóricamente detecta esta información y modifica el resolv.conf de la máquina cliente de manera adecuada (“Asignar servidores de nombre (alternativa 1)” en castellano y “Set nameserver (alternate 1)” en inglés). Por desgracia no funciona correctamente y sólo tiene en cuenta la última entrada, es decir, que nuestro resolv.conf una vez conectados queda así:

1
2

search tortilla.es
nameserver 192.168.1.10

El problema está en el script que detecta estas opciones y le indica al cliente que modifique su configuración. La cosa comienza a torcerse en la línea 105 del script client.3.up.tunnelblick.sh:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

while vForOptions=foreign_option_$nOptionIndex; [ -n "${!vForOptions}" ]; do
	{
	vOptions[nOptionIndex-1]=${!vForOptions}
	case ${vOptions[nOptionIndex-1]} in
		*DOMAIN* )
			domain="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DOMAIN /}")"
			;;
		*DNS*    )
			vDNS[nNameServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option DNS /}")"
			let nNameServerIndex++
			;;
		*WINS*    )
			vWINS[nWINSServerIndex-1]="$(trim "${vOptions[nOptionIndex-1]//dhcp-option WINS /}")"
			let nWINSServerIndex++
			;;
	esac
	let nOptionIndex++
	}
done

La opción DOMAIN se trata como un campo univaluado y hay que modificar el script para tratarlo como multivaluado, al igual que se hace con el campo DNS. En este gist podéis encontrar el script modificado. Para ponerlo a funcionar os remito a la versión corta del post ;).

Ya hemos notificado todo esto a la gente que hace Tunnelblick y esperamos que lo tengan en cuenta para próximas releases y evitar tener que andar parcheando la aplicación.

Happy VPNing!

La semana pasada publicamos la versión 2.0.0 de SugarfreeConfig, nuestra pequeña gema para acceder de manera sexy a valores de configuración almacenados en un fichero YAML.

Coincidiendo con el arranque de un par de proyectos Rails 3.1 hemos aprovechado para actualizar la gema: hemos modificado levemente el API para hacer SugarfreeConfig un poco más configurable y que se pueda usar fuera de Rails (eliminado la dependencia con ActiveSupport) y hemos cubierto todo el código con tests (utilizando specs de MiniTest para comparar su uso con RSpec, pero esa es otra historia).

Más detalles acerca de SugarfreeConfig en github: https://github.com/davidbarral/sugarfree-config.