Ejecutar scp en background sin ssh-keys

Problema: tengo que lanzar una orden scp para copiar el contenido de un directorio en un servidorA a la misma ruta en el servidorB. Para ello, me conecto desde el PC de casa al servidorA por ssh y lanzo la orden. El problema radica en que no quiero dejar la terminal abierta en el ordenador de casa. Lo que quiero es darle la orden al servidorA y desconectar. Esto se puede hacer precediendo la orden con un nohup por delante y dejándolo en segundo plano… ¡pero scp pide password! Y si está en segundo plano no lo puedo teclear o_O

Solución: usar claves ssh (ssh-keys), de tal forma que se copia la clave ssh pública en el servidorB y a partir de ahi éste no le pedirá password al usuario conectándose desde servidorA. Ésto se puede hacer y no es demasiado complicado (en resumidas cuentas, se crea una pareja de clave pública-clave privada, se sube la clave pública al servidor B y se da la orden de aceptar al cliente que tenga la clave privada correspondiente, sin necesidad de password), pero me gustaría hacerlo de forma más sencilla, sin claves ssh ni necesidad de más configuraciones. Ésto último también se puede hacer, con screen, esa gran aplicación que poco o nada veo usar a la gente.

Recordemos el problema: quiero conectarme a servidorA y lanzar desde ahí una orden scp para copiar una serie de archivos de servidorA a servidorB. La copia de archivos durará mucho tiempo y no quiero tener la conexión abierta durante todo ese rato. El problema es: si corto la conexión, el scp se para. Para que no se pare, podría usar «nohup scp … &», pero scp pide password, y al lanzarlo en segundo plano (con &), no puedo teclearlo. Así que vamos al grano, usaremos screen, así:

$ screen 
$ lanzo la orden scp

Salgo de screen, pero dejando la sesión abierta. ¿Cómo? Pulsando ctrl+a y luego d . Ahora puedo cerrar la conexión ssh con serverA cuando quiera.

La próxima vez que conecte por ssh contra serverA puedo retomar la sesión que inicié con screen y ver cómo ha ido evolucionando. Para retomar la sesión, tecleamos:

$ screen -r

Parece más complejo de lo que es. Símplemente toma nota de este post para cuando lo necesites 😉

Urte berri on / Feliz año nuevo

Éste será el último post de 2009. Ha sido un año bastante movidito en lo que se refiere al software libre en general, y al movimiento del software libre en Euskadi en particular. Este año, por ejemplo, el Gobierno Vasco decidió que en 2010 abrirá una oficina técnica del software libre, un enorme paso adelante para acercar soluciones libres a toda la ciudadanía. También tuvimos la ocasión de discutir largo y tendido sobre la implantación de Linux en los portátiles de Eskola 2.0. Recibimos un premio Buber, organizamos la primera reunión de usuarios de Android de Euskadi (EtxekoAndroid’09), el grupo ITSAS realizó una install party (llenando la sala de nuevos usuarios, incluso venidos de otras facultades) y dió unas interesantes charlas sobre Python, BSD, LaTeX, certificados digitales…

El 2009 también ha tenido sus malos momentos… uno personal, que recordaré siempre con dolor fue el fallecimiento de Paco 🙁

En fin, 2010, año nuevo, vida nueva 🙂 Entre los proyectos relacionados con software libre que me gustaría ver realizados este año, destacan, primero babeliumproject.com (un proyecto en el que llevo trabajando diariamente desde hace 14 meses, junto a mi grupo de investigación y una selección de estudiantes de últimos cursos de la FISS y que por fin, verá la luz), un concurso de PFC’s basados en software libre del que no puedo hablar más 🙂 o la edición 2010 de EtxekoAndroid (aprovechando el tirón del Google Nexus One)…

Como no podíamos despedir el año sin un poco de emoción, hoy mismo hemos cambiado de ISP en DiarioLinux (!). Así que, es posible que suframos alguna parada temporal que esperemos pase inadvertida 😉

Me gustaría poder seguir «dando la tabarra» desde aquí un año más, y a ser posible, contando con vuestra participación, siempre bienvenida. Urte berri on!

Karmic y Lucid: escoge lo mejor de cada mundo

Problema: al actualizar de Jaunty (9.04) a Karmic (9.10), CUPS ha dejado de funcionar. Leyendo los bugs de esta aplicación en launchpad, me encuentro con que ya existe una solución en la versión 1.4.2-6. Pero esa versión no aparece en el repositorio de Karmic… sino en la siguiente, es decir, en Lucid.

Solución: añadimos desde el interfaz gráfico, usando Synaptic, en la pestaña Sources:

deb http://archive.ubuntu.com/ubuntu lucid main restricted universe multiverse

(también lo podemos hacer editando directamente /etc/apt/sources.list + apt-get update)

Y actualizamos (pulsamos el botón «Reload»).

Ahora editamos /etc/apt/preferences (ojo, el fichero no existe, hay que crearlo):

Package: *                                                                      
Pin: release a=karmic
Pin-Priority: 900
 
Package: *
Pin: release a=lucid
Pin-Priority: 400

Esos dos bloques vienen a decir: por defecto, intenta actualizar siempre del repositorio de mayor prioridad (prioridad=900: Karmic). Pero si alguien fuerza la instalación de un paquete lucid, permíteselo. Se fuerza así:

sudo apt-get -t lucid install cups

