GCDS 2009 - Día 0: 3 de Julio

Al final tuve la suerte de asistir a Gran Canaria Desktop Submit (GCDS) que por primera vez congregaba a las conferencias anuales de desarrolladores y usuarios de GNOME (Guadec) y KDE (aKademy). En lineas generales y en mi opinión, el evento fue una auténtica maravilla y todo un lujo poder asistir, con un clima excelente, unas instalaciones impecables, una organización perfecta y unas vistas al mar inmejorables. Ya había asistido a la GUADEC de Sevilla en 2002 y la de Vilanova en 2006, pero debo admitir que este evento ha superado, en mi opinión, a todos los anteriores: Los horarios de las conferencias, las salas, el número de fiestas, la cordialidad, el servicio de katering, todo... excelente, una auténtica maravilla.
Llegué a Gran Canaria desde Tenerife el Jueves 2 de Julio, acompañado por mi hermano José Barrancos y aprovechamos el Viernes por la mañana para hacer turismo por la ciudad, una vez que nos encontramos que el registro del evento empezaba por la tarde. A medio día nos reunimos con Rubio en la plaza de San Telmo. Luego buscamos el restaurante El Herreño que nos recomendaron en la Casa de Colón, y comimos fritura de pescado, y probamos el mus de gofio: todo muy bueno a muy buen precio.
Después de comer, fuimos al auditorio a recoger nuestras acreditaciones y los tickets con los que Intel nos invitaba a un café y un helado durante cada uno de los diferentes días, probamos a ver sí podíamos leer el correo: El compañero Carlos Cabezas (r0uzic) captó el instante en el que intentábamos leer el correo.Cuando pudimos leer el correo, visitamos el centro comercial las Arenas (frente al auditorio) para hacer tiempo, tomar unos GinTonics y visitar la exposción de playmobil que había por los pasillos, hasta que llegara la hora de la fiesta Ubuntu subvencionada por Canonical. Esa tarde no había ninguna charla pero durante la noche hubo cerveza y canapés, y además una camiseta de ubuntu de regalo para todos los asistentes.
He hecho una pequeña búsqueda por Internet y he encontrado algunos álbumnes de fotos, con motivo del congreso, aunque probablemente en las próximas semanas haya más, una vez todos lleguemos a casa y haya más tiempo para postear y etiquetar.

Suspender el HP Pavilion dv5-1132es en FedoraCore 10 y Ubuntu 8.10

Esta semana he estado en el GCDS y aunque me he llevado el portátil de trabajo a las Palmas, apenas lo he llevado conmigo durante las charlas, por la incomidad que me suponía estar contínuamente reinciando el sistema. Esto era porque la suspensión del equipo no me funcionaba en Fedora Core 10 ni en Ubuntu 8.10: Cada vez que suspendía, el equipo, al abrir la tapa del portátil para reanudar el sistema me encontraba el siguiente error:

ata1: irq_stat 0x00000040 connection status changed
ata1: SError: { DevExch }
ata1: exception Emask 0x10 SAct 0x0 SError 0x4000000 action 0xe frozen

...y finalmente tenía que reiniciarlo. En resumen: la suspensión del equipo no me funciona en Linux. He estado revisando todo el proceso, que se supone se debe seguir:
  1. Comprobar las recomendaciones que me hace el script quirk-checker.sh. Para ello he tenido que comentar la parte que detecta si estamos usando el driver NVIDIA. Al hacerlo la única recomendación que me hacía era:
    Checking your system...

    WARNING: KVM will not suspend in kernels less than 2.6.23, but should work okay in later kernels.

    Suggestions:

    Add 'SUSPEND_MODULES="kvm_intel kvm"' to /etc/pm/config.d/unload_modules!
    Bueno, el aviso es lógico. Después de hacer lo que me recomendaba, al ejecutar el script obtenía:
    Checking your system...

    Suspend should work
    El problema seguía igual. No funcionaba.
  2. Revisar las opciones de la BIOS, para comprobar que el equipo soporta SATA en modo compatible, como recomendaba en algunos foros. No existen estas opciones entre las opciones de configuración de la BIOS para este modelo.
  3. Cambiar las opciones de arranque del kernel en /etc/grub.conf como recomiendan en algunos foros. Tampoco sirve de nada.
  4. Ir a la web de HP y actualizar la BIOS del equipo y definitivamente eso es lo que me ha servido: Simplemente con subir la versión de la BIOS del Pavilion dv5-1132es a la versión F.16 del 6 de Mayo de 2009, es suficiente. Para ello, claro está he tenido que usar la partición que dejé con Windows Vista que traía el equipo cuando lo compré, porque HP aún no ofrece soporte para Linux en los portátiles, pero si he podido comprobar que ha aumentado el soporte de Linux en servidores a Oracle Unbreakable, Citrix Server, ESX, Ubuntu y Debian.

