X.Org

Resumen

Un monitor ViewSonic VG2021wm y una placa de video nVidia GeForce 6500 dejan de entenderse espontáneamente en Linux Mint y el Xorg pasa a funcionar sólo en modo 640×480. ¿La solución? Deshabilitar el uso de EDID y configurar manualmente los datos del monitor en el xorg.conf.

Desarrollo

Ayer me sucedió algo muy raro. Hace varios meses vengo usando Linux Mint sin mayores inconvenientes en mi máqunia. Cuando ayer fui a encender la máquina (sin que mediara ningún cambio extraño, ningún update de los drivers de la placa de video ni ninguna instalación de software), el X iniciaba sesión solamente en resolución 640×480. Teniendo un monitor de 20″, cuya resolución óptima es de 1680×1050, se darán cuenta que la imagen era espantosa: no entraba nada en la pantalla.

Después de varias horas sin entender bien cuál era el problema, postear en el foro de Linux Mint sin respuesta, y buscar en Internet, me puse a revisar los logs del X y encontré que mencionaba errores para leer el EDID. Por ejemplo:

Unable to get display device CRT-0's EDID; cannot compute DPI

¿Qué es el EDID? Extended display identification data, es una estructura de datos que ofrecen los dispositivos de visualización (ej.: los monitores) y que permiten, por ejemplo, a una placa de video conocer sus cualidades. De esta manera, la operatoria normal habría sido que mi placa de video obtuviera los datos del monitor de su EDID y conforme a ello me diera las opciones adecuadas para configurar mi pantalla. Más concretamente, el Xorg lo que hace es obtener a través de la placa de video, entre otros datos, la frecuencia horizontal (HorizSync) y la tasa de refresco vertical (VertRefresh) (para más información sobre qué es cada una de estas variables, pueden consultar esta página).

La cuestión es que de buenas a primeras, el Xorg dejó de poder leer el EDID de mi monitor y por eso levantaba con los datos default para un monitor CRT (por cierto, entre las cosas que aprendí ayer, el driver de nVidia le pone de nombre “CRT” a cualquier dispositivo que se conecte al puerto VGA, no tiene nada que ver con lo que efectivamente esté conectado). Eso quiere decir que tomaba un HorizSync y un VertRefresh que solamente eran compatibles con una resolución de 640×480@50 Hz.

¿Por qué pasa esto? La verdad, no lo sé a ciencia cierta. Encontré a este usuario que le pasó lo mismo, y levantando de un Live CD se dio cuenta que no era un problema de configuración, entonces lo resolvió cambiando su cable DVI por un cable VGA con un adaptador. Yo comprobé lo mismo, el problema no estaba en la configuración de mi Xorg, pero como yo sólo tenía cable VGA, probé cambiandolo por otro cable VGA, pero no hizo diferencia. Entonces seguí buscando y llegué a este otro post donde alguien lo resolvió sencillamente cambiando los HorizSync y VertRefresh en el xorg.conf.

Me bajé el manual de mi monitor (ViewSonic VG2021wm) y busqué los datos correspondientes (HorizSync y VertRefresh), y los puse en el xorg.conf. Este tipo de configuración manual del Xorg es lo que viene a evitar el EDID. El tema es que al reinicar el X, el Xorg seguía intentando leer el EDID y como no podía, seguía dando el mismo problema.

Finalmente, y casi por casualidad, me di cuenta que el nvidia-xconfig tenía unos parámetros para que configurara el xorg.conf indicándole al Xorg ignorar el EDID. Entonces ejecuté el siguiente comando:

sudo nvidia-xconfig --no-use-edid --no-use-edid-dpi --no-use-edid-freqs --mode=1680x1050

Y con eso me quedó generado el siguiente xorg.conf

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig:  version 280.13  (pbuilder@cake)  Mon Aug  8 15:37:15 UTC 2011

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
EndSection

Section "Files"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/psaux"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
EndSection

Section "Monitor"

    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "LCD-1"
    HorizSync 24.0 - 82.0
    VertRefresh 50.0 - 85.0
    Option         "DPMS"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
EndSection
Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option "UseEdidFreqs" "False"
    Option "UseEdid" "False"
    Option "UseEdidDpi" "False"
    SubSection     "Display"
        Depth       24
        Modes      "1680x1050" "1680x1050_60.00"
    EndSubSection
EndSection

