Debian Jessie: Deshabilitar startpar

Una de las nuevas características de Debian Jessie es el uso del sistema de arranque systemd. Uno de los objetivos de systemd es > es paralelizar al máximo el arranque del sistema para que este sea lo más rápido posible¹. Systemd es un conjunto de programas exclusivos de Linux ya que usan ciertas llamadas al sistema que sólo están disponibles en él.

La existencia de systemd no elimina la necesidad de scripts da arranque, ya sea de programas heredados o bien porque hay programas que prefieren usar estos scripts de arranque que facilitan la portabilidad entre sistemas Unix. En Jessie, los scripts de arranque siguen estando en /etc/init.d y el concepto de runlevels sigue existiendo, sólo que ahora lo maneja systemd. Para ejecutar de manera simultánea varios scripts de arranque existe la utilidad startpar. Se supone que los scripts se han escrito de acuerdo a las Linux Standard Base para que puedan declarase las dependencias de manera correcta y startpar pueda ejecutar los mismos paralelizando al máximo y sin problemas de interdepencias entre ellos.

Sin embargo, esto no siempre es así y puede que en un momento dado sea necesario desactivar esta capacidad de arranque en paralelo para corregir problemas que se presenten en el sistema. En Debian es muy fácil realizar desactivarlo creando un fichero:

touch /etc/init.d/.legacy-bootordering

Para volver a disponer del arranque en paralelo de los diferentes scripts, simplemente borramos el fichero anterior

rm /etc/init.d/.legacy-bootordering

Notas

1. Una pequeña maldad: ¿De verdad la gente apaga y enciende el sistema, en especial portátiles y sistema de escritorio o simplemente lo hiberna?.

Debian: Problemas al arrancar un daemon desde el postint de un paquete

Hace unos días nos encontramos un curioso problema en un paquete Debian de construcción propia: Por alguna razón que desconocíamos en ese momento ,el script postint de un paquete debian, no terminaba la ejecución, convirtiéndose en un proceso zombie, que dejaba al proceso que lo lanzó esperando indefinidamente la finalización del mismo. Como el proceso que lanza estos paquetes es el debconf, encargado de la instalación de paquetes, ésta nunca finalizaba de manera correcta.

Tras buscar bastante, dimos con el problema: hay ciertos programas que no pasan a segundo plano de manera correcta y dejan descriptores de ficheros abierto contra debconf, que es el programa encargado de realizar las instalaciones y configuraciones de paquetes en sistemas basados en Debian. Esto sólo ocurre si desde el postint intentamos arrancar algún tipo de proceso que debe ser un daemon.

Para evitar este problema, Debian provee un script, que puede llamarse desde nuestro fichero postint: Antes de terminar la ejecución del fichero postint, se debe de añadir la llamada db_stop al final del mismo (o bien en aquellos puntos donde se finalice la ejecución). De esta manera, se soluciona el problema del cuelgue de la instalación de paquetes que arrancan daemons que no cierran bien los descriptores de ficheros.

---

Controlar la generación de paquetes Debian a través de DEB_BUILD_OPTIONS

Las opciones de construcción de paquetes Debian a través dpkg-buildpackage pueden controlarse con la variable de entorno DEB_BUILD_OPTIONS. Algunos de los posibles cambios son no ejecución de los tests, desactivar las optimizaciones o no quitar la onformación de depuración de los binarios. Pueden combinarse los diferentes valores para compilar el paquete de acuerdo con las necesidades que se tengan. Las posibles opciones de la variable son las siguientes:

• nocheck El sistema de paquetes no ejecuta los posibles tests que puede tener el paquete (si el paquete usa las autotools para generarse normalmente esto equivale a no hacer el make check)
• noopt Desactiva las optimizaciones, explícitamente pasa los flags -O0 -g al compilador (que como suele ser el gcc implica desactivar la optimización y activar la generación de los símbolos de depuración).
• nohardening Desactiva las opciones que permiten introducir mecanismos en los binarios para prevenir la explotación de fallos de seguridad en los mismos (si se tiene instalado los paquetes para ello en Debian). Se puede ver más sobre en el wiki de Debian en Hardening.
• nodocs No construye los paquetes de documentación.
• nostrip La información de depuración no debe quitarse de los binarios generados durante la instalación.
• parallel=n Si el paquete permite la construcción en paralelo, usar hasta n procesos.

Referencias

• Avoiding tests when building Debian packages
• Debian Policy Manual Chapter 4 - Source packages

---

Technorati Tags: Debian,deb

Algunas notas más de Debian Etch

Siguiendo con la configuración del sistema Debian que utilizo de server en casa, y aquí van algunas notas de cosas que he usado.

En primer lugar el soporte de wpa está implementado en el paquete wpasupplicant, e integrado sin ningún problemas en el /etc/network/interfaces. Así usar una simple clave wpa-psk se hace de la siguiente manera:

iface ath0 inet static
        address 192.168.1.2
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255
        gateway 192.168.1.1
        wpa-driver madwifi
        wpa-ssid  wifi
        wpa-psk clave-de-accesop

En este caso especifico el driver (madwifi), aunque lo normal es poder usar las extensiones wireless del kernel (wext).