Si queremos saber qué versión de BIOS usa nuestro equipo, podemos ejecutar el comando lshal | grep system.firmware, y obtendremos algo similar a lo siguiente:
  system.firmware.release_date = '05/06/2009'  (string)
system.firmware.vendor = 'Hewlett-Packard' (string)
system.firmware.version = 'F.16' (string)

Presentar disco de la SAN sin reiniciar el sistema Linux

Antiguamente, cuando teníamos un sistema Linux al que necesitábamos presentarle disco de SAN, necesitábamos reiniciar el sistema para que el sistema reconociera la nueva LUN. Existe un método documentado por RedHat en el que no necesitamos reiniciar el sistema. Si además resulta que tenemos EMC PowerPath como software de MultiPath, tendremos que seguir la siguiente secuencia de pasos:

  1. Lo primero que deberíamos hacer es parar Naviagent. Para ello, quizás tengamos que desmontar todos los volúmenes SAN administrados por PowerPath como pseudodispositivos /dev/emcpowerXX.
    /etc/init.d/naviagent stop
  2. Ahora, sacar copia de seguridad de todos los ficheros de powerpath, por precaución:
    cd ~
    mkdir backup_ppath
    cp /etc/power* /etc/emc* /etc/ppat* ~/backup_ppath
    Se supone que ahora deberíamos parar PowerPath, pero seguramente no nos dejará y no parará, diciéndonos que tenemos dispositivos abiertos todavía.
    /etc/init.d/PowerPath stop
  3. Forzar el reescaneo de la SAN:
    echo "- - -" > /sys/class/scsi_host/host1/scan
    echo "- - -" > /sys/class/scsi_host/host2/scan
    Según estas líneas, se supone que tenemos dos puertos de Fibra conectados a la SAN.
  4. Decirle a PowerPath que refresque la información de los caminos disponibles:
    /etc/init.d/naviagent stop
    powermt display dev=all
    ... a lo que tendremos que prestar atención a la salida del comando y buscar nuestra nueva LUN.
    Pseudo name=emcpowerl
    CLARiiON ID=CK200052700212 [SG_BACKUP]
    Logical device ID=60060160D48815001ACB9729A5A8DC11 [LUN 34]
    state=alive; policy=CLAROpt; priority=0; queued-IOs=0
    Owner: default=SP A, current=SP A Array failover mode: 1
    ==============================================================================
    ---------------- Host --------------- - Stor - -- I/O Path - -- Stats ---
    ### HW Path I/O Paths Interf. Mode State Q-IOs Errors
    ==============================================================================
    1 qla2xxx sdat SP A0 active alive 0 0
    1 qla2xxx sdau SP B1 active alive 0 0
    2 qla2xxx sdav SP A1 active alive 0 0
    2 qla2xxx sdaw SP B0 active alive 0 0
  5. Ya estamos en condiciones de particionar nuestra nueva LUN 34, con el comando fdisk accediendo al pseudodispositivo.
    fdisk /dev/emcpowerl
    Cuando terminemos, si queremos refrescar la información que el kernel tiene sobre la tabla de particiones de este disco, bastará con ejecutar el siguiente comando, y evitarnos reiniciar para ello.
    partprobe

En caso de que tengamos tarjetas Emulex, os recomiendo usar MultiPulse como software MultiPathing, que es toda una maravilla, y para hacer esto mismo bastará con ejecutar:
hp_rescan -a
lssd
La imagen la he sacado de http://www.50micron.com/ via google images

Habilitar SNMP al router Thompson TG585 v7