Si ven los parámetros resaltados, en la sección Monitor defino el HorizSync y el VertRefresh. Y luego en la sección Screen, los parámetros que evitan que se use el EDID (anteriormente existía una opción IgnoreEDID que fue deprecada, ver los comentarios de este artículo).

Una vez modificado el xorg.conf solamente tuve que reiniciar el X y volvió a la normalidad. Después tuve que pelearme un rato con GDM para volver a configurar la resolución adecuada (1680×1050@60 Hz) utilizando nvidia-settings. Pero esto puede tener que ver con todas las vueltas que dí antes de encontrar la solución.

Uno de los documentos más completos y más leídos por los Administradores de Redes cuando se habla de Calidad de Servicio (QoS) en los sistemas conectados.

Este interesante documento pretende descubrir a fondo herramientas que perteneces a la poderosa infraestructura iproute2, sustituyendo antiguos comandos tales como route e ifconfig.

Actualmente el documento “Enrutamiento Avanzado y Control de Tráfico en Linux” se encuentra en 8 idiomas totalmente traducidos, con diversos ejemplos para dominar por completo la administración de recursos de los sistemas.

Enlaces

• Sitio web de Linux Advanced Routing & Traffic Control (LARTC)
• Última versión del libro en inglés (PDF)
• Versión en español (PDF)

Con esta sensación de satisfacción por lograr lo anhelado, me dispongo a escribir este pequeño post.

Después varios meses dandole vueltas al tema (soy muy indeciso), buscando alternativas, precios, ahorrando, etc. me compré una netbook. Como habrán adivinado por el título, es una Eee PC 1101ha con procesador Intel Atom z520, 2 GB de RAM, disco de 160 GB, webcam de 1.3 MPx, y pantalla de 11.6”. El temita es que venía con Win XP y eso de entrada me parecía un pecado. Luego de jugar un poquito (inicialmente tenía la idea de aprovechar para terminar de desarrollar una pequeña aplicacioncita que estaba haciendo en Python para Windows, pero luego desistí), me decidí a instalarle Linux.

Sin averiguar demasiado me mandé a instalar distros para netbooks, probé varias más de una vez: Ubuntu Netbook Remix, Eeebuntu, EasyPeasy (ex Ubuntu-eee). Fue un proceso tortuoso en el cual aprendí algunas cositas de lo que estaba haciendo, pero no lograba darme cuenta de por qué me andaba TAN LENTO!. No podía creer que Win XP anduviera más rápido! Después de estar un rato largo (más de un día) me fui dando cuenta que el problema no era que el procesador o la RAM no dieran (me llamaba la atención todo lo que cy)onsumía el netbook-launcher en UNR y EasyPeasy), sino en la placa de video, porque no tenía los drivers correspondientes. Luego de dar muchas vueltas por internet encontré dos posts en dos blogs que me ayudaron a sacarla andando:

Perfect Ubuntu Jaunty on the Asus eeePC 1005HA (and 1008HA)

Configurar en Ubuntu 9.10 la tarjeta gráfica Intel GMA500 y Compiz

Con esos dos posts logré sacarla andando, haciendo algunas modificaciones menores. Así que pongo el procedimiento que hice para instalar Ubuntu Netbook Remix, con el Desktop tradicional de Ubuntu (no el netbook-laucher) y los drivers para la placa Intel GMA 500.

Instalar Ubuntu

Lo primero fue descargar Ubuntu Netbook Remix y crear el USB para bootear. Luego F2 para entrar al BIOS de la Eee, configurar para que levante del USB, y ahí mismo levantó la interfaz de instalación de Ubuntu que todos conocemos. No me voy a extender sobre ésto porque hay miles de guías en internet al respecto, además de que la instalación es bastante intuitiva.

El particionamiento del disco elegí hacerlo manualmente, y tomé el recaudo que señalaba el primer artículo citado de dejar una pequeña partición sin formatear de 16 MB para poder configurar el boot booster.

Afortunadamente, la última versión de UNR me levantó sin problemas la placa de red inalámbrica (la ethernet no la probé en realidad), así que no me tuve que preocupar por eso.

Quitar la interfaz para netbooks

El siguiente paso fue quitar la interfaz para netbooks, que consumía bastante. Ahí lo que me enteré fue que a partir de Karmic, el Desktop Switcher ya no viene más en Ubuntu Netbook Remix. Por lo tanto, lo que tuve que hacer fue deshabilitar el Netbook Launcher y Maximus Window Management en System -> Preferences -> Startup Applications (y de paso aproveché para deshabilitar otras que no necesitaba). Con ello, cuando reinicié, acomodé los paneles para que quedaran como en Ubuntu y listo.

