Cuando somos dependientes de Dropbox y ssh nos falla

Reconozco que desde hace muchos años, ya no me acuerdo cuantos, dependo de la nube en mi trabajo. Ya no traslado las actividades de un lugar a otro en discos o dispositivos USB; simplemente teno todos mis ordenadores sincronizados en Dropbox y mi trabajo se mueve de un lugar a otro  sin tener que transportarlo. Desde la actualización a Fedora 23 Dropbox se desconecta de vez en cuando en mi ordenador principal, y aunque lo reviso siempre, ayer me olvidé y todo el trabajo realizado no estaba hoy hoy por la mañana en mi despacho.

https://commons.wikimedia.org/wiki/File:Dropbox_logo_%28September_2013%29.svg

Tranquilamente decidí conectarme por ssh y ejecutar remotamente Dropbox, pero me fue imposible por que mi ordenador principal rechazaba la conexión. No me quedó más remedio que ir a toda velocidad para activar Dropbox.

https://commons.wikimedia.org/wiki/File:SSH_Communications_Security_logo.svg

La vida es más fácil con la nube, pero nos obliga a configurar protocolos de seguridad que hacen difícil su uso cuando nos falla una herramienta.

PD. Ahora solo me queda ver la configuración del cortafuegos.

FedUp por ssh

Hoy se me lio en trabajo en uno de mis despachos y como vi que no era capaz de terminar a tiempo por la mañana y poder llegar a otro se me ocurrió actualizarlo a través de ssh para ir adelantando tiempo. Primero pensé que quizás no era posible, pero como actualizo siempre por terminal, con un simple ssh se debería poder hacer. Es decir, vamos a tunelizar un poco.

Simplemente,

ssh usuario@ip
   palabra usuario

Una vez lograda la conexión por terminal, nos nombramos administrador de aquel equipo

su -
   palabra administrador

y listo. Se ejecuta la misma secuencia de ordenes que decíamos en la entrada del otro día, se instala fedup

yum --enablerepo=updates-testing install fedup
fedup-cli --network 20 --debuglog fedupdebug.log 

y se reinicia el equipo (un simple reboot).

Al reiniciarse, en la entrada de grub la primera opción es la actualización de fedup, así que supuse que se ejecutaría tras los segundos de espera para permitir escoger una opción.
Luego esperé un tiempo prudencial e intenté volver a entrar, suponiendo que se habría reiniciado tras la actualización. No fui capaz de entrar por ssh, pero creo que se debió a que debió tardar algo más de lo que yo esperaba, por que al llegar por la tarde, el proceso se había realizado y el ordenador había reiniciado y estaba simplemente esperando login.

Solamente tuve que actualizar las extensiones de gnome y a trabajar. Un adelanto de entre una hora o dos.

Escritorio remoto. Fedora 18 64bits y TeamViewer

Después del intento fallido de usar TeamViewer descrito en esta entrada he seguido intentando que funcionara, sobre todo por que otros compañeros han podido usarlo, pero en distribuciones basadas en Ubuntu. La primera razón por la que a mi no me funciona y a otros sí puede ser en que para Ubuntu hay versiones de 32 y 64 bits y en Fedora no. Si nos fijamos en la página de descarga

podemos ver que los ubunteros disponen de binarios para 32 y 64bits. En mi caso, desde la version 17 de Fedora uso distribuciones de 64 bits en todos los ordenadores (menos el netbook), incluso en aquellos que no tienen siquiera 4GB de RAM. Como podemos comprobar a través de yumex, el binario rpm es de 32bits

Entonces he decidido que lo mejor, como siempre, sería compilar de código fuente (el fichero marcado con la flecha azul). No debería haber ningún problema, ya que la instalación del binario se hizo desde yum y las dependencias deberían (teóricamente) estar cubiertas, salvo que faltara alguna librería de 64bits, pero .configure nos avisaría.
Para ello desinstalé el paquete 32, desde el propio yumex, en todos los ordenadores

y traté de instalar desde código. El problema es que ese fichero teamviewer_linux.tar.gz no es tal código; es simplemente una aplicación portable ejecutable desde scripts, por lo que funcionará a través de wine en binarios de 32 bits. En estas condiciones es de suponer que tampoco funcionará. Aun así lo he intentado; instalado en varios ordenadores, lo he activado ejecutando el script

y luego he intentado conectar y actuar entre ellos. Sin embargo, de nuevo soy incapaz de enviar atajos de teclado, por lo que ni siquiera puedo cambiar de área de trabajo.

