Los anuncios patrocinados y la publicidad en el blog

   Se ha hablado este último mes en multitud de sitios sobre los post patrocinados y la imagen que crean en un blog. Además, también se ha tocado el tema de la publicidad y cómo afecta a los usuarios recurrentes de una página. En mi caso he realizado tres análisis patrocinados y el blog tiene publicidad desde julio de 2007.

   A mi me gusta escribir el blog, si no me gustara no lo haría, eso está muy claro. Pienso que todos los que tenemos blogs y le dedicamos horas a investigar, preparar artículos, responder las preguntas de los comentarios,... lo hacemos porque nos gusta y nos apetece. Si fuera una obligación o una carga, o no lo haríamos o lo llevaríamos muchísimo peor y al final se notaría en la cantidad y la calidad de los artículos.

   Con estas premisas, si además de hacer lo que te gusta y te apetece, puedes sacar algo a cambio, mejor, no?. Este blog tiene una temática definida (aunque empezó siendo un blog personal en el que contaba lo que me pasaba por la cabeza), por lo que no estoy dispuesto a aceptar ningún análisis patrocinado que no pueda aportar algo a los lectores. Me han llegado solicitudes de buscadores de vuelos, webs de poesía, hoteles en diversos puntos de España (en esta última semana más de 40 solicitudes),... y eso es algo por lo que no estoy dispuesto a pasar. Una cosa es sacar algún provecho y otra es venderte a lo que sea. Yo también leo muchos blogs y cuando me encuentro con un análisis patrocinado que no tiene nada que ver con la temática del blog me enfado bastante.

   Por otro lado está el tema de la publicidad. Al principio este blog no tenía publicidad. Total, era un blog que no leía nadie y en el que escribía sobre cualquier tema. En este post se pueden observar las estadísticas de los primeros cuatro meses y son de pena. El cuarto mes tuve 221 visitantes únicos: ¡¡en todo un mes!!, cuando ahora la media está en torno a las 250-300 visitas diarias. Luego, en julio del año pasado, hablando con un amigo (Jose), después de salir en portada de barrapunto con el artículo del Raid 1 en linux, éste me dijo que como ya tenía más visitas, pusiera publicidad, que total, poquito a poco iría acumulando algo. Al final le hice caso, pero vamos, que tampoco es nada del otro mundo y no voy a poder dejar el trabajo para vivir del blog... ;-). Además el ritmo de publicación ha disminuido bastante últimamente porque estoy más liado en el curro y tengo menos tiempo libre en casa del que me gustaría. Ahora mismo estoy posteando desde un hotel de Spiez (Suiza) en el que llevo toda la semana por motivos de trabajo y en unas horas seguramente coja un avión de vuelta a España.

   En definitiva, que voy a mantener la publicidad porque en algún momento me servirá para algún pequeño caprichito y los análisis patrocinados siempre que puedan os aportar algo a todos vosotros.

Ocultar la ventana de "Equipo Bloqueado" en una Red Novell

   Hace unos meses veíamos cómo ocultar la molesta ventana de "Equipo Bloqueado" cuando bloqueamos la sesión en windows. La red de la empresa en la que trabajo es un tanto peculiar y esta semana nos han instalado el cliente Novell para poder acceder a recursos compartidos en dicha red (aunque también seguimos iniciando la sesión en el dominio Windows). Esto ha provocado que que las ventanas de inicio de sesión, cambio de contraseña, bloqueo del equipo,... hayan cambiado por las nuevas del cliente Novell. Así, cuando bloqueamos el equipo volvemos a tener una fea ventana que tapa nuestra foto de fondo de pantalla.

   Después de investigar cual es la dll en la que se encuentra la ventana llego a este foro en el que alguien pregunta por dicha dll, que finalmente resulta ser C:\WINDOWS\system32\nls\ESPANOL\nwginar.dll. Abro el ResourceHacker, encuentro el diálogo, cambio el código por el siguiente:

105 DIALOG 0, 0, 0, 0
STYLE WS_POPUP | WS_VISIBLE
CAPTION ""
LANGUAGE LANG_SPANISH, 0x1
FONT 0, ""
{
}

Posteriormente salvo la dll, con la consola de recuperación hago el cambio y en poco más de 10 minutos y dos reinicios vuelvo a ver la foto de mi peque a ventana completa sin la molesta ventana quedando algo parecido a esto:

   P.D: Para ver una explicación detallada de los pasos consultar el post anterior para ocultar la ventana en windows.

Actualizando a Hardy Heron

   Por fin he tenido tiempo para actualizar mi versión de Ubuntu a Hardy Heron. Después de más de 1 Gbyte de paquetes para descargar y casi 2 horas actualizando, reinicié la máquina y tuve el primer fallo. Me cargaba el entorno gráfico pero nunca salía la ventana de login, se quedaba el reloj dando vueltas y vueltas. Lo primero que se me ocurrió fue cambiarme de terminal con CRTL + ALT + F1, conectarme con mi usuario y reiniciar GDM. El resultado fue el mismo. Lo siguiente fue pararlo y entrar en modo gráfico con el mítico startx. En ese caso sí arrancaba y todo funcionaba a la perfección. El error sólo podía ser del GDM, así que después de buscar un rato llegué a este enlace en el que a más gente le ocurría lo mismo. Al final, la solución la encontré aquí. Finalmente, lo que pasaba era que había un problema con el paquete ubuntu-gdm-themes y no funcionaba correctamente con algunas configuraciones. En mi caso era porque tenía instalado un tema para el gdm distinto al original y parecía que no era compatible. Lo arreglé y cambié el tema y todo solucionado.

   Otro pequeño problema ha sido con Firefox 3. La versión que han incluído por defecto en Hardy ha sido la beta 5, lo que desde mi punto de vista no ha sido muy acertado. La he probado un rato y se nota la velocidad, pero la mayoría de las extensiones que utilizo no funcionan todavía en firefox 3, por lo que he tenido que desinstalar ésta e instalar la antigua 2.0.0.14.

   El resto han sido todo cosas buenas. Noto que el sistema va mucho más ligero y fluído. Los programas cargan antes y todo es mucho más rápido en general. Además la nueva versión de CompizFusion es rápida y estable y ha solucionado un pequeño problema que tenía con la versión anterior que no me guardaba algunos cambios. A falta de trabajar más días con esta nueva versión, mis primeras impresiones son muy satisfactorias y se ha mejorado bastante respecto a gutsy. Ahora ya sólo me queda compilar el kernel a mi gusto, probar la webcam usb, el infrarrojo y terminar de afinar un poco la configuración para dejarlo todo adaptado a mi gusto.

La informática de antaño

   Estaba haciendo limpieza el otro día en el trastero y al abrir un par de cajas me he encontrado con todo tipo de hardware que me ha hecho recordar cómo era todo en el mundo de la informática hace algunos años. Me he decidido a hacer unas cuantas fotos y a recordar...

Tarjetas perforadas: Datan de los años 1960-1970 y se utilizaban para introducir instrucciones en los ordenadores. Actuan como un código binario en función de si están perforadas o no. Como véis tengo unas cuantas, en total hay 25 perforadas y 4 vírgenes. He querido destacar un fragmento de código de una tarjeta en la que se ve una fecha: 31 de Marzo de 1981, seguramente era para sacar un listado a final de mes. Por aquel entonces sólo utilizaron la fecha con formato 31.03.81 y no se preocuparon de lo que ocurriría en el año 2000... ;-)
   He hablado con mi padre puesto que las tarjetas eran suyas y las utilizó en el trabajo hace mucho y me ha contado que tenían una especie de máquina de escribir en la que tecleaban la instrucción en Cobol y cuando la terminaban la máquina perforaba la tarjeta. Así, iban construyendo el programa línea a línea y al final colocaban todas las tarjetas en un alimentador de hasta 5000 tarjetas que se encarga de leerlas e ir ejecutando el programa. Estos programas corrían contra un host IBM 3090 que estaba en Alemania (mi padre trabajaba desde Madrid). He buscado información de esa máquina y para aquella época era impresionante: dos o cuatro procesadores y 64 ó 128 MB de almacenamiento (según modelo). Y estamos hablando de principios de los 80!.


Disquetes 8": Los empezó a utilizar IBM a finales de los 60 para cargar el microcódigo de arranque en sus mainframes System/370. Antes de disponer de esta unidad de disco utilizaban unidades de cinta para realizar esta carga, pero el proceso era muy lento. Si os fijáis en el de la izquiera, podéis ver que la capacidad era de sólo 1024 bytes, es decir, un "miserable" Kbyte!!.


Disquetes 5.25": El primer prototipo se diseñó en 1975 y surgió por la necesidad de cambiar los discos de 8" que resultaban demasiado grandes. Seguramente los más viejos del lugar recuerden las disqueteras de sus primeros 8086 y la "gran cantidad de información" que podíamos almacenar en estos disquetes. En las fotos véis que la capacidad había aumentado considerablemente, yo tenía de 360 KBytes y de 1.2 MBytes. El disquete de arriba a la derecha es la versión 3.21 de D.O.S.


