Archivo de la etiqueta: disco duro

Fallos en una unidad USB después de hibernar/suspender mi ordenador

Si usas hibernar / suspender en tu ordenador y tienes unidades USB montadas habitualmente, es posible que cuando vuelva a despertar no reconozca las unidades USB y te de algún tipo de error.

La forma más rápida de evitar problemas es desmontar todas las unidades USB justo antes de hibernar y volver a montarlas después de despertar. Podemos automatizarlo todo para que ocurra sin tener que hacer nada, solo hay que añadir un script en el directorio /etc/pm/sleep.d/ (suponiendo que usas un sistema Debian o Ubuntu). Observa el script, es muy sencillo, y cámbialo según tus necesidades. Recuerda que, como cualquier script, debe tener permisos de ejecución.

#!/bin/sh
case "$1" in
       hibernate|suspend)
             umount /media/LinBkp1
             umount /media/LinBkp2
             ;;
       thaw|resume)
             mount /media/LinBkp1
             mount /media/LinBkp2
             ;;
       *)
             exit 0
             ;;
esac

No puedo logarme en mi QNAP NAS, solo me deja cambiar la contraseña

Un buen día, la página web de configuración de mi QNAP NAS 219P dejó de permitirme al acceso a la página de administración. Eso significa que no podía reconfigurarlo a través de la web. Solo me permitía cambiar la contraseña, nada más que eso.

Bien, cuando un usuario normal (no admin) del NAS accede a la página web, el único servicio al que tiene acceso es el cambio de contraseña. Solo cuando entra el usuario admin accederá no solo al cambio de contraseña, sino a todos los servicios de configuración del NAS.

En otras palabras, si accediendo como admin, tu NAS solo te ofrece el cambio de contraseña, significa que tiene un fallo en el sistema que le impide saber que el usuario admin tiene privilegios de administrador. Eso normalmente, se configura a través del grupo, que está contenido en el fichero /etc/config/group y contiene algo así:

administrators:x:0:admin
everyone:x:100:admin
guest:x:65534:guest
transmission:x:101:

Vale. Para solucionar esto, tendrás que acceder al QNAP usando SSH. Así que haz un «ssh admin@<ip_del_qnap» y lógate con tu contraseña. Comprueba que el fichero /etc/config/group contiene la primera entrada, la que se corresponde con «administrators:x:0:admin». No importa que esté en la primera línea o en la tercera, pero tiene que estar.

En mi caso, el fichero /etc/config/group solo contenía basura que parecía código html. Algún software había sobreescrito el fichero. En cambio, había un fichero llamado /etc/config/group_tmp que sí contenía las entradas correctas. Símplemente moví el fichero /etc/config/group_tmp a /etc/config/group y reseteé el QNAP. Eso solucionó el problema y ya pude logarme como admin.

Si tu no ves un fichero /etc/config/group_tmp al que echar mano, siempre puedes usar el fichero original de fábrica del QNAP, que es /etc/default_config/group. Cópialo (no lo borres) a /etc/config/group y reinicia.

Muy útil, que el QNAP te permita acceder por SSH. Ya son dos, los lios gordos de los que me ha sacado…

Muchas gracias a Phuture y NocturnalFilth, del QNAP NAS Community Forum, que encontraron la solución un año antes que yo. No me deis las gracias, dádselas a ellos. ;-)

El fichero .xsession-errors crece sin control en Ubuntu 11.10

En Ubuntu 11.10 (Oneiric  Ocelot), me he encontrado conque con cierta frecuencia el /home se queda sin espacio. El motivo es que hay un fichero que crece exponencialmente ocupándolo todo. Me refiero, claro, al fichero .xsession-errors de tu Home. Si borras el fichero con «rm» te encuentras conque no liberas espacio en absoluto y, aunque el fichero no existe, el espacio sigue constando como ocupado. Solo después de resetear el sistema volverás a tener ese espacio libre.

Se trata de un bug conocido. La nueva distribución Ubuntu 12.04 (Precise Pangolin) lo soluciona (más bien lo parchea) volcando los errores del subsistema gráfico a un fichero de /tmp con lo que los logs son borrados en cada reseteo del sistema. Pero si eres como yo y tu ordenador está siempre encendido, los logs nunca serán borrados y el fichero seguirá creciendo exponencialmente aunque esté en /tmp.

La solución definitiva es decirle al sistema de log que ese registro de errores se vaya directamente al agujero negro. Para ello edita el fichero /etc/X11/Xsession, edítalo como root, y en él verás una linea que dice:

ERRFILE=$HOME/.xsession-errors


Cambia esa entrada para que diga:

ERRFILE=/dev/null


Resetea el sistema. Ya está. Ahora el fichero de errores no ocupará espacio porque se irá a carajo según se vaya creando.

Muchas gracias a los miembros de Ubuntu Forums, como siempre ahí, al rescate.

Indexar y buscar ficheros PDF

Bueno, PDF o de cualquier otro tipo. También en djvu, o documentos Word. Si usas tu escaner para gestión documental, sabrás apreciar esto porque tendrás un montón de PDF o DJVU en tu disco duro, y a veces querrás localizar uno de ellos según lo que contengan.

Te recomiendo Recoll, una herramienta basada en Qt, que es  bastante completita y fácil de usar. Está en los repositorios de Ubuntu, así que no deberías tener ningún problema para instalarla.

Eso si, Recoll necesita algunos programas para mejorar sus búsquedas. No son imprescidibles, pero ampliará los ficheros en los que puede buscar.

  • Haz un «apt-get install antiword» para instalar antiword.
  • Haz un «apt-get install djvulibre-bin para instalar djvutxt
  • Haz un «apt-get install aspell-es» para instalar los diccionarios castellanos de Aspell.

