alvarezp

Esta es una nota rápida para documentar una prueba de conexion VNC inversa (Reverse VNC).

A diferencia de una conexión regular de VNC, en la cual te conectas a la PC a controlar, en una conexión inversa de VNC, la PC a controlar se conecta a ti. El control es en la misma dirección pero la conexión está invertida.

El beneficio? No tener que preocuparse sobre el estado de red ni direcciones de la PC remota. Suele ser más fácil iniciar conexiones que recibirlas. Así, quien tiene mejor conocimiento de redes será el que escuche y el alma en pena será el iniciador. Esto mueve las preocupaciones de red al “escuchante” del socket, justo donde deben estar en este caso en particular. Además, con el estado actual de IPv4 lleno de NAT, el mal necesario, no habrá que preocuparnos sobre la configuración de NAT / port forward en el router remoto.

Conformación de la prueba

La prueba se conforma de mi estación de trabajo de escritorio corriendo Ubuntu y mi laptop corriendo Windows, ambas en el mismo dominio de broadcast de Ethernet. No se toca gateway alguno en la prueba.

Nota: la prueba se realizó con software en inglés, de la cual traduje al español. La traducción podría no ser exacta en comparación con la versión en español del software.

Las características de mi estación de trabajo:

• Sistema operativo: Ubuntu Lucid Lynx (10.04).
• Paquete de VNC: xvnc4viewer 4.1.1+xorg4.3.0-37ubuntu2.
• Rol: Computadora de control (cliente VNC). En un caso real aquí es donde yo estaría sentado y controlando computadoras remotas.
• Dirección IP: 192.0.2.10 (esta dirección es falsa, para documentación según RFC 5735).

Características de la laptop:

• Sistema operativo: Microsoft Windows XP SP3.
• Paquete VNC: TightVNC 1.3.10, instalado de la colección OpenDisc.
• Rol: PC a ser controlada (servidor VNC). En la vida real, esta sería la PC que recibiría soporte técnico por mí..
• Dirección IP: 192.0.2.20 (esta dirección es falsa, para documentación según RFC 5735).

Pasos realizados para establecer la conexión

En la estación de trabajo (el cliente VNC, computadora de control):

• Abrí una terminal
• Ejecuté vncviewer -listen
• Se debe recibir un mensaje como “main: Listening on port 5500″ (”escuchando en puerto 5500″)

En la laptop (el servidor VNC, la computadora a ser controlada):

• Me fui a Inicio » Todos los programas » TightVNC y ejecuté Lanzar Servicio de TightVNC
• Si aparece la ventana Propiedades, deshabilitar “Aceptar conexiones” y hacer click en OK (sólo por seguridad).
• Click derecho en el icono de Servidor TightVNC en la bandeja de sistema y escoger Agregar nuevo cliente…
• Ingresar la dirección IP de la estación de trabajo, en este ejemplo, 192.0.2.10 y hacer clic en OK o presionar Enter.

Notas

• La prueba fue realizada con el Firewall de Windows habilitado. Podrías recibir un mensaje como Para ayudar a proteger tu equipo, el Firewall de Windows bloqueó algunas de las características de este programa. | El administrador del equipo podría ayudar a desbloquear el siguiente programa: TightVNC Win32 Server cuando al correr el Servidor TightVNC. Se le puede dar simplemente “Aceptar” puesto que esa PC será la que inicie y no la que escuche. Este mensaje se inhibe al deshabilitar Aceptar conexiones en la ventana Propiedades del Servidor TightVNC.
• La prueba fue repetida usando una cuenta restringida de Windows con resultados satisfactorios. Esto te da gran flexibilidad. Podrías hasta hacer una versión portátil del servidor de TightVNC siguiendo el paso de las instrucciones en esse documento sobre VNC en el blog TinyApps.Org
• Dependiendo del ancho de banda y latencia disponibles, podría ser necesario ajustar el servidor en la ventana de propiedades.
• Noté una demora algo larga durante el primer intento de conexión, incluso llegando a fallar. En el segundo intento funcionó bien. Quiero suponer que tiene que ver con demoras de resolución de DNS y el caché, pero eso es mera especulación.

Se aceptan comentarios. Si conoces instrucciones para este mismo escenario usando otra plataforma, publícalo en tu blog y enlázalo desde un comentario aquí, o escríbelo directamente en un comentario.

This is a quick note, documenting a quick successful test on Reverse VNC connections.

Unlike regular VNC connections, in which you connect to the controllable PC, in a Reverse VNC connection the controllable PC will connect to you. The control is in the same direction, but the connection is reversed.