La única forma de hacer algo es dejar el programa que se quiera utilizar activo en un escritorio y éste en la pantalla, ya que no podremos cambiar mediante el escritorio remoto. La segunda condición es que las acciones deben ser ejecutadas con el ratón, ya que no podemos enviar atajos de teclado.
Conclusiones:
- TeamViewer solo es útil en el entorno Linux a los usuarios de Ubuntu (ya estamos con lo de siempre; parece que Linux=Ubuntu, y no es así).
- He sido un poco iluso pensando que un software propietario ofrecía código abierto, aunque fuera en su versión gratuita.
- Debemos basarnos en las versiones codificadas de de VNC (que yo aun no he sido capaz de utilizar).
- openSSH funciona perfectamente y muchas cosas podemos hacerlas a través de terminal, dejando scripts preparados para ello. La limitación está en las aplicaciones gráficas.

Escritorio remoto en Linux. TeamViewer, ¿para qué?

Mi ordenador personal, de casa, es el corazón de mi actividad informática. Es una máquina comprada y ajustada para mi, mucho más potente de las que tengo en el trabajo y que funciona todo el día (y noche, estilo, 24 7). Además, la copia completa de mi trabajo y ocio está en él. Por ello estoy siempre interesado en conectarme con él desde mis diferentes puestos de trabajo. Sin embargo, nunca he logrado hacer funcionar correctamente un escritorio remoto gráfico. Con ssh consigo conectarme en terminal y hago copias de seguridad, actualizo cuando descubro alguna actualización importante y puedo ejecutar scripts.

Con nautilus/nemo puedo conectarme con mi ordenador y hacer intercambio de ficheros.

Simplemente lo que necesito además es un escritorio gráfico que me permita en momentos determinados ejecutar una acción determinada en un programa gráfico. Como nunca he logrado que me funciones las versiones libres (x11vnc...) lo he intentado con TeanViewer.
Es muy fácil instalarlo. En la página web se descarga el binario adecuado, que en mi caso (Fedora 18) es el rpm. Luego simplemente

su -c 'yum -y install fichero.rpm'

y listo. Simplemente al arrancarlo (en WINE, eso sí) te da una ID numérica y das una palabra clave para poder conectarte a ese ordenador. Luego lo instalas en el/los otros y al ejecutarlo ya se puede conectar al otro ordenador mediante la ID y palabra (flecha de la izquierda). En el caso de haberse registrado, se puede uno conectar directamente a los ordenadores reconocidos (flecha de la derecha).

Y luego ¿que podemos hacer? Pues poca cosa, al menos en mi caso. Por supuesto, se conecta muy fácilmente

pero como ya sabemos, por mis gustos personales mi escritorio está limpio, vacío de todo. En teoría, al activar en Acciones "Enviar combinaciones de clave" (marcado en rojo), el escritorio remoto debería recibir atajos de teclado, pero en mi caso no ha sido así.

He probado activando en el servidor y en el cliente, en uno y no en el otro, en el otro pero no en el uno, lo he intentado en red local, con otro ordenador, con un portátil, y nada. He intentado que funcionara dejando el panel superior a la vista, pero las ordenes del ratón no se ejecutaban (y además dejaban inutilizado el panel, que luego tenis que activar manualmente al usar el ordenador). La única forma de que funcione es dejar el programa que queremos activar las funciones a la vista, y en el escritorio activo, ya que al no recibir los atajos de teclado, tampoco se puede cambiar de escritorio/área de trabajo. Además, aun en ese caso, la respuesta al ratón es aleatoria e irregular.
Lo que si funciona muy bien es el intercambio de ficheros,

pero eso ya lo tenía solucionado, así que, al menos para mi, no me sirve. O me equivoco en algo (y no he visto en la red más explicaciones)o para los usuarios de Linux, o al menos de Fedora, no cubre nada que no podamos hacer con otras aplicaciones que tenemos en el sistema sin añadir nada.

ssh para una necesidad

En general mi trabajo se realiza a través de Dropbox, por lo que rara vez necesito los ficheros de mis otros ordenadores. Sin embargo, a pesar de haber utilizado todos los recursos para aumentar el límite de tamaño de Dropbox en versión gratuita -he llegado hasta 29,03GB- en ocasiones tengo que retirar los trabajos terminados para poder añadir material nuevo. Por ello, tanto la necesidad de acceder a ficheros de los que no disponía, así como la curiosidad, me he puesto a trabajas con ssh entre mis ordenadores. La verdad, una maravilla. Como idea secundaria surge también que baja seguridad se tiene en Internet, que se ve sobre todo en estas actuaciones en escritorios remotos. Una simple palabra nos separa del desastre.