Discos duros mayores de 32Gb en Linux

A mis servidores necesito ponerles un buen disco duro, entre otras cosas por que van a guardar toda la multimedia que tengo, y por que serán los encargados de descargar de internet, así sus pauperrimos discos de 4 Gb se quedan bastante cortos.

El problema es que son de esos hardwares que en principio no aceptan discos duros de más de 32 Gb (de hecho los discos duros modernos tienen un jumper para limitar sus capacidad a 32 Gb para evitar problemas).

Sin embargo, con Linux el problema es de fácil solución, al menos si el disco de más de 32 Gb no se usa para arracnar el sistema. Basta con poner modo LBA en la BIOS y conectar el disco duro. Linux ya se encarga de acceder a cualquier parte del disco duro sea o no por encima de los 32 Gb.

El problema viene cuando se necesita que el sistema arranque desde uno de esos discos duros, ya que la BIOS es la que tiene problemas para acceder a datos por encima de los 32 Gb (debido a una limitación en las direcciones que maneja). Temo que la solución no es tan sencilla, pero si es posible. Para éste tipo de operaciones lo suyo es consultar el HDs grandes: mini-COMO Andries Brouwertratraducido por Fco. J. Montilla. Hay también un interesante hilo de discusión en las listas de Linux Cantabria de un caso práctico.


En mi caso Sancho arranca desde su disco duro antiguo mientras el secundario, de 120 Gb, se utilzia como almacén.

Nuevos controladores para mi wirelss Ralink

Hace días que había visto que los del proyecto de controlador para tarjetas inalámbricas basadas en el chip de Ralink habían empezado con una versión con soporte para las tarjetas USB. Igor es la excusa perfecta para probarlos ya que lo pondré enun cuarto lejos del router.

Por el momento sólo tienen la versión del CVS del controlador 2570.

La descargo y descomprimo en /usr/src/modules. El primer intento de compilación falla por que falta el enlace desde /lib/modules/2.6.8-2-686/build hasta las las cabeceras (o las fuentes, que incluyen las cabeceras).

Cargo el móudlo y trato de hacer funcionar la antena. No furula, por que no la he activado, con ifconfig:

ifconfig rausb0 up

Configuro la red wireless pero tengo problemas de conexión a través del interfaz wireless. Cuando desconecto el cable ehternet, dejo de poder comunicarme con Igor, pese a que si pongo el cable ethernet parece que puedo acceder a través del interfaz inalámbrico.

Tras un largo rato de pruebas, Google, lecturas y más pruebas, deduzco que es un problema con la tabla de rutas.

Como ando algo justo de tiempo, toco /etc/network/interfaces para que el interfaz rausb0 sea inicializado primero, de manera que las rutas se configuran para usar ese interfaz como principal. De ésta manera parece que solucion el problema de acceder a través del interfaz inalámbrico, pero si eth0 está activo (que conviene, por falla el wireless y accedo a él por ethernet) no tengo salida a internet.

Veamos las rutas:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 rausb0
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
default         mygateway.ar7   0.0.0.0         UG    0      0        0 eth0
default         mygateway.ar7   0.0.0.0         UG    0      0        0 rausb0

El problema es la tercera línea, que indica que la ruta por defecto es por el interfaz etho0. Pues elimino de la tabla y listo:

route del default dev eth0

Tras varios días en marcha, la antena deja de funcionar. No sé a que se debe, imagino que será un asunto de los controladores que están en desarrollo.

Deberé probar a usar un controlador algo más nuevo, por el momento a Igor hay que reiniciarlo de vez en cuando.

Igor y Sancho, presentación de mis servidores

Igor y Sancho son los dos servidores que he acogido bajo mi seno, administro con cariño y mimo con mis comandos de consola.

Igor es un Pentium II al que tuve que hacer una repración de emergencia a su lector de CDs por que no había manera de que leyese correctamente el CD de instalación por red de Sarge. Lleva una Debian Sarge con kernel oficial 2.6.8, unos cuantos servicios de red y parece que va a sustituir a mi ordenador como servidor de la casa para Internet. En breve será Igor quién se encargue del trabajo duro, como ejecutar el mldonkey todo el día.

Sancho es otro Pentium II localizado en casa mis familiares que aloja una página web con dominio propio, aparte de ser también el encargado hacer el trabajo de servidor de la casa. Lleva también una Debian Sarge con kernel oficial.

