Missing [Code]

Me encontré esta historia en menéame y quería compartirla con ustedes, estaba catalogada como “el fallo informatico mas difícil del mundo” de paso, propongo que en los comentarios pongan situaciones similares a las que hayan tenido que enfrentarse, fallos con soluciones simples pero difíciles de encontrar, que la disfruten!!!
From trey@sage.org Fri Nov 29 18:00:49 2002
Date: Sun, 24 Nov 2002 21:03:02 -0500 (EST)
From: Trey Harris
To: sage-members@sage.org
Subject: El caso del email de las 500 millas

Aquí tenéis un problema que os sonará imposible.. Casi me da pena contarlo a una
audiencia más amplia; era una buena anécdota para contar en conferencias La
historia ha sido alterada ligeramente para proteger a los culpables, ignorar
detalles irrelevantes y hacerla en general más amena.

Me encontraba trabajando como administrador de los sistemas de correo de un
campus universitario hace algunos años cuando recibí una llamada del encargado
del departamento de estadística.

“Estamos teniendo un problema para enviar emails fuera del departamento.”

“¿Cuál es el problema?” pregunté yo

“No podemos enviar emails más allá de 500 millas” explicó el jefe de
departamento.

Me atraganté con el café. “¿Podrías repetirlo?”

“No podemos enviar emails a más de 500 millas del departamenteo” repitió. “En
realidad un poco más, unas 520 millas pero no más.”

“Um… El correo electrónico no funciona de esa forma, generalmente.” dije
tratando de no dejar entrever pánico en mi voz. Uno no debe mostrar pánico
cuando está hablando con un jefe de departamento, incluso aunque sea de un
departamento tan pobre como el de estadística. “¿Qué te hace pensar que no
puedes enviar emails a más de 500 millas?

“No es lo que *yo piense*” repitio testarudamente. “Mira, cuando nos dimos
cuenta por primera vez hace unos días..”

“¿Esperasteis unos DÍAS?” interrumpí con un ligero temblor en mi voz. “Y no
habéis podido enviar emails en todo este tiempo”

“No hemos podido enviar emails a más de..”

“500 millas, sí.” acabé su frase. “Lo entiendo. Pero por qué no avisasteis
antes?”

“Bueno, no habíamos recopilado suficientes datos como para estar seguros de lo
que estaba ocurriendo hasta ahora.” Lógico, estoy hablando con el jefe del
departamento de *estadística*. “Además, le pregunté a uno de los geostadísticos
para que lo investigasen..”

“Geostadísticos..”

“.. Sí, y ha elaborado un mapa que muestra que el radio dentro del cual podemos
enviar emails es justo de un poco más de 500 millas. Hay algunos destinos dentro
de ese radio a los que no llegamos o a los que llegamos esporádicamente, pero no
podemos llegar más allá de ese radio.”

“Ya veo”, dije y puse la cabeza entre mis manos. “¿Cuándo empezó todo esto? Hace
unos días has dicho, ¿cambió algo en vuestros sistemas en ese momento?”

“Bueno, el consultor vino, parcheó nuestro servidor y lo reinició. Pero le llamé
y me dijo que no había tocado nada del sistema de correo.”

“De acuerdo, déjame echarle un vistazo y te llamaré más tarde”, dije, sin
creerme que le estaba siguiendo la corriente. No era el día de los inocentes.
Intenté recordar si alguien me debía alguna broma pesada.

Inicié sesión en el servidor de su departamento y envié algunos emails de
prueba. Estábamos en el Triángulo de Investigación del Norte de Carolina, y un
email de prueba a mi propia cuenta llegaba sin problemas. Lo mismo con uno
enviado a Richmond, Atlanta y Washington. Otro enviado a Princetown (400 millas)
funcionó igualmente.

Pero cuando intentaba enviar un email a Memphis (600 millas) fallaba. Boston,
fallaba. Detroit, fallaba. Saqué mi libreta de direcciones y empecé a afinar.
New York (420 millas) funcionaba, pero Providence (580 millas) fallaba.

Estaba empezando a pensar si había perdido el juicio. Intenté enviar un email a
un amigo que vivía en Carolina del Norte pero cuyo ISP estaba en Seattle.
Gracias a dios, fallaba. Si el problema hubiese tenido que ver con la
localización del recipiente humano y no con el del servidor creo que me habría
echado a llorar.

Después de haber establecido –incrédulamente– que la incidencia reportada era
cierta y reproducible me puse a mirar el sendmail.cf. Parecía bastante normal,
de hecho me resultaba familiar.

Lo comparé con el sendmail.cf de mi directorio home. No había sido alterado; era
el sendmail.cf que yo había escrito. Y estaba bastante seguro de no haber
activado la opción “FALLAR_EMAIL_500_MILLAS”. Como último recurso conecté por
telnet al puerto SMTP. El servidor me respondió alegremente con un banner de
sendmail de SunOS.

Espera un minuto, ¿un banner de sendmail de SunOS? En ese momento Sun todavía
distribuía Sendmail 5 junto al sistema operativo aunque Sendmail 8 ya era
bastante estable. Siendo como soy un buen administrador de sistemas había
estandarizado la red en Sendmail 8. Y también como buen administrador que soy
había escrito un sendmail.cf que usaba los agradables y descriptivos nombres de
variables y de opciones que estaban disponibles en Sendmail 8 en lugar de los
códigos de puntuación crípticos que se usaban en
Sendmail 5.

Todas las piezas encajaron de golpe y me atraganté de nuevo con el café que ya
estaba frío. Cuando el consultor actualizó la versión de SunOS rebajó la versión
de Sendmail. La actualización dejó el sendmail.cf tranquilo aunque ahora fuese
para otra versión.

Lo que ocurría era que Sendmail 5 — o al menos la versión que distribuía Sun
tenía algunas modificaciones — podía trabajar con archivos de configuración de
Sendmail 8 ya que todas las reglas se habían mantenido inalteradas. Pero las
nuevas opciones con nombres largos las veía como basura y las ignoraba. Y el
ejecutable de sendmail no traía valores por defecto compilados así que todas las
variables para las que no encontraba una declaración explícita y válida en el
sendmail.cf se ponían a 0.

Una de las opciones que se puso a 0 fue el tiempo de espera para conectar a un
servidor SMTP remoto. Experimentaciones con esta máquina en particular con su
carga típica daban que un timeout de 0 abortaría una conexión en aproximadamente
3 ms.

Una extraña característica de la red de nuestro campus es que estaba 100%
switcheada. Un paquete saliente no se retrasaría hasta llegar al router del lado
opuesto al que conectase. Así que el tiempo de conexión para un host remoto
ligeramente cargado en una red cercana estaría determinado por la velocidad de
la luz en lugar de por retrasos incidentales del router.

Sintiendo un ligero mareo escribí en mi shell:

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979

“500 millas, o un poco más.” trey

Fuente: Link