What’s the benefit? Not having to worry about the network status and addresses of the remote PC. It is usually easier to initiate connections than to receive. This lets the guy with better network understanding to be the listener and the poor soul to be the initiator. This will put the network worries near to the tech support guy, where it should be for this particular scenario. Also, as with the current state of IPv4, full of the evil but necessary NAT, you will not have to worry about router NAT / port forwarding configuration in the remote router.

Test setup

The test setup consisted on my desktop workstation running Ubuntu and my laptop running Windows, both on the same Ethernet broadcast domain. No gateway was involved in the test.

The desktop workstation had the following characteristics:

• Operating System: Ubuntu Lucid Lynx (10.04).
• VNC package: xvnc4viewer 4.1.1+xorg4.3.0-37ubuntu2.
• Role: Controlling computer (VNC client). In real life here is where I would sit and control other computers.
• IP address: 192.0.2.10 (this is a fake, RFC 5735 documentation address).

The laptop had the following characteristics:

• Operating System: Microsoft Windows XP SP3.
• VNC package: TightVNC 1.3.10, installed from the OpenDisc software collection.
• Role: Controlled computer (VNC server). In real life this would be the PC receiving remote tech support from me.
• IP address: 192.0.2.20 (this is a fake, RFC 5735 documentation address).

Steps performed to establish the connection

On the desktop workstation (the VNC client, controlling computer):

• Opened a terminal
• Ran vncviewer -listen
• You should get a message like “main: Listening on port 5500″

On the laptop (the VNC server, controlled computer):

• Went to Start » All Programs » TightVNC and ran Launch TightVNC Server
• If the Properties window pops up, disable “Accept socket connections” and click OK (just for security reasons).
• Right click on the system tray TightVNC Server icon and choose Add New Client…
• Enter the IP address of the desktop workstation, in this example, 192.0.2.10 and click OK or hit Enter.

Sidenotes

• The test was done with the Windows Firewall enabled. You might get a message like To help protect your computer, Windows Firewall blocked some of this program features. | The computer administrator may unblock this program for: TightVNC Win32 Server when running the Tight VNC Server. You may safely click “OK” because you will initiate connections and not listen for a connection. This message gets inhibited by disabling Accept socket connections in the Properties window.
• The test was repeated using a restricted Windows account, with a successful result. This gives you a lot of flexibility. You might even try making a portable TightVNC server by following the Step 2 from the instructions on this VNC document from the TinyApps.Org blog
• Depending on the available bandwidth and latency, it might be necessary to tweak the server on the Properties window.
• I noticed a somewhat long delay on the first connection attempt, in one case even leading to a connection failing. On the second try it worked fine. I would guess this has to do with DNS resolving delays and caching, but it’s just speculation.

Comments welcome. If you have instructions for the same scenario on different platforms, post it on your blog and link it from a comment, or write it directly on a comment.

Actualización: Fotos del Gultij en CETYS Universidad, por Tonymoyoy.

A través del Grupo de Usuarios de Linux de Tijuana tuve la oportunidad de presentar la conferencia “Estilos en OpenOffice.org” en la 8ª Semana de Ingeniería en el CETYS Universidad. Quiero agradecer tanto al CETYS como al Gultij.

El grupo fue muy agradable a pesar de que la laptop amenazó con hacer berrinches. Los invitamos al Software Freedom Day 2010, donde se repetirá la conferencia. Insisto en que la utilidad de la conferencia sólo se puede medir con el tiempo que Uds. ahorren.

Más adelante se publicará información sobre el SFD 2010 en la página del GUL.

Actualización 1: Entre el código rastreado probablemente no debí registrar db/schema.rb, ya que esto es un efecto de rake db:migrate y no de script/generate y entiendo que el programador no debe tocarlo. Sirva únicamente para seguir el contenido del archivo durante la evolución del desarrollo.

Estuve en el curso de Ruby on Rails que impartió Mario Chávez apenas hace unas horas.

Fue una sesión extensa y muy productiva donde se habló de los básicos de Ruby como de Rails.

Para efectos de enfoque se consideró un sistema de facturación y se comenzó a construir usando Rails:

1. Se generó el directorio de trabajo con rails curso
2. Se generaron las primeras plantillas MVC con script/generate scaffold client name:string address:string rfc:string
3. y se continuó sucesivamente

