Como sincronizar vmware-esx con ntpd

Nos hemos encontrado con un nodo de vmware-esx que no conseguía sincronizar la hora contra el servidor ntp.

Después de ver que estaba iptables activado y que no había regla que permitiera la salida hacia puertos 123 udp, estábamos a punto de introducir la regla a mano cuando nos encontramos en la base de datos de conocimiento de vmware una herramienta con la que se pueden modificar las reglas del firewall.

La herramienta es "esxcfg-firewall". Al final ha sido tan fácil como ejecutar "esxcfg-firewall --enableService ntpClient".

Asignación de dispositivos con udev I

Estos días estoy "luchando" un poco contra el driver multipath de rdac, en lugar de utilizar el driver multipath que viene con las distribuciones de Red Hat.

Se puede decir que el driver rdac no tiene un exceso de documentación, pero aunque la instalación no se sale de lo corriente en Linux, el problema con el que nos estamos encontrando es que los dispositivos cambian de nombre en el reinicio del sistema, por lo cual no nos vale la configuración que tenemos en el "fstab".

En el "readme.txt" que tiene el driver podemos encontrar un punto en el que nos dice:

 2.5   Persistent Naming
                    
Linux SCSI device names have the possibility of changing    when the host system reboots.  We recommend using a utility              such as devlabel to create user-defined device names that              will map devices based on a unique identifier, called a              UUID.
En sistemas modernos la herramienta que se utiliza para la asignación de dispositivos en el sistema es udev. Voy a tratar de dar una explicación concisa de cómo trabajar con udev, a través de varios posts.

¿Qué es udev?

En versiones antiguas de Linux el directorio /dev estaba lleno de dispositivos, es decir, el sistema tenía preparado ya los ficheros correspondientes a los dispositivos, por si se daba el caso de que tuviéramos que conectar otro disco duro, un disco externo, un floppy, etc, etc (es una explicación vaga, pero simplemente se trata de dar una noción). Esto era un poco ineficiente. Entre otras cosas nos encontrabamos con miles de ficheros que no tenían ningún uso.

Según la definición de kernel.org, udev provee de un directorio /dev dinámico y engancha el espacio de usuario con los eventos del kernel. ¿Qué quiere decir esto?, que ahora los dispositivos se añaden en el espacio de usuario, independientemente del reconocimiento que haga el kernel del dispositivo, mientras que antes eso era un trabajo casi exclusivo del kernel.

En el siguiente post nos pondremos manos a la obra con udev.

Asignación de dispositivos con udev: Parte I, Parte 2

Borrado de dispositivos SCSI de una LUN.

Recientemente nos hemos encontrado con que después de presentar una lun de una SAN en uno de nuestros servidores linux nos piden que la borremos y que presentemos el almacenamiento dividido en dos luns.

Se nos planteaban dos problemas:

1. ¿Cómo borramos el dispositivo sin que afecte al sistema?
2. ¿Si desaparece la letra de unidad creada, cómo afecta esto a las nuevas unidades cuando reescaneemos de nuevo las hba?

La solución es bien sencilla. Si hace poco tiempo (el tiempo siempre viene dado en términos relativos a cada servidor) que hemos escaneado los dispositivos scsi, podemos encontrarnos con el nuevo dispositivo y su "host, channel, id, y lun" y su letra de unidad, simplemente ejecutando "dmesg" por ejemplo:

Una vez localizado qué dispositivo queremos borrar tenemos que buscar el comando scsi de borrado, que lo tenemos bajo el directorio /sys.

Debemos buscarlo con el comando "find /sys -name delete". El resultado que nos podemos encontrar puede ser similar a esto:

Lo único que hay que hacer ahora para borrar el dispositivo es un echo 1 a la ruta que hemos encontrado. Si ahora ejecutáramos fdisk -l nos encontraríamos que ha desaparecido la letra de unidad que se corresponde con el identificador scsi que hemos borrado.

Si tuviéramos los dispositivos con multipath deberíamos borrar todos los dispositivos.

Después de realizar este procedimiento, se evitan problemas en el arranque del sistema, puesto que cuando arranca el sistema escanea los dispositivos scsi de nuevo, y no sabe nada de letras de unidad, las asigna correlativas, se puede montar un buen jaleo el fstab con las unidades que tiene que montar.

De todos modos este problema es evitable utilizando LVM, ya que de esta manera es la capa de LVM la que se queda con información del dispositivo que está utilizando mediante su UUID no necesitando las letras de unidad.