RHEL4U6: nss_ldap + sendmail = PROBLEMAS

Desde hace varias semanas he notado que los sendmails de los servidores RHEL4U6 autenticados contra el LDAP del Diretorio Activo en Windows2003, no son capaces de entregar el correo local. Hoy por fín he sacado un poco de tiempo para depurarlo. El comportamiento es el siguiente.

1. El equipo está autenticado contra el directorio LDAP del AD. Esto quiere decir que en /etc/nsswitch.conf tendremos algo similar a lo siguiente:

   passwd:     files ldap
   shadow:     files
   group:      files ldap

2. Somos capaces de ejecutar los comandos getent passwd y getent group y obtener el listado de usuarios y grupos autorizados del dominio
3. Arrancamos NSCD y parece que todo funciona, pero cuando ejecutamos service nscd status nos dice que no está ejecutándose.
4. Cuando ejecutamos mail root, para enviar un correo en /var/log/maillog obtenemos:

   Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20289]: m6TKhlFo020289: from=root, size=61, class=0, nrcpts=1, msgid=<200807292043.m6TKhlFo020289@vmtyo-subversion-pro.tyo.carm.es>, relay=root@localhost
   Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20292]: m6TKhlxl020292: from=<root@vmtyo-subversion-pro.tyo.carm.es>, size=411, class=0, nrcpts=1, msgid=<200807292043.m6TKhlFo020289@vmtyo-subversion-pro.tyo.carm.es>, proto=ESMTP, daemon=MTA, relay=localhost.localdomain [127.0.0.1]
   Jul 29 22:43:47 vmtyo-subversion-pro sendmail[20289]: m6TKhlFo020289: to=root, ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=30061, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (m6TKhlxl020292 Message accepted for delivery)

   ... y el correo nunca llega. Al ejecutar mailq vemos que está en la cola.
   
5. Si ahora editamos /etc/nsswitch.conf y dejamos lo siguiente,

   passwd:     files ldap
   shadow:     files
   group:      files

   después de reinciar sendmail, vemos como finalmente el correo llegará a la cuenta de root.

Después de depurar durante varias horas el proceso, depurando el comportamiento con distintas opciones de configuración y con ayuda de strace, en diferentes sistemas RHEL4UXX, he llegado a la conclusión de que tenía que ser un bug de nss_ldap-226-20 (la versión de RHEL4U6). He realizado una búsqueda en Internet y así parece ser que es.

He actualizado el sistema para usar nss_ldap-226-18 (la versión de RHEL4U5) y el envío de correos funciona a la perfección.

Error "sql_select option missing" al reiniciar sendmail en RHEL4

Habitualmente suelo configurar los agentes MTA locales de los servidores Linux, con el fín de que al menos el correo local en la máquina se entregue apropiadamente, y me lleguen los reportes de logwatch,cron, etc.
En las instalaciones de RHEL4, me estaba encontrando en /var/log/messages que cada vez que reiniciaba el demonio, aparecían entradas como esta.

Jul 29 18:58:10 vmtyo-subversion-pro sendmail[6340]: sql_select option missing
Jul 29 18:58:10 vmtyo-subversion-pro sendmail[6340]: auxpropfunc error no mechanism available 
Jul 29 18:58:10 vmtyo-subversion-pro sendmail: sendmail startup succeeded
Jul 29 18:58:11 vmtyo-subversion-pro sendmail: sm-client startup succeeded

Al parecer esto se debe a que tenemos instalado el paquete cyrus-sasl-sql, y no lo hemos configurado, que tampoco es mi caso, por lo que para que desaparezcan estos mensajes bastará con desinstalarlo:

rpm -e cyrus-sasl-sql-2.1.19-14
/etc/init.d/sendmail restart

Vmware Server 2.0 en Ubuntu 8.04

Esta mañana he instalado y configurado al fín VMware Server 2.0, en el equipo con Mythbuntu que tengo conectado a la tele. He seguido las instrucciones de http://ubuntuforums.org/showthread.php?t=779934, y luego en las respuestas he aceptado todas las sugerencias que me hacía, como antiguamente decíamos: Siguiente->Siguiente->...

sudo apt-get install build-essential linux-headers-`uname -r` xinetd
cd /opt/
tar xzvf /opt/software/VMware-server-2.0.0-101586.i386.tar.gz
cd vmware-server-distrib/
./vmware-install.pl

Lo que me resulta más interesante es la posibilidad de crear máquinas virtuales con RHEL5 en 32 y 64 bits, además del nuevo interface Web y el soporte a USB2.0.

Claves GPG en Ubuntu/Debian

A menudo las claves GPG de los distintos repositorios nos caducan y necesitamos actualizarlas, porque de otra forma apt-get nos fallará y nos avisará del problema con las claves GPG. Así, necesitaremos...

wget -q URL-DEL-FICHERO.gpg -O- | sudo apt-key add -

o bien, si ya la tenemos descargada

sudo apt-key add FICHERO.gpg

Una vez hayamos cargado las nuevas claves, ya podremos ejecutar

sudo apt-get update

para refrescar el repositorio de paquetes, que nos estaba fallando.

Investigando el contenido de un initrd

Tratando de solucionar mis problemas de sonido

[   36.093438] ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [LNKC] -> GSI 11 (level, low) -> IRQ 11
[   36.093748] PCI: Setting latency timer of device 0000:00:11.5 to 64
[   36.595513] ACPI: PCI interrupt for device 0000:00:11.5 disabled
[   36.595623] VIA 82xx Audio: probe of 0000:00:11.5 failed with error -13

con el PVR-Mythbuntu sobre Shuttle SK41G que estoy tratando de configurar en casa, tengo la curiosidad de mirar el fichero initrd que preparan en Ubuntu, para ver si por casualidad ahí estuviera la clave del problema.
Al intentarlo me encuentro con que el formato del initrd, no es con el que yo estaba familiarizado (imagen ext2 comprimida, que siempre montaba con mount -o loop), sino que se trata de un cpio comprimido. Para descomprimirlo...

mkdir /tmp/prueba
cd /tmp/prueba
cp /boot/initrd.img-2.6.24-19-generic initrd.gz
gunzip initrd.gz
cpio -imdF initrd

luego realizamos los cambios que consideremos oportunos, y para dejarlo cargable por grub ejecutaremos...

cd /tmp/prueba
rm -f initrd
find ./ | cpio -H newc -o > ../mi-initrd.cpio
gzip ../mi-initrd.cpio
mv ../mi-initrd.cpio.gz /boot/initrd.img-2.6.24-19-generic-mia

También deberíamos editar /boot/grub/menu.lst para que el sistema arranque con esta nueva imagen.