Reconfiguración de interfaces en entornos virutales con máquinas virtuales Linux

En entornos virtuales es habitual clonar servidores. En Linux el sistema udev, al detectar un nuevo hardware con una MAC diferente, le asigna un número de interfaz secuencial. Da igual si se le ha borrado alguna interfaz previa, la nueva que se configure seguirá la numeración. Con este comportamiento, es posible que haya cosas que no funcionen, por ejemplo si tenemos un script que haga referencia al nombre de interfaz eth0. Si queremos recuperar la numeración deberemos modificar el fichero de reglas de udev y luego además revisar los scripts de configuración de las interfaces ya que probablemente las MACs no coincidan.
He creado un nuevo script, que se puede poner en el .bashrc del usuario root por ejemplo. Dicho script detectará si existe la interfaz eth0, en caso de no existir realizará la reconfiguración de udev, limpiará configuraciones de red previas y finalmente creará los nuevos ficheros de configuración. Para crear estos ficheros tendrá en cuenta si queremos utilizar un direccionamiento estático o dinámico (DHCP). 
Utilizando este script, siempre que clonemos la máquina y accedamos con el usuario root nos preguntará la configuración de red que queremos.
Ejemplo de uso (desde una consola ya que baja las interfaces):
Verificamos que el nombre de la interfaz eth0 no existe:

Configuración de red tras el clonado

Lanzamos el script, donde veremos que baja las inerfaces de red y pide si queremos borrar configuraciones previas:

Llamada al script netconfig.sh

Pide que tipo de configuración queremos en todas las interfaces:

Reconfiguración de las interfaces

Una vez terminada la ejecución del script vemos que la interfaz eth0 ya aparece y mantiene la MAC de la interfaz que veiamos en la primer imágen:

Configuración de red final

El script:

#!/bin/bash
function static {
hostname=`hostname`
read -r -p “Hostname: [${hostname}] ” hostname
if [ -z “$hostname” ]; then hostname=`hostname`; fi
read -r -p “IP address: ” ip
read -r -p “Netmask: ” mask
grep dhcp /etc/sysconfig/network-scripts/ifcfg-eth* 2>/dev/null >/dev/null
if [ $? -eq 0 ] ; then
echo “there is a network configured with dhcp which should configure your gateway”
else
read -r -p “Gateway: ” gate
if [ $? -eq 0 ] ; then
sed -i -e ‘s#^\(GATEWAY=\).*$#\1′”${gate}”‘#’ /etc/sysconfig/network
else
echo “GATEWAY=\”${gate}\”” >>/etc/sysconfig/network
fi
fi
#echo “HOSTNAME: ${hostname}\tIP: ${ip}\tNETMASK: ${mask}”
mac=`ifconfig ${iface} | grep eth | awk ‘{ print $5}’`
if [ -f /etc/sysconfig/network-scripts/ifcfg-${iface} ]; then
rm -r /etc/sysconfig/network-scripts/ifcfg-${iface}
fi
echo “DEVICE=\”${iface}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “BOOTPROTO=\”static\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “NM_CONTROLLED=\”yes\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “ONBOOT=\”yes\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “TYPE=\”Ethernet\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “IPADDR=\”${ip}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “NETMASK=\”${mask}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “HWADDR=\”${mac}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “DNS1=\”X.X.X.X\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “DNS2=\”Y.Y.Y.Y\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “DOMAIN=\”enterprise.com\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
sed -i -e ‘s#^\(HOSTNAME=\).*$#\1′”${hostname}”‘#’ /etc/sysconfig/network
grep GATEWAY /etc/sysconfig/network 2>/dev/null >/dev/null
}

function dhcp {
echo “Configuring DHCP for ${iface}”
hostname=`hostname`
read -r -p “Hostname: [${hostname}] ” hostname
if [ -z “$hostname” ]; then hostname=`hostname`; fi
mac=`ifconfig ${iface} | grep eth | awk ‘{ print $5}’`
if [ -f /etc/sysconfig/network-scripts/ifcfg-${iface} ]; then
rm -r /etc/sysconfig/network-scripts/ifcfg-${iface}
fi
echo “DEVICE=\”${iface}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “BOOTPROTO=\”dhcp\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “HWADDR=\”${mac}\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “NM_CONTROLLED=\”yes\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “ONBOOT=\”yes\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
echo “TYPE=\”Ethernet\”” >> /etc/sysconfig/network-scripts/ifcfg-${iface}
sed -i -e ‘s#^\(HOSTNAME=\).*$#\1′”${hostname}”‘#’ /etc/sysconfig/network
}


ifconfig eth0 2>/dev/null >/dev/null
if [ $? -ne 0 ] ; then
echo “eth0 not found. Interface configuration…”
echo “Recreating interfaces”
# Rename eth1 with eth0    
echo “Stopping network”
service network stop

#Clearing devices and renaming
echo “UDEV Config…”
rm -f /etc/udev/rules.d/70-persistent-net.rules
#ls -l  /etc/udev/rules.d/70-persistent-net.rules
udevadm trigger
sleep 2
#ls -l  /etc/udev/rules.d/70-persistent-net.rules
ifdevs=`udevadm info –export-db | grep “INTERFACE=eth” | cut -d “=” -f2`
#echo “Interfaces ${ifdevs}”
count=0
for ifdev in ${ifdevs}; do
sed -i -e “s/${ifdev}/eth${count}/g” /etc/udev/rules.d/70-persistent-net.rules
# echo “sed -i -e ‘s/${ifdev}/eth${count}/g’ /etc/udev/rules.d/70-persistent-net.rules”
count=$((count+1))
# echo “count: ${count}”
done
udevadm trigger –attr-match=subsystem=net
#echo “udev Net rules”
#grep eth /etc/udev/rules.d/70-persistent-net.rules
    echo “—————————————————“
    