Confirme fuimos avanzando, registré los pasos en un repositorio Git que ya he subido a Github, donde pueden ver los cambios en línea o desde donde pueden clonarlo con el siguiente comando: git clone http://github.com/alvarezp/curso-ruby-on-rails-1.git para analizarlo fuera de línea con una herramienta como gitk.

Espero que haya más cursos de esta índole. Felicidades y gracias.

Como se anunció hace algunos días en la lista de correos, Superkb 0.21 ha sido liberado.

Permítanme presentarlo para aquellos que no conozcan aún el proyecto.

Teclado Microsoft Natural, pintado por Superkb (Cairo, flat_key)

Superkb es un lanzador de aplicaciones basado en atajos de teclado con pistas gráficas en pantalla. Está escrito en C usando Xlib con la ayuda de Cairo graphics, Pango, Imlib2, Xinerama, etc. y con su código fuente manejado con Git.

Algunas de las características de Superkb:

• Fácil de usar. Se selecciona una tecla mágica (por omisión Super) como la base de los lanzadores y basta con presionar Super+Tecla para ejecutar cualquier comando configurado o aplicación seleccionada.
• No estorboso. Siendo basado en atajos no se necesita nada en pantalla. Al mantener presionada la tecla mágica mostrará en las pistas en pantalla y al soltarla desaparecen.
• Soporte para diferentes geometrías del teclado según lo provea el servidor de X Window System.
• Provee indicadores en pantalla sobre las acciones invocadas.
• La configuración se escribe en un archivo. Instalar la misma configuración en otra computadora es tan simple como copiar el archivo.
• La tecla mágica no se desperdicia. Se puede usar F8 como tecla mágica y al presionarla sin lanzar nada se envía a la aplicación que actualmente tiene el foco. Yo uso esto para la Thinkpad T42.

Aquí hay algunos pantallazos sobre cómo se ve Superkb cuando se han invocado las pistas en pantalla.

Para esta versión, Superkb continuó sobre el camino de la estabilización. Desde la versión 0.20, se ha puesto mucho esfuerzo en corregir comportamientos inesperados e inamigabilidades. Esta es ua liberación que me tiene muy contento. Puedo decir que ya no está en un estado precario de ‘funciona para mí’. Ha sido sumamente probado con la ayuda invaluable del Grupo de Usuarios de Linux de Tijuana, particularmente en esta última versión.

¿Y qué hay de particular en esta versión? Bien, como proyecto:

• Hemos abierto un Wiki con mucha mejor documentación.
• Se creó la lista de correos superkb-devel en lists.sourceforge.net con su archivo.
• Tuvimos nuestro primer día de caza de bugs en Tijuana.

En el software:

• Un drástico incremento en la estabilidad y amigabilidad.
• Las cadenas de retroalimentación ya no requieren de un doble entrecomillado
  (mediante la nueva opción FEEDBACK_STRINGS_AUTOQUOTE).
• Soporte inicial para estados de teclado (como Super+Shift+N contra el simple Super+N).
• Muchos bugs corregidos.

Y aún así, el proyecto cuenta con mucho espacio para mejorar. Particularmente:

• Empaquetamiento. Necesita ser preparado para las diferentes versiones de Debian, Fedora, openSUSE, Ubuntu, Arch Linux, Slackware, etc.
• Inclusión en distribuciones. No hay mejor manera de instalar un programa que simplemente hacer algo como apt-get install <pkgname>. A Superkb le vendría muy bien eso.
• Un mejor sitio web. Aunque la versión actual es mucho mejor que la original, mantenerla actualizada es difícil. Por lo tanto la documentación ha sido movida hacia el Wiki con miras a transformar el sitio web en uno más estático.
• Traducciones. No hay código para la traducción de cadenas en Superkb. Aunque todos los mensajes que no van a stdout son traducibles por medio de configuración, los mensajes de consola deberían ser internacionalizados.
• Pruebas de portabilidad. El proyecto ha sido probado en distribuciones basadas en Debian, Fedora y Slackware en versiones de 32 y 64 bits. Sin embargo, no se ha probado en plataformas ajenas a Linux como openSolaris, *BSD, etc. ni en arquitecturas diferentes a la PC.

Espacio para mejoras de Superkb:

• Un GUI de configuración. Hasta ahora, Superkb debe ser configurado editando un archivo a mano, pero esto está lejos de la visión inicial del proyecto. Superkb cuenta con un espacio para hacer lo que sea cuando una tecla se mantiene presionada por más de 3 segundos. Esto es para la interfaz de configuración.
• Soporte para Xrandr. Actualmente detecta las pantallas usando Xinerama durante el inicio, pero no puede detectar cambios sin que Superkb sea reiniciado.
• Y mucho más.