Accesibles mediante SSH, ninguno tiene pantalla, los administro remótamente. Por supuesto, están protegidos con contraseñas de calidad, cambiado el puerto del sshd (aunque esta es un protección menor) y autorizados únicamente los usuarios justos.

Rápida introducción a RSA y PGP/GPG

Teoría

RSA es un método de cifrado válido tanto para transmisiones seguras de datos, almacenado de información cifrada y para certificar que la información no ha sido manipulada por terceros.

PGP (Pretty Good Privacy) es el programa, diseñado y desarrollado por Phil Zimmermann en 1991, más conocido que implementaba RSA. El estandar OpenPGP del IETF fue desarrollado basandose en PGP. En el entorno Linux, GnuPG (Gnu Privacy Guard) es la implementación de dicho estándar.

Cada usuario dispone de dos claves, una clave privada y otra clave pública. Dichas claves son generadas por el usuario y nunca se generarán dos parejas de claves iguales. Normalmente cada pareja de claves pública-privada se asocia a una dirección de correo electrónico, aunque no es imprescindible. Mediante éstas claves se pueden realizar las siguientes operaciones:

• Cifrado: La clave pública del usuario permite cifrar los datos de un archivo (o cualquier otro conjunto de datos) de manera que sólo la clave privada es capaz de descifrar la información a su estado original. De ésta manera es posible guardar datos cifrados sólo accesibles por el usuario, ya que será el único poseedor de su clave privada, o enviar datos al usuario a través de un medio inseguro como el correo electrónico de manera que sólo el usuario poseedor de la correspondiente clave privada pueda leerlos correctamente.
• Firma digital: Mediante la clave privada del usuario es posible firmar un conjunto de datos (un correo electrónico, un fichero, etc.). La firma digital es un pequeño anexo de datos a la información original que, mediante el uso de la correspondiente clave pública del usuario, certifica que los dichos datos originales no han sido alterados y que quién los firmó utilizo la clave privada del usuario. De ésta manera es posible que un usuario envíe datos a través de un canal inseguro y se asegure que el contenido es recibido por el destinatario sin haber sido alterado. Si dichos datos son modificados de alguna manera el destinatario será avisado ya que al usar la clave pública del usuario para comprobar la firma digital, ésta no será correcta. Así, también es posible certificar que, por ejemplo, un usuario escribió un mensaje de correo electrónico que después firmó, ya que sólo él podría usar su clave privada para generar una firma válida.
• Firma y cifrado: Es posible combinar ambas acciones, pudiendo así enviar datos a través de un canal inseguro de manera que sólo el destinatario final los pueda leer y se asegure de que dichos datos no han sido alterados.
• Descifrado: Mediante la clave privada de una pareja de claves es posible descifrar los datos codificados usando la clave pública.
• Comprobación de la firma digital: Se verifica, usando la clave pública, que un conjunto de datos no ha sido alterado. La firma digital es añade a los datos originales, pero no forma parte de estos. Cualquier cambio en la firma o en los datos implicará que la firma digital no será válida al comprobarla con la clave pública.

Cada usuario, tras generarse su par de claves, guarda celosamente su clave privada, y comunica abiertamente su clave pública.

Uno de los puntos flacos del sistema es el intercambio de claves. El sistema no dispone de un protocolo para la comunicación de las claves públicas que sea absolutamente inmune a engaños. Sólo es posible asegurarse de que una persona nos ha entregado su llave pública si las conocemos y es ella misma la que personalmente nos entrega la llave pública en un medio de almacenamiento físico que él mismo haya escrito, y aún así podrían hacerle dado el cambiazo. Por ello el usuario ha de asegurarse de que cuando recibe una clave pública, ésta pertenece a quién dice. Dado que las claves son bastante largas, se usa una huella digital o fingerprint, que es un resumen de la clave lo suficientemente largo como para que sea única y lo suficientemente corta como para que pueda ser comunicada mediante medios humanos (por ejemplo, por teléfono o escrita a mano). Así, una vez recibida una clave pública, es posible confirmarla recibiendo del dueño la huella digital, y asegurando que la clave que tenemos corresponde con la huella recibida. Por supuesto, hemos de asegurarnos que dicha huella digital nos la da el dueño de la clave que queremos comprobar, pero al ser la huella digital más corta y más fácil de comunicar, esto resulta más sencillo.