Esta mañana al intentar conectar a internet me he encontrado que tenía el router desconectado desde las 3 de la mañana. Lo primero que he pensado ha sido que el proveedor no se había podido cobrar del banco y me ha cerrado el grifo. Al acceder a la consola Web me he encontrado que estaba desconectado. He pulsado el botón Connect to DSL y oh maravilla ... ha conectado. Me quedado preocupado. He decido empezar a monitorizar el router por SNMP, y si puedo ya de paso lo integraré con mi demonio de refresco de DynDns. Cuando he intentado conectar por SNMP a mi router Thompson TG585v7 con las consultas:

snmpwalk -c public -v 1 192.168.1.100 .1

snmpwalk -Os -c public -v 1 192.168.1.100
... no he obtenido ninguna respuesta. Para habilitar SNMP en este router tenemos primero que conectar como admin al router vía telnet. Luego ejecutar la siguiente secuencia de comandos:
  1. Habilitar el agente SNMP del router
    service system modify name=SNMP_AGENT state=enabled  log=enabled
  2. Permitir que todos los equipos de mi LAN (192.168.1.0/24) puedan hacer consultas SNMP al router.
    service system ipadd name SNMP_AGENT ip 192.168.1.[1-254]
  3. Impedir que SNMP esté accesible desde Internet, aunque seguramente no funcione, pero más vale prevenir.
    service system ifdelete name=SNMP_AGENT group=wan
  4. Habilitar acceso SNMP a la LAN, aunque tampoco tengo claro que funcione correctamente, pero igual que antes, más vale prevenir:
    service system ifadd name=SNMP_AGENT group=lan
  5. Permitir acceso de lectura a la comunidad public, aunque parece como si usara el nombre de la comunidad como contraseña. Yo lo he hecho aún así lo he hecho.
    snmp community add securityname=ROCommunity communityname=public
  6. Guardar los cambios para que cuando se reinicie el router
    saveall
Podemos saber el listado de IPs configuradas en el router ejecutando la consulta:
snmpwalk -c public -v 1 192.168.1.100 .1.3.6.1.2.1.4.20.1
En el CD de drivers que envía Tele2 con el Router hay un directorio llamado SNMP_MIBs donde encontraremos todas la Mibs para las versiones v1, 2c y 3 del protocolo, que podemos incluirle a nuestro cliente SNMP para indagar en las posibilidades de configuración: toda una maravilla y un detalle por parte del distribuidor. Felicidades.

Icinga: Fork de Nagios

El pasado 6 de Mayo Gerhard Lausser anunció en la lista de desarrolladores de Nagios un nuevo fork del proyecto llamado Icinga. Icinga es una palabra Zulú que podriamos traducir por "busca", "mira", "observa", "examina", y se pronuncia como se lee.

Al parecer el origen de este fork se debe a la pasividad y la baja participación del fundador del proyecto, Ethan Galstad, en el proceso de desarollo durante los últimos meses: Parches que se envían a la lista de desarrolladores y no se aplican, falta de nuevas ideas para Nagios 4, carencia de nuevas API webs que permitan mayor integración, no poder usar el nombre Nagios para usos comerciales (Nagios es marca registrada), y un largo etc, que están permitiendo que le coman terreno otros proyecto similares como: OpenNMS, Zabbix, HypericHQ, Zenoss o PandoraFMS. Esto no ha sentado muy bien al fundador que se queja amargamente de que nadie le avisó antes ni se puso en contacto con él para intentar reconducir la situación, apelando a que existe un problema de comunicación que espera resolver en breve.

El nuevo proyecto tiene planificado publicar la versión 1.0 para Octubre de este año y nace con el objetivo de ser la mejor herramienta de monitorización OpenSource, mejorar la conectividad de Base de Datos, generación de informes, APIs, consola Web (Ajax) etc...

Mi opinión como usuario de Nagios es que esto efectivamente hacía falta: La consola web no está a la altura de la robustez del core, y para el usuario resulta muy tosca y hostil y ni nada intuitiva ni usable. Es cierto que necesita un plan de revisión, modernización y dinamización que lleva la consola web al nivel que debe tener en el año en el que estamos si se le compara con aplicaciones web contemporáneas como Gmail o FaceBook.