Instalar EeePC Tray

Luego, siguiendo la guía, instalé eeepc-tray. Para ello agregué los repositorios de statux.org siguiendo esta guía. Luego ejecuté:

# sudo apt-get update
# sudo apt-get install eeepc-tray

En la guía original decía que había que instalar eeepc-laptop-dkms. El tema es que cuando lo intenté, pinchaba al intentar compilar contra el kernel de Karmic. Luego de googlear un poco me enteré de que no era necesario instalar ese paquete en Karmic.

Habilitar boot booster

Por último, el último item de la guía que ejecuté fue el de formatear la unidad de 16 MB que había dejado libre al particionar.

sudo sfdisk --change-id /dev/sda 3 ef

Donde 3 es el número de la partición correspondiente (en este caso, /dev/sda3). Con eso al entrar el BIOS se puede habilitar el boot booster.

Configurar placa de video

Para configurar la placa de video seguí íntegramente la guía de Otro Blog Más. Con ella pude instalar poulsbo como driver para la placa de video Intel GMA500. Una vez seguidos esos pasos, al reiniciar no lo podía creer. Una imagen increíble y los efectos 3d andando aceptablemente bien. Ahora tengo compiz andando, con los efectos que más me gustan.

Pimp my Ubuntu

Finalmente, si quieren configurar algunas cositas que quizás falten, la guía de Ubuntu Life sobre cosas para hacer luego de instalar Ubuntu 9.10 es genial.

poulsbo

Editado: 07/12/2009

Esta mañana cometí el error de aceptar sin mirar las actualizaciones automáticas de Ubuntu. 108 MB de actualizaciones de todo el SO, incluyendo kernel, xorg y otras cosas heavies. Cuando se reinició, los drivers PSB no funcionaban más. Luego de dar vueltas por internet encontré la solución:

# sudo apt-get remove psb-kernel-source
# sudo dpkg -i psb-kernel-source_4.41.2-0ubuntu1~910um1_all.deb

Importante: el archivo .deb es el mismo que había bajado ayer de Otro Blog Más.

A partir de ahora voy a ser más cuidadoso antes de aceptar las actualizaciones automáticas de Ubuntu ^^.

Editado 11/12/2009: Corregí el link de Ubuntu Life que estaba mal.

Hoy les traigo algunos tips para darle un “respiro” a nuestras máquinas cuando tienen un consumo excesivo de RAM, aumentando un poco la swap de Linux. Esto no va a solucionar todos nuestros problemas (la swap es en definitiva memoria en el disco, cuya lectura es mucho más lenta que la RAM), pero puede darnos una pequeña ayudita para superar un momento de mucho uso.

Concretamente vamos a ver dos casos: crear y montar un archivo swap, y hacer lo propio con un pendrive usando swapboost.

Crear un archivo swap

Comenzaremos por este ejemplo que es el más sencillo y el más explicativo. Lo primero que debemos hacer es crear un archivo del tamaño que vamos a reservar para la swap con dd. Por ejemplo, para crear uno de 512 MB haremos:

dd if=/dev/zero of=/tmp/swapfile bs=1M count=512

Luego debemos crear un swapfile vacío con mkswap.

mkswap /tmp/swapfile

Por último montamos el archivo con swapon.

swapon /tmp/swapfile

Ahora podemos ver el archivo montado:

swapon -s
Filename                                Type            Size    Used    Priority
/dev/sdb6                               partition       497972  84032   -1
/tmp/swapfile                           file            524280  0       -2

Vemos en la última línea el archivo con 512 MB de swap y una prioridad secundaria respecto a nuestra partición swap.

Swapboost: crear swap en un flashdrive USB

Swapboost es un sencillo script en BASH que nos permite montar el espacio disponible de un dispositivo de almacenamiento USB como swap en forma sencilla. El procedimiento es sencillo.

Descargamos el script y le damos permisos de ejecución.

wget http://zelut.org/projects/misc/swapboost.sh
chmod +x swapboost.sh

Insertamos el pendrive y lo montamos (esto puede hacerse con mount o si estamos en un entorno gráfico como gnome o KDE, permitiéndo que éstos lo monten automáticamente), y ejecutamos:

./swapboost.sh -n

para crear una nueva swap en el espacio libre del USB. Ahora podemos revisar su uso con:

swapon -s

Por último, para borrar la swap creada y desmontar el USB ponemos:

./swapboost.sh -d

Más información en Ubuntu Tutorials [en inglés].

GNU/Linux

Como sucede a menudo, una situación inesperada me hizo toparme con algo nuevo para aprender, que creo bueno compartir. Hace algún tiempo vendimos un servidor dedicado con un CPU Xeon X3210 (quad-core), para el cual solicitamos una instalación estándar de CentOS 5 con Directadmin. Ayer necesitamos agregarle un poco más de RAM (llegando a 4GB) y nos enteramos que el sistema operativo instalado era de 32 bits.

Personalmente creo que a esta altura ya no se justifica instalar un SO de 32 bits sobre un servidor con arquitectura de 64 bits porque implica un desperdicio de los recursos del sistema y porque la mayoría de las aplicaciones que uno puede llegar a utilizar en máquinas con esta función, trabajan correctamente sobre 64 bits. Es más discutible para una máquina de escritorio, pero últimamente incluso en este caso ya no es tan relevante (sobre todo desde los lanzamientos de Wine o el plugin de Flash para 64 bits en Linux). De hecho yo hace unos dos años que utilizo Linux de 64 bits en mi máquina de escritorio y siempre pude sobrellevar los problemas que ello implicó. Al respecto es interesante este artículo de AMD.

Por si no llegaron a la conclusión, el problema en este caso de tener un sistema operativo de 32 bits es que no permite la asignación de más de 4 GB de memoria física. De hecho, en la práctica el límite suele ser inferior (alrededor de 3.5 GB) por la memoria que de por sí necesita el sistema operativo para algunos dispositivos (acá hay un interesante artículo de Coding Horror sobre este tema en Windows).

Pero existe una solución que se llama PAE: Physical Address Extension (Extensión de dirección física). Se trata de una funcionalidad incluida en los procesadores x86 y x86-64 que permite asignar más de 4 GB de memoria física (hasta 64 GB). El tema es que para hacer uso de esta funcionalidad es necesario que el kernel de nuestro sistema operativo sepa cómo hacerlo. En Windows esto se llama AWE y por supuesto Linux tiene el correspondiente soporte si se lo compila con el flag adecuado.

En el caso de mi problema, como no podía reinstalar el servidor porque hubiera sido riesgoso (está en Estados Unidos y ni sé quién lo hubiera hecho) y perdería bastante tiempo de uptime, esta funcionalidad me resultó indispensable para poder hacer uso de los recursos del servidor. La opción más linda para los que nos gusta experimentar hubiera sido recompilar el kernel por mi mismo, pero las circunstancias para ello no eran las mejores, así que siendo CentOS tuve que recurrir a la basura de yum. Y el procedimiento es tan sencillo como:

# yum install kernel-PAE

