/etc/resolv.conf en Linux

Uno de los clientes para los que trabajo, usa directorio activo para los servicios de impresión y logon de red, en los escritorios, y Linux para los servidores de bases de datos y aplicaciones. Estos funcionan como clientes de los DNS del directorio activo, y así los tenemos configurados en /etc/resolv.conf. Esto funciona perfectmente.

El problema aparece cuando se nos cae alguno o todos los servidores DNS: Todo empieza a funcionar muuuyy lentoooo en Linux. Esto es así, porque la mayoría de los servicios de red de un linux, lanzan contínuamente búsquedas al DNS para resolver las direcciones IP de los equipos que inician conexiones de red.

Cuando los servidores DNS están caídos, Linux no se da cuenta, y lanza una consulta secuencial a todas las IPs de /etc/resolv.conf: Empieza por el primero que encuentra, espera a que expire el timeout (el valor por defecto es 5 segundos), y lanza la misma consulta al siguiente, y vuelve a esperar el timeout, y así sucesivamente hasta que obtenga una respuesta o hayamos llegado a la última IP del fichero /etc/resolv.conf. Paralelamente se van haciendo reintentos (hasta 3). En resumen, si sólo tuviéramos una dirección IP en /etc/resolv.conf, y esa IP estuviera caída, cada operación de red que hiciéramos en el servidor Linux, tardaría como poco 15 segundos.
Podemos configurar este timeout a 1 , y el número de reintentos a 1, para que en vez de 15 segundos, tarde 1 segundo, añadiendo a /etc/resolv.conf la siguiente línea:

options timeout:1 attempts:1
Según nos comentaron en RedHat, esta configuración no podremos comprobarla con los comandos nslookup, ni dig, pero si aplica sobre servicios de red como SSHD o Apache.
La foto la he sacado del album de Giant Ginkgo en flickr

Bar El Guapo

Hoy es el día que es, y dejaré una entrada a propósito de ello. Muchos fines de semana, tengo la grandísima oportunidad (para los tiempos que corren), de hacer algún extra en el Bar El Guapo (tampoco va a ser todo estar con el ordenador!). Curiosamente este fín de semana hemos descubierto que aparecemos en YouTube, nos lo dijo un cliente. Flipante...

Un video de un cliente, donde grabó a otros clientes discutiendo en la barra. Es una pena que no se oiga bien, lo bueno sería tener lo subtítulos, pero se puden pillar algunas frases.

Indagando, me he podido enterar de que tras una considerable ingesta de almuerzo, y seguramente no despreciable cantidad de alcohol en diferentes formatos (vino, cerveza, whisky-ses y demás), los protagonistas acabaron discutiendo sobre quién era capaz de correr más y más rápido con sus bicicletas, evocando (me imagino) tiempos mejores.



El vídeo es una muestra representativa, de los discusiones metafísicas en las que muchas veces vemos inmersos a nuestros maravillosos clientes.

Ajuste de cuentas


Aprovecho este post número 70 del año, para repasar cuántos de los propósitos que me plantee a principios de año, he alcanzado.

  1. Todavía no he cambiado la plantilla de este blog, aunque al menos he avanzado algo: Tengo un logo, y tengo más o menos, el estilo, colores, lo que quiero y lo que no quiero, y como lo quiero, pero no tengo el tiempo de hacerlo, o de escribirlo para subcontratarlo. Se podría decir que esto está a medio.
  2. El blog aún está en 30000 visitas. He administrado servidores Apache que recibían esta carga en unas pocas horas. Me da vergüenza hasta de pensarlo. Quizás debería comprarle un ordenador a mi madre, y pedirle que visite el blog :P. El ratio de visitas mensuales tiene como valor medio 1500, mientras que el año pasado este valor no llegaba a 800. Una ruina. No conseguido.
  3. He conseguido llegar a los 70 post anuales, aunque un poco in extremis, y levantando dudas: Hubo quien la tarde de nochebuena me recordó que no lo conseguiría. Como le dije, tenía las entradas preparadas y me había reservado estos días de Navidad para publicarlos. No estoy muy satifescho con esto porque el objetivo real, era obligarme y acostumbrarme a publicar regularmente a lo largo del mes, y al final las cosas del día a día, me han podido.
  4. Un poco parecido ocurre con las series en inglés. Es cierto que he visto Heroes, Cómo conocí a vuestra madre, V, varias películas y varias conferencias, pero ... no he conseguido obligarme a sacar tiempo de forma regular para esto, ni toda la cantidad que debería haber visto. Yo diría que esto no está ni a la mitad.
  5. La migración a 64bits creo que ha sido un éxito, no sólo en casa con la informática de consumo sino también en servidores. Cada vez más. Es cierto que he sufrido ciertos problemas de incompatibilidad, con Flash y algún otro. Conseguido.
  6. El uso de Fedora, Ubuntu y MacOSX a final de año, ha quedado de la siguiente forma:
    • A principios de año lo intenté con MacOSX, y fracasé... no me acostumbro. Lo sigo teniendo instalado, pero no puedo, es como usar un Linux mal instalado y a medio configurar, me siento muy raro con él y muy torpe, pero reconozco que es una maravilla, cuando se le compara con un escritorio Windows, que parece prehistórico.
    • No me deshice del viejo portátil, y al final le instalé Ubuntu (ni siquiera Windows). Lo uso para la parte más lúdica de mi vida en Internet, cuando estoy por casa, o lo que yo llamo "haciendo el vago". Ubuntu 9.X es un maravilla.
    • En el portatil nuevo, terminé usando Fedora en exclusividad, y es el que uso para trabajar. Como plataforma de trabajo, me viene fenomenal, ya que casi todos los servidores con los que trabajo, son RedHat en el fondo, aunque reconozco que en los últimos meses del año, han aumentado los servidores Debian / Ubuntu.Cuando estoy en casa, procuro no encender Fedora (el portátil del trabajo), sólo Ubuntu (ocio).
  7. Aún no he conseguido terminar el postgrado, aunque sí me he quitado todas las asignaturas que me quedaban colgando. Todavía me falta la tesis que irá en torno a la gestión de identidad digital federada. Ya me vale, cuando vaya a terminar esto, está todo obsoleto. Se podría decir que este propósito está a medio conseguir.
  8. Finalmente migré la zona DNS de casa cuando monté el nuevo servidor Code. Objetivo conseguido.
  9. Y de ITIL sólo me he leído unos cuantos PowerPoints más y unos cuantos extensos documentos. Objetivo sin conseguir.

