El discreto diario de Laz

Kernel Workshop

laz — 2012-05-20T15:04Z

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.

Versionitis

laz — 2011-06-16T17:16Z

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�.

[Chuleta] Montones de documentos interesantes.

laz — 2011-04-08T20:36Z

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

Apuntado queda

Cambio de hardware de este humilde servidor. Me refiero al ordenador. :-)

laz — 2011-04-07T20:29Z

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.

Un poco de TV

laz — 2010-12-19T12:36Z

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.

[Recordatorio]

laz — 2010-11-24T20:14Z

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

Higiene en servidores.

laz — 2010-11-23T07:52Z

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

[Otra de TBBT] Glorioso PINE

laz — 2010-11-23T07:36Z

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:

El poder�o de los 4 cores

laz — 2010-10-07T16:07Z

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 :-)

[Frikada nivel 10]

laz — 2010-08-26T07:30Z

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.