Reivindicando la Terminal

Muchas veces nos subimos a la ola del desarrollo de aplicaciones cada vez más complejas y quedamos atrapados en una espiral de featuritis incremental. Entonces, cada tanto es bueno volver a los orígenes y ver como muchas problemas tienen soluciones simples que hemos olvidado (al menos yo).

Así me encontré con el artículo de José Román Hernández en Emezeta blog titulado La gran guía de supervivencia de la terminal de Linux.

En el artículo, José describe aplicaciones para uso exclusivamente en terminal para:

  • Explorar archivos
  • Multitarea y multiventanas
  • Leer el correo
  • Productividad y organización de tareas
  • Redes sociales
  • Gestores de descargas
  • Lectores de feeds
  • Ofimática y visores de documentos y textos
  • Navegadores web
  • Lectores de PDF
  • Reproducción de música
  • Reproducción de videos

todos con la característica de ser aplicaciones para la Terminal.

Creo que este es un muy buen complemento para conversar sobre la Actividad Terminal la próxima oportunidad que tenga para exponer sobre el tema.

Los nuevos TLDs y los navegadores

¿Has probado escribir algo como www.pilas.guru en la barra de tu navegador y ver si llegas a este blog? ¿o cualquier otro sitio con un nuevo TLDs, como.bike o .dance o .camera? Yo si pues quiero utilizar pilas.guru para llegar a este blog…. pero no funciona correctamente.

El problema es que los navegadores ni siguiera lo entienden como un dominio y por lo tengo lo toman como una frase para hacer una búsqueda.

Captura de pantalla 2014-03-09 a la(s) 9.06.29 PM

Encontre dos buenos análisis sobre este problema:

Copiando archivos de un servidor remoto a otro con SCP

Muchas veces me he visto pasando datos de un servidor remoto a otro, ya sea moviendo un sitio web, un dump de base de datos o un maildir con correos. Generalmente utilizo scp (Secure Copy) o rsync sobre ssh para conectar server_origen con server_destino.

Pero qué pasa si un server no se ve con otro; o solo quiero ejecutar comandos en mi host local. En esos casos, descargo los datos a mi host local y los subo al servidor de destino. Pero lo ideal sería conectar a ambos servidores y que el comando ejecute de una sola vez. Sería como (que no funciona para estos casos):

$ scp  server_origen:archivo.tgz  server_destino:archivo.tgz

El problema radica en que la copia se quiere iniciar (obviamente) desde server_origen y éste no tiene la configuración requerida para conectarse a server_destino. Puede verse claramente invocando con -v el scp:

$ scp  -v  server_origen:archivo.tgz  server_destino:
...
Executing: program /usr/bin/ssh host server_destino, user (unspecified), command scp -v -d -t --
...

A veces, con un poco de configuración se puede salvar este problema y lograr el propósito deseado: que los archivos de server_origen lleguen a server_destino, pero no quiero hacer esas configuraciones, quiero algo que esté disponible para mi linea de comando en mi host local de la forma más simple posible.

1. stdOUT – stdIN

Entonces ejecutar una salida estándar en server_orgien que se guarda en un archivo en server_destino, es una solución simple que lo hace:

$ ssh server_origen 'cat archivo.tgz' | ssh server_destino 'cat > archivo.tgz'

los datos terminan pasando dos veces por el ancho de banda al host local, pero no se ocupa el disco local.

2. SCP con parámetros

Claro que si se se puede conectar un servidor con otro, se pude ejecutar pasando los parámetros necesarios para el scp entre uno y otro:

$ ssh server_origen 'scp -Ppuerto archivo.tgz usuario@server_destino:' 

3. Túnel para aplicaciones

Llegado al caso raro que un servidor remoto no se vea con otro, o que se levante un servicio en 127.0.0.1 de server_destino (mysql o rsync) se puede armar un túnel a través del host local para pasar los datos:

 
$ ssh -R 5001:127.0.0.1:5002 server_origen
$ ssh -L 5002:127.0.0.1:3306 server_remoto

y en este ejemplo, ejecutar directamente el comando mysql en server_origen para que conecte con el mysql del server destino:

$ ssh server_origen 'mysql -P5001 -uroot -p base-datos-server_destino < base-datos-server_origen.sql'

En los comandos que se ejecutan en el host local permiten a través del puerto 5001 abierto en server_origen conectar con 127.0.0.1:3306 de server_remoto y cargar el dump de la base de datos.