Hiparco

Recetas y trucos de GNU/Linux e informática en general

Alojado en http://guimi.net

Background / Foreground jobs – gestión de trabajos en fondo

Para pasar un trabajo al fondo (background) podemos pulsar Ctrl+z durante su ejecución y detenerlo:

$ sleep 10
^Z
[1]+  Detenido                sleep 10

También podemos ejecutarlo directamente en background con “&”:

$ sleep 10 &
[1] 5166

Otra opción es ejecutarlo modificando su prioridad con “nice” y “renice”:

$ nice
0
$ nice sleep 10 &
$ nice -n 5 ls
# nice -n -2 ls
$ renice +1 [PID]

Para ver el listado de trabajos en background:

$ jobs
[1]+  Detenido                sleep 10
[2]-  Ejecutando              sleep 10 &

Atención Como se ve, no es lo mismo detenerlo y dejarlo en background, que ejecutarlo en background.

Siguiendo el ejemplo, pasados 10 segundos, cuando ejecutemos cualquier comando, o pulsando intro nos dice:

$
[2]-  Hecho                   sleep 10

Pero el primero sigue en espera:

$ jobs
[1]+  Detenido                sleep 10

Podemos matarlo y terminarlo con:

$ kill %1
[1]+  Terminado               sleep 10

O podemos recuperarlo con:

$ fg %1
sleep 10

DNIe en Debian GNU/Linux Squeeze 64 bits

Este artículo muestra cómo instalar el DNIe en Debian GNU/Linux Squeeze aunque es extensible a otras distribuciones y versiones.

Para instalar el DNIe en sistemas más antiguos.

Una vez instalado un lector de DNI-e, también nos sirve para utilizar tarjetas criptográficas CardOs M4 como las que utiliza por ejemplo la Comunidad Valenciana a través de la ACCV.

El DNI electónico o DNIe se puede hacer funcionar en GNU/Linux, tanto para identificarse en webs como para firmar documentos todo con plena validez legal. Su instalación es, ahora, muy sencilla.

DNIe DNIe

No hay que olvidar que el DNIe tiene sus limitaciones y pegas de seguridad. (Para los “paranoicos” se recomienda utilizar el DNIe únicamente desde sistemas de solo lectura como un CD con Knoppix).
Tampoco hay que olvidar que una firma “normal” es mucho más facil de falsificar que una firma electrónica, pese a que ninguna sea totalmente segura.
 
Las siguientes instrucciones se han probado en Debian Squeeze 64 bits con un lector C3PO LTC31 (de venta en las oficinas de correos por 19,90 €), con un “miniLector Bit4id” del plan avanza2 (es un Advanced Card Systems ACR38-U pero con una caja blanca) y con un lector Omnikey 3021.
C3PO_LTC31 ACS_ACR38-U Omnikey 3021

 

INSTALACIÓN DEL LECTOR

Básicamente vamos a instalar el paquete de la web del dnielectronico.

$ wget http://www.dnielectronico.es/descargas/PKCS11_para_Sistemas_Unix/Debian_Squeeze_opensc-dnie_1.4.8-2_amd64.deb

Para hacerlos funcionar necesitaremos algunos paquetes:

# aptitude install libopensc2 opensc pinentry-gtk2

 
Nos indica que hemos de registrar el módulo PKCS#11 en iceweasel/firefox utilizando el enlace que nos crea en el menú principal del escritorio en “Oficina-> Registrar módulo DNIe PKCS#11“.
Cuando lanzamos este enlace, indicamos que confiamos en la nueva Autoridad Certificadora (CA) para las tres posibilidades.
 
Podemos comprobar si el sistema reconoce correctamente el lector con el comando “pcsc_scan” y probando a introducir y sacar el DNIe (u otras tarjetas similares):

# aptitude install pcscd pcsc-tools
$ pcsc_scan
PC/SC device scanner
[...]
Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card inserted, 
[...]
Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
	DNI electronico (Spanish electronic ID card)
	http://www.dnielectronico.es

 Reader 0: ACS ACR 38U-CCID 00 00
  Card state: Card removed, 

 