#Clearing configuration    
echo “Remove previous configuration”
for cfgfile in `ls /etc/sysconfig/network-scripts/ifcfg-eth*`; do
read -r -p “Remove previous configuration file ${cfgfile}? [y/N] ” response
case $response in
[yY])
rm -f ${cfgfile}
;;
*)
echo “Not removing ${cfgfile}”
;;
esac
done
    
#Setup ehternet devices
sleep 2
ifaces=`ifconfig -a | grep eth | awk ‘{ print $1}’`
#echo ${ifaces}
for iface in ${ifaces}; do
read -r -p “Do you want to configure a static IP for ${iface}? [y/N] ” response
case $response in
[yY])
static
;;
*)
read -r -p “Do you want to configure DHCP for ${iface}? [y/N] ” respdhcp
case $respdhcp in
[yY])
dhcp
;;
*)
echo “Not configuring ${iface}.”
#rm -r /etc/sysconfig/network-scripts/ifcfg-${iface}
;;
esac
;;
esac
done
#Start networking
echo “Starting networking”
service network start
fi
Anuncios

Widgets en Ubuntu: Conky

Hoy me he encontrado con una aplicación que nos permite tener unos widgets perfectamente integrados con el escritorio de Unity en Ubuntu. Se trata de Conky. Lo he probado y me parece mucho mas ligero que otros que había utilizado antes, y ademas, parece que hay muchos temas disponibles en internet. Para instalarlo simplemente basta con instalarlo desde el Ubuntu Software Center o desde un terminal:
sudo apt-get install conky-all
En la documentación oficial de Ubuntu indica como se puede configurar tocando un fichero de configuración. Sin embargo existe un programa que nos puede servir de gran ayuda. Este es Conky Manager y para instalarlo, desde un terminal añadimos el PPA y lo instalamos:
sudo apt-add-repository ppa:teejee2008/ppa
sudo apt-get update
sudo apt-get install conky-manager
Una vez instalado se puede lanzar desde el panel de Unity. Es un programa muy sencillo que nos permite seleccionar los widgets y temas que queremos tener habilitados y dependiendo del seleccionado alguna opción adicional. Permite ademas configurar opciones como la transparencia o la posición del widget. Ademas existe la opción de habilitar el arranque automático con el sistema.
Resumiendo, me parece una muy buena opción para tener un escritorio mucho mas interesante. Estos son algunos de los widgets que yo me he puesto:
Existe un paquete de temas que se puede importar desde la aplicación. Se puede descargar aqui.

Mis entrevistas con Facebook

“Success is not final, failure is not fatal; it is the courage to continue that counts.” slidesha.re/18IDRZY

Hace unas semanas recibí un mensaje de LinkedIn. El remitente era una reclutadora de Facebook, donde me comentaba que tenian algunas vacantes en las que podría encajar. Como no tenía nada que perder accedí a hablar con ella.

Es conocido que los gigantes de internet tienen unos procesos de selección muy duros con infinidad de entrevistas. En mi caso únicamente fueron dos, ambas por teléfono. Voy a contar un poco mi experiencia por si le puede servir a alguien que esté interesado en un trabajo en este tipo de empresas.

Yo no me apunté a ninguna oferta en la web de Facebook ni nada parecido. Únicamente mantengo actualizado mi perfil de LinkedIn y parece ser que tras la útlima actualización, puse las palabras clave que buscan los reclutadores. La reclutadora de Facebook me encontro, sin yo buscarlo, con lo que me pareció interesante seguir con el proceso.

Una vez revisó mi curriculum me pidió si podríamos tener una entrevista telefónica. En un principio estuve dudando puesto que la entrevista sería en ingles y mi ingles es peor que el de Ana Botella. Finalmente quedamos un día y me llamó. La reclutadora fué muy amable en todo momento, y por suerte, al no ser irlandesa, le entendía lo suficiente para mantener la conversación.

La entrevista estaba dividida en dos partes, la primera mas orientada en la descripción del puesto, las tareas, como estaban organizados, etc. La segunda parte consistió en preguntas básicas de networking y linux, todas muy básicas aunque alguna muy rebuscada.

En la primera parte me explicó que el puesto que buscaban era un SRO (Site Reliability Operations) para el equipo de Dublín. El equipo de SRO es el que se encarga de mantener la infraestructura de Facebook, con lo que pensé que mi perfil se ajustaba perfectamente, puesto que es lo que hago actualmente pero a gran escala. También hizo especial énfasis en lenguajes de programación y scripting, especialmente python. En mi trabajo suelo programar algunos scripts, pero tampoco es mi principal tarea. Parece que eso no le acabó de gustar.

Al finalizar la primera parte empezó a hacerme un pequeño cuestionario sobre diferentes temas. A nivel de networking las preguntas fueron muy básicas: que puertos utilizan los servicios típicos (ssh, dns, http), que tipo de paquetes se envian para establecer una conexión TCP, que es la MTU o como detectar que se pierden paquetes en una red. Sobre linux me preguntó cosas como que significaban los números que aparecen en la salida del comando uptime, el significado de $*, $$, $?; como se chequean errores de disco y luego algunas preguntas sobre señales entre procesos. Esto último lo tenia bastante verde y creo que es lo único en lo que falle.