Vale, y además puedes editar tu «/etc/crontab» como root para añadir recollindex, una utilidad incluida en el paquete que reindexa tu disco duro. Por ejemplo, puedes añadir esto a tu «etc/crontab»:


24 * * * * lacofi  recollindex

Lo que significa que cada hora, a esa hora y 24 minutos, el usuario «lacofi» reindexará de nuevo su disco duro.

Hala, que lo disfrutes.

Compartición de ficheros «on-line» con Linux.

Vale, supongo que voy a ganarme el odio de un montón de talibanes de Linux. Y supongo que me lo tengo merecido. Pero es que si no lo digo, reviento.

Ubuntu One es una mierda. Así de claro, ¿vale?. Pues ya lo he dicho.

Y es que falla más que una escopeta de feria, deja de sincronizar cuando le da la gana, solo permite sincronizar sistemas Ubuntu, es engorroso y complicado de configurar, en fin, que se mire como se mire, es malo de narices. Si esperan que pague por ese servicio, van de cráneo.

Si buscas un servicio de compartición/sincronización de ficheros on-line que haga un buen trabajo y que sea multiplataforma, te recomiendo encarecidamente Dropbox. Es todo lo que Ubuntu One pretende y aún no ha conseguido.

Dicho queda.

Imation Odyssey en Linux

Hace tiempo que llevaba buscando algún sistema de backup en cartuchos, pero ninguno me convencía. Supongo que lo que buscaba era un pelín exigente: por ejemplo lo quería en cartuchos pero disco duro, no cinta, con alta velocidad de acceso, con mucha capacidad y ampliable sin tener que cambiar de aparato.

Al final me he decidido por la Imation Odyssey, un aparato que no es fácil de encontrar, pero que puede comprarse a través de Internet (eBay, por ejemplo). Es un dispositivo USB 2.0, con cartuchos de diferentes capacidades, actualmente hasta 320Gb aunque prometen cartuchos de 500Gb en breve.

Su aspecto es un poco feo (tiene una pinta un tanto soviética, la verdad), pero si da todo lo que promete es justo lo que estaba buscando. Solo falta que funcione en Linux, claro. ;-)

Lo malo es que en ningún lugar de Internet conseguí aclararme de si funcionaba o no en Linux. Así que lo compré un poco a la aventura, imaginando que funcionaría simplemente por ser USB 2.0 y confiando en el buen hacer del módulo usb_storage.

No me equivoqué, porque resulta que la unidad Imation Odyssey funciona en Linux «out of the box». Vamos, que es enchufar y ya está. Grande, muy grande.

Lo que no funciona son los cartuchos. :-P

Lo digo en serio, no funcionan. Linux no consigue leerlos de ningna forma. Pero el problema es una chorrez muy fácil de arreglar. Resulta que la tabla de particiones es anómala, y tiene particiones extrañas que el software Windows propietario utiliza para encriptar y desencriptar.

La solución es muy fácil: utiliza fdisk y borra todas esas particiones. A continuación crea una única partición primaria y formateala en ext3, ext4, o lo que quieras. Tan simple como eso.

¿Quieres encriptar el cartucho?. Si pretendes sacarlo de casa (y la verdad es que eso es lo que le da sentido a una unidad como ésta), puedes hacerlo usando dm-crypt. En este caso te recomiendo que NO uses un archivo de contraseña, sino simplemente una frase de paso. ¿Porqué?. Pues porque así Ubuntu es capaz de manejarlo de forma transparente: en cuanto metas un cartucho encriptado, Ubuntu te sacará un diálogo en el que te pide la contraseña. La tecleas, y hala, a funcionar.

Estoy encantando con el juguetito, la verdad.

Cómo encriptar una partición de disco duro con dm-crypt

A mi me surgió esta «necesidad» porque quería asegurarme de que nadie pueda leer mi disco duro externo portátil en caso de que me lo roben, pero hay muchos motivos para hacerlo. Unos ejemplos:

  1. Quieres encriptar un disco duro externo USB por si te lo roban. En ese caso, podrias encriptarlo con una contraseña que solo tú sabes, y debes teclear cada vez que lo enchufas. Es el ejemplo más sencillo.
  2. Quieres encriptar todos los datos privados que hay en tu ordenador (carpetas personales, fotos, documentos, etc): si se te estropea el ordenador, quieres estar seguro de que el servicio técnico no toqueteará en tus cosas. En ese caso podrías usar una contraseña tecleada cada vez que arrancas la máquina, pero es un poco peñazo, ¿no?. Es más práctico generar una contraseña aleatoria de, por ejemplo, 1024 bytes y meterla en un fichero en un lápiz USB, de tal forma que si el ordenador arranca con ese lápiz metido, puedes acceder a tus datos, pero si no, no.
  3. Quieres encriptar un disco duro externo USB por si te lo roban, pero manejas datos empresariales, o muy confidenciales (como datos médicos), o simplemente eres un paranoico del carajo. En ese caso puede que desconfies de una contraseña tan sencilla como para poder recordarla, y tampoco te fias de que no te roben el lápiz USB con la contraseña aleatoria. En ese caso, puedes encriptar el fichero con la clave con GNUpg, de tal forma que te pida una contraseña tecleada para poder usarlo. Parece un trabalenguas, pero en la práctica significa que para que alguien pueda leer el disco duro USB necesita tener el lápiz USB con la contraseña, y saber la frase de paso que hay que teclear (y que solo tu sabes). Tendrían que robarte, registrarte y torturarte a la vez, vamos. ;-)

