Dummy Hacks

Se acabó mi verano de trabajador del CERN, sobre esto espero tener algo que decir más adelante... Hasta ahora no he posteado por que los servidores han estado caídos y la gente de vacaciones así que no había nadie para resetearlos. Bueno, mejor pongo unas cuantas fotos que siempre son divertidas (hay más en "Continuar Leyendo..."):

AVISO: No he redimensionado ni recomprimido las imágenes así que andan sobre una media de 1,5MB cada una.

Esta es mi oficina, que comparto con Nikolaos, un griego con el que me parto de risa (aparte de que el hombre es un crack en lo que a física aplicada, incluyendo computación, se refiere).

Hoy me ha llegado la foto de los "summer student" del CERN, la verdad es que de la gente de la foto "sólo" 140 sómos summer student, el resto son estudiantes enviados por sus universidades ya que dicen que han de venir una vez en la vida aquí. Hoy si puedo publico unas fotos de las cavernas del LHCb.

Cómo siempre no me atrevo a hablar de mi trabajo por las cláusulas de confidencialidad y no tener problemas con mis jefas (que por cierto me han dejado alucinado con su nivel).

Photograph: Maximilien Brice - Copyright: CERN

Hace tiempo que no escribo pero por supuesto tengo mis motivos: la "mudanza" al CERN ha sido un poco caótica y he tardado más de lo esperado en aterrizar.

Bueno voy a lo interesante, esta mañana he podido visitar el Data Center y esto es lo que he obtenido (fotos ilustrativas):

Este es el punto de intercambio de internet europeo, dónde todos los proveedores obtienen la "conexión" (así que ya sabeis de donde viene todo el pr0n que descargais ).

(La historia sigue)

SNMP es muy útil para monitorizar/gestionar ciertos aspectos de los switch, router e impresoras en red.

En Debian se pueden instalar las aplicaciones básicas para su gestión con:

# apt-get install snmp

Para ver todo el subárbol (por ejemplo de la IP 10.0.0.1 y cuya llave pública es "public"), basta con ejecutar el comando:

# snmpwalk -Os -c public -v 1 10.0.0.1

Si sólo se quisiera ver el subárbol de "system":

# snmpwalk -Os -c public -v 1 10.0.0.1 system

Para obtener un valor único se puede usar snmpget, por ejemplo para obtener con los datos anteriores (y dado el árbol devuelto) para ver la descripción del sistema (por ejemplo):

# snmpget -v1 -Cf -c public 10.0.0.1 system.sysDescr.0

SNMPv2-MIB::sysDescr.0 = STRING: Router de Salida a Internet

Todo esto es bastante útil para por ejemplo los plugins de Nagios o incluso pequeños scripts del sistema, en este caso uno que compruebe el estado de unas IPs dadas cada 5 minutos:

#!/bin/bash

#Tiempo de actualizacion
TIME="5m"

#Direcciones IP separadas por espacio
IPS="172.20.46.123 172.20.46.193"

while [ 1 -eq 1 ]; do

  for i in $IPS; do

   snmpwalk -Os -c public -v 1 $i system.sysStatus.0


  done

 
  sleep $TIEMPO

done

Hace algún tiempo que no escribo, esencialmente por que he estado enfrascado en el curso de Emacs y con la conferencia de RMS (con el que he tenido el placer de dialogar un poco y tener un par de comidas).

Esta semana hemos recibido los servidores HP Proliand DS180 (G5), unas buenas máquinas. No obstante habíamos solicitado equipos con soporte para RAID 0,1 y 5 por hardware, cuál ha sido nuestra sorpresa al descubrir que las controladoras de placa (ICH9R) son por Software, con lo que tras discutir con el comercial hemos obtenido la controladora SmartArray E200 (con el BBWC, que es la expansión de memoria que le permite soportar RAID5) dentro del presupuesto convenido, por supuesto.

Lecciónes aprendida:

• Los comerciales de HP son unos impresentables (a menos que se me desmuestre lo contrario).
• Las controladoras "por defecto" de los Proliant (las "embedded") son Software, y no hay drivers más que para determinadas versiones de Fedora o de SUSE.
• Para tener RAID por Hardware en HP hace falta un SmartArray, y cuidado donde pone "Opcional" por que hace falta una ampliación de memoria (BBWC le llaman ellos) que sale de 100€ para arriba.