Mi opinión como administrador de Nagios, es que tendremos que esperar a ver qué pasa con la versión 1.0 y si se mantiene la compatibilidad, el proceso de migración y ver si reacciona la comunidad Nagios. Pienso que hay muchos plugins desarrollados y muchos despliegues funcionando perfectamente (yo tengo varios clientes que monitorizan cientos de servidores, y por encima de los 700 servicios) que no hemos migrado porque a pesar de que otros proyectos ofrecen más funcionalidades, en su conjunto no están tan maduros como Nagios.
También como administrador he tenido que oir muchas críticas a Nagios sobre su dificultad para configurarlo, el uso de ficheros de texto, etc. Con el paso de los años y las implantaciones reconozco que para la flexibilidad que ofrece Nagios, la mejor manera de poder configurar eficientemente y rápidamente es con el uso de plantillas y ficheros de texto tal y como se hace en la actualidad, de manera que mediante scripts voy muchísimo más rápido para configurarlo que con cualquier tipo de herramienta WYSIWYG/Web/etc.
En resumen: Bien por mejorar la interfaz de usuario y la API para la integración, pero que el corazón se conserve como está.

Guía de supervivencia de RSYNC


Aprovecho para dejar testimonio, ahora que estoy migrando información de un servidor a otro, de cómo con el comando RSYNC podemos hacer copias de seguridad en nuestros equipos Linux:

  • Mantener sincronizados dos directorios de un mismo servidor ejecutando:
    rsync -v -rlt -a /mi_directorio_origen  /mi_directorio_destino
    Es importante que las rutas terminen o no '/', cuidado con dejarlas porque el efecto puede que no sea el deseado. Los argumentos que le hemos pasado al comando, aparte de los directorios que sincronizar son: -v (muestre lo que está haciendo y lo que sincroniza), -r (que sea recursivo y navegue por subdirectorios), -l (copie los enlaces simbólicos como enlaces simbólicos), -t (respete los tiempos de modificación de los archivos, ideal para backups), -a (use el modo archivo).
  • Mantener sincronizados dos directorios de distintos servidores ejecutando:
    rsync -v -rlt -az \
    --delete \
    --timeout=300 \
    -e "ssh -c blowfish -ax -o ClearAllForwardings=yes -l USUARIO" \
    USUARIO@servidor_origen:/directorio_origen /directorio_destino/
    Ahora lo que hacemos es conectarnos por SSH a servidor_origen siendo el usuario del sistema USUARIO (convendría tener una confianza SSH) y traernos el contenido de todo /directorio_origen a nuestro /directorio_destino local. Hemos introducido nuevos argumentos: -z (comprima los archivos para la transferencia por red), --delete (borre en /directorio_destino los ficheros que ya no estén en /directorio_origen), --timeout=300 (si en 5 minutos no evoluciona la transferenicia, la cancelamos) y -e "etc" (parámetros para SSH, siempre los uso así).
  • Sincronizar todo excepto unos cuantos directorios , para ello nos interesa crear un fichero donde escribiremos una ruta por línea (omitiendo la / del principio, la que indica el directorio raíz) y añadiremos la opción a rsync:
    --exclude-from=FICHERO_CON_LAS_EXCLUSIONES_UNO_POR_LINEA
  • Sincronizar con respecto a una copia completa con la intención de hacer una copia incremental. Para esto necesitamos tener un directorio con la copia previa, y lanzar rsync añadiendo la siguiente opción:
    --compare-dest=DIRECTORIO_CON_COPIA_PREVIA

La imagen la he sacado de www.thelinuxblog.com vía google images.

CODE: Mi nuevo servidor para casa

Ya tengo instalado Debian Lenny 32bits en mi nuevo barebone SG33G5. Este equipo reemplazará a mi antiguo servidor ODIN en varias aspetos:

  • Paso de un barebone de gama baja SK41G con AMD Duron 900MHz, 1GB de RAM, y 500 GB de disco IDE, a uno de gama media SG33G5 con Intel Quad Core, 4GB RAM y 1GB de RAM.
  • Paso de Debian 4 Etch a Debian 5 Lenny aunque seguiré de momento todavía en 32bits.
  • Paso de Vmware Server 1.0 a Vmware Server 2.0, que me permitirá ejecutar máquinas 64 y 32 a pesar de que el sistema operativo Host siga siendo 32bits.
  • Cambio la forma de nombrar de los equipos: Al principio fueron planetas de las novelas de Isaac Asimov que aparecían en la Fundación. Como cada vez hacía más tiempo que habia leído las novelas y con Vmware Server 1.0 tenía más máquinas virtuales para pruebas, tuve que actualizar la forma de llamar a los sistemas, y decidí usar nombres de los dioses de la mitología nórdica, aunque estaba bastante visto, y algunos costaba trabajo aprenderlos y escribirlos para poder conectar (terminaba usando las IPs). Hace tiempo decidí usar como nombres el nombre de los comandos BASIC del Spectrum 48k, en un ejercicio de retrospectiva personal. Estoy bastante satisfecho con el método: Estoy usando BORDER para el gateway que me da salida a internet, BREAK para el gateway WiFi, CONTINUE para otro AP que tengo configurado para unir MythTV con la red, REM para la máquina virtual con documentación, DATA para el Oracle, etc... por lo que tendré que actualizar las zonas DNS.