Cuando terminó el cuestionario me dijo que habíamos terminado y que si quería preguntarle algo. Me pilló algo desprevenido y no había preparado nada. Eso creo que tampoco le gustó, ya que deben pensar que no estas interesado en el puesto, con lo que recomiendo tener algunas preguntas preparadas para preguntarle al reclutador. Esta entrevista duró unos 20 minutos y la verdad es que tuve buenas sensaciones puesto que la mayoría de preguntas técnicas las había respondido con soltura.

A los dos días recibí un mail diciendo que lo sentian mucho pero que mi perfil no se ajustaba a lo que estaban buscando. Pensé que se habría acabado, pero al día siguiente me llamó de nuevo la reclutadora diciendome que un manager había visto mi curriculum y que le había interesado mi experiencia como sysadmin. Parece ser que lo que buscaban inicialmente era un experto en python y con mas experiencia en programación pero que tenían alguna otra vacante en la que si podría encajar.

Al dia siguiente me envió otro mail pidiendome cuando podría hacer una segunda entrevista con un SRO y ademas me dió algunas recomendaciones, sobre todo que preparase preguntas para demostrarle interes.

Finalmente me llamó el SRO y ya empezó mal la cosa. Entre mi mal ingles y que se le oia fatal, puesto que estaba en un sitio con bastante ruido y con un manos libres, era dificil entenderlo. Me explicó en que iba a consistir la entrevista, varias preguntas de networking, otras tantas de linux y solucionar algunos casos prácticos.

Para esta segunda entrevista me esperaba un tipo de preguntas y al final fueron diferentes, llegando a muy bajo nivel. Preguntas sobre cómo funciona el comando traceroute, que le puedes explicar que sirve para conocer la ruta que siguen los paquetes en la conexión entre dos hosts. Sin embargo, lo que quería era una descripción de que tipo de paquetes se enviaba, el TTL de cada paquete, porque pasaba por un router y no por otro, etc.

Las preguntas sobre linux estaban enfocadas a los procesos. Que estados puede tener un proceso, que señales se le pueden enviar, que implica que un proceso sea zombie. Fueron muchas preguntas sobre señales que en realidad, a la hora de administrar servidores, no las utilizo mucho y como en la primera entrevista dejé mucho que desear.

Los casos prácticos se basaron en como reiniciar un servidor remotamente desde una consola y como recuperar la password de root de un servidor. La verdad que creo que le respondí como debía pero parece que él lo hubiese hecho de otra manera, quizás porque el conoce su infraestructura y como lo tienen montado y yo estaba a ciegas y respondía de forma algo mas genérica.

Finalmente, para terminar la entrevista me preguntó si quería hacerle algunas preguntas. Las típicas preguntas que sabía que le iba a hacer las tenia bien preparadas y estudiadas y sabía hasta donde podía decirme. Luego le hice alguna pregunta mas técnica y me dijo que no podía responderme ni darme detalles.

Al dia siguiente de la entrevista con el SRO recibí otro mail de la reclutadora diciendome que no seguia. Despues de la entrevista con el SRO sabía que iba a ser ese el resultado así que no me sorprendió demasiado.

Como recomendaciones para alguien que esté interesado en participar en un proceso parecido me quedo con esto:

 Algunos enlaces interesantes:

OpenStack: esto si es cloud!

Hace unos días me preguntaron si con Linux se puede virtualizar! LOL

Básicamente lo que querían era algo tipo vSphere pero barato (gratis) y con un buen performance. En GNU/Linux básicamente tenemos dos hipervisores a elegir: KVM y XEN. EL primero parece ser el elegido por Canonical o Red Hat entre otros por la integración con el Kernel de Linux. XEN por su lado esta mas ampliamente implementado en grandes infraestructuras como las de Amazon o Rackspace. Además, existe otra opción, la del uso de contenedores de Linux (LXC). No se trata de un modelo que haga uso de un hipervisor, sino que se comparte el Kernel y los recursos entre la máquina anfitriona y los huéspedes.

Viendo todas las posibilidades que existían me puse a investigar algo mas sobre algún tipo de software que permitiera una gestión mas amigable y sin la necesidad de andar todo el tiempo desde linea de comandos. Encontré varias opciones para montar clouds privadas, pero la que mas me llamó la atención fue Openstack.

Openstack es una suite de herramientas que permiten la creación de clouds privadas, públicas e híbridas. Empezó su desarrollo como un proyecto Open Source patrocinado por Rackspace y la NASA. Al tiempo la NASA abandona su desarrollo para centrarse mas en el uso como cliente, pero Rackspace continua con él y poco a poco empieza a recibir colaboraciones de muchas empresas (algunas de ellas algo conocidas: AMD, Intel, Caonical, Suse Linux, Red Hat, Cisco, Dell, HP, IBM, NEC, Yahoo!, etc hasta mas de 150).

Como principales ventajas del uso de Openstack frente a otras soluciones creo que se podrían destacar las siguientes:

  1. Se trata de un sistema abierto, un proyecto Open Source con licencia Apache 2.0. Quizás sea uno de los proyectos Open Source con un mayor crecimiento e implicación por parte de las grandes corporaciones
  2. Cuenta con una gran comunidad. Actualmente cerca de 6700 colaboradores de 87 paises. 
  3. Existe mucha información, principalmente en la Wiki del proyecto Openstack
  4. Elimina el “Vendor Locking”. El uso de Openstack no esta ligado a ningún fabricante ni proveedor de software. Se puede utilizar con diferentes hipervisores como KVM, XEN, HyperV o vSphere.
  5. Permite la federación de nubes, algo que puede ser interesante si se quiere tener una infraestructura híbrida.
  6. Como la mayoria de los desarrollos Open Source, tiene un compromiso hacia los estándares. 
  7. Existe gente que dice que es el “Linux of the cloud”, haciendo una analogía entre lo que es actualmente Linux y lo que quiere llegar a ser Openstack.