Otras pruebas que podemos hacer son (estas con una tarjeta CardOs M4):

$ opensc-tool -l
Readers known about:
Nr.    Driver     Name
0      pcsc       C3PO LTC31 (00426664) 00 00
$ opensc-tool -a
Using reader with a card: C3PO LTC31 (00426664) 00 00
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
$ opensc-tool -n
Using reader with a card: C3PO LTC31 (00426664) 00 00
CardOS M4

 
Para que funcione bien iceweasel/firefox y detecte el módulo sin problemas es necesario reiniciar el navegador.
 
 

USO Y DISFRUTE

Lo primero que hay que saber es que en el DNIe tenemos a nuestra disposición dos certificados, uno para identificarnos (certificado de autenticación) y otro para firmar (certificado de firma), lo que son los dos principales usos del DNIe.

También es importante saber que cada aplicación que utiliza el DNIe establece una “sesión” con el lector de tarjetas y que no puede haber dos sesiones abiertas a la vez. Es decir no podemos usar el DNIe en dos aplicaciones a la vez. Sin embargo muchas aplicaciones no indican adecuadamente esta circunstancia y simplemente parece que no funcionan.
Así por ejemplo si iniciamos sesión en iceweasel/firefox para acceder a una web, no podemos firmar un archivo pdf con sinadura hasta cerrar sesión. Y al revés, tras firmar un fichero con sinadura no nos deja validarnos con iceweasel.
Ante la duda basta con extraer y volver a introducir el DNIe en el lector para asegurarse que está disponible el acceso.
 
Un último recordatorio, si se introduce el PIN del DNIe erróneamente tres veces seguidas, éste se bloquea. Así que al hacer pruebas con los programas y sus configuraciones hay que tener cuidado. A mí se me bloqueó haciendo pruebas con Sinadura (para desbloquearlo hay que pasar 5 minutos por una comisaria), así que después cada vez que hacía una prueba con un programa si no funcionaba perfectamente iniciaba sesión en iceweasel/firefox.
 

Identificarse en sitios web con iceweasel/firefox

El DNIe se puede utilizar al navegar para identificarse en un sitio web. Así por ejemplo si nos identificamos en la web de la seguridad social podremos descargarnos al instante nuestra vida laboral.

Primero debemos asegurarnos que hemos registrado en iceweasel/firefox el módulo de DNIe PKCS#11 (usando el menú principal del escritorio en “Oficina-> Registrar módulo DNIe PKCS#11“).
En caso contrario podemos registrarlo a mano desde “Editar -> Preferencias -> Avanzado -> Cifrado -> Dispositivos de seguridad“. Seleccionamos “Cargar”, indicamos un nombre, por ejemplo “DNIe – OpenSC PKCS#11”, y la ruta del módulo “/usr/lib/opensc-pkcs11.so”.
DNIe
 
Si la instalación ha sido correcta y tenemos el lector conectado con un DNIe introducido, nos habilitará la opción “Iniciar sesión” (¡bien!). Si iniciamos sesión nos pedirá el PIN, pero antes es mejor reiniciar el navegador para que nos pida instalar el certificado de la DGP (Dirección General de la Policia).
 
Comprobaciones
Podemos probar nuestro DNIe en el navegador en la página de verificación del portal oficial (el enlace para la verificación está al final de esa página).

Si todo ha ido bien el navegador nos pide nuestro PIN para iniciar sesión (si no lo hemos introducido antes):
PIN DNIe

Cuando conectamos con una web en la que debemos identificarnos nos pregunta cuál de los dos certificados (el de firma o el de autenticación) queremos utilizar. Para identificarnos usamos el de autenticación.
Certificado DNIe

Si el navegador nos indica:

El otro extremo de la conexión SSL no puede verificar su certificado.
(Código de error: ssl_error_bad_cert_alert)

Es porque no hemos iniciado sesión correctamente (hemos fallado el PIN 3 veces, no lo hemos puesto, no está bien instalado el lector…).
 
