Por motivos de último minuto que están fuera de nuestro control, el evento del Día Mundial del Software Libre que habríamos de realizar en Tijuana el 18 de septiembre de 2010 se pospone.
Estaremos informando de la nueva fecha y lugar en este blog y en la página oficial del SFD: http://sfd.gultij.org/
Nuestra intención es posponerlo para principios de octubre, pero aún no es seguro.
Mucho agradeceré que hagan extensivo este anuncio para ayudarnos a evitarle a la gente una vuelta en vano a CECUT. De igual manera, será importantísimo que nos ayuden nuevamente cuando tengamos preparado el anuncio con la nueva fecha y lugar, para correr la voz lo más pronto posible a toda la gente.
El CECUT y el GULTIJ agradecen a todos su respuesta ante los preparativos del evento. Este tipo de circunstancias son las que hacen relucir la importancia de la participación de la comunidad. Aún cuando parece indirecta, ésta es tanto o más importante que la del Comité Organizador mismo.
Estamos haciendo todo lo posible por hacer los arreglos correspondientes para contar con un evento de gran calidad y que 2010 año no pase sin festejo.
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:
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.
Casualidad de la vida. recientemente dije por Twitter lo siguiente:
Debatir si existe o no existe «Dios» es como debatir si el 0 es positivo o negativo. La realidad es que ambos son el mismo número.
Para mí, +0 == -0 y la comparación me gusta. Y sí, ya me criticaron… pero en fin.
En código me lo imagino así:
function dios_existe() {
if (sign(0) == 1) return True;
if (sign(0) == -1) return False;
return dios_existe() /* jaja, porque esto pasa con el ser humano */
}
