Lo mejor que le puede pasar a un cruasán

Lo mejor que le puede pasar a un cruasán es que lo unten de mantequilla. Y lo mejor que le puede pasar a un BOFH es que el upgrade de un servidor funcione.

Así, esta semana, en vez de escribir para el blog, me he dedicado al sano deporte de los upgrades[*] de emergencia. Este insigne deporte proporciona unos subidones de adrenalina que ya quisieran los del puenting. Más o menos, el subidón de adrenalina seria como el puenting pero sin cuerda. Y sin casco. Y en pelota picada. Y con un bajo-puente lleno de cactus.

Este deporte de alto riesgo, para que cuente como modalidad olímpica, necesita de varios elementos imprescindibles.

Para empezar, es indispensable contar con un servidor en producción, es decir, que se trate de un ordenador de esos que usa todo el mundo, a la vez, constantemente y a todas horas. ?Que emoción tiene un upgrde de emergencia en un obscuro servidor de pruebas con un único usuario? !Sé valiente! !Usa el servidor que usan todos los jefes, jefecillos y jefazos de tu curro!

Evidentemente, el servidor debe de correr sobre jarguarre de lo más prehistórico posible. A poder ser, del siglo pasado. Idealmente, usarás una workstation del siglo pasado, afectada por un rayo, llena de polvo, sin las tapas laterales, con el video incrustado en la placa base quemado, y una tarjeta de red soldada al bus PCI. Claro que sí.

Que más.... ah, si. Que el Sistema Operativo y el software que use el servidor sea antediluviano, sin soporte técnico, sin actualizaciones y tan viejo que no existan referencias en Google a esas versiones. !Faltaria más!

Opcionalmente, puedes haber pedido (!suplicado!) a tu jefe la aprobación del presupuesto y del tiempo requerido para la actualización del servidor de forma controlada, con tiempo suficiente para documentar el proceso, hacer pruebas, usar máquinas virtuales y con unos crucifijos y estampitas de San Judas Tadeo y de San MacGyver en el escritório. Las súplicas, imprescindible que hayan durado dos años. Como mínimo.

Las jornadas de deporte empezaron con un disparo. Asi, en la madrugada de un sabado a un domingo, en la garrapata electroplástica se recibió un mensaje tal que así:

"Oye, Esto no va."

Evidentemente, este diafano mensaje, tan preclaro, tan ilustrativo, tan... idiótico, merece la pena ser estudiado en profundidad. Pero como todo deporte de riesgo de categoria olímpica que se precie, el disparo inicial ya ha sido estudiado con anterioridad.

Resulta que el servidor no respondía ni a pings ni a llamadas a identificacion locales ni a insultos a grito pelado. Total, usando técnicas trans-polinizadoras, CiscoMan le dió al botón de reset tras observar velados mensajes[**] de los discos SCSI.

Y empezó la carrera.

El Lunes, el servidor iba a trancas y barrancas. Mas que ir, se le intuía que quería dirigirse hacia algun lado. Un rápido estudio encargado al CIS (con p=q=50%) desveló que la carga del servidor era 9 veces superior a la normal. Consultando a diestro y siniestro, intenté descubrir un metodo no-botonífero de eliminación de procesos 'D' [***]. Pero la ciencia Linuxera aún no ha avanzado lo suficiente.

?Que es un proceso 'D'?

Los procesos 'D' son procesos ininterrumpibles, que ya están muertos. MWAHAHAHAHAHAHAHA. Y como están muertos, no se pueden matar. Lógico. Generalmente, un proceso 'D' está en vias de descomposición y acaba desapareciendo. Alguna vez, un proceso se vuelve zombie, aunque el uso adecuado del agua bendita, de disparos a la cabeza con balas explosivas y cánticos del sutra acaban eliminando los procesos zombies. Pero un proceso 'D' no está ni vivo ni zombie: está muerto y, si no se evapora, se dedica a tocar los... las joyas de la familia. Vamos, que no están muertos, están de parranda.

El martes, la carga ya era 12 veces superior a la normal. !Qué alegría! !Qué alboroto! Tras recibir miles y miles de llamadas diciendo "Oye, Esto No Va", incluso el Jefe reconoció[****] que Houston, tenemos un problema. Así, tras evitar las propuestas de usar un PC guarrindongo cualesquiera como substituto (que me acabé agenciando igualmente como sistema de pruebas gemelo, en caso de fallo de mi requerdo servidor), habilmente conseguí un servidor de verdad, con discos SCSI, RAID por jarguarre, doble procesador y más RAM que famosos en la tele en un fin de semana.

Entre el martes y el miércoles, hice inventario de todo el softguarre importante del servidor, en pan MiG:

"A vé, loh papeleh!"
"Que nusmero del deneises tieh usté?"
"Que se siente, coño!"

Y fui apuntando todo, todo, todo. Asi tendría constancia de lo que estaba haciendo, aunque fuesen las 3:00am y no me quedara café.

Para mi horror, las versiones de los programas eran de cuando Don Manuel aun no habia hecho su primera comunión. La documentación para pasar de esas versiones a unas versiones actuales incluian ochos cubanos y tirabuzones varios, peregrinaciones a Lourdes y unos cuantos sacrificios en casa del oraculo.

Armado de una Spits Special, un billete de ida y vuelta de Air France y un rebaño de corderos, empecé la migracion.

?Que qué pasó? Otro dia, otro post ;)


Salut,
Sinner

Notas:

[*] "upgrades" = "actualizaciones", en roman paladino.
[**] "velados mensajes" = En la pantalla ponía ERROR, en letras bién gordas
[***] "metodo no-botonifero de eliminación de procesos 'D' " = es decir, evitar darle al reset otra vez
[***] "reconoció" = tengo pruebas grabadas en video