Trabajo sobre IDSes Wireless

Hace unas semanas que estuve investigando sobre IDSes Wireless y redes ad-hoc, para el trabajo de una de las asignaturas que estoy cursando en el Máster de la Universidad de Murcia, este año. Lo he subido a mi cuenta de GoogleDocs, porque parece que la publicación cruzada a mi Blog no me terminó de convencer y las entradas en el Blog quedan demasiado grandes a mi juicio, además de que los cambios que hago en el documento después de haber publicado en el blog no se refrescan automáticamente: Parece más práctico, publicar el documento y luego linkarlo desde una entrada en blogger.

Bueno el trabajo versa sobre la Detección de intrusiones en redes wireless y espero que les introduzca en la problemática, que considero muy interesante.

Overlay en OpenLDAP 2.2.13

El otro día Tomás me planteó estudiar la posibilidad de separar toda la rama LDAP donde almacenamos las CRLs de la FNMT en otro árbol separado con su máster y dos réplicas, y configurarles la alta disponibilidad a la lectura mediante nuestros balanceadores hardware de MZ. Para ello me sugirió usar el mecanismo de referral y overlay chain de OpenLDAP, basándose en una primera lectura del http://www.zytrax.com/books/ldap/ch7/referrals.html .

Con esto, pretendíamos sacar de los directorios de desarollo, pruebas y producción las CRLs (que ocupan bastante), ahorrando espacio y ganando flexibilidad y alta disponibilidad: Cuando tenemos algún problema de sincronización con la fábrica, nos resulta complicado parar el master de producción para resincronizar, porque no tenemos alta disponibilidad de escritura: si lo hacemos sin parada, debemos borrar todas las CRLs primero y hay un momento donde no existe ninguna CRL y cualquier certificado sería válido. Un follón. La posibilidad de tener las CRLs nos evitan esto, porque la escritura sólo se realiza dos veces al día, y podríamos parar en cualquier momento.

Investigué todo esto y me encontré que la documentación que me pasó Tomás era para versiones nuevas (2.3 y 2.4) de OpenLDAP. Desgraciadamente aún estamos en 2.2.13 que es la que viene con RHEL4 update2, pero afortunadamente podemos usar overlay chain con la documentación del producto. Encontré las siguientes cosillas sobre overlays y esta versión de openldap, como que podemos saber los overlays que disponemos mirando las páginas man de los módulos que tenemos instalados:


rpm -ql openldap-servers | grep man | grep slapd-
En concreto, toda la documentación del "overlay chain" está disponible en slapd-ldap (man slapd-ldap). Para configurarlo, lo primero que tendremos que hacer será preparar un nuevo árbol con toda la estructura y datos que queremos sacar para darle mayor disponibilidad. Este árbol lo colocaremos en 192.168.1.170 por ejemplo. Luego en el árbol que queremos que tenga la referencia al nuevo (que llamaremos árbol B), deberemos añadir una entrada como la que se muestra a continuación:

dn: o=FNMT,c=ES,dc=RegionMurcia,dc=es
objectClass: referral
objectClass: extensibleObject
o: FNMT
ref: ldap://192.168.1.170/o=FNMT,c=ES

Esta entrada crea un objeto referral o:FNMT en la rama c=ES,dc=RegionMurcia,dc=es, de manera que los objetos que deberían colgar de esta rama, en realidad no están ahí sino en la rama equivalente del árbol 192.168.1.170. Probé a usar otra rama en el árbol 192.168.1.170 (llamaremos árbol A), por ejemplo “o=FNMT,c=ES,dc=CARM,c=es”, pero luego me obligaba a usar el overlay de rewrite (mirar man slapd-meta) para ir reescribiendo todos los DNs en los varios contextos de operaciones LDAP, y finalmente no me atreví por temor a que mis reglas rewrite se olvidaran de contemplar algún caso que en el futuro me generara problemas: Si no queremos complicarnos, lo mejor es dejar la misma estructura que teníamos en B en el nuevo árbol A.

Luego en la configuración del árbol B (/etc/openldap/slapd.conf), justo antes de la sección donde declaramos las réplicas, añadiremos:
# Referral sobre LDAP A
overlay chain
uri ldap://192.168.1.170
binddn "cn=admin,dc=RegionMurcia,dc=es”
bindpw secret
Tenemos todas las opciones configurables en la página man slapd-ldap. Reiniciamos el servicio en árbol B. Debemos asegurarnos de haber añadido en /etc/openldap/ldap.conf (que guarda la configuración del cliente OpenLDAP del equipo):
DEREF always
Después de esto, ya podremos lanzar la prueba:
ldapsearch –x –h IP_de_B
-D “cn=admin,dc=RegionMurcia,dc=es”
-w secret
-b “o=FNMT,c=ES,dc=RegionMurcia,dc=es”
Observaremos como se trae la información desde el directorio A. Luego lo probamos con las aplicaciones clientes en Java y PHP y no nos funcionó. ¿Por qué? … Asumimos que en ambos casos se debe a que por defecto, los clientes, no establecen el “DEREF always”, y hay que establecerlo de forma manual.
Solicité el código Java que hacía el bind al OpenLDAP y descubrí que usaban el objeto LDAPConection . La conexión real se hacía en la llamada al método bind() con tres parametros: IP_Servidor, Login, Passwd. Si miramos la documentación, comprobaremos que existe otro método bind que en vez de 3 espera 4 parámetros. El cuarto argumento es un LDAPConstraints. La API indica que tiene un método llamado setReferralFollowing que por defecto es false, y que hace que los objetos referrall se sigan como si fueran enlaces simbólicos, como bien se explica en la documentación de la API.

Esta mañana (28/Feb/2008) hemos vuelto a intentarlo y lo hemos conseguido usando la conexión a través de JNDI y usando como url ldap://servidor:puerto/????deref=always en la inicialización del parámetro URL de la conexión. Me he inspirado en el código de http://iubio.bio.indiana.edu/biogrid/directories/ldapsearch.java .

Edición automática con vi desde la línea de comandos

A menudo necesitamos aplicar una modificación en cascada sobre un conjunto de archivos, con el fin de reemplazar las ocurrencias de una palabra o frase por otra. Esto se puede hacer con vi, usando la línea de comandos. Imagine que desea reemplazar las ocurrencias de la palabra prueba por test y bendito por maldito, en el fichero documento.txt.
Usando este método, podríamos ejecutar:


vi '+%s/prueba/test/g' '+%s/bendito/maldito/g' '+wq' documento.txt

Búsqueda de artículos de investigación técnicos y drafts

Me he pedido unos días de Vacaciones, dado que cambiaré de trabajo en Marzo y no me pagan esos días, y estoy aprovechando para terminar prácticas que tengo a medio en el Master TITA de la Universidad de Murcia, que estoy haciendo. Para varias de las prácticas nos piden investigar el estado del arte en referencia a algún tema de la asignatura.
Cuando uno empieza a buscar artículos de investigación sobre diversos temas, termina tropezando con http://ieeexplore.ieee.org, lo que se traduce en pagar por leer. Gracias a http://citeseer.ist.psu.edu/ podemos tener acceso a los borradores de muchos de esos documentos, y las versiones previas. El problema de este site, es que el buscador que tienen no es muy allá y nos interesará usar google para buscar en él. Así en Google podemos poner:

site:citeseer.ist.psu.edu Denial of service in sensor networks


... y nos aparecerán los documentos de citisser relacionados.

Mi primera contribución al software libre reconocida