La arquitectura de Openstack es modular, pudiendo instalar todos ellos en un único host o por separado. Esto dependerá del tamaño y el objetivo de la cloud. Para entornos de pruebas lo normal es instalarlo todo en un único nodo.

Los componentes que forman la arquitectura son:

  1. Openstack Compute: Nova. Es el cerebro de la arquitectura y la que permite el control de la nube. Se debe instalar en cada nodo que vaya a formar parte del cloud.
  2. Openstack Object Storage: Swift. Es un sistema de almacenamiento escalable y altamente redundante.
  3. Openstack Image Service: Glance. Repositorio de imagenes y snapshots. Las imagenes sirven como plantillas para la generación de nuevos servidores
  4. Openstack Identity: Keystone. Proporciona un directorio central de usuarios y actua como principal sistema de autenticación.
  5. Openstack Dashboard: Horizon. Proporciona una interfaz gráfica a los usuarios.
  6. Openstack Networking: Quantum (aka nova-network). Se encarga de la gestión de las redes y las direcciones IP que se le asignarán a las instancias.
  7. Openstack Block Storage: Cinder (aka nova-volume). Proporciona un almacenamiento a nivel de bloque persistente. Además se encarga de la creación y el agregado de dichos volúmenes a las instancias.

 En el siguiente gráfico se puede ver la relación entre ellos:

Para hacer pruebas se puede seguir la guia que han desarrollado entre varios institutos: Cloud – IES Gonzalo Nazareno o utilizar una ISO con todo instalado. Tendremos dos opciones:

  1. StackOps Community Edition : CD instalable basado en Ubuntu de la empresa española StackOps para la preparación de entornos de test.        
  2. Ubuntu Cloud Live : Imagen Live con todo ya instalado. En el desktop puedes encontrar las instrucciones para arrancar.

Se puede encontrar mucha información en internet sobre el proyecto, aunque en español escasea. Existen 2 grupos de google, uno español y otro argentino, y recientemente he creado una comunidad en Google+ (espero que empiece a tener algo de vida!):

spain-openstack-user-group@googlegroups.com
openstack-argentina@googlegroups.com
 Comunidad OpenStack en Español

En próximas entradas iré comentando mis experiencias y las configuraciones que he ido probando.

Links de interes:
Página oficial del proyecto: http://www.openstack.org/
Cuenta de twitter oficial: https://twitter.com/OpenStack
Entrada en wikipedia: http://en.wikipedia.org/wiki/OpenStack
Ubuntu cloud: http://www.ubuntu.com/cloud/private-cloud/openstack
Rackspace: http://www.rackspace.com/cloud/openstack/
Proyecto cloud en educación: http://www.gonzalonazareno.org/cloud/

Namebench: Benchmark de DNS

¿Cuales son los mejores DNS para optimizar tu conexión?

Cuando nos damos de alta en un ISP, éste nos suele facilitar unos datos de conexión o el Router preconfigurado, para utilizar sus DNS. Muchas veces estos servidores no son los mejores, y el retardo que agregan puede hacer que notemos que ciertas conexiones vayan más lentas.

Para poder establecer el mejor DNS existe una herramienta alojada en “Google Code”. Esta herramienta hace un chequeo de tiempos de respuesta, y resolución de determinadas direcciones con el fin de determinar cual es el mejor DNS, y por tanto con el que tendremos una resolución de nombres más rápida.

La herramienta se puede descargar de la página web del proyecto Namebench:
http://code.google.com/p/namebench/

Existen varias versiones para diferentes plataformas. En Linux, descargaríamos los fuentes y una vez descomprimido sería tan sencillo como ejecutar el script python:
$ tar xzf namebench-1.3.1-source.tgz
$ cd namebench-1.3.1/
~/namebench-1.3.1$ ls
ChangeLog.txt  COPYING   libnamebench    README.txt  tools
cocoa          data      namebench.py    setup.py
config         JSON.txt  nb_third_party  templates
~/namebench-1.3.1$ python namebench.py
The python-tk (tkinter) library is missing, using the command-line interface.

namebench 1.3.1 – best source (automatic) on 2012-12-07 23:47:28.704379
threads=40/2 queries=250 runs=1 timeout=3.5 health_timeout=3.75 servers=11
——————————————————————————
– Reading Top 2,000 Websites (Alexa): data/alexa-top-2000-domains.txt (0.7MB)
– Reading Cache Latency Test (100% hit): data/cache-hit.txt (0.1MB)
– Reading Cache Latency Test (100% miss): data/cache-miss.txt (0.1MB)
– Reading Cache Latency Test (50% hit, 50% miss): data/cache-mix.txt (0.1MB)
– Skipping /home/xxxxxxx/.config/google-chrome/Default/History (125d old)
– Reading Chromium: /home/xxxxxx/.config/chromium/Default/History (1.2MB)
– Reading Mozilla Firefox: /home/
xxxxxx/.mozilla/firefox/dsvuj7wu.default/places.sqlite (10.0MB)
– Generating tests from Mozilla Firefox (27981 records, selecting 250 automatic)
– Selecting 250 out of 10471 sanitized records (random mode).