As announced some days ago in the mailing list, Superkb 0.21 was released.

Please let me introduce it for those that don’t know the project yet.

Superkb is a shortcut-based launcher with on-screen graphical hints. It is written in C using Xlib, with the help of Cairo graphics, Pango, Imlib2, Xinerama, etc. and the source code is managed using Git.

Continue reading ‘Superkb 0.21 released’ »

Esa es la noticia: se ha liberado msn-pecan 0.1.0! Y me da gusto.

Para citar (traducido) del post de felipec en su blog:

Después de un poco más de dos años de desarrollo, realmente nos orgullece anunciar la primera versión estable de msn-pecan. El proyecto comenzó como un “bifurcación” del protocolo msn de libpurple (lea más abajo por qué no es realmente un bifurcación) pero ha crecido y pronto será una librería por sí misma, también con soporte para Telepathy.

Aunque puse sólo 3 de los 1009 parches y que no entiendo nada del código en sí, debo admitir que me siento parte del projecto.

Hace 7 años inicié un proyecto para escribir un cliente de MSN Messenger para Linux, en modo texto, basado en ncurses. El proyecto aún está registrado en Sourceforge como msnclient. Fue mi primer intento de escribir software libre. Sin embargo, el reto fue demasiado grande y el proyecto rápidamente se murió. Nunca llegué más allá de simplemente iniciar sesión y enviar mensajes de una sola palabra a otro contacto.

Eventualmente aprendí a usar Pidgin y conseguí buen hardware y la necesidad de un cliente personalizado de MSN ya no existía. Aún así creo que msnclient es un buen concepto para ser realizado. Tal vez algún día sea una interfaz basada en las funciones de msn-pecan.

Dicho eso, a mediados de 2009, cuando comencé a aprender Git, felipec me proveyó una rama de su repositorio para probar las conexiones directas (mejor conocidas como “transferencias rápidas” o “transferencias p2p”). No funcionaron en ese entonces.

6 meses y muchos commits sobre su master después: 0.1.0-rc1 salió y directconn aún no funcionaba pero la rama dc-test era ya muy vieja. Había aprendido más sobre Git y creí que era lo suficientemente mejor como para intentar corregir el problema de las conexiones directas. Sin embargo no sabía nada de la funcionalidad de MSN ni del código. Al menos sabía cuál era el primer paso: fuera lo que fuere había que hacer un rebase del código. Así que intenté rebasarlo para que las correcciones de la rama dc-test funcionaran bajo la nueva base de código; al menos sería útil para los desarrolladores. Así que la guerra estaba perdida para mí, pero tal vez felipec se podría motivar lo suficiente para continuar trabajando sobre esta parte de msn-pecan (pero se supone que uno no dice eso, cierto?). Así fue como ví las cosas y obtuve la motivación de hacerlo. Además, sería mi primer git rebase en el mundo real.

El principal problema fue que felipec había hecho muchos cambios de reorganización, renombrado y división de código en julio (algunos bien otros mal). Con un poco de experiencia en C, logré hacer el rebase y lo envié como un par de parches.

De repente felipec continuó trabajando arduamente sobre directconn. No sé si fueron los parches o no; eso es lo de menos. Lo importante es que en msn-pecan 0.1.0, las conexiones directas ya funcionan y de manera estable. Aunque no en todos los casos, es un gran avance.

Ahora creo que fue más allá de aprender a hacer un rebase: Realmente aprendí a contribuir usando Git, tal cual lo hacen los niños grandes en el proyecto del Kernel Linux. Aún no entiendo el código ni el funcionamiento interno del proyecto, pero esos dos parches me permitieron aprender mucho sobre colaboración y revisión de software. Esto fue particularmente útil para Superkb que también está hecho en C y su código fuente está manejado en Git.

Así que, gracias nuevamente, felipec, felicidades y todos deberíamos tomarnos un trago por el proyecto, aunque estemos en diferentes partes del mundo. ¡A tirar fiesta y correr la voz!

So that’s the news: msn-pecan 0.1.0 is released! And I’m glad.

To directly quote from Felipec’s post in his blog:

After a bit more than two years of development we are proud to announce the first stable release of msn-pecan. The project started as a “fork” of libpurple’s msn protocol (read below why it’s not really a fork), but it has grown and soon will become a standalone library with support for Telepathy too.

Continue reading ‘felipec’s msn-pecan 0.1.0 released’ »