martes, 31 de julio de 2012

Utilizando SOCKS por Consola

Tengo conexión SSH con un servidor que está en una red a la que no tengo acceso desde casa. Entonces, para ver recursos Web en esa red, generalmente me valgo de un Proxy SOCKS 5 con SSH y configuro mi navegador. Hago algo como:

$ ssh -D 1234 usuario@servidor

Y después en mi navegador configuro el Proxy SOCKS5 (host: localhost, port: 1234). Con eso puedo navegar sin ningún problema por todos los recursos a los que no tengo acceso desde casa, porque son parte de la red privada. Inicialmente utilizaba un tunel SSH-Forward típico, pero era una pesadilla, del tipo:
$ ssh -L 1234:localhost:1234 usuario@servidor
usuario@servidor$ ssh -L 1234:localhost:80 usuario@servidor-web

Y para acceder al recurso introducía en mi navegador URLs del tipo: http://esedominioquenoveo:1234

Luego, el método de SSH Forwarding lo seguía utilizando hasta hoy para conectarme a otros servicios, no visibles desde el navegador, como por ejemplo MySQL.
De qué va este artículo en realidad, que hoy descubrí tsocks... Si instalas tsocks basta con ejecutar:
$ sudo aptitude install tsocks

Modificar las siguientes últimas líneas del archivo /etc/tsocks.conf:
server = 127.0.0.1
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity 
server_port = 1234

Y luego...
$ ssh -ND 1234 usuario@servidor &
$ tsocks mysql -u usuario -h IP_REMOTA bd

Fíjense que ya no necesito cambiar la IP, porque tsocks resuelve el "problema". NOTA: El usuario debe tener acceso a la BD en la IP_REMOTA desde la IP de servidor.

lunes, 23 de julio de 2012

Aplicaciones web con Node.js

Node.js me tiene impresionado. Es realmente poderoso el enfoque de la plataforma, todo lo que se puede y podría lograr con ella.

Creo que herramientas como esta, simples y poderosas, terminarán por desplazar muchas vacas sagradas, o al menos quitarán cuotas importantes de mercado. He estado investigando quiénes están detrás de la plataforma, o al menos utilizándola, y resulta increíble la cantidad de empresas importantes, entre ellas Yahoo! y Linkedin.

Claro, y es que no hace falta darle demasiadas vueltas a la plataforma para darse cuenta de lo poderoso que puede resultar algo que interpreta el lenguaje de programación más ejecutado (cuentan todos los navegadores del mundo!) y levanta servidores http o tcp con tal facileza.

En lo que vi la plataforma pensé en una sóla cosa: computación distribuida. Pequeños servidores instanciándose en computadores bajo demanda, sin mayores complicaciones, ofreciendo servicios REST y a la vez aplicaciones web que los consumen, bien programados, sin perder de vista buenas prácticas y patrones, bases de datos replicadas, ¿NoSQL?, etc, etc...

A raíz de todas estas ideas y reflexiones, decidí comenzar un proyecto que espero sirva de guía a programadores que se hagan las mismas preguntas que yo. Si bien la plataforma es brutal y tiene un gran presente y futuro, veo que quedan muchas cosas abiertas.

En mi espacio de github conseguirán el proyecto. Aquí el enlace directo. Si alguno se entusiasma y quiere echarle un ojo al proyecto, le recomiendo leer la wiki que iré actualizando. Espero ir haciendo entradas en el blog en español, pero por razones de difusión mantendré el proyecto en inglés.

El proyecto aborda conceptos típicos en aplicaciones de medio tamaño, como: i18n, MVC, DAO, SOA, REST, testing (xUnit style) y documentation (Javadoc style).

domingo, 20 de mayo de 2012

sábado, 12 de mayo de 2012

jueves, 19 de enero de 2012

Algunos tips para gestionar mercurial-server

Agregando usuarios

Para agregar usuarios a una instalación de mercurial-server, basta con agregar la clave pública de la máquina -desde donde se conectará el usuario- al repo hgadmin.

Para generar la clave pública puede ejecutar los siguientes comandos:
$ ssh-keygen -t rsa
$ cat ~/.ssh/id_rsa.pub

Obtenida la clave pública del usuario, deberá pegarla dentro de la carpeta keys/users/ o keys/root/ del repo hgadmin, dependiendo de si quiere que el nuevo usuario sea "ordinario" o "admin", respectivamente. Los admin pueden hacer clone del repo hgadmin (modificar usuarios).

IMPORTANTE: Recuerde que la manera de modificar el repo hgadmin es clonarlo, modificarlo y empujar (push) los cambios al repo principal. NO MODIFIQUE DIRECTAMENTE SOBRE EL SERVIDOR!. Puede seguir los siguientes pasos:
$ mkdir hgadmin-tmp && cd hgadmin-tmp
$ hg clone ~hg/repos/hgadmin .
$ mkdir keys/users/newuser
$ cp ~/newuserkey keys/users/newuser
$ hg add *
$ hg ci -m "Added newuser to repo"
$ hg push

En el momento en que empuje los cambios al repo se agregará automáticamente la nueva clave pública al archivo ~hg/.ssh/authorized_keys, verifíquelo.

Creando un repositorio remoto para compartir entre diferentes usuarios

Debe crear el proyecto en el servidor y luego clonarlo en la máquina donde desee modificar el repositorio. Para ello puede ejecutar los siguientes comandos:

Del lado del servidor
$ cd ~hg/repos/
$ mkdir newrepo && cd newrepo
$ hg init 
$ cd ..
$ chown -R hg.hg newrepo

IMPORTANTE: Dar todos los permisos al usuario dueño del proceso "mercurial-server", en este ejemplo: hg

Del lado del cliente
$ mkdir newrepo && cd newrepo
$ hg clone ssh://hg@hg.mydomain.com/repos/newrepo .

Listo, nuevo repo creado y preparado para ser utilizado!