Hay mucha documentación en la red para los que quieren encriptar una partición o un fichero loopback con dm-crypt. Por lo que tengo entendido, es el sistema recomendado, incluso por encima de loop-AES, que sería la alternativa más cercana. Si quieres probar con loop-AES, puedes echar un vistazo a la documentación. Yo lo he probado y te aseguro que funciona a la perfección.

Pero como parece que en los foros se recomienda más dm-crypt, al final me decidí por él.

Como está todo bien explicado en la red, lo que te pongo aquí es solo un resumen rápido de los pasos que seguí yo. Asumo que tienes Gentoo como yo, pero se puede hacer lo mismo en una Debian o un Ubuntu con muy pocas modificaciones. Si quieres más detalles o hacer algunas virguerías, échale un vistazo al HOWTO en castellano, al Tutorial resumido que usé yo, o al Gentoo Wiki más completo, que viene con un montón de detalles.

Lo primero que necesitas es un kernel adecuado. Muchas distribuciones ya incluyen el soporte a la encriptación dm-crypt de serie, como por ejemplo Fedora. Si no es así, entonces tendrás que compilar uno a medida.

Te animo a que compiles un kernel propio, incluso aunque el kernel de serie te funcione sin problemas. Un kernel propio te proporciona mucha flexibilidad a la hora de añadir cosas «finas» a tu sistema. Encriptar una partición de disco duro es un ejemplo, pero como esto hay muchas más, cosas que puedes ajustar o añadir, pero necesitas activar ciertas opciones del kernel. Modificar un kernel ya creado es muy facil, pero hacer uno nuevo desde cero puede ser un poco tortuoso, asi que piensa que tener un kernel propio es como tener mucho trabajo adelantado de cara al futuro.

Haz un «make menuconfig», entra en «Device Drivers» y luego en la opción que dice «RAID and LVM support». Activa las opciones «Multiple devices driver support (RAID and LVM)», «Device mapper support», y «Crypt target support». Ahora vuelve a la raiz y entra en «Cryptographic Options». Ahí yo lo activaría todo como módulos, pero tú tienes que activar al menos «AES cipher algorithims (i586)». Ahora vuelve a la raiz y entra en «Device Drivers» y luego en «Block Devices». Ahí, activa «Loopback device support». Vuelve al sistema y recompila.

Ojo, si quieres tener simultáneamente una unidad loop-AES, además de dm-crypt, has de saber que loop-AES te exige que desactives la opción «Loopback device support» del kernel, y que hagas un «emerge loop-aes» para compilar una versión modificada del módulo «loop» que está en Portage. Hazlo así, a dm-crypt no le importará, siempre y cuando te acuerdes de hacer un «modprobe loop» para que dm-crypt no se queje de que le falta el soporte de dispositivos loopback.

Bien, si vas a usar un fichero de contraseña, lo primero es crear el fichero, claro. Esto lo puedes hacer así, lo que crearía una contraseña fuerte de 1024 caracteres aleatorios (a que no hay narices a memorizarlos):

[root@jeanne ~]# head -c 1024 /dev/urandom > /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chown lacofi:users /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chmod go-rwx /mnt/usbdisk/.clave_discoduro.txt

Si quieres encriptar ese fichero con GnuPG, entonces será necesario teclear una passphrase cada vez que quieras usar el archivo de contraseña. Eso es algo así como usar una contraseña para desencriptar tu contraseña:

[root@jeanne ~]# head -c 3172 /dev/urandom | \
				uuencode -m - | grep -v ==== | tail -n 65 | \
				gpg --symmetric -a > /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chown lacofi:users /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chmod go-rwx /mnt/usbdisk/.clave_discoduro.txt

Y por supuesto, si no quieres complicarte la vida, puedes no especificar ningún fichero de contraseña. Te pedirá una sobre la marcha y tendrás que teclearla a mano todas las veces que montes la unidad.

Observa que me he asegurado de que el fichero que contiene la contraseña es accesible por mí y por nadie más, pero ahí puedes jugar un poco con los permisos según tus necesidades.

Ahora instala cryptsetup.

[root@jeanne ~]# emerge cryptsetup

Ahora MACHACA el contenido de la partición. ¡Cuidado, este comando que sigue destruirá permanentemente cualquier dato que esté en la partición!. ¡De eso se trata, así que no te confundas!.

[root@jeanne ~]# shred -n 1 -v /dev/lacie_backup1
shred: /dev/lacie_backup1: pass 1/1 (random)...
shred: /dev/lacie_backup1: pass 1/1 (random)...16MiB/120.0GiB 1%
shred: /dev/lacie_backup1: pass 1/1 (random)...87MiB/120.0GiB 2%
shred: /dev/lacie_backup1: pass 1/1 (random)...108MiB/120.0GiB 3%
(tómate un café, porque esto puede tardar un buen rato...)

Luego crea un dispositivo mapper (al final, lo que acabarás montando será este dispositivo mapper, y no el dispositivo real). Las instrucciones originales recomiendan también encriptar la partición swap, para que nadie pueda acceder a los datos temporales, pero como yo solo quiero proteger un disco duro portátil y ahí no habrá ninguna partición swap, puedo saltarme este paso.¡Cuidado, este comando que sigue también destruirá permanentemente cualquier dato que esté en la partición, no te confundas de sitio!.

Si estás usando un fichero de contraseña:

[root@jeanne ~]# cryptsetup -v luksFormat /dev/lacie_backup1 /mnt/usbdisk/.clave_discoduro.txt

WARNING!
========
This will overwrite data on /dev/lacie_backup1 irrevocably.

Are you sure? (Type uppercase yes): <YES>
Command successful.