– Checking query interception status…
– Checking connection quality: 1/3…3/3
– Congestion level is 2.41X (check duration: 96.46ms)
– Applied 2.41X timeout multiplier due to congestion: 1.2 ping, 9.0 health.
– Checking latest sanity reference
– Building initial DNS cache for 4515 nameservers (40 threads)
– Checking nameserver availability (40 threads): 0/4515……………………………………………………………………………….


Este proceso dura varios minutos, ya que hace múltiples consultas a varios servidores de DNS y una vez terminado procesa las estadísticas para mostrarnos el resultado. En mi caso estos son los resultados que he obtenido:
Fastest individual response (in milliseconds):
———————————————-
Telefonica Movis ################################ 58.84600
Movistar ES      ################################ 59.97086
Localhost IPv4   ################################ 60.54616
InfoTelecom ES   ################################# 60.76503
Terra ES         ################################# 61.05208
BT Espagna ES    ##################################### 68.42899
Neuf Cegetel S3  ######################################### 76.67494
Google Public DN ############################################ 81.78401
UltraDNS-2       ################################################ 89.45608
DynGuide-2       #################################################### 98.44708
OpenDNS-2        ##################################################### 100.60596

Mean response (in milliseconds):
——————————–
Movistar ES      ########################## 122.16
Telefonica Movis ############################# 132.68
Localhost IPv4   ############################# 132.74
Terra ES         ############################### 143.17
Google Public DN ################################ 148.57
UltraDNS-2       ##################################### 171.51
OpenDNS-2        ####################################### 181.24
DynGuide-2       ####################################### 181.68
Neuf Cegetel S3  ############################################ 206.33
InfoTelecom ES   ############################################# 209.36
BT Espagna ES    ##################################################### 249.98

Con estos resultados los DNS propuestos son:
Recommended configuration (fastest + nearest):
———————————————-
nameserver 194.179.1.100   # Movistar ES  
nameserver 194.179.001.101 # Telefonica Movistar-2 ES  
nameserver 127.0.0.1       # Localhost IPv4


Además nos ha guardado un reporte en HTML en /tmp con los resultados y gráficos:

Mean Response DurationMean Duration GraphFastest Individual Response Duration
Fastest Response GraphResponse Distribution Chart (First 200ms)Response Distribution Graph (first 200ms)Response Distribution Chart (Full)

Response Distribution Graph (full)
He remarcado un warning que me ha dado al lanzar por primera vez la aplicación. Al no tener instalado el paquete python-tk me ha lanzado el script automáticamente por línea de comando. Si instalo el paquete python-tk y lo vuelvo a lanzar tendremos una interfaz gráfica donde configurar diferentes parámetros:
$ sudo apt-get install python-tk


Si ya teníamos instalado ese paquete y queremos aún así lanzarlo en modo comando lo lanzaremos con la opción -x:
$ python namebench.py -x

Con la opción -h veremos la ayuda, con todas las opciones disponibles para realizar las diferentes pruebas.

Zero-Padding en Bash

Hoy me he encontrado con el problema de tener que generar una secuencia de números desde un terminal con bash. A todos los números de dicha secuencia debían estar formados por tres caracteres con lo que debía añadir ceros de relleno a la izquierda del número.



Buscando un poco me he encontrado con esta interesante entrada donde explica como usar el comando printf basándose en el uso que el autor le da a la función en C.

http://jonathanwagner.net/2007/04/zero-padding-in-bash/

A modo de resumen, para generar la secuencia he utilizado el siguiente bucle:

for i in {1..10}; do printf “%03d\n” $i; done
001
002
003
004
005
006
007
008
009
010


De esta forma me he podido descargar los 100 ficheros secuenciales que me interesaban de una forma rápida y cómoda.

for i in {1..100}; do seq=`printf “%03d\n” $i`; wget $url1$seq$url2; done

Nota: parece que desde la versión 4.1.5 de bash se puede simplificar de la siguiente manera:
$ for i in {01..10}; do echo $i; done
01
02
03
04
05
06
07
08
09
10

Las últimas versiones de las diferentes distribuciones de GNU/Linux ya vienen con una versión de bash superior, con lo que la segunda opción será mas óptima. En sistemas antiguos o con otras shells se podría utilizar la opción con el printf.

SNMP y Trabajo con MIBs

Muchas veces debemos monitorizar elementos que disponen del protocolo SNMP. Normalmente es fácil encontrar el fichero de MIB del dispositivo que queremos monitorizar, ya sea en a través del fabricante o a través de webs de terceros como oidview. Una vez tenemos el fichero de la MIB, ¿que hacemos?¿Como podemos obtener el OID de un nodo en particular?