Lo recomendado es “Iniciar sesión” en el navegador solo cuando se necesita y “Terminar sesión” lo antes posible. Si visitamos una página que requiere certificado sin haber iniciado sesión, el navegador nos solicitará el PIN automáticamente, pero para cerrar sesión hay que ir “a mano” a la opción “Dispositivos de seguridad” del menú.
 

Firmar archivos PDF con Sinadura

Otro uso interesante del DNIe es firmar un archivo PDF. Esta firma tiene plena validez legal. Es decir, hasta ahora había que hacer un documento, imprimirlo y después firmarlo a mano. Ahora podemos hacer un documento, guardarlo como PDF (por ejemplo con OpenOffice Writer) y después firmarlo con nuestro DNIe.
Hay que insistir en que tiene plena validez legal. Sirve para hacer contratos, compra ventas, reclamaciones…

Primero descargamos Sinadura, en mi caso he descargado la versión 3.1.2 para GNU/Linux de 64 bits.

Su instalación es muy sencilla, basta con hacer:

$ java -jar sinaduraDesktop-3.1.2-unix64-installer.jar

y seguir el típico asistente de “siguiente”, “siguiente”, “siguiente”…

Lanzamos el programa desde “Aplicaciones->Otras->Sinadura”.
Para configurarlo vamos a “Aplicaciones -> Preferencias -> Firma -> Certificados“, y elegir “Tarjeta Inteligente“.
También recomiendo ir a “Sinadura -> Preferencias -> Firma -> PDF” y seleccionar otra imagen ya que la que viene por omisión (el logo de Sinadura) apenas permite leer el texto insertado. Yo me he creado una imagen muy clarita del DNIe en grises.
 

Utilizamos el botón “Añadir documentos” para seleccionar el documento pdf a firmar, en mi caso “prueba.pdf” y pulsamos “Firmar“.
DNIe

El programa carga el certificado (la primera vez tarda un poco, si se cuelga probablemente sea por el problema de las sesiones que comentabamos al principio) y después nos pide el PIN del DNIe.
DNIe

Después elegimos el certificado a utilizar, en este caso el certificado de firma:
DNIe

Nos solicita una confirmación:
DNIe

Y ya está. Podemos verificar cualquier documento firmado también desde Sinadura. Primero lo seleccionamos y después utilizamos el botón “Validar
DNIe
 

Más posibilidades

Una de las posibilidades que la gente busca es firmar y/o cifrar correos electrónicos con el DNIe.
Hay que decir que técnicamente se puede pero que su validez legal es cuanto menos dudosa, y como lo que se busca con el DNIe es tener validez legal no es muy práctico. Siempre se puede enviar un correo-e “normal” con un pdf firmado como adjunto, por ejemplo un contrato.

Esto es porque técnicamente para firmar y/o cifrar basta con tener un par de claves pública/privada, pero el estándar internacional PKI requiere, para firmar un correo-e, que el certificado de la clave indique una dirección de correo-e, que será la única que se “certificará”. Sin embargo en el DNIe no se indica ninguna dirección de correo-e, por lo que no se puede utilizar las firmas del DNIe para este fin.
Lo más recomendado es firmar y cifrar con claves GPG, u obtener firmas de la FNMT, que sí están preparadas para este propósito.
En todo caso hay buenas y sencillas guías en internet sobre cómo conseguir, técnicamente, firmar correos-e con el DNIe (GMail+DNIe; Thunderbird+DNIe).

Para consultar otras posibilidades tenemos el oráculo, la página de Servicios Disponibles o la web Kriptopolis.
 
 

dnie, dni electrónico, linux, debian, squeeze, C3PO LTC31, miniLector Bit4id, ACS ACR38-U

Uso de VNC: Escritorio remoto. Compartir escritorio.

VNC (Virtual Network Computing/Computer) permite utilizar una sesión gráfica de un equipo desde otro. Hay servidores y clientes disponibles para los principales SO como GNU/Linux, Mac, Windows…
La sesión gráfica puede ser la misma que se utiliza desde la consola del equipo u otra diferente, siempre que lo permita el sistema operativo. Así se puede compartir una sesión, útil para dar soporte remoto, por ejemplo; o bien se puede utilizar una sesión totalmente independiente.