Si omites /mnt/usbdisk/.clave_discoduro.txt te pedirá una passphrase en la línea de comandos. En ese caso te recomiendo que uses la opción «-y», para que te la pida dos veces, y así no tendrás problemas en caso de que te equivoques al teclear.

Si prefieres encriptar el fichero de contraseña con GnuPG:

[root@jeanne ~]# gpg --quiet --decrypt /mnt/usbdisk/.clave_discoduro.txt | \
> cryptsetup -v luksFormat /dev/lacie_backup1
Introduce la passphrase: <aqui metes la passphrase>
gpg: ATENCIÓN: la intgridad del mensaje no está protegida
Command successful.

Observa que el dispositivo que uso es /dev/lacie_backup1 y no /dev/sdb1. Eso es porque tengo bien configurado UDEV. Te lo recomiendo sinceramente.

Ahora tienes que abrir el dispositivo mapper que acabas de crear.

Si usas un fichero de contraseña:

[root@jeanne ~]# cryptsetup --key-file /mnt/usbdisk/.clave_discoduro.txt \
> luksOpen /dev/lacie_backup1 encriptado
key slot 0 unlocked.
Command successful.

Si omites «–key-file /mnt/usbdisk/.clave_discoduro.txt» debería pedirte la contraseña en línea de comandos. Obviamente no serás capaz de recordarla, si la contraseña son 1024 caracteres aleatorios, pero sí si es solo una contraseña tecleada. En cualquier caso, con esto queda abierto y accesible el dispositivo mapper con nombre «encriptado».

Si usas un fichero de contraseña encriptado con GnuPG:

[root@jeanne ~]# gpg --decrypt /mnt/usbdisk/.clave_discoduro.txt 2>/dev/null | \
> cryptsetup luksOpen /dev/lacie_backup1 encriptado
key slot 0 unlocked.
Command successful.

Ahora ya tienes el dispositivo /dev/mapper/encriptado que es con lo que vas a trabajar. Para tí, /dev/lacie_backup1 ya no importa. Bien, pues ahora tienes que formatear el dispositivo. Algunos recomiendan no usar un sistema con journaling porque teoricamente puede producir corrupción de datos. Yo estoy usando ext3 hasta ahora sin problemas.

[root@jeanne ~]# mkfs.ext3 /dev/mapper/encriptado

Y ahora ya puedes crear el punto de montaje y montarlo:

[root@jeanne ~]# mkdir /mnt/lacie_backup
[root@jeanne ~]# mount /dev/mapper/encriptado /mnt/lacie_backup -t ext3 -o rw

El siguiente paso sería meter una entrada nueva en tu fstab:

/dev/mapper/encriptado  /mnt/lacie_backup  ext3  user,noauto,rw  0 0

Con esto, la configuración ya está.

A partir de ahora, para acceder a tu partición metiendo la contraseña a mano (sin fichero de contraseñas) tendrás que ejecutar, también a mano:

