Tras un largo periodo de sequía y falta de novedades importantes, al fín pasó algo digno de contar en el discreto diario: la primera compilación correcta y funcional de un kernel (concretamente un 3.3.6) que hago desde hace... ni me acuerdo.

¿Cuál era el problema? Desde que se impuso el SATA como interfaz principal en los dispositivos de almacenamiento masivo (discos duros/DVD/CD) no conseguía construir un kernel que me reconociera correctamente el disco duro que contiene el sistema operativo en el arranque. Puedo recordar el proceso de arranque de linux en brevísimos pasos:

• Arranca el ordenador, se lee la BIOS y el primer sector (MBR) del dispositivo de arranque.
• En la actualidad, si usamos un Linux modernillo, se ejecuta GRuB (o LiLo para los más veteranos)
• Estos gestores de arranque cargan un kernel en memoria, lo ejecutan con ciertos parámetros y por tanto le ceden el control
• El kernel reconoce los dispositivos básicos -entre ellos donde está el sistema operativo-, lo monta, haciéndolo accesible y ejecuta el proceso de PID 0 o 1, llamado init

El problema estaba en que los kernels que construía no reconocían, o lo hacían mal, el disco duro SATA donde está el S.O., y se paraba con un bonito error, que viene a decir "no puedo montar el sistema de archivos root, no leo nada, ni init ni ná... hasta aquí llegamos y no puedo pasar". Batacazo.
A cuenta de esto, hay dos grandes métodos de construir el kernel: con o sin ramdisk. Recordemos que actualmente los kernels linux son modulares, es decir, se carga una pequeña parte de los drivers (por seguir una nomenclatura guindosera) en el nucleo, y el resto se cargan dinámicamente (o sea, cuando sean necesarios, para no gastar RAM ni recursos en cosas innecesarias) desde pedazitos de código llamados módulos.
Si tenemos un sistema de ramdisk para arrancar (el más habitual para los linux actuales, léase Ubuntu, Debian, CentOS....), el kernel arranca, genera un ramdisk (o sea un disco virtual en memoria RAM) y descomprime allí un fichero con los módulos, que se suele llamar initrd. Este tema ya lo traté por aquí.
Pero no sé lo que pasa, que no me funcionaba correctamente, por lo que decidí probar con un kernel un poco más monolítico, o sea, incorporar en el propio kernel el soporte de hardware para SATA, pasando del initrd y del ramdisk. Para ello la compilación se hace un poco más pesada, ya que hay que fijarse (yo uso el make menuconfig para configurar la compilación) muy bien en lo que se marca para compilar en el kernel o en los módulos.
La gran pega de todo esto de compilar el kernel es que, si falla (y lo hizo muchas veces) el ordenador se queda colgado, hay que resetear, arrancar con un kernel funcional (por suerte el GrUB o LiLo nos permite tener varios kernels para arrancar), repasar la configuración y recompilar. Por suerte, el Core2Quad se "come" la compilación con bastante brío :-)
Entonces opté por otro experimento: una máquina virtual VirtualBox que sería mucho más cómoda de re/arrancar, modificar, cambiar, etc, etc.
Tras varios intentos en el KernelKrucher, ¡éxito!. Tras recompilar jugando con varias opciones del SATA/SCSI/PATA/AHCI y no sé cuantas siglas más, tenemos un kernel operativo, tanto en la máquina virtual como en la real:


Y por cierto, todo funcionando, el audio, la VGA, la tarjeta DVB-T, la red, el VirtualBox. En módulos, claro :-)
Tenemos por aquí el fichero ".config" de configuración de la compilación, para salvaguardarlo y para lo que haga falta :-)
Aquí lo tenemos en formato bonito para la web y en formato original.

Disclaimer: Todo lo que cuento aquí tiene mucho de opinión y experiencia personal. Nada serio. 100% chapuza. 0% académico.

Cuánto hacía que no me pasaba nada "raro" en el mundo "linux".
Pero en el curro llevo una temporadita "adoctrinando" a los compañeros sobre las ventajas de tener un mini-linux en los portátiles para analizar fácil y rápidamente el tráfico ethernet taggeado de productos como macro/metro/cobreLAN. Cosas de las VLANs.

Así que ahí estaba yo, con mi Debian en consola pura, blanco sobre negro, y la línea de comandos de bash, mostrando lo fácil que resulta el uso de vconfig y la sencillez de tcpdump para esnifar tráfico. Y con mi tcpdump salía el tráfico capturado perfectamente "marcado" con su vlan, como en este ejemplo:

XX:XX:36.782970 vlan 586 IP (tos 0x10, ttl 64, id 30506, offset 0, flags [DF], proto TCP (6), length 52)............

Tras la prueba, convincente al 100%, nos pusimos manos a la obra e instalé una Debian minimalista, sólo con consola, pero con todos los extras usados. Lo ponemos a prueba y:

XX:XX:36.782970 IP (tos 0x10, ttl 64, id 30506, offset 0, flags [DF], proto TCP (6), length 52)............

Y la parte VLAN desaparece como por arte de magia. Evidentemente eso no era lo pactado, y comencé a investigar:

No era el hardware. En mi portátil, tanto la ethernet integrada (una broadcom gigabit vulgaris), como algún otro interface PCMCIA o USB ethernet, captura el tráfico con la VLAN.

No es el kernel. Copio mi kernel y mis módulos al ordenador de destino y lo mismo.

No es ningún tipo de firmware después de comparar los directorios /lib/firmware.