Como para todo, existirán múltiples formas de trabajar con este fichero, pero para los usuarios de Linux tenemos disponible el paquete “snmp” con un grupo de herramientas que nos servirán para nuestro propósito. Lo primero que deberemos hacer es instalar dicho paquete, si no lo hemos hecho ya antes, con un simple “sudo apt-get install snmp“. Una vez instalado tendremos disponibles comandos como snmpwalk, snmpget o snmptranslate.
En el siguiente ejemplo veremos como obtener el valor de algunas variables que nos pueden interesar para monitorizar un SAI con un adaptador CS121. Con dicho módulo venia su correspondiente CD de utilidades donde podíamos encontrar la MIB del producto, en concreto la RFC1628cs121.MIB. 
Nos podríamos ver tentados por visualizar dicho fichero, pero la sintaxis que utiliza (ASN1) no es la mas amigable para su lectura. 
La herramienta snmptranslate nos sirve para interpretar dicho fichero MIB. A primera vista podríamos analizar el arbol de la mib para evaluar que variables nos pueden interesar en la monitorización, para ello ejecutaremos el siguiente comando, especificando que carge el fichero de MIB del módulo:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tp 
+–iso(1)
   |
   +–org(3)
      |
      +–dod(6)
         |
         +–internet(1)
            |
            +–mgmt(2)
               |
               +–mib-2(1)
                  |
                  +–upsMIB(33)
                     |
                     +–upsObjects(1)
                     |  |
                     |  +–upsIdent(1)
                     |  |  |
                     |  |  +–upsIdentManufacturer(1)
                     |  |  |
                     |  |  +–upsIdentModel(2)
                     |  |  |
                     |  |  +–upsIdentUPSSoftwareVersion(3)
                     |  |  |
                     |  |  +–upsIdentAgentSoftwareVersion(4)
                     |  |  |
                     |  |  +–upsIdentName(5)
                     |  |  |
                     |  |  +–upsIdentAttachedDevices(6)
                     |  |
                     |  +–upsBattery(2)
                     |  |  |
                     |  |  +– -R– EnumVal   upsBatteryStatus(1)
                     |  |  |        Values: unknown(1), batteryNormal(2), batteryLow(3), batteryDepleted(4)
Si en la herramienta de monitorización podemos cargar el fichero de MIB, con interrogar al dispositivo con el nombre del nodo que nos interesa será suficiente (mas adelante explicaré algún ejemplo). En cambio, muchas herramientas de monitorización no permiten la carga del fichero de MIB y le debemos especificar el OID que queremos interrogar. El árbol de OIDs de la MIB lo podemos ver de la siguiente forma:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -To
.1.3
.1.3.6
.1.3.6.1
.1.3.6.1.2
.1.3.6.1.2.1
.1.3.6.1.2.1.33
.1.3.6.1.2.1.33.1
.1.3.6.1.2.1.33.1.1
.1.3.6.1.2.1.33.1.1.1
.1.3.6.1.2.1.33.1.1.2
.1.3.6.1.2.1.33.1.1.3
.1.3.6.1.2.1.33.1.1.4
.1.3.6.1.2.1.33.1.1.5
.1.3.6.1.2.1.33.1.1.6
.1.3.6.1.2.1.33.1.2
.1.3.6.1.2.1.33.1.2.1
.1.3.6.1.2.1.33.1.2.2
.1.3.6.1.2.1.33.1.2.3
.1.3.6.1.2.1.33.1.2.4
.1.3.6.1.2.1.33.1.2.5
.1.3.6.1.2.1.33.1.2.6
.1.3.6.1.2.1.33.1.2.7
.1.3.6.1.2.1.33.1.3
.1.3.6.1.2.1.33.1.3.1
.1.3.6.1.2.1.33.1.3.2
.1.3.6.1.2.1.33.1.3.3
.1.3.6.1.2.1.33.1.3.3.1
.1.3.6.1.2.1.33.1.3.3.1.1
.1.3.6.1.2.1.33.1.3.3.1.2
.1.3.6.1.2.1.33.1.3.3.1.3
.1.3.6.1.2.1.33.1.3.3.1.4
.1.3.6.1.2.1.33.1.3.3.1.5
El problema ahora es que no sabemos cual es la correspondencia entre el OID y el nodo que evaluamos. Esto se soluciona pasando como parámetro en el snmptranslate la opción -Tz, que nos devolverá la forma numérica y etiqueta de todos los objetos:
julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Tz
“org” “1.3”
“dod” “1.3.6”
“internet” “1.3.6.1”
“mgmt” “1.3.6.1.2”
“mib-2” “1.3.6.1.2.1”
“upsMIB” “1.3.6.1.2.1.33”
“upsObjects” “1.3.6.1.2.1.33.1”
“upsIdent” “1.3.6.1.2.1.33.1.1”
“upsIdentManufacturer” “1.3.6.1.2.1.33.1.1.1”
“upsIdentModel” “1.3.6.1.2.1.33.1.1.2”
“upsIdentUPSSoftwareVersion” “1.3.6.1.2.1.33.1.1.3”
“upsIdentAgentSoftwareVersion” “1.3.6.1.2.1.33.1.1.4”
“upsIdentName” “1.3.6.1.2.1.33.1.1.5”
“upsIdentAttachedDevices” “1.3.6.1.2.1.33.1.1.6”
“upsBattery” “1.3.6.1.2.1.33.1.2”
“upsBatteryStatus” “1.3.6.1.2.1.33.1.2.1”
“upsSecondsOnBattery” “1.3.6.1.2.1.33.1.2.2”
“upsEstimatedMinutesRemaining” “1.3.6.1.2.1.33.1.2.3”
“upsEstimatedChargeRemaining” “1.3.6.1.2.1.33.1.2.4”
“upsBatteryVoltage” “1.3.6.1.2.1.33.1.2.5”
“upsBatteryCurrent” “1.3.6.1.2.1.33.1.2.6”
“upsBatteryTemperature” “1.3.6.1.2.1.33.1.2.7”
“upsInput” “1.3.6.1.2.1.33.1.3”
“upsInputLineBads” “1.3.6.1.2.1.33.1.3.1”
“upsInputNumLines” “1.3.6.1.2.1.33.1.3.2”
“upsInputTable” “1.3.6.1.2.1.33.1.3.3”
“upsInputEntry” “1.3.6.1.2.1.33.1.3.3.1”
“upsInputLineIndex” “1.3.6.1.2.1.33.1.3.3.1.1”
“upsInputFrequency” “1.3.6.1.2.1.33.1.3.3.1.2”
“upsInputVoltage” “1.3.6.1.2.1.33.1.3.3.1.3”
“upsInputCurrent” “1.3.6.1.2.1.33.1.3.3.1.4”
“upsInputTruePower” “1.3.6.1.2.1.33.1.3.3.1.5”