Importante: La instrucción la vi en este post, pero no mencionaba un detalle. Lógicamente este procedimiento descarga e instala un nuevo kernel (con el flag activado). Pero, al menos en mi caso, no hizo el cambio adecuado en el GRUB. Por lo cual edité el archivo /etc/grub.conf:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE:  You have a /boot partition.  This means that
#          all kernel and initrd paths are relative to /boot/, eg.
#          root (hd0,0)
#          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
#          initrd /initrd-version.img
#boot=/dev/sda
default=1
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-92.1.22.el5PAE)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.22.el5PAE ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-92.1.22.el5PAE.img
title CentOS (2.6.18-92.1.13.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.1.13.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-92.1.13.el5.img
title CentOS (2.6.18-92.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-92.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet
initrd /initrd-2.6.18-92.el5.img

Donde tuve que cambiar la línea que dice “default=1″ por “default=0″, para que inicie con el kernel que tiene el soporte para PAE activado. Luego corremos “grub” de nuevo y reiniciamos.

# grub
# reboot

GNU/Linux

La publicación de la versión 2.6.29-rc1 del kernel el pasado sábado marca el fin de la etapa de incorporación de cambios en el núcleo de GNU/Linux, y como indican en Heise a partir de ahora simplemente queda esperar la revisión de esos cambios y la corrección de errores para la publicación final de uno de los núcleos más importantes de los últimos tiempos.

Si como todo parece el kernel aparece en las próximas semanas es muy probable que la hornada de distribuciones primaverales lo incluyan, de modo que Ubuntu 9.04, Fedora 11, openSUSE 11.2 y el resto de contendientes se beneficiarían de las mejoras en el kernel, de las cuales destacan cinco muy especialmente.

Si queréis descubrirlas, seguid leyendo…

Como decíamos, cinco son las grandes sorpresas que nos deparará el kernel 2.6.29, y todas ellas son importantes:

FreeBSD

Me entero en Slashdot que ya está disponible la versión 7.1 estable de FreeBSD. De acuerdo con el anuncio oficial, entre los cambios se incluye:

• El planificador (scheduler) ULE es el nuevo default en los kernels GENERIC para arquitecturas amd64 e i386. Este scheduler incrementa significativamente la performance en sistemas multi-core.
• Se importó de OpenSolaris el soporte para usar DTrace dentro del kernel.
• Un nuevo y significativamente mejorado cliente de NSF Lock Manager (NLM).
• Cambios en el boot loader que permiten, entre otras cosas, bootear de dispositivos USB o de dispositivos GPT.
• Se agregaron la system call cpuset(2) y el comando cpuset(1), proveyendo una API para bindear threads con CPUs para agrupar y asignar recursos de CPU.
• Actualización de KDE a 3.5.10 y GNOME a 2.22.3.
• Medios tamaño DVD para las arquitecturas amd64 e i386.

Más información sobre bugs corregidos y nuevos features en:

• http://www.FreeBSD.org/releases/7.1R/relnotes.html
• http://www.FreeBSD.org/releases/7.1R/errata.html

Pido perdón por la traducción un tanto tarzanesca y si cometí algún error, por favor, hacérmelo saber.

GNU/Linux

Lo interesante de esta nueva versión es que incluye soporte para el sistema de archivos Ext4, que hasta el momento estaba marcado como en estado “experimental”. Según Linux Hispano, el paso entre Ext3 y Ext4 es más significativo que el experimentado entre Ext2 y Ext3. En aquel último pasaje, la característica fundamental que se incorporó fue el journaling o transacciones, capaces de restaurar la información en caso de que ocurra un error durante una de ellas. Ext4, en cambio, implica una modificación importante en la estructura de datos orientada a mejorar la performance y la estabilidad del filesystem. Además, Ext3 soportaba un tamaño máximo del sistema de archivos de 16 TB (Terabytes) con un tamaño máximo por archivo de 2 TB. Ext4 eleva esos límites a 1 EB (Exabyte) para todo el filesystem y 16 TB para los archivos. También, la cantidad de subdirectorios dentro de cada uno es ahora ilimitada (antes era de 32.000 con Ext3).

Para mayor información sobre Ext4, hay otro artículo interesante en Linux Hispano: Ext4. Y, por supuesto, su versión original en inglés en Kernelnewbies.org

Personalmente, aunque me parecen muy interesantes estas características, aún tengo ganas de probar ZFS.

GNU/Linux

Para cualquiera de nosotros que empezamos a aprender computación cuando Microsoft ya dominaba el mercado y que conocimos las maravillas de Unix de grandes, la jerarquía del sistema de archivos puede resultar bastante confusa al principio. Además, los usuarios de Linux sabemos que, por lo general, cada distribución (o por lo menos cada familia de distribuciones), mete las cosas donde más le gusta.

Es interesante darle una mirada al FHS (Filesystem Hierarchy Standard), un estándar desarrollado por iniciativa de Linux, el cual otros SOs Unix suelen ignorar, pero que intenta una definición de los distintos directorios principales de un filesystem. Dejo el siguiente cuadro tomado de la versión en español del mismo artículo.

BIND DNS

Recientemente tuve que instalar bind y, como ahora tengo un blog donde hacerlo, escribo esta pequeña guía con los pasos que seguí. La idea será ir completándola luego con configuraciones más específicas, pero por lo pronto empecemos con lo básico.

¿Qué es un DNS?

Antes de instalar un servicio es muy importante saber de qué se trata y cuanto más sepamos al respecto, más vamos a entender lo que estamos haciendo y cómo hacerlo mejor. Hace algunos meses publiqué en el blog del Web & Beer un link a un artículo sobre DNS: ¿Cómo funciona el DNS? de Javier Smaldone.

Instalación de bind

Sin lugar a dudas bind es el servidor DNS más difundido, por ello esta guía se dedica a él. Particularmente yo trabajé sobre CentOS, pero como no quería instalarlo con yum (me encanta compilar mis servidores), lo hice directamente desde los fuentes. Partí de esta guía bastante clara, pero fui haciendo algunas modificaciones de acuerdo a las necesidades de la última versión de producción de bind. Adicionalmente, para darle mayor seguridad (y complicarla un poco más, porque me encanta), lo configuré para que corra en un chroot.

Antes de empezar, posiblemente sea necesario quitar versiones anteriores de bind que estén instaladas. Muchas distribuciones de Linux vienen con versiones de bind instaladas, pero si son tan obsesivos como yo, querrán quitarlas e instalar la propia. En CentOS podemos verificar esto con yum y con rpm.

# yum remove bind
# rpm -q bind
# rpm -e --nodeps bind-9.3.4-6.0.2.P1.el5_2

Para empezar, lógicamente, descargamos los fuentes de la página de descargas de ISC, descomprimimos, configuramos, compilamos e instalamos. Asumismos que, previamente, fueron instaladas las librerías necesarias que generalmente vienen en cualquier Linux. Entre ellas es importante destacar OpenSSL.

# cd /usr/src
# wget http://ftp.isc.org/isc/bind9/9.4.3/bind-9.4.3.tar.gz
# tar zxvf bind-9.4.3.tar.gz
# cd bind-9.4.3/
# ./configure --prefix=/usr \
                  --sysconfdir=/etc \
                  --enable-threads \
                  --localstatedir=/var/state \
                  --with-libtool \
                  --with-openssl=/usr/lib
# make && make install

Configurar el entorno

Si había una versión anterior de bind instalada, posiblemente todo esto ya esté hecho, pero no está de más revisarlo. Lo que haremos en este punto es crear un usuario y grupo llamados “named”, y configurar los permisos de las carpetas que vamos a utilizar. Téngase en cuenta que en este caso correremos el proceso en un chroot.

# groupadd named
# useradd -d /var/named -g named -G daemon -s /bin/false named
# mkdir -p /var/named/chroot/etc \
               /var/named/chroot/var/named \
               /var/named/chroot/var/run \
               /var/named/chroot/dev
# mknod /var/named/chroot/dev/null c 1 3
# mknod /var/named/chroot/dev/random c 1 8
# chmod 666 /var/named/chroot/dev/null
# chmod 666 /var/named/chroot/dev/random
# chown -R named:named /var/named
# cp /etc/localtime /var/chroot/etc/
# echo "nameserver 127.0.0.1" >  /etc/resolv.conf

Configurar bind

Ahora vamos a tener que definir los distintos archivos de configuración de bind. Con éstos vamos a definir el comportamiento general del servidor de DNS (en named.conf), definir las claves para utilizar rndc para controlar el demonio, y por último y fundamental, definir las zonas de nuestro DNS. Hay que tener en cuenta que este DNS que configuré yo es público, es decir que va a ser consultado por clientes de redes externas para obtener las IPs de mis dominios. La guía previamente citada, sirve para configurar un DNS de una red local que resuelve dominios externos para clientes de la LAN.

Repasemos los archivos sobre los que vamos a trabajar:

• /var/chroot/etc/named.conf: configuración básica de bind.
• /var/chroot/etc/rndc.conf: configuración de rndc
• /var/chroot/etc/rndc.key: clave de rndc
• /var/chroot/named: en este directorio guardaremos las distintas zonas de nuestro DNS.

Antes que nada, debemos generar la clave para rndc. Siguiendo el ejemplo citado usaremos como clave la palabra “hush”. Para generar el hash debemos usar el comando mmencode.

# mmencode
hush # nuestro password
aHVz # esto es lo que devuelve mmencode
^C # salimos con Ctrl+C

Esa clave es la que vamos a utilizar en nuestros archivos de configuración.
En el rndc.conf ponemos:

// this file is used by the rndc utility
        options {
        // what host should rndc attempt to control by default
            default-server localhost;
        // and what key should it use to communicate with named
            default-key "rndc-key";
        };

        server localhost {
        // always use this key with this host
            key "rndc-key";
        };

        key "rndc-key" {
        // how was the key encoded
            algorithm hmac-md5;
        // what's the password
            secret "aHVz";
        };

        // secret was generated by running mmencode on command line
        // and then entering a secret phrase

Luego, en nuestro rndc.key ponemos:

key "rndc-key" {
	algorithm	hmac-md5;
	secret		"aHVz";
};

Notesé que en ambos casos estamos utilizando el hash que generamos, pero para mayor seguridad sería conveniente generar un hash más largo.

Editado 25/12/2008 13:12: Un detalle importante es que los archivos rndc.conf y rndc.key hay que copiarlos a /etc para que cuando nuestro script del init.d llame a rndc, éste encuentre sus archivos de configuración.

# cp /var/named/chroot/etc/rndc.* /etc/

Luego el named.conf

// This is a configuration file for named (from BIND 9.0 or later).
        // It would normally be installed as /etc/named.conf.
        //
        // Changed to match secure example from LASG 5/17/00
        // Changed to match Linux Journal example 9/17/00
        // Added new "view' sections to stop fingerprinting of Bind 9.x per
        // Bugtraq 1/31/00
        // Added rndc key stuff per DNS & Bind (Rev. 4) Chapter 11
        // added use-id-pool and more comments based on above chapter

             options {
            // Directory where bind should create files if
            // not explicitly stated
            directory "/var/named";

            // whom do we allow to do zone tranfers
            allow-transfer { 192.168.1.0/24; };

            // tell Bind to check the names in zone files
            // since it no longer does this by default
            // (unimplemented 9.3.0+)
            check-names master warn;

            // sets the size of something or other to 20Mb
            datasize 20M;

            // sets the size of the journal to 5Mb
            max-journal-size 5M;

            // where should Bind put a dump of its cache
            // if told to dump it
            dump-file "named_dump.db";

            // how often should bind check for new
            // interfaces toi listen on. we turn
            // this off by setting it to 0
            interface-interval 0;

            // specify what interfaces/ips to listen on
            // as the default is all of them
            listen-on { 1.2.3.4; 2.3.4.5; 127.0.0.1; };

            // define a mximum size of cached records
            // new in Bind 9.x
            max-cache-size 20M;

            // where to right stats of memory usage
            // Bind 9.x doesn't recognize this yet
            memstatistics-file "named.memstats";

            // where to put out pid file
            // absolute path since we don't want
            // it in /var/named
            pid-file "/var/run/named.pid";

            // force Bind to use port 53 for its
            // network operation to other DNS
            // servers (Bind 9 uses high ports
            // by default). Makes firewalling easier
            // query-source address * port 53;
            // transfer-source * port 53;
            // notify-source * port 53;

            // where to dump Bind server stats
            statistics-file "named.stats";

            // force Bind to be "more" random in assiging
            // message ids
            // use-id-pool yes;

            // If the chaos view below doesn't work
            // for some reason, still give out a bogus
            // answer for Bind version requests
            version "This is not the port you're looking for.";

            // keep stats on a zone basis
            zone-statistics yes;
             };

             controls {
            // this allows rndc to be used from the localhost
            // to talk to bind on the loopback interface
            // using the key defined as 'rndc-key'
            inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
             };

             // the rest of the key configuration is in
             // /etc/rndc.conf and the key itself is in
             // /etc/rndc.key
             key "rndc-key" {
            // how was key encoded
            algorithm hmac-md5;
            // what is the pass-phrase for the key
            secret "aHVz" ;
             };

             logging {
            channel named_info {
                // log to syslog instead of a file
                syslog;
                // include the category of the event in the log
                print-category yes;
                // include the severity of the event in the log
                print-severity yes;
                // include the time of the event in the log
                print-time yes;
            };

            // Processing of client requests
            category client { named_info; };

            // named.conf parsing and processing
            category config { named_info; };

            // Messages relating to internal memory structures
            category database { named_info; };

            // This is the default for any category not specifically defined
            category default { named_info; };

            // The catch-all. Anything without a category of its own
            category general { named_info; };

            // Uncomment if you dont want to know about lame server.
            // Leave commented and it defaults to the
            // value of default above
            // category lame-servers { null; };

            // The NOTIFY protocol
            category notify { named_info; };

            // Network operations
            category network { named_info; };

            // DNS resolution like recursive lookups, etc..
            category resolver { named_info; };

            // Approval and denial of requests
            category security { named_info; };

            // Dynamic updates
            category update { named_info; };

            // Queries. Duh.
            category queries { named_info; };

            // Zone transfers received
            category xfer-in { named_info; };

            // Zone transfers sent
            category xfer-out { named_info; };
            };

	zone "." IN {
		type hint;
		file "named.ca";
	};

	zone "localhost" IN {
		type master;
		file "localhost.zone";
		allow-update { none; };
	};

	zone "0.0.127.in-addr.arpa" IN {
		type master;
		file "named.local";
		allow-update { none; };
	};

	include "/var/named/zones.list";

Estos archivos los tomé del ejemplo original pero tuve que hacer algunas modificaciones. Una importante a notar es que comenté la parte donde se forzaba el puerto del bind. Esto es un error de seguridad importante que se descubrió hace relativamente poco y a partir del cual bind (en la versión 9) empezó a utilizar puertos aleatorios mayores al 1024 para consultar otros DNS. Esto es para contrarrestar ataques de DNS Cache Poisoning.
Luego cambié la línea de listen-on, para definir que escuche en todas mis interfaces de red públicas. Yo puse IPs 1.2.3.4 y 2.3.4.5, pero allí deberían ir las IPs en las que ustedes quieran que su DNS escuche.
Por último, cambié la definición de vistas que no me hacía falta por una mera declaración de las zonas principales y agregué al final un include de un archivo /var/named/zones.list.
En ese archivo es donde definiré la lista de archivos con las zonas para cada uno de mis dominios.

Por ejemplo:

[root@tail-f]# cat var/named/zones.list
zone "domain.com.ar" { type master; file "/var/named/zones/domain.com.ar.db"; };

Y luego, en el archivo /var/named/zones/domain.com.ar.db defino la zona en sí.

[root@tail-f# cat var/named/zones/domain.com.ar.db
$TTL 14400
@       IN      SOA     ns1.domain.com.ar.      root.domain.com.ar. (
                                                2008120300
                                                14400
                                                3600
                                                1209600
                                                86400 )

domain.com.ar.        14400   IN      NS      ns1.domain.com.ar.
domain.com.ar.        14400   IN      NS      ns2.domain.com.ar.

domain.com.ar.        14400   IN      A       1.2.3.4
ftp     14400   IN      A       1.2.3.4
localhost       14400   IN      A       127.0.0.1
mail    14400   IN      A       1.2.3.4
pop     14400   IN      A       1.2.3.4
smtp    14400   IN      A       1.2.3.4
www     14400   IN      A       1.2.3.4

domain.com.ar.        14400   IN      MX      10 mail

domain.com.ar.        14400   IN      TXT     "v=spf1 a mx ip4:1.2.3.4 ?all"
domain.com.ar.        14400   IN      SPF     "v=spf1 a mx ip4:1.2.3.4 ?all"

Editado 23/12/2008 13:32: Por sugerencia de Walruz incluyo el registro SPF. Como bien dice él, a partir de la versión 9.4, bind acepta la definición de registros del Sender Policy Framework, un estandar de IETF (RFC 4408) para la verificación del remitente del email. Para mayor información, este artículo (en inglés) es bastate completo.

Configurar el init.d

Por último, queda instalar el script en el init.d para arrancar nuestro servicio y configurarlo de manera que corra en un chroot. Esto es muy sencillo, pero la versión que voy a dar es específica para Red Hat/CentOS. En otras distribuciones posiblemente cambie la forma de implementación.

Básicamente lo que vamos a necesitar es el script de init.d que levante el servicio con el siguiente comando:

named -u -t /var/named/chroot/

Para ello, en CentOs tendremos nuestro script del init.d y la definición de los parámetros en /etc/sysconfig/named. De esta forma:

[root@tail-f]# cat /etc/sysconfig/named
# This option will run named in a chroot environment.
ROOTDIR="/var/named/chroot/"
# These additional options will be passed to named at startup.
# Don't add .t here, use ROOTDIR instead.
#OPTIONS=""

Cuando nuestro script inicie el servicio, cargará las variables de /etc/sysconfig/named y verificará si definimos un directorio ROOTDIR para levantar el servicio con ese directorio como chroot.

Luego copiamos nuestro script al init.d y ejecutamos chkconfig.

# cp named /etc/init.d/
# chmod 700 /etc/init.d/named
# chkconfig --add named
# chkconfig named on

Descargas

Los archivos a descargar son varios, así que hice un tar con los archivos de ejemplo que utilicé yo, incluyendo también las zonas por default para dominios locales y el named.ca que tiene las IPs de los root DNS.

Descargar: bind.conf.tar.gz