Vulnerabilidad crítica en Debian

URGENTE: En principio cualquier responsable de un sistema Debian a estas horas ya deberia ser consciente de este problema, pero por si acaso atención a este problema:

Debilidad criptográfica en los paquetes openssl de Debian [Barrapunto]

Rsync 3 bajo Windows

Como ya sabéis los que hayáis leido posts anteriores de este blog utilizo mucho rsync para realizar copias de seguridad de manera remota a través de Internet (y también red local, por qué no) dado su alta eficiencia. Normalmente dichas copias de seguridad las realizo entre equipos corriendo sobre una versión u otra de Linux y todo funciona de maravilla. Sin embargo un par de las copias que hago son de estaciones de trabajo Windows utilizando el mismo rsync como servicio que incluye el paquete backuppc.

El problema viene con la gestión de los juegos de carácteres de los nombres de los ficheros. Al hacer la copia entre un Windows (cp1252) y un Linux (UTF-8 en mi caso) los nombres de los ficheros se corrompen. El contenido por supuesto siempre es tratado de manera binaria y por tanto es perfectamente correcto. Como tampoco había ninguna solución durante este tiempo simplemente me he "aguantado" y si tenia que recuperar algo pues lo hacía con los nombres mal (aunque yo personalmente nunca utilizo carácteres fuera del ascii básico precisamente por este tipo de cosas).

Recientemente el grupo de trabajo de Samba ha sacado la versión 3 de rsync que incorpora jugosas novedades entre las que destaca (en este caso) el soporte de la libreria iconv para convertir los nombres de ficheros entre juegos de carácteres. Así que me he armado de valor para intentar compilar e instalar como servicio Windows un software diseñado para Linux.

Ha resultado ser sorprendentemente fácil. Con cygwin por supuesto. Primero he eliminado el anterior servicio rsyncd basado en el paquete que viene con backuppc. He instalado cygwin junto con algunos paquetes extras necesarios para compilar el paquete (gcc, libiconv, make, cygrunsrv). He descargado, compilado e instalado el paquete rsync que ha funcionado de manera sorprendentemente fluida y sin errores (para ser un entorno un poco "delicado" como cygwin). Lo he instalado como servicio mediante la utilidad cygrunsrv y finalmente he conseguido sincronizar los datos para la copia de seguridad contra un Debian Lenny (testing) ejecutando rsync 3.0.0 y manteniendo correctamente todas las eñes, vocales acentuadas y demás engendros diabólicos.

Comentar tan sólo algunos problemas encontrados:

• Hay que ir con cuidado al compilar rsync 3 porque realmente no requiere la libreria libiconv pero si no la encuentra simplemente lo compila sin soporte para esa característica.
• Quizás es un problema de cygwin o de la versión de rsync 3 o simplemente de compatibilidad con Windows pero la configuración por defecto del rsyncd que incluye un fichero pid donde almacena el identificador del proceso del daemon no me funciona. Al cerrar el equipo no borra el fichero y al siguiente arranque el servicio no arranca alegando que ya existe el fichero. Quitando la opción para que no utilice el fichero lo soluciona.
• La versión 3.0.0 de rsync tiene un bug que impide en ciertos casos que se transfiera correctamente el nombre de un fichero deteniendo toda la transferencia. En la versión 3.0.1 ya está corregida. Yo mismo detecté el error y lo transmití a la lista de distribución de rsync donde, de manera muy rápida y eficiente, Wayne Davison corrigió el error. Desde aquí (aunque no lo vaya a leer), gracias Wayne!
  

Configuraciones RAID y LVM en Debian Linux

Hoy tengo una nueva batallita que contaros sobre configuraciones RAID y LVM en un Debian Lenny (testing). Ya tocaba porque hacia bastante que funcionaba sin ningún problema y eso "no puede ser normal".

Bromas aparte os recuerdo un poco como está configurada esta máquina:

El servidor incorpora 5 discos duros bastante variados: 1 de 300 GB, 2 de 320 GB y 2 de 500 GB.