Siendo VNC (incluido su protocolo) software libre, existen múltiples versiones del servidor (vncserver) y del cliente (vncviewer). No es el objeto de este artículo comentar las ventajas e inconvenientes de cada uno. Las diferentes versiones tienen diferentes optimizaciones, algunos permiten claves de “solo lectura”… Pero en lo principal siguen el estándar y no se diferencian.

Con GNU/Linux, en algunas situaciones, en vez de usar VNC puede ser mejor usar ssh con reenvío de las X (ssh -X servidor; ver Túneles SSH).

Servidor

Por un lado tenemos x11vnc que se usa para compartir una sesión gráfica y por tanto se ha de lanzar desde una sesión con entorno gráfico.
Por otro lado tenemos vncserver que genera diferentes instancias de las X. Se usa por tanto para generar nuevos escritorios independientes.

Compartir escritorio (x11vnc)

Se instala con el previsible:

# aptitude install x11vnc

Y su uso más sencillo es:

$ x11vnc -many

Aunque esto es inseguro.

Para mejorar un poco la situación se recomienda crear una clave (por omisión en ~/.vnc/passwd):

$ x11vnc -storepasswd

Y después lanzar el servidor

$ x11vnc -usepw

Si queremos poner la clave en otro fichero podemos usar:

$ x11vnc -storepasswd /path/to/file
$ x11vnc -rfbauth /path/to/passfile

Generar nuevos escritorios (vncserver)

vncserver es provisto por diferentes programas, como tightvncserver y vnc4server. Podemos instalarlos así (solo es necesario uno):

# aptitude install tightvncserver
# aptitude install vnc4server

Para generar un nuevo escritorio simplemente hacemos:

$ vncserver
New 'servidor:1 (usuario)' desktop is servidor:1

Starting applications specified in /home/usuario/.vnc/xstartup
Log file is /home/usuario/.vnc/servidor:1.log

Nota: Si no existe una clave , por ejemplo la primera vez que se utiliza, solicita al menos una nueva clave. Puede generarse una clave añadida que permita únicamente ver el escritorio pero no interactuar.

You will require a password to access your desktops.

Password: 
Warning: password truncated to the length of 8.
Verify:   
Would you like to enter a view-only password (y/n)? n

Para matar un escritorio hacemos:

$ vncserver -kill :1

Si queremos optimizar la conexión, lo que generalmente ocurre si la conexión no se realiza en una red local, podemos hacer:

$ vncserver :1 -geometry 1024×768 -depth 16 -pixelformat rgb565

Cliente (vncviewer)

El uso del cliente es independiente de si el servidor está compartiendo un entorno gráfico (x11vnc) o generando uno independiente (vncserver).
De nuevo existen múltiples versiones del cliente que proveen el programa vncviewer. Por ejemplo:

# aptitude install xtightvncviewer

Para conectar con el servidor hacemos:

$ vncviewer servidor:puerto
Connected to RFB server, using protocol version 3.8
Enabling TightVNC protocol extensions
Performing standard VNC authentication
Password: 

A la hora de indicar el puerto podemos simplemente indicar el número del escritorio. Este número lo indica el servidor y suele ser el 0 para el escritorio disponible en consola (compartido por x11vnc), el 1 el primer escritorio generado por vncserver…
En todo caso el servidor lo indica en su ejecución (en el ejemplo de arriba “servidor:1”).

Esto no siempre funciona bien fuera de una red local por lo que es mejor indicar el puerto. Por omisión el puerto utilizado es el 590x (5900 para el :0, 5901 para el :1…).

Si conectamos a un equipo a través de una red lenta podemos hacer:

$ vncviewer -encodings “copyrect hextile” servidor:5901

VNC a través de túnel SSH

El protocolo VNC es inseguro. Aunque algunas versiones de servidor vnc implementan capas de SSL, el sistema más estándar es utilizar un túnel ssh:

$ ssh servidor -N -f -L 5901:localhost:5901
$ vncviewer -encodings "copyrect hextile" localhost:5901