Acaban de contestarme al correo que envié al proyecto hal@freedesktop con el parche para arreglar la suspensión del portatil Compaq nx6110.
Oficialmente, esta es la primera contribución en la que obtengo feedback directo, a pesar de que ya he hecho algunas otras.

  • En el proyecto Samba, les di todas las pistas y el programita que 100% de los casos era capaz de reporducir el problema, para que implementaran ReadDirectoryChangesW. Esto lo hice a través del soporte TAM de RedHat. Se incluyó a partir de samba 3.0.25b-0.3.
  • En el proyecto device-multipath y el kernel, contribuí a que funcionaran las cabinas de almacenamiento activo-pasivo haciendo de tester y reportando resultados, sugerencias y fallos (módulo dm_hp_sw). Esto también fue a través de la cuenta TAM.
  • También intenté aportar mi contribución en el proyecto phpBugTracker de sourceforge, allá por el 2005, pero nunca obtuve respuesta de los bugs que arreglé y de las correcciones en la traducción.
  • La versión de OCFS v1 para Oracle 9iRAC 9.0.4, no compilaba bien para kernels SMP. Me suscribí a la lista y les comenté el problema que había en el Makefile, y cómo lo había arreglado yo. Me respondieron que lo tendrían en cuenta y que gracias.

Cómo almacenar mis contraseñas en Linux

He creado un pequeño script que nos permite almacenar nuestras contraseñas en un fichero encriptado. La idea es usar el módulo "aes" del kernel 2.6 y con ayuda de dm-setup y cryptsetup, usar un fichero local montado en /dev/loop/0 formateado como ext3 encriptado. La utilidad permite inicializar un nuevo fichero, montar y desmontar el ficherito.
La ventaja de usar este mecanismo frente "-x " en vi, es que con vi tenemos el inconveniente de que si alguien se pone al lado de nosotros mientras consultamos el fichero vé todas las contraseñas que haya en pantalla. Con esta otra solución podemos almacenar cuentas en ficheros separados. Además también podríamos almacenar a su vez otros ficheros encriptados.

El script es el siguiente:


#!/bin/bash
# Inicia y detiene un montaje local de un sistema de archivos
# encriptado, que permite almacenar claves.
#
# -----------------------------------------------
# Variables globales

# Dispositivo "Lo" a usar
loDevice=/dev/loop/0

# Fichero claves en Mapper
mapperDevice=myPasswords

# Tamaño del fichero, por defecto
sizeDefault=5

# Fichero criptográfico por defecto
defaultFile=~/.claves.img

# Directorio donde montar por defecto
defaultDir=~/.claves_mnt_point


# -----------------------------------------------
# Mostrar la ayuda del comando
_help() {
local cmd=`basename $0`
cat <<EOF
Argumentos: $cmd [-f file] mount|umount|init
-h : Muestra esta ayuda
-f : Indica el fichero de claves a usar. Si se omite
usará ~/.claves.img
init : Inicializa un nuevo fichero criptográfico.
mount : Monta el fichero critográfico, en el directorio
~/.claves_mnt_point
umount : Desmonta el fichero critográfico.

Cuando alguna de estas opciones pida una contraseña, nos estará
pidiendo la contraseña del fichero criptográfico.
EOF
exit 1
}


# -----------------------------------------------
# init(): Inicializar el fichero, con 5MB
# Recibe como argumento el fichero criptográfico.
_init() {
dd if=/dev/zero of=$1 bs=1M count=$sizeDefault
losetup $loDevice $1

cryptsetup -y create $mapperDevice $loDevice
mkfs.ext3 /dev/mapper/$mapperDevice
}


# -----------------------------------------------
# mount(): Montar el fichero criptográfico, y abrirlo.
# Recibe como argumento el fichero criptográfico.
_mount() {
mkdir $defaultDir -p
losetup $loDevice $1 2>/dev/null

cryptsetup -y create $mapperDevice $loDevice
mount /dev/mapper/$mapperDevice $defaultDir
}


# -----------------------------------------------
# umount(): Desmontar el fichero criptográfico.
_umount() {
umount /dev/mapper/$mapperDevice
cryptsetup remove $mapperDevice
}


# ===============================================
# MAIN
# ===============================================

# Comprobar que se tiene instalado "cryptsetup"
_Crypt=$(type cryptsetup 2>/dev/null)
if [ "$_Crypt" = "" ]
then
echo "Error. Debe instalar el paquete 'cryptsetup'"
exit 3
fi

# Inicializar
Operation="help"
File=$defaultFile

# Recorrer argumentos...
while [ "$1" != "" ]
do
arg=$(echo $1 | tr [A-Z] [a-z])
if [ "$arg" = "-f" ]
then
File=$2
shift
elif [ "$arg" = "mount" ]
then
Operation="mount"
elif [ "$arg" = "umount" ]
then
Operation="umount"
elif [ "$arg" = "init" ]
then
Operation="init"
elif [ "$arg" = "-h" ]
then
Operation="help"
else
echo "Error: argumento [$arg] desconocido" >&2
echo "Use el modificador -h." >&2
exit 2
fi
shift
done

# Insertar el modulo de criptografía...
modprobe aes 2>/dev/null

# Procesar el argumento
case $Operation in
mount)
_mount $File
;;
umount)
_umount
;;
init)
_init $File
;;
help)
_help
;;
esac


Deberíamos almacenarlo en /etc/init.d/cryptoLoopFile.

device-mapper en RedHat 4 con multipath

Describe cómo configurar y manipular device-mapper en RedHat4, como software MultiPath para el almacenamiento en S.A.N.

Ignacio Barrancos Martínez
20/Marzo/2007

1. Introducción

Device-Mapper es un nuevo componente del kernel de Linux en la rama 2.6, que permite manejar volúmenes lógicos. Esto es un requisito cuando se usa LVM2 y EVMS. Sobre él, se podrá configurar device-mapper-multipath que es un software libre que viene a sustituir PowerPath de EMC y a Secure-Path de HP.

Las ventajas de usar este software las podríamos enumerar en:

  • Permite mezclar HBAs de diferentes modelos, fabricantes, velocidades, etc.

  • Permite mezclar cabinas de almacenamiento en un mismo servidor.

  • Permite que el sistema de archivos raíz se configure sobre la SAN

  • No hay que pagar licencias de uso.

1.1. Requisitos

Para poder configurar device-mapper en RedHat4 se necesitará de la RH4 Update 2 o superior: las otras versiones anteriores a esta no funcionan correctamente.

Para configurarlo deberá instalar los paquetes device-mapper y device-mapper-multipath que vienen con su distribución de RedHat.

Otro tema importante sobre esto es que las cabinas de almacenamiento deberían funcionar en activo-activo. En cabinas Simmetrix, esto es así, pero en equipamientos de gama inferior como Clariion y EVA de HP no siempre es así y lo habitual es que las controladoras estén en activo-pasivo. Mientras en las primeras las dos contraladoras están trabajando, una controladora se encarga de un conjunto de discos y la otra del otro conjunto (si una cae, la que queda viva asume el control de lo que llevaba la otra), para el segundo caso (HP), una controladora está parada esperando a que caiga completamente la primera. Para el segundo caso no he encontrado ejemplos de configuración, si no es con un Firmware 4 o superior, aunque parece que sí hay ejemplos documentados de configuración para Clariion.

1.2. Para saber más

Podrá encontrar más documentación sobre device-mapper consultando los siguientes documentos:

2. Instalación y configuración