El nombre que he elegido para este nuevo servidor es CODE. Este era el comando que usábamos para poder saber la representación gráfica un byte. También lo usábamos cuando teníamos que pintar en pantalla gráficos definidos por el usuario GDUs, y que nos hacían falta cuando queríamos hacer sprites para nuestros juegos. Anda que no gasté libretas milimitredas en diseñar sprites. El nombre en realidad no hace justicia a las funciones de este equipo, pero me gustaba como sonaba. Este nuevo servidor tendrá que asumir las funciones de hypervisor de Vmware Server 2.0, DHCP + DDNS, Servidor Web, Subversion, Samba y Router para cerrar el grifo a Jose Miguel con el WOW.

Ya estoy configurando a ratos los nuevos servicios y me encontrado varias cosas que deben hacerse cuando se pasa de usar VMWare 1.0 a 2.0:
  1. La consola de VMware para ver la consola física de los sevidores se instala mediante un plugin del navegador: Ir a la consola de VMware y en la pestaña Consola hacer click donde se indica para instalarla. La he probado en Firefox tanto en Windows como en Linux 32 y 64 bits y funciona bien, siempre que la profundidad del color sea 16 o 24 bits. Parece que perdemos el concepto de Vmware Client (vmware-server-console, etc) de las anteriores.
  2. Algunas teclas no funcionan muy bien en la consola desde los clientes: Cursores, \, etc.. Para arreglarlo editar el fichero /etc/vmware/config de nuestro cliente y añadir las siguientes líneas:
    xkeymap.keycode.108 = 0x138 # Alt_R
    xkeymap.keycode.106 = 0x135 # KP_Divide
    xkeymap.keycode.104 = 0x11c # KP_Enter
    xkeymap.keycode.111 = 0x148 # Up
    xkeymap.keycode.116 = 0x150 # Down
    xkeymap.keycode.113 = 0x14b # Left
    xkeymap.keycode.114 = 0x14d # Right
    xkeymap.keycode.105 = 0x11d # Control_R
    xkeymap.keycode.118 = 0x152 # Insert
    xkeymap.keycode.119 = 0x153 # Delete
    xkeymap.keycode.110 = 0x147 # Home
    xkeymap.keycode.115 = 0x14f # End
    xkeymap.keycode.112 = 0x149 # Prior
    xkeymap.keycode.117 = 0x151 # Next
    xkeymap.keycode.78 = 0x46 # Scroll_Lock
    xkeymap.keycode.127 = 0x100 # Pause
    xkeymap.keycode.133 = 0x15b # Meta_L
    xkeymap.keycode.134 = 0x15c # Meta_R
    xkeymap.keycode.135 = 0x15d # Menu
  3. También han actualizado la autenticación SSL y ahora permite usar Certificados de Usuario, pero contínuamente nos estás preguntando y se se pone bastante pesado. He dedido quitar esta feature, editando /etc/vmware/hostd/proxy.xml del servidor donde instalé VMware Server y cambiar
    <e id="2">
    <_type>vim.ProxyService.LocalServiceSpec</_type>
    <accessMode>httpsWithRedirect</accessMode>
    <port>8308</port>
    <serverNamespace>/ui</serverNamespace>
    </e>
    ... por ...
    <e id="2">
    <_type>vim.ProxyService.LocalServiceSpec</_type>
    <!-- <accessMode>httpsWithRedirect</accessMode> -->
    <accessMode>httpAndHttps</accessMode>
    <port>8308</port>
    <serverNamespace>/ui</serverNamespace>
    </e>
    que al menos nos dejará en modo no seguro por el puerto 8222, sin estar preguntando contínuamente.