Por otro lado existen los servidores de claves públicas. Son ordenadores que almacenan las claves públicas de los usuarios y algunos datos (huella, correo electrónico del usuario, etc.). Un usuario que quiera hacer pública su clave pública puede subirla a uno de estos servidores. Normalmente los servidores de claves están interconectados de manera que periódicamente se informan de las novedades, por lo que sólo es necesario subir la clave pública a uno de los servidores, que en poco tiempo ésta figurará también en el resto de servidores.

Un usuario puede validar una clave pública de otro usuario firmando ésta con su propia clave privada. De ésta manera afirma o certifica que él confía en dicha clave pública. Así, cuando se inserta una clave pública recibida en gpg, ésta en principio no esta avalada. Si el usuario confía en que ha recibido la clave correctamente, firmará (avalará) dicha clave, indicando a gpg que confía en ella. La única diferencia es que cuando gpg usa una clave no avalada, dará un aviso de que, aunque descifre o valide correctamente firmas digitales, no es de confianza.

Éste sistema de firma de claves permite establecer anillos de confianza. Así, si yo recibo una clave pública firmada por un usuario en el que yo confío, se interpreta que la clave recibida es de confianza. De ésta manera, además de poder confiar en las claves que uno mismo valida, es posible confiar en las claves en las que otros usuarios bien conocidos confían. Por supuesto es responsabilidad de cada uno decidir en quién se confía. Así, es posible subir a un servidor de claves una clave pública de un usuario firmada por otros, de manera que dicha clave pública estará avalada por las firmas de los otros usuarios. Conviene tener en cuenta que aunque un usuario puede coger la clave pública de otro usuario, firmarla y subirla a un servidor de claves normalmente es el dueño de la clave quién decide que otros usuarios la avalarán, por lo que se suele enviar la clave pública firmada por otro usuario a su dueño, y será éste el que decida si sube o no su firma avalada por el otro usuario.

Dado que los servidores de claves no permiten el borrado de las claves que almacenan, ha de existir un método para anular una clave. Dicho anulación puede ser por que la correspondiente clave privada ha sido comprometida (robada o publicada), no va a ser usada más, ha sido sustituida por otra o por la razón que fuere. El usuario ha de generar un certificado de revocación, generado mediante su clave privada, que es enviado el servidor. Notar también que las claves pueden generarse con un período de validez concreto, superado el cuál son revocadas automáticamente. También hay que tener en cuenta que una clave revocada o caducada ya no podrá usarse para cifrar ni para firmar datos así como tampoco podrá emplearse para descifrar los datos codificados durante el período de validez de la clave.

gpg permite crear confianza localmente. Es decir, asignar a las claves públicas recibidas un grado de confianza. El nivel de confianza en una clave se establece una vez ésta ha sido avalada por el usuario (mientras no se firme no se podrá establecer el grado de confianza). Así, si recibo una clave pública avalada por alguno de los usuarios de los que ya tengo su clave pública firmada, gpg asignará a dicha nueva clave la confianza que tenemos en dicho usuario.

Por último mencionar que gpg almacena las claves privadas cifradas mediante una clave (cifrado simétrico: una sola clave permite cifrar y descifrar) que será pedida normalmente cada vez que se quiera hacer uso de la clave privada. Esto hace más difícil el robo claves privadas.

Las fuentes para éste artículo ha sido la web de Antonio Caravantes, concretamente su sección sobre PGP. Es una larga explicación de PGP, muy entendible y que profundiza sobre todo en aspectos prácticos y útiles. Del taller de criptografía de Arturo Quirantes Sierra se puede obtener mucha información de carácter más técnico en su sencillo curso de PGP.

Práctica

Para poner a funcionar un sistema de claves en mi sistema Linux he optado por instalar gpg, KGpg para manejar gpg desde KDE de una manera fácil y sencilla, y los plugins enigmail y enigmime para Thunderbird. En el artículo de Kriptopolis Pinguino en salsa de bits se explica como echarlo a andar.

Yo ya tengo mi par de claves generadas y funcionando sin problemas en Thuderbird, así como en los menús contextuales de KDE para cifrar archivos.

A vueltas con el Router D-Link G604T de Jazztel

Después de un tiempo de sin demasiados problemas, el router módem ADSL inalámbrico D-Link G604T ha decidido aguarme la fiesta.

Hace unas dos semanas dejo de realizar el enlace IP con Jazztel, pese a que conexión en la capa ADSL había. Consultando en el teléfono de resolución de problemas técnicos de Jazztel, me explicaron como hacer un reset del dispositivo más fuerte que simplemente desenchufarlo (como yo había probado varías veces). Consiste en pulsar el botón de reset durante 20 segundos, los 10 primeros con el cacharro encendido, y los 10 últimos habiendo desenchufado al aparato. Por supuesto , se pierde la configuración.