Lo primero que debe hacerse es instalar el paquete con el demonio multipath. Para ello, siga la siguiente secuencia de pasos:

  1. Instale los paquetes de device-mapper device-mapper y device-mapper-multipath, bien vía NFS o YUM, de la distribución que esté usando ...

    mount -t nfs rhupasa:cpqrdp /mnt/nfs
    cd /mnt/nfs/rhes4u3/RedHat/RPMS/
    rpm -Uvh device-mapper-multipath-0.4.5-12.0.RHEL4.i386.rpm

    Lo habitual será que ya cuente con el paquete device-mapper instalado.

  2. Configure el driver de QLogic para que no haga Fail-Over, editando el fichero /etc/moules.conf, recreando el initrd, y luego reiniciando el equipo.

    La secuencia de pasos a seguir sería la siguiente:

    • Comprobar que tenemos el driver en failover, ejecutando el siguiente comando, y observando que la versión del driver termina en -fo.

      cat /proc/scsi/qla2xxx/?  | grep Driver
    • Editar el fichero /etc/modprobe.conf, y asegurarse de eliminar las referencias a la confoiguración del driver de qlogic, de forma que las únicas referencias que aparezcan al driver de QLogic, sean ...

      alias scsi_hostadapter1 qla2xxx_conf
      alias scsi_hostadapter2 qla2xxx
      alias scsi_hostadapter3 qla2300
      alias scsi_hostadapter4 qla2400
      alias scsi_hostadapter5 qla6312

      Ahora, introduzca la siguiente línea de configuración en el fichero /etc/modprobe.conf, con el fin de que no aparezcan los errores esporádicos kernel: SCSI error : <X 0 0 Y> return code = 0x20000 que aparecen en /var/log/messages,

      options qla2xxx ql2xprocessrscn=1
    • Reupere los drivers de QLogic que proporciona RedHat con el kernel de la distribución...

      for i in $(find /lib/modules/`uname -r` -name "qla*orig")
      do
      F=`basename $i .orig`
      D=`dirname $i `
      mv $D/$F $D/$F.hp-psp
      mv $i $D/$F
      done
    • Regenere las dependencias de los módulos y recree la imagen initrd del kernel. Luego reinicie el equipo.

      depmod -a 

      cd /boot
      mv initrd-$(uname -r).img initrd-$(uname -r).img-instalacion
      mkinitrd -v initrd-$(uname -r).img $(uname -r)

      reboot
  3. Edite el fichero /etc/multipath.conf, y realice los siguientes cambios:

    • Comente la primera sección donde se define blacklist. La sección blacklist le dice al software qué dispositivos scsi no debe controlar mediante multipath: Estos son los dispositivos locales (cdroms, discos duros).

      Comente las líneas, para que queden como sigue:

      #devnode_blacklist {
      # devnode "*"
      #}
    • Descomente la segunda sección donde se definen blacklist, para que excluya del multipathing los dispositivos locales.

      Descomente las líneas, para que queden como sigue:

      devnode_blacklist {
      # wwid 26353900f02796769
      devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
      devnode "^hd[a-z]"
      devnode "^cciss!c[0-9]d[0-9]*"
      }

      La línea wwid, permite identificar dispositivos scsi, identificados de forma única por su identificador SCSI. Para averiguar este identificador, ejecutaremos...

      /sbin/scsi_id -g -u -s /block/XXX

      ...donde /block/XXX, podrá consultarlo en /sys/block/XXX, y habitualmente coincidirá con el nombre del dispositivo /dev: sda, sdo, etc. Un primer uso de esto es excluir del multipath los disco de GateKeeper dado que sólo los ve por un camino. Más adelante, veremos cómo configurarlos.

    • Comente la sección defaults. En ella se establecen todos los parámetros que por defecto tendrán los dispositivos que formarán parte del multipath: Al dejarla toda comentada, estos valores se cogerán de los valores que vengan establecidos desde las cabinas del Simmetrix.

      #### defaults {
      #### udev_dir /dev
      #### polling_interval 10
      #### selector "round-robin 0"
      #### path_grouping_policy multibus
      #### getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
      #### prio_callout /bin/true
      #### path_checker readsector0
      #### rr_min_io 100
      #### rr_weight priorities
      #### failback immediate
      #### no_path_retry fail
      #### user_friendly_name yes
      #### }
    • En la sección devices asegúrese de añadir el siguiente bloque, que se supone que realiza un fine-tunning para la configuración del DMX que tenemos desplegada.

      devices{
      device{
      vendor "EMC"
      product "SYMMETRIX"
      path_grouping_policy multibus
      getuid_callout "/sbin/scsi_id -g -u -ppre-spc3-83 -s /block/%n"
      features "1 queue_if_no_path"
      }
      }
  4. Cargue los siguientes módulos del kernel Linux y arranque el demonio multipath mediante:

    modprobe dm-multipath
    modprobe dm-round-robin
    service multipathd start
    multipath -v2
  5. Configure el demonio para que se inicie con el sistema ejecutando:

    chkconfig --level 35 multipathd on
  6. Una vez tenga los discos que definitiamente tendrá presentados el equipo, desmonte todos los puntos de montaje que hagan uso del DMX y ejecute el siguiente bloque:

    multipath -F                    #-Vaciar toda la caché de multipath
    /etc/init.d/multipathd restart #-Reiniciar el demonio de multipath
    multipath -v2 #-Reescanear discos del DMX

Con esto ya deberíamos poder realizar pruebas de deshabilitar y habilitar puertos, para comprobar que el doble camino nos funciona correctamente. Obviamente estas pruebas siempre se han realizado sobre cabinas Symmetrix, nunca sobre Clariion ni EVA.

Tras esto podremos ejecutar los siguientes comandos:

multipath -ll

Nos mostrará todos los caminos y wwid detectados. La salida tendrá esta pinta:

mpath1 (360060480000287971039523544343331)
[size=49 GB][features="0"][hwhandler="0"]
_ round-robin 0 [enabled]
_ 0:0:0:11 sdg 8:96 [active][ready]
_ 1:0:0:11 sdo 8:224 [active][ready]

...donde podemos identificar los siguientes elementos:

  • mpath1, el nombre del pseudo-dispositivo que nos presenta device-mapper, que luego podremos montar mediante /dev/mapper/mpath1

  • 360060480000287971039523544343331 es el wwid (Worl Wide ID) del dispositivo. Este identificador nos lo entrega y denomina la cabina de almacenamiento, y por tanto debe ser el mismo para el mismo volumen en diferentes equipos.

  • size=49 GB, será el tamaño del disco.

  • round-robin 0 [enabled] nos indica el tipo de balanceo que está realizando para el grupo de caminos.

La demás información nos indica el estado de los caminos y el LUN SCSI por el que se presenta el dispositivo al equipo, etc, que no nos será muy relevante en principio. Toda esta explicación la encontramos en el fichero /usr/share/doc/device-mapper-multipath-0.4.5/Multipath-usage.txt.

multipath -F

Borra toda la información sobre caminos, que tengamos en nuestro sistema, una especie de flush de este tipo de información.

multipath -v2

Este comando fuerza un reescaneo a la SAN de los discos y caminos que vemos. Sólo nos mostrará algo la primera vez que se ejecute, las siguientes no, a no ser que hayamos ejecutado previamente multipath -v2.

2.1. Configuración de blacklists. GateKeepers de EMC

Para evitar avisos no deseados en /var/log/messages, conviene excluir de forma explícita los dispositivos de GateKeeper que usa EMC para intercambiar información entre el hosts y la cabina. Es útil cuando se usan comandos SIM_CLI para controlar operaciones de la cabina, pero en servidores de propósito general deben exluirse, porque sólo se ven por un camino y puede resultar molesto que continuamente device-mapper nos esté informando de que tenemos caído un camino.