Al cambiar la libc, algunos programas compilados me dan advertencias (mldonkey), con lo cual tengo que recompilarlos de nuevos (supongo que con el soportte ocaml). Por otra parte hay paquetes con versiones mucho más antiguas que la actual (por ejemplo snort, que es la 2.3.3, frente a la versión actual 2.6.x, y en beta la 2.7), pero eso es endémico de las Debian.La versión de qmail y las deamontools que tengo compilada con la versión antigua de Debian funcionan sin ningún tipo de problemas tampoco.

Poco más de las notas de mi actualización :)

Technorati Tags: debian, linux

Debian, kernels,madwifi . Notas varias

Normalmente, al usar Debian en un update, no actualiza el kernel y deja la máquina con la versión que estás usando. Ayer, tras actualizar Debian Woody a Etch, decidí actualizar su 2.4.30 el último de la serie 2.6.20.6. En principio, quería usar por pereza (y por no pasarme 5 horas compilando un kernel en un K6-2 a 450 Mhz) usar la imagen 2.6.18 que trae la distribución. El problema es que esta imagen oficial no trae soporte para la wifi Atheros, el driver madwifi. Total, después de ver la documentación en Debian, me animé a usar el module-assistan, una serie de scripts para poder instalar módulos desde fuentes, que no están incluido en Debian por diversos motivos. El principal que estaba con un 2.4.x, pero necesitaba compilar para el 2.6.x e instalar antes de reiniciar, puesto que dicha máquina no tiene ni teclado ni monitor y la administro en remoto a través de la wifi.

No me salió demasiado bien la jugada, así que decidí tirar por el modelo clásico de Linux: bajarme un kernel, configurarlo, compilarlo (o sea 5 horas en esta máquina), meter el módulo de madwifi, compilarlo e instalarlo, en remoto. Así:

# cd linux-2.6.20.6 # make menuconfig # make bzImage # make modules # make modules-install # cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.20.6 # cp System.map /boot/vmlinuz-2.6.20.6 # cp .config /boot/config-2.6.20.6 # cd .. # cd madwifi-0.9.3 # make KERNELSOURCE=/usr/src/linux-2.6.20.6 # make KERNELRELEASE=2.6.20 # cd / # update-initramfs -k 2.6.20.6 -c # rm vmlinuz # ln -s /boot/vmlinuz-2.6.20.6 vmlinuz # rm initrd.img # ln -s /boot/initrd.img-2.6.20.6 initrd.img # /sbin/lilo -v

El único paso importante en este caso es no olvidar hacer el initrd.img. Hay que asegurarse que la entrada correspondiente en el lilo.conf al kernel que estamos usando tiene el parámetro initrd=/initrd.img, ya que sino, lo más probable es que el kernel no arranque al faltarle algún módulo básico (ext3 por ejemplo)

Podría usar el make-kpkg que tiene Debian para hacer un paquete de kernel propio, pero al final, siempre me resulta más cómodo terminar haciendo la instalación manual.

Technorati Tags: linux, debian

Debian Etch, 64 bits y ossim

Acaba de salir la nueva versión de Debian Stable, Etch. Puesto que tengo acceso a un PowerEdge 1950 con dos Xeon que tienen las extensiones AMD 64 (Intel las llama EMT64T), me ha dado por probar que tal la instalación del sistema. Usando el disco de Netinstall de Debian, no ha habido ningún problema para instalar el sistema base.

Luego, he decido probar la compilación de ossim para la plataforma AMD64, utilizando las fuentes del cvs, en especial por la parte del server. Se ha compilado sin problemas y creado los paquetes .deb correspondientes. Ahora espero poder poner el server a funcionar y ver que tal reacciona. Al usar como plataforma de portabilidad la librería glib, no deberían existir problemas por el tamaño de los punteros ni nada por el estilo (he seguido estas instrucciones de instalación en el wiki de Ossim).

Los paquetes que genera ossim para Debian son los siguientes:

Fichero	Descripción
ossim_0.9.9~rc4-3_amd64.deb	Metapaquete para que instale el resto de los paquetes de ossim
ossim-agent_0.9.9~rc4-3_amd64.deb	Agente de OSSIM. Este programa permite recopilar los datos desde los diferentes sensores (snort, p0f, arpwatch,...) eventos para enviárselos al server para su posterior correlación y proceso.
ossim-contrib_0.9.9~rc4-3_amd64.deb	Diverso parches para herramientas y ejemplos de configuración para ossim, útil para desarrolladores.
ossim-framework_0.9.9~rc4-3_amd64.deb	Frontend web para ossim.
ossim-framework-daemon_0.9.9~rc4-3_amd64.deb	Daemon encargado de actualizar los ficheros de datos del frameworks (ficheros rrd, gráficas)
ossim-mysql_0.9.9~rc4-3_amd64.deb	Scripts para realizar la carga de datos necesarios para el funcionamiento de OSSIM
ossim-server_0.9.9~rc4-3_amd64.deb	Servidor de correlación de eventos de OSSIM.
ossim-utils_0.9.9~rc4-3_amd64.deb	Scripts en Perl para el manejo de diversos aspectos de OSSIM

Tengo ganas de probar ossim sobre CentOS puesto que es una distribución que conozco más. A ver si tengo algo de tiempo, y genero los .spec para poder generar los paquetes adecuadamente.

Technorati Tags: amd, intel, linux