El fichero /etc/apt/preferences es importante, dado que si no lo creas, al hacer «apt-get install paqueteX» APT se irá a buscar la versión más reciente de ese paqueteX, que con seguridad será siempre el de Lucid, y se puede liar un buen embrollo. Es decir, sólo queremos paquetes de Lucid cuando forcemos con «-t lucid».

EJIE y el Software Libre

EJIE S.A. es una empresa pública de servicios informáticos integrales cuyo ámbito de actividad es la administración de la Comunidad Autónoma Vasca. Es lo que pone en el epígrafe de su web. EJIE no se ha caracterizado precisamente por la promoción del Software Libre, y leyendo el programa electoral del PSE, tampoco creo que la reforma de EJIE coja a nadie de sorpresa; ésto es lo que dice dicho programa al respecto:

«Abordaremos una reforma de la empresa pública EJIE que se encarga de los servicios informáticos del Gobierno Vasco. Se debe realizar un estudio de nivel de subcontratación, su deficiente gestión de los recursos, el desnivel con el que cuentan sus departamentos y su retraso en el nivel tecnológico utilizado, ciertamente lastrado por el Framework propietario que utilizan Geremua.»

Si hace unas semanas fue el PP vasco, ahora es el PNV el que pide explicaciones sobre la oficina del software libre, básicamente preguntando: ¿por qué no lo hace EJIE en lugar de formar una nueva oficina? El PNV conoce perfectamente lo que hace y deja de hacer EJIE. No en vano ha estado en el gobierno, durante muchos años, al corriente de lo que se cocía en esa entidad. Y sí, sí que en EJIE se hace uso interno de aplicaciones de software libre, y el PNV lo sabe – y tiene, si quiere, una lista muy detallada al respecto-, no entiendo a qué viene ahora la pregunta. Pero no pondría a EJIE nunca a asesorar sobre software libre, sería como meter al zorro a cuidar del gallinero. Es obvio cuál sería el resultado.

Veamos la pregunta y esperemos que entre PP y PNV no tumben la iniciativa de la oficina:

Alex Etxeberria Aranburu, parlamentario del grupo Nacionalistas Vascos, al amparo del Reglamento vigente, formula las siguientes preguntas para su respuesta por escrito a la consejera de Justicia y Administración Pública del Gobierno Vasco, sobre la contratación de una consultora externa para el software libre.

JUSTIFICACIÓN

En el pleno del 11 de diciembre de 2009, en respuesta a una pregunta, la señora Zabaleta expresó la intención de contratar una consultora externa para realizar las labores de desarrollo y promoción del software libre en el ámbito del Gobierno Vasco. Conociendo los proyectos de asesoría que tiene EJIE, · ¿Cuáles son los motivos por los que no es EJIE quien realiza dichas labores? · ¿Cuáles son los objetivos y proyectos de EJIE en relación con el software libre? · ¿Cuáles son los productos de software libre y cuáles los de licencia en propiedad que utiliza EJIE en los proyectos que está desarrollando en este momento?

Chrome y la visualización de PDFs en Linux

¿Qué es lo que os ocurre al pinchar sobre un enlace que lleva a abrir un PDF en Chrome/Chromium? Que en lugar de abrirse el PDF incrustado se abre una bonita pantalla negra como la de la imagen de la izquierda. Esto se puede evitar de dos formas. La primera: botón derecho, «Save Link as…». Pero claro, es una solución a posteriori (muchas veces no sabes que vas a pinchar sobre un enlace a un PDF hasta que pulsas el enlace y ves las consecuencias). La segunda opción: usar Mozplugger. Pero no la versión oficial, sino una versión parcheada disponible en el repositorio PPA http://ppa.launchpad.net/setack/stuff/ubuntu .

Para instalar ese nuevo repo, abrimos System/Administration/Synaptic y elegimos Settings/Repositories. En la pestaña «Other Software», pulsamos «Add..» y tecleamos el nombre del repositorio PPA indicado.

Si es necesario, importamos las claves GPG en nuestro llavero de claves APT :

$ gpg --keyserver keyserver.ubuntu.com --recv 60FD0E97
$ gpg --export --armor 60FD0E97 | sudo apt-key add -

Pulsamos ahora el botón Reload:
Descargamos el código fuente de Mozplugger+parche, compilamos e instalamos:

$ apt-get source mozplugger
$ cd mozplugger-1.13.0/
$ make
$ sudo make install

Ya queda menos… sólo configurar mozplugger:

$ gksudo gedit /etc/mozpluggerrc

Para que debajo de esta línea:

text/x-pdf:pdf:PDF file

aparezca:

repeat noisy swallow(evince) fill: evince "$file"

¡Presto! Vamos a probar. Abrimos Chrome y tecleamos en la URL: 

about:plugins

Debe de aparecer Mozplugger y… NO debe de aparecer Adobe Acrobat Reader Plugin. Si éste último apareciera, buscar nppdf y quitarlo de la carpeta de plugins. En mi caso:

$ sudo mv /home/juanan/.mozilla/plugins/nppdf.so /tmp

Nota: Chrome reutiliza los plugins de Firefox, y éste a su vez los disponibles en la la carpeta .mozilla. Y en lugar de borrarlo he optado por moverlo a /tmp hasta probar que el experimento funciona 😉

Ahora, cerramos el navegador y por fin, abrimos Chrome, buscamos un PDF y debemos de verlo incrustado en pantalla (gracias a Evince).