[root@jeanne ~]# cryptsetup luksOpen /dev/lacie_backup1 encriptado
(aquí pedirá la contraseña)
[root@jeanne ~]# exit
[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Aunque si estás usando un fichero de contraseña en un lápiz USB, puedes meter los comandos en los scripts de inicio del sistema, de tal forma que si está el lápiz enchufado, la máquina desencripte y monte los directorios seguros automáticamente.

Y para desmontar:

[lacofi@jeanne ~]$ umount /mnt/lacie_backup
[lacofi@jeanne ~]$ su
password:
[root@jeanne ~]# cryptsetup remove encriptado
(mientras no hagas esto último, la partición seguirá estando accesible sin
contraseña)

Si usas un fichero de contraseñas encriptado con GnuPG, tendrías que hacer más o menos lo mismo. Para montar:

[root@jeanne ~]# gpg --decrypt /mnt/usbdisk/.clave_discoduro.txt 2>/dev/null |\
> cryptsetup luksOpen /dev/lacie_backup1 encriptado
(aquí pedirá la passphrase)
[root@jeanne ~]# exit
[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Y para desmontar, igual que antes.

Otra opción para automatizar el proceso sería por ejemplo, entrar en /etc/udev/rules.d/10-local.rules, ir a la entrada que identifica el disco duro lacie_backup1 y añadir en esa entrada una regla tal que así:

RUN+="cryptsetup --key-file /mnt/usbdisk/.clave_discoduro.txt luksOpen /dev/lacie_backup1 encriptado"

Con lo que cada vez que enchufes el disco duro portátil en ese ordenador, se abrirán todos los cerrojos y quedará listo para montarlo (siempre y cuando esté metido el lápiz USB con las claves):

[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Observa que ya ni siquiera necesitamos ser root.

Pero la mejor automatización es la que viene ya de serie en todas las distribuciones Linux actuales, que tienen luksOpen integrado en el sistema, de tal manera que si tienes encriptado un disco, será reconocido directamente en el arranque sólo configurando /etc/crypttab con las claves y /etc/fstab con el punto de montaje.

Así, puedes introducir en /etc/crypttab una línea tal que así:

# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/ paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
#
#                                                                                                                          
encriptado	UUID=bb792154-e58e-4fd8-a2c0-ba3c8cb4cbd8	/mnt/usbdisk/.clave_discoduro.txt

Observa la última línea, donde se especifica el dispositivo mapper que estará asociado al disco, el UUID del disco y el fichero de claves. Esta configuración será leída en el arranque, después de montar todas las unidades, con lo que el dispositivo mapper estará listo y cargado para que que /etc/fstab pueda montarlo.

/dev/mapper/encriptado  /mnt/lacie_backup  ext3  user,noauto,rw  0 0

Que lo disfrutes.

Gestión dinámica de los dispositivos con udev

Actualmente el kernel linux ha migrado hacia el sistema UDEV, que ha sustituido por completo a DEVFS. Por decirlo en cinco palabras: ES EL MOMENTO DE MIGRAR, si es que no lo has hecho ya.

Y francamente, UDEV es muy superior a DEVFS. Merece la pena el esfuerzo. ¿Para qué, te preguntarás?. Bien, UDEV gestiona los dispositivos que aparecen en la carpeta /dev, pero lo hace dinámicamente, creando y destruyendo dispositivos según el kernel los necesite o no, y apoyándose para ello en hotplug, que hace de correveidile entre los eventos del kernel y el espacio de usuario.

UDEV es una gozada, por ejemplo porque permite gestionar de forma rigurosa los discos USB, dandoles nombres personalizados, que no dependen del orden en que los hemos enchufados, sino de su número de serie interno, o su marca, o algo que los identifica físicamente. Ya no tienes que buscar si tu Memorybird se ha instalado como /dev/sda1 o como /dev/sdb1: ahora siempre será /dev/memorybird. (!). Ya no tienes que volverte root (o usar sudo) para usar ese Dongle USB Bluetooth: ahora el dispositivo se creará perteneciendo al grupo que quieras, y con los permisos que quieras.

La instalación está bien documentada, tanto en sistemas linux inespecíficos como en Gentoo. Para convertir tu viejo sistema en una máquina UDEV, puedes leer las mejores instrucciones disponibles en la página de decibels. Si quieres jugar de verdad con las reglas y personalizar tu sistema, te recomiendo el manual de Daniel Drake, muy útil, clarito y sencillo de leer. A estas dos páginas me remito. Lo que te pongo a continuación no es mas que un montón de notas que tomé de ellas, una especie de traducción simplicada y libre. ¿Vamos allá?

UDEV: la instalación

Bien, pues debes entender en primer lugar que UDEV sustituye a DEVFS en el espacio de usuario, y para ello se apoya en sysfs y hotplug. UDEV crea y destruye las entradas /dev basandose en la configuración del sistema. Lo hace mirando los eventos de hotplug y leyendo la información sobre estos eventos a través de sysfs. Los pasos a seguir para la distribución Gentoo son:

Introducción e instalación de nuevo kernel

Lo primero es crear un kernel apropiado. Se puede compilar simultáneamente UDEV y DEVFS en ese kernel, y luego elegir qué es lo que va a funcionar, simplemente poniendo opciones al arranque (las opciones son: devfs o udev). Eso sí, nunca, nunca se debe activar en el kernel la opción «Enable Devfs to automatically mount at Boot».

Bien. Se debe activar:

Bus options (PCI, PCMCIA, EISA, MCA, ISA)
	[*] Support for hot-pluggable devices
File systems
	Pseudo filesystems
		[*] /proc file system support
		[*] /dev file system support (OBSOLETE) (esto es devfs!)
		[*] /dev/pts file system for Unix98 PTYs (a partir de 2.6.4 no está)
		[ ]	/dev/pts Extended Attributes
		[*] Virtual memory file system support (former shm fs)
		[ ] HugeTLB file system support

A partir de la versión 2.6.13 del kernel, la opción «/dev file system support (OBSOLETE)» ya ni siquiera aparece: en esos kernels solo podremos usar UDEV.

Si usas un kernel menor que ese, se puede compilar DEVFS en el kernel, y luego elegir mediante opciones boot (en Lilo), si vamos a arrancar con DEFVS o UDEV. Sin embargo, los cambios que se hagan en DEVFS no serán reflejados en UDEV. La única forma en que se pueden salvar los cambios de DEVFS a UDEV es usando /lib/udev-state/devices.tar.bz2. Si prefieres usar un UDEV puro entonces ningún cambio que hagas en DEVFS será recuperable cuando arranques en UDEV, así que si quieres hacer cambios en tus dispositivos UDEV tendrás que probar a añadirlos en /etc/udev/rules.d/10-local.rules. Debes crear este script, no deberías nunca editar 50-udev.rules.

Emerge UDEV

Una vez que tienes el kernel, hay que hacer un «emerge udev». Esto implica hacer también un «emerge hotplug», porque es una dependencia. Si no usas Gentoo, deberías comprobar cómo se instala udev y hotplug en tu sistema. Seguramente tendrás que hacer un apt-get o usar rpm.

Añadir HOTPLUG al boot runlevel

En Gentoo tienes que añadir Hotplug al boot runlevel mediante «rc-update add hotplug boot». Deberías comprobar que no tienes Hotplug en el default runlevel (rc-update show), porque si es así deberías quitarlo de ahí mediante «rc-update del hotplug default». En otras distribuciones Linux tienes que añadir Hotplug al runlevel para que se ejecute automáticamente en el arranque.

El /Sys

Gentoo debería ahora crear /sys para montar sysfs ahí. Si no es así, deberías crear tú la carpeta /sys manualmente.

El /etc/fstab

Gentoo puede ahora manejar el montaje de devpts y sys. Por eso ya no tienes que añadir ninguna entrada al respecto en /etc/fstab (los kernels modernos ya no lo hacían). En lugar de eso, el trabajo lo hará ahora el script /sbin/rc. Puedes chequearlo con «df -a». Si tienes entradas que se refieran a devpts y sys, es seguro retirarlas ahora de tu /etc/fstab. Si después tienes problemas con devpts o sys y no se montan o no eres capaz de abrir una sesión de consola, probablemente deberías mirar otras posibles causas.

¿Y ahora?

Bien, llegados a este punto podrías creer que si tienes udev, sysfs, y hotplug instalados y funcionado. Pues no. Hasta que sysfs esté montado, /dev montado en tmpfs y hotplug arrancado, realmente no has hecho nada. Puede que veas cambios en /sys, si añades o quitas dispositivos, pero el sistema no está haciendo nada con esta información. ¿Qué es lo que falta?.

Baselayout

Lo siguiente que necesitas es «emerge baselayout», que contiene los init scripts necesarios para arrancarlo todo.

Hay un archivo que deberías comprobar que existe: /lib/udev-state/devices.tar.bz2, que es donde se guarda el actual estado de /dev desde tmpfs cuando reseteas o apagas.

La verdad es que salvar el estado de /dev, va en contra de la filosofía de UDEV, porque se supone que debe ser un sistema de archivos dinámico que crea solo los dispositivos del sistema que necesita. Si los salvas, estarán ahí la próxima vez que arranques, los necesites o no. La razón de hacer esto, es porque al principio solo se creaban dispositivos muy básicos, pero hoy en día UDEV ya ha evolucionado mucho y se crean toda clase de dispositivos, con lo que es posible instalar un sistema UDEV puro. Bien… todavía hay algunos problemas con esto, pero se pueden arreglar con algunos atajos aquí y allá. Si te sirve de algo, te diré que yo he instalado un UDEV puro en mi ordenador y no he tenido ningún problema con un Kernel 2.6.12-gentoo-r6.

En algún momento en el futuro, seguramente Gentoo dará el paso y eliminará devices.tar.bz2. Será cuando UDEV esté ya totalmente perfeccionado y, francamente, tal y como me ha ido a mí, yo diría que lo harán en menos de un año.

Asegúrate de poner los archivos de configuración adecuados en el sitio correcto ejecutando «etc-update». Si no lo haces, no se salvarán tus dispositivos /dev en el archivo devices.tar.bz2. Incluso si planeas usar un sistema puro UDEV, seguirás necesitando esos scripts.

Editar los scripts

Suponiendo un sistema «adecuadamente actualizado», tienes que editar /etc/conf.d/rc y ajustar:

RC_DEVICES="auto"
RC_DEVICE_TARBALL="yes" (o "no", si quieres un UDEV puro como yo).

¿Qué significa «adecuadamente actualizado»?. Bueno:

  1. Un kernel más o menos recientito. Yo lo configuré todo para un kernel 2.6.11-gentoo-r11 y comprobé que no funcionaba nada bien: los dispositivos solo se creaban si ejecutaba a mano «udevstart», y no seguían las reglas personalizadas, se creaban como les daba la gana. Con esa misma configuración, cambié a un kernel 2.6.12-gentoo-r6 y todo empezó a funcionar como la seda, así que ya lo sabés: más o menos por ahí está el límite.
  2. Un baselayout superior a 1.8.6.13-r1.
  3. Un UDEV superior a 024-r1.

No son unos grandes requisitos. Todos ellos pueden conseguirse simplemente actualizando las distribuciones Linux principales.

Si no puedes iniciar una consola

En un sistema puro UDEV es porque no se crea /dev/console y /dev/null. Debes crear manualmente ambos dispositivos:

cd /dev
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3

En el caso de estar actualizado a una Gentoo 2005.1 como la mía cuando me pasé a UDEV, todos los dispositivos se crearon correctamente, incluyendo /dev/console y /dev/null

Menú lilo

Tienes dos opciones:

  1. No arrancar devfs, y se usará udev: añade la opción gentoo=nodevfs
  2. No arranquar udev, y se usará devfs: añade la opción gentoo=noudev

Por ejemplo, con una entrada en lilo.conf tal que así:

image=/boot/vmlinuz-2.6.12-kal
  label=Gentooza
  append="gentoo=nodevfs"
  read-only
  root=/dev/hda3

Reset

Ahora deberías poder resetear y comprobar tu sistema UDEV. Deberías poder ver en el arranque algo así:

Mounting /dev for udev ...
Configuring system to use udev ...
	Populating /dev with device nodes ... (si lo activaste con tarball)
	Setting /sbin/udevsend as hotplug agent ... (dependiendo de versión udev)

Y ahora, deberías crear reglas personalizadas para tus dispositivos removibles. ¡La diversión empieza ahora!. Que lo disfrutes. :-)

¿Funcionará ese disco duro externo LaCie/Porsche FireWire de 160 Gb?

Si tienes Firewire, la unidad conocida como «Hard Drive LaCie design by F. A. Porsche» funcionará perfectamente en tu Linux. :-)

La mayoría de las distribuciones modernas deberían reconocerlo automáticamente sin necesidad de hacer nada. Pero siempre hay excepciones, y puede que haya todavía alguna que necesite de algunos ajustes a mano.

Para ello solo tienes que enchufar el disco duro a tu puerto FireWire, enchufar a la red eléctrica, y cargar los módulos del kernel por orden:

[root@claudia:~]# modprobe ieee1394
[root@claudia:~]# modprobe raw1394 #esto es opcional
[root@claudia:~]# modprobe ohci1394
[root@claudia:~]# modprobe sbp2

(Naturalmente, si no tienes estos módulos, tendrás que recompilar tu kernel para activar el soporte FireWire y sus módulos).

Si ahora haces un dmesg, el kernel debería mostrarte cómo reconoce la unidad, de esta guisa:

ieee1394: Initialized config rom entry `ip1394'
ieee1394: raw1394: /dev/raw1394 device initialized
ohci1394: $Rev: 1223 $ Ben Collins <bcollins@debian.org>
ACPI: PCI interrupt 0000:00:09.3[A] -> GSI 9 (level, low) -> IRQ 9
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[9]  Max Packet=[65536]
ieee1394: Node added: ID:BUS[0-00:1023]  GUID[00d04b4a1105bfa7]
ieee1394: Host added: ID:BUS[0-01:1023]  GUID[ffffffffffffffff]
eth1394: $Rev: 1224 $ Ben Collins <bcollins@debian.org>
eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
eth1394: eth1: Could not allocate isochronous receive context for broadcast channel
sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>
scsi5 : SCSI emulation for IEEE-1394 SBP-2 Devices
ieee1394: sbp2: Logged into SBP-2 device
ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
  Vendor: WDC WD16  Model: 00BB-00GUA0       Rev: 08.0
  Type:   Direct-Access                      ANSI SCSI revision: 06
SCSI device sde: 312581808 512-byte hdwr sectors (160042 MB)
sde: asking for cache data failed
sde: assuming drive cache: write through
SCSI device sde: 312581808 512-byte hdwr sectors (160042 MB)
sde: asking for cache data failed
sde: assuming drive cache: write through
 /dev/scsi/host5/bus0/target0/lun0: p1 p2 p3 p4 < p5 p6 >
Attached scsi disk sde at scsi5, channel 0, id 0, lun 0
Attached scsi generic sg4 at scsi5, channel 0, id 0, lun 0,  type 0

Esto significa dos cosas: que la unidad será interpretada como un disco SCSI, y el dispositivo que le corresponde (en mi caso, /dev/sde). La unidad viene, de serie, en una única partición vfat (FAT32, si lo prefieres así). Podrías montarla con un comando del tipo «mount /dev/sde1 /mnt/pruebas -t vfat -o rw». Sin embargo, en todas partes te recomiendan que la reparticiones y formatees a tu gusto, a ser posible con un sistema de ficheros más decente que vfat. Yo hice un «fdisk /dev/hde» y la reparticioné en cinco unidades: para copias de seguridad, para basura, para sistemas virtuales de qemu, para cosas que bajo de internet, y para cosas que comparto con el mldonkey. Todas son unidades ext3, y estoy encantado.

El Firewire tiene un pequeño detalle que puede desconcertarte. Si reseteas el ordenador, es posible que la próxima vez no reconozca el disco externo, y se limite a notificarte la carga del último módulo con una única línea, pero sin especificar absolutamente nada que haga referencia a SCSI:

sbp2: $Rev: 1219 $ Ben Collins <bcollins@debian.org>

De hecho, si reseteas una y otra vez, es posible que la unidad sea reconocida a veces sí, y a veces no, de forma caótica. Eso sí, las veces que la reconoce, funciona perfectamente y sin problemas hasta que vuelves a resetear. ¿Qué esta pasando?. Bien, lo cierto es que es la segunda vez que me encuentro con algo parecido (la otra fue con un escaner SCSI Mustek). Parece ser que los sistemas SCSI a veces se «olvidan» de comprobar si el disco o lo que sea sigue ahí, así que asumen que sí o que no, según algún tipo de señal que manejan en el arranque. La solución es sencillísima: solo hay que enviarle al sistema SCSI un comando que le indique que lo vuelva a comprobar. Es comando es:

[15:07:52/0][root@claudia:~]# echo "scsi add-single-device 0 0 0 0" > /proc/scsi/scsi

Si comprobamos nuestro dmesg, veremos que ahora sí se detecta correctamente y que empieza a funcionar. Naturalmente, si queremos que el disco sea reconocido en el arranque, tendremos que meter estos comandos en los scripts de arranque. En el caso de Gentoo, tendrás que meter los módulos en el fichero /etc/modules.autoload.d/kernel-2.6 (solo los módulos, no el comando modprobe), y en cuanto al comando «echo», puedes ponerlo en /etc/conf.d/local.start, que para eso está.

Actualización: Hace ya mucho tiempo que vengo notando que mi Gentoo reconoce el disco FireWire en todos los arranques. Parece que alguna de las actualizaciones que hago automáticamente ha corregido ese problema y ahora va todo como la seda. Que lo sepas. Es de suponer que en las demás distribuciones habrá ocurrido otro tanto de lo mismo, porque seguramente ha sido algún cambio en el kernel.

Montar automáticamente unidades de disco

Habitualmente uso Linux en una pantalla de X-Windows, ya sea con WindowMaker, Gnome o KDE. Pero es muy, muy raro que no tenga abierta una ventana de comandos. Estoy acostumbrado, desde siempre, a usar comandos para todo, así que no me cuestan nada teclear un «mount /mnt/dvd».

Y es que el montaje de unidades de disco con mount es una de las características más típicas y potentes de UNIX y Linux. Ciertamente, es un sistema muy flexible que proporciona multitud de opciones, pudiendo… bla, bla, bla…

Este truco está obsoleto. Casi todas las distribuciones linux montan ya automáticamente
todas las unidades de disco. Parece que el sentido común acabó imponiéndose. ;-)

Chorradas. Seamos sinceros: todo el mundo usa mount para lo mismo, y al final plantas todas tus opciones en /etc/fstab y las ejecutas siempre igual con un comando estereotipado, como hago yo. Hasta que alguien acostumbrado a Windows, en su inocencia, te dice «Pues eso de montar los discos es un peñazo, en Windows no hay que hacer nada de eso».

Y entonces frunces el ceño y a poco que lo pienses, reconoces que sí, que tienen toda la razón. Windows no te pide que montes los CD antes de usarlos. Lo hace él de forma transparente. Y es una buena costumbre… sinceramente, tener que montarlo todo es un peñazo. Así que vamos a hacer que nuestro Linux se comporte igual.

En primer lugar necesitas instalar un demonio que haga exactamente eso: vigilar la disquetera o el CD, de tal forma que cuando metes un disco, él va y lo monta. Y que cuando no estás haciendo nada con él, va y lo desmonta. En Debian es tan complicado como esto: Anda, vete a una ventana de comandos y teclea «apt-get install autofs».

Ahora tienes que configurarlo. En este ejemplo configuraré el automontaje para mi DVD, mi Iomega ZIP y la disquetera.

Edita /etc/auto.master y déjalo tal que así

# $Id: auto.master,v 1.2 1997/10/06 21:52:03 hpa Exp $
# Sample auto.master file
# Format of this file:
# mountpoint map options
# For details of the format look at autofs(5).
/mnt/auto /etc/auto.discos --timeout=2

La entrada «/mnt/auto» es el directorio donde se van a montar las unidades. «/etc/auto.discos» desvía la configuración de este directorio de montaje hacia otro fichero (puedes especificar varios, si quieres, uno para cada unidad, pero en la práctica es más cómodo hacerlo con uno solo para todo). La opción «timeout» es el tiempo de inactividad, en segundos, a partir del cual el demonio desmontará automáticamente la unidad. En mi caso, son dos segundos.

Ahora edita el fichero /etc/auto.discos:

# $Id: auto.misc,v 1.2 1997/10/06 21:52:04 hpa Exp $
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage
dvd	-fstype=iso9660,ro,sync,nodev,nosuid	:/dev/hdd
floppy	-fstype=auto,sync,nodev,nosuid		:/dev/fd0
zip	-fstype=auto,sync,nodev,nosuid		:/dev/hdb

En este fichero, «dvd» será un subdirectorio de «/mnt/auto», donde el demonio montará el disco dvd, con las opciones especificads y usando el dispositivo que figura en la misma linea. El fichero es bastante claro, como ves.

Ahora tienes que crear el directorio de montaje y borrar los antiguos, que ya han dejado de ser válidos. Los vas a sustituir por simples enlaces simbólicos.

[15:16:04/0][root@claudia:~]# mkdir /mnt/auto
[15:16:10/0][root@claudia:~]# cd /
[15:16:13/0][root@claudia:/]# ls -Fohld dvd floppy /mnt/zip
drwxr-xr-x	1 root	13 ene 25 15:06 dvd
drwxr-xr-x	1 root	16 ene 25 15:06 floppy
drwxr-xr-x	1 root	13 ene 25 15:05 /mnt/zip
[15:16:24/0][root@claudia:/]# rmdir dvd floppy /mnt/zip
[15:16:29/0][root@claudia:/]# ln -s /mnt/auto/dvd /dvd
[15:16:35/0][root@claudia:/]# ln -s /mnt/auto/floppy /floppy
[15:16:43/0][root@claudia:/]# ln -s /mnt/auto/zip /mnt/zip
[15:16:54/0][root@claudia:/]# ls -Fohld dvd floppy /mnt/zip
lrwxrwxrwx	1 root	13 ene 25 15:06 dvd -> /mnt/auto/dvd
lrwxrwxrwx	1 root	16 ene 25 15:06 floppy -> /mnt/auto/floppy
lrwxrwxrwx	1 root	13 ene 25 15:05 /mnt/zip -> /mnt/auto/zip

Observa que hemos creado el directorio «/mnt/auto», pero no los subdirectorios «/mnt/auto/dvd», etc. Está bien, es correcto, y esto hace que los enlaces simbólicos estén rotos. Pero, insisto, así es como debe ser.

Existe un poderoso motivo por el cual estos enlaces simbólicos deben estar rotos. Ese motivo es un requerimiento de UNIX: «los directorios de montaje deben estar siempre vacios». Imagínate que los enlaces simbólicos están bien. ¿Qué ocurre si intentas copiar un fichero a tu disquetera ZIP, sin meter un disco ZIP?. ¡Que lo hace!. Solo que no va a ningún disco ZIP, claro, sino al directorio de montaje, con lo que la próxima vez que metas un disco ya no estará vacío. De ahí que el enlace simbólico esté roto: no se puede grabar nada, ni siquiera accidentalmente, porque el enlace apunta a… nada. No temas, el demonio de montaje se encargará de crear el subdirectorio adecuado en cuanto detecte un disco en la unidad. Y entonces, solo entonces, el enlace simbólico dejará de estar roto.

Ahora ya solo tienes que ponerlo en marcha:

[15:22:12/0][root@claudia:/]# /etc/init.d/autofs stop
[15:22:16/0][root@claudia:/]# /etc/init.d/autofs start

Y ya está. Las unidades DVD, ZIP, y la disquetera de tu ordenador se comportarán de forma «transparente» y «automágica», como en Windows. De hecho, mejor que en Windows. Por ejemplo, si pulsas el botón de expulsión del DVD mientras tienes abierto su contenido en el Konqueror, descubrirás que el ordenador se niega a obedecerte. Sin embargo, bastará con que cierres el Konqueror para que el ordenador desmonte la unidad, «recuerde» la orden de expulsión y saque el DVD, todo en uno. :-)

Eso sí, si usas KDE, descubrirás un pequeño problema con los iconos del escritorio. La solución es sencilla, pero hay que encontrarla. ;-)

Pues eso, encuéntrala. :-D

Obviamente, la mayoría de las distribuciones modernas, como Ubuntu o Fedora, incluyen algun modo de montaje automático por defecto. Este truco solo necesitas aplicarlo si usas alguna distribución anticuada o para frikis (como mi querida Gentoo, por ejemplo ;-).