Si alguien tiene más interés en estos falsos arrays, antes de comprar cualquier "controladora" mejor echar un vistazo a esto.

Hace tiempo escribí del uso de PowerTop para monitorizar el ACPI y optimizar el uso de la batería. Últimamente parece que ha mejorado bastante (parece que gracias a HAL, una batería de 12 celdas da sobre 4:30-5h en el modo power_save).

Un script de ejemplo:

#!/bin/bash

#Suggestion: increase the VM dirty writeback time from 4,99 to 15 seconds with:
#This wakes the disk up less frequenty for background VM activity

echo 1500 > /proc/sys/vm/dirty_writeback_centisecs


#Suggestion: Enable laptop-mode by executing the following command:
echo 5 > /proc/sys/vm/laptop_mode


#Suggestion: Disable 'hal' from polling your cdrom with:
hal-disable-polling --device /dev/scd0 'hal'
#is the component that auto-opens a window if you plug in a CD but disables SATA power saving from kicking in.

#Suggestion: Enable SATA ALPM link power management via:
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy

Por supuesto cada uno debe de seguir los consejos indicados por powertop y crear su propio script, aunque este que indico es bastante genérico (las acciones están indicadas en los comentarios).

Lo típico de dejar un script ejecutándose en background (o en un screen) y queremos que nos mande un mail al terminar (usando un servidor SMTP deseado):

No iba a hacerlo pero finalmente me he presentado al concurso de RTB en la XGN 10, lo he hecho en medio día y en C++ (sin API ni paso de mensajes, parseo de cadenas "a pelo"). También he conocido a una gente muy interesante de la FIC que está intentando devolver a la vida el proyecto (haciendo APIs, documentación, montando torneos asiduamente, recopilando bots...), el link a su página.

No tengo demasiadas esperanzas (sobre todo por lo básico de mi bot), pero en cuanto acabe el concurso postearé el código.

Edit: Inexplicablemente el bot ha pasado la ronda previa pero ha caido en la semifinal. [Código del Bot Techno_Viking]

Edit 2: Finalmente ha ganado Seve con su bot "camperbot", el cógido estará en la página que mencione arriba (Belay). Enhorabuena!

Voy a iniciar una serie de entradas derivadas de mis experiencias personales con la esperanza de ayudar a quién decida embarcarse en la misma aventura y poder ahorrarle dolores de cabeza. Cómo es mucha información la ire partiendo en 3 o 4 trozos y quizás al final lo junte todo en un único documento (ODT/PDF):

Antes de nada decir que no voy a entrar en la selección de las máquinas (quizás un anexo en el último post), ya que eso se debe de decidir con respecto a cada caso en concreto.

Tarea1: Seleccionando el local adecuado

La primera cosa a decidir a la hora de montar un centro de cálculo o CPD es el local "físico" (las comunicaciones y electricidad lo trataré en consiguientes posts), por lo que necesitaremos el asesoramiento de diversos profesionales.

Elementos a tener en cuenta:

• Peso y dimensiones de las máquinas. Por supuesto todo debe de caber dentro
• Carga máxima admitida por el suelo del local.
• Puertas/accesos con dimesiones adecuadas para las máquinas/electrónica.
• Temperatura "habitual". Si es más bien baja esto favorecerá la refrigeración.

Una vez se han conseguido los planos del local lo recomendable sería hablar con un arquitecto para que valorase la carga máxima que podría soportar el suelo del mismo, no creo que a los "vecinos" de abajo les hiciese gracia encontrarse un armario de 500kg encima de su mesa.

Recomendaciones para la selección:

• Un sótano siempre es mejor que un primero, el concepto de carga máxima deja de ser preocupante (si es el piso más bajo del edificio), a parte la refrigeración natural ayudará al ahorro energético (usualmente). Un problema que se podría añadir a esto es la posibilidad de inundaciones causado por escorrentía de lluvias, este aspecto deberá de ser valorado y propuesta una solución (como sumideros en zonas críticas, suelo técnico o banquetas para la circuitería).
  
• Buscar un local con pocas ventanas (pero sí con tomas de aire), la luz es una fuente de calor.

Este tema me ha tocado de cerca por trabajo estos días al desarrollar aplicaciones en un sistema x86 (32 bit) para una arquitectura IA64 (64 bit), concretamente de cálculo intensivo por lo que la precisión de los datos era imprescindible.