En general, esto también nos servirá para configurar la sección blacklists, con el fin de excluir dispositivos del multipathing.

  • Recargar la configuración de la cabina en limpio. Quite cualquier referencia a wwid dentro de las secciones blacklists del fichero /etc/multipath.conf, y ejecute...

    /etc/init.d/multipathd stop
    multipath -F
    multipath -v2
    /etc/init.d/multipathd start
  • Averiguar los wwid de los discos de GateKeeper de la cabina: para ello ejecute multipath -ll -v3 y observe la salida:

    load path identifiers cache
    ux_socket_connect error
    #
    # all paths in cache :
    #
    cciss!c0d0 blacklisted
    dm-0 blacklisted
    dm-10 blacklisted
    dm-11 blacklisted
    dm-12 blacklisted
    dm-13 blacklisted
    dm-14 blacklisted
    dm-15 blacklisted
    dm-16 blacklisted
    dm-17 blacklisted
    dm-18 blacklisted
    dm-19 blacklisted
    dm-1 blacklisted
    dm-20 blacklisted
    dm-2 blacklisted
    dm-3 blacklisted
    dm-4 blacklisted
    dm-5 blacklisted
    dm-6 blacklisted
    dm-7 blacklisted
    dm-8 blacklisted
    dm-9 blacklisted
    md0 blacklisted
    ram0 blacklisted
    ram10 blacklisted
    ram11 blacklisted
    ram12 blacklisted
    ram13 blacklisted
    ram14 blacklisted
    ram15 blacklisted
    ram1 blacklisted
    ram2 blacklisted
    ram3 blacklisted
    ram4 blacklisted
    ram5 blacklisted
    ram6 blacklisted
    ram7 blacklisted
    ram8 blacklisted
    ram9 blacklisted
    path sda not found in pathvec

    ===== path info sda (mask 0x5) =====
    bus = 1
    dev_t = 8:0
    size = 92160
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:0
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdb not found in pathvec

    ===== path info sdb (mask 0x5) =====
    bus = 1
    dev_t = 8:16
    size = 4197120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:6
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdc not found in pathvec

    ===== path info sdc (mask 0x5) =====
    bus = 1
    dev_t = 8:32
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:7
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdd not found in pathvec

    ===== path info sdd (mask 0x5) =====
    bus = 1
    dev_t = 8:48
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:8
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sde not found in pathvec

    ===== path info sde (mask 0x5) =====
    bus = 1
    dev_t = 8:64
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:9
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdf not found in pathvec

    ===== path info sdf (mask 0x5) =====
    bus = 1
    dev_t = 8:80
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:10
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdg not found in pathvec

    ===== path info sdg (mask 0x5) =====
    bus = 1
    dev_t = 8:96
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:11
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdh not found in pathvec

    ===== path info sdh (mask 0x5) =====
    bus = 1
    dev_t = 8:112
    size = 5760
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 0:0:0:12
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdi not found in pathvec

    ===== path info sdi (mask 0x5) =====
    bus = 1
    dev_t = 8:128
    size = 92160
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:0
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdj not found in pathvec

    ===== path info sdj (mask 0x5) =====
    bus = 1
    dev_t = 8:144
    size = 4197120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:6
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdk not found in pathvec

    ===== path info sdk (mask 0x5) =====
    bus = 1
    dev_t = 8:160
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:7
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdl not found in pathvec

    ===== path info sdl (mask 0x5) =====
    bus = 1
    dev_t = 8:176
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:8
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdm not found in pathvec

    ===== path info sdm (mask 0x5) =====
    bus = 1
    dev_t = 8:192
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:9
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdn not found in pathvec

    ===== path info sdn (mask 0x5) =====
    bus = 1
    dev_t = 8:208
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:10
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdo not found in pathvec

    ===== path info sdo (mask 0x5) =====
    bus = 1
    dev_t = 8:224
    size = 103941120
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:11
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    path sdp not found in pathvec

    ===== path info sdp (mask 0x5) =====
    bus = 1
    dev_t = 8:240
    size = 5760
    vendor = EMC
    product = SYMMETRIX
    rev = 5671
    h:b:t:l = 1:0:0:12
    tgt_node_name =
    path checker = readsector0 (internal default)
    state = 2
    #
    # all paths :
    #
    0:0:0:0 sda 8:0 [ready] EMC /SYMMETRIX /5671
    0:0:0:6 sdb 8:16 [ready] EMC /SYMMETRIX /5671
    0:0:0:7 sdc 8:32 [ready] EMC /SYMMETRIX /5671
    0:0:0:8 sdd 8:48 [ready] EMC /SYMMETRIX /5671
    0:0:0:9 sde 8:64 [ready] EMC /SYMMETRIX /5671
    0:0:0:10 sdf 8:80 [ready] EMC /SYMMETRIX /5671
    0:0:0:11 sdg 8:96 [ready] EMC /SYMMETRIX /5671
    0:0:0:12 sdh 8:112 [ready] EMC /SYMMETRIX /5671
    1:0:0:0 sdi 8:128 [ready] EMC /SYMMETRIX /5671
    1:0:0:6 sdj 8:144 [ready] EMC /SYMMETRIX /5671
    1:0:0:7 sdk 8:160 [ready] EMC /SYMMETRIX /5671
    1:0:0:8 sdl 8:176 [ready] EMC /SYMMETRIX /5671
    1:0:0:9 sdm 8:192 [ready] EMC /SYMMETRIX /5671
    1:0:0:10 sdn 8:208 [ready] EMC /SYMMETRIX /5671
    1:0:0:11 sdo 8:224 [ready] EMC /SYMMETRIX /5671
    1:0:0:12 sdp 8:240 [ready] EMC /SYMMETRIX /5671
    params = 0 0 1 1 round-robin 0 2 1 8:32 100 8:160 100
    status = 1 0 0 1 1 A 0 2 0 8:32 A 0 8:160 A 0
    ===== path info sdc (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343239 (cache)
    ===== path info sdk (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343239 (cache)
    mpath2 (360060480000287971039523544343239)
    [size=49 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:7 sdc 8:32 [active][ready]
    _ 1:0:0:7 sdk 8:160 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:16 100 8:144 100
    status = 1 0 0 1 1 A 0 2 0 8:16 A 0 8:144 A 0
    ===== path info sdb (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 3600604800002879710394d4952304541 (cache)
    ===== path info sdj (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 3600604800002879710394d4952304541 (cache)
    mpath1 (3600604800002879710394d4952304541)
    [size=2 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:6 sdb 8:16 [active][ready]
    _ 1:0:0:6 sdj 8:144 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:0 100 8:128 100
    status = 1 0 0 1 1 A 0 2 0 8:0 A 0 8:128 A 0
    ===== path info sda (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 36006048000028797103956434d303032 (cache)
    ===== path info sdi (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 36006048000028797103956434d303032 (cache)
    mpath0 (36006048000028797103956434d303032)
    [size=45 MB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:0 sda 8:0 [active][ready]
    _ 1:0:0:0 sdi 8:128 [active][ready]

    params = 0 0 1 1 round-robin 0 1 1 8:240 100
    status = 1 0 0 1 1 A 0 1 0 8:240 A 0
    ===== path info sdp (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039474b50334435 (cache)
    mpath8 (360060480000287971039474b50334435)
    [size=2 MB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 1:0:0:12 sdp 8:240 [active][ready]

    params = 0 0 1 1 round-robin 0 1 1 8:112 100
    status = 1 0 0 1 1 A 0 1 0 8:112 A 0
    ===== path info sdh (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039474b50334433 (cache)
    mpath7 (360060480000287971039474b50334433)
    [size=2 MB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:12 sdh 8:112 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:96 100 8:224 100
    status = 1 0 0 1 1 A 0 2 0 8:96 A 0 8:224 A 0
    ===== path info sdg (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343331 (cache)
    ===== path info sdo (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343331 (cache)
    mpath6 (360060480000287971039523544343331)
    [size=49 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:11 sdg 8:96 [active][ready]
    _ 1:0:0:11 sdo 8:224 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:80 100 8:208 100
    status = 1 0 0 1 1 E 0 2 0 8:80 A 0 8:208 A 0
    ===== path info sdf (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343246 (cache)
    ===== path info sdn (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343246 (cache)
    mpath5 (360060480000287971039523544343246)
    [size=49 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [enabled]
    _ 0:0:0:10 sdf 8:80 [active][ready]
    _ 1:0:0:10 sdn 8:208 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:64 100 8:192 100
    status = 1 0 0 1 1 A 0 2 0 8:64 A 0 8:192 A 0
    ===== path info sde (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343244 (cache)
    ===== path info sdm (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343244 (cache)
    mpath4 (360060480000287971039523544343244)
    [size=49 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:9 sde 8:64 [active][ready]
    _ 1:0:0:9 sdm 8:192 [active][ready]

    params = 0 0 1 1 round-robin 0 2 1 8:48 100 8:176 100
    status = 1 0 0 1 1 A 0 2 0 8:48 A 0 8:176 A 0
    ===== path info sdd (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343242 (cache)
    ===== path info sdl (mask 0x8) =====
    getprio = /bin/true (internal default)
    prio = 0
    uid = 360060480000287971039523544343242 (cache)
    mpath3 (360060480000287971039523544343242)
    [size=49 GB][features="0"][hwhandler="0"]
    _ round-robin 0 [active]
    _ 0:0:0:8 sdd 8:48 [active][ready]
    _ 1:0:0:8 sdl 8:176 [active][ready]

    Estos discos serán los dos de 2MB que veremos por un sólo camino, y el de 45MB. En la salida del comando son sdh, sdp y sda-sdi. Los discos de GateKeeper de 2MB tendrán wwid diferentes en los diferentes nodos, porque se trata de discos/volúmenes diferentes.

  • Añadir los wwid a la configuración del fichero /etc/multipath.conf dentro de la sección blacklist. Para el ejemplo, deberíamos dejar nuestra sección blacklist como...

    devnode_blacklist {
    #- Excluimos el GateKeeper 2MB (/block/sdp)
    wwid 360060480000287971039474b50334435
    #- Excluimos el GateKeeper 2MB (/block/sdh)
    wwid 360060480000287971039474b50334433
    #- Excluimos el GateKeeper 45MB ( /dev/sda - /dev/sdi)
    wwid 36006048000028797103956434d303032

    devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
    devnode "^hd[a-z]"
    devnode "^cciss!c[0-9]d[0-9]*"
    }
  • Aplicar los cambios ejecutando:

    multipath -F
    multipath -v2

2.2. Uso de alias para los pseudo-dispositivos mpathXXX

Podra darse el caso de que un mismo pseudo-device (un mismo wwid) en diferentes nodos se viera en diferente mpath: Esto puede ser crítico en la configuración de clusters, dado que estarían accediendo a diferentes volúmenes de almacenamiento según el nodo en el que estuviéramos ejecutando la aplicación. Esto no significa que el mismo volumen en diferentes nodos tenga diferente wwid: el wwid lo define la cabina, no el software, por lo que siempre debe conservarse.

Con el fin de forzar la asociación wwid-mpath se puede usar las claúsulas ALIAS en el fichero multipath. Para ello...

  • Averigüe el wwid del volumen al que quiere definirle el alias. Puede usar el comando multipath -ll para ello y fijarse en la primera línea.

  • Añada el alias a la configuración del fichero /etc/multipath.conf creando una nueva subsección multipath dentro de la sección multipaths. Para el ejemplo, deberíamos dejar nuestra sección blacklist como...

    multipaths {
    multipath {
    wwid 360060480000287971039523544343239
    alias symx00
    }
    }
    Importante
    Importante

    Puede encontrar todas las posibilidades de configuración para /etc/multipath.conf, en /usr/share/doc/device-mapper-multipath-0.4.5/multipath.conf.annotated.

  • Aplicar los cambios ejecutando:

    multipath -F
    multipath -v2

2.3. Configuración de ASM para Oracle 10G con pseudo-dispositivos

Si utilizamos este tipo de dispositivos con los volumenes ASM en Oracle 10G, hay que configurar ASMLIB para que reconozca estos dispositivos antes que los /dev/sdxxx. Con esto nos aseguramos que los volumenes ASM utilicen los dispositivos multipath. Esto se hace de manera sencilla en el fichero /etc/sysconfig/oracleasm modificando las entradas ORACLEASM_SCANORDER y ORACLEASM_SCANEXCLUDE para que detecte antes los dispositivos /dev/dm-XXXX y que excluya los /dev/sdXXX. A continuación se muestra como debe configurarse:

# # This is a configuration file for automatic loading of the Oracle 
# Automatic Storage Management library kernel driver. It is generated
# By running /etc/init.d/oracleasm configure. Please use that method
# to modify this file
#
# ORACLEASM_ENABELED: 'true' means to load the driver on boot.
ORACLEASM_ENABLED=true
# ORACLEASM_UID: Default user owning the /dev/oracleasm mount point.
ORACLEASM_UID=oracle
# ORACLEASM_GID: Default group owning the /dev/oracleasm mount point.
ORACLEASM_GID=dba
# ORACLEASM_SCANBOOT: 'true' means fix disk perms on boot
ORACLEASM_SCANBOOT=true
# ORACLEASM_CLEARBOOT: 'true' means clean old disk perms on boot
ORACLEASM_CLEARBOOT=true
# ORACLEASM_SCANORDER: Matching patterns to order disk scanning
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Matching patterns to exclude disks from scan
ORACLEASM_SCANEXCLUDE="sd"

Importante
Importante

Para más detalles consultar la nota de METALINK número 394956.1

2.4. Tests de comprobación

A finales de Junio de 2007 y para la migración a MySAP ERP 2005, sobre Oracle RAC 10.2.0.2 con OCFS2 y almacenamiento remoto en el Simmetrix DMX800, se realizaron tests de comprobación del failover y de recuperación de caminos. Estas pruebas fueron las siguientes:

  1. Desmontar todos los volúmenes del Simmetrix, y ejecutar las siguientes instrucciones, con el fín de partir de una situación estable y limpia:

    multipath -F             
    /etc/init.d/multipathd restart
    multipath -v2

    Si sospecha que puede ir algo mal, ejecute el comando sysreport o sosreport (RHEL5) y siga las instrucciones. Cuando haya terminado y renómbrelo, con un nombre significativo, que luego le permita identificarlo para enviarlo a la gente de RedHat.

  2. Montar uno o más de los volúmenes del DMX, y lanzar el siguiente comando:

    dd if=/dev/zero of=/sapmnt/PRO/fichero bs=512 count=100000000000000

    ...donde /sapmnt/PRO es el punto de montaje de disco del DMX. Durante las pruebas de conexión/desconexión de fibras, no debería cortarse la ejecución de este comando, ni deberían encontrarse errores.

  3. Desde los switches de fibra, se deshabilita el puerto de la HBA0: esto es mejor que quitar y poner el cable de forma física, porque puede que no quede correctamente conectado, y comience a generar errores de I/O, o incluso se deteriore el cable o los conectores.

    Observe la salida de los comandos multipath -ll y tail -f /var/log/messages, en ventanas o terminales diferentes, con el fín de tener instantáneas del estado del equipo.

    _ round-robin 0 [active]
    _ 1:0:0:11 sdai 66:32 [active][ready]
    _ 0:0:0:11 sdk 8:160 [failed][faulty]
  4. Pasados unos minutillos (más de uno y menos de cinco), habilite de nuevo el puerto, para que recupere el Link. El comportamiento es que recupere el link ...

    _ round-robin 0 [active]
    _ 1:0:0:11 sdai 66:32 [active][ready]
    _ 0:0:0:11 sdk 8:160 [failed][ready]

    ...y el camino completamente...

    _ round-robin 0 [active]
    _ 1:0:0:11 sdai 66:32 [active][ready]
    _ 0:0:0:11 sdk 8:160 [active][ready]
  5. Pasados unos minutillos (más de uno y menos de cinco), deshabilite el otro puerto, el que se corresponderá a la HBA-1, y observe el comportamiento, que deberá ser análogo al de esta primera fibra.

  6. Pasados otros pocos minutillos vuelva habilitar el puerto y espere ver cómo se recupera automáticamente el camino.

    En caso de que no se de este comportamiento, vuelva a realizar otro sysreport o sosreport, y renombrarlos para adjuntarlos al número de incidencia con RedHat.

Estas pruebas se pueden realizar mientras que se hace un import de una BBDD, o similar, de forma que haya algún proceso que saque máximo rendimiento de I/O a los diferentes discos, y no sea todo el acceso de forma secuencial, que siempre es más lineal y previsible: Un acceso a Base de datos, es aleatorio y más imprevisible. También sería recomendable hacer los siguientes tests:

  • Repetir las pruebas quitando zonas en lugar de deshabilitar puertos.

  • Repetir pruebas dejando una sola fibra durante más de un día.

  • Repetir pruebas con diferentes intervalos de tiempo a la hora de quitar las fibras.

Las pruebas que se realizaron para la migración de SAP, generaron los siguientes tickets en nuestro soporte TAM:

  • Issue 124900, donde se detectaron los primeros problemas y se pedía que nos aconsejaran qué hacer con la configuración de los drivers de qlogic, y multipath.conf. Conclusiones:

    1. Dejar la sección defaults de multipath.conf comentada: El demonio obtiene su configuración desde la cabina.

    2. No incluir referencias de configuración del driver de qlogic en /etc/modprobe.conf, quitar cualquier configuración del driver y referencia que meta el PSP.

    3. La BIOS y versión del firmware de las QLogic, no se toca a no ser que HP diga otra cosa, en principio, y según comentó vía telefónica, EMC no tiene por qué opinar aquí, nos dijo: el proveedor del hardware de la tarjeta, no el de la cabina.

    4. Si se usan los drivers de HP que vienen con el PSP, RedHat no nos dá soporte, hay que ir entonces a HP.

    5. Una vez se tengan los discos presentados que finalmente se usarán en el servidor, deberíamos ejecutar:

      multipath -F             
      /etc/init.d/multipathd restart
      multipath -v2
  • Issue 125389, donde se detectaron contínuos SCSI error : <X 0 0 Y> return code = 0xZ0000, y sobre ello se sacaron las siguientes conclusiones:

    1. Cuando se tienen SCSI error : <X 0 0 Y> return code = 0x20000 (la X es el camino, mientras la Y es el disco), de manera exporádica es por un tema interno del driver y es normal. Se omiten añadiendo a /etc/modprobe.conf las siguientes opciones al driver:

      options qla2xxx ql2xprocessrscn=1

      Si aún con esta opción siguen apareciendo los mensajes de código SCSI 0x20000, será porque haya un problema en la fibra o en el Switch, como ya nos pasó. Si el problema estuviera en los discos de la cabina, todos los equipos del cluster que vieran esos volúmenes deberían presentar estos errores, incluso muchos más. Si el problema estuviera en el switch deberían estar reflejados en las estadísticas internas del switch de fibra y debería haber más de un equipo afectado, y en cualquier otro caso, deberíamos fijar nuestra atención en el GBiC, en la fibra, en la conexión, o en la qlogic.

    2. Cuando se tienen SCSI error : <X 0 0 Y> return code = 0x10000, son problemas de conectividad a los discos: Estos son habituales cuando se desconectan los puertos del FC-switch y permanecen quitados. El que sigan apareciendo estos mensajes, es normal, porque al parecer es la forma en la que la cabina desea que la interrogue, que es consultando el primer sector. Esto se sabe ejecutando el comando multipath -v3 y fijándonos en el valor del parámetro path checker,

      path checker = readsector0 (internal default)
  • Issue 125509, donde se reportaron unos errores raros sobre OCFS2 que no conseguimos reproducir, pero que nos sirvieron para obtener las siguientes conclusiones:

    1. Para aumentar el nivel de logs del driver de QLogic, deberemos añadir a /etc/modprobe.conf, la opción extended_error_logging=1 dentro de las opciones de qla2xxx.

    2. Para aumentar el nivel de logs del demonio de multipath debemos añadir en la línea 91 aproximadamente del fichero /etc/rc.d/init.d/multipathd, la opción -v3 de forma que el arranque del demonio quede como daemon $DAEMON -v3.

2.4.1. Qué información enviar a RedHat en caso de encontrarse fallos

Se deben enviar los siguientes archivos:

  1. Los dos sysreports: el previo a las pruebas y el posterior.

  2. El fichero /var/log/messages

  3. El fichero /etc/modprobe.conf

  4. La configuración de multipath /etc/multipath.conf

  5. El resultado de ejecutar /usr/sbin/dmidecode

  6. Un fichero comprimido con /var/lib/multipath

    tar czvf var_lib_multipath.tgz /var/lib/multipath/*
  7. La salida de ejecutar multipath -ll

  8. El resultado de ejecutar multipath -v3

Todo esto en Inglés (no muy bueno), sería algo así:

I have attached three new files:

+ PREVIO-sysreport-root.XXXX.tar.bz2
- A sysreport previous to the test.

+ POSTERIOR-sysreport-root.XXXX.tar.bz2
- A sysreport that we have executed after the test.

+ The file recopilacion.tgz, that contains:

- messages
* A copy of /var/log/messages

- modprobe.conf
* A copy of /etc/modprobe.conf

- multipath.conf
* Configuration file /etc/multipath.conf

- output_dmidecode.txt
* Results of execute: "/usr/sbin/dmidecode"

- var_lib_multipath.tgz
* Results of "tar czvf var_lib_multipath.tgz /var/lib/multipath/*"

- output_multipath_-ll.txt
* Results of "multipath -ll"

- output_multipath_-v3.txt
* Results of "multipath -v3"


Problemillas del día a día

Descripción de la solución a varios problemas típicos que nos ocurren a diario al trabajar linux.

Ignacio Barrancos Martínez
23/Marzo/2007

1. Introducción

A diario, los técnicos de sistemas que tenemos que trabajar con Linux nos encontramos problemillas que como podemos vamos solucionando, y nunca se documentan porque son parte del día a día y lo asumimos como tal. En este documento he ido colocando esas cosillas que nos suceden a diario y que nunca terminan por documentarse, y que por tanto, siempre debemos andar reinventando y redescrubiendo, y al final nos obligan a perder el mismo tiempo muchas veces.

2. Trabajando con LVM2

LVM viene de Logical Volume Manager, y nos permite gestionar almacenamiento a lo bruto, de forma dinámica de la misma manera que se hacía en HP-UX y lo hacen los discos dinámicos de Windows. No voy a disertar sobre esto, en http://tldp.org/HOWTO/LVM-HOWTO/ está mucho mejor explicado todo. La chicha del asunto está en el capítulo 11: Common Tasks.

2.1. Ampliar volúmenes físicos: Dar más disco a VG_Sistema

En máquinas virtuales suele pasar que necesitamos agregar un nuevo volumen VMware de almacenamiento, porque las plantillas quedan escuetas en cuanto al almacenamiento. También en los Blades a veces se necesita disponer del espacio sin particionar en los discos locales, para adjuntarlo al volumen físico y hacer crecer alguno de los volúmenes lógicos.

  • Añada el nuevo dispositivo. Si es una máquina virtual párela y agregue el nuevo volumen. Luego cree la partición (con tipo 8e) y si está disponible, ejecute partprobe (para no tener que reiniciar, y releer la tabla de particiones).

    Para ilustrar el ejemplo, supondremos que estamos añadiendo /dev/sdb, sobre el que hemos definido una nueva partición /dev/sdb1.

  • Preparar la partición y añadir a VG_Sistema mediante ...

    pvcreate /dev/sdb1
    vgextend VG_Sistema /dev/sdb1

Podría ser de utilidad mirar http://kbase.redhat.com/faq/FAQ_79_3744.shtm.

2.1.1. Kernel panics al reiniciar el equipo con RH4, y haber ejecutado fdisk

En algunos casos, al ejecutar fdisk para crear la nueva partición, y darnos el aviso de que debemos rebotar para que se refresque la tabla de particiones, obedientemente lo hacemos y al reiniciar nos genera un kernel panic, que nos dice que no encuentra el VG_Sistema, por no sabemos qué rollo del UUID: no tenemos que reiniciar.

Pantallazo con el panic en el arranque
Figura 1: Pantallazo con el panic en el arranque

Tras salir de fdisk, debemos ejecutar partprobe para que se refresque la tabla de particiones del disco, sin rebotar. Luego es necesario ejecutar vgscan, y ejecutar después pvcreate. Si al ejecutarlo se tienen errores de que no encuentra el volumen VG_Sistema, vuelva a ejecutar vgscan. Una vez no se obtengan errores, ejecute el vgextend, y ya podrá reiniciar.

Si se genera el error tendrá que reiniciar el equipo con la iso del primer CD de RedHat, y cuando le pregunte si quiere instalar, escriba linux rescue y luego pulse enter. Siga las instrucciones y deshaga la partición que creó. Luego reinicie.

Encontrará ISOS de RedHat 3 y RedHat 4 en la unidad D: de Trapo dentro del directorio D:Rescate-redhat. Es importante que si el equipo es RedHat4 arranque con el CD de RedHat4, y si es RH3 con el de RH3, por la versión de LVM que usa cada uno.

2.2. Ampliar volúmenes lógicos: dar más disco a un LV_XXXX y redimensionado del filesystem

Cuando trabajamos con volúmenes lógicos es habitual que se nos llene alguna de las particiones que tenemos montada sobre un volúmen lógico. Una vez se tiene de un volúmen físico con espacio suficiente, que podremos comprobar ejecutando vgdisplay y fijarnos en el campo Free PE / Size, deberemos asignarle espacio al volumen lógico que queremos ampliar, que es lo que haremos a continuación: Si no se tuviera espacio en el volumen físico, tendrá que ampliar el famoso VG_Sistema, explicado líneas antes.

Para ampliar el volumen lógico, ejecute...

  1. Extienda el volúmen mediante:

    lvextend -L+XXXG /dev/VG_Sistema/LV_YYY

    ...donde XXX son la cantidad de GigaBytes que quiere extenderlo, y LV_YYY es el nombre del volumen lógico que desea extender.

  2. Extienda el sistema de archivos. Si está usando RedHat3 o inferior deberá hacerlo en frío, desmontando la partición o si se trata de /, /usr, /var o similar reiniciando en modo single. Si fuera sin reinicio, podría ejecutar:

    lsof | grep opt | awk '{print $2}' | xargs kill -9
    umount /opt
    e2fsck -f /dev/VG_Sistema/LV_Opt
    resize2fs /dev/VG_Sistema/LV_Opt
    mount /opt

    ...imaginado que se quiere redimensionar /opt. Si está en RedHat4 podrá hacerlo en caliente sin reinicio, y bastará con que ejecute:

    ext2online /dev/VG_Sistema/LV_Opt


Drivers de QLogic y matrices de certificación

Describe los procedimientos que tenemos que hacer para saber los drivers de QLogic que debemos usar y versiones con Linux

Ignacio Barrancos Martínez
17/Enero/2008

1. Introducción

Ya he comentado alguna vez en mi entorno cercano, con más WhiteLabel que hielo en mi cuerpo, que las matrices de certificación de los fabricantes de hardware, acabarán por destruir a Linux a poco que se le propongan, porque sus técnicos de soporte o no están bien formados, o no tienen accesible toda la documentación: Al final, la configuración de estas cosas depende de los administradores de sistemas a los que nos colocan estos cacharros, teniendo que soportar que los comerciales que se han llenado la saca nos insulten.

Bueno, estoy harto de esto, e intentaré dejar aquí, el proceso que finalmente realizan los arquitectos de almacenamiento, para decirme qué version de driver debo usar en mi RedHat Linux, qué versión de firmware de la controladora y con qué opciones ... pero eso sí ... cobrándonos a 300€/hora.

El criterio general sería el siguiente:

  1. Cabinas Activo/Pasivo, como HPEVA5000 con firmware version 3.X. Debemos usar los drivers de QLOGIC que nos sugiere HP, configurados en modo failover=1, sin ningún software de Multipath.

  2. Cabinas Activo/Activo, como EMC Symmetrix DMX800. Deberíamos usar software de multipath como DM-MP de RedHat o PowerPath de EMC. Los drivers de QLOGIC deben estar configurados sin failover, porque él propio driver quien se encargue de realizar el failover ante un fallo en un camino. Para ello deberíamos usar el driver que propone EMC en sus matrices.

El problema de estos casos es cuando las matrices no están muy actualizadas, como el caso de EMC que sólo tiene actualizadas hasta el año 1981 (el partNumber 361426-B21 de las tarjetas que vienen con HP BL20pG3, a día de hoy, 16 de Enero de 2008, todavía no está disponible), o cuando hemos comprobado que la combinación que estamos probando no termina de funcionar bien. En este caso, puede ser una buena cosa ir a la página Web de soporte de QLogic y examinar sus matrices de compatibilidad y configuraciones recomendadas.

En cualquier caso, siempre deberíamos saber el PartNumber de la QLOGIC, porque es un follón total: HP los llama Mezzanine, EMC los llama QLAXXXX, la propia Qlogic utiliza otra nomenclatura, etc... Es un lío, y la única forma de asegurarse de que estamos hablando de la misma tarjeta es a través de este PartNumber. Para conocerlo, yo miro la factura de compra, nada de PDFs con especificaciones de los Blades y demás... nada de todo eso vale para nada: Lo que se ha pagado es lo que vale.

2. Matriz de certificación de HP

Para comprobar la versión de driver sugerida por HP, hay que hacer lo siguiente:

  1. Ir a la página de HP: "http://www.hp.com"

  2. Buscar la sección Software & Driver Downloads y pinchar en ella.

  3. En el cuadro de búsqueda for product teclear el PartNumber y pulsar el botón >>.

  4. Lo normal será encontrarnos con el dibujo de nuestra tarjeta, y una sección Select operating system. En ella pinchar sobre la versión del sistema operativo en el que estamos interesados, en nuestro ejemplo, lo haremos sobre Red Hat Enterprise Linux 4 (x86).

  5. En la tabla Driver - Storage Controllers - FC HBA descargaremos el último y lo instalaremos.

Una vez hemos descargado los drivers de HP, convendría hacer copia de seguridad de todos los ficheros de configuracion y binarios. Para ello,

cd 
mkdir backup_antes_ignacio
cd backup_antes_ignacio

mkdir etc
cp /etc/modprobe* /etc/multipath* etc/

mkdir kernel
for i in `find /lib/modules -name "qla2xxx" | cut -c14- `
do
mkdir kernel/$i -p
cp /lib/modules/$i/* -R kernel/$i
done

mkdir boot
cp -R /boot/* boot/

Una vez hayamos realizado este backup, partimos de que tendremos el driver descargado de la página de HP, en el directorio /opt/software/Drivers_QLogic/ en formato tgz. Lo descomprimiremos, leeremos el README que venga en el fichero y procederemos como se indique. Probablemente sea ejecutando:

./INSTALL

Cuando queramos desinstalar el driver, tendremos que ejecutar, probablemente

./INSTALL -u

Mirarse el script o el README para ver lo que hay en él.

2.1. Actualización de la BIOS de QLogic

Para actualizar la BIOS de la QLogic a la versión recomendada por HP, si quisiéramos montar Fail-Over, deberíamos descargar la versión que recomienda el propio HP. Esto se hace repitiendo los mismos pasos que habíamos hecho para descargar el driver, pero en vez de ir a la sección de nuestro sistema operativo, haremos click en Cross operating system (BIOS, Firmware, Diagnostics, etc.). Luego, en la tabla BIOS, seleccionaremos el paquete ZIP que incluya BIOS y NVRAM.

Para instalarlos necesitaremos ayudarnos de una máquina VMWare, en principio Workstation, con WindowsXP. Crear una nueva imagen de fichero para la unidad de disco 3"1/2. Conectarla la unidad. Desde el Windows XP acceder a la unidad de disquetes y formatearla indicándole que añada los ficheros de arranque del sistema, para que podamos arrancar el equipo con ese disquete. Cuando esté formateado el disco, descomprimir el contenido del ZIP que nos bajamos de HP en la disquetera A:. Ir a VMWARE y desconectar la unidad para que escriba los cambios al ficherito este de imagen. Con este ficherito, accedemos a la iLO del equipo y lo montamos como Disquete Virtual en el VirtualMedia. Reiniciamos el servidor, y esperamos a que termine cargar desde este disquete. Luego leeremos el README, pero al final tendremos que ejecutar algo como lo siguiente:

hpqutil /i /f
hpqutil /i /u /n hpmezz.dat
hpqutil /i /l /n hpmezz.dat

Al ejecutar estos comandos de esta forma, se tendrá que los valores de la BIOS quedan un poco macarras. Deberíamos afinarlos inspirándonos en las recomendaciones de alguien, aunque probablemente lo mejor será inspirarnos en las recomendaciones que hace QLogic para configuraciones sin multipath, sólo con Fail-Over.

3. Matriz de certificación de EMC

Para comprobar la versión de driver sugerida por EMC, hay que hacer lo siguiente:

  1. Ir a la página de EMC: https://powerlink.emc.com. Pide un Login y un passwd, que imagino, deberíamos tener porque nos lo haya facilitado el contrato de compra desde EMC, y si no pedírlo porque es parte del acceso a soporte de sus cacharros.

  2. En la página que se cargará, ponga el cursor del ratón sobre Soporte, y en el menú que se despliegue vaya a la opción Interoperability and Product Lifecycle Information y luego haga click sobre el submenú E-Lab Interoperability Navigator.

    Acceder al navegador de interoperabilidad
    Figura 1: Acceder al navegador de interoperabilidad
  3. Esto le genererá un ticket de sesión válido para poder abrir el Navegador de interoperabilidad. Haga click sobre el link Lanzamiento de E-Lab Interoperability Navigator, lo que provocará que se le habra en una nueva ventana: Asegúrese de que el bloqueador de pop-ups se lo permite.

    Lanzar el navegador de interoperabilidad
    Figura 2: Lanzar el navegador de interoperabilidad
  4. Haga click en la pestaña que le da acceso al asistente de configuración, haciendo click sobre Wizards.

    Acceda al asistente de configuración
    Figura 3: Acceda al asistente de configuración
  5. En el Step1 y en el combo Storage Array, seleccione Symmetrix DMX/DMX2.

    Acceda al asistente de configuración
    Figura 4: Step1: Seleccionar Symmetrix DMX
  6. En el Step2, deje la topología como FC-SW y seleccione el tipo de switch como Brocade 24000.

    Step2: Seleccionar FC-SW y Brocade 24000
    Figura 5: Step2: Seleccionar FC-SW y Brocade 24000
  7. En el Step3, deberá ir poco a poco seleccionando la configuración para la que desea obtener la matriz de certificación. Lo más importante, es que para el caso de los Blades seleccione en HostBus Adapter: Hewlett Packard y en el Modelo, busque el PartNumber de la tarjeta.

    Step3: Seleccionar la combinación hardware-Linux
    Figura 6: Step3: Seleccionar la combinación hardware-Linux
  8. En la parte derecha, hacer click en Combined Results.

    Abrir la matriz de certificación
    Figura 7: Abrir la matriz de certificación
  9. En la ventana que se le abrirá se le mostrará el informe de compatibilidad. Seleccione el documento en PDF si desea descargarlo y consultarlo. La matriz la encontrará en la página de Base Connectivity, y en una tabla verá que combinaciones de BIOS de Qlogic y Driver necesita establecer.

    Descargar el documento
    Figura 8: Descargar el documento
  10. Descargar el documento
    Figura 8: Descargar el documento

También podrá descargar un documento con todas las matrices y combinaciones (más de 3500 páginas) de estas haciendo click en la pestaña PDFs and Guides.

Ver todos los PDFs
Figura 9: Ver todos los PDFs

4. Matriz de certificación de QLogic

Para saber la matriz de certificación de Qlogic siga la siguiente secuencia de pasos:

  1. Ir a http://support.qlogic.com

  2. En la caja derecha Best Bets hacer click en Drivers, Software and Manuals

  3. En la ventana que se abre nueva ... dentro de la seccion OEM MODELS ... pinchar en el Link EMC

  4. En la seccion EMC Approved Software pinchar en EMC SYMMETRIX, CLARiiON & CELERRA supported software.

  5. En la seccion OEM Blade Servers & Embedded Products hacer click en HP.

  6. En la tabla de modelos, que hay más modelos que chinos en la China, buscar por Part-Number del modelo afectado. En mi ejemplo 361426-B21.

  7. Seccion Boot Code, descargamos el ZIP con la BIOS y la NVRAM recomendada.

  8. Seccion Drivers for 2.6 kernel, descargaremos el ZIP con el driver

    Buscar nuestro sistema RHEL4 U3/U4. De las dos apariciones que encontraremos, descargaremos ZIP de la seccion Linux DKMS, que es un tema para la administracion de módulos del kernel 2.6, mejor que otros.