El motivo de esta variedad es porque a medida que van fallando o puedo ir ampliando discos los voy sustituyendo por otros de mayor capacidad lo que me permite ir aumentando la capacidad disponible, sobre todo teniendo en cuenta que sobre el software RAID utilizao LVM para gestionar particiones.

El problema me lo he encontrado ahora que he reiniciado la máquina, pero se generó hace ya semanas con un cambio que realicé (y para el que no reinicié en su momento ya que no era necesario).

Antes de ese cambio tenia dos unidades software RAID, md0 y md1. La primera es un simple RAID 1 para /boot sobre 3 dispositivos. El segundo es más interesante, un RAID 5 sobre 5 particiones de cada uno de los discos.

El cambio fue sustituir 2 discos de 320 GB por los actuales 2 de 500 GB y para ir aprovechando el espacio (hasta que pueda disponer de todos en 500GB) utilizaré el espacio sobrante de los de 500GB para crear un RAID 1 de dos particiones.

Bueno, nada más facil. Creé el RAID con mdadm, lo convertí en unidad física LVM con pvcreate y lo añadí a un grupo existente (vg0). Todo funcionaba correctamente hasta que hoy he reiniciado la máquina y me he encontrado que no arranca quejándose de que no puede montar la partición raiz (y unas lineas más arriba el LVM se queja que le falta un dispositivo).

El problema está en que si bien LVM si que hace un escaneo total de todas las particiones y busca las unidades y dispositivos físicos, el software raid se basa en el fichero /etc/mdadm/mdadm.conf para construir los arrays aunque los pueda detectar automáticamente. El problema es que el arranque del Debian me deja un mínimo sistema (busybox) en el que no dispongo del LVM aunque si del mdadm.

Lo siguiente es arrancar con un CD (en este caso tras un kubuntu que no lleva mdadm ni lvm y un debian-installer antiguo que no me reconoce una controladora SATA PCI-Express) acabo consiguiendo arrancar con una imagen nueva del Debian-Installer para testing. Con eso consigo entrar por linea de comandos, construir la unidad y el lvm y acceder a mi /etc.

Una vez en /etc puedo ya editar el mdadm.conf y poner el nuevo array. Grabo fichero, rearranco, y sigue igual. ¡Claro! El mdadm.conf es una de las partes que se copian en la imagen de arranque en memoria (el llamado initramfs). Así que además de modificar el mdadm.conf tengo que actualizar ese initramfs.

Así que vuelta a arrancar con el CD, monto de nuevo la partición raiz y el /var que también necesito, y ejecuto update-initramfs -ut para actualizar la última versión del kernel. De momento no los actualizo todos para probar... no sea el caso que rompamos algo.

Reinicio para probar y arranco con el último kernel. Y ahora si, todo perfecto (aunque con tanto ir y venir el RAID se ha quejado y está reconstruyendo la unidad).

Así que la moraleja de hoy es: si añades un array con mdadm y quieres tenerlo disponible al arrancar, recuerda ejecutar update-initramfs.

Blog de empresa

Bueno, habréis visto que llevo una buena temporada sin escribir. Resulta que estamos a tope de trabajo (por cierto, buscamos gente) y además estamos preparando una remodelación total de la web de la empresa. Como parte de la remodelación hemos creado un blog de empresa donde todos los de TICOP iremos escribiendo.

Los temas que considere especialmente interesantes técnicamente intentaré recordar de poner una referencia aquí por si alguien lo encuentra de utilidad.

Avances en factorización entera, o ¿el principio del fin de mucha criptografia actual?

Perdonad el título pero me llevan los titulares morbosos. A través del nuevo microblog c Microsiervos leo en Kriptópolis un interesantístimo artículo de Fernando Acero sobre Avances en factorización entera.

Al parecer el Dr Hugo Scolnik está perfeccionando un método matemático para factorizar un número primo en un tiempo casi polinómico (aquí habria que entrar en detalles más técnicos para ver hasta que punto es rápido el método). El artículo es bastante técnico, pero da una idea clara de por donde se mueve y sobre todo asusta un poco atisbar el principio del fin del algoritmo RSA2048 que se usa en, por ejemplo, el e-dni que ahora nos estan implantando.