Lo primero decir que GNU/Linux (GCC en mi caso) para 64 bit usa la arquitectura de programación LP64 y en 32 bit ILP32, cómo puede verse en la tabla con los tipos de datos:

Antes de nada, si demasiado geek y se me ocurren cosas raras, pero me he montado un clon libre de la iPillow, con la diferencia de que la mía me ha valido 16 euros y la privativa sale por unos 75. Ah por cierto tiene una licencia WTFPL [ver licencia]

Componentes:

• Almohada o cojín grande. 5 euros
• Altavoces Logitech S-120 (2,3 W RMS). 8 euros
• Bridas grandes. 0,60 euros
• Cinta Americana o similar. 1 euro
• Espuma amarilla. 1 euro
• Percha de Madera para pantalones. 0,50 euros

Herramientas:

• Tijeras
• Fuerza bruta

Seguir leyendo para el proceso y fotos...

Siguiendo la información encontrada en estas dos páginas:

http://local.wasp.uwa.edu.au/~pbourke/dataformats/fortran/

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/6861ababada30129

Me quedo con la frase de la primera " FORTRAN Weirdness, what were they thinking?"

Manos a la obra, primero el código en FORTRAN, escribe a un fichero binario (unformatted) dos números dobles:

double precision :: a = 2.458899, b= 132230.2323
open(unit=5, file = 'test.bin', form='unformatted')
write(5) a, b
close(5)

Y el código en C para leerlo (lectura RAW incluso en C++):

double a,b;
char tmp[8];
FILE in;
in=fopen("test.bin","r");
fread(tmp,1,4,in);        / 4 bytes inciales: 0 tamaño /
fread(&a,sizeof(a),1,in); / Lectura Primer double /
fread(&b,sizeof(b),1,in); / Lectura Segundo double /
printf("%g %g\n",a,b);
fread(tmp,1,4,in);  / 4 bytes finales, no siempre aparecen:  tamaño 0*/
fclose(in);

La cosa es que en cada "línea" del fichero se meten al principio y al final 4 bytes (aumentando así el tamaño del fichero) donde la primera cifra es un cero y  la segunda la longitd de la "línea" (en este caso 16 bytes correspondientes a los 2 double), al final de la "línea" se repite al revés, por ejemplo:

0 16 a b 0 16

Espero haber ayudado a que alguien no se haya comido la cabeza tanto como yo...

¿Si el Software Libre es como una receta de cocina por qué una receta de cocina no puede ser como el Software Libre? Siempre he intentado experimentos culinarios de todo tipo (con mayor o menor nivel de éxito), y una cosa que siempre me ha intrigado es como congelar determinado tipo de alimento, tres cosas que he congelado con éxito (y luego comido):

• Huevos: No se pueden congelar enteros ya que explotarían (física elemental) , no obstante si se bate bien se pueden meter en una bolsa plástica (yo lo hice con 3 huevos).


• Filloas (Crepes): Para congelarlos hay que enrollar 4 o 5 juntos en forma de tubo, esto es necesario ya que al congelarse se vuelven quebradizos. Finalmente meter en una bolsa bien sellada para que el hielo no las queme.


• Tortilla de Patatas: Dividirla en 4 trozos (4 radios) y meterlos bien sellado en una bolsa para que el hielo no los queme.

Para descongelarlo mejor dejarlo que se haga sólo por el ambiente que en el microondas o sartén. La duración en el congelador (4 estrellas) es de como máximo un año, pero es recomendable consumirlo en como mucho 6 meses.

• Udev y Xen no se llevan bien. Sobre todo por lo que a la tarjeta de red se refiere, cada vez que se arranca la máquina virtual (y a pesar de definir una MAC estática) el sistema virtual se empeña en crear un nuevo interfaz (he llegado a tener hasta eth9), mi solución es un poco radical pero como no puedo (más bien no quiero) pasar de Udev: borrar el fichero (hacer backup!) /etc/udev/network.rules


• No es aconsejable que las Máquinas Virtuales usen más VCPU que las reales. En teoría la compartición de recursos permitirían superar este límite físico pero en la práctica ya se me han "estropeado" (posteraría los errores de SMP y las violaciones varias pero son más bien inmensas) varios sistemas.


• Mejor arrancar las Máquinas Virtuales a mano. Ya me ha sucedido que las máquinas en /etc/xen/auto se hayan arrancado antes que servicios y "cosas" que pueden dar errores, de nuevo he llegado a tener bastantes problemas (incluso de corrupción de memoria).