Como para VNC la conexión es a un puerto local, por defecto no comprime la comunicación (indica “Same machine: preferring raw encoding”), por eso forzamos la compresión con el parámetro -encodings “copyrect hextile” (ver un poco más arriba como optimizar desde el lado del servidor -vncserver-).

Uso de scp

El uso de scp es muy similar al de ssh (Uso de ssh).
El único parámetro “importante” que cambia es el que indica el puerto, que en ssh es -p y en scp es -P. Todavía no entiendo el porqué de este cambio tan molesto.

El uso es muy similar a cp pero indicando el equipo remoto.

Para copiar el fichero local “prueba” en el equipo remoto (servidor) usamos:

$ scp prueba servidor:.

El fichero se copiará en la carpeta inicial del usuario en el servidor (generalmente ‘/home/usuario/’).

Podemos indicar rutas relativas a la carpeta inicial o absolutas.
Para copiar el fichero “documentos/prueba” del servidor al equipo local usamos:

$ scp servidor:documentos/prueba .

Ahora, usando parámetros de ssh/scp:

$ scp -P 10022 -i .ssh/id_dsa *.tgz usuario@servidor:/ruta/fichero

Otros artículos relacionados:
Configuración de ssh
Confianza ssh
Túneles SSH
Uso de ssh
sshfs – Montando recursos mediante SSH y FUSE

ssh, scp

Uso de ssh

En esta entrada resumiré los diferentes usos del cliente ssh que han ido apareciendo en otras entradas.
Para configurar un servidor ssh se puede consultar: Configuración de ssh.

El uso más sencillo del cliente ssh es:

$ ssh servidor

Esto nos abre una sesión remota interactiva con servidor.
Estamos dando por supuesto que el usuario del equipo remoto tiene el mismo nombre que nuestro usuario local y que el servidor ssh está escuchando en el puerto estándar (22).
Para indicar el usuario del servidor hacemos:

$ ssh usuario@servidor

Algunos parámetros útiles:

-p puerto
Indica el puerto del servidor ssh al que conectarse (puerto)
-i fichero
utiliza el fichero de claves fichero para autenticar la conexión, en vez de usuario/password (ver Confianza ssh)
-X
Indica que queremos utilizar nuestro servidor X para las aplicaciones gráficas (ver Túneles SSH)
-L puerto_local:maquina3:puerto_maquina3
Realiza un túnel entre puerto_local y maquina3:puerto_maquina3 (ver Túneles SSH)
-R puerto_remoto:maquina3:puerto_maquina3
Realiza un túnel entre servidor:puerto y maquina3:puerto_maquina3 (ver Túneles SSH)
-N
Sin conexión interactiva (útil en Túneles SSH)
-f
En segundo plano (útil en Túneles SSH). Al acabar puede usarse, por ejemplo $ killall ssh

Por ejemplo con ficheros de claves, puerto no estándar, usuario diferente del local y varios túneles:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Túneles SSH
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh
 

Túneles SSH

Podemos usar SSH para generar túneles seguros. Estos túneles ssh establecen una conexión cifrada entre un puerto de nuestra máquina local y otro puerto accesible desde la máquina remota, generalmente un puerto local de la máquina remota, pero no necesariamente.

Puede ver como configurar un servidor ssh [Configuración de ssh], de confianza ssh, usos básicos de ssh [Uso de ssh] y scp [Uso de scp].

Túnel directo

Si queremos conectar con un servidor MySQL de una maquina remota “servidor” sin usar ssh conectaremos con nuestro cliente de base de datos al puerto 3306 del servidor. El problema es que toda la comunicación es insegura y viaja en claro.
Si “servidor” dispone de ssh podemos generar un túnel ssh para proteger la comunicación. Lo que hacemos es “conectar” un puerto de nuestra máquina local, por ejemplo 13306 con el puerto 3306 de “servidor”. Después conectamos nuestro cliente de base de datos al puerto local 13306 y ssh se encargará de comunicar con “servidor” de manera segura.

Para hacer este primer túnel sencillo hacemos:

$ ssh servidor -L 13306:localhost:3306

Esto indica que el puerto 13306 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:3306”; esto es el puerto local 13306 apunta al puerto 3306 de “servidor”.

También podemos complicar un poco el comando ssh para usar ficheros de claves (http://guimi.net/blogs/hiparco/confianza-ssh/) que es lo recomendado, mediante -i; para indicar el usuario de la máquina “servidor” si no coincide con el usuario de la máquina local; para indicar el puerto ssh del servidor (si no utiliza el puerto por omisión: 22).
Esta vez generaremos un túnel para el puerto 5432 (el puerto habitual de PostgreSQL) desde el puerto local 5555:

$ ssh usuario@servidor -p x -i id_dsa_copiada -L 5555:localhost:5432

El puerto 5555 de la máquina local (cliente) se dirige al puerto que servidor conoce como “localhost:5432”; esto es el puerto local 5555 apunta al puerto 5432 de “servidor”.

Túnel a una tercera máquina

Supongamos que “servidor-ssh” y “servidor-svn” son dos máquinas de una red local. Uno tiene ssh y otro svn. Nos interesa desde internet conectar de forma segura al servidor de svn:

$ ssh servidor-ssh -L 3690:servidor-svn:13690

El puerto 3690 de la máquina local (cliente) se dirige al puerto que servidor-ssh conoce como “servidor-svn:5432”; esto es el puerto local 5555 apunta al puerto 5432 de la máquina que servidor-ssh conoce como “servidor-svn”. Es importante remarcar que el nombre “servidor-svn” lo resuelve “servidor-ssh”, no nuestro cliente local, por tanto puede ser la IP de la red local o un nombre que sea capaz de resolver “servidor-ssh”.

Con esto establecemos una conexión segura hasta “servidor-ssh” que a su vez conecta en claro (por la red local) con “servidor-svn”. De esta forma si utilizamos un cliente SVN para conectar con el puerto local 13690, la información estará viajando protegida por el túnel ssh hasta “servidor-ssh” y después en claro hasta “servidor-svn”.
Esto permite que “servidor-svn” no tenga ninguna conexión directa con el exterior y esté más protegido.

Túnel inverso

Aunque menos utilizado puede interesarnos que un puerto del equipo “servidor-ssh” se redirija a un puerto a través de nuestra máquina local:

$ ssh servidor -R 13690:localhost:3690

De esta manera todas las conexiones al puerto 13690 de “servidor” será redirigidas al puerto “localhost:3690” de la máquina local.
También se puede hacer por tanto:

$ ssh servidor -R 13690:otra-maquina:3690

El puerto 13690 de la máquina “servidor” se dirige al puerto que nuestra máquina local conoce como “otra-maquina:3690”; esto es el puerto servidor:13690 apunta al puerto que nuestra máquina local conoce como “otra-maquina:3690”. Es importante remarcar que el nombre “otra-maquina” lo resuelve nuestra máquina local.

Túnel no interactivo

Podemos usar la opción -N para que no se abra una conexión interactiva (una consola remota) y podemos usar -f para que el cliente ssh pase a en segundo plano. De esta forma si solo queremos hacer el túnel es más cómodo. Por ejemplo para habilitar un túnel a un servidor de OpenERP:

$ ssh servidor -N -f -L 18070:localhost:8070

Túnel de las X (servidor gráfico)

Aquí trataremos algo totalmente diferente a todo lo anterior. En principio, cuando abrimos una terminal remota mediante ssh “solo” podemos utilizar comandos sin GUI y no aplicaciones gráficas. Podemos pedirle a ssh que para la sesión abierta utilice nuestras X locales (si las tenemos, claro) como servidor gráfico. Así podemos lanzar comandos con GUI, es decir aplicaciones gráficas, que se ejecutarán en el servidor pero las veremos en nuestra máquina local.

$ ssh servidor -X

Varios túneles a la vez

Pueden generarse varios túneles a la vez, por ejemplo:

$ ssh servidor -X -L 18070:localhost:8070 -L 5555:localhost:5901

O con ficheros de claves, puerto no estándar y usuario diferente del local:

$ ssh usuario@servidor -p 10022 -i .ssh/id_dsa -X -L 18070:localhost:8070 -L 5555:localhost:5901

Otros artículos relacionados

Configuración de ssh
Confianza ssh
Uso de ssh
Uso de scp
sshfs – Montando recursos mediante SSH y FUSE

ssh, túnel, túneles ssh

(Des)Activar Ctrl+Alt+Backspace en Gnome

Desde hace unas cuantas versiones, el escritorio Gnome no permite reiniciar el servidor X con la combinación Ctrl+Alt+Backspace.

Para rehabilitarla hay que ir en Gnome 2 al menú ‘Sistema->Preferencias->Teclado‘ y una vez ahí en la pestaña ‘Distribuciones’ seleccionar ‘Opciones’.
En Gnome 3 vamos a ‘Configuración del sistema -> Teclado -> Configuración de la distribución -> Opciones

La opción que buscamos es ‘Key sequence to kill the X server‘ o ‘secuencia de teclas para matar el servidor X‘:

Gnome, kill, X server

SVN+SSH: Conectar con un servidor SVN mediante SSH

Hay bastantes articulillos sobre como conectar con un servidor SVN mediante SSH, utilizando la opción directa, que no nos permite usar ficheros de claves pública/privada de ssh (confianza ssh), ni modificar el puerto de ssh, ni en definitiva usar toda la potencia de ssh.
El sistema directo para configuraciones sencillas de ssh es:
$ svn co svn+ssh://servidor/proyecto
Pero si el servidor está configurado con un mínimo de seguridad esto no es suficiente (Configuración de ssh).

Sin embargo hay una forma casi igual de sencilla usando los túneles SSH que nos permite toda la funcionalidad y potencia de SSH (claves ssh, puerto…).
Primero, desde el cliente, hacemos un túnel ssh desde el puerto 3690 del servidor al puerto 3690 de la máquina local (cliente). En este ejemplo modificamos el puerto y utilizamos claves ssh:
$ ssh usuario@servidor -p xx -N -f -i id_dsa_key_ssh -L 3690:localhost:3690

A partir de hay usamos svn como si estuviese instalado en local:
$ svn co svn://servidor/proyecto

Los túneles ssh son uno de los mejores inventos… se pueden usar para acceder “localmente” a cualquier servidor externo, de cualquier servicio (postgres, svn…) de forma segura y cómoda. [Túneles SSH]

svn, shh, tunel ssh, subversion

Expect: Scripts para procesos interactivos

Algunos procesos no pueden automatizarse simplemente con bash, porque requieren la interacción con el usuario, por ejemplo un login de ssh.
En mi caso quería automatizar el montaje de comparticiones de Windows 2003, y aunque podía enviar la clave en el comando, esto queda grabado en los registros de sistema… no me gusta que se registre mi clave:

#!/bin/bash
#
# unidades_red 0.2 - GPL
# (c) 2007-05 Guimi
# http://guimi.net
#
# Ult mod: Guimi 2012-03
#

# Solicitamos la clave
echo  -n "Introduzca su clave de red: "
# Tomamos nota del estado de stty
oldmodes=`stty -g`
# Quitamos el echo para que no se muestre la clave
stty -echo
# Leemos la clave
read clave
# Volvemos a situar stty como estaba
stty $oldmodes
# Generamos un salto de linea
echo

# OJO: LA CLAVE SE REGISTRA
sudo mount -t cifs //SERVIDOR/RECURSO /MONTAJE/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777,password=$clave

Una solución pasa por expect.
# aptitude install expect

#!/usr/bin/expect -f
#
# unidades_red 0.3 - GPL
# (c) 2012-03 Guimi
# http://guimi.net
#
# Ult mod: Guimi 2012-03
#
# Tomamos el primer parametro como clave
#set clave [lrange $argv 0 0]

# Solicitamos la clave de red
send_user "Introduzca su clave de red: "
stty -echo
expect_user -re "(.*)\n" {set clave $expect_out(1,string)}
stty echo
send_user "\n"

# Anulamos la salida por terminal
log_user 0

# Conectamos las unidades de red
spawn sudo mount -t cifs //SERVIDOR/RECURSO /MONTAJE/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777
expect "*assword:"; send "$clave\r"
expect eof

spawn sudo mount -t cifs //SERVIDOR/RECURSO2 /MONTAJE2/ -o username=guimi,workgroup=MIRED,iocharset=utf8,file_mode=0777,dir_mode=0777
expect "*assword:"; send "$clave\r"
expect eof

expect, password

Solventar en OSCommerce eregi is deprecated

Si tienes OSCommerce y actualizas PHP, aparece el error “eregi is deprecated”.

Para solventarlo vamos al foro de OSCommerce, donde tenemos los parches.

Después siguiendo esta receta de cómo generar (diff) y aplicar (patch) parches, bajamos de github los parches, añadiendo “.patch” al URL y aplicar los parches.

$ wget https://github.com/osCommerce/oscommerce2/commit/79c601a7b3ee87943b92a5e6d77ce02480b49ffe.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/88d550f392d86c02d2fe16d0b93f1de8aa6a6770.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/1bfed2f6bf0e9c1c0ce4b160bce1e881cc6e6ef8.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/15101263fa27b523139b405f99b1613c71a8e2c1.patch
$ wget https://github.com/osCommerce/oscommerce2/commit/bc2bcd9b1bd2148bf852409b3843543555bc01e2.patch
$ patch -p1 < 79c601a7b3ee87943b92a5e6d77ce02480b49ffe.patch
patching file catalog/admin/backup.php
patching file catalog/admin/cache.php
Hunk #1 succeeded at 91 with fuzz 2.
patching file catalog/admin/configuration.php
patching file catalog/admin/ext/modules/payment/sofortueberweisung/install.php
[...]
patching file catalog/admin/includes/functions/general.php
Hunk #1 FAILED at 939.
1 out of 1 hunk FAILED -- saving rejects to file catalog/admin/includes/functions/general.php.rej
[...]
patching file catalog/includes/modules/payment/paypal_express.php
Hunk #1 FAILED at 59.
1 out of 1 hunk FAILED -- saving rejects to file catalog/includes/modules/payment/paypal_express.php.rej
[...]

Si nos fijamos en esta parte de la salida:

patching file catalog/admin/includes/functions/general.php
Hunk #1 FAILED at 939.
1 out of 1 hunk FAILED -- saving rejects to file catalog/admin/includes/functions/general.php.rej

Vemos que al parchear el fichero "catalog/admin/includes/functions/general.php" en la línea 939 ha habido un error.
Tenemos más información en "catalog/admin/includes/functions/general.php.rej". Lo que hace patch en este casp es generar 3 ficheros:
- general.php es el fichero original CON los cambios que SÍ ha aplicado.
- general.php.orig es el fichero original.
- general.php.rej contiene los cambios que NO ha aplicado.
Así si el parche incluye varios cambios para un fichero puede ocurrir que unos cambios se apliquen y otros no.
En este caso no queda más remedio que revisar el cambio no realizado a mano.

Puede ocurrir que el archivo a parchear no exista. En ese caso tendremos solo dos ficheros:
- x.orig con 0 bytes, es copia del original. Como éste no existía, es un archivo en blanco.
- x.rej los cambios que no se han aplicado.
Basta con confirmar que es correcto que el fichero no exista. podría ocurrir que esté movido (revisar porqué), o que sea de un módulo del que no disponemos -lo habitual- (ignorar).

Igual con el resto de parches:

$ patch -p1 < 88d550f392d86c02d2fe16d0b93f1de8aa6a6770.patch
$ patch -p1 < 1bfed2f6bf0e9c1c0ce4b160bce1e881cc6e6ef8.patch
$ patch -p1 < 15101263fa27b523139b405f99b1613c71a8e2c1.patch
$ patch -p1 < bc2bcd9b1bd2148bf852409b3843543555bc01e2.patch
OSCommerce, OSC, github, eregi deprecated, patch,