Para obtener mas información de un nodo en concreto primero deberíamos obtener la forma mas completa:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Onf -IR upsInputTruePower
.iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower

Ya ejecutando el snmptranslate con el OID completo obtendremos mas información del nodo, con una descripción de la variable, las unidades, la  sintaxis, etc.

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -Td -OS .iso.org.dod.internet.mgmt.mib-2.upsMIB.upsObjects.upsInput.upsInputTable.upsInputEntry.upsInputTruePower
UPS-MIB::upsInputTruePower
upsInputTruePower OBJECT-TYPE
  — FROM UPS-MIB
  — TEXTUAL CONVENTION NonNegativeInteger
  SYNTAX INTEGER (0..2147483647) 
  DISPLAY-HINT “d”
  UNITS “Watts”
  MAX-ACCESS read-only
  STATUS current
  DESCRIPTION “The magnitude of the present input true power.”
::= { iso(1) org(3) dod(6) internet(1) mgmt(2) mib-2(1) upsMIB(33) upsObjects(1) upsInput(3) upsInputTable(3) upsInputEntry(1) 5 }

Para obtener el OID numérico que utilizaremos en la herramienta de monitorización para este nodo ejecutaremos la siguiente consulta:

julian@ubuntu:$ snmptranslate -m “/tmp/RFC1628cs121.MIB” -On UPS-MIB::upsInputTruePower
.1.3.6.1.2.1.33.1.3.3.1.5
Con estos datos ya podemos montar nuestro sistema de monitorización, evaluando únicamente las variables que nos interesen. 
También tendremos dos utilizades que nos permitirán obtener los valores directamente desde el módulo. El snmpwalk hará un recorrido por las ramas del árbol desde el nodo que le especifiquemos mientras que el snmpget nos devolverá el valor específico de un nodo. En ambos métodos podemos especificar el fichero de MIB que queremos utilizar o especificar el OID en formato numérico. Veamos varios ejemplos:
julian@ubuntu:$ snmpget -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsOutputPower.1
upsOutputPower.1 = INTEGER: 700 Watts

julian@ubuntu:$ snmpget -Os -c comunidad -v 1 DireccionIP 1.3.6.1.2.1.33.1.4.4.1.4.1
mib-2.33.1.4.4.1.4.1 = INTEGER: 700

julian@ubuntu:$  snmpwalk -Os -c comunidad -m “./RFC1628cs121.MIB” -v 1 DireccionIP upsInputEntry
upsInputLineIndex.1 = INTEGER: 1
upsInputFrequency.1 = INTEGER: 500 0.1 Hertz
upsInputVoltage.1 = INTEGER: 230 RMS Volts
upsInputCurrent.1 = INTEGER: 0 0.1 RMS Amp
upsInputTruePower.1 = INTEGER: 0 Watts

julian@ubuntu:$ snmptranslate -m “./RFC1628cs121.MIB” -On UPS-MIB::upsInputEntry
.1.3.6.1.2.1.33.1.3.3.1
julian@ubuntu:$  snmpwalk -Os -c comunidad -v 1 DireccionIP .1.3.6.1.2.1.33.1.3.3.1
mib-2.33.1.3.3.1.1.1 = INTEGER: 1
mib-2.33.1.3.3.1.2.1 = INTEGER: 500
mib-2.33.1.3.3.1.3.1 = INTEGER: 230
mib-2.33.1.3.3.1.4.1 = INTEGER: 0
mib-2.33.1.3.3.1.5.1 = INTEGER: 0
Se puede encontrar mas información en los siguientes enlaces:

Uso de proxy en Linux

Uno de los problemas que nos encontramos al utilizar máquinas con Linux en entornos corporativos es la restricción de acceso a Internet. Muchas compañías disponen de un proxy de navegación que limita y controla donde pueden acceder los usuarios. En Linux disponemos diferentes formas de configurarlo, muchas veces no es trivial y dependiendo de si el proxy requiere autenticación o no, puede llevar mas de un quebradero de cabeza.

A continuación comentaré los diferentes casos que me he ido encontrando:
  • Uso del proxy desde la línea de comandos:
    • En la línea de comandos hay que configurar las variables de entorno que se utiliza para definir el proxy:
export http_proxy=”http://X.X.X.X:8080″
export https_proxy=”http://X.X.X.X:8080″
export ftp_proxy=”http://X.X.X.X:8080″
    • Para hacer el cambio permanente habría que editar el fichero del perfil para cargarlo al iniciar la shell (.bashrc para bash)
    • Si el proxy requiere autenticación, se puede especificar el usuario o el usuario y password de la siguiente manera:
    • Si no se configura el usuario y password se puede pasar como parámetro del wget, por ejemplo:
julian@ubuntu:~$ wget –proxy-user=usuario –proxy-password=password http://wwww.blabla.com/index.html
  • Uso del proxy para el gestor de paquetes de Ubuntu (apt, synaptic, software center):
  • Uso del proxy para el gestor de paquetes de Red Hat (y derivados):
    • Añadir en el fichero de configuración de yum los parámetros del proxy (/etc/yum.conf):

      proxy=http://X.X.X.X:8080 proxy_username=usuario proxy_password=password
  • Uso del proxy en el escritorio de ubuntu:
    • Desde la llegada de Unity ha cambiado un poco la configuración del proxy. Se configura en “System Settings” y ahí en Network. En el panel de la izquierda aparece la opción de configurar el proxy. Ahí para cada protocolo se debe especificar el servidor y el puerto a utilizar. El problema viene a la hora de utilizar autenticación, para eso deberemos configurarlo mediante el dconf-editor. Si no lo tenemos instalado se deberá instalar el paquete dconf-tools (sudo apt-get install dconf-tools).
Una vez abierto el dconf-editor iremos a la rama system->proxy. En esa rama general podremos configurar las excepciones para las que no utilizar el proxy. En la rama system->proxy->http podremos configurar el usuario y password de nuestro proxy:

Nota: En caso de que el password contenga algún carácter especial como una @ se deberá sustituir por el caracter ASCII en los ficheros de configuración (a excepción del de Yum, que se puede escribir sin modificaciones). Por ejemplo:
p@ssword pasaría a ser p%40ssword

Instalación de la última versión de aMule

Como es conocido, en los repositorios de Ubuntu existe una gran cantidad de paquetes y programas, pero muchas veces no están en la última versión. Es el caso de aMule, del que salió una versión este mes y del cual no se ha actualizado automáticamente.

En launchpad podemos encontrar los repositorios para la última versión. Accediendo a la página principal de launchpad y buscando por aMule aparece la página correspondiente al programa. Desplegamos el link “Technical details about this PPA” y alli aparcerá la entrada que debemos añadir al archivo /etc/apt/sources.lst (o a través de la herramienta gráfica):

En la captura anterior aparece también la clave del repositorio. Una vez añadida la fuente al fichero se deberá importar la clave y actualizar la lista de paquetes del sistema:

julian@ubuntu:~$ sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys 4B2C459E
Executing: gpg –ignore-time-conflict –no-options –no-default-keyring –secret-keyring /etc/apt/secring.gpg –trustdb-name /etc/apt/trustdb.gpg –keyring /etc/apt/trusted.gpg –keyserver keyserver.ubuntu.com –recv-keys 4B2C459E
gpg: solicitando clave 4B2C459E de hkp servidor keyserver.ubuntu.com
gpg: clave 4B2C459E: clave pública “Launchpad PPA for aMule stable releases” importada
gpg: Cantidad total procesada: 1
gpg: importadas: 1 (RSA: 1)
julian@ubuntu:~$ sudo apt-get update

A continuación deberemos desinstalar la versión de aMule que tengamos de los repositorios oficiales de Ubuntu ya que si no no detecta la nueva versión y nos devuelve un error como el siguiente al actualizar el sistema:

Los siguientes paquetes se han retenido:
amule amule-common amule-daemon

Al desinstalar no se pierde nada de la configuración de aMule. No obstante es posible hacer un backup del directorio $HOME/.aMule/ Para instalar el programa se puede utilizar de nuevo apt-get para instalarlo, esta vez desde los nuevos repositorios:

julian@ubuntu:~$ sudo apt-get remove amule amule-common amule-daemon
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Se instalaron de forma automática los siguientes paquetes y ya no son necesarios.
libupnp2
Utilice «apt-get autoremove» para eliminarlos.
Los siguientes paquetes se ELIMINARÁN:
amule amule-common amule-daemon
0 actualizados, 0 se instalarán, 3 para eliminar y 0 no actualizados.
Se liberarán 13,6MB después de desempaquetar.

julian@ubuntu:~$ sudo apt-get install amule amule-common amule-daemon
Leyendo lista de paquetes… Hecho
Creando árbol de dependencias
Leyendo la información de estado… Hecho
Se instalarán los siguientes paquetes extras:
libupnp3
Los siguientes paquetes se ELIMINARÁN:
libupnp2
Se instalarán los siguientes paquetes NUEVOS:
amule amule-common amule-daemon libupnp3
0 actualizados, 4 se instalarán, 1 para eliminar y 0 no actualizados.
Necesito descargar 6948kB de archivos.
Se utilizarán 21,1MB de espacio de disco adicional después de desempaquetar.
¿Desea continuar [S/n]? s
Des:1 http://ppa.launchpad.net hardy/main amule-common 2.2.6-0ubuntu1~hardy1 [2417kB]
Des:2 http://ppa.launchpad.net hardy/main libupnp3 1:1.6.6-3ubuntu1~ppa2 [92,0kB]
Des:3 http://ppa.launchpad.net hardy/main amule 2.2.6-0ubuntu1~hardy1 [2531kB]
Des:4 http://ppa.launchpad.net hardy/main amule-daemon 2.2.6-0ubuntu1~hardy1 [1908kB]

Buscar fichero creado entre dos fechas en linux

Interesante artículo publicado en DiarioLinux donde se explica cómo encontrar un fichero modificado entre dos fechas. Para ello se utiliza el comando touch para crear dos ficheros modificándole la fecha de creación con el parámetro “-d”.


Despues con el comando find se buscarán ficheros mas nuevos que el primer fichero pero que sean mas antiguos que el segundo (para ello utiliza el símbolo de negación ! escapado aunque también podría haber utilizado -not). El ejemplo que utilizan en DiarioLinux es el siguiente:

julian@ubuntu:~$ $ touch -d “15 sep 2008” /tmp/begin
$ touch -d “30 sep 2008” /tmp/end
$ find . -newer /tmp/begin -a \! -newer /tmp/end