Después de hacer esto, el router volvió a conectar sin problemas. Pero hoy a vuelto a incordiar. Se resetea en un tiempo corto de tiempo, apenas 20 minutos en el caso más extremo, pero es que no es sólo que se reinicie, sino que además pierde toda la configuración, con lo que ni siquiera vuelve a conectar por que le falta la configuración del enlace con Jazztel.

Aparentemente es un problema del mldonkey, según comentan en foros y demás el router no limpia con la suficiente frecuencia sus listas de conexiones, y dado que el mldonkey (como todos los clientes de la red eDonkey) hacen un uso intensivo de las red, éstas acaban desbordándose haciendo reiniciar al router.

Circulaba por Internet un script que cambiada la frecuencia de limpieza de dichas tablas, pero ahora no los encuentro, y además había que ejecutarlos cada vez que se arrancaba el router.

En el FTP de D-Link Italia se puede encontrar el último firmware así como un firmware experimental que se supone soluciona los problemas con los programas P2P, aunque D-Link no se responsabiliza del correcto funcionamiento de dicho firmware.

He comprobado que tengo dicho firmware.

Por otro lado, en Jazztel me comentaron que podría deberse a no tener los puertos del eMule abiertos. La razón me parece bastante surrealista.

Por suerte, he encontrado en el router la manera de salvar y cargar la configuración (pese a que en Jazztel me dijeron que no se podía). No es fácil encontrar la opción; está en Tools, Update Gateway.

Ahora que he encontrado la opción de guardar la configuración el router parece haberse estabilizado, y funciona sin problemas. Vaya usted a saber.

La última sospecha que me queda, y por ausencia de otra coherente parece que va a ser cierta, es que el mldonkey ha debido de tener un fallo. Intentando arrancar a media mañana el mldonkey después de varios cortes seguidos, me daba error con los temporales. Forzando un poco las cosas, he conseguido que los cargue, pero en realidad parecía sólo tener el identificador del archivo, por que todos estaban al 0% de completados, cuando muchos iban por más de la mitad. He borrado finalmente todos los temporales, sin molestarme en buscar una manera de recuperarlos. Creo que no tenía gran cosa.

Así, sospecho que algún problema con los temporales hacía al mldonkey desbordar las tablas de conexiones de mi router en breves minutos. Eliminados los temporales, eliminado el problema.

Veremos a ver si aguanta el día entero...

Actualización:
Una semana después parece que el router sigue sin dar problemas. ¡Óle!

Las fuentes del kernel y su parches en kernel.org

He estado mirando kernel.org, y decidido clarificar un poco como se organizan actualmente las versiones del kernel en desarrollo y los parches.

Así, tenemos la versión oficial o estable del kernel, sobre la que se pueden aplicar un serie de parches oficiales que "transforman" el kernel a una versión más experimental. Los diferentes tipos de parches, sobre qué aplicarlos y qué momento del desarrollo represetan puede entenderse a través de la siguiente explicación:

• Prepatches: Son básicamente versiones alfa de Linux. Se deben aplicar, mediante patch, a las fuentes con versión de 3 números, es decir, el preparche 2.6.12-rc4 deberá ser aplicado a las fuentes 2.6.11, no, por ejemplo, a la versión 2.6.11.10. Los preparches que contienen rc en su nombre se consideran versiones candidatas y prodrán llegar a ser la nueva vesión (esto es importante por que es conveniente que estén muy probadas).
• Snapshots: Son las fuentes actualmente en desarrollo, tomadas directamente de los repositorios de los desarrolladores. Son generados atuomáticamente sin ninguna supervisión humana, por lo que es probable que contengan errores o incluso que ni siquiera compilen en un momento dado. Usando patch, la obtención del snapshot 2.6.1-rc1-git5 se haría aplicando a las fuentes 2.6.0 el parche 2.6.1-rc1 seguido del parche 2.6.1-rc1-git5.
• -ac patches: Son parches pertenecientes a Alan Cox sobre las versiones oficiales del kernel. Habitualmente son más experimentales que la serie oficial.
• -mm patches: Son parches pertenecientes a Andrew Morton sobre las versiones oficiales del kernel. Al igual que los de Alan Cox, suelen ser más experimantales que la serie oficial.