Disquetes de 3.5": Surgieron a mediados de los 80 como sustitutos de los de 5.25". Por aquel entonces éstos últimos ya no resultaban nada prácticos y además se podían estropear con mucha facilidad. Así, después de diversos formatos e intentos por reducir el tamaño se llegó a los discos de 3.5" que todos conocemos. Las ventajas eran innumerables: formato mucho más pequeño, más capacidad debido al rediseño que se hizo, estaban protegidos por una pequeña chapita,... De estos seguro que sí os acordáis todos. Como podéis ver tengo unas cuantas cajas con juegos clásicos (Monkey Island, Doom, Maniac Mansion,...), multitud de programas (WordPerfect, dBase III,...), discos de arranque... grabados en disquetes de 3.5" y la mayoría comprimidos con el mítico ARJ.


Platos de disco duro: Aunque seguro que la mayoría ha desarmado algún que otro disco duro, los platos de abajo son los normales de discos duros de 3.5" y los de arriba son de discos duros mucho más antiguos. Seguramente no tenían ni siquiera 20 MBytes de capacidad, por lo que os podéis hacer una idea de cuando serán.


Placa de 486: Esta es la placa de un 486DX 50Mhz. Como véis por aquel entonces no había slots PCI y lo máximo eran los nuevos slots VESA Local Bus que creo que nunca llegué a utilizar.


Memorias SIMM de 30 contactos: Las que utilizaba en la placa anterior con mi 486. Empecé con 4 Mbytes cuando me compré el ordenador pero un año después lo amplié con 8 MBytes más. Con esos 12 Mbytes era capaz de ejecutar todos los juegos nuevos sin ningún problema y el ordenador iba muy fluido. Todavía conservo 16 módulos (recordad que iban de 2 en 2) de diversos tamaños que en total suman 152 MBytes de RAM.


Tarjetas gráficas ATI Mach: Todavía conservo un par de tarjetas gráficas de la época. La de abajo es una ATI Mach32 ISA y la de arriba una ATI Mach64 PCI. ¡Qué buenos ratos me hicieron pasar las dos!.


Tarjetas de red: Todas 3Com de diversos modelos. Las de la izquierda son de 10 MBits/seg y conexión ISA, las inferiores de 10 Mbits/seg y conexión PCI y las superiores de 100 Mbits/seg y conexión PCI.


Tarjetas de sonido: Las míticas Sound Blaster AWE 64. ¿Quién no ha tenido una Sound Blaster en su máquina?.


Controladora SCSI: Tiene conexión ISA y creo que nunca la llegué a utilizar, tengo poco que añadir...


Unidad de cinta: En la época de los discos duros de 120MB que parecía que nunca los ibas a llenar y que al final terminaban llenos de juegos (de MS-DOS, claro). La unidad de cinta era perfecta para poder hacer backups de tus juegos y los pocos datos que se acumulaban por aquel entonces. La capacidad era abrumadora porque en una sóla cinta entraban 340MB!. Tenía una unidad externa que se conectaba al puerto de paralelo y posteriormente me hice con esta interna que se conectaba al cable de la disquetera. Las transferencias eran bastante lentas pero podías dejar el backup lanzado y cuando volvías tenías todo tu disco duro en una pequeña cinta.


Cintas de backup: Como ya he comentado tenían 340 Mbytes de capacidad que incluso se podían duplicar si los backups se hacían con la compresión habilitada.


Pentium MMX: Este micro fue una mejora realizada a los primeros Pentium que les añadía las Multimedia Extensions.


Pentium Pro: Fue el procesador diseñado por intel para reemplazar a los Pentium originales. Se utilizó básicamente en servidores y estaciones de trabajo de alto rendimiento y su característica principal es que estaba diseñado para poder montarse en placas bi-procesador.


Placa Pentium 2: Esta era mi placa para el pentium 2 a 300 Mhz que tuve. Esta placa ya llevaba memoria SDRAM, tenía slots PCI e ISA y además introducía el AGP para la conexión de la tarjeta gráfica. Este ordenador me estuvo acompañando muchos años y todavía funciona. En la entrada Servidor Raid 1 en Preproducción de marzo de 2007 comentaba que lo había montado de nuevo para hacer una prueba del raid 1 en linux con hardware real.


Pentium 2: Intel creó este micro después del Pentium Pro. La principal característica que más llamaba la atención era su enorme tamaño y su encapsulado. Era algo totalmente distinto a lo que estábamos acostumbrados a ver.


Memoria SDRAM: Este tipo de memorias ya no era necesario montarlas de 2 en 2 y fueron las precursoras de las actuales DDR, DDR2,.... Se podían mezclar de cualquier tamaño y funcionaban sin problemas. La mayoría de los módulos que tengo funcionan y en total suman 896 MBytes de RAM repartidos en los 10 módulos que se ven.


Tarjetas PCMCIA: El principal uso de este tipo tarjetas es para utilizarlas como expansión en los portátiles. Así, en los tiempos en que éstos no tenían ni modem ni tarjeta de red integrados con una simple tarjeta pcmcia se podían ampliar. Este tipo de tarjetas se podían conectar y desconectar en caliente (el famoso plug&play).


Discos duros: En total tengo 14 discos duros IDE de los que seguramente no debe funcionar casi ninguno. Son discos muy antiguos y su capacidad va desde los 850 MBytes a los 4.2 GBytes. Los fabricantes son Seagate, Sansumg, Quantum y Fujitsu.


   A todo esto que habéis visto hay que añadirle multitud de cables IDE, cable de red, conectores DB25 y DE9 desarmados y listos para soldar en un cable, cables de audio de los que se conectaban a la tarjeta de sonido y al lector de cd's, algún lector de cd's y grabadora antigua, tres modems de 33.6 bps y 56 bps... y diverso hardware más.

   Quiero dar las gracias a mi padre que ha estado muchos años dedicándose a esto y gracias al cual he podido estar cerca de todo lo que acabáis de ver. Muchas veces he pensado que si él hubiese sido albañil, fontanero, mecánico... en lugar de informático, yo no habría llegado donde estoy ni tendría esta pasión y afición que tengo por la informática. ¡Muchas gracias papá!.
   Además, tampoco me olvido de mi mujer por dejarme conservar todas estas reliquias y cacharros viejos como los llama ella en el trastero...

Un diez para el SAT de Rimax

   Hace un año mi hermana nos regaló una cámara de vigilancia de bebés para que la tuviéramos lista para cuando naciera Judith. Durante todo este tiempo la hemos estado usando por las noches para vigilarla por si se despierta, llora o le pasa cualquier cosa. Es muy útil y práctica porque no te tienes que levantar de la cama y puedes ver en cualquier momento cómo se encuentra.

   El caso es que la semana pasada se nos estropeó el adaptador de corriente de la cámara y con las pilas casi seguro que no nos duraba encendida toda la noche. Miramos en la web de Rimax en el apartado de garantías y el servicio que ofrecen es de lo mejor. Te dan 2 años completos de garantía para todos sus productos. Se compromenten a recogerlo en tu casa, repararlo o sustituirlo por uno nuevo en caso de no poder hacerlo y enviártelo de nuevo a casa sin ningún coste adicional. Al día siguiente de tramitar la garantía se pusieron en contacto conmigo por email solicitando una copia del ticket para comprobar la fecha de compra. Me dijeron que les indicara claramente cual era el cargador que fallaba (cámara o monitor) y que me enviarían uno nuevo. Como el del monitor también me fallaba a veces les pedí los dos. En dos días llegó por mensajería un paquete con los dos cargadores nuevos y desde entonces ya podemos usar de nuevo la cámara por las noches.

   Cuando elegimos la cámara no conocíamos el excelente servicio post-venta que tiene Rimax. Esto ha hecho que a partir de ahora, cuando tenga que comprar cualquier gadget mire si Rimax tiene algo que me interese, porque es una marca que voy a tener muy en cuenta en el futuro. Escribiendo este post me he acordado de las peleas que tuve durante casi 6 meses con Panasonic por un móvil que le regalé a mi mujer hace más de 4 años, pero esa es una historia para otro post...

¿OOXML?... No, gracias

   Se ha hablado y escrito mucho la semana pasada sobre la aprobación de OOXML por parte de ISO como estándar. En los medios más importantes se recogen numerosos comentarios, críticas, lamentos,...
Se habló tanto en slashdot como en barrapunto de la aprobación por parte de ISO. Kriptópolis también se hizo eco de la noticia y posteriormente se conocieron la manipulación de Polonia y las irregularidades de Noruega.

   A partir de ahí han habido numerosas declaraciones. Uno de los que más duramente han cargado contra ISO y OOXML ha sido Mark Shuttleworth (fundador de Ubuntu) que no se ha mordido la lengua.

Pienso que devalúa la confianza que las personas tienen en los procesos de estandarización. Es triste que ISO no quiera admitir que todo el proceso ha fallado gravemente. Cuando tienes un proceso construido sobre la verdad y cuando se abusa de esa verdad, el proceso se debería parar.

   Y para finalizar Rosa García, presidenta de Microsoft España nos sorprendió el pasado viernes con esta entrada en su blog. Desde su posición es lógico que tenga que defender OOXML, pero clama al cielo lo que comenta en el artículo. De hecho, lo leí el viernes por la noche y no tuve más remedio que contestarle en su blog:

Iván
04 abril 23:52
(http://lopezivan.blogspot.com)
¡Qué fuerte me parecen estas palabras!

Todo el mundo sabe que lo único que quería conseguir Microsoft con la estandarización es obligar a todo el mundo a usar su formato. Vale que dices: "...tras el último anuncio de interoperabilidad de Microsoft, a corto plazo será posible “guardar como” ODF desde cualquier aplicación de Office por defecto si así se desea."
Quien va a usar eso?. El usuario de "a pie" no sabe nada de formatos ni tiene idea de nada. Si cuando va a guardar su documento el formato que aparece por defecto es ooxml, pues ese será con el que se guardará.

Otro: "El estándar presenta algunas limitaciones en diversos aspectos, como la gestión de fórmulas en hojas de cálculo o las funcionalidades de accesibilidad, para garantizar que las personas con discapacidad puedan utilizar los documentos en formato ODF pero, en cualquier caso, Microsoft no se opuso en su momento a la estandarización de ODF".
Comentas que existen muchos formatos de imágenes, de compresión de videos,... y que ODF tiene algunas limitaciones. La solución pasa por una revisión del estándar ya existente, no por hacer uno nuevo.

Otra perla: "El proceso de estandarización de Open XML ha sido transparente y ha cumplido todos los requerimientos de ISO. El estándar se ha aprobado por mayoría absoluta, con el apoyo del 86% de los países miembros de ISO. Por encima de cualquier otro condicionante, el respaldo de la gran mayoría de los países representados en ISO demuestra que la lógica técnica es la que finalmente se impone."
Toda la blogosfera y muchísimos medios se han hecho eco de lo que ha ocurrido con las votaciones y cómo se han amañado. ¿Cómo es posible casos como el de Noruega que con 19 votos en contra y sólo 5 a favor, el país vote sí?. Está claro, se han movido maletines y se ha sobornado a mucha gente.

Más: "Desde el momento en que ECMA e ISO aprueban el formato Open XML como estándar internacional, Microsoft deja de controlar este formato, que pasa ahora a depender de los cuerpos de estandarización internacionales".
No nos engañemos, con esas 6000 páginas de especificación, muy pocas empresas distintas a Microsoft van a ser capaces de implementar completamente el formato, por lo que al final, sólo serán los productos de Microsoft los que lo puedan utilizar bien.

Entiendo que tienes que defender a tu compañía pero hay cosas que comentas que no son normales. En fin...

Saludos, Iván.

   Para finalizar, yo lo tengo muy claro. No pienso instalarme office 2007 (todavía utilizo el 2000 las pocas veces que entro en windows) y no pienso utilizar ooxml. Convertiré todos mis documentos a ODF y haré "campaña" con familiares y amigos para que utilicen ODF en lugar de ooxml.
   ¿Alguien piensa qué ocurrirá con sus documentos dentro de 15, 20 ó 50 años si están todos bajo control de Microsoft?. Yo no pienso pasar por el aro. Cuando la gente empiece a instalarse masivamente el office 2007 en sus casas (pirata, por supuesto) y empiecen a enviar las típicas chorradas en ooxml, simplemente les responderé a su email diciendo que si desean que ese documento lo pueda utilizar todo el mundo, lo conviertan y lo envíen con un estándar de verdad como es ODF y no con otro conseguido a golpe de talonario. Eliminaré el email y listo, una chorrada menos.

Convertir un raid 1 a un raid 5 sin formatear

   Hace un mes Javier Ros me contaba que se había montado un servidor Ubuntu en casa con un raid 1 para almacenar sus datos siguiendo mi artículo del Raid 1 en Linux. En ese mismo comentario me planteaba que se le estaba llenando el raid y que en lugar de hacer un nuevo raid 1 (puesto que necesitaba dos discos adicionales) había pensado en hacer un raid 5 añadiendo solamente un disco más. Así, me pasaba un enlace que había encontrado en el que se muestra cómo pasar de un raid 1 a un raid 5 sin necesidad de formatear y sin perder la información.

   Como sabéis, no me creo las cosas si no las pruebo. Además he estado buscando información sobre cómo funciona un raid 5 y cómo puede ser posible hacer el cambio sin perder los datos. Así, en este artículo vamos a ver un poco de teoría, posteriormente la conversión de un raid 1 a raid 5 siguiendo el tutorial inicial añadiendo mis propios comentarios, y finalmente mis impresiones sobre el raid 5.

Un poco de Teoría
   Un raid 5 es la evolución lógica de un raid 4. Divide los datos en bloques y distribuye la paridad entre el total de discos del raid. Así, se elimina el problema del raid 4 de tener la paridad en un único disco y que éste se convierta en un cuello de botella. Este tipo de raid tiene una tolerancia a los fallos de un disco. Si uno falla el raid puede seguir funcionando y cuando se reemplaza el disco que ha fallado, se puede reconstruir la información que falta partiendo de la existente en el resto de discos.

   El cálculo de la paridad se realiza con la función lógica XOR cuya característica es que devuelve 1 si los bits de entrada son diferentes y 0 si son iguales. Esta es una característica muy importante puesto hace que dicha función sea reversible. Veámoslo con un ejemplo para que quede más claro:

	Binario	Decimal
A	11000110	198
B	00100101	37
XOR	11100011	227

   Como hemos dicho, la función es reversible, por lo que si "le damos la vuelta":

	Binario	Decimal
A	11000110	198
B	11100011	227
XOR	00100101	37

   Es decir, que partiendo de A y teniendo la paridad podemos calcular B. Esta propiedad también se aplica a A XOR B XOR C XOR D ... XOR N = PARIDAD, de manera que si tenemos un raid de N discos y falla cualquiera, la información que falta se puede calcular sin problemas partiendo del resto de datos y de la paridad.

   El truco para realizar la conversión consiste en que si aplicamos dicho algoritmo a dos discos, lo que obtenemos es que los dos discos se quedan en espejo!. Esto es así porque la paridad de un único bloque es él mismo, debido a que el algorimo del raid 5 necesita al menos dos bloques. Así, la única diferencia entre un raid 1 de dos discos y un raid 5 de dos discos son los metadatos. Si reemplazamos estos metadatos convertiremos el raid 1 en un raid 5.

La parte práctica
   Ahora ya sí, con la teoría aprendida vamos a realizar la conversión. Partimos de un sistema Debian ya instalado con un raid 1 creado con 2 discos y al 99% de su capacidad.

shian:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md3              496M  464M  6.3M  99% /mnt/md3

Desmontamos el raid y lo paramos.

shian:~# umount /dev/md3
shian:~# mdadm --stop /dev/md3
mdadm: stopped /dev/md3

Creamos el raid 5 con los dos dispositivos del raid 1 (sdf1 y sdg1).

shian:~# mdadm --create /dev/md3 --level=5 --raid-devices=2 /dev/sdf1 /dev/sdg1
mdadm: /dev/sdf1 appears to contain an ext2fs file system
    size=524160K  mtime=Wed Mar 26 16:43:27 2008
mdadm: /dev/sdf1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Wed Mar 26 15:09:37 2008
mdadm: /dev/sdg1 appears to contain an ext2fs file system
    size=524160K  mtime=Wed Mar 26 16:43:27 2008
mdadm: /dev/sdg1 appears to be part of a raid array:
    level=raid1 devices=2 ctime=Wed Mar 26 15:09:37 2008
Continue creating array? y
mdadm: array /dev/md3 started.

Podemos observar cómo se reconstruye el raid y en la información detallada vemos que ya es un raid 5.

shian:~# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md3 : active raid5 sdg1[2] sdf1[0]
      524160 blocks level 5, 64k chunk, algorithm 2 [2/1] [U_]
      [=====>...............]  recovery = 27.1% (143104/524160) finish=0.5min speed=11008K/sec

shian:~# mdadm --detail /dev/md3
/dev/md3:
        Version : 00.90.03
  Creation Time : Wed Mar 26 17:19:26 2008
     Raid Level : raid5
     Array Size : 524160 (511.96 MiB 536.74 MB)
    Device Size : 524160 (511.96 MiB 536.74 MB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 3
    Persistence : Superblock is persistent

    Update Time : Wed Mar 26 17:20:16 2008
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 64K

           UUID : df77ed88:83aa5bac:daa25bcf:b5b2c6e7
         Events : 0.2

    Number   Major   Minor   RaidDevice State
       0       8       81        0      active sync   /dev/sdf1
       1       8       97        1      active sync   /dev/sdg1

Ahora añadimos el nuevo disco para tener los 3 que queremos en el raid 5 y ampliamos el dispositivo. Podemos comprobar que se ha añadido el nuevo disco que se está redimensionando el raid.

shian:~# mdadm --add /dev/md3 /dev/sdh1
mdadm: added /dev/sdh1

shian:~# mdadm --grow /dev/md3 --raid-disks=3 --backup-file=/tmp/raid1-5.backup
mdadm: Need to backup 128K of critical section..
mdadm: ... critical section passed.

shian:~# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md3 : active raid5 sdh1[2] sdg1[1] sdf1[0]
      524160 blocks super 0.91 level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      [=>...................]  reshape =  8.3% (44544/524160) finish=2.6min speed=2969K/sec

Forzamos la comprobación del filesystem y lo redimensionamos.

shian:~# e2fsck -f /dev/md3
e2fsck 1.40-WIP (14-Nov-2006)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md3: 20680/131072 files (0.6% non-contiguous), 491521/524160 blocks

shian:~# resize2fs -p /dev/md3
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/md3 to 1048320 (1k) blocks.
Begin pass 1 (max = 64)
Extending the inode table     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/md3 is now 1048320 blocks long.

Después de montar de nuevo el raid, comprobamos el nuevo tamaño (los 500MB del nuevo disco):

shian:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md3              992M  465M  476M  50% /mnt/md3

No se nos puede olvidar finalmente modificar el archivo /etc/mdadm.conf para que se actualicen los datos de nuestro nuevo raid 5.

shian:~# cd /etc/mdadm
shian:/etc/mdadm# cp mdadm.conf mdadm.conf.`date +%y%m%d`
shian:/etc/mdadm# echo "DEVICE partitions" > mdadm.conf
shian:/etc/mdadm# mdadm --detail --scan >> mdadm.conf

Conclusiones
   Hemos visto que es posible realizar la conversión de un raid 1 a un raid 5 sin perder los datos y sin necesidad de recrear el raid desde cero. Aún así, la pregunta es ¿merece la pena pasar a un raid 5?.
   Depende. Para un entorno doméstico sin mucha carga y sin un uso muy intensivo yo diría que sí. La alternativa a tener un raid 5 pasa por un raid 10, pero en este caso ya necesitaríamos 4 discos en lugar de tres. La capacidad del volumen total sería la misma en ambos casos, pero para el raid 10 utilizaríamos un disco más!. En el lado positivo tendríamos dos discos de redundancia a fallos (uno de cada mirror), recuperaciones mucho más rápidas y mayor rendimiento.
   Por contra, el principal problema del raid 5 es el tiempo de recuperación en caso de fallo de un disco y el pobre rendimiento que obtenemos cuando se está realizando dicha recuperación. De nuevo, en un entorno doméstico esto no debería representar mayor problema, pero aún así es un hecho a tener en cuenta antes de tomar la decisión final.

Un escritorio diferente

   El otro día toqué por primera vez un windows vista. Un compañero del trabajo se compró un portatil nuevo y se lo llevó para enseñárnoslo. Quise ver el nuevo interfaz Aero y la verdad es que me pareció muy básico y pobre. Les comenté a mis compañeros que iba a hacer un video de mi escritorio de Linux para que vieran unos efectos de verdad con CompizFusion y sin necesidad de una máquina y una gráfica muy potentes. Sin más, este es el video:



   Sé que muchos de estos efectos son pijadas, pero hay muchas opciones que son realmente útiles y sí que aumentan la productividad a la hora de trabajar.

   Por supuesto todo el proceso de realización del video está realizado con software libre. La grabación la he hecho con XVidCap, para el montaje he utilizado KDEnlive y para añadir la música y redimensionar el video final mencoder.

Raid 1 en un sistema ya instalado

   En el artículo del Raid 1 en linux veíamos cómo montar un raid 1 con Debian para tener fiablidad en nuestros datos y en el caso de que fallase un disco no perderlos. De esta forma aseguramos nuestros datos, pero en caso de fallo del disco de sistema irremediablemente tendríamos que instalar de nuevo todo.

   Lo que vamos a ver en este artículo es cómo montar un raid 1 completo de todo el sistema Debian, con éste ya instalado y funcionando. De esta forma contesto a varias personas que me han pedido este artículo tanto en los comentarios del primero como por email. Para no hacer muy pesado el artículo obviaré algunas partes que están detalladas en el artículo anterior del raid 1, por lo que si algún paso no lo comprendes, por favor lee el artículo anterior para aclarar las dudas.

   Debo aclarar que este tutorial está pensado para Debian y similares por lo que en otras distribuciones no funcionará correctamente al no existir el comando update-initramfs.

Partimos de un sistema ya instalado con tres particiones distintas: /dev/sda1 para /boot, /dev/sda5 para el swap y /dev/sda6 para /.

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda6             7.4G  509M  6.5G   8% /
tmpfs                  63M     0   63M   0% /lib/init/rw
udev                   10M   84K   10M   1% /dev
tmpfs                  63M     0   63M   0% /dev/shm
/dev/sda1             177M   11M  157M   7% /boot

Después de añadir el disco a la máquina utilizamos el truco que ya usamos en el artículo original para copiar la tabla de particiones de un disco a otro:

shian:~# sfdisk -d /dev/sda | sfdisk /dev/sdb
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 1044 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/sdb: unrecognized partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1            63    385559     385497  83  Linux
/dev/sdb2        385560  16771859   16386300   5  Extended
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
/dev/sdb5        385623   1172744     787122  82  Linux swap / Solaris
/dev/sdb6       1172808  16771859   15599052  83  Linux

Editamos con fdisk las particiones de /dev/sdb y cambiamos del tipo a fd de las número 1, 5 y 6. El resultado final es:

...
Command (m for help): p

Disk /dev/sdb: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          24      192748+  fd  Linux raid autodetect
/dev/sdb2              25        1044     8193150    5  Extended
/dev/sdb5              25          73      393561   fd  Linux raid autodetect
/dev/sdb6              74        1044     7799526   fd  Linux raid autodetect

Ahora creamos los dispositivos raid para las particiones.

shian:~# mdadm --create /dev/md0 --level=1 --raid-disks=2 missing /dev/sdb1
mdadm: array /dev/md0 started.
shian:~# mdadm --create /dev/md1 --level=1 --raid-disks=2 missing /dev/sdb5
mdadm: array /dev/md1 started.
shian:~# mdadm --create /dev/md2 --level=1 --raid-disks=2 missing /dev/sdb6
mdadm: array /dev/md2 started.

Formateamos las nuevas particiones.

shian:~# mkfs.ext2 /dev/md0
shian:~# mkswap /dev/md1
shian:~# mkfs.ext3 /dev/md2

Actualizamos el archivo mdadm.conf con los nuevos dispositivos raid.

shian:~# cd /etc/mdadm
shian:/etc/mdadm# cp mdadm.conf mdadm.conf.`date +%y%m%d`
shian:/etc/mdadm# echo "DEVICE partitions" > mdadm.conf
shian:/etc/mdadm# mdadm --detail --scan >> mdadm.conf

Montamos las particiones del raid.

shian:~# mkdir /mnt/md0
shian:~# mkdir /mnt/md2

shian:~# mount /dev/md0 /mnt/md0
shian:~# mount /dev/md2 /mnt/md2

Editamos el archivo /etc/fstab y cambiamos sda1, sda5 y sda6 por los nuevos dispositivos del raid (md0, md1 y md2 respectivamente).

# /etc/fstab: static file system information.
#
#                
proc            /proc           proc    defaults        0       0
/dev/md2        /               ext3    defaults,errors=remount-ro 0       1
/dev/md0        /boot           ext2    defaults        0       2
/dev/md1        none            swap    sw              0       0
/dev/hdc        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto  0       0

Editamos el archivo /boot/grub/menu.lst de configuración del grub para añadir las entradas a ambos discos duros. Duplicamos la línea que tenemos del arranque, cambiamos sda6 por md2 y cambiamos el disco duro del que arranca.

# Línea original
#title           Debian GNU/Linux, kernel 2.6.18-4-686
#root            (hd0,0)
#kernel          /vmlinuz-2.6.18-4-686 root=/dev/sda6 ro
#initrd          /initrd.img-2.6.18-4-686
#savedefault

# Nuevas líneas
title           Debian GNU/Linux, kernel 2.6.18-4-686 (HD1)
root            (hd1,0)
kernel          /vmlinuz-2.6.18-4-686 root=/dev/md2 ro
initrd          /initrd.img-2.6.18-4-686
savedefault

title           Debian GNU/Linux, kernel 2.6.18-4-686 (HD0)
root            (hd0,0)
kernel          /vmlinuz-2.6.18-4-686 root=/dev/md2 ro
initrd          /initrd.img-2.6.18-4-686
savedefault

Ahora actualizamos el ramdisk para que se reflejen los cambios que hemos hecho.

shian:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.18-4-686

Copiamos los datos de las particiones antiguas a las nuevas del raid. La opción 'x' es muy importante porque sino al copiar desde / copiaríamos todo de manera recursiva.

shian:~# cp -ax / /mnt/md2

shian:~# cd /boot/
shian:/boot# cp -ax . /mnt/md0

Instalamos y reconfiguramos grub en los dos discos.

shian:~# grub

grub> root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83

grub> setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/grub/stage2 /grub/menu.lst"... succeeded
Done.

grub> root (hd1,0)
 Filesystem type is ext2fs, partition type 0xfd

grub> setup (hd1)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd1)"...  15 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd1) (hd1)1+15 p (hd1,0)/grub/stage2 /grub/menu.lst"... succeeded
Done.

Y ya podemos reinicar la máquina. Hay que tenemos en cuenta que la máquina sólo arrancará del segundo disco porque el primero todavía no forma parte del raid. Si todo va bien, una vez que arranque veremos algo como esto:

shian:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/md2              7.4G  509M  6.5G   8% /
tmpfs                  63M     0   63M   0% /lib/init/rw
udev                   10M  100K   10M   1% /dev
tmpfs                  63M     0   63M   0% /dev/shm
/dev/md0              183M   13M  161M   8% /boot

shian:~# mount
/dev/md2 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/md0 on /boot type ext2 (rw)

Lo más difícil ya está hecho. Tenemos el raid funcionando en modo degradado porque sólo está disponible el disco sdb. Ahora repetimos casi el mismo proceso para el disco antiguo. Cambiamos el tipo de particiones a fd y las añadimos particiones al raid.

shian:~# fdisk /dev/sda
...
Command (m for help): p

Disk /dev/sda: 8589 MB, 8589934592 bytes
255 heads, 63 sectors/track, 1044 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1          24      192748+  fd  Linux raid autodetect
/dev/sda2              25        1044     8193150    5  Extended
/dev/sda5              25          73      393561   fd  Linux raid autodetect
/dev/sda6              74        1044     7799526   fd  Linux raid autodetect
...


shian:~# mdadm --add /dev/md0 /dev/sda1
mdadm: added /dev/sda1
shian:~# mdadm --add /dev/md1 /dev/sda5
mdadm: added /dev/sda5
shian:~# mdadm --add /dev/md2 /dev/sda6
mdadm: added /dev/sda6

Empezará entonces la reconstrucción de los raid.

shian:~# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active raid1 sda6[2] sdb6[1]
      7799424 blocks [2/1] [_U]
      [=====>...............]  recovery = 25.2% (1967936/7799424) finish=1.1min speed=81997K/sec

md1 : active raid1 sda5[0] sdb5[1]
      393472 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      192640 blocks [2/2] [UU]

unused devices: 

   Un vez terminada la reconstrucción tendremos listo el sistema. Ahora, si queremos probar que todo funciona correctamente podemos reinicar de nuevo la máquina y comprobar que es capaz de arrancar desde cualquiera de los dos discos.

   Con este tipo de configuración estamos seguros de que aunque falle un disco nuestro servidor estará disponible y no tendremos que reinstalar ni reconfigurar nada. Sólo será necesario cambiar el disco defectuoso, reconstruir el raid y reconfigurar el grub.

Nokia Maps: Mapas para tu móvil

Este análisis está patrocinado por Zync.es

   Nokia ha sacado al mercado una nueva aplicación para móviles llamada Nokia Maps con la que podemos descargarnos mapas para poder localizar lugares de interes o el sitio al que queremos ir. Es una aplicación gratuita y cuenta actualmente con mapas de 150 paises y más de 15 millones de puntos de interés.

   El funcionamiento es muy simple. Te instalas la aplicación en el móvil, te descargas los mapas de la zona de interés y listo. Si además de eso tu móvil tiene GPS, aparecerás posicionado en el mapa automáticamente.

   La aplicación parece muy completa puesto que permite realizar búsquedas por dirección, lugares cercanos,... Además posee muchas categorías para localizar rápidamente lo que nos interese: restaurantes, hoteles, farmacias,... Incluso puedes compartir tus lugares favoritos con tus amigos por medio de SMS, MMS, bluetooth,...

   La mayor utilidad que puede tener es cuando vas de viaje a una ciudad que no conoces. Puedes descargarte previamente los mapas en el PC por medio del Nokia Maps Loader y sincronizarlos con el móvil. Así, cuando llegues a tu destino no tendrás que preocuparte en pagar una cara conexión de datos para descargar los mapas y podrás empezar a recorrer la ciudad sin problemas. Creo que puede ser una alternativa muy útil a otros navegadores puesto que no tienes que pagar por unos mapas que sólo vas a usar 5 días en tu vida.

El código Geek

   El otro día navegando encontré el Código Geek. De vez en cuando me he encontrando en alguna web esa especie de código raro que no entendía. El caso es que hoy le he dedicado un rato y como buen geek que se precie, aquí teneis el mío.

-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/IT/ d- s: a- C++ UL++ P L++ E--- W+++ N o? K- w O-- M?
V PS PE Y-- PGP t 5? X R tv b DI D+++ G e+++ h--- r+++ y+++
------END GEEK CODE BLOCK------

   Y tú, qué clase de geek eres?.

Crear paquetes deb desde otros formatos

   Cuando utilizaba RedHat, SuSE o Slackware hace algún tiempo para probar y cacharrear o simplemente para hacer las prácticas de la facultad y tenía que instalar algún programa no tenía ningún problema en compilarlo e instalarlo "a lo loco" e incluso trabajar como root. Por aquel entonces, aunque linux me gustaba sólo lo utilizaba como una ayuda durante la carrera para no tener que pasarme las horas en el centro de cálculo pegándome por un terminal VT100 de fósforo verde que me destrozaba la vista. Qué tiempos aquellos... y eso que "sólo" han pasado 10 años desde aquel 1997 en que empecé la carrera (que por cierto ya terminé).

   En fin, que compilaba, hacía make install y no me preocupaba de desinstalar ni de cómo podía quedar el sistema después de eso (total, lo reinstala y punto, no me suponía demasiado). Ahora, desde que utilizo linux como mi sistema operativo principal me preocupa que si me pongo a compilar e instalar compulsivamente o simplemente quiero probar algo, luego me resulte complicado mantener el control de lo que está instalado, desinstalarlo con facilidad,... Aunque con el magnífico apt este problema desaparece para cualquier paquete que descarguemos, en el caso de las compilaciones o de utilidades de las que no existan paquetes .deb la cosa es más compleja. Así, he descubierto un par de utilidades que me van a hacer la vida aún más fácil: alien y checkinstall.

Alien: En ocasiones no hay paquetes en formato .deb pero sin embargo sí existen en formato .rpm. Con esta utilidad los podemos convertir a nuestro formato favorito.

Checkinstall: Cuando compilamos un programa, el paso final suele ser make install que instala los binarios, las librerías, la ayuda del man,... En muy pocas ocasiones viene con un target uninstall del make, por lo que una posterior tarea de desinstalación suele ser algo tediosa. Checkinstall sirve para crear paquetes .deb a partir del código compilado, por lo que si posteriormente queremos desinstalar algo sólo hay que hacer un simple apt-get remove paquete.

Instalarlos es algo tan sencillo como:

ivan@doraemon:~$ sudo apt-get install checkinstall alien

Para convertir los paquetes con alien hacemos:

ivan@doraemon:~$ sudo alien -d paquete.rpm

Y una vez convertido lo podemos instalar como siempre:

ivan@doraemon:~$ sudo dpkg -i paquete.deb

Si por el contrario tenemos el código fuente para compilarlo utilizaremos checkinstall, para ello hacemos:

ivan@doraemon:~$ tar zxvf paquete.tar.gz
ivan@doraemon:~$ cd paquete
ivan@doraemon:~/paquete $ ./configure
ivan@doraemon:~/paquete $ make
ivan@doraemon:~/paquete $ sudo checkinstall

Y después de unas cuantas preguntas tendremos creado nuestro paquete.deb listo para instalar y mantener.

Monitorizando sistemas con Nagios

Nagios es un sistema de código abierto de monitorización de redes, máquinas, servicios, sistemas, filesystems... muy flexible que permite definir distintos tipos de alertas en función de la disponibilidad de los objetos monitorizados.

   En mi anterior trabajo lo instalé y configuré para monitorizar distintos entornos que gestionábamos y también para la monitorización remota de filesystems. He rescatado el pequeño documento que hice en su momento y este es el resultado después de completarlo con explicaciones más detalladas, ejemplos y alguna captura.

   Lo primero que debo aclarar es que está basado en la versión 2.4 de Nagios, siendo la versión estable actual la 2.10. No debería haber muchas diferencias por lo que supongo que todo lo que voy a contar funcionará sin problemas. La máquina en la que monté el servidor Nagios es una Sun Fire 280R con Solaris 8 y obviamente no tenía permisos de root, por lo que la instalación está hecha con un usuario normal (vtprov) siendo su home /internet/vtprov. Además, al ser una máquina con Solaris no hay paquetes de binarios ya compilados, por lo que toca compilar desde el código fuente. El caso de la instalación para Linux debería ser similar.

Instalación
Después de descargar y desempaquetar el .tar generamos el fichero Makefile:

$ ./configure --prefix=PREFIX --with-nagios-user=SOMEUSER --with-nagios-group=SOMEGROUP

Donde: PREFIX es la ruta en donde queremos instalar y que llamaremos $NAGIOS_HOME.
           SOMEUSER es el usuario que ejecutará Nagios.
           SOMEGROUP es el grupo del usuario que ejecutará Nagios.
Después simplemente compilamos:

$ make all

Y finalmente instalamos en la ruta que hayamos configurado anteriormente:

$ make install

   Para comprobar el estado de los servicios, sistemas,... Nagios utiliza diversos plugins programados en C. Es necesario descargar y compilar dichos plugins e instalarlos en Nagios. La utilización de plugins hace que Nagios sea muy potente respecto a los sistemas que puede monitorizar puesto que si no existe ningún plugin que nos interese, siempre es posible crear uno a medida.
   La compilación de los plugins es exáctamente igual a la de Nagios y una vez compilados deben almacenarse en el directorio $NAGIOS_HOME/libexec.

Configuración
   Nagios se configura mediante archivos de texto que se encuentran en $NAGIOS_HOME/etc. Los principales archivos son:

nagios.cfg: Es el archivo principal de Nagios. En él, además de diversas opciones de configuración se definen las rutas del resto de archivos de configuración. Podemos elegir si queremos un archivo con toda la configuración o múltiples archivos más pequeños. En mi caso elegí un único archivo.

checkcommands.cfg: En este archivo se define el nombre lógico y físico de los comandos de monitorización que se utilizarán así como los parámetros de reciben.

misccommands.cfg: Se definen las plantillas que se utilizarán para los emails de notificación.

bigger.cfg: Archivo principal en el que se configuran los servicios que se desean monitorizar, notificaciones, comandos para la monitorización, agrupación de servicios,...

   A continuación muestro con un poco más de detalle los archivos de configuración y añado ejemplos de configuración. Sólo he seleccionado algunas partes concretas puesto que algunos son muy grandes y tienen muchas opciones. Cada una de ellas viene con una pequeña explicación sobre su utilización.

nagios.cfg
   Hay que prestar especial atención a la opción check_external_commands puesto que sin habilitarla no podremos comprobar el estado de un servicio que deseemos en un momento determinado, sino que sólo se ejecutará la comprobación según se haya planificado.

# OBJECT CONFIGURATION FILE(S)

# Plugin commands (service and host check commands)
cfg_file=/internet/vtprov/nagios/etc/checkcommands.cfg

# Misc commands (notification and event handler commands, etc)
cfg_file=/internet/vtprov/nagios/etc/misccommands.cfg

# You can split other types of object definitions across several
# config files if you wish (as done here), or keep them all in a
# single config file.
cfg_file=/internet/vtprov/nagios/etc/bigger.cfg

# NAGIOS USER
nagios_user=vtprov

# NAGIOS GROUP
nagios_group=users

# EXTERNAL COMMAND OPTION
# This option allows you to specify whether or not Nagios should check
# for external commands (in the command file defined below).  By default
# Nagios will *not* check for external commands, just to be on the
# cautious side.  If you want to be able to use the CGI command interface
# you will have to enable this.  Setting this value to 0 disables command
# checking (the default), other values enable it.

check_external_commands=1
[...]

checkcommands.cfg
   Estos son algunos de los comandos (plugins) que podemos usar para comprobar el estado de los servicios. Por ejemplo, el comando check_http realiza una simple llamada GET a la máquina definida en el parámetro $ARG1$, al puerto $ARG2$ y a la URL $ARG3$. Esta llamada la usábamos para comprobar el estado de diversos servlets que estaban corriendo en distintas instancias de servidores tomcat.
   El comando check_http_wm es una personalización del anterior (fijaos que el command_line es el mismo) pero se conecta con un usuario y password que pasamos como parámetro.
   También muestro el ejemplo del ping y también el comando check_nrpe que veremos posteriormente para ejecutar scripts en máquinas remotas y en función del resultado lanzar o no una alarma.

define command{
    command_name    check_ping
    command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}

define command{
    command_name    check_http
    command_line    $USER1$/check_http -H $ARG1$ -p $ARG2$ --url=$ARG3$
}

define command{
    command_name    check_http_wm
    command_line    $USER1$/check_http -H $ARG1$ -p $ARG2$ -a USER:PASSWD
} 
        
define command{
    command_name    check_nrpe
    command_line    $USER1$/check_nrpe -H $HOSTADDRESS$ -p $ARG1$ -c $ARG2$ -a $ARG3$ $ARG4$ $ARG5$
}

misccommands.cfg
   En mi caso cambié el command_line que venía por defecto por el que muestro a continuación puesto que así se envía más información en la alerta que nos llega por email.

# 'notify-by-email' command definition
define command{
 command_name notify-by-email
 command_line /usr/bin/printf "Subject: ** $NOTIFICATIONTYPE$ alert - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ ** %b\n\n ***** Nagios  *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService: $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState: $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional Info:\n\n$SERVICEOUTPUT$" | /usr/bin/mail $CONTACTEMAIL$
}

bigger.cfg
   Como ya he comentado este es el archivo de configuración en el que damos de alta todos los servicios que queremos monitorizar. Además, también definimos los periodos de monitorización, usuarios, agrupamos los servicios,...

Definición de periodos en los cuales se notifican los cambios de estado de los servicios. En este caso definimos dos: 24x7 y Workhours. Luego, al dar de alta un servicio para monitorizar le asociamos uno de estos periodos, de tal forma que sólo se envían notificaciones si estamos en el periodo definido.

# '24x7' timeperiod definition
define timeperiod{
    timeperiod_name   24x7
    alias             24 Hours A Day, 7 Days A Week
    sunday            00:00-24:00
    monday            00:00-24:00
    tuesday           00:00-24:00
    wednesday         00:00-24:00
    thursday          00:00-24:00
    friday            00:00-24:00
    saturday          00:00-24:00
}

# 'workhours' timeperiod definition
define timeperiod {
    timeperiod_name   Workhours
    alias             "Normal" Working Hours
    monday            08:00-19:00
    tuesday           08:00-19:00
    wednesday         08:00-19:00
    thursday          08:00-19:00
    friday            08:00-15:00
}

Definición de grupos de notificación. Los emails a los que notificar separdados por comas y el periodo de notificación definido anteriormente.

# 'vt-prov' contact definition
define contact {
    contact_name                    vt-prov
    alias                           Nagios Admin
    service_notification_period     24x7
    host_notification_period        24x7
    service_notification_options    w,u,c,r
    host_notification_options       d,u,r
    service_notification_commands   notify-by-email
    host_notification_commands      host-notify-by-email
    email                           user1@empresa.com,user2@empresa.com
}

Definición de máquinas y agrupación de las mismas.

# 'host1' host definition
define host{
    use                     generic-host
    host_name               host1
    alias                   Servidor host1
    address                 172.24.88.169
    check_command           check-host-alive
    max_check_attempts      10
    check_period            24x7
    notification_interval   120
    notification_period     24x7                 
    notification_options    d,u,r                
    contact_groups          vt-prov              
}                                                
                                                 
# 'solaris-servers' host group definition        
define hostgroup{                                
    hostgroup_name   solaris-servers             
    alias            Solaris Servers             
    members          host1,host2,host4,host6     
}

Definición de servicios a monitorizar: Esta es la parte más importante y es donde realmente damos de alta todos los servicios que deseamos monitorizar. Como ejemplo muestro el ping para saber si la máquina está activa, la comprobación de un servicio corriendo en un tomcat y la ocupación de un filesystem:
Ping

define service{                             
    use                    generic-service                          
    host_name              host1                               
    service_description    PING
    is_volatile            0
    check_period           24x7
    max_check_attempts     4
    normal_check_interval  1
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  120
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_ping!100.0,20%!500.0,60%
}

Servlet en Tomcat

define service{
    use                    generic-service
    host_name              host2
    service_description    ENTORNO1 - Servicio2
    is_volatile            0 
    check_period           24x7
    max_check_attempts     1
    normal_check_interval  5
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  10
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_http!host2!10102!/servicio/jsp/autent/login.jsp
}

Ocupación Filesystem

define service{
    use                    generic-service
    host_name              host2
    service_description    host2 - /var
    is_volatile            0 
    check_period           24x7
    max_check_attempts     1
    normal_check_interval  5
    retry_check_interval   1
    contact_groups         vt-prov
    notification_interval  120
    notification_period    24x7
    notification_options   w,u,c,r
    check_command          check_nrpe!7997!check_disk!7!5!/var
}

Agrupación de servicios en un grupo: De esta forma se actua sobre todo el grupo a la vez. Esto es útil cuando por ejemplo hay una intervención en una máquina o se está actualizando un entorno completo y se quieren deshabilitar todas las alarmas de ese entorno a la vez.

define servicegroup{
    servicegroup_name      ENTORNO1 - TOMCATs
    alias                  ENTORNO1 - TOMCATs
    members                host2,ENTORNO1 - Servicio2,host2,ENTORNO1 - Servicio3,host2,ENTORNO1 - Servicio8
}

   Una vez definidos los servicios que deseamos monitorizar, podemos verificar si el archivo de configuración es correcto o contiene algún error. Desde el directorio $NAGIOS_HOME/bin:

$ nagios -v ../etc/nagios.cfg
Nagios 2.4
Copyright (c) 1999-2006 Ethan Galstad (http://www.nagios.org)
Last Modified: 05-31-2006
License: GPL

Reading configuration data...

Running pre-flight check on configuration data...

Checking services...
        Checked 82 services.
Checking hosts...
        Checked 5 hosts.
Checking host groups...
        Checked 1 host groups.
Checking service groups...
        Checked 16 service groups.
Checking contacts...
        Checked 1 contacts.
Checking contact groups...
        Checked 1 contact groups.
Checking service escalations...
        Checked 0 service escalations.
Checking service dependencies...
        Checked 0 service dependencies.
Checking host escalations...
        Checked 0 host escalations.
Checking host dependencies...
        Checked 0 host dependencies.
Checking commands...
        Checked 26 commands.
Checking time periods...
        Checked 4 time periods.
Checking extended host info definitions...
        Checked 0 extended host info definitions.
Checking extended service info definitions...
        Checked 0 extended service info definitions.
Checking for circular paths between hosts...
Checking for circular host and service dependencies...
Checking global event handlers...
Checking obsessive compulsive processor commands...
Checking misc settings...

Total Warnings: 0
Total Errors:   0

Things look okay - No serious problems were detected during the pre-flight check

   Como no hay ningún error podemos arrancar Nagios:

$ nagios -d ../etc/nagios.cfg

   En este momento se empezarían a monitorizar los sistemas que tengamos definidos y se enviarían notificaciones por email si se han configurado.

Interfaz Web
   Para poder interactuar con el sistema y ver todo de un modo gráfico es necesario configurar la consola web de Nagios. Para ello es necesario un servidor Apache. Instalamos el servidor y en el archivo httpd.conf añadimos lo siguiente:

ScriptAlias /nagios/cgi-bin "/internet/vtprov/nagios/sbin/"
    <Directory "/internet/vtprov/nagios/sbin">
        AllowOverride AuthConfig
        Options +ExecCGI
        Order allow,deny
        Allow from all
    </Directory>

    Alias /nagios "/internet/vtprov/nagios/share"
    <Directory "/internet/vtprov/nagios/share">
        Options None
        AllowOverride AuthConfig
        Order allow,deny
        Allow from all
    </Directory>

   Reiniciamos apache y ya nos deberíamos poder conectar a la consola de administración:


Control de Acceso
   Se pueden definir distintos usuarios para conectarse a Nagios con diferentes permisos y que verán únicamente los servicios en los que se hayan añadido como contacto. Para ello utilizamos las opciones de autenticación que ofrece Apache.
   Creamos el archivo .htaccess en los directorios share y sbin con el siguiente contenido:

AuthName "Acceso a Nagios"
AuthType Basic
AuthUserFile /internet/vtprov/nagios/etc/htpasswd.users
require valid-user

   Y creamos el archivo de passwords desde el directorio bin de la instalación de Apache añadiendo el usuario nagios.

$ htpasswd -c /internet/vtprov/nagios/etc/htpasswd.users nagios

   Ahora al conectarnos a Nagios nos aparecerá la típica ventana solicitando nuestro usuario y password.


Comandos remotos
   Para poder ejecutar scritps en máquinas remotas, como por ejemplo, para comprobar el tamaño de los filesystems de otras máquinas, necesitamos instalar un pequeño servidor en dichas máquinas. Este servidor se llama NRPE (Nagios Remote Plugin Executor). Es necesario descargarlo y compilarlo tal y como hemos hecho con Nagios.

   La configuración es muy sencilla: En cada máquina que queramos monitorizar la ocupación de sus filesystems debemos configurar el archivo nrpe.cfg en el que básicamente hay que indicar el puerto en el que queremos levantar el servidor, el usuario y el grupo que lo ejecutan y activar la opción para permitir recibir comandos remotos con parámetros. El fichero de configuración tiene el siguiente aspecto (como antes, incluyo sólo lo más importante).

# PORT NUMBER
server_port=7997

# SERVER ADDRESS
server_address=172.24.88.169

# ALLOWED HOST ADDRESSES
# This is a comma-delimited list of IP address of hosts that are allowed
# to talk to the NRPE daemon.
allowed_hosts=127.0.0.1,172.24.86.11

# NRPE USER
nrpe_user=nrpe

# NRPE GROUP
nrpe_group=users

# COMMAND ARGUMENT PROCESSING
# This option determines whether or not the NRPE daemon will allow clients
# to specify arguments to commands that are executed.  This option only works
# if the daemon was configured with the --enable-command-args configure script
# option.  
#
# *** ENABLING THIS OPTION IS A SECURITY RISK! *** 
# Read the SECURITY file for information on some of the security implications
# of enabling this variable.
#
# Values: 0=do not allow arguments, 1=allow command arguments
dont_blame_nrpe=1

# COMMAND DEFINITIONS
command[check_disk]=/home/user/nrpe/check_disk.sh $ARG1$ $ARG2$ $ARG3$

   Hay que destacar la opción dont_blame_nrpe ya que tal y como se indica activarla puede representar un problema de seguridad porque estamos aceptando parámetros y podría realizarse algún tipo de ataque a la máquina por este medio. En mi caso lo habilité porque el script que comprueba el tamaño del filesystem necesita dichos parámetros y no representaba ningún problema de seguridad.
   Al final también hemos añadido el comando remoto que se ejecutará (check_disk) y la llamada al script con los parámetros necesarios. Este script debe existir en la máquina de la que deseamos monitorizar los filesystems.

   Recordemos que antes definimos la ejecución del script check_disk (para un filesystem y máquina concretos) como:

check_nrpe!7997!check_disk!7!5!/var

   En esta llamada 7997 es el puerto del nrpe en la máquina remota, check_disk es el nombre lógico del script y 7, 5 y /var son los parámetros del script. Éste comprueba el porcentaje de espacio libre del filesystem que recibe como parámetro y lo compara con los dos umbrales que le pasamos. Si es menor de un 7% genera un warning y si es menor de un 5% genera un error crítico.

   El script check_disk.sh que acabamos de ver y que definíamos anteriormente en el archivo bigger.cfg es el siguiente:

#!/bin/ksh
# check_disk.sh: Comprueba el tamaño de un filesystem y 
# devuelve el estado en función de dos umbrales definidos.
#
# Iván López Martín

warning=$1
critical=$2
filesystem=$3

STATE_OK=0
STATE_WARNING=1
STATE_CRITICAL=2

size=`df -k $filesystem | grep $filesystem | awk '{print $4}'`
sizeMB=`echo "$size/1024" | bc`
percentage=`df -k $filesystem | grep $filesystem | awk '{print $5}' | sed -e s/%//g`
freePercentage=`echo "100-$percentage" | bc`

if [ "$freePercentage" -le "$critical" ]; then
   echo "DISK CRITICAL - free space: "$filesystem" $sizeMB MB"
   return $STATE_CRITICAL
fi
if [ "$freePercentage" -le "$warning" ]; then
   echo "DISK WARNING - free space: "$filesystem" $sizeMB MB"
   return $STATE_WARNING
fi

echo "DISK OK - free space: "$filesystem" $sizeMB MB"
return $STATE_OK

   Con los scripts remotos configurados arrancamos el demonio nrpe:

$ nrpe -c nrpe.cfg -d

   Como veis, me he hecho mi propio script para comprobar remotamente los filesystems de las distintas máquinas. Aunque dije inicialmente que los plugins que vienen con Nagios están escritos en C, se puede utilizar cualquier lenguaje que soporte la máquina para comprobar el estado del servicio que deseemos.

   Este script nos era especialmente útil sobre todo para comprobar la ocupación del filesystem /var. Cuando veíamos que estaba bastante lleno sólo teníamos que enviar un email a administración Unix para que borrasen logs antiguos y nos liberaran algo de espacio.

Interfaz gráfica
   A continuación muestro una serie de capturas de pantalla de la interfaz gráfica con todos los servicios que teníamos configurados en su momento.

Servicios	Máquinas

Agrupación de servicios	Opciones de servicios

Conclusiones
   Lo que más me gusta de Nagios es que es muy sencillo de configurar y que con el simple hecho de dar de alta un servicio, automáticamente ya lo estamos monitorizando.
   En su momento también probé herramientas como Hyperic HQ y aunque visualmente son más bonitas, descubren automáticamente los servicios que hay corriendo en las máquinas,... al final son más engorrosas. En mi caso, en algunas máquinas descubría "demasiados" servicios y había que estar eliminando todos los que no queríamos monitorizar. Además, había que definir una a una las alarmas para cada uno de esos servicios. Al final, después de probarla durante un tiempo la descarté y me quedé con Nagios.

Primer Viernes Técnico de OpenSolaris

   Como ya comenté hace unas semanas me apunté a unas charlas técnicas que impartía la comunidad española de OpenSolaris. La primera de ellas fue el pasado viernes 2 de febrero y estuvo genial. Nos dieron una documentación muy completa con ejemplos de todo lo que nos contaron y un DVD para que nos animáramos a instalarlo en casa. La charla fue muy amena y se notaba que el nivel de los participantes era muy alto porque en algunas ocasiones completaban las respuestas que ofrecían los organizadores. Los temas que trataron fueron:

Distintas versiones de OpenSolaris.

La instalación.

En nuevo gestor de arranque SMF (Service Management Facility).

La virtualización con zonas.

Vimos una máquina SunFire 280R "por dentro" puesto que la mayoría no conocíamos la arquitectura Sparc.

   Además también me dieron esta camiseta que veis a continuación (tienes envidia Alex? :-P)

   También conocimos a Álvaro López que es el creador de Cherokee, el nuevo servidor web que está llamado a sustituir a Apache. En su blog ha colgado algunas fotos del evento y es posible que en alguna se me vea un poco... ;-)

   Ahora ya me ha picado el gusanillo y cuando tenga un rato lo instalaré en una máquina virtual para probar. Además tengo muchas ganas de que lleguen las dos próximas charlas sobre Virtualización y ZFS.

   Como anécdota final diré que en el office que había al lado de la sala de la charla se veía el siguiente cartel (foto con móvil) y que me llamó la atención porque a primera vista parecía un cartel de salida de emergencia pero luego ponía HP AWAY y la lista de empresas que habían migrado a servidores Sun.

Truecrypt en Linux con kernel 2.6.23

   Para el que no lo conozca, Truecrypt es una mágnifica utilidad libre y de código abierto multiplataforma para windows y linux que permite entre otras muchas opciones crear discos virtuales cifrados para poder almacenar nuestra información confidencial de manera segura. Además, proporciona un modo de funcionamiento traveller en el que no es necesario tener nada instalado y que podemos ejecutar desde un pendrive. Así, podemos llevar toda la información de nuestro pendrive cifrada y descifrarla al vuelo y en cualquier ordenador en el momento en que la necesitemos.

   En la web existen numerosos tutoriales sobre cómo crear volúmenes cifrados, las distintas opciones, elegir el algoritmo de cifrado,... Además el apartado de documentación de la web oficial es muy completo y extenso. En este artículo lo que quiero contar es cómo compilar truecrypt en linux utilizando un kernel superior a 2.6.23.

   Lo primero de todo es descargarlo. Existen binarios compilados para unas cuantas distribuciones (OpenSuSE 10.2, OpenSuSE 10.3 y algunas versiones de Ubuntu), pero en mi caso no me servían porque están pensados para el kernel estándar y yo trabajo con una versión compilada por mi del kernel. Así, me descargué el código fuente y me dispuse a compilarlo e instalarlo. Enseguida encontré el primer problema porque nada más empezar la compilación aparecía un error:

ivan@doraemon:~$ tar zxf truecrypt-4.3a-source-code.tar.gz
ivan@doraemon:~$ cd truecrypt-4.3a-source-code/Linux
ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./build.sh
Checking build requirements...
Building kernel module... /home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c: In function `dm_truecrypt_init´:
/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c:659: error: too many arguments to function `kmem_cache_create´
make[2]: *** [/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.o] Error 1
make[1]: *** [_module_/home/ivan/truecrypt-4.3a-source-code/Linux/Kernel] Error 2
make: *** [truecrypt] Error 2
Error: Failed to build kernel module

   Buscando un poco de información por la red encontré este post en un foro de Fedora en el que cuentan una solución. Todo pasa por editar el archivo Dm-target.c y en la línea 659 quitar el último NULL.

//bio_ctx_cache = kmem_cache_create ("truecrypt-bioctx", sizeof (struct bio_ctx), 0, 0, NULL, NULL);
bio_ctx_cache = kmem_cache_create ("truecrypt-bioctx", sizeof (struct bio_ctx), 0, 0, NULL);

Ahora, compilando de nuevo:

ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./build.sh
Checking build requirements...
Building kernel module... Done.
Building truecrypt... Done.

Instalamos

ivan@doraemon:~/truecrypt-4.3a-source-code/Linux$ sudo ./install.sh
Checking installation requirements...
Testing truecrypt... Done.

Install binaries to [/usr/bin]:
Install man page to [/usr/share/man]:
Install user guide and kernel module to [/usr/share/truecrypt]:
Installing kernel module...
Done.
Installing truecrypt to /usr/bin... Done.
Installing man page to /usr/share/man/man1... Done.
Installing user guide to /usr/share/truecrypt/doc... Done.
Installing backup kernel module to /usr/share/truecrypt/kernel... Done.

   Espero que le pueda servir a alguien porque yo estuve un buen rato buscando hasta que encontré la solución. Ahora ya podemos utilizar esta magnífica herramienta para cifrar toda nuestra información sensible tanto en linux como en windows en nuestro pendrive.

   Como nota final diré que hace unos días han publicado en HowtoForge un artículo con una GUI para el Truecrypt de Linux y unos sencillos pasos para configurarlo y dejarlo todo a punto.

Calendario de Sotfware Libre

   Descubrí el otro día en microteknologías un calendario de escritorio de software libre. Cada mes tiene un animal que es la mascota de alguna aplicaciones libre. Así están Tux, el Geeko de openSuSE, Sakila de MySQL o el panda rojo de Firefox entre otros. Me lo descargué y esta mañana he estado montándolo. Estos son los pasos y al final el resultado:

Las hojas impresas	Cada mes recortado y ajustado al máximo

La plantilla y el soporte	Y el resultado final!

   Ya lo tengo listo y preparado para llevármelo el lunes al trabajo y presumir de calendario entre los compañeros.

Administrando un HP Proliant con Integrated Lights-Out

   Integrated Lights-Out (iLO) es una tecnología que incorporan algunos servidores HP que permite administrar e interactuar completamente con la máquina en remoto aunque ésta se encuentre apagada. Utiliza una interfaz de red independiente que se puede configurar en el arranque de la máquina. Una vez que le asignamos dirección IP, máscara de red y creamos un usuario ya nos podemos conectar a la máquina desde el navegador web.

   Una vez conectados a la consola, introducimos nuestro usuario y password y accedemos a la ventana principal en la que podemos ver el estado del servidor.

   Podemos encender el servidor en remoto y desde la consola virtual ver todo el proceso de arranque.

   La única pega es que por defecto la consola sólo muestra la información en modo texto y para mostrar gráficos es necesario pasar por caja y comprar una licencia avanzada. No obstante en la web de HP se puede descargar una versión de prueba de 60 días. Así, una vez activada podemos ver el arranque gráfico e interactuar con el servidor.

   Esto no me ocurre con el servidor que tengo instalado con VMware ESX puesto que nuestro sistema operativo favorito arranca en modo texto.

   No conocía esta gran utilidad que proporcinan los servidores pero me parece realmente útil cuando tenemos muchos en un CPD y ocurre un problema con alguno. Cómodamente sentados en nuestro sitio podemos reiniciar la máquina y comprobar el arranque para ver cual es el fallo. Para nuestros PCs de casa siempre tendremos la opción de utilizar un cable null modem con Linux.

Charlas técnicas de OpenSolaris

   Ayer me enteré vía barrapunto que la comunidad hispana de OpenSolaris organiza unas jornadas técnicas gratuitas sobre OpenSolaris en Madrid los últimos viernes de febrero, marzo y abril, así que me decidí y me apunté. Al principio abrieron 30 plazas pero finalmente han sido 40 y he podido inscribirme.

   En mi anterior empleo trabajaba mucho con máquinas con Solaris y siempre me ha picado un poco el gusanillo de aprender un poco más y no centrarme sólo en Linux. Además, Alex desde que le gusta Solaris me ha dado la brasa bastante para que le dedique un poco de tiempo a OpenSolaris. Mi única pega es que mis conocimientos de administración de Solaris son nulos y no sabría por donde empezar, así que estas charlas creo que me van a venir muy bien. Si me convence finalmente OpenSolaris prometo un post contando mi experiencia instalándolo y probándolo en casa.

    En fín, que si alguno se pasa por allí ya comentaremos qué nos han parecido.

ACTUALIZACIÓN 17/01/2008
   Se van a impartir los mismos cursos en otras fechas. Los que se quedaron sin plaza puede que todavía estén a tiempo. Más información en Viernes Técnicos OpenSolaris.

Pateando el culo a ZP... en la Wii

   Otro de los regalos de cumpleaños que tuve en mi cumpleaños fue una Nintendo Wii. Me la regalaron mis padres/abuelos/hermana y desde entonces hemos jugado bastante. Además, ahora con el segundo mando las partidas al WiiSports son mucho más interesantes.

   La Wii es una consola totalmente distinta del resto de las disponibles en el mercado, su forma de jugar engancha desde el principio y aunque los gráficos no son como los de la Xbox360 o la PS3 su jugabilidad creo que es muy superior. Si hasta mi mujer se ha enganchado y eso que no le gustan las consolas!!.

   Aprovechando el canal Concursos Miis estuvimos viendo los Mii's (muñecos que puedes crear a tu gusto y que te representan en algunos juegos) que había hecho la gente y hemos importado algunos. Ahora tenemos a Doraemon, ZP, Einstein, Urkel,... y he aprovechado para pegarle una buena paliza virtual en el boxeo a ZP. Así le agradezco la ayuda de 2500 euros por hijo nacido sólo a partir del 1 de Julio cuando inicialmente dijo que era a partir del 3 (mi peque nació el 18 de Junio), por el canon digital, el euribor,... y todo lo que se me ocurra.

Podéis ver el Mii que me representa y al otro lado a ZP.
P.D: También tengo importados Miis de Rajoy, Carod Rovira y demás políticos para desestresarme pegándoles un rato :-P