De 9 objetivos, he conseguido 5 y medio... y creo que esto es un poco desastroso :(. A pesar de ello, gracias a todos los que habeis perdido un minuto leyendo algo de lo que he colgao aquí.

La foto la he sacado de espejo-ludico.blogspot.com vía google images.

Premoniciones sobre OpenSource


Estos días de descanso entre la familia, he aprovechado para ver unas cuantas conferencias TEDTalks. Estas mini-charlas son bastante instructivas: llevan a una persona que controla un montón sobre una determinada cosa, y la ponen a explicarse durante 15 a 25 minutos, y hablar de esto que sabe. Yo empecé con Ken Robinson says schools kill creativity, la cual os recomiendo encarecidamente que veais, y si el idioma del audio es un problema, usar los subtítulos. Si la experiencia os parece interesante, podeis revisar todas las charlas que hay publicadas en este Excell-Doc, y en el documento os cuenta un poco sobre lo que habla, la duración y os deja el enlace rápido.

Después de haberlas visto, hay una cosa que me ha llamado muchísimo la atención y es que casi sin proponérmelo, he visto varias charlas sobre OpenSource pero aplicadas a otras disciplinas como arquitectura o biología, y todo ello me ha animado a escribir este pequeño rollo que os voy a contar.

Cuando tenía que explicar el concepto de OpenSource a los chavales, siempre me gustó usar aquello que dice: Si yo tengo una manzana y tu tíenes otra manzana, y yo te doy mi manzana y tú me dás la tuya, cada uno seguimos teniendo una manzana; pero si tú tienes una idea, y yo tengo otra idea, y yo te cuento la mía y tú la tuya, al final tenemos dos ideas cada uno, y esto lo podemos sintetizar en que el conocimiento siempre suma, nunca resta: Esto es OpenSource, hacer que el conocimiento siempre sume .

Esta definición pura e ideal aplicada al software, nos conduce inexorablemente al software libre, que no tiene nada que ver con software gratis. En la facultad de informática nos cuentan una película didáctica de que escribir un programa es como hacer una receta de cocina, que luego se pueda seguir a pies juntillas, y hacer un plato de comida. Cuando alguien quiere ganar dinero con recetas de cocina monta un restaurante, y justo ahí deberíamos leer el post que escribí en Mayo: Conversaciones con Jenny.

De nuevo, esta definición la podemos aplicar en la arquitectura, por ejemplo. En síntesis, OpenSource aplicado a la arquitectura permitiría aprovechar las técnicas y diseños de construcción usadas en china, y en otros lugares del planeta y mejorar así la resistencia de las construcciones ante huracanes; o estudiar algunas de las construcciones de Africa, para mejorar la resistencia a temperaturas extremas.

Esto mismo, podríamos aplicarlo a otras disciplinas de conocimiento y estudio. Y eso es lo que me ha llamado la atención de las charlas TED, que eso ya se está haciendo. ¿Qué está pasando entonces? ¿Que vá a pasar con el OpenSource?
Creo que lo que está pasando, sencillamente es que estamos sufriendo un cambio de fase en la evolución del OpenSource. Pasamos de la fase de las herramientas, a la fase de los contenidos.

  • La fase de las herramientas, se ha caracterizado porque en ella se han establecido los modelos (de negocio, de desarrollo, de trabajo) para poder desarrollar las herramientas (software libre, wikipedia, opendocument, etc) que hicieran posible la segunda fase.
  • La fase de los contenidos, se caracterizará por la compartición del conocimiento y de las técnicas: Arquitectura OpenSource, Enseñanza OpenSource, etc. Pensar por un momento, en la cantidad de material educativo y contenidos que hay publicados en papel. Pensar el gasto que ello supone, no solo económico, sino forestal: En cualquier caso no es sostenible. Pensar en que podemos digitalizar todo esto y servirlo con estas herramientas OpenSource: ¿no estaríamos abartando los costes? ¿no sería más sostenible para el planeta?, ¿no podríamos llegar a mayor cantidad de alumnos?...

Y ... ¿cuando será este cambio de fase un hecho tangible?. Pienso que este salto lo daremos cuando la industria de los derechos de propiedad intelectual, se resigne a la extinción: Nos venden que compartir es un delito, que es malo, que es lo peor, y nos criminalizan por ello. Están perdiendo el tiempo, y en vez de buscar modelos de negocio viables, esperan que los gobiernos elaboren un gran plan de regulación que les permita seguir explotando (y exprimiendo) los mismos modelos de negocio que han usado hasta ahora. Ya hay modelos que empiezan a funcionar, véase si no, los ejemplos de iTunes y Spotify.
Ale, ahí queda eso.

La foto la he sacado del album de cl a ra en flickr

Monitorizar servidores OpenLDAP desde Cacti

Dentro de la serie de entradas dedicadas a cacti, no podíamos dejar de ver la monitorización de nuestros servidores OpenLDAP desde Cacti, lo cual puede reportarnos estadísticas y gráficas de los tiempos de respuesta, y número de consultas que estamos atendiendo, y hacernos una idea de la calidad de servicio LDAP que estamos ofreciendo.

El problema con el que me he encontrado es que los scripts para Cacti que había en Internet para monitorizar servidores OpenLDAP, ya no están tan accesibles como siempre, y la mayoría de los links aparecen rotos. El enlace que parece funcionar la mayoría del tiempo es https://ltb-project.org/svn/cacti-plugins/trunk/.
Para poder monitorizar OpenLDAP desde cacti tendremos que:

  1. Descargar los scripts ldap_response_time.pl y openldap_operations.pl, y copiar en el directorio /var/www/cacti/scripts/ de nuestro servidor Cacti. Luego ejecutar como root los siguientes comandos:
    yum install perl-LDAP
    chmod 755 /var/www/cacti/scripts/openldap*pl
  2. Ahora, ir al servidor OpenLDAP que queremos monitorizar. Editar el fichero de configuración /etc/openldap/slapd.conf, y en la zona en la que se declaran la base de datos de Ldap, añadir
    database monitor 
    Luego reiniciaremos el servicio:
    /etc/init.d/ldap restart
    Desde el servidor de Cacti, lanzar una prueba de conexión:
    /var/www/cacti/scripts/openldap_operations.pl \
    -h SERVIDOR_LDAP \
    -D "cn=CUENTA_DE_ACCESO_A_LDAP" \
    -W CONTRASEÑA_DE_ACCESO
  3. De nuevo en la consola de Cacti como usuario Administrador, importaremos las plantillas cacti_graph_template_openldap_initiated_operations.xml y cacti_graph_template_openldap_response_time.xml, que nos deberíamos haber descargado de internet.
  4. Ahora sólo nos queda añadir las gráficas OpenLDAP - intiated operation y OpenLDAP - response time a nuestro servidor LDAP o a nuestras plantillas, y esperar unos minutos.

La foto la he sacado del album de eschipul en flickr

NDOUtils: Addon para Nagios

Nagios Data Out (NDO) es un addon oficial de Nagios que permite exportar todos los sucesos y la configuración de una o más instancias de Nagios a una base de datos MySQL, y por supuesto, sin que dejen de escribirse en los ficheros status.dat y retention.dat, y tampoco sin obligarnos a renunciar a tener toda la configuración de Nagios en nuestros ficheros de texto plano, como lo hemos hecho toda la vida.

¿Y para qué necesitaríamos esto entonces?, ¿qué utilidad tiene esto? ... la gran ventaja de configurar NDOUtils en nuestro servidor Nagios, es que nos permitirá integrarlo con otras herramientas como NagVis (usar diagramas de red y vincular alertas), php4nagios (estadísticas para Nagios), o nagiosbp (Nagios Business Process AddOns), que ampliarán las funcionalidades de nuestro Nagios.

Para instalarlo y configurarlo, lo primero que hago es hacer una copia de seguridad de toda las instalación de Nagios, y luego realizo los siguientes pasos:

  1. Preparar el sistema para poder compilar y ejecutar este programa
    yum install mysql-devel perl-DBD-MySQ
  2. Descargar el software de NDOUtils y descomprimirlo...
    cd /opt/software

    export URL="http://downloads.sourceforge.net/project/nagios"
    export URL="$URL/ndoutils-1.x/ndoutils-1-4b8/ndoutils-1.4b8.tar.gz"

    cd /opt
    tar -xzvf software/ndoutils-1.4b8.tar.gz
  3. Compilar el programa
    cd /opt/ndoutils-1.4b8

    export LD_LIBRARY_PATH="/usr/lib:/usr/local/lib:$LD_LIBRARY_PATH"
    export LD_LIBRARY_PATH="/usr/lib/mysql:/lib:$LD_LIBRARY_PATH"

    ./configure --prefix=/usr/local/nagios \
    --enable-mysql \
    --with-mysql-lib=/usr/lib/mysql
    make
  4. Instalar los ejecutables y la configuración de ejemplo de NDO mediante...
    cp -f src/file2sock \
    src/log2ndo \
    src/ndo2db-* \
    src/ndomod-* \
    src/sockdebug \
    /usr/local/nagios/bin/

    /bin/cp -p config/ndo2db.cfg /usr/local/nagios/etc/ndo2db.cfg
    /bin/cp -p config/ndomod.cfg /usr/local/nagios/etc/ndomod.cfg
    ...y dependiendo de la versión de Nagios que tengamos instalado copiaremos un ejecutable u otro. En mi caso uso la versión 3.
    /bin/cp -f src/ndomod-3x.o /usr/local/nagios/bin/ndomod.o
    /bin/cp -f src/ndo2db-3x /usr/local/nagios/bin/ndo2db
  5. Ahora en el servidor MySQL tendremos que crear el usuario y la base de datos donde NDO escribirá las tablas y todos estos datos que provienen de Nagios. En mi caso crearé la base de datos nagios_ndo, el usuario nagios con contraseña nagios.pwd:
    create database nagios_ndo;

    CREATE USER nagios@IP_SERVIDOR_NAGIOS
    IDENTIFIED BY 'nagios.pwd';

    GRANT USAGE ON *.* TO nagios@IP_SERVIDOR_NAGIOS
    IDENTIFIED BY 'nagios.pwd'
    WITH MAX_QUERIES_PER_HOUR 0
    MAX_CONNECTIONS_PER_HOUR 0
    MAX_UPDATES_PER_HOUR 0
    MAX_USER_CONNECTIONS 0;

    GRANT ALL PRIVILEGES
    ON nagios_ndo.*
    TO nagios@IP_SERVIDOR_NAGIOS
    WITH GRANT OPTION ;

    flush privileges;
  6. Crear las tablas y el modelo de datos, en la base de datos:
    cd /opt/ndoutils-1.4b8/db
    ./installdb -u nagios \
    -p 'nagios.pwd' \
    -h IP_SERVIDOR_MYSQL \
    -d nagios_ndo
  7. Ahora cambiar la configuracion de NDO en /usr/local/nagios/etc/ndo2db.cfg, para aplicar los siguientes cambios:
    # Evitar problemas con otros plugins NRPE y NSCA
    tcp_port=5663

    # Indicar la IP de nuestro servidor de MySQL
    db_host=IP_SERVIDOR_MYSQL

    # Credenciales de BBDD
    db_name=nagios_ndo
    db_user=nagios
    db_pass=nagios.pwd

    # Mantener los eventos durante 2 semanas
    max_timedevents_age=20160
  8. Ahora cambiar la configuracion de Nagios (/usr/local/nagios/etc/nagios.cfg) para decirle que debe usar el Broker de eventos:
    broker_module=/usr/local/nagios/bin/ndomod.o config_file=/usr/local/nagios/etc/ndomod.cfg
  9. Editar el fichero de configuracion del broker NDO para configurar el puerto que debe escuchar. Esto es editar el fichero /usr/local/nagios/etc/ndomod.cfg y configurar:
    tcp_port=5663
  10. Crear el script de arranque del servicio, a partir del que nos propone la distribución:
    /bin/cp -f /opt/ndoutils-1.4b8/daemon-init /etc/init.d/ndo2db
    chmod a+x /etc/init.d/ndo2db
    chkconfig ndo2db on

Para terminar, reiniciar todos los servicios y comprobar que las tablas empiezan a rellenarse de datos.
/etc/init.d/ndo2db stop
/etc/init.d/ndo2db start
/etc/init.d/nagios restart


Recuperar un bakup de Oracle hecho con RMAN

Esto también lo tengo que buscar a menudo :( ... ¿qué sentido tendría si sabemos hacer un backup y luego no sabemos recuperarlo. En esta entrada anotaré el procedimiento que sigo para recuperar bases de datos Oracle con RMAN.
Se supone que tenemos un backup físico realizado con RMAN en el directorio /opt/backups_oracle/backupset, y que el catálogo local lo tenemos inicializado y configurado. También supondremos que tenemos una copia del pfile de la base de datos a recuperar en /opt/backups_oracle/backupset/bbdd_init.ora y que sabemos el DBID de la bbdd de la que hemos hecho la copia.

  1. Conectarnos al servidor donde queremos recuperar el backup como usuario Oracle, y desde RMAN detener la BBDD y establecer el nuevo DBID
    su - oracle
    $ORACLE_HOME/bin/rman target / nocatalog

    RMAN> shutdown abort;
    RMAN> set dbid 815531541;
  2. Montar la BBDD usando el pfile del backup...
    RMAN> startup nomount \     
    pfile='/opt/backups_oracle/backupset/bbdd_init.ora' ;
  3. Recuperar los controlfiles desde el Backup que tenemos, y volver a parar la instancia
    RMAN> restore controlfile from \
    '/opt/backups_oracle/backupset/controlfiles/BD_c-XXXXXXXXXx.ctl.bck';

    RMAN> shutdown immediate;
  4. Ahora montar desde los controlfiles recuperados...
    RMAN> startup nomount  \
    pfile='/opt/backups_oracle/backupset/bbdd_init.ora' ;

    RMAN> alter database mount;
  5. Mirar si tenemos backups para recuperar... es muy importante que nos fijemos en el SCN que tienen todos los tablespaces...
    RMAN> list backup; 
  6. Recuperar la BBDD y abrirla reseteando logs..
    RMAN> run {
    set until scn XXXXX--SCN--XXXXX ;
    restore database;
    recover database; }

    RMAN> alter database open resetlogs;
    RMAN> exit;

Cómo configurar Oracle en modo archivelog

En una BBDD Oracle contínuamente se están escribiendo las instrucciones que ejecutamos (hasta el commit) con nuestras modificaciones en lo que se conoce como RedoLog, como si se tratase de un cuaderno de bitácora. Estos son unos tablespaces especiales que habitualmente poseen redundancia y se suelen configurar en al menos tres grupos de estos: El que se usa actualmente donde oracle escribe el actual RedoLog, el que estábamos usando antes de usar el actual (y que cuando se cambia, conserva una pequeña actividad residual hasta que se ha completado el cambio) y el que usaremos cuando llenemos el actual (sin uso hasta ese momento). Podemos forzar este cambio, ejecutando:

alter system switch logfile;
La idea de estos Redolog, es que si partimos de una base de datos recién instalada y tenemos todos los ficheros RedoLog hasta el día actual, podríamos ir aplicando los cambios escritos en estos redologs hacia adelante, y podriamos dejarla como estaba la BBDD en una fecha y hora determinadas. En vez de usar una BBDD recién instalada, podemos usar una copia física (donde la BBDD está en estado consistente), y aplicar ficheros de redolog hacia adelante, pudiendo recuperar hasta justo antes de algún fatídico cambio.
El problema que tiene esta teoría, es que Oracle va reutilizando los ficheros DBFs que forman los RedoLog de manera cíclica, y sólo tenemos los tres últimos RedoLogs. El modo ArchiveLog le dice a Oracle que antes de reciclar un DBF de un RedoLog, deje una copia del fichero en otro directorio, y así podremos guardar más allá de los tres últimos. Además, tener la BBDD en este modo configurada, nos permitirá poder hacer backups físicos con RMAN sin parar el servicio de Oracle... todo un lujo.
Para configurar este modo en Oracle 9.2 (al menos) realizaremos los siguientes pasos:
  1. Crear los directorios para almacenar los archiveLogs.
    mkdir -p  /opt/backups_oracle/archivelogs \      
    /opt/backups_oracle/backupset/controlfiles

    chown oracle.dba -R /opt/backups_oracle
  2. Conectarse como DBA a la base de datos...
    su - oracle
    sqlplus /nolog

    SQL> connect /as sysdba;
  3. Parar la base de datos, y después montarla
    shutdown immediate;
    startup mount;
  4. Decirle a la bbdd donde debe dejar los Redolog reciclados, configurar la BBDD en modo archivelog, y abrir la bbdd...
    alter system set \
    log_archive_dest='/opt/backups_oracle/archivelogs' \
    scope=both;

    alter database archivelog;
    alter database open;
  5. Guardar la configuración en el SPFile
    alter system set log_archive_start=true scope=spfile;
  6. Comprobar que ya tenemos la BBDD configurada, ejecutando:
    select log_mode from v$database;
    show parameter log_archive;
  7. Reiniciar la Base de datos, para que arranque ya con este modo, y empiece a rotar al directorio que hemos configurado...
    shutdown immediate;
    startup;

Forzar la rotación de redolog, un par de veces para comprobar que se están guardando nuevos ficheros en el directorio: /opt/backups_oracle/archivelogs/

alter system switch logfile;
alter system switch logfile;

Monitorizar nuestro servidor MySQL desde Cacti


Siguiendo con la serie de posts dedicados a cacti, en este os contaré cómo podemos monitorizar un servidor MySQL con Cacti, lo cual nos puede venir bien para detectar cuellos de botella y mal funcionamientos.
Esta configuración está bastante bien explicada en http://code.google.com/p/mysql-cacti-templates/, pero os la resumo en unas pocas líneas:

  1. Descargar las plantillas de GoogleCode, http://mysql-cacti-templates.googlecode.com/files/mysql-cacti-templates-1.1.1.tar.gz
  2. Importar la plantilla cacti_host_template_x_db_server_ht_0.8.6i.xml en Cacti como Administrador, y copiar el script ss_get_mysql_stats.php al directorio /var/www/cacti/scripts/ del servidor.
  3. Crear en MySQL un usuario cactimon, con contraseña cactipwdmon, al gusto, que será el que usaremos desde cacti para monitorizar el servidor de base de datos.
    GRANT PROCESS ON *.* TO \
    cactimon@'SERVIDOR_CACTI' \
    IDENTIFIED by 'cactipwdmon';

    GRANT SUPER ON *.* TO \
    cactimon@'SERVIDOR_CACTI' \
    IDENTIFIED BY 'cactipwdmon';

    flush privileges;
  4. Ahora en Cacti desde la consola del administrador, Console->DataTemplates, buscar todas las gráficas que sean: X MySQL lo_que_sea, y en todas ellas editar y marcar en Custom Data, el username y el password, y fijar: Username=cactimon y Password=cactipwdmon
Ya podremos dar de alta un nuevo dispositivo de tipo MySQL Server para que empiece a pintarnos gráficas.
La foto la he sacado del album de groovehouse en flickr

Monitorizar Microsoft SQLServer desde Nagios


A menudo, en nuestra infraestructura IT, no sólo tenemos servidores de base de datos corriendo en el supereficiente Linux, si no que tenemos que vérnoslas con servidores Microsoft Windows ejecutando SQLServer.
Los administradores de Nagios podemos monitorizar si SQLServer está funcionando o no, y podemos conectarnos, siguiendo los siguientes pasos:

  1. Conectarnos como root al servidor de Nagios. Luego descargar el plugin que ha desarrollado la gente de Consulting & Solutions
    cd /opt/software

    URL="http://www.consol.de/fileadmin/opensource"
    URL="$URL/Nagios/check_mssql_health-1.5.1.tar.gz"

    wget $URL
  2. Después, debemos instalar el paquete perl-DBD-Sybase. Es posible que encontremos alguna versión en RPM que nos pueda servir para nuestro sistema operativo en http://dag.wieers.com/rpm/packages/perl-DBD-Sybase/. Luego instarlarlo ejecutando:
    yum install freetds perl-DBD-Sybase
  3. Compilar e instalar el plugin que ha desarrollado la gente de Consulting & Solutions.
    cd /opt
    tar -xzvf /opt/software/check_mssql_health-1.5.1.tar.gz

    ./configure --prefix=/usr/local/nagios
    make
    make install
Ya podemos realizar la prueba de conectar a SQLServer, para lo que necesitaremos una cuenta de acceso de base de datos:
/usr/local/nagios/libexec/check_mssql_health \
--hostname=SERVIDOR_SQLSERVER \
--username=LOGIN_SQLSERVER \
--password=PASSWD_SQLSERVER \
--mode=connection-time
Este comando implementa otros modificadores que nos permitirán comprobar otros indicadores de SQLServer.

Google Reader

Google Reader es una herramienta muy útil de Google, que conocí gracias a Puche, y que he recomendado un motón de veces a la gente, en especial a mi hermano Pepe y mi hijo Jose Miguel... pero no consigo que lo usen ni obligándolos :(


GoogleReader es una simple herramienta de sindicación de noticias XML (RSS, OPML, etc), y como cualquier otra, tiene la gran ventaja de que ahorramos un montón de tiempo para ponernos al día de lo que pasa en aquellos blogs y sites que nos interesa seguir a diario: No tenemos que ir uno a uno, visitándolos, esperando que cargue la publicidad, y que al final nos despista y desconcentra. Al ser online, nos permite que podemos consultar nuestros feeds desde cualquier equipo conectado a la red, y al tratarse de Google, nos hace sugerencias de qué otros feeds pueden interesarnos, viendo el contenido de los que ya estamos suscritos. Como añadido, podemos compartir aquellas noticias de los feeds a los que estamos suscritos, para que les aparezca también a nuestros contactos de GMAIL, de forma que podemos ver aquellos que otros de nuestros contactos considera interesante, y así abrirnos nuevas espectativas. Una caña. Resulta muy, muy útil. Lo uso a diario desde hace un montón de tiempo.
Pero no todo son ventajas: Para mi gusto, creo que deberían revisar:
  • Las listas tardan unos segundos en cargar (a tramos) y se nota pesado
  • Cuando llevo dos o tres días sin leer mi reader, la aplicación me estresa: Me dice que tengo pendientes ¡400 mensajes! .. y eso me estresa ... deberían darse cuenta que dedico unos 15 a 30 minutos a leer el reader, y lo habitual es que lea de 50 a 90 post. Lo que supere eso, prefiero casi ni saberlo.
  • ¿Para qué nos colocan dos opciones Share? ¿Para qué sirve Like?

A pesar de esto, os recomiendo encarecidamente que lo useis si quereis ahorrar tiempo a diario.

Backups de Oracle con RMAN


Siempre tengo que buscar esto por Internet. La foto que he seleccionado para la ocasión, evoca la necesidad de tener buenos backups.

RMAN (Recovery Manager) es la herramienta de Oracle para poder hacer backups físicos de nuestra BBDD. Un backup físico, es a fín de cuentas, como copiar los ficheros DBFs que forman los TableSpaces de nuestra BBDD a un lugar seguro (de ahí, lo de copia de seguridad), pero claro, si lo hiciéramos con el comando COPY del sistema operativo, el estado de la copia de seguridad sería inconsistente, porque no todos los DBFs estarían sincronizados con los cambios en nuestra BBDD a la misma hora, por lo tanto, lo mejor es hacer esta copia con la base de datos parada.
Claro que no todas las bases de datos se pueden parar, para hacerles backup, por lo que para poder hacer un backup físico con Oracle arriba, necesitamos que la base de datos esté configurada en modo ArchiveLog. En ese caso, podremos hacer backup físico en caliente (que se dice).
Para ilustrar el procedimiento, vamos a lanzar un backup físico al directorio /opt/backups_oracle/backupset/, por lo que, lo primero será crear el directorio donde dejaremos la copia.

mkdir -p /opt/backups_oracle/backupset/controlfiles
chown -R oracle.oinstall /opt/backups_oracle

Nos convertimos en usuario oracle, y lanzamos RMAN usando el catálogo local (esto son los ControlFiles de la propia BBDD).
su - oracle
$ORACLE_HOME/bin/rman target / nocatalog

Ya en la consola de RMAN ejecutaremos los siguientes comandos:
RMAN>

-- Mostrar nuestr política de backup
SHOW RETENTION POLICY;

-- Configurar: solo conservaremos dos backups físicos
CONFIGURE RETENTION POLICY TO REDUNDANCY 2;

-- Hacer copia también de los controlFiles.
CONFIGURE CONTROLFILE AUTOBACKUP ON;

-- Decirle el directorio donde dejar los backups de estos
-- controlfiles...
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK \
TO '/opt/backups_oracle/backupset/controlfiles/BBDD_%F.ctl.bck';

-- Decirle que el dispositivo por defecto sera el disco
CONFIGURE DEFAULT DEVICE TYPE TO DISK;


-- Decirle el directorio donde dejar la copia de los Datafiles
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT \
'/opt/backups_oracle/backupset/%T__%d_%p_%s.bck';

-- No limitar el tamaño de la copia
CONFIGURE MAXSETSIZE TO UNLIMITED;

-- salir :)
RMAN> exit;

Con estos comandos estamos configurando nuestra política de backup, donde lo más significativo es que le decimos el directorio donde debe dejar los backups y que como máximo conservaremos dos copias físicas. Esto se guardará en los controlfiles de la BBDD, ya que no estamos usando un catálogo global. Esto es importante porque significa que tenemos que guardar copia de los controlfiles junto al backup de Oracle.
Una vez configurada nuestra política de copia, podremos lanzar el backup de Oracle ejecutando...
RMAN>

-- Hacer backup de los Datafiles
BACKUP DATABASE;

-- Borrar los archivelogs, obsoletos
BACKUP ARCHIVELOG ALL DELETE INPUT;

-- Hacer copia extra de los controlfiles
COPY CURRENT CONTROLFILE TO \
'/opt/backups_oracle/backupset/controlfiles/control%u.copia';

-- Borrar las copias obsoletas (según RETENTION POLICY REDUNDANCY)
DELETE NOPROMPT OBSOLETE;

-- salir :)
RMAN> exit;

Además, sería bueno conservar junto al backup el BDID de la BBDD...
su - oracle
sqlplus /nolog

SQLPLUS> connect /as sysdba;

SQLPLUS> select DBID from v$database;

... y una copia del SPFILE que usa la BBDD para arrancar (que podemos copiar usando el comando COPY del sistema Operativo)
su - oracle
sqlplus /nolog

SQLPLUS> connect /as sysdba;

SQLPLUS> show parameter pfile;

La foto la he sacado del album de godog en flickr

Configurar PHP para conectar a Oracle

En algunas ocasiones nos encontramos que la base de datos a la que tenemos que conectar desde PHP es Oracle en vez de MySQL, y el problema suele ser que no el yum install php-oracle o apt-get install php-oracle no nos funciona.
¿Qué podemos hacer? ... os cuento lo que yo hago:

  1. Lo primero que debemos hacer es descargar los RPMs del InstantClient de Oracle en /opt/software/oracle. Nos servirán oracle-instantclient11.1-basic-11.1.0.7.0-1.i386.rpm y oracle-instantclient11.1-devel-11.1.0.7.0-1.i386.rpm. Luego los instalaremos ejecutando:
    rpm -ivh /opt/software/oracle/oracle-instantclient11.1-*
  2. Añadir al entorno las variables que necesita Oracle para ejecutarse. Para ello, añadir las siguientes lineas al fichero /etc/profile:
    export ORACLE_HOME=/usr/lib/oracle/11.1/client
    export NLS_LANG=spanish_spain.WE8ISO8859P15
    export TNS_ADMIN=$ORACLE_HOME/network/admin
    export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib/:/lib:$LD_LIBRARY_PATH
    export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH
    export PATH=$PATH:$ORACLE_HOME/bin
    Sería recomendable cerrar sesión y volverla abrir para que se carguen estas variables en nuestro entorno.
  3. Lo siguiente será copiar un fichero tnsnames.ora al directorio $ORACLE_HOME/network/admin desde otro servidor de aplicaciones, en el que ya nos funcione la conexión a la BBDD de Oracle.
  4. Para instalar las librerías de Oracle, lo haremos mediante PECL, que es algo así como el CPAN para Perl, pero para PHP.
    yum install php-pear php-devel

    pecl install oci8
    Cuando nos pregunte, decirle que autodetecte la instalacion. Cuando instalamos lo hacemos desde los RPM lo hace automaticamente. Al terminar de compilar e instalar nos habrá dejado la libreria en /usr/lib/php/modules/. Ahora deberíamos incluirla en /etc/php.ini añadiendo la siguiente línea dentro de la sección de Dynamic Extensions, entorno a línea número 620:
    extension=oci8.so
  5. Reiniciar el servicio de Apache, para que PHP cargue las librerías de Oracle...
    /etc/init.d/httpd restart
  6. Crear un fichero /var/www/html/infophp.php con el siguiente contenido:
    <?php
    phpinfo();
    ?>
    Abrir la URL desde un navegador http://MISERVIDOR/infophp.php, para comprobar las variables de entorno y que PHP ha cargado la librería oci8.
  7. Cuando hayamos comprobado, que ya tenemos el PHP configurado para poder conectar a Oracle, podremos crear nuestra primera página:
    <?php

    # Inicializar la conexión a Oracle
    $conn = oci_connect('XXLOGINXX', 'XXCONTRASEÑAXX', 'XXSIDXX');

    # Preparar la Query
    $query = 'select table_name from user_tables';

    # Conectar realmente y lanzar la consulta...
    $stid = oci_parse($conn, $query);
    oci_execute($stid, OCI_DEFAULT);

    # Lanzar la consulta
    while ($row = oci_fetch_array($stid, OCI_ASSOC)) {

    # Recuperar las filas de la consulta
    foreach ($row as $item) {
    echo $item." ";
    }
    echo "<br>\n";
    }

    # Cerrar la conexión con Oracle
    oci_free_statement($stid);
    oci_close($conn);

Cuando reiniciemos el servidor seguramente nos habrá dejado de funcionar. Es importante añadir al script /etc/init.d/apache, después del bloque de comentarios inicial la línea:
. /etc/profile
Esto pasa porque el cliente Oracle necesita estas variables definidas en el entorno, y cuando se reinicia el servidor, el proceso init, no incializa este entorno y ejecuta estos ficheros. Al añadirlo al demonio de arranque de Apache, nos aseguramos que Apache las tenga inicializadas cuando init lo llame durante el inicio del servidor.

La foto la he sacado del album de CalEvans en flickr

Feliz navidad y próspero año nuevo



Felíz navidad a todos y próspero año nuevo. Mis mejores deseos para el año que viene haga que se cumplen vuestros sueños.

La imagen la he sacado de http://www.funny-potato.com/blog/category/christmas, vía google images.

Plugin aggregate para Cacti

Una vez se tiene instalada la arquitectura de plugins para nuestro Cacti, podremos empezar a instalar nuevos plugins. Entre los plugins disponibles nos encontramos con el plugin aggregate, que nos permitirá crear nuevas gráficas de agregados a partir de otras ya existentes: Yo, por ejemplo, suelo usarlo para aglutinar en una única gráfica, el consumos de RAM y CPU de todas las máquinas virtuales de un mismo servidor ESX.

En la misma página del plugin, el autor ha publicado un manual en PDF muy completo de cómo instalarlo y usarlo, pero básicamente esto consistirá en: descargarnos la última versión, descomprimir el tgz en la carpeta /var/www/cacti/plugins y añadir el nombre de la carpeta al array php de los plugins, en el fichero /var/www/cacti/include/global.php. Luego debemos asegurarnos de activarlo desde la interfaz web del administrador de Cacti.

La foto la he sacado del album de Hipopótominha en flickr

Actualizar Cacti a 0.8.7e y añadirle plugins


Cacti es un proyecto vivo, en el que contínuamente encontramos nuevas actualizaciones y plugins. Las actualizaciones nos permiten mantener actualizados los script que componen la distribución, pero si sustituimos nuestra versión por una versión superior, corremos el riesgo de perder los cambios que hayamos realizado en los scripts, y las plantillas que hubiéramos importado, por lo que es importante actualizar en vez de reinstalar.
Además podemos encontrar numerosos plugins, que añaden nuevas funcionalidades a nuestra consola. De entre todos encuentro muy útil el Agregate, que nos permite crear gráficas de agregados a partir de otras gráficas, y es bastante útil para comparar métricas de diferentes servidores, expresados en la misma magnitud. El plugin Monitor, no os lo recomiendo: yo me he encontrado con problemas al dar de alta nuevos dispositivos, teniendo habilitado este plugin.
En este post, os contaré como mantener actualizada nuestra versión de Cacti. Para ello, seguiremos la siguiente secuencia de pasos:

  1. Hacer un backup de la instalación que tenemos de nuestro cacti, para garantizar que podemos volver atrás.
    cd /var/www
    cp -R cacti cacti_backup_`date '+%Y%m%d'`
    También sería recomendable hacer un backup con mysqldump de la BBDD del servidor MySQL donde almacenamos los datos para Cacti.
  2. Descargar los plugins y las actualizaciones que queremos instalar, a un directorio local de nuestro servidor, supondremo que en el home
    cd
    mkdir update_cacti
    cd update_cacti

    wget http://www.cacti.net/downloads/cacti-0.8.7e.tar.gz

    export U="http://mirror.cactiusers.org/downloads/plugins"
    wget $U/cacti-plugin-0.8.7e-PA-v2.5.zip

    wget http://cactiusers.org/downloads/boost.tar.gz
    wget http://cactiusers.org/downloads/ntop.tar.gz
    wget http://cactiusers.org/downloads/settings.tar.gz
    wget http://cactiusers.org/downloads/thold.tar.gz
    wget http://cactiusers.org/downloads/tools.tar.gz
    wget http://cactiusers.org/downloads/update.tar.gz
  3. Preparar la actualización de nuestra distribución desde el directorio temporal que usamos para las descargas
    cd ~/update_cacti

    tar -xzvf cacti-0.8.7e.tar.gz
    mv cacti-0.8.7e/ cacti
    mkdir parche
    cd parche/

    unzip ../cacti-plugin-0.8.7e-PA-v2.5.zip
    cd ../cacti
    patch -p1 -N < ../parche/cacti-plugin-0.8.7e-PA-v2.5.diff

    cd plugins
    tar -xzvf ../../boost-2.4.tar.gz
    tar -xzvf ../../ntop-0.1.tar.gz
    tar -xzvf ../../settings-0.5.tar.gz
    tar -xzvf ../../thold-0.4.1.tar.gz
    tar -xzvf ../../tools-0.3.tar.gz
    tar -xzvf ../../update-0.4.tar.gz
  4. Instalar la version actualizada con plugins, sobrescribiendo nuestra instalación:
    cd ~/update_cacti/parche/cacti

    /bin/cp -Rf * /var/www/cacti/

    cp /var/www/cacti_backup_`date '+%Y%m%d'`/include/config.php \
    /var/www/cacti/include/config.php
    Ahora, editar el fichero /var/www/cacti/include/global.php, y añadir:
    $plugins = array(
    "boost",
    "ntop",
    "settings",
    "thold",
    "tools",
    "update"
    );

    $config['url_path'] = '/cacti/';
  5. Ahora, actualizar el modelo de la base de datos,
    cd ~/update_cacti/parche

    mysql -u cactiuser --password=SECRET -h SERVIDORBBDD \
    cacti < pa.sql
  6. Abrir el cacti en nuestro navegador como administrador, y seguir el asistente para completar la actualización. Cuando hayamos terminado, accederemos a User Management->Admin->Realm Permissions y marcaremos Plugin Management y el resto de plugins que queremos poder utilizar.

La foto la he sacado del album de cobalt123 en flickr

Ideas para optimizar MySQL

Cuando trabajamos con programas OpenSource es muy probable que terminemos usando MySQL 5.0, y cuando lo hacemos durante varios meses, también es muy probable que acabemos administrándolo, e intentando mejorar el redimiento. Para conseguirlo, os propongo tres posibles mejoras:

  1. La primera, es que usemos ext4 o xfs como sistema de archivos para /var/lib/mysql. Estos sistemas de archivos consiguen más velocidad y rendimiento que ext3.
  2. La segunda, consiste en usar un fichero por cada tabla innodb, para lo cual habrá que añadir la siguiente línea a la sección [mysqld] en /etc/mysql/my.cnf,
    innodb_file_per_table
    Esto evitará que el fichero /var/lib/mysql/ibdata1 crezca sin límite, alamcenando en él todos los datos de nuestra BBDD y siendo este fichero cuello de botella para el acceso a disco. Si este fichero se dañara perderíamos todas las bases de datos. Con esta optimización, lo que hacemos es que cada tabla MYSQL tenga su propio fichero bajo su correspondiente subdirectorio en /var/lib/mysql.Después de aplicar este cambio y reiniciar el servicio, tendremos que exportar e importar cada una de las base de datos que tuviéramos configuradas.
  3. La tercera consiste en aplicar algunas mejoras en la configuración, que encontramos en la comparativa http://developer.cybozu.co.jp/kazuho/2009/12/comparing-innod.html?lang=en, dentro de la sección tunning del fichero /etc/mysql/my.cnf:
    innodb_buffer_pool_size = 2048M
    innodb_log_file_size = 64M
    innodb_flush_method=O_DIRECT
    innodb_flush_log_at_trx_commit=2
    key_buffer_size=64M
    myisam_sort_buffer_size=32M

La foto la he sacado del album de Nanaki en flickr

El comando "bar"


Esta tarde, Antonio Rubio me ha mostrado la utilidad del comando bar, cuando estamos esperando a que termine un proceso largo como una copia vía scp o un simple dd: Es muy simple, basta con añadirlo a nuestro pipe..

cd /
tar cvpf - bin lib root sbin usr \
| bar \
| ssh root@192.168.1.2 "cd / && tar xvpf - "

Al hacerlo, veremos una pequeña barra de progreso, que al menos nos permitirá saber si la tarea sigue ejecutándose o no. Muy útil.
La foto la he sacado del album de Odalaigh en flickr

Debian Lenny DM-Multipath en IBM DS4700


Hoy he tenido la ocasión de configurar DeviceMapper Multipath en Debian Lenny para un cliente, que usaba almacenamiento de IBM, en concreto una DS4700. En el equipo, teníamos conectada una tarjeta Emulex y sólamente le hemos presentado una LUN de 100Gb para poder almacenar los ficheros de una base de datos MySQL 5.0.
Los pasos que he seguido para configurar multipath han sido los siguientes:

  1. Lo primero será instalar multipath:
    apt-get install multipath-tools
  2. Crear el fichero /etc/multipath.conf, inicial.
    defaults {
    user_friendly_names yes
    }

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

    devices {
    device {
    vendor "IBM*"
    product "1814*"
    getuid_callout "/lib/udev/scsi_id -g -u -s /block/%n"
    prio_callout "/sbin/mpath_prio_rdac /dev/%n"
    features "0"
    hardware_handler "1 rdac"
    path_grouping_policy group_by_prio
    failback immediate
    rr_weight uniform
    no_path_retry queue
    rr_min_io 1000
    path_checker rdac
    }
    }

    multipaths {
    multipath {
    wwid 3600a0b80001185dc0000306b4ae66c33
    alias sataext
    }
    }
  3. Refrescar la información sobre los caminos ...
    /etc/init.d/multipath-tools restart
    multipath -F
    multipath -v2
    ...y fijarnos en la salida, para localizar el ID de la LUN
    create: mpath2 (3600a0b80001185dc000033f64b26e485)  IBM     ,1814      FASt
    [size=100G][features=0][hwhandler=1 rdac]
    \_ round-robin 0 [prio=3][undef]
    \_ 1:0:0:0 sdb 8:16 [undef][ready]
    \_ round-robin 0 [prio=0][undef]
    \_ 1:0:1:0 sdc 8:32 [undef][ghost]
    libdevmapper: libdm-common.c(312): Created /dev/mapper/mpath
  4. Con el ID de la LUN, editaremos el fichero /etc/multipath.conf, y sustituiremos el wwid que teníamos en la sección multipaths. Recargar la información del almacenamiento:
    /etc/init.d/multipath-tools restart
    multipath -F
    multipath -v2
    multipath -ll
    ...y comprobar la salida...
    sataext (3600a0b80001185dc000033f64b26e485) dm-4 IBM     ,1814      FASt
    [size=100G][features=1 queue_if_no_path][hwhandler=1 rdac]
    \_ round-robin 0 [prio=3][active]
    \_ 1:0:0:0 sdb 8:16 [active][ready]
    \_ round-robin 0 [prio=0][enabled]
    \_ 1:0:1:0 sdc 8:32 [active][ghost]

Ahora ya podremos crear particiones en la LUN ejecutando fdisk /dev/sataext, crear volúmenes LVM, darles formato, etc...
La foto la he sacado del album de tophost en flickr

Recuperar la contraseña del root en mysql

Alguna vez me he encontrado con algún servidor de base de datos, del que no tenía la contraseña de root, y siempre termino buscando por internet. Aprovecho esta entrada para comentaros una forma de solucionarlo. El síntoma es que al ejecutar el comando mysql como root, nos encontramos con el siguiente error:

ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
  1. Lo primero será parar el servicio de mysql
    /etc/init.d/mysqld stop
  2. Ahora arrancaremos el servicios, saltándonos la tabla de privilegios, mediante:
    /usr/bin/mysqld_safe --user=mysql --skip-grant-tables
  3. Ahora desde otra consola, nos conectaremos a mysql y podremos cambiar la clave del root.
    mysql> use mysql;
    mysql> update user set password=password('secreto') where user='root';
    mysql> exit;
  4. Reiniciar el servicio, y ya podremos conectar.
    /etc/init.d/mysqld restart 
La foto la he sacado del album de Travelling Pooh en flickr

Port-mirroring en switches 3COM


Port-mirroring es una configuración que podemos establecer en un switch, con el fin de que este envíe una copia de todos los paquetes que pasan por uno o más puertos (mirroring-port) a otro puerto concreto que llamamos monitor-port o, a otro switch. Esto es muy útil cuando necesitamos monitorizar el tráfico de red o detectar intrusiones en nuestra red. Dependiendo del fabricante podremos encontrarnos que,

  • En Cisco el port-mirroring se suele llamar como Switched Port Analyzer (SPAN)
  • Mientras en 3COM el port-mirroring se denomina Roving Analysis Port (RAP)
Antes de configurar nada, siempre deberíamos identificar los puertos del switch que queremos sniffar, mirroring-ports, (ejemplo: puertos del firewall, puertos donde están los servidores, etc... ) y el puerto al que queremos dirigir todo el tráfico y donde tendremos sniffer (monitor-port). Además sería recomendable identificar estos puertos o bocas del switch, en formato ID_EN_STACK/_FRONTAL_TRASERO/PUERTO. Una vez los tenemos identificados seguiremos la siguiente secuencia de pasos:
  1. Conectarse como admin al switch por telnet desde HyperTerminal de Windows
  2. Desactivar Spanning-Tree en la boca del switch que configuraremos como monitor-port (donde conectaremos el sniffer)
    sys
    interface GigabitEthernet 2/0/15
    stp disable
    q
    save
  3. Configurar el grupo de mirroring y el puerto que se encargará del sniffing:
    mirroring­group 1 local
    mirroring­group 1 monitor­port GigabitEthernet 2/0/15
  4. Agregar al grupo de mirroring los puertos que queremos monitorizar, los mirroring-ports (una linea por cada boca de la que queremos ver el tráfico):
    mirroring­group 1 mirroring­port GigabitEthernet 1/0/17 both 
  5. Guardar los cambios:
    q
    save
  6. Comprobar el resultado:
    display mirroring­group all
La foto la he sacado del album de philcampbell en flickr.

Hacer que nuestro Linux conozca las VLANes de nuestro switch


Hace unas semanas estuve en un cliente trabajando con switches y Port-Mirroring para monitorizar tráfico de red desde un servidor Linux. La teoría es sencilla: Configurar un monitor-port en nuestro switch y configurar las bocas del switch que queremos monitorizar como mirroring-port al grupo de mirror.
El problema nos aparece cuando tenemos varias VLANes en nuestro switch y la electrónica sólo nos permite un monitor-port activo al mismo tiempo. ¿Qué se puede hacer en este caso? ... podemos usar un equipo Linux, conectado al switch en la boca configurada como monitor-port y además, configurar este puerto como trunk-port, con STP deshabilitado, y propagar por él las VLANes que nos interese monitorizar.
Con esto, la electrónica enviará a la tarjeta de red de nuestro equipo todos los paquetes que lleguen a cualquiera de las bocas del switch configuradas como mirroring-port, sólo que si hacemos un tcpdump, probablemente sólo veamos el tráfico que se corresponde a la VLAN por defecto, o en su defecto la nº1. Para ver el tráfico de otras VLANes necesitaremos:

  1. Instalar el paquete VLAN (en Debian).
    apt­get install vlan
  2. Configurar las VLANes a las que queremos tener acceso...
    vconfig add eth1 1
    vconfig add eth1 5
    ...si ahora ejecutamos el comando ip a, comprobaremos como nos ha creado una nueva interfaz de red.
  3. Configurar una dirección IP editando el fichero /etc/networtk/interfaces y añadiendo las siguientes líneas:
    auto  vlan5
    iface vlan5 inet static
    address 192.168.4.101
    netmask 255.255.255.0
    vlan_raw_device eth1
Esto es una gran comodidad cuando no podemos tener todas las tarjetas de red que necesitamos en nuestro Linux, y tenemos que montar un router, o un firewall... una maravilla, sí señor.
La foto la he sacado del album de ivanx en flickr