Y al final era la versión SUPERIOR del tcpdump. El que funciona bien es el tcpdump version 3.9.8. En cambio la versión 4.1.1 no hace lo esperado. No hay problema con las librerias (sobre todo libpcap) ya que son de una versión superior.
Cambiados los binarios, todo OK.

Moralejilla: No hay que fiarse de que las versiones superiores sean mejores. Ya sé que es lógico, pero en este caso fué lo primero que ví y lo último de lo que sospeché.

Buscando cómo mejorar y asegurar el servidor ssh, encuentro este sitio [calomel.org] con un montón de documentación interesante....

Apuntado queda

Bueno, el miedo a la rotura del disco duro, que llevaba ya unos 10 años girando (tenía backup, que conste) me ha llevado a poner un nuevo servidor.
Aunque el primer artículo de este humilde lugar data de Diciembre de 2002, el pobrecito servidor lleva un poco más "en pié".
Hoy ha sido apagado y preventivamente guardado sin tocar hasta que el nuevo monstruo -en comparación- demuestre su valía. Esperemos que dure otro tanto. :-)

Una breve comparación del antiguo y el nuevo:

CPU: antes, Pentium III, desde 733MHz a 866Mhz. Ahora, Pentium E5700 DualCore.

RAM: antes, 512Mb SDRAM. Ahora 2GB DDR3 1333.

Disco duro: antes, 200Gb IDE UDMA5. Ahora 250Gb SATA-II (creo).

Red: Antes: 2x100mpbs 3COM ethernet, 1x1Gbps Intel. Ahora, 3x1Gbps, una Atheros, una Realtek y una Via Velocity.

Una mejora de nada :-)

In memoriam:uptimes de > 350 días... a ver si vuelven.

Aunque el doblaje a veces asombra (¿servidores madre? y alguna otra joya), esta serie de cuatro documentales de la BBC, La Revolución Virtual me ha dejado buen sabor de boca.

Son casi cuatro horas de documental con Aleksandra Krotoski (¡ay omá qué rica!) sobre las influencias sociales de Internet y cosas así.
Al principio parece un poco rollete, pero presenta pruebas, documentos y testigos sobre todo aquello de lo que algunos sospechamos hace tiempo: que la Red es imparable y que hay que cuidar la privacidad y hacer un uso responsable e inteligente.

Se pueden encontrar en tu burrito favorito, en tu tracker favorito o por otros lares.

Tengo que mirarme la parte de seguridad, la séptima.

Recientemente se han detectado unos cuantos ataques a servidores linux. Bueno, de hecho se produjeron intrusiones hace bastante tiempo, buscando vulnerabilidades sobre todo de PHP vía Apache, convirtiendo algunos servidores en zombies que se comunican con sus controladores, generalmente, vía IRC.
Una vez dentro, las maniobras de ocultación varían, pero basicamente se reducen a instalar bouncers, programas o scripts de spam intensivo.
Estas maniobras de ocultación se basan en varios conceptos:

• Directorios camuflados, por ejemplo ". " o ".,"
• crontabs de usuarios hackeados por su password débil.
• Directorios temporales
• Y relacionada con lo anterior, directorios sticky

Para ello he hecho un script cutre y muy mejorable que al menos nos informará de que existen cosas raras en muestro sistema:

#!/bin/sh
echo "Buscando directorios camuflados: "
/usr/bin/find / -name ". *" # Directorios camuflados con espacios
/usr/bin/find / -name ".*,*" # Directorios camuflados con comas
echo "Buscando crontabs rarunos: "
/usr/bin/find /var/spool/cron/
echo "Buscando directorios temporales: "
/usr/bin/find / -name tmp -type d
echo "Buscando directorios con sticky: "
/usr/bin/find / -mount -perm 1777 -type d

De nuevo frikada de TBBT:
En el episodio 9 de la temporada 3, Raj controla desde Pasadena el telescopio de Hawaii. Esos controles incluyen ordenadores con Linux y el magnífico cliente de correo PINE (se nota que lo uso yo...desde, no sé, 1994).
La prueba gráfica:

Experimento realizado con:

Fuentes del kernel 2.6.35.7 (último estable de la fecha actual)

CPU Intel(R) Core(TM)2 Quad CPU Q9300@2.50GHz

CPU:~/usr/src/linux# time make -j1
[mucho rollo del GCC]
real    24m24.584s
user    22m47.321s
sys     1m24.393s

CPU:~/usr/src/linux# time make -j4
[mucho rollo del GCC]
real    7m16.786s
user    23m31.080s
sys     1m41.410s

CPU:~/usr/src/linux# time make -j8
[y de nuevo el rollo del GCC]
real    7m8.328s
user    23m50.641s
sys     1m41.950s

¡Vaya! enviar un make con 4 trabajos o jobs simultáneos, implica un ahorro de 17 minutos más o menos de trabajosa compilación.
Bueno es saberlo.
Y también que incrementar el número de jobs a 8 no supone ninguna mejora.
Otra vez habrá que probar con algún Xeon Quad de esos con HyperThreading (que son reconocidos por el kernel como 8 cores) a ver si mejora algo.

Evidentemente ambas pruebas han sido realizadas con la misma configuración (copiando el .config, para los curiosos) de compilación de kernel, tras un make mrproper y con la misma carga exterior (ver un video ,concretamente el episodio 2 de la temporada 3 de Fringe :-)

Acerca de Inception (La película titulada aquí Origen), se puede leer en un tweet:

The main idea of "Inception": if you run a VM inside a VM inside a VM inside a VM, everything will be very slow

En cristiano: "si ejecutas una máquina virtual dentro de una máquina virtual dentro de una máquina virtual, todo será muyyy lento."
Gran verdad. Leído en Meneame, que conste.