Problemas con Iceweasel y los módulos criptográficos

Desde que instale un lector de tarjetas inteligentes USB iceweasel me escupe esto en la consola:

[opensc-pkcs11] reader-pcsc.c:1015:pcsc_detect_readers: returning with: No readers found

Ese y otro mensaje del mismo tipo, haciendo referencia a la imposibilidad de acceder al lector externo. Y lo escupe todo el rato, cada 2 ó 3 segundos.

Dado que podría estar enlenteciendo mi navegador me pongo a desinstalar el módulo criptográfico de la tarjeta que pretendo leer (y tiene certificado de la FNMT). El módulo se descarga en el mismo sitio que se carga, ‘Preferencias > Avanzado > Cifrado > Dispositivos de seguridad‘:

Cuando lo instalé (pulsas Cargar en la ventana que sale) me pidió un nombre para el módulo y el propio fichero del módulo: /usr/lib64/opensc-pkcs11.so (sin el 64 para 32bits).
Este fichero no es otra cosa que el driver criptográfico que es capaz de entenderse con el chip. Se instala con las librerías opensc. Pero esa fue una historia anterior.

Pero ahora, cuando abro la ventana de ‘Dispositivos de seguridad’ pueden pasar dos cosas:
La primera opción, más breve, es que se te fríe el navegador y tienes que matarlo por la espalda.
La segunda posibilidad es que el módulo que instalaste aparezca a la izquierda de la ventanita pero sin nombre (un blanco), pero con entradas bajo el título. He aquí el problema.

Cuando instalé el módulo y lo nombré quizás añadí algún espacio o símbolo y de alguna forma iceweasel no lo entendió y no pudo darle nombre. Y por tanto tampoco puede usarlo ni proceder a su desinstalación (‘Descargar’ en la ventanita).

La solución (si se te frió el navegador también) está en el fichero secmod.db que está en la raíz de la carpeta del actual perfil de iceweasel. Es decir en /home/USER/.mozilla/firefox/XXXXXX.default/secmod.db

(Nota: Podemos ver la carpeta concreta si navegamos a about:support, pinchando allí en ‘Directorio de perfil’:‘Abrir carpeta que lo contiene’. Esto va en Firefox 4 y posteriores)

Este fichero guarda la configuración de los módulos criptográficos que instalamos en el navegador. Así que sin más miramientos procedemos a borrarlo. Se permite hacer un pequeño miramiento con un ‘more secmod.db’ para ver que además de ser un fichero binario contiene algunos datos legibles sobre el módulo que nos está amargando (veo cosas como ‘/usr/lib64/opensc-pkcs11.so’). Visto. Procedemos a eliminar esa amargura:

rm secmod.db

Y reiniciamos el navegador, esta vez sin molestos warnings sobre la no existencia del lector y módulos.

Ahora procedemos a instalarlo de nuevo, eso sí, poniendo un nombre al módulo lo más sencillo posible: fnmt.

Para empezar desenchufamos el lector, y matamos el servicio-demonio pcscd, que maneja las tarjetas. Reiniciamos el servicio y enchufamos la tarjeta (no es necesasrio esto último, pero mejor). Abrimos el navegador, y cargamos el módulo con un nombre ‘compatible’:

Y ya está. Veremos nuestro certificado en ‘Sus certificados’.

Lo podemos usar, y también lo podemos desinstalar. Iceweasel ahora sí maneja adecuadamente el módulo y no se queja.

Si por alguna razón alguna vez no se ven los certificados de la tarjeta prueba a reiniciar el demonio:

sudo service pcscd restart

En cualquier caso la opción de descarga del módulo es interesante para tener un arranque más rápido del navegador; parece que iceweasel realiza una comprobación inicial para activar los certificados que tuviéses instalados (como ficheros, no dentro de la tarjeta). Y tarda un par de segundos en mi pepino. Si además no has puesto contraseña maestra es posible que estos certificados sean usables sin solicitar clave. Uy!

Así que yo lo he descargado, y el año que viene, en época de IRPF volveremos a la carga. Turú, turú….

Reboot en Dell E5420

Simplemente añadir ‘reboot=pci’ al GRUB_CMD_LINE (no el default) en el fichero /etc/default/grub
En mi caso queda:
GRUB_CMDLINE_LINUX=”quiet splash reboot=pci”

Otras opciones son reboot=acpi, reboot=kbd, reboot=cold
Incluso parece que se pueden poner todas y el kernel las usara en orden si falla la anterior.
Incluso parece que va mejor:
GRUB_CMDLINE_LINUX=”quiet splash reboot=acpi,bios,pci”

(fuente: linux.koolsolutions.com)

Desactivar el molesto parpadeo del led wifi en iwlagn (Latitude E5420)

A partir del kernel 2.6.39 ya está disponible el control del led para el driver de la tarjeta wifi Ultimate-N 6300 (iwlagn).

Si hacemos ‘modinfo iwlagn’ tenemos:

[...]

parm:           led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking (int)

[...]

Este parámetro no se lista en kernels 2.6.38 y anteriores.

echo 'options iwlagn led_mode=1' > /etc/modprobe.d/iwlagn.conf

Sin reiniciar podemos apagar el wifi con el botón físico y volver a encender. Vemos que se enciende pero ya no parpadea. Bien!

Touchpad con scroll vertical para Dell Latitude 5420 (debian wheezy)

El fallo está en que el touch no es reconocido por el kernel como synaptic sino comp ps2/mouse. El desarrollo está en evolución, quizás algún día.
De momento se puede parchear el kernel (parte) para hacer funcionar el scroll vertical.

La idea es de aquí pero no he utilizado la modificación de esa web, sino el parche que hay en patchwork.kernel.org y de la forma que indican en como indican en el foro de bugs del kernel.

Uso el enlace ‘mbox’ (nada que ver con el mail :-) que descarga un fichero patch de nombre intragable, pero que es la fuente de parcheo del fichero alps.c que hay en:
/usr/src/linux-source/drivers/input/mouse/alps.c
Obviamente me he instalado via apt las fuentes del kernel que uso (en mi caso el de sid, 2.6.39)

Lo parcheo con:

cd /usr/src/linux-source/
patch -p1 < fichero.patch

Y una vez parcheado compilo el psmouse (que llama a otros ficheros, alps.c entre ellos):

cd /usr/src/linux-source/drivers/input/mouse
make -C /lib/modules/`uname -r`/build M=`pwd` psmouse.ko

Y quito el driver en uso del touchpad (atención! te quedas sin touchpad)

rmmod psmouse

para copiar el nuevo y cargarlo.

cp psmouse.ko /lib/modules/`uname -r`/kernel/drivers/input/mouse/
modprobe psmouse

Cada vez que se actualice el kernel (y no contenga el parche u otro arreglo) habrá que hacer esto de nuevo.
Quizás haga falta un reinicio.

Nota: he realizado el parcheo para usar el tocuhpad en 2.6.38 y 2.6.39, pero en ambos casos el parcheo lo he hecho en el kernel 2.6.38. a pesar de que los binarios del nuevo kernel instalado son distintos.
Con un poco de suerte la parte compilada no ha cambiado, o si aún hay más suerte hay cambio y arreglo.

Clonar disco de sistema en pc antigüo

Vamos a ver como podemos clonar el disco de sistema con la idea de sustituirlo por otro con más capacidad.
La práctica se llevo a cabo en un portátil antigüo (y duro como una roca!) con disco IDE. El pequeño viejo compaq sólo tiene puertos usb1.

Método simple
Suponiendo que tenemos el disco nuevo y una carcasa para conectarlo vía usb, desde el mismo host origen y con una live podríamos hacer directamente a ese disco usb:

dd if=/dev/sda of=/dev/sdb

(sda es el disco fijo en el portátil, y sdb usb externo)

Y luego metemos el disco nuevde la carcasa externa USB en el slot para disco del pc. Reinicimos y ya está.

Complicándose la vida

Si sdb en el comando anterior es USB 1 y va muy lento (20 Gb > 5 horas), tendremos que sacar el disco origen (modelo, sda) y meterlo en una carcasa usb.
Lo ponemos en otro pc (ayudante), y nos hacemos una imagen de él (sdb) que para 20Gb dura de 15 a 20 minutos.

dd if=/dev/sdb of=imagen-sda.bin

Metemos mientras el disco nuevo en el host destino y arrancamos con una live cd.
Instalamos openssh-server, con apt o con el deb correspondiente a la distribución (no suele tener dependencias no instaladas en la live).
Nos hacemos root, y nos ponemos una password.
Y desde el host (ayudante) que contiene la imagen ( fichero bin-ario):

dd if=imagenserver.bin | pv | ssh -c blowfish-cbc root@10.0.0.2 " dd ↵ 
   of=/dev/sda"

Nos pide la contraseña y empieza, informando en la salida.

Sin carcasa
Si no tuviesemos carcasa podríamos hacer el primer paso desde el host origen arrancando con una live:

dd if=/dev/sda | pv | ssh -c blowfish-cbc root@10.0.0.2 "dd ↵ 
   of=/home/usuario/imagen.bin"

Luego, cambiaríamos el disco y haríamos el segundo paso igual.

Este último método es más lento, dado que la red en cable cruzado con ssh da unos 7-8Mb por segundo, mucho menos que el USB2. Se tarda 40 minutos por cada paso para los 20Gb, mientras que en el primer caso serían 20min+40min.

Si además quieres usar gzip porque tienes una buena máquina:
http://www.vicente-navarro.com/blog/2008/12/07/usando-ntfsclone-y-dd-para-clonado-por-red-con-netcat/

Por último faltaría agrandar las particiones con gparted.  Si sólo teníamos una partición es rápido y sencillo, pero si hay que estar moviendo particiones y haciendo hueco, échale un rato largoooo.